Spelling scripts

Why:
Closes: #30894

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[ ] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[ ] For content changes, I have completed the self-review checklist.

Fwiw, https://github.com/github/docs/actions/runs/7388828032/job/20100431728 is going to ❌ -- see https://github.com/github/docs/issues/30896

@jsoref Thanks so much for opening a PR! I'll get this triaged for review ✨

@github/docs-engineering 👋🏻 - this fixes spelling mistakes mostly in scripts. Would you like to fix these internally as we appear to not be accepting external contributions to these files? 🤔

That said, the fixes look great to me, thanks @jsoref 🙇🏻 ✨

Fwiw, there's a sarch in one of the search workflows -- https://github.com/github/docs/blob/4c0d5f11071f58853f682c2af0ee3e7cc0f11c54/.github/workflows/sync-search-pr.yml#L3
I called it out elsewhere and the public side seemed disinclined to deal with it.
(I might have other things that should be fixed in workflows as this PR was designed for just scripts which the PR system didn't explicitly say were forbidden and I'm trying to make these PRs reasonably small and scoped to limit how many reviews would be needed...)

Thank you :) I think its okay to admin merge for these, its just typos, so I don't think there's any security concerns.

Makes me a bit nervous that src/content-linter/tests/unit/liquid-data-tags.js passed before despite the typo there. :)

Thanks @jsoref for these! If you want to get a speedier review next time, consider breaking it up into multiple smaller PRs of ~10 files each.

That's on me! @jsoref and I discussed previously, and I didn't advise to break into smaller PRs. Thank you for the vast number of quality contributions, which I'm sure is no small amount of effort on your part 💛

@peterbe: yeah, the liquid-data-tags test definitely worried me. Fwiw, it's a great example of why I encourage people to run a spell-checker on everything (including tests) -- I regularly run into tests that aren't testing what people think they're testing.

