npm	@babel/parser

Type: Missing
Summary:
npm	@babel/parser
Details:
Harvested license file indicates license is MIT
Resolution:
Package.json also indicates license is MIT
Affected definitions:

parser 7.11.1

Closing; license is already declared as MIT.
<EMAIL_ADDRESS>


Specify cairo-lang version = 0.9.1

Specify cairo-lang version = 0.9.1
Description
Specify cairo-lang version = 0.9.1, so the Cairo programs run OK
Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

Codecov Report

Merging #414 (20908cd) into main (c5208a8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #414   +/-   ##
=======================================
  Coverage   96.62%   96.62%
=======================================
  Files          50       50
  Lines        9009     9009
=======================================
  Hits         8705     8705
  Misses        304      304

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


Rebuilding DreaMS Atlas

Context
I am attempting to rebuild the DreaMS Atlas, for the purpose of querying it with external (not already included in Atlas) embeddings. As suggested in the paper, I am using the PyNNDescent library. From my understanding, the NNDescent index can be built by using the objects:

data (array of embeddings of spectra)
init_graph (2D array of indices of candidate neighbors)
init_dist (2D array specifying the metric distance to the neighbors in init_graph)

Thankfully, the DreaMSAtlas object contains the object atlas.dreams_clusters which represent "DreaMS k-NN clusters of GeMS-C1" and the object atlas.csrknn which represents the NNDescent index compressed as a csr matrix. The objects init_graph and init_dist can be easily inferred from the atlas.csrknn, but obtaining the data seems to not be very straightforward.
Problem
Considering that the data component of the NNDescent index is not stored in atlas.csrknn, I assume that the embeddings must be selected from the atlas.lib and self.gems objects, according to the atlas.dreams_clusters. However, atlas.dreams_clusters.shape[0] = 33_642_257 while atlas.csrknn.csr.shape[0] = 33_631_113. There is a difference of 11_144 nodes not accounted for., which leads me to believe that selecting the nodes based on atlas.dreams_clusters is not entirely correct.
Question
Could you please explain how the data necessary for building the NNDescent object can be obtained?

Hi @a-turcu! Thanks for your question.
To build the PyNNDescent index, you can follow the official documentation as follows:
import pynndescent
pynndescent.NNDescent(dreams_embeddings)

where dreams_embeddings is a numpy array with shape (num_embeddings, embedding_dimensionality) containing the embeddings you want to use.
If you’re interested in using GeMS-C1 data, the pre-computed DreaMS embeddings are available on our Hugging Face page in the GeMS_C1_DreaMS.{X}.hdf5 files. The clusters used in our code result from additional BFS-based clustering (an optional step) described in the DreaMS Atlas section of the Online Methods in our paper.

Could you also provide more information on how you use the DreaMS Atlas? According to the log in documentation, it should be atlas.dreams_clusters.shape[0] = 33_631_113 instead of atlas.dreams_clusters.shape[0] = 33_642_257 (i.e., "Loaded DreaMS Atlas nodes representing DreaMS k-NN clusters of GeMS-C1 (33,631,113 nodes)").

Hello @roman-bushuiev,
Running atlas = DreaMSAtlas() outputs:
Initializing DreaMS Atlas data structures...
Loaded spectral library (79,300 spectra).
Loaded GeMS-C1 dataset (75,520,646 spectra).
Loaded DreaMS Atlas edges (100,881,993 edges).
Loaded DreaMS Atlas nodes representing DreaMS k-NN clusters of GeMS-C1 (33,642,257 nodes).
Loaded LSH clusters of DreaMS Atlas nodes representing GeMS-C (201,223,336 spectra).

I did not make any modification to the downloading scripts.

Ok! Thank you. It's strange, I will look into it.

Hi @a-turcu!   I’m sorry for the late reply. The issue should be fixed now: 77723204d1c4fd68e812d7a327b2e1ea67c82c75. Could you check if everything works and let me know?
It's okay that atlas.dreams_clusters.shape[0] != atlas.csrknn.csr.shape[0] because atlas.dreams_clusters includes some NIST20 nodes that we masked in atlas.csrknn.
Please note that if you want to rebuild the atlas on your data, the whole procedure can be significantly simplified:

You can simply have only nodes and edges without any clustering within the nodes if your dataset is smaller than GeMS-C.
Without masking proprietary data (like NIST20), you won’t need to handle the additional mapping between the k-NN graph and the data.

Let me know if you have any further questions!


Implement Firebase remote config API

Closes #134 #172

I'll create a new PR rebased from updated matsr.


chore: Release v1.7.10

Description
Release promotion v1.7.10
Type of change
How Has This Been Tested?
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

/ok-to-test sha=3b7ace67b5c2e42ae6aa1b4c9b788f88c9731df2

/ok-to-test sha=ebe7ec3

Closing this on behalf of https://github.com/appsmithorg/appsmith/pull/15475


In-place update

This PR introduces an efficient FromTLV::update_from_tlv method with a default implementation that:

Turns FromTLV::init_from_tlv into an infallible initialiser
Does a check - using the also newly introduced FromTLV::check_tlv (which also has a default implementation) before attempting the update, so as to make sure, that the initializer can indeed be safely turned into an infallible one (i.e. it will not fail in the middle due to a malformed TLV stream)

Note that FromTLV::update_from_tlv assumes that FromTLV::check_tlv would be idempotent - i.e. calling it multiple times on the same TLVElement would yield identical results. However, that should be indeed the case anyway.
The benefit of having FromTLV::update_from_tlv is that it gives us cheap, transactional in-place updates, where either a value is in-place updated with the initializer completely, or the value is not updated at all. Basically, an "in-place" equivalent of:
fn update(&mut self, element: &TLVElement) -> Result<(), Error> {
    let new = Self::from_tlv(element)?;
    *self = new;

    Ok(())
}

The problem with the above update method, and the reason why we need FromTLV::update_from_tlv is - as usual - stack memory; i.e. it is transactional w.r.t. updating the value, but not cheap. The problem is, the new value is first materialized on-stack, and only after that it is moved to its final location (*self) - a behavior, which rustc might or might not optimize.
While we now have FromTLV::init_from_tlv which avoids the on-stack materialization of FromTLV::from_tlv, we don't have any "update" equivalent to FromTLV::init_from_tlv, which this PR introduces.
NOTE: This PR is deliberately in Draft and will stay in such, until I can discuss with @y86-dev (the author of the pinned-init crate and a RfL contributor) that the crate::utils::init::ApplyInit extension trait introduced with this PR is sound.

@y86-dev Sorry for pinging you here and sorry to ask - but - would you be willing to review the implementation of the crate::utils::init::ApplyInit extension trait, as I mentioned in this PR description?
You don't need to review anything else. The whole other machinery introduced with this PR lays on the assumption, that what ApplyInit::apply does is safe.
To translate a bit in English what ApplyInit::apply does: essentially it transforms any unwinding panic into an abort, because - in my opinion - in-place updates of an already initialized value are fundamentally incompatible with unwinding panics, as that would lead to the compiler attempting to drop an already dropped value.
Also - and if I understand your in-place initialization correctly - you don't have any such problem with the in-place initialization code in pinned-init, because - in the presence of unwinding panics - the worst that can happen is memory leaks, as the compiler will not drop your partially-initialized value. Which is OK.
It is another topic that you probably don't care that much about unwinding panics in pinned-init, as this code works in the kernel, where - I suppose? - rustc operates with panic_abort.
Same as we do for our main use case, which is running rs-matter on MCUs, where the only feasible strategy - due to firmware size - is panic_abort as well.
Yet, I would like to make sure, that rs-matter would behave (by promoting unwind to abort) in STD-land as well.

@y86-dev Sorry for pinging you here and sorry to ask - but - would you be willing to review the implementation of the crate::utils::init::ApplyInit extension trait, as I mentioned in this PR description?

No worries for pinging me. I will take a look, but I am rather busy at the moment. I might be able to get to it in the next week or so.

@y86-dev Sorry for pinging you here and sorry to ask - but - would you be willing to review the implementation of the crate::utils::init::ApplyInit extension trait, as I mentioned in this PR description?

No worries for pinging me. I will take a look, but I am rather busy at the moment. I might be able to get to it in the next week or so.

Thank you. Next week is fine. This PR is not gate-keeping any other development ATM.

