help folllowing the example and getting my own simple test working

@OleksandrKvl
I've been trying to put an example together that uses my simple case, but the examples have gaps in explanation, IMO and I would appreciate your help.
I'm following very carefully the example
within one program I'm trying to use my message scheme (3 fields) to encode into buffer and then decode from address and size generated.
============= my Schema =============  My message schema:   file: timesmsg1.xml
<?xml version="1.0" encoding="UTF-8"?>
<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2016/sbe"
                   xmlns:xi="http://www.w3.org/2001/XInclude"
                   package="three_arg_msg1"
                   id="1"
                   version="0"
                   semanticVersion="5.2"
                   description="Schema to test endianness"
                   byteOrder="bigEndian">
    <types>
        <composite name="messageHeader">
            <type name="blockLength" primitiveType="uint16"/>
            <type name="templateId" primitiveType="uint16"/>
            <type name="schemaId" primitiveType="uint16"/>
            <type name="version" primitiveType="uint16"/>
        </composite>

        <composite name="composite_19">
            <type name="float_field" primitiveType="float"/>
        </composite>

        <composite name="varStrEncoding">
            <type name="length" primitiveType="uint32"/>
            <type name="varData" primitiveType="char" length="0"/>
        </composite>
    </types>

    <sbe:message name="msg1" id="1">
        <data name="date" id="1" type="varStrEncoding"/>
        <data name="time" id="2" type="varStrEncoding"/>
        <data name="meno" id="3" type="varStrEncoding"/>
    </sbe:message>
</sbe:messageSchema>

============= my generated files  =============   that were copied into my project
three_arg_msg1.zip
============= my test program  =============  My message schema:   file: msg1.xml
#include "stdio.h"
#include <iostream>

#include "three_arg_msg1/messages/msg1.hpp"   // copied over from sbeppc generation

int main() {
    std::array<char, 1024> buf{};

    auto m = sbepp::make_view<three_arg_msg1::detail::messages::message_1>(buf.data(), buf.size());
    sbepp::fill_message_header(m);

    auto d = m.date();
    d.assign_string("2/23/2010");

    auto t = m.time();
    t.assign_string("12:13:123");

    auto c = m.meno();
    c.assign_string("33333.234");
    //
    const auto msg_size = sbepp::size_bytes(m);
    char* addr = sbepp::addressof(m) ;
    printf(" msg_size=%ld, address of m = %lld\n", msg_size, (unsigned long long)addr) ;
    /// =============== Now Decode (as if received over network comm ====================
    auto header = sbepp::make_const_view<sbepp::schema_traits<three_arg_msg1::schema>::header_type>(addr, msg_size);

    if(*header.templateId() != sbepp::message_traits<three_arg_msg1::schema::messages::msg1>::id()) {
        std::cout << "unknown message id: " << *header.templateId() << '\n';
        exit(1);
    } else {
        printf("header id OK!!\n") ;
    }
// >>>>>>>  when I comment out below, the above code prints out "header id OK!!"

// <<<<<< here is where I have a problem compiling and can't find the right namespace path:
    // auto r = sbepp::make_const_view<three_arg_msg1::detail::messages::message_1>(addr, msg_size);
    auto r = sbepp::make_const_view<three_arg_msg1::detail::messages::message_1>(addr, msg_size);

    // let's pretend we got this buffer from an untrusted network and want to be
    // sure that the message is fully contained within given buffer.
    auto checked_size = sbepp::size_bytes_checked(r);
    if(!checked_size.valid) {
        std::cout << "bad message\n";
        exit(1);
    }

    // note: order doesn't matter, it's mixed for demo purpose
    auto dd = m.date();
    std::cout.write(dd.data(), dd.size());
    auto td = m.time();
    std::cout.write(td.data(), td.size());
    auto cd = m.meno();
    std::cout.write(td.data(), td.size());
    std::cout << "Done\n" ;
}

============= compile errors when I uncomment below "// <<<<<< here is where I have a problem compiling" =============
TE-SBE/test-sbepp/build$ make
Consolidate compiler generated dependencies of target sbetst1
[ 50%] Building CXX object CMakeFiles/sbetst1.dir/main.cpp.o
TE-SBE/test-sbepp/main.cpp: In function ‘int main()’:
TE-SBE/test-sbepp/main.cpp:50:50: error: no matching function for call to ‘size_bytes_checked(three_arg_msg1::detail::messages::message_1<const char>&)’
   50 |     auto checked_size = sbepp::size_bytes_checked(r);
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from TE-SBE/test-sbepp/three_arg_msg1/messages/msg1.hpp:7,
                 from TE-SBE/test-sbepp/main.cpp:7:
/usr/local/include/sbepp/sbepp.hpp:5534:5: note: candidate: ‘template<class View> sbepp::size_bytes_checked_result sbepp::size_bytes_checked(View, std::size_t)’
 5534 |     size_bytes_checked(View view, std::size_t size) noexcept
      |     ^~~~~~~~~~~~~~~~~~
/usr/local/include/sbepp/sbepp.hpp:5534:5: note:   template argument deduction/substitution failed:
TE-SBE/test-sbepp/main.cpp:50:50: note:   candidate expects 2 arguments, 1 provided
   50 |     auto checked_size = sbepp::size_bytes_checked(r);
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
make[2]: *** [CMakeFiles/sbetst1.dir/build.make:76: CMakeFiles/sbetst1.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/sbetst1.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
TE-SBE/test-sbepp/build$

I believe line 46 ...
46:    auto r = sbepp::make_const_view<three_arg_msg1::detail::messages::message_1>(addr, msg_size);
is the problem but the examples have gaps and I can't figure what is the proper namespace path and object to put here.
Is there another complete example somewhere I can study?
Thanks

First of all, you should never use things from the detail namespace directly. Namespace structure of generated headers is described here. You should use three_arg_msg1::messages::msg1 type.
About size_bytes_checked, yes, there's a mistake on examples page (they've never been compiled) but if you open its own documentation, you'll see that it has 2 parameters, the second one is the buffer size. Actually, compiler error tells you the same, candidate expects 2 arguments, 1 provided.

Examples are pretty artificial, their intent is just to provide an overview of how the generated code can be used. It's better to check individual documentation pages or look how they are used in test files.


Frozen process

Dear Alberto!
Smth strange goes on when i'm trying to run this code.

I run this code and nothing happens, no speed per second, no new range displayed.... But the CPU utilization is good (3 threads are used on 100%).
But if I run smth like searching 64th or 120th puzzle everything goes well.
Why this can occur?

You are testing 136K publickeys you need to add some K factor check the readme please i suggest
-k 128
To start but you can run it with more RAM to get better speed

Dear Alberto. I didn't hurry to reply to you. I wanted to check weather the -k option will work or not. But unfortunately it didn't help to solve the problem. May be i should install new version as of 30th of March.. I don't know... Very strange...
The command line i used is:
./keyhunt -f allpubkeys.txt -m bsgs -r 1:ffffffffffffffffff -k 24 -t 7 -s 20 -p ./Pfile.bin
(a low value of -k was entered in order to check quickly the functionality)

In that case please use a file with a less number of publickeys, some 50 or 100 publickeys will be enough. the speed of the BSGS mode decrease with the number of keys that your input file have.

Thank you very much, Alberto! And excuse me for annoying :)

It seems to me that i have understood what's up. The calculations are processing but very-very slowly due to huge amount of public keys. It was a bit strange for me as i remember that you've been writing that you've tried 20K keys and got a speed of Tera-, Peta- or smth like this. I tried xpoint mode and obtained a speed of 1,5Mkey/s ))
Hence we can make a conclusion (by comparing VanitySearch using search by address and -bsgs mode using search by public key) that keyhunt is devilishly useful for searching 1 address by public key in a specified range. Searching for a list of addresses/public keys is useless in both cases. :)

Yes it was 20 000 publickeys at 200  @Gigakeys/s

Step by step i involving in understanding the process of searching ))
My further 120K file compressed onto 20K public addresses with balance as you do have.
I see that these addresses have the first mined coins (most of them have 50 BTC), but to determine the range of searching these addresses is still a difficult problem. :)

The range of keys you cannot find unless it was deliberately disclosed, you can only guess that the range of addresses with 50 bitcoins is from 254 to 256 .

To "see how many bits your private key is" for this moment is rather difficult for me to understand. :) I will just believe you that those addresses are in 254...256 bit range. As i've understood it's just need to add a "-b 254" argument in command line (then "-b 255"...) at that is all?

You cannot know how many bits the private key has. In the puzzle, this is intentionally open. But knowing the public key, you cannot know the key space.

The range of keys you cannot find, unless it was deliberately disclosed, you can only guess that the range of addresses with 50 bitcoins is from 254 to 256 bits .in principle, you can download early versions of the bitcoin core 0.1-0.1.3, extract the priv key of the address and see how many bits your private key is.

With all respect to all written above i'd like to add a POV that the range of 2^253 is just a 12,5% of the whole range. Thus the scanning of whole range neither scanning the 2^254...2^256 has no difference (or it just give a 12.5% less performance rather than scanning the whole range). It both cases the result is zeroth )))

I just wanted to say that in case of searching for 50BTC-wallets there's no difference neither to scan the whole range nor to scan 2^254...256 range. Sorry for my English :)

Dear Alberto. Could you explain am i right or not? :)
Look. We are (i do) searching for 120th puzzle with a speed of 5*10^14 keys/thread/second. So to pass all the range (with 1 thread) we need 2^119 divide the speed. It equals near 10^21 seconds. The probability of finding the 1 key is 1/(10^21). Or reversing: 10^21 to scan for 1 key.
Thus extracting the public keys from blockchain we have near (supposedly) 20K keys. The speed of searching lowers approx. 10 times down. Suppose it will be 510^13 keys/thread/second. But we need to scan the full range from 1 to 2^256. So we need 2^256 divide the speed. It equals near 210^63 second. The probability of finding any key is 20000/(2*10^63). Reversing: 10^59 to scan for 1 key.
Thus what is the reason to search using public keys in full range if there exist a huge probability to search for 120th puzzle?


WIP: GitHub Actions init