(Oh, and props to the GitHub team. These PRs have been merged very quickly, even though they aren't tiny. I regularly encounter w/ projects that take over a year to merge smaller PRs.)


Node overview

Is your feature request related to a problem? Please describe.
Create node overview page to quickly get insights about node resources
Describe the solution you'd like
A new view that contains important information about node status

Node overview page should have information about CPU and memory requests as well as how many pods can be ran on each node


Default to using notified_ids=[]

From: https://hypothesis.zendesk.com/agent/tickets/6010
Not entirely sure I have this right, so feel free to give me feedback:
User is trying to add Slack to the tools they're using, and wasn't adding "notified_ids=[]". You decided it should default to that.
Finally, you wrote:
"The error is just a traceback that's unnecessarily printed if namemap.json doesn't exist. But you should really try it, it's very cool to be able to @mention somebody's Slack name in an annotation and have them be tagged in Slack."

You decided it should default to that.

Done.


Fix checkout action

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 76.31%. Comparing base (4521c80) to head (d49cdb9).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #162   +/-   ##
=======================================
  Coverage   76.31%   76.31%
=======================================
  Files          13       13
  Lines         553      553
=======================================
  Hits          422      422
  Misses        109      109
  Partials       22       22

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


drift file view "Expression has an unknown type, the generated code can be inaccurate."

I created a view using a drive file, and the build process always prompts
"Expression has an unknown type, the generated code can be inaccurate."
How to solve this problem?
thanks！
task table
CREATE TABLE tasks (
    id INT NOT NULL PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL
);

todo table
CREATE TABLE todo (
    id INT NOT NULL PRIMARY KEY AUTOINCREMENT,
    task_id TEXT NOT NULL,
    content TEXT NOT NULL
);

tabk view
CREATE VIEW task_view AS
SELECT
    t.id as id,
    td.content as todo_content
FROM tasks t
INNER JOIN todo td ON t.id = td.task_id;

database.g.dart TaskViewData
It is obvious that the id field type should be int to be correct
class TaskViewData extends DataClass {
  final String? id;
  final String? todoContent;
  const TaskViewData({this.id, this.todoContent});
  factory TaskViewData.fromJson(Map<String, dynamic> json,
      {ValueSerializer? serializer}) {
    serializer ??= driftRuntimeOptions.defaultSerializer;
    return TaskViewData(
      id: serializer.fromJson<String?>(json['id']),
      todoContent: serializer.fromJson<String?>(json['todo_content']),
    );
  }
  @override
  Map<String, dynamic> toJson({ValueSerializer? serializer}) {
    serializer ??= driftRuntimeOptions.defaultSerializer;
    return <String, dynamic>{
      'id': serializer.toJson<String?>(id),
      'todo_content': serializer.toJson<String?>(todoContent),
    };
  }

  TaskViewData copyWith(
          {Value<String?> id = const Value.absent(),
          Value<String?> todoContent = const Value.absent()}) =>
      TaskViewData(
        id: id.present ? id.value : this.id,
        todoContent: todoContent.present ? todoContent.value : this.todoContent,
      );
  @override
  String toString() {
    return (StringBuffer('TaskViewData(')
          ..write('id: $id, ')
          ..write('todoContent: $todoContent')
          ..write(')'))
        .toString();
  }

  @override
  int get hashCode => Object.hash(id, todoContent);
  @override
  bool operator ==(Object other) =>
      identical(this, other) ||
      (other is TaskViewData &&
          other.id == this.id &&
          other.todoContent == this.todoContent);
}

Are the tables and the views in different drift files? If so, you need an import 'path/to/table.drift'; import statement at the top of the drift file importing the view.

Are the tables and the views in different drift files? If so, you need an import 'path/to/table.drift'; import statement at the top of the drift file importing the view.

The problem was resolved after importing the drift file.
I didn't read the document clearly. I found it on Supported statements

thank you ! 🥳


[quarto1.3] Revert "Override bad bootstrap transition css (#99)"

This reverts commit ab3a1d7a5a9c7c69361ed69b0f1920bbc2df223f from openproblems-bio/website-experimental#99. Closes #142.

Replaced by #231


Hacktoberfest 2021: Program with emojis 😲

This is a project written in EmojiCode, a language that uses emojis for syntax. By contributing to this project, you can brag that you know how to program with emojis :100:
What we need most is more emojis. Many more emojis.
To add an emoji, you will need to add a name for the emoji, the emoji itself, and some keywords for the emoji.
For more information, please consult CONTRIBUTING.md.
Of course, other contributions are also welcome 😃
Happy Hacking! 🎃

Hello, can I work on this?


Updated code for TORNET use

I updated the code I had made to the new changes that were pushed to main. Again with tornet i have 3 options one that send 1 POST per IP change one that send 25 POST per ip change and one that sends a POST in a random timeframe(so the POST look human made...)

@CybrZone pls give me feedback on this idea of using tor endpoints for sending the POST, I think it can be a great implementation that we will give a choice between Tor and proxy!


Runtime error for two classes in one ts file.

TypeScript Version:
1.8.10
Code
export class BaseLayoutModel extends BaseModel {
    constructor(attributes?: any, options?: any) {
        super(attributes, options);
    }
}

export class BaseModel extends Backbone.Model {
    constructor(attributes?: any, options?: any) {
        super(attributes, options);
    }

    destroy(options?: Backbone.ModelDestroyOptions): any {
        const opts = _.extend({
            contentType: "application/json",
            dataType: "text"
        }, options || {});
        super.destroy(opts);
    }
}

Expected behavior:
Actual behavior:
Runtime error. BaseModel  is undefined

in your code BaseModel is declared lexically after BaseLayoutModel
in the compiled code it means that BaseModel is used before being initialized
try swapping the declarations (BaseModel class should come first)

I know about “why it failed”. But this code translated to JS without any errors.
From: Aleksey Bykov<EMAIL_ADDRESS>Sent: Thursday, May 12, 2016 3:43 PM
To: Microsoft/TypeScript<EMAIL_ADDRESS>Cc: Виталий Лещенко<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [Microsoft/TypeScript] Runtime error for two classes in one ts file. (#8572)
in your code BaseModel is declared lexically after BaseLayoutModel
in the compiled code it means that BaseModel is used before being initialized
try swapping the declarations (BaseModel class should come first)
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/TypeScript/issues/8572#issuecomment-218745193

Duplicate of #4341 and #5207 which should be fixed by #4343


Guard check does not follow Google Style

On Define Guard, the definition:

The format of the symbol name should be <PROJECT>_<PATH>_<FILE>_H_.

However, if I have the follow structure:
/foo/include/internal/qux.h
The guard in qux.h would be:
#ifndef FOO_INTERNAL_QUX_H_
#define  FOO_INTERNAL_QUX_H_
#endif //  FOO_INTERNAL_QUX_H_

Although, the cpplint returns the follow error:

$ > cpplint foo/include/internal/qux.h
foo/include/internal/qux.h:0:  #ifndef header guard has wrong style, please use: INTERNAL_QUX_H_  [build/header_guard] [5]
foo/include/internal/qux.h:2: #endif line should be "#endif  // INTERNAL_QUX_H_"  [build/header_guard] [5]
Done processing foo/include/internal/qux.h
Total errors found: 1

I have meet the same problem!


04 : ChatUpstage(model="solar-pro") & new results

Please ensure that you follow the environment variable settings precisely as specified in 01.

updated env setting!


"Headers" verifications is not translated properly from Postman to Bruno

Test_bruno_migration.postman_collection.json
I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
When importing postman collection, the collection level tests and scripts were partially translated.
When we want to verify the Headers section of the response then it should have "to.have.property" method but we have to.equal method
Expected: expect(res.getHeaders()).to.have.property("content-type");
Actual:   expect(res.getHeader()).to.equal("content-type");
Due to this issue tests are getting failed. Please find the attached screenshot

.bru file to reproduce the bug
No response
Screenshots/Live demo link

Added sample Bruno Collection . Please update request keyword to req as well

Hey @SravaniPady5 ,
Thanks for reporting this issue.
I'm was able to reproduce it on my end, and we're working on it.


Merge v1.0.1 into master

This PR merges the bug fix release v1.0.1 into master.

LGTM 🐸 assuming it's green :green_heart:
(and the branch is out of date)


Dark version of the documentation

I was wondering if it would be possible to have a dark version of the documentation. Us devs usually spend many hours reading documentation, so it would be great news for the health of our eyes.
Both Vue and React's material docs have this feature... So.. why not? :)

You can change the theme of the documentation. Two of the themes are dark themes. (It's located next to the Github button on the header)


Running the test suite

Shouldn't this read:
python setup.py test

manage.py is some Django-ish thing? :)

D'oh, you're 100% right! Just pushed a fix =)
Thanks!

:+1:


CombSorting failed to sort correctly

Brief Intro
combSort failed to sort correctly
@srutstein21
More Details
input :
[-74,48,-20,2,10,-84,-5,-9,11,-24,-91,2,-71,64,63,80,28,-30,-58,-11,-44,-87,-22,54,-74,-10,-55,-28,-46,29,10,50,-72,34,26,25,8,51,13,30,35,-8,50,65,-6,16,-2,21,-78,35,-13,14,23,-3,26,-90,86,25,-56,91,-13,92,-25,37,57,-20,-69,98,95,45,47,29,86,-28,73,-44,-46,65,-84,-96,-24,-12,72,-68,93,57,92,52,-45,-2,85,-63,56,55,12,-85,77,-39]
actual output:
[-96,-91,-90,-87,-85,-84,-84,-78,-74,-74,-72,-71,-69,-68,-63,-58,-56,-55,-46,-46,-45,-44,-44,-39,-30,-28,-28,-25,-24,-22,-24,-20,-20,-13,-13,-12,-11,-10,-9,-8,-6,-5,-3,-2,-2,2,2,8,10,10,11,13,12,14,16,21,23,25,25,26,26,28,29,29,30,35,34,35,37,45,47,48,50,51,50,52,54,55,56,57,63,57,64,65,65,72,73,77,80,85,86,86,91,92,92,93,95,98]
expected output:
[-96,-91,-90,-87,-85,-84,-84,-78,-74,-74,-72,-71,-69,-68,-63,-58,-56,-55,-46,-46,-45,-44,-44,-39,-30,-28,-28,-25,-24,-24,-22,-20,-20,-13,-13,-12,-11,-10,-9,-8,-6,-5,-3,-2,-2,2,2,8,10,10,11,12,13,14,16,21,23,25,25,26,26,28,29,29,30,34,35,35,37,45,47,48,50,50,51,52,54,55,56,57,57,63,64,65,65,72,73,77,80,85,86,86,91,92,92,93,95,98]

import Foundation
// Input array
let input = [-74, 48, -20, 2, 10, -84, -5, -9, 11, -24, -91, 2, -71, 64, 63, 80, 28, -30, -58, -11, -44, -87, -22, 54, -74, -10, -55, -28, -46, 29, 10, 50, -72, 34, 26, 25, 8, 51, 13, 30, 35, -8, 50, 65, -6, 16, -2, 21, -78, 35, -13, 14, 23, -3, 26, -90, 86, 25, -56, 91, -13, 92, -25, 37, 57, -20, -69, 98, 95, 45, 47, 29, 86, -28, 73, -44, -46, 65, -84, -96, -24, -12, 72, -68, 93, 57, 92, 52, -45, -2, 85, -63, 56, 55, 12, -85, 77, -39]
// Sorting the array
let sortedArray = input.sorted()
// Printing the sorted array
print("Sorted Array: (sortedArray)")


Script test analysis/evaluation

What has to be done
Some visual evaluation of test data could be replaced and/or complemented with scripted analysis. We have talked of things like:

undershoot
overshoot
not falling down to PEEP
bad/good slopes or curves for reaching PIP
evidence for lung compliance by inspection
oscillation
In addition to this, we have been able to say if a particular test was performed with satisfaction or not.
It seems that at least some of these evaluations could be abstracted away with python scripts that analyze collected debug data in post-processing. A report could be generated that identifies sore spots.

How do you know it has to be done
More people have been testing the controller with their pizzas and hand-made lungs. Not everyone is equally adept at understanding the implications of the test data. Since the home made test lungs perform differently, it is important to tally up the ways in which they are different so we know what efforts we can make to conform them to a standard. Also, we will want to automate this much more of these tests in the future, and evaluating the data automatically will become important.
Code pointers
The /utils directory has a script for running covent tests. Test data analysis could possibly live therein as well.

Would be good for Data Scientist to pick up.

As a minimum, we need the existing performance test scripts to generate a file with metadata, and help us avoid very long directory names that we now have in sample_data.

Can we benefit from asking VentMon about this?

This is a signal processing or data science task for a python-minded person.


Allow optimistic concurrency check on write to be optional

Appending events to a stream requires an expected version. This is used for optimistic concurrency checking to ensure writers have not missed an event appended by another process.
:ok = EventStore.append_to_stream(stream_uuid, expected_version, events)

This check should be made optional to allow writers to append events without having first read them from the stream.
Proposal
The expected_version argument should be extended to allow the following options:

:any_version - no concurrency checking; allow any stream version (including no stream, or empty stream).
:no_stream - ensure the stream does not exist.
:empty_stream - ensure the stream exists, but has no events.
an integer  value - optimistic concurrency check against expected version (current behaviour).

Example usage
:ok = EventStore.append_to_stream(stream_uuid, :any_version, events)

@slashdotdash are there any plans of delivering this feature?

@HarenBroog Yes, I've just done it! Published to Hex as v0.12.0.


Proposal: Adapt return value to different Promise implementations

It would be a good thing if async functions would return the same type of promise that was awaited on in their function bodies. This would align with how typescript is implementing it (according to this issue). The async/await keywords could then be used together with various promise implementations without loosing the bells and whistles that comes with various Promise libraries such as bluebird, Q, WinJS and Dexie.
External Promise implementations can have features that would be lost if converting them to the 'standard' Promise as suggested in the readme of this repository.
Therefore, I would propose a more adaptive implemetation of spawn() that can accept and forward any A+ compatible Promise that was awaited for:
function spawn(genF, self) {
    var gen = genF.call(self);
    function step(nextF,initial) {
        var next = nextF();
        if (next.done) {
            // finished with success, resolve the promise
            return initial ?

                // Nothing was awaited. Direct return value must be converted
                // to promise:
                Promise.resolve(next.value) :

                // Return the value as is and let the promise
                // implementation take care of the A+ compatible promise chain
                next.value;
        }
        // not finished, chain off the yielded promise and `step` again
        if (!next.value || typeof next.value.then !== 'function')
            // Don't accept yielding a non-promise such as "yield 3;".
            // By not accepting that, we could detect bugs better.
            gen.throw(new TypeError("Only acceptable to yield a Thenable"));

        return next.value.then(function (v) {
            step(function () { return gen.next(v); });
        }, function (e) {
            step(function () { return gen.throw(e); });
        });
    }

    try {
        step(function() { return gen.next(undefined); }, true);
    } catch (e) {
        // Failure before code has yielded any Promise.
        return Promise.reject(e);
    }
}

Specifically, for my library, Dexie.js, there is a feature that enables 'Promise-Specific Data' which is analogue to 'thread static data' for promises. The entire Dexie API depends on that feature because it enables things like reentrant mutexes, implicit transaction scope, sub transaction awareness and some more API sugar. I believe that bluebird, Q, WinJS and others also would benefit from having this openess in how async/await behave.
By not binding the async keyword to a specific implementation of Promise, we would allow new Promise implementations with features that we cannot think of today and still use them with async/await.

External Promise implementations can have features that would be lost if converting them to the 'standard' Promise as suggested in the readme of this repository.

Where in the README is this mentioned?

It's how I interpret the behaviour when applying the rules from Rewrite and Spawning.

Those sections are only informative and not totally representative of an implementation. Even if it was, it's not explicitly said that it has to be a native ES6 promise?

Ok :+1:
Do you know if it has been discussed require this kind of adaptivity for async?

@dfahlander compositional functions?

Ok, that's an even broader approach. Is it still an open issue on how to accomplish this? Can it be done without having to configure the behavior of async/await? Or would it be acceptable to have a least common denominator, such as an interface that all asyncronic primitives would have to implement to work with async/await?

Ok, sorry. I saw that compositional functions use different keywords for async. That's fine. What I am interested in is a fine tuning of the async/await spawning method.

This is an interesting idea but I'm not sure how well it would work in practice. I think this is morally equivalent to passing through promises returned from then handlers, and has the same issue. Namely, if you think about the following code:
async function get(url) {
    if(cache[url]) return cache[url];  // no promise returned, so wrapped in built-in promise
    let data = await $.get(url);
    if(!url.endsWith('.json')) return data; // jQuery promise returned
    return await handleJSON(data); // whatever kind of promise handleJSON returns
}

Depending on how you call get, you get a different promise. Today libraries use many different promise libraries so this problem will be quite pervasive. Worse, it seems like it will be very difficult to debug/work around when you need to. Thoughts?

Yeah it seems better if you want a specific kind of promise to do something like
function bb(fn) {
  return (...args) => BluebirdPromise.resolve(fn(...args));
}

const get = bb(async url => {
  if (cache) ...
});

@bterlson Yes, I've been thinking about that and it's a problem unless you understand the rules of how async. If the author of the async function want to ensure a single Promise type to return, (s)he could start with an await expression that returns the desired promise type to unify the rest of the function.
async function get(url) {
    await CustomPromise.resolve(); // This line will unify all promises below to CustomPromise
    if(cache[url]) return cache[url];
    let data = await $.get(url);
    if(!url.endsWith('.json')) return data;
    return await handleJSON(data);
}

@domenic Your suggestion might work for some use cases. But at least in my use case, the internal steps between the await calls must be done using Dexie.Promise. Otherwise I would loose the indexedDB transaction between the await calls due to an incompatibility between indexedDB and most ES6 Promise implementations. I would also loose the Promise-specific data feature between the calls.

I don't think you should be using async/await if you need implementation-specific features. It's not a general method for triggering .then calls; it's a way of doing standard promises (which can be hopefully optimized even better given the guarantees standard promises make).

It is a better design to be dependent on an interface rather than on an implementation. Especially for a built-in keyword.

It's not unlikely that more innovative Promise features will be developed in libraries. Like Dexie has its PSD, other libs has cancellation tokens and God knows what will show up out there...
What about this: Instead of expecting a Thenable (as I suggested), require an Awaitable interface more simplistic and maybe more optimizable than Thenable. It's use case is only to be ran by the await engine.
interface Awaitable {
    await(onSuccess : Function, onReject: Function) : Awaitable;
}

Awaitable.await would be simpler than Promise.then: It only needs to supports a single listener onto each instance.
Awaitable.await would be compatible with Promise.then. To support it in standard Promise, do Promise.prototype.await = Promise.prototype.then.
I think that since async/await is such a great improvement of the language, all libraries would directly support the Awaitable interface including Task and Observable.
It wouldn't be an issue if all libraries out there, including non-promise asyncronic primitives. would have to add 'await' function to their prototype in order to work with async/await. This would not only solve the issue I have in Dexie.Promise but also Compositional functions without introducing new keywords like 'task' and 'observable'.

This proposal is not a general method for triggering .await calls; it's a way of doing standard promises (which can be hopefully optimized even better given the guarantees standard promises make).

I still believe it is better to be dependent on an interface rather than on an implementation. Especially for a built-in keyword.

I don't think we will pursue this for now. Support for promise subclasses is a good argument for composition functions. For async functions it makes more sense to use the same behavior as promises WRT subsuming other promise types. If you want a "FooPromise" out of an async function you could also convert with var p = FooPromise.resolve(asyncFunction()). It would also probably be easy with decorated async functions.

@bterlson - the issue with FooPromise.resolve(asyncFunction()) is that features will get lost between the awaits in the async function.

WinJS cancel() won't be propagated.
Dexie.currentTransaction will not be maintained correctly.

As a result, these promise implementations will not be able to use async/await.

It's a good point that when using async functions to await non-native promise-returning functions will result in the non-native promises being subsumed by native promises. You suggest a special case for libraries that have the same signature for .then, which might help (at some cost) but doesn't address libraries that have special conventions for, for example, propagating the cancellation signal, on progress handlers, etc.
In general I believe that developers should know exactly the kind of promise they're going to get from an async function (whether its because async functions always return native promises or because the async function is tagged in some way to indicate its return type ala composition functions). I don't think it's acceptable to let callees of an async function decide what type of promise the function returns. This seems like asking for subtle bugs and breakage when libraries change.

@dfahlander ... i agree with you... we use $q with some monkey patching that allows us to capture "unhandled rejections", that is, promises that are rejected but don't have a rejected handler which we consider to be unhandled exception... anyway... i for this and other reasons would like to use our promises from async functions... i am having a hard time understanding the reasoning behind having to use the global Promise... anyway... thanks for your attempt..


Few enhancements & fixes

Fixes #19
Strips unneeded items from categories
Fetch reviews for a given app

The fetching reviews feature is nice! Could you split out the changes for that into a separate pull request instead? I have a few comments as well for it.
The categories selector fix is fine.


additional white noise mezzanines required

Can you kindly create another 60 seconds mezzanine same as what is it there now, but with different seed please?
We would like to have seed noted on the file name if possible.
We also required white noise mezzanines main and ad for splicing test if you can help to create them as well please?

Can I also suggest we choose 2 PN seeds and document them in the annotations spec?  Then use "PN1" or "PN2" in the filename?

Can I also suggest we choose 2 PN seeds and document them in the annotations spec? Then use "PN1" or "PN2" in the filename?

We dont have specific requirement for seed if we can read it from the file name then it is fine. What is PN stands for please?
Do you want to suggest splicing main and ad seeds as well please if you wish?

@cta-source @yanj-github Please explicitly agree what you want & don't expect @nicholas-fr to do anything unless/until you have reached agreement.

@jpiesing , totally agree--I'm hoping to intercept any "production" path mezzanine audio files while we get documented agreement.  @nicholas-fr has put together a spec for these kinds of details in the mezz annotations.  I'll discuss here and if we are OK, I'll edit his draft with the results.
Regarding "PN", sorry, that's an abbreviation for Pseudo-Noise, which is what we're getting with the Python numpy.random library methods.  The term PN is commonly used in signal processing to indicate not-actually-random-but-random-like sequences.
I think we already discussed that the Python libraries for PN sequences aren't long-term reproducible.  Changes in the library may result in equally valid PN sequences that don't match what we're using now.  So we need to work from static copies of our defined PN sequences.  In other words, the test code must draw the PN sequence from a WAVE-validated file, not from a library call.  That's easy, we just need to archive the PN sequences.
Another dev note, when converting ASCII to decimal to create the entropy seed, we need to make sure we use leading zeros.  E.g., for ascii("P"), use "080" rather than "80".  Using the shorter form results in less than 32 bits of entropy (about 26 bits).  This should actually still work fine, either way, but we need to have a consistent approach.  Note that the current audiomezz.py does NOT add leading zeros, so if we make this change we need to be consistent.
I recommend we set up some kind of structure like the following:

Seed   Source String
Seed
Use

test
116101115116
Development purposes

PN01
080078048049
Primary content,   production code

PN02
080078048050
Ad (spliced) content,   production code

PN03
080078048051
Spare No. 1

PN04
080078048052
Spare No. 2

Then we can embed "PN01", etc., in the file names.  But will we have files with multiple PN sequences?  Seems like the splice tests would?  So we'll need a convention to indicate this as well?
--MJB

Thanks @cta-source ,
We have test mezzanine white noise already.
I would like to have 2 white noise for main testing and swithing testing.
And 2 white noise for splicing tests, one main one is ad.

Seed   Source String
Seed
Use
MD5 Hash
Duration

test
116101115116
Development purposes
A18D8B6BEF5A37C2018EA02E7A0B3F5A
60

PN01
80078048049
Primary content,   production code
3A2E4B3B41FED078241A02DE6848ACA9
60

PN02
80078048050
Secondary content,   production code
144A3E6C0D4D4F4EC42D35C9BD2E00ED
60

PN03
80078048051
Main (spliced) content
72F92675E263E5AFD0F34FA5EE70DCE0
?

PN04
80078048052
Ad (spliced) content
7120086841ECB45721D9CE89A7E5D732
?

Duration for Main (spliced) content and Ad (spliced) content should match the duration of mezzanine that we have for video so that we can do sync.
@cta-source  are you happy with this?

Hi Yan, sounds very reasonable.  However, I'm not clear on one point.

Duration for Main (spliced) content and Ad (spliced) content should match
the duration of mezzanine that we have for video so that we can do sync.

Is that the 60s duration?  Or will it be something else?
I'm working now with 60s durations.

Hi Yan, sounds very reasonable. However, I'm not clear on one point.

Duration for Main (spliced) content and Ad (spliced) content should match
the duration of mezzanine that we have for video so that we can do sync.

Is that the 60s duration? Or will it be something else?
I'm working now with 60s durations.

As far as I know splice main has different duration please see this:
https://dash-large-files.akamaized.net/WAVE/Mezzanine/under_review/2021-08-05/

I think we can use the first (e.g.) 15 seconds of a 60-second PN file, can't we?  Rather than make a file for each length, let's just have one for the longest requirement (60 seconds?) and truncate as needed.  Would that work for you?

I think we can use the first (e.g.) 15 seconds of a 60-second PN file, can't we? Rather than make a file for each length, let's just have one for the longest requirement (60 seconds?) and truncate as needed. Would that work for you?

Yes that is fine with us.

@cta-source We can shorten the lenght within the encoding process for splice main to match video duration. Can you kinldy list down the content that you would like to have so that @nicholas-fr have clear idea of what to generate please?

OK, after some realtime discussion, here's what we've agreed upon.  Four PN files, as described above, plus one music file with an embedded copy of PN01, for test purposes.
Very important for devs: The hash codes of PN01-PN04 have changed because we went from stereo noise to Lch noise.  The files are different, so the MD5 hash is different.  Please see below.

Seed Source String
Seed
Use
MD5 Hash
Duration

AdagioPN01-12dB.wav
n/a
Development purposes
A6C14824708CB8A96FE91D1F2E838F84
60

PN01.wav
80078048049
Primary content, production code
98626CE9659298B9316A26DE2C92AE91
60

PN02.wav
80078048050
Secondary content, production code
19DEC56E552A5848CAD0350C2994A704
60

PN03.wav
80078048051
Main (spliced) content
D12AB69985A3E6A7B88CA4911FC46EBA
60

PN04.wav
80078048052
Ad (spliced) content
BCE7DC0250E359306E3EC490416B4453
60

I've passed copies of the files, the hashes and the code used to generate the noise to Yan for her review.  If this all works as expected, these files will be part of the next release.  We may also maintain testout.wav; I'm not using it but Eurofins may have a use for it.

@cta-source Can you point me to the repo where these are shared please? I dont see "research" folder on akamai. Are they shared elsewhere?

They are in a repo at cta-source/audio-watermark-study for now.  We had not yet agreed to move this to the WAVE repo area.  I'm not sure we want a dedicated repo under WAVE just for this little project, I was thinking we would leave the code in this 'research' repo until we merge with the OF.  What do you think?

They are in a repo at cta-source/audio-watermark-study for now. We had not yet agreed to move this to the WAVE repo area. I'm not sure we want a dedicated repo under WAVE just for this little project, I was thinking we would leave the code in this 'research' repo until we merge with the OF. What do you think?

Thanks, Mike. Certainly we can wait this to be agreed with the group.
However, please note that there are already final encoded contents eac3 and ac4 from this source already on content pool.

However, please note that there are already final encoded contents eac3
and ac4 from this source already on content pool.

Noted, thanks. As this isn't a current priority (use of audio watermarks), it should not be a problem to leave things as-is.


Allow redirect from github.dev

It would help switch between stable and insiders

@joyceerhl how can i verify this?

This is probably the fastest way: https://github.com/microsoft/vscode-dev-chrome-launcher/blob/main/CONTRIBUTING.md#development


Fixed isHasKey and added trimWhitespaces

Closes #479

[x] Running yarn lint does not trigger any linter errors
[x] The test of the method you have fixed is passing
[x] You have written a new skeleton method for someone else to work on!
[x] You have written tests to accompany your skeleton method

Bingo! Thanks! Could you create a new issue too. It would be really helpful.


setting initial date range

initializing a new instance can only set date from and to with the same date,
can there be a way to set both date from and to independently.

You can use the end parameter newinstance method


Add an exiting data analysis in a single juypter notebook

For this milestone, the analysis code and narration should be contained within a single literate code document (i.e., Jupyter notebook). This document should not actually be named analysis.ipynb, but have a more descriptive title, related to the project title.
Requirements:
For this milestone, the analysis code and narration should be contained within a single literate code document (i.e., Jupyter notebook). The following sections should be included:
Title
Summary
Introduction:

provide some relevant background information on the topic so that someone unfamiliar with it will be prepared to - understand the rest of your report
clearly state the question you tried to answer with your project
identify and describe the dataset that was used to answer the question

Methods & Results:

describe in written english the methods you used to perform your analysis from beginning to end that narrates the code the does the analysis.
your report should include code which:
loads data from the original source on the web
wrangles and cleans the data from it’s original (downloaded) format to the format necessary for the planned classification or clustering analysis
performs a summary of the data set that is relevant for exploratory data analysis related to the planned classification analysis
creates a visualization of the dataset that is relevant for exploratory data analysis related to the planned classification analysis
performs classification or regression analysis
creates a visualization of the result of the analysis
note: all tables and figure should have a figure/table number and a legend

Discussion:

summarize what you found
discuss whether this is what you expected to find?
discuss what impact could such findings have?
discuss what future questions could this lead to?

References:

at least 4 citations relevant to the project (format is your choose, just be consistent across the references).

Dependent on #6

This task can also be used to split the analysis up into separate chunks which can then be worked on by other team members

Added the dsci100 project which @Rz02 worked on

Reopened issue because some milestone goals were missing

https://github.com/miniatureseal/dsci-310-group-10-GCC/pull/24


CSS

CSS
User story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I see a dark blue header and footer, and four boxes with a shadow

added  required stylings to HTML doc.


Upgrade React Native 0.72.4

React Native 0.72.4 has interop layer could lead big impact with performance, so we upgrade to this version first
What to test:

Interaction with native components: Camera, biometry, upload file, browser,...
Performance in all list view
Items with image

Version test: https://file.cdmteck.com/s/DB9JLAnjJczopcC/download?path=%2F&files=SubWalletMobile-build-221-1008-merge-2023-09-27T07-54-17.apk
Device test: Samsung S20 FE 5G
Validation passed.


kludge to fix null pointer on low memory devices

this fixes #72

also not sure if npm will automatically pick up this changes.......? otherwise don't forget to publish to npm....

also published 🚀

YAY! Thanks! :confetti_ball: :tada: :confetti_ball:
(So you have to manually publish to npm right? I thought they would automatically update nowadays....)


Support for azure Data Lake Gen2 type storage

🚀 Feature Request
The current support for Azure only covers the blob type storage and not the Data Lake Gen2 type storage which is more generally used for AI workloads. These support hierarchical namespaces in comparison to the flat namespaces in the case of blob storage. Also these type of storage are optimized for Big Data analytics and training on large sets of data.
Motivation
With PR #256, we can use Streaming with azure blob type storage. I tried it out and it worked seamlessly. But when I tried it with Data Lake type storage it crashed, mainly due to differences in the way these two are handled by the sdk.
Implementation
The code additions to allow their usage is minimal:
   # Create a new session per thread
    service = DataLakeServiceClient(
        account_url=f"https://{os.environ['AZURE_ACCOUNT_NAME']}.dfs.core.windows.net",
        credential= os.environ['AZURE_ACCOUNT_ACCESS_KEY'])
    try:
        file_client = service.get_file_client(file_system=obj.netloc, file_path=obj.path.lstrip('/'))
        with open(local, 'wb') as my_blob:
            file_data = file_client.download_file()
            file_data.readinto(my_blob)
    except ResourceNotFoundError:
        raise FileNotFoundError(f'Object {remote} not found.')
    except Exception:
        raise

We need only add a new service client for Data Lakes and change the corresponding  get_file_client method. Also  a corresponding uploader needs to be created.
The only reason I haven't created a PR yet is that it is not yet clear to me what may be the best way to differentiate between calling either of the clients. Can we have a flag for the storage type ( storage_type = blob  or storage_type = datalake), hat can be set by the user? Which other files may need changing because of this? Please suggest and I can contribute.

Hi @shivshandilya , thanks for showing interest in the streaming dataset and interest in contribution. When someone uses Azure Data Lake Gen2 type storage, is the data location prefix path starts from azure:// like blob type or is it different ?

its the same, but the prefix doesn't matter that much. I say this because the way the remote path is used in Streaming is not the actual URI of the data that we have in azure. The actual URI contains info like the subscription id, the workspace name etc(azure://subscriptions/<-subscription id->/resourcegroups/<-Name of resource group->/workspaces/<-Name of workspace->/datastores/<-path to data->). For our use we can have a custom prefix like azure-dl (for Data Lake), and it would not make much of a difference because the remote path that we give here is anyway customized to be in a certain format( that is , container name followed by the path of the data).

To answer simply, its the same. But there is a catch. In azure the data can be accessed in many ways. Simple URIs like azure://datastores/<-data_store_name->/path/ can be used to access the data, but they need account details like account_url and key. They can be URIs of different types which differ in the way the data is accessed and how easily(all dependent on the type of data asset we create) . The example above is just one way. Here are more ways. The main info that we need is always the container name and the path to the data is the container, which a URI or path like azure://container_name/path-to-data  is sufficient to convey along with the account details. This is the way the PR #256 did it. Now if we want to access data lakes instead of blobs they can have same or different URIs depending on the access type we want but to make it simple we can stick to the azure:// format, otherwise we would have to handle more prefixes. I suggest that we add support for a custom prefix like azure-dl (for azure Data Lake). This way we can make minimalistic changes and also respect the way azure present the data(in some way, only the prefix is different, everything else in the URI or path is the same).

Hi @shivshandilya, thanks for the detailed explanation. I liked the approach of a custom prefix like azure-dl (for azure Data Lake). Also, if we keep the same prefix azure, I am guessing there is no way to identify at runtime whether this is a data lake or a blob storage right ? Since the credential setup is the same and both need an environment variables setup AZURE_ACCOUNT_NAME and AZURE_ACCOUNT_ACCESS_KEY.

Sure @karan6181. I will create a PR for the same.


RFC 0029: signature verification and MTC

After writing an implementation of Message Trust Contexts, I get the feeling that it may be helpful to have a context for signatures being successfully verified (SIG_VERIFY_OK or something). I think it plausible, for instance, to have a decorator pre-processor verify and unpack signatures such as connection~sig in the connection protocol, adding the context to the message. However, having more than one signature decorator inside of a message where one verifies and another does not muddies the waters. We would have to be able to specify which field verified and which one did not.
This might be scope creep for the concept of MTCs; but, I think we already face the same issue with the nonrepudiable context. If a message has a signature decorator inside of it that verifies, do we apply the nonrepudiable context to the whole message? Are MTCs, perhaps, recursive meaning that sections of a message can have their own MTC? Or do we need another data structure that adds more context to a specific message trust context?
cc @dhh1128

The intent was that the NONREPUDIABLE attribute of an MTC would equate to what you are calling SIG_VERIFY_OK.
I agree that having a signature over a specific subset of a message's content, and having a signature over the entire message, muddies the water. But I wonder if incomplete signature verification is really useful; could we just say that either all signatures validate, or else the whole message is unworthy of the NONREPUDIABLE flag?
I'm feeling like we should shy away from extra complexity if we can get away with it, because right now code written by @dbluhm and code written by me are the only two impls I know of for MTCs, and I want to make it easy to pick up support; I think pretty good MTCs that are widely adopted would be better than highly precise, granular/recursive MTCs that feel too intimidating to back into impls.
That's just a quick gut reaction, though. I could be talked out of it.

I understand the reasoning to keep MTCs simple and I think I agree.

I agree that having a signature over a specific subset of a message's content, and having a signature over the entire message, muddies the water. But I wonder if incomplete signature verification is really useful; could we just say that either all signatures validate, or else the whole message is unworthy of the NONREPUDIABLE flag?

I'm not sure I follow here. If we did have a message with one or multiple signed subsets of content and the signatures verify, applying NONREPUDIABLE to the whole message would seem to imply that any contents outside of those subsets are also nonrepudiable which would not be true.
I wonder if a solution to the muddiness would be to let NONREPUDIABLE apply to whole messages and perhaps have custom trust attributes for specific fields of a message that have been signed. Going back to my original example from the connection protocol, as a signature verifying pre-processor successfully verifies the connection~sig decorated field, it could add CONNECTION_SIG_VERIFIED. This may still be falling into "highly precise" land and I'm still not quite certain the benefits outweigh the added complexity.

You're right. I wasn't being careful enough in my analysis. Having a message where 2 subsets of the content are signed, and both signatures verify, is definitely different from having a message where the entire message is signed and it verifies. We can't use NONREPUDIABLE for both.
I'm still thinking about the rest of what you said.

This is an interesting angle that reinforces my thinking that the ~sig decorator may be more complex than we originally thought. I agree with the analysis that @dbluhm has provided around needing to provide attribute specific MTCs for the ~sig decorator. I wonder if this is limited to this decorator only (because it's cryptographic in nature) or if this is more common to all decorators.

With the move to use ~attach with a signature over ~sig, I think a solution becomes clearer; attached documents can be more cleanly thought of as separate messages with their own associated trust context, with some of its attributes being inherited from the parent message.

@dbluhm agreed to do some RFC Updates to capture tribal knowledge. Will close after that has happened.

PR #346 in with a small update to the MTC RFC that attempts to capture the outcome of this discussion. I'll go ahead and close this issue.


Migrate to use StandardWebhooks

https://www.standardwebhooks.com/
https://github.com/standard-webhooks/standard-webhooks/tree/main

When accepting inbound webhooks test for the usage of it and handle properly.
When sending webhooks conform to the standard

@cpursley If you are going to work on the Elixir library to contribute to the StandardWebhooks project I will wait until that is done for this.

Sounds good. If they don't accept a PR we can just use the code ourselves.


Medial la should not be in the MH class

In Pwo Karen and Aso Chin, the sequence Medial Ha / Medial La can appear as part of a syllable cluster. (See https://github.com/w3c/font-text-cg/issues/43#issuecomment-922907745) Currently the Uniscribe cluster model places U+103E and U+1060 in the same class, making them mutually exclusive within a cluster.
U+1060 should be placed in a separate class, and the cluster model adjusted accordingly. (See https://github.com/harfbuzz/harfbuzz/pull/3220)

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

ID: 707025a9-99cf-7dab-e332-00cefc8138bd
Version Independent ID: 2a25e6c3-c710-37e0-b581-0c4a38f22309
Content: Creating and Supporting OpenType Fonts for Myanmar Script - Typography
Content Source: typographydocs/script-development/myanmar.md
Product: typography
GitHub Login: @alib-ms
Microsoft Alias: alib

We received a report from native speakers of the Karen (S’gaw) language that they cannot input the proper form, which is transliteration of an English name.
For your information, we checked this reference: Creating and Supporting OpenType Fonts for Myanmar Script - Typography | Microsoft Learn
It defines classification of sequence of Unicode characters to syllable clusters.
The new characters are listed:
“MH”  Medial consonants Ha, Mon La (103E, 1060)
“MW”  Medial consonants Wa, Shan Wa (103D, 1082)
As a result, when these characters are used together, the syllable is separated to two clusters.
Reference: 1060_103D.txt


Issue with testem / Chrome in tests

It seems it is not properly configured and npm auto-updated the dependencies (this is why we should use package-lock.json and npm ci).
https://travis-ci.org/BoxFactura/pulltorefresh.js/builds/425531162

Thanks for your feedback, CI is stable now: https://github.com/BoxFactura/pulltorefresh.js/pull/51
Now just waiting for some feedback before proceed.


[APIReview] Add Upsert convenience helper

Consider adding an Upsert convenience helper.

PoR - add a PUT option that does the Create or Replace operation - Upsert will use this new functionality.

Removed due to move away from the Azure.Core library dependency.


Issue after deploy on heroku

Works fine on development, but after deployed on heroku, charts doesnt open. Im getting the error
c3.js:1046 Uncaught TypeError: n is not a function
    at new a (c3.js:1046)
    at new r (c3.js:1026)
    at Object.Y.generate (c3.js:1055)
    at t.value (react-c3js.js:69)
    at t.value (react-c3js.js:85)
    at t.value (react-c3js.js:44)
    at commitLifeCycles (react-dom.production.min.js:148)
    at t (react-dom.production.min.js:157)
    at b (react-dom.production.min.js:168)
    at v (react-dom.production.min.js:167)

Exactly same problem here! Any solutions?

We've run into this issue, think its to do with the require in componentDidMount which worked fine in development but not in production because of our setup
https://github.com/bcbcarl/reactc3js/blob/89fb042d5e582dca14e04a17e7690a2524fe0f7d/src/index.js#L48
componentDidMount() {
    c3 = require('c3');
    this.updateChart(this.props);
  }


Consider moving symbol and footprint configs out of scripts...

... and into .json/.yaml files elsewhere that the scripts can be pointed at

Upon further consideration I will keep them in the script files for now.


Inconsistency in Company Name field.

While looking at the assets/trackerdb.sql, in the table trackers lot of times the company names are with quotes like  "company name" and at times without quotes, is there a reason for it?
name
"Google Analytics"
DoubleClick
Google
"Google APIs"
"Google Tag Manager"
Facebook
INFOnline
"Google AdServices"
"Google Syndication"
"Amazon Web Services"```

Hi @konarkmodi this should be fixed now. It was indeed just inconsistent naming - thanks for reporting. Source: https://github.com/cliqz-oss/whotracks.me/blob/master/whotracksme/data/assets/trackerdb.sql


export error-shape error

Hi!
I have trained successfully on the blender data. When i export the point cloud or mesh, it raised the shape error

Hi!
I got the identically same problem in exporting tsdf mesh from trained nerfacto model when I used the lego blender dataset and Blenderdataparser.
Have you tackled this error?

Hi! I got the identically same problem in exporting tsdf mesh from trained nerfacto model when I used the lego blender dataset and Blenderdataparser. Have you tackled this error?

sorry, I didn't fix the bug. But my friend had fixed. She doesn't have her computer with her, so it takes a few days for her to tell me how to fix it. As soon as I know the solution, I'll upload this issue.


Add Western Springs College

@falingdy Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Rebased Teams extension.

Purpose

The Teams extension was not working. I rebased the extension with the latest Teams Toolkit updates.

Does this introduce a breaking change?

[ ] Yes
[X] No

Pull Request Type
What kind of change does this Pull Request introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Follow the README guidance for installing the Teams extension.

Test the code

Follow the README guidance for installing the Teams extension.

What to Check
Verify that the following are valid

Ask a question against the Knowledge Store. Verify the answer is comparable to the response within the web-based UI.

Other Information

N/A

Hi @hunterjam - I'm happy with all of the changes apart from the package.json. Ideally we want to be on Node 20, but the Teams Toolkit has a dependency on botbuilder-js which has a dependency on an older msal library that has to support node 16, but doesnt support 20. That's fine, but we should really be on Node 18 as a minimum. Nodemon has a security flaw which is why we upgraded that. Are we saying that the code does not work with the packages we have?

Hi @ross-p-smith --- I've been testing with version 18 and everything seems to be working fine. I did change the min version of Node on the package.json to 18. I did try testing with version 19 and 20. Unfortunately, the app does not work. I had to reach out to support to check the logs because no errors were generated. Let me know if you have any other questions.


docs: fix mdc component usage and cloudflare preset reference

🔗 Linked issue

❓ Type of change

[X] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Fixes incorrect MDC syntax was preventing the following paragraph from displaying.
Fixes Nitro preset name (cloudflare => cloudflare_module)
Fixes formatting on the Cloudflare page (see below).

[!Note]
It appears that undocs (or something in the docs site config) is not properly transforming ordered lists defined in markdown, so I just switched to a bulleted list. Probably needs to be addressed at the source.

Formatting before

Formatting after

📝 Checklist

[ ] I have linked an issue or discussion.
[X] I have updated the documentation accordingly.

@pi0 uodated from the proper branch


Evaluation for XNLI dataset

See https://github.com/EleutherAI/lm-evaluation-harness/pull/258
Compare to mGPT  (mGTP XL = 1.3B) https://arxiv.org/abs/2204.07580

prompt =
XNLI "<s>" + sentence1 + ", right? " + mask + ", " + sentence2 + "</s>",

 where mask is the string that matches the label: entailment - Yes, neural - Also, contradiction - No.

Example:

<s>The girl that can help me is all the way across town, right? Yes, The girl I need help from lives a ways away.</s>

mGPT https://huggingface.co/sberbank-ai/mGPT
xnli_de:

zero short: 0,450  (OK; IN STD RANGE)
16 shot: 0,425

xnli_en:

zero shot 0,498 (OK; IN STD RANGE)
16 shot: 0.442

Task
Version
Metric
Value

Stderr

xnli_en
0
acc
0.4912
±
0.0071

xnli_de
0
acc
0.4569
±
0.007

xnli_de (bad prompt)
0
acc
0.3749
±
0.0068

xglm-1.7B https://huggingface.co/facebook/xglm-1.7B
xnli_de:

zero shot: 0.50
16 shot: 0.40

xnli_en:

zero shot: 0.472 (too low)
16 shot: 0.386

Task
Version
Metric
Value

Stderr

xnli_en
0
acc
0.497
±
0.0071

Alternative implementation https://github.com/OpenGPTX/lm-evaluation-harness/commit/04855d1fc182156032e6bf944b3dbdc7c8a830ba

PR https://github.com/OpenGPTX/lm-evaluation-harness/pull/23