(Just to mention that I'll later probably switch the "abort-on-unwinding-panic" code to use this clever trick, but that should be an insignificant change w.r.t. the logic of ApplyInit::apply.)

I left some comments about the implementation, overall it looks sensible.

Thank you.

In Rust for Linux, we have the need for InPlaceWrite<T> I haven't yet added it to the github repo, but at some point I might get to it. You can use that trait to initialize a smart pointer that contains MaybeUninit<T>.

This means I could retire my own InitMaybeUninit creation.
Note that we don't really use smart pointers at all, because the whole rs-matter codebase is no_std and no-alloc, so our (few) use cases where we have to initialize a user-passed MaybeUninit<T> are around in-place initialization of &mut MaybeUninit<T> rather than e.g. Box<MaybeUninit<T>>.
One danger with in-place initializing &mut MaybeUninit<T> is that the return type would be &mut T. In other words, even though the slot was initialized, the compiler does not remember that (as there is no SmartPointer<MaybeUninit<T>> to SmartPointer<T> transformation) and hence you need to manually drop your memory if the &mut reference is not 'static (which however it is usually, in .bss).

I took a quick look at the use case of Apply::apply and what I find a bit odd, is how the FromTLV::update_from_tlv function is implemented. The whole "check if it is valid and then convert the fallible initializer to an infallible one" seems very strange. Maybe the correct return type of init_from_tlv should actually be Result<impl Init<Self>>?

Regardless which signature is used, the "check if it is valid before trying to init" is unavoidable. What is also unavoidable, is that if the initialization (after the check is already done) fails mid-way (it should not if the check is idempotent but then you never know) we can only turn the error into a panic and then any unwinding panic into a hard abort.
The above we have to do regardless of the signature, so I don't think your Result<impl Init<Self>> suggestion would function any differently than the PR's impl Init<Self, E>?
I actually did start with Result<impl Init<Self>> but than had to convert to impl Init<Self, E> because somehow I had use cases where the latter was more ergonomic. I'll check this again.

sidenote: the FromTLV::init_from_tlv function is probably not working as expected:
fn init_from_tlv(element: TLVElement<'a>) -> impl init::Init<Self, Error> {
    unsafe {
        init::init_from_closure(move |slot| {
            core::ptr::write(slot, Self::from_tlv(&element)?);

            Ok(())
        })
    }
}

The in-place initializer will overflow the stack, if the size of Self is too big. That's because the call to Self::from_tlv puts a temporary value on the stack.

Agree completely!
The thing is, this implementation is only a default one. FromTLV implementors that are potentially large, like Vec, Maybe - my home-grown in-place-initable version of Option, OctetsOwned and all proc-macro generated FromTLV implementations do override it with a memory-efficient and correct variant (I hope).

Also, this function could take element by reference instead of by value, then there would be no need to clone it in update_from_tlv.

I would turn it the other way around: update_from_tlv should take the element by value rather than by reference. The thing is, the (anonymous) lifetime 't in &'t TLVElement<'a> in our code is often shorter than 'a and then the initializers cannot outlive it, but very often in our codebase they have to, because the initialization often gets delayed until after 't is no longer valid.
In any case, the point is moot because TLVElement<'a> is just a repr(transparent) for &[u8] so I could just as well implement Copy for it. :-)
Thanks again for taking the time to review - let me look at the inline comments as well now...

In Rust for Linux, we have the need for InPlaceWrite<T> I haven't yet added it to the github repo, but at some point I might get to it. You can use that trait to initialize a smart pointer that contains MaybeUninit<T>.

This means I could retire my own InitMaybeUninit creation. Note that we don't really use smart pointers at all, because the whole rs-matter codebase is no_std and no-alloc, so our (few) use cases where we have to initialize a user-passed MaybeUninit<T> are around in-place initialization of &mut MaybeUninit<T> rather than e.g. Box<MaybeUninit<T>>.
One danger with in-place initializing &mut MaybeUninit<T> is that the return type would be &mut T. In other words, even though the slot was initialized, the compiler does not remember that (as there is no SmartPointer<MaybeUninit<T>> to SmartPointer<T> transformation) and hence you need to manually drop your memory if the &mut reference is not 'static (which however it is usually, in .bss).

You could create a smart pointer type that has its backing memory in the .bss section. Dropping that smart pointer only drops the value, but doesn't actually free the memory (you can't access it though).

I took a quick look at the use case of Apply::apply and what I find a bit odd, is how the FromTLV::update_from_tlv function is implemented. The whole "check if it is valid and then convert the fallible initializer to an infallible one" seems very strange. Maybe the correct return type of init_from_tlv should actually be Result<impl Init<Self>>?

Regardless which signature is used, the "check if it is valid before trying to init" is unavoidable. What is also unavoidable, is that if the initialization (after the check is already done) fails mid-way (it should not if the check is idempotent but then you never know) we can only turn the error into a panic and then any unwinding panic into a hard abort.

I meant that you do the check twice, since first you check and return if it errors and then you do the check again, but panic if the result isn't Ok. It would be better if there is only one check and no result discarding.

The above we have to do regardless of the signature, so I don't think your Result<impl Init<Self>> suggestion would function any differently than the PR's impl Init<Self, E>?
I actually did start with Result<impl Init<Self>> but than had to convert to impl Init<Self, E> because somehow I had use cases where the latter was more ergonomic. I'll check this again.

That depends on when you know that the initializer will fail. If you can do the check without having the resulting memory on hand, then you can use Result<impl Init<Self>>. Otherwise you need that the initializer returns an error.

sidenote: the FromTLV::init_from_tlv function is probably not working as expected:
fn init_from_tlv(element: TLVElement<'a>) -> impl init::Init<Self, Error> {
    unsafe {
        init::init_from_closure(move |slot| {
            core::ptr::write(slot, Self::from_tlv(&element)?);

            Ok(())
        })
    }
}

The in-place initializer will overflow the stack, if the size of Self is too big. That's because the call to Self::from_tlv puts a temporary value on the stack.

Agree completely! The thing is, this implementation is only a default one. FromTLV implementors that are potentially large, like Vec, Maybe - my home-grown in-place-initable version of Option, OctetsOwned and all proc-macro generated FromTLV implementations do override it with a memory-efficient and correct variant (I hope).

Also, this function could take element by reference instead of by value, then there would be no need to clone it in update_from_tlv.

That's what I thought. It might be easier to only have one initialize/new function though (note that any T implements impl Init<T>, so you can just return the value directly).

I would turn it the other way around: update_from_tlv should take the element by value rather than by reference. The thing is, the (anonymous) lifetime 't in &'t TLVElement<'a> in our code is often shorter than 'a and then the initializers cannot outlive it, but very often in our codebase they have to, because the initialization often gets delayed until after 't is no longer valid.

Ah yeah, then you have to take it by value.

In any case, the point is moot because TLVElement<'a> is just a repr(transparent) for &'a [u8] so I could just as well implement Copy for it. :-)

Oh! Yeah probably makes sense to only use it by-value then and also implement copy :)

Thanks again for taking the time to review - let me look at the inline comments as well now...

Glad I could help :)

I took a quick look at the use case of Apply::apply and what I find a bit odd, is how the FromTLV::update_from_tlv function is implemented. The whole "check if it is valid and then convert the fallible initializer to an infallible one" seems very strange. Maybe the correct return type of init_from_tlv should actually be Result<impl Init<Self>>?

Regardless which signature is used, the "check if it is valid before trying to init" is unavoidable. What is also unavoidable, is that if the initialization (after the check is already done) fails mid-way (it should not if the check is idempotent but then you never know) we can only turn the error into a panic and then any unwinding panic into a hard abort.

I meant that you do the check twice, since first you check and return if it errors and then you do the check again, but panic if the result isn't Ok. It would be better if there is only one check and no result discarding.

I'll address only ^^^ as it is the most important comment of all.
I don't think a single check in T::update_from_tlv is possible at all.
Suppose I remove the call to Self::check_from_tlv(element)?; and suppose that a concrete TLV stream inside TLVElement happens to be erroneous (invalid).
What would then happen when I call Self::init_from_tlv(element.clone()).into_infallible().apply(self); is that it will panic, because the TLV stream contains errors.
But we don't want that!
We want the update to fail if the TLV stream contains errors. OK then, can I just NOT convert the initializer to "infallible" and return the error?
And I think the answer is no.
The reason why the answer is no is because if the stream is erroneous - in the absence of our initial "pre-check" of the stream, the parsing WILL fail mid-way while we are initializing the slot. No problem you would say - the initializer will drop in place whatever was already initialized. Sure, but when calling update_from_tlv, we are not initializing a MaybeUninit! We are (re-)initializing an already initialized memory. That's by the way the reason why we need the unsafe drop_in_place before the (re)initialization.
So where I'm going with that is that if we get a failure during the initialization, that should absolutely be an immediate abort, or else - even if your initializer is cleaning up the half-initialized memory behind itself - the rest of the code does not know that we have called drop_in_place and it will STILL try to free the slot in case we don't abort. And that would be a double-free because of our explicit drop_in_place.


Vespa Deploy Error

Describe the bug
Error: Invalid service: query services have not converged
To Reproduce
Steps to reproduce the behavior:

Used sample application '(https://github.com/vespa-engine/sample-apps/tree/master/text-search).'
vespa deploy --wait 300 - This is failing with above error
See error

Expected behavior
Expected app to deploy
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

OS: [macOS 12.4]
self-hosted

Vespa version
vespa version 7.528.38
Additional context
Add any other context about the problem here.

I just ran https://github.com/vespa-engine/sample-apps/tree/master/text-search, works for me. Please check the vespa.log file in the Docker container, and validate startup. https://vespa.ai/resources got startup troubleshooting - often it too little memory for Docker the problem, check output from docker info | grep "Total Memory"


chore: remove ported tactic from Mathport syntax

move_add, move_mul and move_oper are all available in Mathlib.

awaiting-author

It is called move_oper now, yes, but where should I report that?

Good question! I don't know if there's a way to report that - if there isn't, I won't object to removing this as-is.

Should perhaps mathport be tweaked, to emit move_oper instead of move_op?

I have not looked at mathport, but the only references to move_op that I could find in mathlib are the ones that I removed.  The tactic was almost never used anyway, and probably really never in its move_op/move_oper form, so I do not think that it is a big deal if mathport converts it incorrectly.
I am going to re-label as awaiting-review, and maybe someone else can give an opinion as well!

bors merge


code block in figure should not be centered