Testing GitHub actions behaviour during PR creation.

Would be great to see the npm-ci-job run on Windows as well. 😊
The bs test is not really needed on Windows, as most of the time the npm script creation is cross-os.

@tmsns Added windows-latest. It fails on npm run build
Run npm run build && npm run build:types
At D:\a\_temp\05c0e193-7ab4-4c39-90af-7b86aec5be9f.ps1:2 char:15
+ npm run build && npm run build:types
+               ~~
The token '&&' is not a valid statement separator in this version.
+ CategoryInfo          : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : InvalidEndOfLine

Running the node tests on windows would be really great indeed, it is a major blind spot for us.
I expect some tests and commands fail on windows, we will need to fix those.

@tmsns Added windows-latest. It fails on npm run build
Run npm run build && npm run build:types
At D:\a\_temp\05c0e193-7ab4-4c39-90af-7b86aec5be9f.ps1:2 char:15
+ npm run build && npm run build:types
+               ~~
The token '&&' is not a valid statement separator in this version.
+ CategoryInfo          : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : InvalidEndOfLine

Seems the windows image is using Powershell as the command-line environment. Over there the ; character is used to delimit commands. The normal CMD would have worked, though.
In order to be trully os and command line indepent, we should switch over to JS. Some packages like npm-run-all or concurrently can help here. 😃

@tmsns Added windows-latest. It fails on npm run build
Run npm run build && npm run build:types
At D:\a\_temp\05c0e193-7ab4-4c39-90af-7b86aec5be9f.ps1:2 char:15
+ npm run build && npm run build:types
+               ~~
The token '&&' is not a valid statement separator in this version.
+ CategoryInfo          : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : InvalidEndOfLine

Seems the windows image is using Powershell as the command-line environment. Over there the ; character is used to delimit commands. The normal CMD would have worked, though.
In order to be trully os and command line indepent, we should switch over to JS. Some packages like npm-run-all or concurrently can help here. 😃

So commands do must be re-written for npm or we just need to use npm-run-all / concurrently ?

Yeah lets switch to npm-run-all


oic/cbor encoding to/from the wire, remove sol_vector