Description
#figure(caption: "but... why ?",
  raw("print('hi mom')
print('hello world')")
)

render as

when it should render as

Reproduction URL
No response
Operating system
Web app
Typst version

[X] I am using the latest version of Typst

Fixed with #1034 (a new release will come out shortly with this fix!).

looks its gonna be soon https://github.com/typst/typst/commit/f692a5efc62bf95f57d123895b7dce55d2eb9741

A regression has reintroduced this issue on the web app (v0.4.0).


A problem with the flutter Web font appears as follows:

A problem with the flutter Web font appears as follows:

It will be normal after a while

我的程序：
`import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
import 'package:get/get.dart';
class BottomSheetDemo extends StatelessWidget {
const BottomSheetDemo({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(title: Text("BottomSheet Demo"),),
body: Center(
child: ElevatedButton(onPressed: (){
Get.bottomSheet(Container(child: Wrap(children: [
ListTile(
leading: Icon(Icons.wb_sunny_outlined),
title: Text("白天模式"),
onTap: (){
Get.changeTheme(ThemeData.light());
},
        ),
        ListTile(
          leading: Icon(Icons.wb_sunny),
          title: Text("夜间模式"),
          onTap: (){
            Get.changeTheme(ThemeData.dark());
          },
        )
      ],),));

    }, child:Text("BottomSheet123")),
  ),
);

}
}
`

Duplicate of https://github.com/flutter/flutter/issues/77023


Add pip check (maybe don't merge)

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Thanks for getting 0.32 out so speedily, looking forward to testing with it.
This is a low-priority addition of pip check (it passes, locally), and wouldn't need a new build just for this, but I'd love to see this get added if any other builds occur in the near term, just for the warm fuzzies.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

What does pip check do?

pip check uses setuptools (presumably) to verify that every install_requires pin, of every installed python package, is satisfied. I am not entirely sure it checks extras, and is not configurable, so there can certainly be some false positives. However, I haven't yet found a package that passes pip check that still creates errors like distribution not available, etc. when pkg_resources.iter_entry_points gets called (even if something isn't "really" broken). Given that pyls uses that extensively, we've had lots of folk run into issues, especially if they try to install with conda, then start doing some pip on top of it to "fix" it.
There's some support for doing it by default, and really, it should be a conda-build feature, but there's very few reasons not to proactively start using it on a repo-by-repo basis if it provides value... and given the adventures with ujson, etc. I'd say this repo is a good candidate!
Some of those reasons:

if installing pip, and its dependencies (e.g. setuptools), fulfills dependencies that otherwise wouldn't have been, you get a false-positive.

On this package, for instance, because pkg_resources gets used, there should be a declared dependency on setuptools

the upstream doesn't declare it, though, as they probably don't test any way other than installing their dependencies with pip.

if something is broken, it can be a very deep rabbit hole indeed

there are a (diminishing) number of older, stable packages that don't get rebuilt/tested often that actually have (potentially inaccurate) pins that didn't get added to the feedstocks

Thanks for the very detailed explanation @bollwyvl!
Could you change the required version of one of our deps (e.g Jedi to >=0.14.1,<0.16) to see if pip check effectively detects an error there?

Hey, at least it passed the linter!

Nice!! Please remove your last commit so I can merge this one @bollwyvl.
And thanks again for your help!

So should we add setuptools on the install requires upstream?

Well, like it said up top: this may not even need to be merged (or if so,
shouldn't bump the build).
Regarding the upstream setuptools dep: yes, it probably should!
Anyhow will so some plumbing later...
On Fri, May 15, 2020, 16:47 Gonzalo Peña-Castellanos <
<EMAIL_ADDRESS>wrote:

So should we add setuptools on the install requires upstream?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/python-language-server-feedstock/pull/54#issuecomment-629475990,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALCRFIOWBJP2HLC7UCCZ3RRWS5VANCNFSM4NAIR3ZQ
.


xml-resolver

i am trying to the build the project using mvn clean install
but every time it gives the following error
Failed to execute goal on project personservice-server: Could not resolve dependencies for project net.lr.tutorial.karaf.cxf.personservice:personservice-server:bundle:1.0-SNAPSHOT: Failure to find xml-resolver:xml-resolver:jar:1.2 in http://localhost:8081/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced.
how can i resolve this dependency issue?

Looks like you do not have access to maven central. Make sure your nexus is set up as a proxy to provide all the needed contents from maven central.

i removed all maven configurations that points to my local nexus and now its working, thank you very much for your kind quick response.

Glad it worked


Feature Request: Can Excalidraw Create Visualizations in Stepwise Format?

Desired Format

Structured Workflows:
Stepwise representation of processes.
Hierarchical Diagrams:
Visualization of layered concepts effectively.
Interactive Components:
Editable diagrams allowing customization and collaboration.

Reference Material
A detailed example of the desired format is available here: Reference File on Google Drive
Current Limitations
Excalidraw currently has:
Limited templates for structured and hierarchical diagrams.
Minimal support for complex workflows with interactive components.
By introducing these features, Excalidraw could expand its usability to cater to a broader range of users, making it a versatile tool for various workflows and collaborative tasks.
Thank you for considering this request! For further details or clarifications, feel free to reach out.

Hey @theaminuli, thank you for reaching out to us. We have flowcharts in the editor, which you can see demoed in this video.
Is this something you can apply to your use cases?
Or do you have something else in mind? Would appreciate it if you provide some examples if so 😊

Thank you for your response! @ryan-di
For example, I plan to use Excalidraw to take class notes in a stepwise format, similar to how we used to write in school notebooks. I find it comfortable to organize information visually and systematically, just like in a physical notebook. Later, I can export these notes as a PDF for easy access and sharing.
Looking forward to hearing your thoughts! 😊


must crashes with Xcode 9.3  iOS 11.3

user  my iphone7p  after start demo  app,  When  selection one   image   and  app   must   crashes. but  the The simulator  is  good.    please help me fix it.  thanks very much
Log：：
2018-05-15 09:25:05.151429+0800 TCMaskBlendExample[2150:979418] [MC] System group container for systemgroup.com.apple.configurationprofiles path is /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
2018-05-15 09:25:05.152394+0800 TCMaskBlendExample[2150:979418] [MC] Reading from public effective user settings.
2018-05-15 09:25:15.177658+0800 TCMaskBlendExample[2150:979481] [discovery] errors encountered while discovering extensions: Error Domain=PlugInKit Code=13 "query cancelled" UserInfo={NSLocalizedDescription=query cancelled}
2018-05-15 09:25:20.118659+0800 TCMaskBlendExample[2150:979912] WF: === Starting WebFilter logging for process TCMaskBlendExample
2018-05-15 09:25:20.118907+0800 TCMaskBlendExample[2150:979912] WF: _userSettingsForUser mobile: {
filterBlacklist =     (
);
filterWhitelist =     (
);
restrictWeb = 1;
useContentFilter = 0;
useContentFilterOverrides = 0;
whitelistEnabled = 0;
}
2018-05-15 09:25:20.119286+0800 TCMaskBlendExample[2150:979912] WF: _WebFilterIsActive returning: NO

fixed in the latest release


Ensembl API is unable to parse the variant

Hi there, I've been getting the following error for the past few weeks: 'Ensembl API is unable to parse the variant'. I get this error for any variant that I try, and I've tried entering variants in different formats and tried using different computers as well, but I get the same error. Meanwhile, other people using the same computers have no problems using SpliceAI. Any help would be much appreciated :))

Hi. Do you get the same error if you enter the variants in chrom-pos-ref-alt format (eg. chr8-140300616-T-G)?
This could be an IT security/firewall issue.
Are these different computers connected to different networks?
Which browsers and operating systems have you tried?
To troubleshoot, could you open Chrome and do

open the SpliceAI-lookup page
show Developer tools
click on the Network tab
enter one of the example variants (eg. NM_001089.3(ABCA3):c.875A>T (p.Glu292Val)  )
click submit and share the screenshot

It should look like


Revert "Align file suffixes in main dir"

Updating to v7.x created a regression, useKeysAsDefaultValues is Deprecated in v7.x and all our translations became empty strings.
Problem:
All our translations are empty
Options:
a. use defaultValue method instead or useKeysAsDefaultValues.
b. add a separate script to fill in the values of new keys to a sane default value.
For now, I will just revert the library update.
Reverts kubev2v/forklift-console-plugin#83
[1] https://github.com/i18next/i18next-parser/releases/tag/7.0.0

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@7f79949). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #84   +/-   ##
=======================================
  Coverage        ?   78.36%
=======================================
  Files           ?       18
  Lines           ?      319
  Branches        ?       69
=======================================
  Hits            ?      250
  Misses          ?       66
  Partials        ?        3

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Milk Quality Prediction #348

Pull Request for ML-Crate 💡
Issue Title :

Info about the related issue (Aim of the project):
Name:
GitHub ID:
Identify yourself:

Closes: #348
Describe the add-ons or changes you've made 📃
Created a model using SVM to predict the quality of Milk.
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

I have done all the necessary changes, please check.

Thank you @abhisheks008


remove zookeeper dependency in deploy mode of standalone

The zookeeper dependency seems redundancy and useless, sometimes will be faild in TIS launch ,
so it will be good to remove zookeeper dependency in deploy mode of standalone

已经在主干代码中去掉zk的依赖，如果是分布式部署的话，将来再考虑


Restart operation on child devices