We changed the approach regarding memory allocation when we changed the internals to use cbor to use more memory allocation that we did before.
we should change it to iterator pattern that reads/writes directly to the "wire" (packet's payload).
hopefully before v1 so we can break api and do not keep the old behavior.
@lpereira can share some ideas.

Fixed when PR #1127 was merged.


OpenAI key

Hi! I applied for an OpenAI key for exploring the gpt-f tactic by filling the form mentioned in the repo last week. @jesse-michael-han Is there any further step necessary for accessing the key? Kindly advise. Thanks! - Ayush Agrawal

@ayush1801 It took me several months to receive my key.


'sanitize-html' need more actions than the tutorial of adding RSS

📋 Explain your issue
In the tutorial of adding RSS, it use sanitize-html but it show:
[vite]: Rollup failed to resolve import "sanitize-html" from "C:/Users/leen/Documents/workspace/astro-fafabear/src/pages/rss.xml.js".
This is most likely unintended because it can break your application at runtime.
If you do want to externalize this module explicitly add it to
`build.rollupOptions.external`

I have tried configure the astro.config.mjs:
export default defineConfig({
  site: 'https://example.com',
  .....
  build: {
    rollupOptions: {
      external: ["sanitize-html"]
    }
  }
});

But it doesn't work. Could someone give a help and fix the doc?

Hi @LeenHawk! We have work in progress to update the tutorial RSS example for v3! In the mean time, you can consult the updated docs page on adding RSS to an Astro site for more up-to-date information!  🙌
If you encounter more problems with your own code, then please ask in our Discord https://astro.build/chat which is where people will be happy to help you with your project! We cannot answer support questions here. These issues are only for working on the documentation site. But, we have support people in Discord ready to help answer questions and troubleshoot code with you! 🚀


navigate from function call to function body

In large block programs, it would be really useful to have an option from right-mouse button on a function-call block to navigate to the function call.

Takes Peli some time to find called user functions in on-line video.

Also, many functions in blocks are called just once, so maybe nice to have navigation back to call site.

At the very least, we need a "go to definition" context menu item.

And a "collapse all" context menu item that shrinks and organizes everything together. Navigation in large scripts is pretty bad.

Collapse all added.


Bump Cocoa to 7.1.3 and use PrivateSentrySDKOnly instead of the private headers

This is a private class for our SDK that exposes some stuff that is needed, eg for envelopes https://github.com/getsentry/sentry-dart/pull/391
that are more things that can be removed I guess eg the private header

I think @denrase already done it in https://github.com/getsentry/sentry-dart/commit/60cde6dc13e00fdb771fc93f56d78897891e10e3

Yeah, needed to bump in order to use the new API.

The new class has more methods used by the sdk, so the bump is indeed done but not removing the old private header hacky solution

eg https://github.com/getsentry/sentry-dart/blob/main/flutter/ios/Classes/SentrySDK%2BFlutterPrivate.h could be removed in favor of PrivateSentrySDKOnly

I know the bump has been done already on https://github.com/getsentry/sentry-dart/pull/391 but that PR lands only on v6 and I'd like to bring this improvement into 5.1 too


QueryRaw: Error serializing parameter

Bug description
When using $executeRaw or $queryRaw, it is impossible to insert an array containing Integer if the schema is of type Float.
Prisma seems to type check the values containing the array, since it never sends the query to the database. In fact, if I change the column name to a column that doesn't exist, Prisma send the query to the database, resulting in the expected error.
The error is the following:
{
  code: 'P2010',
    clientVersion: '3.13.0',
    meta: {
      code: 'N/A',
      message: "error serializing parameter 0: Conversion failed: Couldn't add value of type `Integer(Some(1))` into a double array."
  }

I am trying to use raw database access, since PrismaClient doesn't support null value in scalar list (#12086). However, it still won't let me insert scalar array with null value. I get the same kind of error as when using an Integer
{
  code: 'P2010',
    clientVersion: '3.13.0',
    meta: {
      code: 'N/A',
      message: "error serializing parameter 0: Conversion failed: Couldn't add value of type `Integer(None)` into a double array."
  }

If I change the type of the scalar array for Real @db.Real, I get this variation of the error message:
message: "error serializing parameter 0: Conversion failed: Couldn't add value of type Integer(None) into a float array.`
How to reproduce

Clone https://github.com/s-montigny-desautels/prisma-raw-query-scalar-array
Start postgreSQL with docker-compose up
Run with npm run start
Toggle between valuesWithInt and valuesWithNull to see variation of the same error.

Expected behavior
No error, Prisma doesn't look in the schema for input validation. The database should handle it.
Prisma information
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Test {
  id Int @id @default(autoincrement())

  values Float[]
}

const values = [1, 1.2, 1.3]
await prisma.$executeRaw`
    INSERT INTO "Test" (values) VALUES (${values})
`;

Environment & setup

OS: Linux
Database: PostgresSQL
Node.js version: Node v18.0.0

Prisma Version
prisma                  : 3.13.0
@prisma/client          : 3.13.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine efdf9b1183dddfd4258cd181a72125755215ab7b (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli efdf9b1183dddfd4258cd181a72125755215ab7b (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core efdf9b1183dddfd4258cd181a72125755215ab7b (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt efdf9b1183dddfd4258cd181a72125755215ab7b (at<EMAIL_ADDRESS>Default Engines Hash    : efdf9b1183dddfd4258cd181a72125755215ab7b
Studio                  : 0.459.0

I tested with the release 3.14.0 and by enabling the improvedQueryRaw preview feature.
It now work with null values in the scalar list. I'm still having the error with Integer in float array though.
Raw query failed. Code: `N/A`. Message: `error serializing parameter 4: Conversion failed: Couldn't add value of type `Int64(Some(1))` into a float array.`

I have updated the repo with the reproduction.

Can reproduce in 4.0.0 and also our internal dev version 4.4.0-dev.30
Raw query failed. Code: `N/A`. Message: `error serializing parameter 0: Conversion failed: Couldn't add value of type `Int64(Some(1))` into a float array.`
    at RequestHandler.handleRequestError (/Users/j42/Repros/14999/node_modules/@prisma/client/runtime/index.js:30850:13)
    at RequestHandler.request (/Users/j42/Repros/14999/node_modules/@prisma/client/runtime/index.js:30833:12)
    at async Proxy._request (/Users/j42/Repros/14999/node_modules/@prisma/client/runtime/index.js:31805:16)
    at async /Users/j42/Repros/14999/main.ts:73:27 {
  code: 'P2010',
  clientVersion: '4.4.0-dev.30',
  meta: {
    code: 'N/A',
    message: "error serializing parameter 0: Conversion failed: Couldn't add value of type `Int64(Some(1))` into a float array."
  }
}


Refine jline dependency

Why are the changes needed?
Follows on #1413.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #1416 (05335c4) into master (fb8bf49) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1416   +/-   ##
=========================================
  Coverage     57.44%   57.44%
  Complexity      154      154
=========================================
  Files           225      225
  Lines         11418    11418
  Branches       1404     1404
=========================================
  Hits           6559     6559
  Misses         4315     4315
  Partials        544      544

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb8bf49...05335c4. Read the comment docs.

Thanks, merging to master


Collection Helpers

I'm completely new to ground:db and grounded succesfully my database in a cordova app. The app only needs to read, no operations to the database are needed. But I'm using a lot of Collection Helpers (dburles:collection-helpers ) which can't be accessed when grounded (says they are not defined), because the functions aren't attached to the object returned when taken frome the grounded collection. Also I can't attach Collection Helpers to Ground.Collection (says GroundedCollection.helpers is not defined).
export const Artworks = new Mongo.Collection('artworks');

if(Meteor.isCordova){
    const  ArtworksGround = new Ground.Collection(' ArtworksGround');

    ArtworksGround.observeSource(Artworks.find());

    Meteor.subscribe('artworks.all');

    Artworks.find = function(...args) {
        return  ArtworksGround.find(...args);
    };

    Artworks.findOne = function(...args) {
        return  ArtworksGround.findOne(...args);
    };
}

Artworks.helpers({
    helperFunction() {
        // do something...
        return something;
        }
});

I know this problem is connected with the other package but I thought it would be likelier somebody around here knows a workaround for this.

I'm trying to figure out a way to do this too. Tried adding the helpers function to Ground.Collection.prototype, and then setting Mongo.Collection helpers on there, but it doesn't seem to work... probably some sneaky scoping issue!! Any assistance would be very much appreciated :)
// dburles:collection-helpers for Ground.Collection
// https://github.com/dburles/meteor-collection-helpers/blob/master/collection-helpers.js
Ground.Collection.prototype.helpers = function(helpers) {
    var self = this;

    if (self._transform && ! self._helpers)
      throw new Meteor.Error("Can't apply helpers to '" +
        self._name + "' a transform function already exists!");

    if (! self._helpers) {
      self._helpers = function Document(doc) { return _.extend(this, doc); };
      self._transform = function(doc) {
        return new self._helpers(doc);
      };
    }

    _.each(helpers, function(helper, key) {
      self._helpers.prototype[key] = helper;
    });
};

function _ground(collection, selector) {

    // new references to find and findOne
    collection.findOnline = collection.find;
    collection.findOneOnline = collection.findOne;

    // setup ground collection
    collection.groundCollection = new Ground.Collection(`_${collection._name}`);
    collection.groundCollection.observeSource(collection.find(selector || {}));

    // override find and findOne with ground collection functions
    collection.find = collection.groundCollection.find;
    collection.findOne = collection.groundCollection.findOne;

    // add helpers
    if (collection._helpers.prototype)
         collection.groundCollection.helpers(collection._helpers.prototype);

}

The result of that is the MyCollection.findOneOnline().myHelper() works but MyCollection.findOne().myHelper() throws an error:
TypeError: MyCollection.findOne().myHelper is not a function. (In 'MyCollection.findOne().myHelper()', 'MyCollection.findOne().myHelper' is undefined)

Update: MyCollection.findOneOnline (i.e. the normal ungrounded version) returns a Document, whereas MyCollection.findOne (the grounded collection find method) returns an Object... watch this space!

@richardgsands I am facing the same problem. Are you able to solve this?


Replace CXPLAT_THREAD usage by CxPlatAsync to increase readability and remove more platform specific things

Weird. How am I getting a conflict in submodules/cxplat? Is the right way to use the latest submodule git pull origin main in the submodule folder?


Peer review of the current governance framework draft to ensure consistency

We have made considerable progress against the authoring of threats / controls as per #30 - however, the speed at which we have developed this framework means that we do have some inconsistencies in style, level of detail and quality.
We need to find a way to review this framework in order to set a quality bar that we feel is suitable and attainable on a long-term basis.

Here the feedback we received from MS https://github.com/finos/ai-readiness/issues/79


docs: spelling mistake chnages -> changes in Svelte configuration documentation

Describe your changes
While reading the Svelte configuration documentation, I saw this easy to fix error and wanted to fix it.

Fixes Issue

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.

@all-contributors add @steffenvan for docs


Icons Request: money icons

Describe the requested icon
A lot of icons related with money are missing from phosphor icons, could you please add them, and thank you so much for your efforts.
Screenshots

Additional context
Add any other context here.

Can you be more specific with this request, and include your use-cases that are not covered by existing money icons?

Hey, thanks for your response, I need some icons (withdrawal | invoices | transfers_money_icons) throughout my search on the available icons I didn't find any icon that matches my need.

Added hand-withdraw, hand-deposit, hand-arrow-down, hand-arrow-up, cash-register, invoice, money-wavy, tip-jar.


Test cart and payments with real cards

closing as its duplicate of https://github.com/perminder-klair/gatsbyjs-ecommerce/issues/38


Create Feedback_Visualization_For__Mentors_Sample.ipynb

Description
This is a notebook that shows some visualizations for Mentor feedback by Mentees.
Fixes # BL-136, BL-393
Type of change
Notebook addition
Please delete options that are not relevant.

[x] New feature

Checklist:

[x] My code follows PEP8 style guide
[x] I have removed unnecessary print statements from my code
[x] I have made corresponding changes to the documentation if necessary
[x] My changes generate no errors
[x] No commented-out code
[x] Size of pull request kept to a minimum
[x] Pull request description clearly describes changes made & motivations for said changes

Loom
https://www.loom.com/share/25bd4421e8d344658b9c2a19b6445f5f

Great work on the visualization you made it really easy to understand and follow along in the video.

This flexible visualization tool provides admins with the ability to get a quick overview, a detailed look at individual mentors' feedback outcome and vader score, and even look at sentiment changes over certain time ranges. Nice addition!

@ErinNC, I figured out those changes and did some more fine detail work. It looks better than before. Thanks for your input.


Tree model should contain num_leaves field

Hi everyone, i got a strange bug in my jupyter notebook using LightGBM.
When trying to load data from a pandas Dataset, i got the following case :
Environment info
Operating System: Ubuntu
Python: 3.5
Error Message:
/opt/conda/lib/python3.5/site-packages/lightgbm/engine.py in train(params, train_set, num_boost_round, valid_sets, valid_names, fobj, feval, init_model, feature_name, categorical_feature, early_stopping_rounds, evals_result, verbose_eval, learning_rates, keep_training_booster, callbacks)
    211         booster.best_score[dataset_name][eval_name] = score
    212     if not keep_training_booster:
--> 213         booster._load_model_from_string(booster._save_model_to_string())
    214         booster.free_dataset()
    215     return booster

/opt/conda/lib/python3.5/site-packages/lightgbm/basic.py in _load_model_from_string(self, model_str)
   1552             c_str(model_str),
   1553             ctypes.byref(out_num_iterations),
-> 1554             ctypes.byref(self.handle)))
   1555         out_num_class = ctypes.c_int(0)
   1556         _safe_call(_LIB.LGBM_BoosterGetNumClasses(

/opt/conda/lib/python3.5/site-packages/lightgbm/basic.py in _safe_call(ret)
     46     """
     47     if ret != 0:
---> 48         raise LightGBMError(_LIB.LGBM_GetLastError())
     49
     50

LightGBMError: b'Tree model should contain num_leaves field.'

Reproducible examples
data = pandas.read_csv('...')
label, data = data['XXX'], data.drop('XXX', axis=1)
train_data = lgb.Dataset(data=data, label=label)  # No error here
param = {
    'num_threads':4,
    'early_stopping_round':10,
    'feature_fraction':0.8,
    'num_leaves': 31,
}
bst = lgb.train(param, train_data, num_boost_round=100)
# This produce the given error.

Note that this example is perfectly working :
train_data = lgb.Dataset(data=data.values, label=label)  # Using numpy array as input but pandas as label
param = {
    'num_threads':4,
    'early_stopping_round':10,
    'feature_fraction':0.8,
    'num_leaves': 31,
}
bst = lgb.train(param, train_data, num_boost_round=100)

@wxchan it seems is some problem in python package.

Note that i also tried several ways to install lightGBM  : pip, pip --no-binary, python setup.py from source but none worked.

@PPACI can you provide the output log of first example ?

Strangely, i couldn't have an output log in my jupyter notebook.
Even while configuring logging.basicConfig(level=logging.DEBUG, stream=sys.stdout).
Also trying verbose_eval=1 did not yield any log. Will investigate on my side to see if it's not a mis configuration of my jupyter. (other libs without problem in my setup)

@PPACI
The second example doesn't have logs as well ?

Nothing. i will try i a non jupyter environnement and report.
I did test and the first example which doesn't work on last version, and it seems to work with release 2.0 from 3 may (tag d12e5e4).

OK. Got no log in jupyter but it work in console.
[LightGBM] [Warning] Find whitespaces in feature_names, replace with underlines
[LightGBM] [Info] Total Bins 632
[LightGBM] [Info] Number of data: 55, number of used features: 83
[LightGBM] [Warning] Find whitespaces in feature_names, replace with underlines
[LightGBM] [Info] No further splits with positive gain, best gain: -inf
[LightGBM] [Info] Trained a tree with leaves=2 and max_depth=1
[LightGBM] [Info] No further splits with positive gain, best gain: -inf
[LightGBM] [Info] Trained a tree with leaves=2 and max_depth=1
[LightGBM] [Info] No further splits with positive gain, best gain: -inf
[LightGBM] [Info] Trained a tree with leaves=2 and max_depth=1
...
[LightGBM] [Info] Trained a tree with leaves=2 and max_depth=1
[LightGBM] [Fatal] Tree model should contain num_leaves field.
Traceback (most recent call last):
  File "test.py", line 53, in <module>
    bst = lgb.train(param, train_data, num_boost_round=100, verbose_eval=1, valid_sets=test_data)
  File "/opt/conda/lib/python3.5/site-packages/lightgbm/engine.py", line 213, in train
    booster._load_model_from_string(booster._save_model_to_string())
  File "/opt/conda/lib/python3.5/site-packages/lightgbm/basic.py", line 1554, in _load_model_from_string
    ctypes.byref(self.handle)))
  File "/opt/conda/lib/python3.5/site-packages/lightgbm/basic.py", line 48, in _safe_call
    raise LightGBMError(_LIB.LGBM_GetLastError())
lightgbm.basic.LightGBMError: b'Tree model should contain num_leaves field.'

The problem is you are using very small data (55). you can try to set min_data=1 and min_data_in_bin=1 .

For future reference :
I had to set a higher min_sum_hessian_in_leaf (100 in my case) to have a working model.
Thank you guys to pointing me to training parameters in case of small data.


Titan: Make several options online configurable

What is changed and how it works?

Issue Number: Close #16516

What's Changed:
Making min-blob-size, blob-file-compression, blob-file-discardable-ratio online configurable.

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[x] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

we can merge this after #16460

/merge


Allow host to be dynamic in appliance builds

Builds will have no defined host and will use the host serving the application as the API_BASE.

Development uses a hardcoded URL of http://localhost:4000

:+1:

Merging since this doesn't affect the specs.


Fix Page scrolling issues, adjust width of buttons

Fixed these issues -
The additional content of the page is hidden.
The margin of the heading is way too high.
The text overflows outside the button.

PR Raised
https://github.com/jpk3lly/Boggle_Hacktoberfest2023/pull/31


How to destroy images / release memory

I'm using lwip for last few months, it works great. But the process always takes more memory. I have a app just to resize the image, and it quickly takes 600MB RAM, and its not going down on idle, calling global.gc() is also not helping.
When i open image file, the file is opened, decoded and loaded to memory. When this memory is released ? Is it managed by node's GC ? is there any way to explicitly destory the image, after processing it ? I'm can see lwip is using c/c++  libraries for processing image, definitely they may be allocating memory by malloc(), so i'm looking for explicit call to free() them.
var lwip = require('lwip');
lwip.open('image.jpg', function(err, image){
  // do some thing with image
  // then, how to destroy image ?
});

It appears that after some time images & buffers are garbage collected, I'm using LWIP as part of (high-use) image APIs and it's causing pretty crazy memory usage per process. Once I process the image and get the buffer, it's cached and I'm immediately seeking to release that memory. I'm just tacking on--expose-gc to the process and executing global.gc() within the callback of the image/batch toBuffer()


⚠ Jenkins Plugins Artifactory has degraded performance

In a3c250f, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1874 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 3d936ce.


On Infusion Stability's Stabilizers

While I haven't actually progressed far enough to try the Infusion mechanics myself, I thought the idea of having stabilizers that ran off RF was a brilliant idea. Not only did it make me feel happier with the idea of using Thaumcraft with other mods, but one of the problems I always had in older versions of Thaumcraft was the Infusion Altar always had to be on the bottom floor, to accommodate the 'candle room' below it for stability. This gave an alternative to that, and I was looking forward to ways to integrate that with my builds (I have always wanted to make an infusion altar on the top of a large tower).
I thought it might help to give this feedback given your removal / overhaul of the Infusion Stabilizers. I never liked the idea of candles being stabilizers, as a room full of candles just seems so straightforwardly exploitative of the mechanics, and also forcing me to move away from the cleaner, more modern builds I like making.

personally i hated the rf mechanic it essentially forces you to add a tech mod in to use them properly.
the candles/stabilizers are a bit overpowered a.t.m. i have mine setup to add 3.79 stability per cycle and i only have about half done of what i had originally planned .
the current alters fit much more thematically, however i do agree the candle floor is not ideal

@Aldurnamiyanrandvora I might re-invent RF powered stabilizers in my addon "Thaumic Additions" :)

A room full of candles will do very little in the current release as there are diminishing returns.
Either way, since this is not a bug report I am going to close this.


Different design to allow azure-core-test to take HttpClient dependencies

Description
Similar to https://github.com/Azure/azure-sdk-for-java/pull/41752 but instead of a new package for the shared HttpClient test code azure-core now produces a test JAR that contains this code.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

Discussed offline, but lets rename com.azure.core.test.shared to something like com.azure.shared.validation.http, to avoid confusion about what package types come from.


Add axhline, contour and spy

Summary
Add the methods

axhline (axvline already existed)
contour
spy

Also added example for contour and spy to show how to use them (and test that they work).

+1 for it

This fixes issue #234
I've replaced the current countour function in the matplotlibcpp.h header file with this version and plt::contour now works perfectly! Please merge this. @lava

There were a few merge conflicts, so I had to slightly adjust your commits while rebasing. I also removed the numpy-dependency, since contour()/spy() don't seem to do anything numpy-specific.
Thanks for contributing!


[Thirsty Sword Lesbians] New playbook, no legacy CSS, dark mode support

Changes / Comments

Added bladesoul playbook (third party)
Weaned CSS off legacy sanitization
Added support for dark mode

Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[x] Does this add functional enhancements (new features or extending existing features) ?
[x] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Fix NoBang.append for non-array iterators

Codecov Report

Merging #83 into master will increase coverage by 0.07%.
The diff coverage is 100%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 479c63e...42207e2. Read the comment docs.


Adds Gifcurry.

Project URL
https://github.com/lettier/gifcurry
https://lettier.github.io/gifcurry
Category
Graphics
Description
Adds the open source macOS app Gifcurry made with Haskell, GTK+, and GStreamer.

Why it should be included to Awesome macOS open source applications  (optional)
Why do I need Gifcurry?
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Appropriate language icon(s) added if applicable
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

:+1:

@lettier Thanks for your contribution!
We haven't Haskel icon yet. Can you please add Haskel language icon?

Updated.
:+1:

Thahk you!


Allow scaling workloads to zero

Rancher versions:
rancher/rancher: 2.0.6
Since kubernetes doesn't have the concept of "stopping" a workload, but does support scaling it to zero pods, this should be supported by rancher.
The limitation currently seems to just be implemented in the UI. Removing the "disabled" property of the minus button makes scaling to zero work without issues.
If the point if the UI limitation is to prevent accidental service downtime, there should be an option to turn this off. Alternatively rancher could pop up a warning before scaling to zero.

Submitted a pull-request https://github.com/rancher/ui/pull/2064

Version - 2.0 master 7/23
Not fixed - UI still goes back to 1 when I try to enter 0 on create/edit of workload

Version - 2.0 master 7/26
Verified fixed


wip: manifest v1 and lit 2

Fixes #61
What I Did

update most dependencies
use the types from the v1 custom-elements manifest

still some clean up work to do matching class fields to attributes

wip migration to lit 2

the directives need some attention here, I could use a hand

wip es-dev-server -> wds

If the general direction seems agreeable, let's continue
Most of the mechanical migration is done. It seems to me the last things needed are:

port the custom directive to lit 2
rework the concept of knobs to accept manifest v1

For knobs, I think probably the way to go here is to either
1. create our own modified manifest data structure when the manifest is loaded
2. separate the knobs data structure entirely from the manifest structure

closing in favour of #84


Investigate downloading partial parquet data for preview

Suggested in #6990. We should look into downloading partial parquet data for preview instead of always downloading the entire file.

This would be really helpful since in a Lakehouse architecture parquet files usually get really large.
Downloading the complete file and not just some rowgroups will take time, create unnecessary traffic and come at egress cost.
@JasonYeMSFT, any chance you will implement this? 🥺

@JasonYeMSFT, @MRayermannMSFT, @craxal, just wanted to renew my statement that this feature would be highly appreciated.
Especially in the context of Microsoft Fabric and Azure Synapse, large parquet fiels are very common. For previewing the content, it would be just fine to read and display just a small excerpt of the file.

@keen85 Thank you for the feedback. We appreciate it!
Here's an overview of the problem we face with this feature. Storage Explorer's preview is based on the principle of reading the first ~10 MiB of data from a blob and parsing that data for display. For most file formats, this is perfectly fine.
Parquet files are different, though. They are column-based, not row-based. This means, if you want to see even just one complete row, you'd have to read from essentially random locations in the file, which isn't possible when you only have the first ~10 MiB. The only way to allow random reads from the file is to download the entire file.
The alternative is to show partial rows (rows where not all the columns are downloaded). However, this likely isn't very useful for large files with many rows. Because the format is columnar, you would end up downloading only one column's worth of data for hundreds of thousands of rows, so the chances of you being able to preview the data you want is slim.

@craxal, to read a parquet file, you have to:

First read the footer (the footer length is in the 8 last byte of the file)
Analyze the footer in order to get the offset of any block
Choose a block (a raw group) (you have the info in the metadata)
Read at most a block (for example the smallest)

FYI: the default Parquet block size is 128Mb (so it should be the upper limit + footer size to read).
I agree with you: you won't visualize the data with a single read of 10Mb, but you are able to do it with several (relatively) small read (up to 128Mb + footer) which is much better than the entire file.
One other possible solution ? : use DuckDB, it perfectly does the job.

@sbarnoud can you please elaborate on your proposal using DuckDB?
Do you propose using DuckDB inside of Azure Storage Explorer to perform the preview? I'd like that!
But copying the file URL from Azure Storage Explore, opening up Azure Data Studio, writing some lines of Code, pasting in the file path and then run DuckDB can just be a workaround IMHO.

How does DuckDB solve the "don't download the entire file" problem? The issue at hand isn't really a data processing problem. It's a file format problem. And from what I'm seeing, DuckDB just takes data from a file and converts it into an SQLite database. We don't need full-fledged database structures and semantics. For this issue, we're just trying to get enough information from a file to preview it in a tabular format.

DuckDB is a C++ library running on Windows (and Linux, ...) that you can integrate in any application. It comes with the full SQL semantic on Parquet files. With the Azure extension (also a C++ library), you have the full support of the Blob storage (Native ADLS support will come later, however, I have tested it on any ADLS Gen2 files, and it works already).
So, IMO, it is not so complex to directly bind the Storage Explorer with DuckDB.
The preview, in that case, could be a free SQL command on the file.
Actually, I'm using DuckDB has a JDBC Driver in dbeaver, and from dbeaver, I can run any SQL query I want on ADLS. I use the same directly in some of my API.

DuckDB is a C++ library running on Windows (and Linux, ...) that you can integrate in any application. It comes with the full SQL semantic on Parquet files. With the Azure extension (also a C++ library), you have the full support of the Blob storage (Native ADLS support will come later, however, I have tested it on any ADLS Gen2 files, and it works already).
So, IMO, it is not so complex to directly bind the Storage Explorer with DuckDB.
The preview, in that case, could be a free SQL command on the file.
Actually, I'm using DuckDB has a JDBC Driver in dbeaver, and from dbeaver, I can run any SQL query I want on ADLS. I use the same directly in some of


How to Fix: TypeError: 'int' object is not subscriptable

In cellpose my figure is showing up blank and not doing any masks or segmentations, it returns this TypeError: 'int' object is not subscriptable flagging the following code:

TypeError                                 Traceback (most recent call last)
 in ()
----> 1 plot.show_segmentation (fig, imgs[idx], maski, flowi, channels=channels[idx])
1 frames
/usr/local/lib/python3.7/dist-packages/cellpose/plot.py in image_to_rgb(img0, channels)
169     if img.shape[0]<5:
170         img = np.transpose(img, (1,2,0))
--> 171     if channels[0]==0:
172         img = img.mean(axis=-1)[:,:,np.newaxis]
173     for i in range(img.shape[-1]):
I'm wondering if anyone can please help me figure out how to make it so the program recognizes the function and will display the image? Thank you so much for any and all help, I appreciate it a lot!
Warm Wishes and Many Thanks!

hey @sdand318 it looks like you are giving channels as an integer instead of a list, see the documentation here: https://cellpose.readthedocs.io/en/latest/settings.html#channels
closing issue but let me know if it doesn't work


toArray returns array with null element

Dexie 3.2.7
Given the following code:
        dexie.queue
            .where('userId').equals(authenticatedUserId)
            .limit(100)
            .toArray().then((entries) => entries.map(({id, action, timestamp, resourceTableName}) => ({
                id: id ?? -1,
                action,
                timestamp,
                resourceTableName
            })))

I get the following error (only for one user, for everyone else it works perfectly fine)
TypeError: Cannot destructure property 'id' of 'e' as it is null.

(The build process moves the destructuring assignment to the function body, replacing the function params with an object called e)
So that means the array entries is [null], But I have trouble reproducing this as dexie won't let me insert null items into the queue table. How can this happen, and how do I get rid of these null items?

It is possible to insert null values into indexedDB but they would never be returned when querying on an index like this code shows. I would say that it is impossible that this could happen unless there would be a bug in the indexedDB implementation that I never heard of. Are you sure the error comes from this part of the code?

Yeah, similar code* is present in some other parts of the application and the stacktraces all point to either the destructuring of the null entry or accessing the id property on a null entry.

one being for example the same query, but using forEach instead of toArray

The fact that it crashes isn't really a big issue to me, but I would need to somehow remove the null entries from the table as I also got a count on that and it's (probably?) being inflated, messing up quite a bit of logic. Removing the table itself and re-creating it is not an option as this is essentially the only table that is critical in our entire application >.<

I think..... this should work to clear out the queue table. right?
        while ((entry = await dexie.queue
            .where(['userId', 'timestamp'])
            .between([userId, minKey], [userId, maxKey], true, true)
            .first()) !== undefined
        ) {
            if (entry === null) {
                captureException(new Error('Encountered null entry in queue during upload'));
                await dexie.queue
                    .where(['userId', 'timestamp'])
                    .between([userId, minKey], [userId, maxKey], true, true)
                    .limit(1)
                    .modify((value, ref) => {
                        if (value === null) { // Just to be absolutely sure that we're never deleting customer data
                            delete (ref as Partial<{value: QueueEntry;}>).value;
                        }
                    });
                continue;
            }
            // actual logic with entry

Yes, but I'm still confused that a null entry could get there. Is the query performed in a liveQuery() If so, this could indicate a bug in Dexie's cache (which is only active in liveQuery contexts) - and if that would be the case, removing the null entries wouldn't lead anywhere. A better workaround if so, would be to filter them out from the result.
In the case of indexeddb bug, the code you show should delete the entry.

The place where we show a count of entries in the queue relies on dexie-observable with a simple count, so it doesn't crash on this as the entries themselves aren't used. The part I just showed you is executed onClick.
I'll report back once I know more :-)


Bump version to 4.13

Ref. https://issues.redhat.com/browse/ART-5087

/lgtm
/approve

/assign @romanbednar

/approve

/lgtm
/label docs-approved
/label px-approved
Adding docs and px labels - this is not a user facing change.

@RomanBednar PR is still missing qe-approved label. As an alternative, how could I get the bugzilla/valid-bug instead?

Turns out we just got a bug filed, so let's use this one:
/retitle OCPBUGS-4535: Bump version to 4.13

@locriandev with the bug being added and linked it should be ok to merge this now.

It should merge in a moment, or after the retest completes I guess.
Also in the future I think it's fine to add qe-approved ourselves for release chores like this that are not being pre-merge tested.


Fix #1273 AsyncMethodsRateLimiter does not handle ratelimitted errors properly

This pull request resolves #1273 ; Only the AsyncMethodsClient has been having this bug, so we don't need to make similar changes to SCIM/SCIMv2/Audit Logs API clients.
Category (place an x in each of the [ ])

[ ] bolt (Bolt for Java)
[ ] bolt-{sub modules} (Bolt for Java - optional modules)
[x] slack-api-client (Slack API Clients)
[ ] slack-api-model (Slack API Data Models)
[ ] slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
[ ] slack-app-backend (The primitive layer of Bolt for Java)

Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.

Thanks for making this fix @seratch !
I'm probably missing something, but in this block in AsyncRateLimitExecutore.enqueueThenRun:
if (e.getResponse().code() == 429) {

does setRateLimitedMethodRetryEpochMillis need to called similarly to what is in MethodsClientImpl.postFormWithTokenAndParseResponse?

Thanks for the comment. I thought so too when I checked this issue, but actually it is not necessary. I found that the only changes needed for fixing this issue is the correction in AsyncMethodsRateLimiter. In rate-limited error scenario, setRateLimitedMethodRetryEpochMillis method call is done in the underlying MethodsClient side, so all the things async side should do is just to check the existence of the rate limited state of the API method.

Nice. Thanks for confirming and thanks again for the fix!


git-hooks is down

I can't find the original git-hooks repo by icefox anymore.
I did find a fork by git-hooks.

fixed by removing git-hooks

fixed by removing git-hooks


[FLINK-6435] [async] React to exceptionally completed StreamElementQueueEntry

The AsyncWaitOperator should not only react to orderly completed
StreamElementQueueEntries but also to those completed with a user exception
or those which timed out.
This PR fixes the problem by calling the onComplete function passed to
StreamElementQueueEntry#onComplete also in the exceptional case.

Merging this PR.


Support files added

Added cmd file for build support
Added nuspec for the nuGet package creation

@leigh-pointer do you think the the cmd and nuspec files should be in the Oqtane.Client folder? When I created then yesterday for de-DE I put them in the Resources folder ( with all of the paths relative to that folder ). My thought was that when someone copied the contents of the Resources folder to their Oqtane framework instance it would include these files to make it simpler to generate the nupkg.

@sbwalker I cant see there being an issue and if you are to put them somewhere it is a good a place as any.  My only concern is that the SharedResources.resx files get maintained in the Resources folder.

@leigh-pointer I am trying to make the instructions more clear for people who want to use the translations - does this diagram make sense:
https://github.com/oqtane/oqtane.translations/blob/main/README.md

@sbwalker I think it is clear enough. The diagram makes is clear by example, which is always good.


Provide more definitive guidance on GeoIP lookup from Application Insights

It would be useful to provide our customers that make use of GeoIP lookups some more definitive information regarding our offering in this area.
Currently, we simply state that GeoIP might not be complete/reliable, but really what we might want to say is something far more clear such as:

"We will do our best to provide GeoIP location but we provide this service as a convenience to our users and not as a core feature. If you have high- fidelity and reliability needs concerning GeoIP, please visit our partner add a link to partner providing GeoIP services and employ Telemetry Initializers as necessary in your solution to resolve this as your application would require."

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

ID: 2c8adb27-7386-3e7a-7c8f-324a5206db0d
Version Independent ID: cc276f0a-5ddd-bcb5-8261-7c4bed92454c
Content: Monitor a live ASP.NET web app with Azure Application Insights
Content Source: articles/application-insights/app-insights-monitor-performance-live-website-now.md
Service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@d3r3kk Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@d3r3kk Can you provide a link to the article/paragraph you want updated. The issue is currently pointing to the doc that mainly talks about Status Monitor and I am not finding references to GeoIP and location reliability. We currently mention/link to GeoLite2 in 3 of the App Insights docs, but I agree if we are talking about reliability of location based tracking elsewhere in the docset we should include similar references/info.

I guess what I was asking was I wasn't sure what you were referencing with: Currently, we simply state that GeoIP might not be complete/reliable I was unable to find that language in the official docs. Or are you referring to the link to the apmtips post?

But I am happy to dig in with Sergey or Dmitry and add on to this doc. (And a correction to my previous statement there are only two references to geolite2. The reference you found, and a brief one line ref in the data retention article. So there is definitely room to expand and add detail for interested customers who want to know how it works.

@mrbullwinkle This can likely be closed due to inactivity?

I'd say that if you haven't gotten any extra votes (the thumbs-up thing, or +1, or otherwise) on the issue it's not a high priority, at least at the moment.
I'd say close it out and if it comes up again deal with it then.

@d3r3kk Sounds good, thanks again!

@MicrosoftDocs/azure-cxp-triage #please-close


Add more Differential tests

@jjx

@jjx i am going to self-merge given how trivial this is. speak now...


Update Flow diagram on stateful-elastigroup-flow.md

What would you like to be added?
The image used by src/docs/elastigroup/features/stateful-instance/stateful-elastigroup-flow.md does not include any information on how the IP is persisted (i.e. the shouldPersistPrivateIp option).
Why is this needed?
The image as it is does not show the whole process.

the image is src/docs/elastigroup/_media/stateful-process-flow.png


more concise, increased clarity

@Houndsong : Thanks for your contribution! The author, @MikeRayMSFT, has been notified to review your proposed change.

@Houndsong - thank you for your contribution. #sign-off


Suggested revision of

Preface:
As the MEI header has become more commonly adapted to the creation of catalogs or metadata focused applications separate from files of MEI music notation encoding we see a problem with a dual interpretation of the element sourceDesc
The two roles can be summarized as follows:

The original intent of sourceDesc was to identify materials used to created digital music notation. This usage does not require a physical description of a specific document (FRBR Item), rather only a bibliographic identification. With this intent in mind, it makes sense to locate the element as part of the fileDesc element

The evolving use of sourceDesc is not linked to music notation necessarily, but mostly a physical description of a specific source/document. It may involve a very detailed physical and (and possibly other aspects) description. This use of sourceDesc would apply to a collection catalog. Maybe it would also apply to thematic catalog but the descriptive elements would be more selectively applied.

Suggested solutions:

Change the name of sourceDesc in the fileDesc to sourceIdentifer

Create a new level in the MEI Header titled sourceDesc independent of both fileDesc and workDesc. In this new level develop and refine elements that could be used to describe a physical document (independent of the abstract work described in workDesc.)

Place the new sourceDesc category after workDesc in the MEI hierarchy. In this sense the newsourceDesc will correspond with the "Item" level of a FRBR description. Manuscript sources will be unique by definition, and detailed descriptions of specific print sources would also be unique and correspond with "Item" in the FRBR hierarchy. This new use of sourceDesc might require some rethinking of @analog to describe FRBR relationships.

We further suggest that revisionDesc should be relocated as a sub-element of fileDesc because it is intended to describe revisions to MEI code, not musical revisions in a specific document. It would also be good to rename the current revisionDesc to codeRevisionDesc in order to avoid any confusion with a future use of revisionDesc in the new category of sourceDesc

I've tried to tackle this huge issue a couple of times now… but still don't manage to address everything. Something that might be connected to this is #61

I wonder if this issues might also be related indirectly to Dennis Reid's post to the MEI list on December 1st. At least in principle it seems wrong to use the current sourceDesc for the creation of catalogs because the creation of a catalog requires much more flexibility in describing sources than was ever intended for the simple identification of the source used to create an encoded notation file. The creation of a separate sourceDesc intended specifically for describing sources in different kinds of catalogs seems to be a necessity.

<sourceDesc> need not be limited to the sources actually used in the creation of the file -- one could think of it as a container for description of source material generally.  The actual sources employed as witnesses are/should be identified using @source on <lem> or <rdg>.

I agree that <sourceDesc> (as child of <fileDesc>) should be limited to the "sources actually used in the creation of the file". But we have to acknowledge the fact, that there are many use cases where no 'file' (in the sense of coded music) is created, mainly work catalog entries and stand-alone source descriptions that rely on the MEI header by itself.
I do not think that a seperate <sourceDesc> "intended specifically for describing sources" should be created; it's up to the user how simple or how deep he/she wants to describe the sources. But in order to reconcile the various use cases the current <sourceDesc> could be moved out of the <fileDesc> and hierarchically coordinated with <fileDesc> and <workDesc> where it may receive additional features in order to make it more flexible.
Within the <filesDesc> a <sourceIdentifier> as suggested in @BruxDDay's original proposal could be used as pointer to the corresponding item in the <sourceDesc>.

@ndubo, I see the logic in the approach, I'm just trying to find the best path.
We need to maintain backward compatibility as much as possible, which would suggest leaving <sourceDesc> in place to hold descriptions of the "sources used in the creation of the file" while also allowing it to use its @target attribute to point into a catalog of a more comprehensive nature.  This would not only maintain compatibility, but let those who want to describe the source material "in place" to continue to do so while also accommodating those want to use a pointer instead.
The target of the pointer could reside within a new <workList> or <workCatalog> element.  This element can take over the descriptive functions now covered by the combination of <work>, <expression>, <source>, and <item>.   <workList> can be allowed to be a document-level element so that catalogs may be placed in external files.   In fact, it could be a new, ancillary MEI document type; i.e., it wouldn't occur in the header at all, making for a cleaner separation between metadata for the current encoding (captured within <meiHead>) and an independent work list/catalog.

I like this approach. The ability to create a catalog as a separate MEI document type suggests to me greater freedom in creating and managing different elements and attributes for advanced description of rare and manuscript sources (if needed). This approach should also maintain backward compatibility, which I recognize is very important. I am assuming that within a new <workList> document it would still be possible to use all the MEI notation features for creation of incipits. I am also thinking that the FRBR elements may still play a role in a separate <workList> document, depending on the nature of the list or catalog. Are these two assumptions correct?

I understand the logic and appeal of sth. like <workList> or <workCatalog> but from my perspective, proposing a model for cataloging is not what MEI is really about. Our focus should rather be how to use MEI encoded information in accordance with catalogs. I bet there are many models for catalogs out there somewhere, and of course a format for cataloging should not "be limited" to music.
The approaches I encountered in various music edition projects (in which a catalog of works, sources, or other material is of course an intended output) was rather on a file-per-object basis (with an object being something that would be defined by the project).
Having consumed FRBR to some degree (and of course in the general light of semantic web) and of course taking in @pe-ro concern of backwards compatibility, a good approach should allow both:

handling all there is to say about the work, source, musical text in one comprehensive file (see above comments)
having separate files for each defined entity (see below)

entity based MEI
The Edirom Online software for example has a couple of files when encoding a music edition:
a) an edition.xml (custom schema non MEI)
b) a work.xml (MEI, describing frbr:work- and grbr:expression-level metadata and including the edition's critical notes)
c) any number of source.xml files describing fror:manifestation- and fror:item-level metadata
Nevertheless this approach is not fully modelled to all extents as the development approach of Edirom generally is to allow any kind of MEI and not to specify how and where to encode what information.
This approach could be extended to some merit by having separate files for the primary for-entities:

frbr:work.xml
frbr:expression.xml
frbr:manifestation.xml
frbr:item.xml

Doing so would also allow a better granularity in data exchange e.g. with memory institutions like libraries or authority file providers. While four my perspective a all-in-one file approach would not!
conclusion
Generating a work catalog on the basis of such a data-set would be a higher-level operation that, yes could be done in MEI e.g. using <meiCorpus> or rather any combination of presentation-layer query language an markup language to render some nice web or print output.
So it's -1 for <workCatalog> from me.
And -1 for <workList>. Though it could be interesting in describing a source's contents this can be handled be frbr:relations, already.

Hi all,
Like Benni, I'm reluctant to go there with MEI itself. For me, this sounds more like another MEI profile for a specific use case, but not like a new model within MEI. FRBR is extremely helpful in an editorial context, and we shouldn't give that one up in order to simplify handling of catalogues. Let's revise the problems that have been raised:

//meiHead/workDesc vs. //meiHead/fileDesc/sourceDesc seems imbalanced from a FRBR perspective
//sourceDesc serves a double purpose (specify the materials used in preparation of the file vs. frbr:manifestion)

To be honest, both aspects are no showstoppers for MEI, and better documentation seems to be a potential solution – not necessarily the best, but also not the worst. If we take backwards-compatibility as an argument, it's hard to get any better, though ;-)
But let's have a closer look. The main problem of 2) is that we're mixing two different meaning of "source". In the original meaning, this was intended to describe both editorially relevant prints or manuscripts, but also the arbitrary Finale or MusicXML file that was used on the way towards MEI. This particular meaning isn't covered by a common understanding of FRBR, and indeed it seems to be sensible to not conflate that in an MEI file with contents we put under the frbr:manifestation hat. From within an //app/rdg/@source, we surely wouldn't point to the description of a Finale file, but only to manuscripts etc. I suspect that the latter is the most common use of mei:source anyway, with only very few exceptions.
What I could imagine is to promote the current /sourceDesc up to be a direct child of /meiHead. In it's current place, we could introduce a new element <fileSource>, which would get a stripped down version of the existing <source>. (Of course the name is just a straw man, and we need a container as well…). For manuscript sources, we could introduce a standardised pointer to a separate <source> element in the FRBR sense, where all the bibliographic details and the description of this print (etc.) could live (maybe using a <sourceIdentifier> as proposed by @BruxDDay, maybe using an attribute). That way, the fileSource element would just say that this source was used to prepare the file, but other sources might be described as well.
I am fully aware that this

causes a certain markup overhead
isn't fully backwards compatible (though it should be fine to convert most existing files into this new model in a straight-forward way)
seems to focus on music content (if encoding a catalogue only, one could assume that there has to be a fileSource for every source anyway)

However, I see the following benefits:

It becomes possible to use the existing meiHead start element for catalogue files without introducing a new, separate model
The new model makes no difference between catalogues, editions, or other use cases of MEI, providing the same possibilities in all situations
This should simplify interchange between different use cases for or profiles of MEI
It focusses on a separation of the current double meaning of source (number 2) above), and addresses 1) at the same time

I think we should seek a solution that introduces only changes that are really necessary, and are justifiable for all different use cases of MEI.

Am 06.12.2017 um 22:25 schrieb Benjamin W. Bohl<EMAIL_ADDRESS>I understand the logic and appeal of sth. like  or  but from my perspective, proposing a model for cataloging is not what MEI is really about. Our focus should rather be how to use MEI encoded information in accordance with catalogs. I bet there are many models for catalogs out there somewhere, and of course a format for cataloging should not "be limited" to music.
The approaches I encountered in various music edition projects (in which a catalog of works, sources, or other material is of course an intended output) was rather on a file-per-object basis (with an object being something that would be defined by the project).
Having consumed FRBR to some degree (and of course in the general light of semantic web) and of course taking in @pe-ro concern of backwards compatibility, a good approach should allow both:
• handling all there is to say about the work, source, musical text in one comprehensive file (see above comments)
• having separate files for each defined entity (see below)
entity based MEI
The Edirom Online software for example has a couple of files when encoding a music edition:
a) an edition.xml (custom schema non MEI)
b) a work.xml (MEI, describing frbr:work- and grbr:expression-level metadata and including the edition's critical notes)
c) any number of source.xml files describing fror:manifestation- and fror:item-level metadata
Nevertheless this approach is not fully modelled to all extents as the development approach of Edirom generally is to allow any kind of MEI and not to specify how and where to encode what information.
This approach could be extended to some merit by having separate files for the primary for-entities:
• frbr:work.xml
• frbr:expression.xml
• frbr:manifestation.xml
• frbr:item.xml
Doing so would also allow a better granularity in data exchange e.g. with memory institutions like libraries or authority file providers. While four my perspective a all-in-one file approach would not!
conclusion
Generating a work catalog on the basis of such a data-set would be a higher-level operation that, yes could be done in MEI e.g. using  or rather any combination of presentation-layer query language an markup language to render some nice web or print output.
So it's -1 for  from me.
And -1 for . Though it could be interesting in describing a source's contents this can be handled be frbr:relations, already.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@bwbohl 's suggestion that MEI is not primarily about catalogs, but rather music notation is well taken. However, MEI is being used quite extensively for catalogs, especially thematic catalogs and catalogs of closed discrete collections that require or merit advanced descriptions. From that perspective it is important to ensure that when MEI is used for cataloging it is accommodating to the needs of specialized catalogs. The MEI use for catalogs should not be a secondary consideration. The ability to describe a rare edition or manuscript in great detail is one of the persuasive arguments for using MEI rather than MARC. Admittedly TEI also has the ability to handle advanced descriptions, but because incipits are often very important components of such catalogs, why not stay within MEI?
Could I ask for some friendly clarification on what is meant by the creation of a catalog on a file-per-item basis? Does this mean as outlined in the Edirom Edition example that separate files be created for each FRBR level of a catalog? I am not sure I follow the logic of creating separate XML files for one catalog. Please help me better understand your point.

@BruxDDay I absolutely with you that

The MEI use for catalogs should not be a secondary consideration

And I never intended to be understood else!

some friendly clarification on what is meant by the creation of a catalog on a file-per-itemobject basis

I just called it this way, as I had no better term for it ;-) An yes you're absolutely right, the idea behind it is creating separate files for the objects (items, entries, name it…) of one catalog. In fact, when looking at a catalog in a more abstract way, it could be seen as a (curated) data collection! This makes it comparable to a database (having defined fields for each object/item). The fact that it might be printed or available in digital form is nothing more than a form of manifestation.
Let's imagine you have a printed catalog and want to create a web-version of it. You could follow two strategies:

a) sit down, create a (single) file in your computer program, open the book, turn to page one, and transcribe, and transcribe, and transcribe all the details the catalog provides on each item into one file. The growth of you data would be slow in terms of width (items covered) but constantly high in terms of depth (detail of the items' description). Your data will be usable when you've finished transcribing.

b) sit down, cut the book into pieces corresponding to the single items, cut the items into more pieces and put those on piles ordered by level of detail – ranging from general info e.g. work title, composer, etc. to very special information e.g. critical notes from an edition. Now you pick the "general information pile" containing all the general information of all items covered, create a file and transcribe the general information of item one, then create a file and transcribe the general information of item two, … The growth of your data would now be fast in terms of width (items covered) and constantly slow in terms of depth (detail). But your data will achieve an early stage of low detail completeness, allowing for first usage of the data.

Why separate files? Their changes can be controlled more easily and a change on one file would reflect a change on one item. While a change on your huge file would reflect a change on any one item in the catalog or on several.

From my perspective, this aspect is surely interesting, but a separate issue. MEI utilises the anyURI datatype, so it is equally possible to put everything into one file or split it up into separate files for each FRBR entity. The only missing thing here would be to allow , ,  and  as start elements, but again, that seems to be a separate discussion. I think we should leave it to individual projects to decide what approach is more practical to them. MEI should have a way to keep everything in one file, and be it only for better interchange or archiving purposes. As I mentioned in Mainz, for me the boundaries between data and metadata are increasingly blurred, and I believe that this is a good thing, as it (potentially) combines the strengths of both worlds. Admittedly, this requires good guidance, but this is what this discussion is about, right?

Am 07.12.2017 um 10:06 schrieb Benjamin W. Bohl<EMAIL_ADDRESS>@BruxDDay I absolutely with you that
The MEI use for catalogs should not be a secondary consideration
And I never intended to be understood else!
some friendly clarification on what is meant by the creation of a catalog on a file-per-itemobject basis
I just called it this way, as I had no better term for it ;-) An yes you're absolutely right, the idea behind it is creating separate files for the objects (items, entries, name it…) of one catalog. In fact, when looking at a catalog in a more abstract way, it could be seen as a (curated) data collection! This makes it comparable to a database (having defined fields for each object/item). The fact that it might be printed or available in digital form is nothing more than a form of manifestation.
Let's imagine you have a printed catalog and want to create a web-version of it. You could follow two strategies:
• a) sit down, create a (single) file in your computer program, open the book, turn to page one, and transcribe, and transcribe, and transcribe all the details the catalog provides on each item into one file. The growth of you data would be slow in terms of width (items covered) but constantly high in terms of depth (detail of the items' description). Your data will be usable when you've finished transcribing.
• b) sit down, cut the book into pieces corresponding to the single items, cut the items into more pieces and put those on piles ordered by level of detail – ranging from general info e.g. work title, composer, etc. to very special information e.g. critical notes from an edition. Now you pick the "general information pile" containing all the general information of all items covered, create a file and transcribe the general information of item one, then create a file and transcribe the general information of item two, … The growth of your data would now be fast in terms of width (items covered) and constantly slow in terms of depth (detail). But your data will achieve an early stage of low detail completeness, allowing for first usage of the data.
Why separate files? Their changes can be controlled more easily and a change on one file would reflect a change on one item. While a change on your huge file would reflect a change on any one item in the catalog or on several.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@BruxDDay, both your assumptions are correct -- Existing features of MEI, such as <incip>, would be available within <workList>.  Also, <workList> would make use of FRBR, though its use wouldn't be required.

@axgeertinger expertly articulates our common goals.  I'm simply looking for a more efficient, better all-around methodology for achieving them.
The amount of change brought about by this proposal is minimal.  The number of changes to the schema is comparable to those suggested by @kepper.  I believe, however, that the <workList> approach does a better job of cleaning up the current confusion over <source> while also providing a convenient way to separate in-depth from light-weight metadata when that's desirable.
<workList> is intended to be a refinement of <workDesc>, which already allows for the description of multiple works.  No encoding options would be lost, only moved.  That is, the data found in <source> would also be allowed within <work>, although likely renamed to <manifestation>.  This will make it possible to encapsulate the WEMI (work, expression, manifestation, item) description within <work> for those who desire to follow this approach.  <source> will retain its current content model to satisfy backward compatibility and simple use cases, but can also be used to reference data captured in <manifestation> to avoid duplication.
<workList> will be allowed to be a document element for those cases where it makes sense not to duplicate the WEMI information across multiple encodings.  Something like this capability has always been possible using XInclude, but under this plan a separate workList file could be validated independently of the file into which it's included.
Since <work>, <expression>, <source>, and <item> will retain their current child elements, the level of cataloging detail will remain the same and still be variable according to local needs.
<work> already allows <incip>, which may in turn contain an MEI-encoded incipit, one in another encoding scheme, or a pointer to a graphic, so no stumbling blocks are introduced by this proposal with regard to plans for the Nielsen catalog or any other.  I've long held that it would be beneficial to provide an XPath-based pointing mechanism on/within <incip> to allow it to identify an excerpt within the transcription.  Even so, the presence or function of <incip> has very little to do with the current proposal.
Early next week, I plan to provide an ODD customization implementing the proposed changes so that the discussion can become more concrete than theoretical. 😀

as the entire music would also be encoded, the user could read through the rest of the score as well. Would that be a catalog or an edition?

In my opinion, it's both.  But in reaching for that outcome, we shouldn't limit the possibility of separation of these two options.  One should be able to use MEI to encode an edition or a catalog as necessary without combining them.


containerised applications do not survive a camera restart

Describe the feature
Less a feature and more a requisite for production usage. Should anyone use the  contianer-example pattern they will encounter an issue whereby if their camera is either gracefully restarted or externally rebooted the containers do not respawn.
The root cause of the issue is that the paths which are recreated in the parent namespace are not removed prior to dockerd starting, resulting in the inability to create containers under /run/container in the user namespace.
You can see the dockerd-rootless.sh solves this by deleting the necessary paths  so dockerd/rootlesskit can administrate these appropriately https://github.com/moby/moby/blob/4318ab0b33888d155abea0366d9c066dad46cf6c/contrib/dockerd-rootless.sh#L144
Added value
Any body availing of containerised applications which are managed by the runtime itself and not restarted externally will need this in order to have stable fault tolerant workloads.
Additional context
N/A

Hi @fire-ant , Thank you for the feedback. We will investigate this.

This issue is fixed in AXIS OS LTS 2024 11.11 from 11.11.109. Upcoming AXIS OS 12 will also have the fix.


rexray: upgrade to v0.11.1 [Backport to 1.11]

Backport of https://github.com/dcos/dcos/pull/2882 to 1.11. Contains unit file backport of https://github.com/dcos/dcos/pull/2593/commits/0b66b574f27005c41b5eaeb2b6f2261d6b575113#diff-b4738aec95eb5d18a80de948ec4ce039R16, too._
High-level description
What features does this change enable? What bugs does this change fix?
This PR bumps REX-Ray from v0.9.0 to v0.11.1. It configures REX-Ray to operate in DOCKER_LEGACY mode as the newer version of REX-Ray switched to CSI-based logic. The REX-Ray developers seem to agree as REX-Ray's master branch was recently switched to DOCKER_LEGACY by default: https://github.com/rexray/rexray/commit/6162a4c0a35255414e0fb82e18a8ed44800d5749.
This PR also improves the delete_ec2_volume.py cleanup script by adding logging and better error handling.
Corresponding DC/OS tickets (obligatory)
These DC/OS JIRA ticket(s) must be updated (ideally closed) in the moment this PR lands:

DCOS_OSS-3597 Upgrade REX-Ray to v0.11.1

Related tickets (optional)
Other tickets related to this change:

DCOS-37441 Triage integration test failures for REX-Ray upgrade
DCOS_OSS-2310 REX-Ray integration test is flaky after version bump

Checklist for all PRs

[x] Added a comprehensible changelog entry to CHANGES.md or explain why this is not a user-facing change:
[x] Included a test which will fail if code is reverted but test is not. If there is no test please explain here: This bump was designed to introduce no new test or flakiness. Existing tests should keep working at their current level of flakiness (sad).
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Change log from the last version integrated (this should be a link to commits for easy verification and review): rexray
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

This repo has @mesosphere-mergebot integration. You can interact with the following commands.
@mesosphere-mergebot override-status
@mesosphere-mergebot merge-it
@mesosphere-mergebot label [Ready For Review |Holding |Request For Comment |Ship It |Work In Progress]
@mesosphere-mergebot bump-ee

PR creators can apply one of  [Ready For Review |Work In Progress]. Owners can apply any label.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

Your pull request's branch is not based on the most recent version of 1.11. Please rebase your changes against this repo's 1.11 branch.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label Ready For Review

@mesosphere-mergebot bump-ee

Your pull request's branch is not based on the most recent version of 1.11. Please rebase your changes against this repo's 1.11 branch.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@orsenthil any idea why there aren't any 1.11 trains? What do you think about sending all mergebot logs to a dedicated #mergebot slack channel so we can help debug by ourselves?


__set in \App\Entities\Sample doesnt works

I'm trying to use Entities.
In my model SampleModel.php I've got:
    protected $table = 't_sample';
    protected $primaryKey = 'smp_id';
    protected $returnType = '\App\Entities\Sample';

    protected $allowedFields = [
        'all_fields_from_t_sample... without id ;)'
    ];

and in Entity Sample.php
<?php

namespace App\Entities;

class Sample
{
    protected $all_fields_1;
    protected $all_fields_2;
    protected $all_fields_3; ...

    public function __get($key)
    {...}

    public function __set($key, $value)
    {
                ddd($this->$key);
        if (isset($this->$key))
        {
            if($key == 'all_fields_1') {
                $this->$key = sthdifferent;
            }
            else
                $this->$key = $value;
        }
    }
}

but that __set is never used by BASEPATH.'Model.php'.
I can also define __set in my SampleModel instead  od Entity which called Sample... but why?
And why when I change method __set in SampleModel like that:
    public function __set($key, $value)
    {
        d($key, $value);
}

it prints only salt and their value ?
Is it a bug?

Ok that issue is in documentation :).
https://bcit-ci.github.io/CodeIgniter4/database/model.html
instead of: class Job shoud beclass Job extends \CodeIgniter\Entity
instead of
`public function __get($key)
{
if (isset($this->$key))
{
return $this->$key;
}
}
    public function __set($key, $value)
    {
            if (isset($this->$key))
            {
                    $this->$key = $value;
            }
    }`

should be:
`public function __get(string $key)
{
if (isset($this->$key))
{
return $this->$key;
}
}
    public function __set(string $key, $value = null)
    {
            if (isset($this->$key))
            {
                    $this->$key = $value;
            }
    }`

Good catch. The Entity class didn't exist when those docs were written up. I'll need to adjust those now.
However, there are docs for the Entity class, but it looks like they're not showing up in the index. You can find them, here, though.


Adding link to changelog

I'm not really sure how to format this, but I hit the main landing README and saw it barren when I was looking for changelogs. I had to get help to find them, which makes me think there should be more links to them.

I will update it, and also include a link to https://docs.k8s-at-home.com/

updated! thanks


CkPicture not disposed

Steps to reproduce

Run sample in web
Observe log with leaks
CkPicture leaks have no detailed/retaining path

This leak only applies to the web platform. Tried to check the phases to see if there was already an issue for this but couldn't find it.
cc @polina-c
Expected results
CkPicture doesn't leak when new frames are pumped.
Actual results
CkPicture leaks frequently, likely due to new frames as they won't leak without new frames. (sample uses CircularProgressIndicator to constantly request new frames).
Code sample
Code sample
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:leak_tracker/leak_tracker.dart';

void main() {
  LeakTracking.start(
    config: const LeakTrackingConfig(onLeaks: _onLeaks),
  );

  FlutterMemoryAllocations.instance.addListener(
    (event) => LeakTracking.dispatchObjectEvent(event.toMap()),
  );

  runApp(
    const MaterialApp(
      home: Center(
        child: CircularProgressIndicator(),
      ),
    ),
  );
}

Future<void> _onLeaks(LeakSummary summary) async {
  final leaks = await LeakTracking.collectLeaks();
  for (final leak in leaks.all) {
    print(leak.toYaml('', phasesAreTests: false));
  }
}

Screenshots or Video
No response
Logs
Logs
CkPicture:
  identityHashCode: 599787274
...
leak_tracker: 262 memory leak(s): not disposed: 262, not GCed: 0, GCed late: 0

Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel master, 3.19.0-9.0.pre.204, on Microsoft Windows [Version 10.0.19044.3803], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.3.5)
[√] Android Studio (version 2021.3)
[√] VS Code (version 1.85.2)
[√] Connected device (3 available)
[√] Network resources

Steps to repro use leak tracker not in a way that is not currently tested and recommended. Can you create a widget test using this guidance and check if leaks are still detected: https://github.com/dart-lang/leak_tracker/blob/main/doc/leak_tracking/DETECT.md#test-cover-with-testwidgets

Yep, I figured it was pre-emptive, I was using the live detector to locate and fix some other leaks and noticed this one likely coming from the framework. I can try to repro with testWidgets, but it says in that document you linked that web platform isn't supported yet - should I wait then? Since this leak was only observed on web. Thanks for all your great work on this!

Then I suggest instead of using leak tracker (that does not support both web apps and running app), just to add temporary counting for CkPicture in your local copy: increase global counter in constructor and decrease it in dispose. It will give you idea how many of them are created and not disposed. How does it sound?


[Feature] Compatibility with CHANGES file

@colleenjg has been pushing forward some changes to DANDI that allow attachment of a changelog for mutliple version releases
On top of the dandiset-level view through neurosift possible from #104, it would be great if neurosift could actively render the text of these files (all I can do on the dandi side is download the file, which seems silly for a 400 byte file)
https://dandiarchive.org/dandiset/000037/0.240209.1623/files?location= is the first example of this (scroll down to bottom; see the CHANGES file), though I will likely make more personal use of it from now on as well

Yes, I agree! Thanks for pointing that out @CodyCBakerPhD

Cool. So I'd look for an asset named "CHANGES" and display the contents?

Yep; pretty easy ^.^

How's this?
https://flatironinstitute.github.io/neurosift/?p=/dandiset&dandisetId=000037&dandisetVersion=0.240209.1623
Scroll to the bottom

Beautiful ❤


Add norwegian bank registry

This PR adds a script to generate a bank registry for Norwegian banks. It uses the official source, available at https://www.bits.no/document/iban/
Relevant links: https://bits.no/en/iban

Does this PR look ok, or is there something else I need to do? We rely on this functionality, so it would be great if it could be accepted, or let me know what I need to do to make it so :)

Hej @ezet! Sorry that I didn't get back to you earlier, and thank you very for your pull request. I will merge it right away and create a release with the change included.

Great, thanks 🚀


Add api session rate limiter

Clients can render the system unusable if they flood it with authentication requests. Introduce a rate limiter to make sure that we degrade more gracefully under that kind of load.

Test setup:

100 max window size
5 min window size
250ms delay in api session create to simulate DB load
100 goroutines, each with separate SDK Context
each goroutine retrying as fast as possible to get 10 successful authentications

Succeeded with 1411642 requests rejected by rate limiter and 1071 api sessions created (so 71 extra, where the response write failed).


fix interleave table id bug

I found a MML compiler bug.
Invalid size error occurs when wave/table ID is not continuous number.
The following is test MML:
#TITLE <test>
#CHANNEL 1

#WAV 0,<(0,127),32>
#WAV 2,<(60,60),16,(-60,-60),16>

#TABLE 0,<(127,-128),16>
#TABLE 2,<(127,127),16,(-128,-128),16>

#A %4 v10 @0 na0,1 cde @2 na2,1 fga

Thanks, and sorry for taking a long time to pull this request.
I should write a document about data format so that I can remember quickly :)


Fixes 3231: remove non-UTF8 chars from introspection error

Summary
When introspecting, certain error messages may contain non-UTF8 characters. The database doesn't like non-UTF8 characters. This removes those characters before the error messages are inserted into the database.
Testing steps

Assuming this yummy PR is not integrated into the backend, introspect this repository: https://fixtures.pulpproject.org/rpm-pkglists-updateinfo/
Without this PR you will get the error: "invalid byte sequence for encoding "UTF8": 0xf4 0x62 0x20 0x28 (SQLSTATE 22021)"
With this PR, you should get no error

Checklist

[x] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

/retest

tested functionality and no longer seeing that sql error, error message was inserted in the database without that character. lgtm!

@jlsherrill This looks like a "no qe required" (but no Jira link) and there are no API changes. So merge when ready I say.


[macOS] Refactoring and cleanup.

Switch to Objective-C ARC.
DisplayServer and OS related Objective-C delegates and some other classes (keyboard mappings, logger) are split up into own files.
Removed some unused code.

Thanks!


Replace add_to_network(network_builder) with a dedicated call in network_builder.

Motivation
Broad goal at present is to cleanup and organizer main_node.rs and network_builder.rs
This PR is an intermediate step which will allow moving setup_network out of main_node.rs and into network_builder.
A core problem in the current paradigm of XXX::add_to_network(&mut network_builder) is that each component XXX  has an explicit dependency on the network_builder crate, so setup_network cannot be a part of network_builder without creating a circular dependency.
This change sidesteps this problem by taking away the explicit dependency from every component onto network_builder.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
Don't break existing integration and unit tests.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

@davidiw This is a follow on to #4246 which should not be considered until the previous PR is resolved.   Otherwise the scope becomes difficult to review.

:umbrella: The latest upstream changes (presumably 8080b15e10a88585f0a09ba5b4b838243b021275) made this pull request unmergeable. Please resolve the merge conflicts.

@davidiw This PR is a coherent milestone along the path towards builder cleanup.   #4384 is the immediate extension.

@davidiw
PTAL and let me know if you feel this PR is scoped where the context is sufficient for review;  if this is too narrow/too much context is missing, then let's consider #4384 instead.
I'll move whichever is more appropriate out of draft.

So I didn't take a look at your references to future PRs, so I'll do that to make sense of what's going on here. I think your rebase hell should ideally be minimal -- though there were some recent tweaks recently.

So I didn't take a look at your references to future PRs, so I'll do that to make sense of what's going on here. I think your rebase hell should ideally be minimal -- though there were some recent tweaks recently.

The rebase hell is mostly associated with two points in the immediate follow up #4384:

Move network_builder from network/src/validator_network/ to network/builder/src/
Move setup_network from main_node to network_builder

cross file structural changes are tediously complicated.

Closing out as this is included in #4384