tedge-agent can run on a child device as well as on the main device.
As this is a work in progress, only one operation is implemented: restarting the device.
See the specifications: here https://github.com/thin-edge/thin-edge.io/pull/2235
This first step includes the following:

tedge-agent can be launched on a child-device using --mqtt-topic-root and  --mqtt-device-topic-id to specify the topic used for the child. For instance, running tedge-agent --mqtt-device-topic-id device/child-001//  on the child-device child-001, starts the agent on this device and makes it accessible to c8y via the c8y mapper.
An alternative way to launch tedge-agent on a child device is to specify the child topic using tedge config. For instance, tedge config set mqtt.device_topic_id "device/child-001//" then simply running tedge-agent.
When tedge-agent is launched on a child device and when the main device is connected to c8y, then the child-device is registered on c8y. The restart capability is also registered. The child device can then be restarted from c8y.

Child device restart has been implemented by https://github.com/thin-edge/thin-edge.io/pull/2245.

QA has thoroughly checked the feature and here are the results:

[ ] Test for ticket exists in the test suite.
[x] QA has tested the bug and could not reproduce it anymore.

QA has thoroughly checked the feature and here are the results:

[ ]  Test for ticket exists in the test suite.
[x]  QA has tested the bug and could not reproduce it anymore.

System tests are included here:

https://github.com/thin-edge/thin-edge.io/blob/main/tests/RobotFramework/tests/cumulocity/restart/restart_device_child.robot


Hi

Hi friend please can you make this .dll for cs go? because i downloaded your unknowncheats files none of them work, only crash...
My discord is tfthanzhi# 0861

solved


Discrepancy Between LAPA and Scratch Results on Simpler and Paper Report

Hello! Thank you for your excellent work and for making the code open source. However, I am facing inconsistencies between the results I obtained when reproducing LAPA on the Simpler simulation environment and those reported in the paper. Considering that the released checkpoint might be based on Open-X rather than Bridgev2 as mentioned in the paper, I also reproduced the Scratch results for verification, that is, I fine-tuned directly on the LWM checkpoint using the Simpler data you released. Unfortunately, this also seems to have discrepancies compared to the paper's report. I would like to know the reason for this. Is it possibly due to the need for multiple random seed experiments (I have only experimented 24 times with the default random seed from the source code)? Alternatively, could you release a test code specifically for Simpler (also, I am eagerly looking forward to the release of the Latent Action Quantization code)?
For reference, here is my experimental log:
LAPA:
Task name: widowx_stack_cube
Success num: {'moved_correct_obj': 5, 'moved_wrong_obj': 2, 'is_src_obj_grasped': 8, 'consecutive_grasp': 5, 'src_on_target': 0}
Task name: widowx_carrot_on_plate
Success num: {'moved_correct_obj': 9, 'moved_wrong_obj': 1, 'is_src_obj_grasped': 2, 'consecutive_grasp': 1, 'src_on_target': 0}
Task name: widowx_spoon_on_towel
Success num: {'moved_correct_obj': 7, 'moved_wrong_obj': 3, 'is_src_obj_grasped': 1, 'consecutive_grasp': 1, 'src_on_target': 1}
Task name: widowx_put_eggplant_in_basket
Success num: {'moved_correct_obj': 22, 'moved_wrong_obj': 0, 'is_src_obj_grasped': 18, 'consecutive_grasp': 15, 'src_on_target': 11}
Scratch:
Task name: widowx_stack_cube
Success num: {'moved_correct_obj': 3, 'moved_wrong_obj': 0, 'is_src_obj_grasped': 3, 'consecutive_grasp': 1, 'src_on_target': 0}
Task name: widowx_carrot_on_plate
Success num: {'moved_correct_obj': 11, 'moved_wrong_obj': 0, 'is_src_obj_grasped': 2, 'consecutive_grasp': 1, 'src_on_target': 0}
Task name: widowx_spoon_on_towel
Success num: {'moved_correct_obj': 2, 'moved_wrong_obj': 4, 'is_src_obj_grasped': 3, 'consecutive_grasp': 2, 'src_on_target': 0}
Task name: widowx_put_eggplant_in_basket
Success num: {'moved_correct_obj': 19, 'moved_wrong_obj': 0, 'is_src_obj_grasped': 8, 'consecutive_grasp': 8, 'src_on_target': 1}

We will shortly release the test code specifically for Simpler. One change we applied from original Simpler codebase is early stopping during evaluation (terminating the trajectory evaluation when the success is True for the first time rather than going through all max steps). We changed this because during fine-tuning data collection through rollouts, we also used this implementation. Therefore, the trained policy showed some unintended behavior after it has completed the task (since it has not learned how to act after the initial success), leading to performance degradation.

@seonghyeonye Thanks for you response. I have modified the code according to your suggestion, but the result has not changed. Therefore, a test code that is released as soon as possible would be very helpful. Salute.

@seonghyeonye @joeljang  Thanks a lot for your updates! However, it seems that the inference script scripts/lapa_bridge.sh is missed, as it has been mentioned in the updated Simpler Section in README.

@seonghyeonye @joeljang Thanks a lot for your updates! However, it seems that the inference script scripts/lapa_bridge.sh is missed, as it has been mentioned in the updated Simpler Section in README.

Sorry, I have found it, SimplerEnv/scripts/lapa_bridge.sh


feat: audit post processors

As per previous engineering council action item: https://git.corp.adobe.com/ExpSuccess/spacecat-infrastructure-docs/wiki/Engineering-Council#1-proposal-to-deprecate-the-post-processor---ekrem
This PR introduces the post processing step to the audit sequence in the audit-worker. Post-processor functions added are run sequentially at the end of each audit run.
Documentation: https://github.com/adobe/spacecat-audit-worker/tree/audit-post-processors?tab=readme-ov-file#how-to-add-a-custom-post-processor

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

v1.17.0
GitHub release

Your semantic-release bot :package::rocket:


Exclude PageSpeed Insights API errors from retries.

When retries are enabled in the client, the Runner class by default retries requests when the API returns a 500 error code. Unfortunately, the PageSpeed Insights API returns 5XX's for errors that should really be 4XX (specifically in Lighthouse for the errors ERRORED_DOCUMENT_REQUEST, FAILED_DOCUMENT_REQUEST). So 500 errors from this API shouldn't be retried, they will only increase load and fail again.
These errors are non-retryable user defined errors: for example requesting data for a url that doesn't go anywhere. This PR changes the default client behavior to avoid retrying requests the the reason lighthouseError, preventing unnecessary retries.
Steps to reproduce

Visit the PageSpeed Insights API explorer page
Enter a domain that does non exist in the URL field, for example https://notareal-websiteno.com, and run the report.
Note the returned error response is a 500 error.

Additional Context
We recently added this change the the defaults used by Site Kit which relies on this library. Since we found this condition important enough to explicitly exclude, I thought it might be worth contributing upstream, although I'm not sure you want to add these types of API specific exceptions.

@adamsilverstein thank you for this change!
I am not sure the implications of the reason lighthouseError, and if errors with this reason should never be retried. Do you know of any documentation for what lighthouseError means? If it's not always a result of a bad request, e.g. 400, then we may need something more robust.

@adamsilverstein thank you for this change!
I am not sure the implications of the reason lighthouseError, and if errors with this reason should never be retried. Do you know of any documentation for what lighthouseError means? If it's not always a result of a bad request, e.g. 400, then we may need something more robust.

Looking more into it, Lighthouse is our tool for analyzing / auditing the webpages. When this downstream library throws an error, the wrapping API throws a 500 and sets the reason as "lighthouseError".
Unfortunately, looking at possible error responses, some of them do correspond to 500 errors that should be retried. For example:
Lighthouse returned error: INTERNAL: APP::1: Lost browser connection."

In these cases, it would be best if the libraries retried this request. So is it better to retry all requests so that the ones that need retrying get it, or to not retry any requests, to prevent unnecessary retries? A third option would be to allow for certain "error" values to be configured.
I think the error above is not as common as the bad request error, and so this is an appropriate change.

Looking more into it, Lighthouse is our tool for analyzing / auditing the webpages. When this downstream library throws an error, the wrapping API throws a 500 and sets the reason as "lighthouseError".
Unfortunately, looking at possible error responses, some of them do correspond to 500 errors that should be retried. For example:
Lighthouse returned error: INTERNAL: APP::1: Lost browser connection."

In these cases, it would be best if the libraries retried this request. So is it better to retry all requests so that the ones that need retrying get it, or to not retry any requests, to prevent unnecessary retries? A third option would be to allow for certain "error" values to be configured.
I think the error above is not as common as the bad request error, and so this is an appropriate change.

@bshaffer Thank you for reviewing and approving.

@bshaffer Thank you for reviewing and approving.


Propose a Centos Based docker image

Could you propose a centos based docker image ?
It could be helpful to test some types of scripts on CentOS directly thanks to a golang:1.17-centos docker image for example
What version of Go are you using (go version)?
every version
What operating system and processor architecture are you using (go env)?
I use Centos :-)

Docker images with Go are not released or maintained by this project, they're packaged by someone else (members of the docker or Go community I suppose). So I'm afraid this is not the right place to ask.
Closing here, feel free to comment if I've misunderstood your request.


Remove old pages

Stuff like https://deploy-preview-371--cds2019.netlify.app/devsummit/schedule/ is still there, which might confuse people who have bookmarks etc.

Fixed in https://github.com/GoogleChrome/devsummit/pull/383


Add CI to the Sway Reference

The reference has been written over a few months.
The versions of forc used to write the code examples has changed over that time.

Check all the code examples and unify them under the current version of the repository
Add CI to validate the examples using the version

We seem to build the examples here. https://github.com/FuelLabs/sway/blob/d37f706af75b41528073860c43bd1afb7041b69a/.github/workflows/ci.yml#L72


Performance against NMT models

Great work!
How does your work fair against SOTA NMT models like SeamlessM4t, NLLB, m2m?
Thank you!

Hi @King-Rafat!
You can check out the eval results or the write-up
The seamless is referring the SeamlessM4t model. SeamlessM4t, being a multimodal model, is not really specialized SOTA in text-to-text translation, while NLLB and m2m focused more on the number of languages they support
If the languages you are looking for are supported, you might want to check out models like google/madlad400-10b-mt, Unbabel/TowerInstruct-7B-v0.2, etc
T-Ragx is a RAG system-based system, so it generally provides some improvement over whatever underlying model you use, especially for jargon-heavy use cases. Checkout the write-up for more details!


c# csharp_linux_dbg_native.csharp.Grpc.Core.Tests.ShutdownHookPendingCallTest

https://grpc-testing.appspot.com/job/gRPC_master_linux/1685/testReport/junit/(root)/csharp_linux_dbg_native/csharp_Grpc_Core_Tests_ShutdownHookPendingCallTest/
15:03:08 W0306 22:58:03.637133 Grpc.Core.Channel Channel shutdown was called but there are still 1 active calls for that channel.
15:03:08 E0306 22:58:03.796631<PHONE_NUMBER>22496 src/core/lib/iomgr/tcp_server_posix.c:425: Failed accept4: Invalid argument
15:03:08 W0306 22:58:03.820454 Grpc.Core.Server Exception while handling RPC. System.InvalidOperationException: Operation is not valid due to the current state of the object.
15:03:08   at Grpc.Core.Utils.GrpcPreconditions.CheckState (System.Boolean condition) [0x00008] in <bfad2bebd13f43838eb6d1226ed765df>:0
15:03:08   at Grpc.Core.Internal.AsyncCallServer`2[TRequest,TResponse].SendStatusFromServerAsync (Grpc.Core.Status status, Grpc.Core.Metadata trailers, System.Tuple`2[T1,T2] optionalWrite) [0x0004a] in <bfad2bebd13f43838eb6d1226ed765df>:0
15:03:08   at Grpc.Core.Internal.DuplexStreamingServerCallHandler`2+<HandleCall>c__async0[TRequest,TResponse].MoveNext () [0x001ce] in <bfad2bebd13f43838eb6d1226ed765df>:0
15:03:08 --- End of stack trace from previous location where exception was thrown ---
15:03:08   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <8f2c484307284b51944a1a13a14c0266>:0
15:03:08   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <8f2c484307284b51944a1a13a14c0266>:0
15:03:08   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <8f2c484307284b51944a1a13a14c0266>:0
15:03:08   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <8f2c484307284b51944a1a13a14c0266>:0
15:03:08   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in <8f2c484307284b51944a1a13a14c0266>:0
15:03:08   at Grpc.Core.Server+<HandleCallAsync>c__async2.MoveNext () [0x000c2] in <bfad2bebd13f43838eb6d1226ed765df>:0
15:03:08
15:03:08 2017-03-06 23:03:07,490 TIMEOUT: csharp.Grpc.Core.Tests.ShutdownHookPendingCallTest [pid=6102]
15:03:08 2017-03-06 23:03:07,490 FAILED: csharp.Grpc.Core.Tests.ShutdownHookPendingCallTest

This seem in all likelihood related to #10002
@yang-g FYI

Seen again: https://grpc-testing.appspot.com/job/gRPC_master_linux/1707/testReport/junit/(root)/csharp_linux_opt_native/csharp_Grpc_Core_Tests_ShutdownHookPendingCallTest/

Not seen for the last 3 months. Closing

Seen again: https://sponge.corp.google.com/target?id=534e4ea6-558a-4e57-91dd-7824a5e29b6a&target=github/grpc/csharp_macos_dbg_native&searchFor=&show=FAILED&sortBy=STATUS


Config File "ValueError: need at least one array to concatenate"

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
I have read the FAQ documentation but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
Get "ValueError: need at least one array to concatenate" when I train the model using a dataset that I have created Coco format annotation files for. I have referenced and tried the following other errors:
#210 : is not very clear, but it seems that the id field should be an int, and segmentation needs to be a list inside of a list. I seem to be good here.
#4199 : I have explicitly defined classes in my coco.py and other file, and the final comments here indicate that I should define classes in the train.dataset dict, which does not seem to exist, and returns an error when I try to define a train.dict dictionary.
I have looked through more, which indicate that it may be in my config or dataset files, so here is my config file, and an example from my annotation file.
config:

annotation:

Thank you in advance for everybody's help!
Reproduction

What command or script did you run?

python tools/train.py configs/faster_rcnn/2faster_rcnn_r50_fpn_1x_coco.py

Did you make any modifications on the code or config? Did you understand what you have modified?

I am using the most basic config file modifications, like the path to the images and the path to the annotation files.

What dataset did you use?

I am using the DeepLesion medical image dataset, I have created the Coco database as follows:
-train
----images
----annotation
-----------annotation.json
--test
--valid
Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.
You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)
sys.platform: linux
Python: 3.7.10 (default, Jun  4 2021, 14:48:32) [GCC 7.5.0]
CUDA available: True
GPU 0,1: TITAN X (Pascal)
GPU 2,3: GeForce GTX TITAN X
CUDA_HOME: /usr
NVCC: Cuda compilation tools, release 10.1, V10.1.243
GCC: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
PyTorch: 1.8.0
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) oneAPI Math Kernel Library Version 2021.2-Product Build 20210312 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.7.0 (Git Hash 7aed236906b1f7a05c0917e5257a1af05e9ff683)
OpenMP 201511 (a.k.a. OpenMP 4.5)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 11.1
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_37,code=compute_37
CuDNN 8.0.5
Magma 2.5.2
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.1, CUDNN_VERSION=8.0.5, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.8.0, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

TorchVision: 0.9.0
OpenCV: 4.5.2
MMCV: 1.3.8
MMCV Compiler: GCC 7.3
MMCV CUDA Compiler: 11.1
MMDetection: 2.14.0+2028b0c
Error traceback
If applicable, paste the error trackback here.
Traceback (most recent call last):
  File "tools/train.py", line 188, in <module>
    main()
  File "tools/train.py", line 184, in main
    meta=meta)
  File "/home/tarun/mmdetection/mmdet/apis/train.py", line 170, in train_detector
    runner.run(data_loaders, cfg.workflow)
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 127, in run
    epoch_runner(data_loaders[i], **kwargs)
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 47, in train
    for i, data_batch in enumerate(self.data_loader):
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 355, in __iter__
    return self._get_iterator()
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 301, in _get_iterator
    return _MultiProcessingDataLoaderIter(self)
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 940, in __init__
    self._reset(loader, first_iter=True)
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 971, in _reset
    self._try_put_index()
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 1205, in _try_put_index
    index = self._next_index()
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 508, in _next_index
    return next(self._sampler_iter)  # may raise StopIteration
  File "/home/tarun/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/sampler.py", line 227, in __iter__
    for idx in self.sampler:
  File "/home/tarun/mmdetection/mmdet/datasets/samplers/group_sampler.py", line 36, in __iter__
    indices = np.concatenate(indices)
  File "<__array_function__ internals>", line 6, in concatenate
ValueError: need at least one array to concatenate

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

Please use the tools/misc/browse_dataset.py script to verify that the data is correct.

Have you solved it?

the filename should be like this: 004453_01_01/132.png. Change the last _ into /.


Shorter slack notifications

Could you make shorter notifications for slack?
If more things goes down, uptimekuma makes too much spam in channel.
Look at uptimerobot notifications:

I'm working on letting the notifications allow templates in #646. This would allow you to shorten/lengthen the message as you see fit, but it is a lot of work, and reliant on a lot of testing. It will, in the best case, but quite some time until they are implemented across the board.

@deefdragon @streamthing how do they currently look for you in Slack? I only get Uptime Kuma Alert: MONITOR_NAME which does not even communicate the up/down status, is that correct?

UptimeKuma vs UptimeRobot on Slack:


refactor suggestion: replace findNodeHandle calls

Is your feature request related to a problem? Please describe.
As presented in React Native EU this year, findNodeHandle will soon be deprecated. We should consider a way to refactor the code around that.

thanks for the heads up! I haven't seen that findNodeHandle was deprecated -- have you seen any posts about it?

It was presented here

@brunohkbx how can we refactor our code when it is deprecated ?


Add parameter to allow skipping of tagging

Naive approach to be able to skip tagging of images during docker:build using a property. When docker.skipTags is true, then built images won't be tagged.

Looks good to me. Could you add some documentation to manual.md and add to changelog.md ?
Just out of curiosity: What is your use case for skipping configured tags ?

This used to be a CI issue when creating docker images tagged with the git commit ID. The current solution is a special profile in the POM for that. Not a big deal, but with the skipTags property there wouldn't have been the need to change the POM.

Added some lines to the docs. I wasn't sure if I did it right for the change log, though.

Applied for 0.12.0


Function precedence issue with libexec_dir when included with apache2 cookbook version 5.2.2 or later.

Cookbook version
4.9.2
Chef-client version
14.10.9
Platform Details
CentOS 7.6 Running in VMWare
CentOS 7.6 Running in Virtualbox
Scenario:
Converge a cookbook that depends on both the docker cookbook and the apache2 cookbook version 5.2.2 or later.
There exists a function precedence issue with these methods:
https://github.com/chef-cookbooks/docker/blob/d96b54605b845fc5f34068265569b91a7eb2dee6/libraries/docker_service_base.rb#L95
https://github.com/sous-chefs/apache2/blob/2fcb45ec68d3769b824530f21dfb613390a8e1ce/libraries/helpers.rb#L84
Steps to Reproduce:
git clone https://github.com/estenrye/docker_apach2_cookbook_precedence_issue_example.git
kitchen converge
kitchen verify

Expected Result:
Cookbook should converge without issue.
Actual Result:
esten.rye@USMAP-U102:~/github/issue_example$ kitchen create
-----> Starting Kitchen (v1.23.2)
-----> Creating <default-centos-7>...
       Bringing machine 'default' up with 'virtualbox' provider...
       ==> default: This machine used to live in /home/esten.rye/github/docker_apach2_cookbook_precedence_issue_example/.kitchen/kitchen-vagrant/default-centos-7 but it's now at /home/esten.rye/github/issue_example/.kitchen/kitchen-vagrant/default-centos-7.
       ==> default: Depending on your current provider you may need to change the name of
       ==> default: the machine to run it as a different machine.
       ==> default: Checking if box 'bento/centos-7' is up to date...
       ==> default: Setting the name of the VM: kitchen-issue_example-default-centos-7
       ==> default: Clearing any previously set forwarded ports...
       ==> default: Fixed port collision for 22 => 2222. Now on port 2205.
       ==> default: Vagrant has detected a configuration issue which exposes a
       ==> default: vulnerability with the installed version of VirtualBox. The
       ==> default: current guest is configured to use an E1000 NIC type for a
       ==> default: network adapter which is vulnerable in this version of VirtualBox.
       ==> default: Ensure the guest is trusted to use this configuration or update
       ==> default: the NIC type using one of the methods below:
       ==> default:
       ==> default:   https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
       ==> default:   https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
       ==> default: Clearing any previously set network interfaces...
       ==> default: Preparing network interfaces based on configuration...
           default: Adapter 1: nat
       ==> default: Forwarding ports...
           default: 22 (guest) => 2205 (host) (adapter 1)
       ==> default: Booting VM...
       ==> default: Waiting for machine to boot. This may take a few minutes...
           default: SSH address: <IP_ADDRESS>:2205
           default: SSH username: vagrant
           default: SSH auth method: private key
           default:
           default: Vagrant insecure key detected. Vagrant will automatically replace
           default: this with a newly generated keypair for better security.
           default:
           default: Inserting generated public key within guest...
           default: Removing insecure key from the guest if it's present...
           default: Key inserted! Disconnecting and reconnecting using new SSH key...
       ==> default: Machine booted and ready!
       ==> default: Checking for guest additions in VM...
       ==> default: Setting hostname...
       ==> default: Mounting shared folders...
           default: /tmp/omnibus/cache => /home/esten.rye/.kitchen/cache
       ==> default: Machine not provisioned because `--no-provision` is specified.
       [SSH] Established
       Vagrant instance <default-centos-7> created.
       Finished creating <default-centos-7> (0m48.77s).
-----> Kitchen is finished. (0m52.04s)
esten.rye@USMAP-U102:~/github/issue_example$ kitchen converge
-----> Starting Kitchen (v1.23.2)
-----> Converging <default-centos-7>...
       Preparing files for transfer
       Preparing dna.json
       Resolving cookbook dependencies with Berkshelf 7.0.6...
       Removing non-cookbook files before transfer
       Preparing validation.pem
       Preparing client.rb
       el 7 x86_64
       Getting information for chef stable 14 for el...
       downloading https://omnitruck.chef.io/stable/chef/metadata?v=14&p=el&pv=7&m=x86_64
         to file /tmp/install.sh.2896/metadata.txt
       trying wget...
       sha1     7fa8289867cd8e91d1e325099a71c3e04e8d7f99
       sha256   6149bbd478318f5bea029274860ffeb9686d04d6534b77cc1ff48043b6a3a2a7
       url      https://packages.chef.io/files/stable/chef/14.10.9/el/7/chef-14.10.9-1.el7.x86_64.rpm
       version  14.10.9
       downloaded metadata file looks valid...
       /tmp/omnibus/cache/chef-14.10.9-1.el7.x86_64.rpm exists
       Comparing checksum with sha256sum...
       Installing chef 14
       installing with rpm...
       warning: /tmp/omnibus/cache/chef-14.10.9-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
       Preparing...                          ################################# [100%]
       Updating / installing...
          1:chef-14.10.9-1.el7               ################################# [100%]
       Thank you for installing Chef!
       Transferring files to <default-centos-7>
       Starting Chef Client, version 14.10.9
       Creating a new client identity for default-centos-7 using the validator key.
       resolving cookbooks for run list: ["docker_apache2_precedence_issue::default"]
       Synchronizing Cookbooks:
         - docker_apache2_precedence_issue (1.0.0)
         - docker (4.9.2)
         - virtualbox-install (2.0.0)
         - dmg (4.1.1)
         - apt (7.1.1)
         - windows (5.2.3)
         - apache2 (6.0.0)
       Installing Cookbook Gems:
       Compiling Cookbooks...
       Converging 6 resources
       Recipe: docker_apache2_precedence_issue::default
         * yum_package[yum-utils, device-mapper-persistent-data, lvm2] action install (up to date)
         * docker_installation_package[default] action create
           * yum_repository[Docker] action create
             * template[/etc/yum.repos.d/Docker.repo] action create
        - create new file /etc/yum.repos.d/Docker.repo
        - update content in file /etc/yum.repos.d/Docker.repo from none to 6d9a6c
        --- /etc/yum.repos.d/Docker.repo        2019-02-26 21:05:09.942732102 +0000
        +++ /etc/yum.repos.d/.chef-Docker20190226-3017-naoh23.repo      2019-02-26 21:05:09.942732102 +0000
        @@ -1 +1,11 @@
        +# This file was generated by Chef
        +# Do NOT modify this file by hand.
        +
        +[Docker]
        +name=Docker Stable repository
        +baseurl=https://download.docker.com/linux/centos/7/x86_64/stable
        +enabled=1
        +fastestmirror_enabled=0
        +gpgcheck=1
        +gpgkey=https://download.docker.com/linux/centos/gpg
        - change mode from '' to '0644'
        - restore selinux security context
             * execute[yum clean metadata Docker] action run
        - execute yum clean metadata --disablerepo=* --enablerepo=Docker
             * execute[yum-makecache-Docker] action run
        - execute yum -q -y makecache --disablerepo=* --enablerepo=Docker
             * ruby_block[package-cache-reload-Docker] action create
        - execute the ruby block package-cache-reload-Docker
             * execute[yum clean metadata Docker] action nothing (skipped due to action :nothing)
             * execute[yum-makecache-Docker] action nothing (skipped due to action :nothing)
             * ruby_block[package-cache-reload-Docker] action nothing (skipped due to action :nothing)

           * yum_package[docker-ce] action install
             - install version 18.06.0.ce-3.el7 of package docker-ce

         * docker_service_manager_systemd[default] action start
           * directory[/usr/libexec/docker] action create
             - create new directory /usr/libexec/docker
             - change mode from '' to '0755'
             - change owner from '' to 'root'
             - change group from '' to 'root'
             - restore selinux security context
           * template[/usr/libexec/docker/docker-wait-ready] action create
             - create new file /usr/libexec/docker/docker-wait-ready
             - update content in file /usr/libexec/docker/docker-wait-ready from none to 64d78d
             --- /usr/libexec/docker/docker-wait-ready  2019-02-26 21:06:48.063153733 +0000
             +++ /usr/libexec/docker/.chef-docker-wait-ready20190226-3017-1jexzje       2019-02-26 21:06:48.052153381 +0000
             @@ -1 +1,11 @@
             +#!/usr/bin/env bash
             +i=0
             +while [ $i -lt 40 ]; do
             +  /usr/bin/docker  ps | head -n 1 | grep ^CONTAINER > /dev/null 2>&1
             +  [ $? -eq 0 ] && break
             +  ((i++))
             +  sleep 0.5
             +done
             +[ $i -eq 40 ] && exit 1
             +exit 0
             - change mode from '' to '0755'
             - change owner from '' to 'root'
             - change group from '' to 'root'
             - restore selinux security context
           * template[/lib/systemd/system/docker.socket] action create
             - create new file /lib/systemd/system/docker.socket
             - update content in file /lib/systemd/system/docker.socket from none to 7d06f6
             --- /lib/systemd/system/docker.socket      2019-02-26 21:06:48.122155625 +0000
             +++ /lib/systemd/system/.chef-docker20190226-3017-1my1crx.socket   2019-02-26 21:06:48.122155625 +0000
             @@ -1 +1,13 @@
             +[Unit]
             +Description=Docker Socket for the API
             +PartOf=docker.service
             +
             +[Socket]
             +ListenStream=/var/run/docker.sock
             +SocketMode=0660
             +SocketUser=root
             +SocketGroup=docker
             +
             +[Install]
             +WantedBy=sockets.target
             - change mode from '' to '0644'
             - change owner from '' to 'root'
             - change group from '' to 'root'
             - restore selinux security context
           * template[/lib/systemd/system/docker.service] action create
             - update content in file /lib/systemd/system/docker.service from f67888 to 1eff05
             --- /lib/systemd/system/docker.service     2018-07-18 19:01:19.000000000 +0000
             +++ /lib/systemd/system/.chef-docker20190226-3017-163uang.service  2019-02-26 21:06:48.178157421 +0000
             @@ -1,7 +1,8 @@
       [Unit]
       Description=Docker Application Container Engine
       Documentation=https://docs.docker.com
             -After=network-online.target firewalld.service
             +After=network-online.target docker.socket firewalld.service
             +Requires=docker.socket
       Wants=network-online.target

       [Service]
             @@ -9,16 +10,16 @@
       # the default is not to use systemd for cgroups because the delegate issues still
       # exists and systemd currently does not support the cgroup feature set required
       # for containers run by docker
             -ExecStart=/usr/bin/dockerd
             +ExecStart=/usr/bin/dockerd -H fd://
       ExecReload=/bin/kill -s HUP $MAINPID
             +LimitNOFILE=1048576
       # Having non-zero Limit*s causes performance problems due to accounting overhead
       # in the kernel. We recommend using cgroups to do container-local accounting.
             -LimitNOFILE=infinity
       LimitNPROC=infinity
       LimitCORE=infinity
       # Uncomment TasksMax if your systemd version supports it.
       # Only systemd 226 and above support this version.
             -#TasksMax=infinity
             +TasksMax=infinity
       TimeoutStartSec=0
       # set delegate yes so that systemd does not reset the cgroups of docker containers
       Delegate=yes
             - restore selinux security context
           * template[/etc/systemd/system/docker.socket] action create
             - create new file /etc/systemd/system/docker.socket
             - update content in file /etc/systemd/system/docker.socket from none to a64128
             --- /etc/systemd/system/docker.socket      2019-02-26 21:06:48.222158832 +0000
             +++ /etc/systemd/system/.chef-docker20190226-3017-17zp5y3.socket   2019-02-26 21:06:48.222158832 +0000
             @@ -1 +1,12 @@
             +[Unit]
             +Description=Docker Socket for the API
             +PartOf=docker.service
             +
             +[Socket]
             +ListenStream=/var/run/docker.sock
             +SocketGroup=docker
             +
             +
             +[Install]
             +WantedBy=sockets.target
             - change mode from '' to '0644'
             - change owner from '' to 'root'
             - change group from '' to 'root'
             - restore selinux security context
           * template[/etc/systemd/system/docker.service] action create
             - create new file /etc/systemd/system/docker.service
             - update content in file /etc/systemd/system/docker.service from none to 3ed9f0
             --- /etc/systemd/system/docker.service     2019-02-26 21:06:48.278160628 +0000
             +++ /etc/systemd/system/.chef-docker20190226-3017-h9tjtp.service   2019-02-26 21:06:48.278160628 +0000
             @@ -1 +1,29 @@
             +[Unit]
             +Description=Docker Application Container Engine
             +Documentation=https://docs.docker.com
             +After=network-online.target docker.socket firewalld.service
             +Requires=docker.socket
             +Wants=network-online.target
             +
             +[Service]
             +Type=notify
             +ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
             +ExecStartPre=/sbin/sysctl -w net.ipv6.conf.all.forwarding=1
             +ExecStart=/usr/bin/dockerd  --group=docker --log-driver=json-file --pidfile=/var/run/docker.pid
             +ExecStartPost=/usr/lib64/httpd/modules/docker-wait-ready
             +ExecReload=/bin/kill -s HUP $MAINPID
             +LimitNOFILE=1048576
             +LimitNPROC=infinity
             +LimitCORE=infinity
             +TasksMax=infinity
             +TimeoutStartSec=0
             +Delegate=yes
             +KillMode=process
             +Restart=always
             +StartLimitBurst=3
             +StartLimitInterval=60s
             +
             +
             +[Install]
             +WantedBy=multi-user.target
             - change mode from '' to '0644'
             - change owner from '' to 'root'
             - change group from '' to 'root'
             - restore selinux security context
           * execute[systemctl daemon-reload] action run
             - execute /bin/systemctl daemon-reload
           * execute[systemctl try-restart docker] action run
             - execute /bin/systemctl try-restart docker
           * execute[systemctl daemon-reload] action nothing (skipped due to action :nothing)
           * execute[systemctl try-restart docker] action nothing (skipped due to action :nothing)
           * service[docker] action enable
             - enable service service[docker]
           * service[docker] action start

             ================================================================================
             Error executing action `start` on resource 'service[docker]'
             ================================================================================

             Mixlib::ShellOut::ShellCommandFailed
             ------------------------------------
             Expected process to exit with [0], but received '1'
             ---- Begin output of /bin/systemctl --system start docker ----
             STDOUT:
             STDERR: Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
             ---- End output of /bin/systemctl --system start docker ----
             Ran /bin/systemctl --system start docker returned 1

             Resource Declaration:
             ---------------------
             # In /tmp/kitchen/cache/cookbooks/docker/libraries/docker_service_manager_systemd.rb

       92:       service docker_name do
       93:         provider Chef::Provider::Service::Systemd
       94:         supports status: true
       95:         action [:enable, :start]
       96:         only_if { ::File.exist?("/lib/systemd/system/#{docker_name}.service") }
       97:         retries 1
       98:       end
       99:     end

             Compiled Resource:
             ------------------
             # Declared in /tmp/kitchen/cache/cookbooks/docker/libraries/docker_service_manager_systemd.rb:92:in `block in <class:DockerServiceManagerSystemd>'

             service("docker") do
        provider Chef::Provider::Service::Systemd
        action [:enable, :start]
        updated true
        default_guard_interpreter :default
        service_name "docker"
        enabled true
        running false
        masked false
        pattern "docker"
        declared_type :service
        cookbook_name "docker_apache2_precedence_issue"
        supports {:status=>true}
        retries 1
        only_if { #code block }
             end

             System Info:
             ------------
             chef_version=14.10.9
             platform=centos
             platform_version=7.5.1804
             ruby=ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
             program_name=/opt/chef/bin/chef-client
             executable=/opt/chef/bin/chef-client

           ================================================================================
           Error executing action `start` on resource 'docker_service_manager_systemd[default]'
           ================================================================================

           Mixlib::ShellOut::ShellCommandFailed
           ------------------------------------
           service[docker] (/tmp/kitchen/cache/cookbooks/docker/libraries/docker_service_manager_systemd.rb line 92) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
           ---- Begin output of /bin/systemctl --system start docker ----
           STDOUT:
           STDERR: Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
           ---- End output of /bin/systemctl --system start docker ----
           Ran /bin/systemctl --system start docker returned 1

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/docker_apache2_precedence_issue/recipes/default.rb

             9: docker_service_manager 'default' do
            10:   log_driver 'json-file'
            11:   action :start
            12: end
            13:

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/docker_apache2_precedence_issue/recipes/default.rb:9:in `from_file'

           docker_service_manager_systemd("default") do
             action [:start]
             updated true
             updated_by_last_action true
             default_guard_interpreter :default
             declared_type :docker_service_manager
             cookbook_name "docker_apache2_precedence_issue"
             recipe_name "default"
             log_driver "json-file"
             pidfile "/var/run/docker.pid"
           end

           System Info:
           ------------
           chef_version=14.10.9
           platform=centos
           platform_version=7.5.1804
           ruby=ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
           program_name=/opt/chef/bin/chef-client
           executable=/opt/chef/bin/chef-client

       Running handlers:
       [2019-02-26T21:06:54+00:00] ERROR: Running exception handlers
       Running handlers complete
       [2019-02-26T21:06:54+00:00] ERROR: Exception handlers complete
       Chef Client failed. 16 resources updated in 01 minutes 59 seconds
       [2019-02-26T21:06:54+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2019-02-26T21:06:54+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
       [2019-02-26T21:06:54+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: docker_service_manager_systemd[default] (docker_apache2_precedence_issue::default line 9) had an error: Mixlib::ShellOut::ShellCommandFailed: service[docker] (/tmp/kitchen/cache/cookbooks/doc
ker/libraries/docker_service_manager_systemd.rb line 92) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
       ---- Begin output of /bin/systemctl --system start docker ----
       STDOUT:
       STDERR: Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
       ---- End output of /bin/systemctl --system start docker ----
       Ran /bin/systemctl --system start docker returned 1
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Converge failed on instance <default-centos-7>.  Please see .kitchen/logs/default-centos-7.log for more details
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

👋I just got bit by this issue today.

@estenrye @bkonick git repo is dependent on source URL: https://chef-supermarket.prlb.io and I don't have access for this URL.I tried with change source url to https://supermarket.chef.io/ but not able to replicate this.It is dependent on https://chef-supermarket.prlb.io. Could you please give more information to replicate this issue?

This was resolved by https://github.com/sous-chefs/apache2/pull/678

Thanks to confirm @bkonick, Closing now


Added possibility to use callable when setting 'default_stage'.

Q
A

Bug fix?
No

New feature?
Yes

BC breaks?
No

Deprecations?
No

Fixed tickets
#1278

@kszymukowicz done and release (with phar also).

@antonmedv
Many txn !
I owe you a couple of beers which will go to you by paypal today night :)


Update builders to allow building updated software deps

What does this PR do?
Update builders of pipeline to the versions that include changes from:

https://github.com/DataDog/datadog-agent-buildimages/pull/24
https://github.com/DataDog/datadog-agent-builders/pull/118 (private repo)

So that the dependency bumps of curl, autoconf and procps-ng from https://github.com/DataDog/omnibus-software/pull/346 can be built successfully.
I've double-checked that the pipeline is successful.

@DataDog/agent-platform: unilaterally merging this as it's needed for master pipelines to succeed. Feel free to add comments on the PR, and I'll address them in a separate PR.


Data race in episode4

Range over the connection map can execute concurrently with modifications to the map in addConnection and removeConnection.

thanks @garyburd - fixed in #28


Quick Start Guide

Quick Guide to getting started with IBM Bluemix Watson Android SDK
I am writing this to help anyone who is going through or went through what I did to get the example up and running.
To get the Android SPEECH TO TEXT and TEXT TO SPEECH working following these instructions, I am writing them as I am doing them as of 2-1-2016.
First create an IBM BlueMix account
https://console.ng.bluemix.net
Once created make the page full screen…
Go to the dashboard
https://console.ng.bluemix.net/
and click dashboard on the top right
Click Create a Space on top left
name it serviceTEST ( whatever you want… )
Once completed click Create App
Web App
SDK Node Js App
click Continue
name it serviceTESTApp1 ( whatever you want… ) If you get a weird error message that probably means someone is using that name just a number or 2 to the end…  serviceTESTApp12345 etc…
click Finish
Hit the back or left arrow on the top left of the page
You will see 1 CF App
Now we need to make our services, you CANNOT AS OF THIS WRITING make a service without an app…
Click on Services
click Use Services APIs
click on Speech to Text
on top right click on the App drop down and you will see your new app serviceTESTApp1
Select it and click Create
It will ask to ReStage, say YES
hit the back arrow on the top left
You will now see Services has 1
Click Services and click Speech to Text
click Service Credentials on the left
click add Credentials on the right
name it serviceTESTApp1-STT (whatever you want or just leave the default…)
Now you will see your credentials, you need these for the app
Open a notepad session on Windows or Notes session on Mac and copy all of this block of text you will need this for the android app
{
"credentials": {
"url": "https://stream.watsonplatform.net/speech-to-text/api",
"username": “yyyyyyyyyyyy”,
"password": “XXXXXXX”
}
}
Now lets make the Text to Speech Service same steps…
Hit the back or left arrow on the top left of the page
Click on Services
click Use Services APIs
click on Text to Speech
on top right click on the App drop down and you will see your new app serviceTESTApp1
Select it and click Create
It will ask to ReStage, say YES
hit the back arrow on the top left
You will now see Services has 2
Click Services and click Text to Speech
click Service Credentials on the left
click add Credentials on the right
name it serviceTESTApp1-TTS (whatever you want or just leave the default…)
Now you will see your credentials, you need these for the app
Open a notepad session on Windows or Notes session on Mac and copy all of this block of text you will need this for the android app
{
"credentials": {
"url": "https://stream.watsonplatform.net/text-to-speech/api",
"username": “yyyyyyyyyyyy”,
"password": “wwwwwwwww”
}
}
Now lets test your credentials before we move on
take the url above they are different
"url": "https://stream.watsonplatform.net/text-to-speech/api",
copy and paste the https…./api  in your browser and use the user name and password blue mix provided you above
You will know you got in it will say invalid credentials if it didn’t work and if it did work you will see a JSON output and documentation recommendations…
Now we are done with Bluemix
go here and download the android SDK ( which you probably already have… )
https://github.com/watson-developer-cloud/speech-android-sdk
click download zip on top right
unzip and in the folder you will see 2 folders, 2 project and a grade folder
Open Android Studio
Click open an existing project
Select the folder you just downloaded with all the 3 folders and files in it…
or
Click File > Open > and Select the folder you just downloaded with all the 3 folders and files in it…
Now lets set the credentials we just tested in place
Click on Project on the left side of the window if you don’t see any folders or code…
go to Examples > res > values > strings.xml
where you see default credentials… delete that block and replace with below….
<!-- STT default credentials -->

<string name="STTdefaultUsername">yyyyyyyy</string>

<string name="STTdefaultPassword">xxxxxxxx</string>

<string name="STTdefaultTokenFactory">https://stream.watsonplatform.net/speech-to-text/api</string>

<!-- TTS default credentials -->

<string name="TTSdefaultUsername">yyyyyyyy</string>

<string name="TTSdefaultPassword">xxxxxxx</string>

<string name="TTSdefaultTokenFactory">https://stream.watsonplatform.net/text-to-speech/api</string>

Now fill in the URL for Token Factory , Username , and password you received
We are done with this file
Now open Example project > Java > com….. > MainActivity
find this method  initSTT comment out don’t delete it… then copy and paste this version of the method
 private boolean initSTT() {
     // initialize the connection to the Watson STT service
     String username = getString(R.string.STTdefaultUsername);
     String password = getString(R.string.STTdefaultPassword);
     String tokenFactoryURL = getString(R.string.STTdefaultTokenFactory);
     String serviceURL = "wss://stream.watsonplatform.net/speech-to-text/api";
     SpeechConfiguration sConfig = new SpeechConfiguration(SpeechConfiguration.AUDIO_FORMAT_OGGOPUS);
     SpeechToText.sharedInstance().initWithContext(this.getHost(serviceURL), getActivity().getApplicationContext(), sConfig);
     // Basic Authentication
     SpeechToText.sharedInstance().setCredentials(username, password);
     SpeechToText.sharedInstance().setModel(getString(R.string.modelDefault));
     SpeechToText.sharedInstance().setDelegate(this);
     return true;
 }

find this method   initTTS comment out don’t delete it… then copy and paste this version of the method
 private boolean initTTS() {
     String username = getString(R.string.TTSdefaultUsername);
     String password = getString(R.string.TTSdefaultPassword);
     String tokenFactoryURL = getString(R.string.TTSdefaultTokenFactory);
     String serviceURL = "https://stream.watsonplatform.net/text-to-speech/api";
     TextToSpeech.sharedInstance().initWithContext(this.getHost(serviceURL));
     TextToSpeech.sharedInstance().setCredentials(username, password);
     TextToSpeech.sharedInstance().setVoice(getString(R.string.voiceDefault));
     return true;
 }

We are done with this file
Now run the app on a test device
If you see any please check internet connection messages, that simply means your credentials are not working.  Test them again on your browser and also make sure the URLs for Speech to Text and Text to Speech are correct they are different urls and the credentials will NOT work on both
Now from this point if anyone has any resources on how to make the REST speech to text services work with Android please reply or message me so we can collaborate.
thanks

ref
https://developer.ibm.com/answers/questions/240963/help-with-watson-speech-to-text-android-sdk.html#answer-251071

@KeyOnTech  Thanks~Help me a lot

@jzhang300 can you please update the readme with the instructions that @KeyOnTech wrote?

maybe it's time to learn some android :baby_chick:


Wrong normalization for "H2Kd"

In [1]: mhcnames.normalize_allele_name("H2Kd")
Out[1]: 'HLA-H*02:01'

Still broken.


Fixed this in a non-bound callback.

I don't really think the fix helps much though, because Readable doesn't seem to have a property encoding.

Thanks, I ended up merging a similar fix. The encoding property is not part of the public API of stream.Readable but it can be found in its private API.


Use CFPB brand colors in cf-expandables component

Adds CFPB brand colors as the default variable values for colors in cf-expandables.
Depends on #561 - this includes changes from that branch in the diff.
Testing
In this repo:

check out this branch
run npm run cf-link

In a second local clone of this repo in a different folder:

pull down and check out the gh-pages-rm-overrides branch: git fetch && git checkout gh-pages-rm-overrides
if you haven't already in this second clone, run all the install steps for the project
run npm run cf-link
run npm run build
run npm start
Compare colors on local site:

http://localhost:3000/components/cf-expandables/
to the live cf documentation to make sure they match: https://cfpb.github.io/capital-framework/components/cf-expandables/

Screenshots
before (WITHOUT cf-theme-overrides.less colors)

after (WITHOUT overrides stylesheet + with brand colors)
note that fonts aren't loading locally so it looks slightly different from the docs:

Notes

Todos

Checklist

[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the front end playbook
[ ] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

For some reason, when using Node 8, gulp doesn't compile cf-expandables' Less file. When using Node 6, running npm run build creates /tmp/cf-expandables/cf-expandables.css. With Node 8 that file is not created. I can't for the life of me figure out why. 😩  It results in the QUnit tests failing.

Try rebasing with canary and running npm run build && npm test and see if there are any failures, then force push the branch back up here.

Test still fails. I tried the following:

merged canary
deleted node_modules and package-lock.json
npm install
npm run build
npm test

wonder if #578 will fix this

This is what I've done in my modals branch:
git fetch && git checkout -b brand-colors-cf-expandables_webpack && rebase webpack_update

yup just about to try the same, will report back!

still fails!! try it out on this branch: brand-colors-cf-expandables_webpack
Travis job: https://travis-ci.org/cfpb/capital-framework/builds/270935556?utm_source=github_status&utm_medium=notification

finally passing 🥇 🤣