blue-build distroboxes are broken/bluebuild build podman errors

[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="cannot find UID/GID for user user: no subuid ranges found for user \"user\" in /etc/subuid - check rootless mode in man pages."
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="cannot find UID/GID for user user: no subuid ranges found for user \"user\" in /etc/subuid - check rootless mode in man pages."
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="cannot find UID/GID for user user: no subuid ranges found for user \"user\" in /etc/subuid - check rootless mode in man pages."
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="cannot find UID/GID for user user: no subuid ranges found for user \"user\" in /etc/subuid - check rootless mode in man pages."
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="cannot find UID/GID for user user: no subuid ranges found for user \"user\" in /etc/subuid - check rootless mode in man pages."
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=warning msg="Using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids if not using a network user"
[04:40:28 server:local-40] => time="2024-08-17T04:40:28+02:00" level=error msg="invalid internal status, try resetting the pause process with \"podman system migrate\": cannot re-exec process to join the existing user namespace

My podman installation works fine on aurora because distrobox works and hello world is also fine.
Something related to the distroboxes are broken, the exact same repo/template file works on the cargo install method.
I followed the exact steps that were in the README
distrobox create blue-build --image ghcr.io/blue-build/cli
distrobox enter blue-build
distrobox-export --bin $(which bluebuild --export-path ~/.local/bin/distrobox
exit
...

I layered zsh on my host and konsole executes zsh -l on startup if that matters for any reason.
BlueBuild 0.8.12
Am I missing something?

Yeah we have an issue open to fix the distrobox setup. We had one of our users get it working. Here's their message in our Discord:

Sharing a working distrobox-assemble configuration for the cli. I've successfully used this with both bluebuild build and bluebuild switch. This method relies on the podman build driver. Haven't gotten the default (docker?) method working.
In distrobox.ini:
[bluebuild-root]
#image=ghcr.io/blue-build/cli:latest
image=ghcr.io/blue-build/cli:main
home="~/distrobox/bluebuild"
exported_bins="/usr/bin/bluebuild"
additional_packages=""
init_hooks="ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/podman"
init_hooks="ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/rpm-ostree"
init_hooks="ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/ostree"
init=false
unshare_all=false
nvidia=false
pull=true
root=true
replace=true
start_now=true
exported_apps=""
volume="/etc/bluebuild:/etc/bluebuild:z"

In ~/.bashrc:
if [ -f "${HOME}/.local/bin/bluebuild" ]; then
  bluebuild() {
    local args=("$@")
    if (( ${#args[@]} > 0 )); then
      case "${args[0]}" in
        build|switch)
          ${HOME}/.local/bin/bluebuild "${args[0]}" --build-driver=podman "${args[@]:1}"
          ;;
        *)
          ${HOME}/.local/bin/bluebuild "$@"
          ;;
      esac
    else
      ${HOME}/.local/bin/bluebuild
    fi
  }
fi

The in draft PR is https://github.com/blue-build/cli/pull/160, the original issue is https://github.com/blue-build/cli/issues/145

Yeah we have an issue open to fix the distrobox setup. We had one of our users get it working. Here's their message in our Discord:

For what it's worth, I'm still happily using this configuration since I posted it on the discord.
Some of the steps in that distrobox-assemble configuration might be unnecessary, but I haven't bothered investigating whether it still works are removing some parts of it.
If this works for other people too, it might be worth temporarily putting this in the documentation until the underlying issue is resolved.


Update packages releases to .dev2

Why are these changes needed?
set versions to .dev2
set package dir to [src] for library and for doc quality used by data sift
Related issue number (if any).
#533
#531

And one of your commit comments suggests make set-versions is not catching everything and some manual changes are required.  We should fix make set-versions.

And one of your commit comments suggests make set-versions is not catching everything and some manual changes are required. We should fix make set-versions.

The following seem to be missed.
./transforms/universal/html2parquet/python/pyproject.toml:version = "0.2.1.dev0"
./transforms/universal/html2parquet/python/pyproject.toml:    "data-prep-toolkit==0.2.1.dev0",
./transforms/universal/ededup/ray/pyproject.toml:    "dpk_ededup_transform_python==0.2.1.dev0",
./transforms/universal/doc_id/python/pyproject.toml:    "data-prep-toolkit==0.2.1.dev0"
./transforms/universal/doc_id/ray/pyproject.toml:    "dpk_docid_transform_python==0.2.1.dev0",
./transforms/universal/doc_id/ray/pyproject.toml:    "data-prep-toolkit-ray==0.2.1.dev0"
./transforms/language/doc_quality/ray/pyproject.toml:    "data-prep-toolkit-ray==0.2.1.dev0"
./transforms/language/pii_redactor/python/pyproject.toml:version = "0.2.1.dev0"
./transforms/language/pii_redactor/python/pyproject.toml:    "data-prep-toolkit==0.2.1.dev0",
./transforms/language/pii_redactor/ray/pyproject.toml:version = "0.2.1.dev0"
./transforms/language/pii_redactor/ray/pyproject.toml:    "dpk_pii_redactor_transform_python==0.2.1.dev0",
./transforms/language/pii_redactor/ray/pyproject.toml:    "data-prep-toolkit-ray==0.2.1.dev0",

@touma-I given the recent 0.2.1 release, can we close this one?


Allow LED access via compass direction

Currently, the led abstraction allows access via their names (ld3, etc).
The board is also labeled with directions.
Allow users to access the Leds via the direction, North, South, East, West, etc.
Related: #4, #8.

What about a direction enum and mutably borrowing from Leds like in https://github.com/sirhcel/stm32f3-discovery/commit/06692b6867ce49aee9cae95e7482638a6fc3342b? I'm commenting in the first place as a PR without having #38 landed would look pretty cluttered up.

That looks that a reasonable approach to me.

Alright. Then I prepared #39.

#39 added a method for accessing the leds via the direction printed on the board.
Before releasing:

[ ] Split the roulette example into three.

into_array indexing
into_array iterator
for_direction

There should be an easy way to get an array or iterator of directions
Make sure we understand the consequences of the mutable borrowing of a single struct field

@sirhcel would you mind taking a look at #40 and letting me know what you think?

#41 introduces the Iterator I’ve been wanting to expose. Now I just need to decide if it’s actually a good idea to deprecate into_array() or if I should just add a note to the docs strongly recommending iter_mut() instead.

0.7.1 is now available on crates.io
Docs are in the queue now and should be available soon.
I apologize that I didn't think about adding a note about your contribution until after I published the crate, but it is in the changelog in the readme.
Thanks for the help!

#41 introduces the Iterator I’ve been wanting to expose. Now I just need to decide if it’s actually a good idea to deprecate into_array() or if I should just add a note to the docs strongly recommending iter_mut() instead.

This is awesome! Thank you! I was thinking about how this could be implemented and I'm impressed from #41. This is a bit out of reach for my actual skills.

I apologize that I didn't think about adding a note about your contribution until after I published the crate, but it is in the changelog in the readme.

No worries. Isn't this for the spirit and not for the fame? It was a pleasure to help you out with my first iterator ever implemented in Rust. :)

Lol. It was beyond my skills until I did it!


[The One Ring 2e] - include targetname in roll-template + css fixes

Changes / Comments
02.03.00 (Build 8)
Features

Roll-Template: Target rolls now show the targetname in the roll-template. This is especially helpfull for lm rolls, to assign rolls to the corresponding characters.
Roll-Template: If the roll has failed the roll-template will not show the damage and weapon details to save space.

CSS

import fonts from fonts.google
update to higher resolution borders

02.02.01 (Build 7)
CSS fixes

removed font imports and font-face declarations
added two missing .sheet prefixes in roll-template html
added two missing .charsheet prefixes in the pc css
fixed a typo in the roll-template css

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.
[x] Is this a bug fix?
[x] Does this add functional enhancements (new features or extending existing features) ?
[ ] 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.

@nmbradley Hi Nic, this PR finally fixed the roll-template.


[Error] F2613: Unit 'PngFunctions' not found when compiling Cod.SysUtils.pas

Title
[Error] F2613: Unit 'PngFunctions' not found when compiling Cod.SysUtils.pas
Content
Hello,
I encountered the following error while building the project:
[dcc32 Fatal Error] Cod.SysUtils.pas(21): F2613 Unit 'PngFunctions' not found.

The error occurs on line 21 of the Cod.SysUtils.pas file, indicating that the PngFunctions unit cannot be found. Could you confirm if this file is missing or if it is part of an external dependency that needs to be installed separately?
Thank you!

Hi there!
My mistake. I've completely forgotten about that unit, I believe It used to be included in older versions of Delphi. It's part of the PNGTools library.
I will include It in the repository as soon as I can, or just remove It.
Thank you for pointing this out to me!


Clarified use of column values.

Resolves issue (https://github.com/nicolaslopezj/searchable/issues/122) wherein the use of column values are vague or unclear.

Great, thanks!


DynamoDBContext.FromDocument Exception for string without milliseconds (decimal seconds)

Describe the bug
DynamoDBContext.FromDocument will throw an exception converting a valid ISO date/time string (for example "2022-05-05T11:59:11Z") to a DateTime object. The code works correctly only when the decimal seconds are included, for example the equivalent string "2022-05-05T11:59:11.000Z".
This behavior is problematic in using DynamoDBContext with data sources from other AWS services that may remove trailing zeros. See https://repost.aws/questions/QU6ga7E0zPSRKIpqx1OEIFOA/incompatibility-between-state-entered-time-and-the-dynamo-db-net-sdk.
Expected Behavior
The DateTime will be correctly deserialized from a string with or without decimal seconds, and model object returned without an exception.
Current Behavior
Currently an exception is thrown when attempting to deserialize the string to a DateTime:
An exception of type 'System.InvalidOperationException' occurred in AWSSDK.DynamoDBv2.dll but was not handled in user code: 'Unable to convert [2022-05-05T11:56:11Z] of type Amazon.DynamoDBv2.DocumentModel.Primitive to System.DateTime'
   at Amazon.DynamoDBv2.Converter.FromEntry(DynamoDBEntry entry, Type targetType)

Reproduction Steps
In the form of a unit test, the problem is reproducible (test will fail with an exception) with:
        public class TestObject
        {
            public DateTime DateFromString { get; set; }
        }

        [Fact]
        public void DateTimeDeserializationWithDdbContext()
        {
            Environment.SetEnvironmentVariable("AWS_REGION", "us-west-2");
            Environment.SetEnvironmentVariable("AWS_PROFILE", "not-a-real-profile");

            var json = JsonConvert.SerializeObject(new {
                DateFromString = "2022-05-05T11:56:11Z"
            });
            var doc = Document.FromJson(json);

            var model = new DynamoDBContext(new AmazonDynamoDBClient()).FromDocument<TestObject>(doc);

            Assert.NotNull(model);
        }

Possible Solution
The use of DateTime.ParseExact seems overly restrictive, and creates a situation of incompatibility with other AWS services that store data/time values.  Switching to simple DateTime.Parse would seem a safe and pragmatic choice. Any code that would break with this change would seem to be dependent on a bug (exceptions on deserializing valid dates).
Change:
    public object FromEntry(DynamoDBEntry entry)
    {
        return DateTime.ParseExact(entry.AsString(), "o", CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind);
    }

To:
    public object FromEntry(DynamoDBEntry entry)
    {
        return DateTime.Parse(entry.AsString(), CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind);
    }

Additional Information/Context
As more and more "direct" integrations between services are employed by AWS users, it is important that interoperability be considered a very high priority. This bug is one that make such interoperation more complicated and error prone.  Even more so in the example of the behavior of Step Functions, which is unpredictable but correct (complied with ISO date/time formatting) and only causes this problem when a time is exactly "on a second") -- i.e. 1 time in 1000 executions, give or take.
AWS .NET SDK and/or Package version used
AWSSDK.DynamoDBv2 <IP_ADDRESS>
Targeted .NET Platform
.Net 6
Operating System and version
Windows, Ubuntu, Amazon Linux 2

Reproducible.

@mlhpdx This fix was released in dynamodb version <IP_ADDRESS> on 2023-02-18. Closing this issue as it has been resolved. Feel free to open it if there is still an issue

@mlhpdx This fix was released in dynamodb version <IP_ADDRESS> on 2023-02-18.

Fantastic, and thank you!


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/89551

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/90673

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/105328


UI: Toolbox 2

[x] 14) Instead of showing nothing, I suggest to select MSC (or another property) as default pre-selection. Or alternatively some information about how the search works. edit: screw it

[x] 15) Meta data for MSC and TMSC should be refined.

Re 15) that's easy enough to do, but I'm not 100% we should.  We're going to rebrand the token to Omni which would also involve the metadata changing, but I kind of think that has to go in a consensus breaking release like 0.0.10 (even though it's only the name and metadata we're changing not any actual token values).

I did not intend to rename MasterCore to OmniCoin or so, but simply reword it's description.
I'd be fine, if the property name remains as "MasterCoin" instead of "Mastercoin", for the crazy case someone uses this name as some kind of identifier within an application, even though I think they should actually be punished, if this is really the case.. :)
No, jokes aside, my main rant is about ***data*** which just looks bad, and those descriptions are likely the ones seen the most.

I pushed #23, but please feel free to edit, as you like.
I'm no longer 100 % sure about point 14, given that the other tools have no pre-selected values either.

Still unsure here mate.  I'd be more comfortable with an override at the UI layer than I would with actually changing the underlying data outside of a consensus release.  My fear is simply that perhaps some integrators have gone to extremes and are comparing not just property ID but also the metadata said property ID contains - if we change such metadata I'm not sure what the outcome would be...
So a few options I think:

Everyone weighs in and tells me I'm worrying about nothing and we modify property metadata directly in 0.0.9.x
We override this data display at the UI layer only (few lines of code not much) temporarily until 0.0.10 but leave RPC output unchanged
We do nothing until 0.0.10

P.S. incase not clear my initial vote if for 2) :)

It's not consensus affecting actually, but I'd be fine with (2), maybe even (3), because it has a similar effect as intended, and it gets massive bonus points for valuing the "social contract" of providing immutable data, not changing history, non-changing API interfaces, ... and this is much more sacred to me than elegance.
And after thinking really hard about potential scenarios where such a change would have any impact, I recalled the discussion about off-chain storage of metadata (https://github.com/mastercoin-MSC/spec/issues/250), and one may hash the whole property information and use that hash as identifier, which seems even be more reasonable than relying on the plain id number.

OK awesome, easy then let's do (2) for now, I'll make that change shortly when done with the columns (speaking of, think I have it licked - I didn't use a model for the Omni txhistory and as such I was calling resizetocontents before there were actually any contents there.  Hopefully buttoning up now - this columns one has been one PITA cat to skin - to quote a certain TV show - "I'd like to throw this cat in a bag, throw the bag into a river, and hurl the river out into space." hehe

https://github.com/zathras-crypto/mastercore/commit/2d0628f0e01b2192c3b292a1a5fd5b589e6e27cf

Do we really want to use omnilayer.org? This seems pretty.. different. And I believe mastercoin.org will remain active for quite a while?

Hmm...  not really fussed tbh.  OK I have just checked whois records for mastercoin.org and it's registered until EOM July '15.  So as long as we get the discussion on underlying metadata done by then, I'm OK with leaving as is.
Will modify now.
Thanks
Z

https://github.com/zathras-crypto/mastercore/commit/a47ec994b24ef8848413a86b3fde43bb7693d99c


fix: don't save handleIds for node

Older node versions (0.10, still default in debian stable) will throw exceptions while trying to use the objects returned nodes Timers implementation as keys -> don't make them try it.
For the same reason - as far as I understand it - this has never worked in node, also newer versions, anyway. Therefore this shouldn't break anything.

I signed it!

Basically you're right, of course. Simply suppressing errors is a bad idea in general.
I came up with this idea for a node version of 'tasksByHandleId' (stripped js-version):
function patchTimer(window, setName, cancelName, nameSuffix) {
    var objectHandles = [];
    var tasksByHandleId = {};
    function scheduleTask(task) {
            finally {
                delete objectHandles[data.handleId];
                delete tasksByHandleId[data.handleId];
            }
        }
        if (objectHandles.length > 3000000) {
            var newObjectHandles = [];
            var newTasksByHandleId = {};
            for (var i in tasksByHandleId) {
                tasksByHandleId[i].data.handleId = newObjectHandles.length;
                newObjectHandles[tasksByHandleId[i].data.handleId] = objectHandles[i];
                newTasksByHandleId[tasksByHandleId[i].data.handleId] = tasksByHandleId[i];
            }
            objectHandles = newObjectHandles;
            tasksByHandleId = newTasksByHandleId;
        }
        data.handleId = objectHandles.length;
        objectHandles[data.handleId] = setNative.apply(window, data.args);
        tasksByHandleId[data.handleId] = task;
    }
    function clearTask(task) {
        var objectHandle = objectHandles[task.data.handleId];
        delete objectHandles[task.data.handleId];
        delete tasksByHandleId[task.data.handleId];
        return clearNative(objectHandle);
    }

It puts the objects in an array, uses the index as handle id, and does the laundry now and then.
I decided not to pursue it further, because apart from timeout.ref() and timeout.unref() (which are probably what is handled in lines 75 and 76 of timers.ts), the returned object is only good for being
passed to clear*, which is afaik again patched by zones. In that case it would be a waste of
ressources to have this mapping in node.
What do you think?

@manuelschneider , I think the reason of the issue is in nodejs v0.10, nodejs lazy load timers, so global.setTimeout !== timers.setTimeout, and zone.js patch them all.
I think we just remove global patch is ok, but I think it will need some test.
in node.ts, currently the logic is
// Timers
const timers = require('timers');
patchTimer(timers, set, clear, 'Timeout');
patchTimer(timers, set, clear, 'Interval');
patchTimer(timers, set, clear, 'Immediate');

const shouldPatchGlobalTimers = global.setTimeout !== timers.setTimeout;

if (shouldPatchGlobalTimers) {
  patchTimer(_global, set, clear, 'Timeout');
  patchTimer(_global, set, clear, 'Interval');
  patchTimer(_global, set, clear, 'Immediate');
}

I think we can change it to
// Timers
const timers = require('timers');
patchTimer(timers, set, clear, 'Timeout');
patchTimer(timers, set, clear, 'Interval');
patchTimer(timers, set, clear, 'Immediate');

it will be ok, I think, but we should add some test and findout why we patch global before.

When you skip the global patches, the existing tests fail at
build/test/common/setInterval.spec.js:26
                global[utils_1.zoneSymbol('setTimeout')](function () {

If you remove the timers patch instead, at least the existing tests are ok and it seem to work. However,
at the moment I don't understand why the original author put it there.
I still don't understand, why this is related to the exceptions? From what I understand, they're simply a
type problem: handleId is everywhere described and handled as integer, not object. Trying to use it as keys of an object triggers the exceptions in older node versions.

@manuelschneider , the test code failed is reasonable, if we modify that way, we will modify the test case as well.

If you remove the timers patch instead, at least the existing tests are ok and it seem to work. However,
at the moment I don't understand why the original author put it there.

Yeah, I don't know either. I will try to find out why.

I still don't understand, why this is related to the exceptions? From what I understand, they're simply a
type problem: handleId is everywhere described and handled as integer, not object. Trying to use it as keys of an object triggers the exceptions in older node versions.

I believe that in nodejs v0.10, the timer.setTimeout still return an integer, not object, the reason it returns object because it return a ZoneTask(which is patched by zone.js), so it will cause the error.
So I think the real solution should let setTimeout still return integer correctly.
We need to add some tests to simulate the nodejs v0.10 behavior.

I believe that in nodejs v0.10, the timer.setTimeout still return an integer, not object, the reason it
returns object because it return a ZoneTask(which is patched by zone.js), so it will cause the error.

I don't think so:

from the docs:

To schedule execution of a one-time callback after delay milliseconds. Returns a timeoutObject for possible use with clearTimeout(). Optionally you can also pass arguments to the callback.

let's try it:

$ node -v
v0.10.29
$ node -e "console.log(setTimeout(function (){}, 10));"
{ _idleTimeout: 10,
  _idlePrev:
   { _idleNext: [Circular],
     _idlePrev: [Circular],
     msecs: 10,
     ontimeout: [Function: listOnTimeout] },
  _idleNext:
   { _idleNext: [Circular],
     _idlePrev: [Circular],
     msecs: 10,
     ontimeout: [Function: listOnTimeout] },
  _idleStart:<PHONE_NUMBER>171,
  _onTimeout: [Function],
  _repeat: false }

@manuelschneider , yes, you are right, in v0.10, it return a TimerObject, and it doesn't have any id like property.

How do I run tests with node v0.10?
$ npm run test-node

><EMAIL_ADDRESS>test-node
> gulp test/node

gulpfile.js:17
const os = require('os');
^^^^^

@manuelschneider , I think you just need to add a test case in test/common/setTimeout.spec.ts, and   write a fake setTimeout which return a fake timerObject to  override global setTimeout and test if setTimeout and clearTimeout work and recover the setTimeout to original one after your test.

I don't get it. You want me to patch the patched setTimeout with a fake one? Why?
The existing testcases test if a timeout can be scheduled and canceled. In my opinion that's exactly what is needed to make sure the changes don't break something.
My change should not have modified previously existing behaviour. It simply reduced the usage of tasksByHandleId to the cases, when handleId is an integer. It does not modify data.handleId.
tasksByHandleId never worked in node before:
$ node -v
v7.8.0
$ node -e 'let x={a:1}; let y={b:2}; let z={c:3};x[y]="yy"; x[z]="overrides yy"; console.log(x);'
{ a: 1, '[object Object]': 'overrides yy' }

=> Objects still get stringified in newer node versions, when used as key. Which makes them
practically useless. The difference is that older node versions threw an exception instead of silently
stringifying all objects to '[object Object]'.
As far as I understand it, the patched setTimeout always returns a task. But when data.handleId is
a integer, toString() from zone.ts (line 1165) returns the integer (see #739). In node data.handleId has always been an object, which is why the tests in setTimeout.spec, which are checking the 'return value' are skipped for node.
I don't now, but for now I can't think of a useful test to my patch apart from the already existing ones.

@manuelschneider , in current cases, it can only make sure the changes not break anything, I mean we should simulate node v0.10 behavior to test if global.setTimeout return a object insteadof integer, our logic should also work.
the case should like
const originalSetTimeout = global.setTimeout;
global.setTimeout = function() {
    const  originalResult = originalSetTimeout.apply(this, arguments);
   const fakeResult = {
      timer: originalResult;
    }
    return fakeResult;
}
const originalClearTimeout = global.clearTimeout;
global.clearTimeout = function(timerObject) {
    return originalClearTimeout.apply(this, [timerObject.timer]);
}

Zone.current.fork({
   name: 'test',
   scheduleTask: (...) => {
      ...
     // some spy here
   },
   cancelTask:(...) => {
     // some spy here
    }
}).run(() => {
    const timerId = setTimeout(() => {
       // some other spy here
    }, 100);
    clearTimeout(timerId);
});

expect(scheduleSpy).toHaveBeenCalled();
expect(cancelSpy).toHaveBeenCalled();
expect(timeoutCallbackSpy).toHaveBeenCalled();

I still don't see how this should test handling the exceptions?

@manuelschneider , in my understandings, we should test from those 2 views.

the new code should not break anything, the current test cases can cover this one.
the new code can still work for the error case (here means the node v0.10 behavior, if setTimeout return Object instead of an integer), so we add some cases to simulate this case.

What do you think?

the new code can still work for the error case (here means the node v0.10 behavior, if setTimeout return Object instead of an integer), so we add some cases to simulate this case.

This is still the case in newer node versions:
$ node -v
v7.8.0
$ node -e 'console.log(setTimeout(function() {}, 50))'
Timeout {
  _called: false,
  _idleTimeout: 50,
  _idlePrev:
   TimersList {
     _idleNext: [Circular],
     _idlePrev: [Circular],
     _timer: Timer { '0': [Function: listOnTimeout], _list: [Circular] },
     _unrefed: false,
     msecs: 50,
     nextTick: false },
  _idleNext:
   TimersList {
     _idleNext: [Circular],
     _idlePrev: [Circular],
     _timer: Timer { '0': [Function: listOnTimeout], _list: [Circular] },
     _unrefed: false,
     msecs: 50,
     nextTick: false },
  _idleStart: 34,
  _onTimeout: [Function],
  _timerArgs: undefined,
  _repeat: null }

See also current API.
Therefore in my opinion this is already covered by running the current testcases in node (doesn't matter what version). The exception-problem however is not testable without node 0.10, because
it only occurs there.

@manuelschneider , sorry, I think I misunderstand this issue totally, I will check it.

@manuelschneider , I think you are right. We don't need to add test cases.
Node always return complex Timer Object. So the taskHandleId object should only hold integer type of timer id.
So in fact we have 2 problems

in nodejs, we should not use taskHandleId anyway, because it is an object
in nodejs v0.10, it will throw error TypeError: Cannot convert object to primitive value, but I don't know why only nodejs v0.10 throw this error, I think for further research, we should check chromium v8 code.

So this fix in fact not only resolve the nodejs v0.10 issue, but also remove the unused process for saving an complex object.toString() into taskHandleId object and never use it.

Thank you very much!
I'll try to look into the 'patch-problem' you stated above within the next days. Patching only the global setTimeout seems to have some performance benefit in node v0.10. If I can figure out what's wrong there I'll submit another issue/merge request.


Update Alpine miss leading info!

The information provided about Alpine DNS "issue" is not only miss leading but completely wrong!
Thanks.

/retitle Replace misleading info about Alpine and DNS lookups

/approve

/lgtm


fatal  error C1083 “bluevk/BlueVK.h”: No such file or directory

The cmake file of filamentapp needs to include the bluevk Header file directory.

What's the exact error? This library shouldn't include bluevk.

It includes a file from libbackend though, that's probably the missing dependency.

I actually just ran into the same issue when attempting to include "backend/platforms/VulkanPlatform.h" with the v1.40.2-windows build. I haven't made any progress trying to track down the cause yet though.

Make sure you link against bluevk.

After the git clone.. In the Windows environment, editing filamentapp with cmake will result in errors. There are two problems. One is that the backend Header file contains, and the other is that the bluevk Header file contains. VulkanPlatform. h is referenced in filamentapp. This file contains # include<bluevk/BlueVK. h>. Another issue is that when compiling gltfviewer.exe, an error will be reported as a link error in filamentapp, which should be an issue with the public link between filamentapp and backend.

I can take a look at this since I introduced the bluevk dependency.
@idclosed , do you have any specific repro steps?  Just try compiling the filamentapp lib?

git clone git@github.com:google/filament.git
mkdir out
cd out
cmake..
Then open TNT.sln, and the compiler will discover the compilation issue with filamentapp. lib. Alternatively, you can directly open cmakelists.txt in the root directory using vs2022, open the cmake project view, and compile directly to discover the problem. The compilation issue can be resolved by adding an include to bulevk in cmakelists.txt under filamentapp.

With my setup I'm not using filamentapp. Here's the relevant lines from my CMakeLists

target_include_directories(DLE PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/filament-v1.40.2-windows/include/)
target_include_directories(DLE PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/filament-v1.40.2-windows/libs/)
set(fiLibs backend bluegl bluevk vkshaders filabridge filaflat filament ibl utils geometry camutils smol-v)
foreach(X IN LISTS fiLibs)
target_link_libraries(DLE PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/filament-v1.40.2-windows/lib/x86_64/mdd/${X}.lib)
endforeach()

And the section of the header file I'm using:

#include <filament/Engine.h>
#include <filament/Camera.h>
#include <filament/ColorGrading.h>
#include <filament/IndexBuffer.h>
#include <filament/RenderableManager.h>
#include <filament/Renderer.h>
#include <filament/Scene.h>
#include <filament/Skybox.h>
#include <filament/TransformManager.h>
#include <filament/VertexBuffer.h>
#include <filament/View.h>
#include <filament/RenderableManager.h>
#include <filament/Material.h>
#include <filament/IndexBuffer.h>
#include <filament/Viewport.h>
#include <filament/SwapChain.h>
//#include <backend/platforms/VulkanPlatform.h>

@lconn-dev , your issue might be different.  Since you're using your own CMakeLists.txt, please make sure that you're doing all the things guarded by FILAMENT_SUPPORTS_VULKAN in our root CMakeLists.txt

Well done, Quickly fixed, this issue is already resolved.


Fix support for legacy Z-Wave thermostats

Description:
This brings back support for Z-Wave thermostats
of SETPOINT_THERMOSTAT specific device class.
Such devices don't have COMMAND_CLASS_THERMOSTAT_MODE
and are now handled separately.
fixes #29844
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the [development checklist][dev-checklist]

I try oandrew:zwave-thermostat-bugfix with Danfoss Popp Radiator Thermostat (manf 2, type 115, id a010) and it works OK.
Version 0.102.3 - climate component of Danfoss Popp Radiator Thermostat - OK
Version 0.103.0 - climate component of Danfoss Popp Radiator Thermostat - disappeared
Version from oandrew:zwave-thermostat-bugfix - climate component of Danfoss Popp Radiator Thermostat - OK

We should make sure to tag this for 0.103.1


feat(snap): Remove device-virtual

This PR removes device-virtual for the following reasons:

This app is for development/demonstration purposes only and not needed in production. It shouldn’t be shipped by default. It will become a standalone snap.
The hardcoded versioning of the source inside the snap makes it hard to keep the edgex-go source compatible with device-virtual source. Upstream takes care of go vendor versioning but not snapcraft parts.
The build and hooks logic adds avoidable complexity to the core snap. Removing device-virtual reduces edgex snap size from 293M to 283M.

Signed-off-by: Mengyi Wang<EMAIL_ADDRESS>

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[x] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[x] I am not introducing a new dependency (add notes below if you are)
[x] I have added unit tests for the new feature or bug fix (if not, why?) https://github.com/canonical/edgex-snap-testing/pull/62
[x] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[ ] I have opened a PR for the related docs change (if not, why?)

Testing Instructions

TODO:

[ ] update checkbox test
[x] remove snap testing edgexfoundry etst suite: https://github.com/canonical/edgex-snap-testing/pull/62

New Dependency Instructions (If applicable)

snap test will pass after the update edgexfoundry test suite PR has been merged.


fixed mkl sgemm call

gemm called used *float instead of Float
see: https://intel.github.io/mkl-dnn/group__dnnl__api__blas.html

@mslacken Could you please check failed build errors? Thanks!

@alextp Can you please assist with the above query from @mslacken? Thanks!

@penpornk do you know the answer?

DNNL (MKL-DNN v1.x) is only used with TF-MKL build (--config=mkl). Stock TensorFlow is still using MKL-DNN v0.x, whose sgemm interface is incompatible with v1.x. There is nothing to fix here. (I'll fix them when we update stock TF to v1.x later after the 2.2 branch cut.)

More details:

Stock TensorFlow (@mkl_dnn) currently uses MKL-DNN v0.21.3.
eigen_contraction_kernel depends on @mkl_dnn.
conv_grad_input_ops depends on eigen_contraction_kernel.
Here is the sgemm interface in v0.21.3 (const float* alpha and const float* beta).

So the existing sgemm calls are correct and shouldn't be fixed.

@penpornk Thanks for you clarification. I encountered this issue as I am using the system mkl-dnn which is at version 1.1.3.
One good news is that this calls seem the only incompatibility so far.

@mslacken Got it. Thank you for the explanation! Stock TensorFlow only uses two routines from MKL-DNN: mkldnn_sgemm and mkldnn_s8u8s32. So there can't be many incompatibilities to begin with.
We plan to also switch to MKL-DNN v1.2 for stock TF in the near future. If you'd like to use v1.x before that, please feel free to apply the fix locally in the meanwhile. Note that another difference between v0.x and v1.x is that v0.x assumes matrices are in column major order and v1.x assumes row-major. Please account for that too if you do make the changes.
However, I'd suggest staying with v0.21.3 to save your time, because v1.2 doesn't have any noticeable performance improvements from v0.21.3 for sgemm. I'll ping this thread once stock TF also switches to v1.2.

Hi, i'm compiling this but with --config=cuda. I was under the impression --config=mkl would use this, but if --config=cuda would not.

@muziker Yes, only --config=mkl would use MKL-DNN v1.x. Vanilla TF and --config=cuda (and all other configurations that runs on non-mobile devices) are still using MKL-DNN v0.21.3.


Bipartite Graphs

We should add Bipartitioned graphs to Catlab.Graphs. We can then use this type for both AlgebraicPetri.jl and also be able to represent presentations that would give us pushout support for combining presentations as well as graphically displaying them. I think we something like the following types:
@present BipartitionedGraph(FreeSchema) begin
  (V1, V2)::Ob
  E::Ob
  src::Hom(E,V1)
  tgt::Hom(E,V2)
end

@present BipartitionedDiGraph(FreeSchema) begin
  (V1, V2)::Ob
  (E1, E2)::Ob
  src1::Hom(E1,V1)
  tgt1::Hom(E1,V2)
  src2::Hom(E2,V1)
  tgt2::Hom(E2,V2)
end

This would be great. You're right that it's technically more correct to call these "bipartitioned graphs," but I'd also be fine with calling them "bipartite graphs." In CT we don't always strictly follow the graph theory terminology, e.g., what we call a "graph" a graph theorist would call a "directed multigraph."
Micah, do you want to implement this? I think a new submodule Catlab.Graphs.BipartiteGraphs would make sense.

Yeah I can start implementing this!

I'll take this one over since I need it now.
It turns out that the (co)limit diagrams derived from UWDs have exactly the form of an undirected bipartite graph, with one vertex set corresponding to boxes and the other to junctions. This class of (co)limits is important enough, encompassing both conjunctive queries and structured cospan composites, that it makes sense to have special support for the diagrams.


Mongo check deprecation messages

Hi,
I'm seeing these deprecation messages in the agent logs with the latest agent version 6.15.0:
2019-11-21 12:05:34 UTC | CORE | WARN | (pkg/collector/python/check.go:201 in Configure) | could not get a 'mongo' check instance with the new api: __init__() takes at least 4 arguments (4 given) 2019-11-21 12:05:34 UTC | CORE | WARN | (pkg/collector/python/check.go:217 in Configure) | passing agentConfigto the constructor is deprecated, please use theget_config function from the 'datadog_agent' package (mongo).
How can this be fixed?
Relevant agent status information:

Getting the status from the agent.

===============
Agent (v6.15.0)
Status date: 2019-11-21 12:20:17.035476 UTC
Agent start: 2019-11-21 12:05:33.021960 UTC
Pid: 11931
Go Version: go1.12.9
Python Version: 2.7.16
Check Runners: 4
Log Level: info
mongo (1.12.0)
--------------
Instance ID: mongo:b23f55cf42b63f65 [OK]
Configuration Source: file:/etc/datadog-agent/conf.d/mongo.d/conf.yaml
Total Runs: 59
Metric Samples: Last Run: 4,693, Total: 276,887
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 59
Average Execution Time : 311ms

Hi @mihaialdoiu , Did you find the solution for this problem?

Hi @priyesh2609, updating the Agent to a more recent version or updating the mongo check to 1.14.0 or newer (see mongo check changelog) should remove the error.
I am closing this issue and transferring it to integrations-core repo, but feel free to raise any further problems.


Research into the potential restructure of status object`

As titled, current status object can be confusing at times, but we probably need more discussion this.

There doesn't seem to be the need to talk about this in the immediate future. I will close this issue for now.


Add Cocoapods source

The goal of this pull request is to add support for the CocoaPods package manager

[x] Include documentation for the new source and update the documented source list.
[x] Add a setup script if needed.
[x]  Include tests and test fixtures needed to verify the source in CI.
[x]  Add a CI job to .github/workflows/test.yml.

:wave: @LouisBoudreau just wanted to ACK that I've seen the PR, but my days have been incredibly busy this week.  I'll take a look at this and your other open PR over the weekend.  Sorry for the delay and thank you so much for adding cocoapods support 🙇

Perfect @jonabc,
Let me know if there is anything I can do 😄

Thanks for you review!
I just wanted to let you know that I applied the requested changes.

Thanks for you review!
I just wanted to let you know that I applied the requested changes.

I appreciate the extra notice, I had another pretty busy week and then took a few days away from the computer to relax.  I should be more available to look at any more changes to your open PRs over the next few days.

No problem, I just applied the last requested change 😄

I haven't gotten around to fixing the cached license verification action to work with forks.  Everything else is looking good, merging!  Thanks again for putting this together.  :shipit:


Pelican origin token create does not respect issuer flag

Describe the bug
pelican origin token create --issuer "foobar.com" should use foobar.com as its issuer, but I believe it ends up calling config/config.go/GetServerIssuerURL() instead. If I don't set Server.IssuerUrl, it always grabs my local hostname
To Reproduce
pelican origin token create --issuer "foobar.com"
Expected behavior
The generated token should have its issuer set to foobar.com

Closed by #1135


when is the update for 14.23 on NA version

Hey, thank you for continuing R3nzskins mod. Just wanna ask when the update for 14.23 on NA version because it doesn't work anymore. RiotServersReSkin_new.

I am so sorry lol. It was my fault, I usually use the RiotServersReskin_new, I tried the ReSkin.7z and it works perfectly fine. Good work again, thank you for the mod 👍


Add a license to the repository

I recently came across your project QiskitSG and I noticed that the repository github.com/adlantz/QiskitSG currently does not have a license specified.
Why Adding a License is Important?
As GitHub documents

Public repositories on GitHub are often used to share open source software. For your repository to truly be open source, you'll need to license it so that others are free to use, change, and distribute the software.

Would be possible to add a valid license to this repository? Probably something really OpenSource such as the Apache 2.0 license would fit really well.
Thanks!

Done. Thanks!

Thanks!


storage-service-cxx/logs/storage-service.INFO lost log info

Log is truncated.

Possibly caused by grpc::string_ref usages. Can convert it to a string to solve this issue.


wlfreerdp crashes during a video call when not in focus

In Debian testing (wlfreerdp 2.9.0) in KDE Wayland session (kwin / plasma 5.27.0), wlfreerdp often crashes when wlfreerdp window is not in focus (like alt tabbed out from), while there is a Teams call going on in it in Firefox, with camera and microphone redirections happening.
The way client is called:
wlfreerdp /v:<host> /u:<user> /d:<domain> /p<pass> /w:2432 /h:1368 /bpp:24 /gfx:avc444 /network:lan /sound:format:1 /usb:id,dev:####:#### /microphone:format:1 /log-level:INFO -sec-nla

Crash backtrace I got from sudo coredumpctl debug wlfreerdp
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x00007f566d452d2f in __pthread_kill_internal (signo=11, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007f566d403ef2 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
#3  0x00007f566d704c0f in fatal_handler (signum=11) at ./libfreerdp/utils/signal.c:76
#4  <signal handler called>
#5  __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:664
#6  0x000056464a2ee4d6 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29
#7  wlf_copy_image (scale=0, area=0x7f5635ffa108, dstHeight=1368, dstWidth=2432, dstStride=9728, dst=<optimized out>, srcHeight=<optimized out>, srcWidth=<optimized out>, srcStride=9728, src=<optimized out>) at ./client/Wayland/wlfreerdp.c:710
#8  wlf_copy_image (src=<optimized out>, srcStride=9728, srcWidth=<optimized out>, srcHeight=<optimized out>, dst=<optimized out>, dstStride=9728, dstWidth=<optimized out>, dstHeight=<optimized out>, area=<optimized out>, scale=<optimized out>)
    at ./client/Wayland/wlfreerdp.c:682
#9  0x000056464a2ee7ea in wl_update_buffer (context_w=0x56464b50df30, ix=<optimized out>, iy=<optimized out>, iw=<optimized out>, ih=<optimized out>) at ./client/Wayland/wlfreerdp.c:108
#10 0x00007f566d782800 in update_end_paint (update=update@entry=0x56464b55ff10) at ./libfreerdp/core/update.c:3022
#11 0x00007f566d71b498 in gdi_OutputUpdate (surface=0x7f5627926ca0, gdi=0x56464b9fec50) at ./libfreerdp/gdi/gfx.c:188
#12 gdi_UpdateSurfaces (context=0x56464ba88cf0) at ./libfreerdp/gdi/gfx.c:225
#13 0x00007f566d71af1b in gdi_EndFrame (context=<optimized out>, endFrame=<optimized out>) at ./libfreerdp/gdi/gfx.c:258
#14 0x00007f566d8f0114 in rdpgfx_recv_end_frame_pdu (callback=0x56464babddc0, s=0x7f560cdbfb00) at ./channels/rdpgfx/client/rdpgfx_main.c:873
#15 rdpgfx_recv_pdu (callback=callback@entry=0x7f5624000d90, s=s@entry=0x7f560cdbfb00) at ./channels/rdpgfx/client/rdpgfx_main.c:1688
#16 0x00007f566d8f216b in rdpgfx_on_data_received (pChannelCallback=0x7f5624000d90, data=<optimized out>) at ./channels/rdpgfx/client/rdpgfx_main.c:1808
#17 0x00007f566d8c596e in drdynvc_process_data (s=<optimized out>, cbChId=<optimized out>, Sp=<optimized out>, drdynvc=<optimized out>) at ./channels/drdynvc/client/drdynvc_main.c:1169
#18 drdynvc_order_recv (s=0x56464ba25b50, drdynvc=0x56464b5e7270) at ./channels/drdynvc/client/drdynvc_main.c:1235
#19 drdynvc_virtual_channel_client_thread (arg=<optimized out>) at ./channels/drdynvc/client/drdynvc_main.c:1389
#20 drdynvc_virtual_channel_client_thread (arg=0x56464b5e7270) at ./channels/drdynvc/client/drdynvc_main.c:1353
#21 0x00007f566d6269e8 in ?? () from /lib/x86_64-linux-gnu/libwinpr2.so.2
#22 0x00007f566d450fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#23 0x00007f566d4d166c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Let me know if there is any way to narrow it down further.

Still happens with freerdp 2.10.0.

Something fails here, but it shows "optimized out" for me despite adding debug symbol packages:
#7  wlf_copy_image (scale=0, area=0x7fa21dffa108, dstHeight=1368, dstWidth=2432, dstStride=9728, dst=<optimized out>, srcHeight=<optimized out>, srcWidth=<optimized out>, srcStride=9728, src=<optimized out>) at ./client/Wayland/wlfreerdp.c:710

I.e. this memcpy is coring for some reason:
		for (i = 0; i < height; i++)
		{
			const size_t srcOffset = i * srcStride + baseSrcOffset;
			const size_t dstOffset = i * dstStride + baseDstOffset;
			memcpy(&pdst[dstOffset], &psrc[srcOffset], width * 4);
		}

Just guessing, but may be window buffer somehow gets invalidated at some point?
When it's doing
	if (!wlf_copy_image(gdi->primary_buffer, gdi->stride, gdi->width, gdi->height, data, stride,
	                    geometry.width, geometry.height, &area,
	                    context_w->context.settings->SmartSizing))

That data comes from:
	data = UwacWindowGetDrawingBuffer(context_w->window);

	if (!data || (rc != UWAC_SUCCESS))
		goto fail;
...

Noticeably crash happens with loss of focus, so may be some kind of invalidation isn't handled correctly.

Any suggestion how to narrow it down further? It still happens periodically crashing the session during video calls which is pretty disruptive.

Was this fixed in the latest code?

wlfreerdp is deprecated, closing all related issues.

Ah, I see. So there are no plans to support Wayland directly?

@shmerl no, the SDL-client is to replace all specific implementations as we do not want to support various platform clients (which mostly only work half way)
currently it already supports more than the older wayland client and with SDL3 the last major blocker (clipboard) will be resolved.

Ah, that's good to know thanks! SDL should handle Wayland integration for you.


feat(patternMatching): Switch to path-to-regexp for pattern matching

path-to-regexp offers a broader pattern matching feature set with better performance. This replaces react-router's home grown pattern matching with path-to-regexp. For more information on the capabilities of path-to-regexp's pattern matching, checkout the documentation: https://github.com/pillarjs/path-to-regexp/blob/master/Readme.md#parameters

LGTM


MqttApplicationMessageReceived QoS is always 0 ?Java client demo is normal

MQTT.fx  publish

Java client demo Received

I assume you are using MQTT v5 right?
Did you subscribe to the topic with QoS 2 as well in the C# code?


Change default rounding mode to TIES_EVEN

#10413 introduces a new rounding mode which rounds ties to the next even number (also known as "Banker's roundin").
This rounding mode should be used as default for Number#round. The current default, TIES_AWAY has a bias towards larger magnitude.
TIES_EVEN is recommended as dedault mode by IEEE-754 and many other languages use it as default including Julia, libc, Java.

This might be controversial, but should we change this before 1.0? It's probably better to change now than any pointer later.

I'm on board with changing it for 1.0. Other languages allow setting the default rounding mode. Should we consider the same? It can appear later of needed.

@bcardiff do you mean globally?

Yes

Is there any other language that allows that? Well, maybe if it's a compile flag... But then, what if a lib expects a default round mode but you change it?
Or what would be the use case? If the default is configurable then you would always want to specify a value to make sure you get the behavior you want, making the default useless.

Is there any other language that allows that? [...]

@asterite Yes, Ruby - for BigDecimal at least.

Julia, libc and java links shared previously shows how to set the current global rounding mode. That's why I mentioned it.
For apps it might not be useful. For numerical processing it might.
Again, is not mandatory on my end.

A number of languages have global configuration. Julia and libc as noted in the OP.
Java on the other hand has a MathContext class which can be tied directly to BigDecimal number instances and then all operations on that instance uses the configured rounding mode.
I'm not very familiar with the specifics though. We shouldn't rush an implemementation. Having a global setting would surely be nice to offer a fallback mechanic. But is should be fine with just changing the default. If it breaks someone's code, it's always possible to re-implement Number#round.

For people in the future who will undoubtedly be confused by the new default:  Does this mean we should expect 0.5 to round to 0, 1.5 to round to 2, 2.5 to also round to 2, and 3.5 to round to 4, etc? (As opposed to the rules many of were taught as children to "round up when equidistant" (which I believe is the "rounds away [from zero]" method).

Yes, exactly. The new TIES_EVEN mode breaks ties by rounding to the nearest even number.
No doubt this may be confusing when you expect TIES_AWAY which is commonly used in every-day maths and typically tought in school.
TIES_EVEN is preferred however in computational algebra because it is less biased and minimizes the expected error for sums of rounded numbers.
To show this in an example.
numbers = [0.5, 1.5, 2.5, 3.5, 4.5]

numbers.sum                      # => 12.5
numbers.sum(&.round(:ties_even)) # => 12.0
numbers.sum(&.round(:ties_away)) # => 15.0

The actual sum of these four numbers is 12.5. With rounded values, the sum is 12.0 for TIES_EVEN mode. The difference is a small error due to rounding. With TIES_AWAY mode the difference is much larger at 15.0.
This example is obviously rigged to demonstrate the effect drastically, but the fact is that this error shows in any larger set of mostly unrelated figures.
Thus TIES_AWAY is considered a better rounding mode for these kind of operations which happen a lot in computer programs. It has some other drawbacks of course, but is generally preferred over TIES_AWAY.


Tweaks on the git tab (mobile) + misc stuff

made all usernames clickable in convo (added "underline" prop to Usernames component)
added blue/green backgrounds to @mentions
fixed simple teams avatar size issue on mobile inbox

:no_entry: Error rendering the commits 84d8ba67170d...6a30ba881245 on linux. :mag_right: 20 errored, 5 new, 1 removed, 30 changed

Error in 84d8ba67170d: Chat_Inbox-You_Rekey_Selected-ERROR

Error in 6a30ba881245: Chat_Inbox-You_Rekey_Selected-ERROR

Error in 84d8ba67170d: Chat_Inbox-You_Rekey-ERROR

Error in 6a30ba881245: Chat_Inbox-You_Rekey-ERROR

Error in 84d8ba67170d: Chat_Inbox-Selected_Normal-ERROR

Error in 6a30ba881245: Chat_Inbox-Selected_Normal-ERROR

Error in 84d8ba67170d: Chat_Inbox-Selected_Muted-ERROR

Error in 6a30ba881245: Chat_Inbox-Selected_Muted-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Part_Rekey_Selected-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Part_Rekey_Selected-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Part_Rekey-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Part_Rekey-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Normal-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Normal-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Long_Top-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Long_Top-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Long_Bottom-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Long_Bottom-ERROR (view)
Error in 84d8ba67170d: Chat_Inbox-Empty-ERROR (view)
Error in 6a30ba881245: Chat_Inbox-Empty-ERROR (view)
Added: Colors-green_3_E_8_FAF_3 (view)
Added: Chat_Banner_Invite-Invite (view)
Added: Chat_Banner_Info-Info (view)
Added: Chat_Banner_Error-Error (view)
Added: Chat_Banner_Broken-Broken_Tracker_3 (view)
Changed: Profile-Your_Profile_Proof_Menu (before) (after) (diff)
Changed: Profile-Your_Profile_Pending_Proof_Menu_HN (before) (after) (diff)
Changed: Profile-Your_Profile_Pending_Proof_Menu_DNS (before) (after) (diff)
Changed: Profile-Your_Profile_Pending_Proof_Menu (before) (after) (diff)
Changed: Profile-Your_Profile_No_followers_or_following (before) (after) (diff)
Changed: Profile-Your_Profile_No_Proofs (before) (after) (diff)
Changed: Profile-Your_Profile_Following_Tab (before) (after) (diff)
Changed: Profile-Your_Profile_Empty (before) (after) (diff)
Changed: Profile-Your_Profile_Broken_Proof_Menu (before) (after) (diff)
Changed: Profile-Your_Profile_Broken (before) (after) (diff)
Changed: Profile-Your_Profile (before) (after) (diff)
Changed: Profile-Unfollowed_Scrolled (before) (after) (diff)
Changed: Profile-Unfollowed_Profile_page (before) (after) (diff)
Changed: Profile-Unfollowed_Folders_Expanded (before) (after) (diff)
Changed: Profile-Unfollowed_Few_Folders (before) (after) (diff)
Changed: Profile-Unfollowed_Changed_Proofs_unreachable (before) (after) (diff)
Changed: Profile-Unfollowed_Changed_Proofs_deleted (before) (after) (diff)
Changed: Profile-Unfollowed (before) (after) (diff)
Changed: Profile-Followed_Changed_Scrolled (before) (after) (diff)
Changed: Profile-Followed_Changed (before) (after) (diff)
Changed: Profile-Followed (before) (after) (diff)
Changed: Invite_Generated-Normal (before) (after) (diff)
Changed: Invite_Generated-No_email (before) (after) (diff)
Changed: Folders_Ignore_Confirmation-Normal_Public (before) (after) (diff)
Changed: Folders_Ignore_Confirmation-Normal_Private (before) (after) (diff)
Changed: Folders_Delete_Confirmation-Normal_Public (before) (after) (diff)
Changed: Folders_Delete_Confirmation-Normal_Private (before) (after) (diff)
Changed: Folders_Clear_History_Confirmation-Normal_Public (before) (after) (diff)
Changed: Folders_Clear_History_Confirmation-Normal_Private (before) (after) (diff)
Changed: Folders_Clear_History_Confirmation-Long_Name_Public (before) (after) (diff)
Removed: Colors-green_3_e_5_f_6_ef (view original)


brew-build-bottle-pr: audit formulae before submitting PRs

When we submit PRs to build bottles, CI builds will fail when formula don't pass audit checks. We should run audit automatically before submitting a PR... hence, this PR :)

@sjackman done! In that case it doesn't make sense to have a function for that check, so I just moved the core to where you suggested

I guess I have to move a tad lower


Fix TF parsing for creating literals and Fix name lookups for input params

Bug 1: create_literal was using back_inserter to copy vector with already allocated size, causing double the size of literal.
Fix 1 :  not use back_inserter
Bug 2:  Input param to model can be from operation that has multiple output, in that case name of the input param would contain : e.g. input_1:0
Fix 2: Look for : and take substring

Are we able to add unit tests for these issues?

Are we able to add unit tests for these issues?

I can try tomorrow, not sure if newer versions of TF would generate :0 for a node that has only one output edge.

Are we able to add unit tests for these issues?

I can try tomorrow, not sure if newer versions of TF would generate :0 for a node that has only one output edge.

I am unable to produce a model with TensorFlow with :0 edge, I've mailed QA team on how they got the model. Waiting on it.

Since this is passing CI, I am okay with merging and leaving the test generation as a TODO.

I looked at the code of the UIF model and how they generated input:0. They are using TF-1.15.2 which is very old. They have custom TF with Vitis AI Quantization transforms called decent_q.  I am not sure if we can generate such a test without pulling many dependencies into MIGraphX. I think it is fine for now to not add a test.


added formulas for skillpoints

added formulas for:

skillpoints per minute
skillpoints per level and rank (including table of common results)

Are those formulas rendering the way you want them to? They don't look right to me....

I viewed them using 'make livehtml' and they looked good for me. I used the subscript for mor meaningful variables.
Or do you mean the formulas themself are wrong?

Yea the subscript felt off to me but if it was on purpose cool. :)


Feature request: index.md overrides current index behavior

I think of this as an opt-in feature: if you have a top-level file called index.md, fetching the root of your wiki would render it instead of the current "index" behavior. Maybe have the current index behavior always be available with the pseudo tag "all_pages"? (kind of like "recent" does recent updates)

Love this. I've added /all as well but didn't link to it in the UI yet. Will merge it later today.
Thank you!

Yay - glad you liked it! This suggests a better behavior for creating a link with a trailing "/" too: have it access/create an index.md in that directory.
I'm enjoying using your wiki, and learning about this Rust web framework too. I have migrated my "home wiki" over from Decko - it's been a great experience - thanks!

This suggests a better behavior for creating a link with a trailing "/" too: have it access/create an index.md in that directory.

I'm :+1: on this as I just mentioned in the other issue, but I haven't started working on it yet. Right now only the root looks for index.md. I like the trailing slash idea and think it's the way to go, just fits perfect with the spirit of everything.

I'm enjoying using your wiki, and learning about this Rust web framework too. I have migrated my "home wiki" over from Decko - it's been a great experience - thanks!

Great, I'm happy to hear that! Decko looks interesting - I do want to add different ways to visualize pages and their relationships eventually, particularly some kind of vertical / card view. But right now I'm focused on the web environment and the core deadwiki workflow, which I don't think is fully there yet.
Anyway the index.md feature is now in master so I'm going to close this, unless you have more ideas. I think all the subdirectory support is maybe a separate, larger issue. Thanks again!


TabError: inconsistent use of tabs and spaces in indentation

Looked at the suggestions in #12 but still get issues below @mrdehate

C:\sms\hangouts_to_sms-develop>python hangouts_to_sms.py
Traceback (most recent call last):
File "hangouts_to_sms.py", line 2, in
from titanium_backup_formatter import TitaniumBackupFormatter
File "C:\sms\hangouts_to_sms-develop\titanium_backup_formatter.py", line 83
message_string += "{}".format(escape(message.content) if content_is_plain else self._base64_text(message.content))
^
TabError: inconsistent use of tabs and spaces in indentation

here is the code snippet

replaced all tabs with 4 spaces in file to resolve issue

Using reindent.py


Fix/add msg value type

name: "Pull request"
about: A new pull request
New Pull Request
Checklist

[x] I am not disclosing a vulnerability.
[x] My code is conform the code style
[x] I have made corresponding changes to the documentation
[x] I have updated Typescript definitions when needed

Issue Description
Add missing msgValue type for useWeb3ExecuteFunction
Related issue: https://github.com/MoralisWeb3/react-moralis/issues/119

:tada: This PR is included in version 0.4.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Adds 'promised' type to better handle promise resolution and await

Following the discussion in https://github.com/Microsoft/vscode/issues/30216, I noted that the Promise definition in VSCode was out of date. I created https://github.com/Microsoft/vscode/pull/30268 to address this and ran into a number of cases where I had to add explicit type annotations to work around limitations in the checker.
As a result, I discovered two classes of issues with how we handle resolution for Promise-like types:

Incorrect return types or errors with complex Promise chains created via then().
Incorrect eager resolution of the "promised type" for a type variable.

To that end, I am introducing two features into the compiler:

A promised T type operator, used to explicitly indicate the "promised type" of a type
following the same type resolution behavior as the await expression and providing an explicit
parallel in the type system for the runtime behavior of await.
A PromisedType type in the checker, used to defer resolution of the "promised type" of a type
variable until it is instantiated as well as to better support type relationships.

Incorrect return types or errors with complex Promise chains
The then() method on Promise currently has the following definition:
interface Promise<T> {
    then<TResult1 = T, TResult2 = never>(
        onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | undefined | null,
        onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
    ): Promise<TResult1 | TResult2>;
}

Generally, this works well if the return statements in the function passed to onfulfilled are simple:
declare const pr: Promise<number>;

pr.then(x => {
    if (x < 0) return "negative";
    return x;
}).then(y => {
    y; // string | number
});

However, the following results in errors:
declare function f(x: number): Promise<string>;
declare const pr: Promise<number>;

// error: Argument of type '(x: number) => number | Promise<string>' is not assignable to parameter
// of type '(value: number) => string | PromiseLike<string>';
pr.then(x => {
    if (x < 0) return f(x);
    return x;
});

To resolve this, this PR adds a new promised T type operator that allows a developer to more
reliably indicate the type that would be the result of the implicit unwrapping behavior inherent to both Promise resolution as well as the await expression.
This allows us to update our definition of Promise to the following:
interface Promise<T> {
    then<TResult1 = T, TResult2 = never>(
        onfulfilled?: ((value: promised T) => TResult1) | undefined | null,
        onrejected?: ((reason: any) => TResult2) | undefined | null
    ): Promise<promised TResult1 | promised TResult2>;
}

With promised T, regardless what type you specify for T, the type of value in the
onfulfilled callback will be recursively unwrapped following the same mechanics of await (which
in turn follows the runtime behavior of the ECMAScript specification).
In addition, the much simpler return types of the onfulfilled and onrejected callbacks allow
for more complex logic inside of the bodies of the callbacks. The complex work of unwrapping the
return types of the callbacks is then pushed into the return type of then, where the promised
types of TResult and TResult2 are resolved.
As such, we can now infer the correct types for the above example:
declare function f(x: number): Promise<string>;
declare const pr: Promise<number>;

pr.then(x => {
    if (x < 0) return f(x);
    return x;
}).then(y => {
    y; // string | number
});

Incorrect eager resolution of the "promised type" for a type variable
This brings us to the second issue this PR addresses. The underlying implementation of await in
the type checker already recursively resolves the "promised type" of an expression. For example:
async function f(x: Promise<Promise<number>>) {
    const y = await x;
    return y; // number
}

declare const a: Promise<Promise<number>>;

f(a).then(value => {
    value; // number
});

However, it can fall short in cases where generics are concerned:
async function f<T>(x: Promise<T>) {
    const y = await x;
    return y; // T
}

declare const a: Promise<Promise<number>>;

f(a).then(value => {
   value; // Promise<number> !!!
});

The reason we get the wrong type in the second example is that we eagerly get the "promised type"
of x, which is T. We cannot further resolve T as it has not been instantiated, so the
return type of f becomes Promise<T>. When we supply a nested promise type to f, we assign
the type MyPromise<number> to T which then instantiates the return type of f(a) as
Promise<MyPromise<number>>!
To address this, TypeScript will now internally have the concept of a PromisedType which indicates
the deferred resolution of the "promised type" of a type variable. As a result, whenever you await
an expression whose type is a type variable, or whenever we encounter a promised T operator for a
type variable, we will internally allocate a PromisedType for that type variable. Once the type
variable is instantiated, the "promised type" will be resolved.
With this change, the failing example above now has the correct type:
async function f<T>(x: Promise<T>) {
    const y = await x;
    return y; // promised T
}

declare const a: Promise<Promise<number>>;

f(a).then(value => {
   value; // number
});

This also allows us to more accurately check type relationships between the "promised types" of
two generics, following these rules:

When relating two types S and T, where S is the source type and T is the target:

promised S is related to promised T if S is related to T.
S is related to promised T if S is related to promised C, where C is the constraint of T.
promised S is related to T if promised C is related to T, where C is the constraint of S.

Out of scope
One thing this PR does not cover is attempting to recursively unwrap the T of a Promise<T> when
explicitly written as such by the user. Generally this is considered unnecessary as the T will be
unwrapped when using then() or catch():
const p1 = new Promise<Promise<number>>(resolve => resolve(Promise.resolve(1)));
const p2 = p1.then(); // Promise<number>

Bear in mind that this means that though p1 in the example above has the type
Promise<Promise<number>>, p2 will have the type Promise<number>. It may seem counter-
intuitive, but this is the correct behavior and mitigates the need to add syntax to unwrap
type parameters.
Definitions

onfulfilled callback - The first callback passed to the then() method of a promise.
The callback accepts a single value parameter which is the fulfilled value of the promise.
fulfillment type - The explicit type of the value parameter for the onfulfilled callback of a promise.
promised type - If a type T is promise-like, the promised type of the fulfillment type of T; otherwise, T.
recursive unwrapping - The process of resolving the promised type above.

Will need to remember to make an issue to remove the --exclude 'src/lib/es2015.iterable.d.ts' --exclude 'src/lib/es2015.promise.d.ts'" from the build once tslint is updated with a nightly that understands the new syntax.
Bikeshed: Is there a reason it's promised T rather than await T (to mirror the expression syntax)? It seems apt, especially when it's used to describe the behavior of the operator - similar to how we reuse this in type positions (even though it's not exactly the same, the concept is analogous).

Problem 1 may be among the many issues that could also be solved given #6606:
interface UnwrapPromise {
  <U>(v: PromiseLike<U>): UnwrapPromise(U); // try unwrapping further, just in case
  <U>(v: U): U;
  // ^ else case: can't unwrap, so no-op
};
// ^ function type used to unwrap promise types
interface Promise<T> {
    then<TResult1 = T, TResult2 = never>(
        onfulfilled?: ((value: T) => TResult1) | undefined | null,
        onrejected?: ((reason: any) => TResult2) | undefined | null
    ): Promise<UnwrapPromise(TResult1) | UnwrapPromise(TResult2)>;
}

Since this approach does not rely on TResult1 | PromiseLike<TResult1> for unwrapping, a return type like number | Promise<string> should automatically pass through UnwrapPromise yielding number | string, as intended.
I'm not so much expecting the approach to change for this current in-progress PR; I'm just under the impression that particular proposal has been somewhat under-appreciated given what it could address.

It'd be really nice if you could solve these problems by making the overall type system sufficiently expressive, rather than adding magic user-inaccessible types.

I concur with @masaeedu. It's a rather brute force/patchy solution that might become a considerable debt in the near future.

@masaeedu, my intention here is to make the type system more expressive. This introduces a type-system parallel to the await expression, similar to keyof in the type system being a parallel to in and Object.keys at runtime. Addressing the second issue without the first would have truly introduced a user-inaccessible type.
With this change, the type system would have a mechanism to reflect at design time the behavior of both the await expression and Promise resolution that is both internally consistent and able to be expressed by the user. The previous approach of using T | PromiseLike<T> was more akin to using type-system magic to extract the correct T, but that approach only works for inference. I believe having an explicit and well-defined mechanism for reflecting this behavior at design time is the correct direction, and allows other library authors to leverage the same type language for non-native Promise implementations.

@rbuckton There is nothing in particular that is special about Promise, which is why it seems weird to make a promise T keyword instead of fixing the problems in the type system that make it impossible to express unwrapping of monadic types like Promise.

@masaeedu That's not what this proposes. It is not promise T, but rather promised T, which is intended to mean "get the underlying value of T after all recursive unwrapping of a Promise is applied".
JavaScript promises do not let you have a Promise for a Promise. Any time a Promise is settled with another Promise, the first Promise adopts the state of the second promise. This effectively unwraps the second Promise's value. Strongly typed languages like C# do not have this concept. Consider Task<T>: If you create a Task<Task<string>>, the result is Task<string> as the T cannot be unwrapped. Without a syntactic construct to represent this behavior, any other attempt to resolve this in the type system is "magic".
By introducing promised T, regardless of whether T is number, or Promise<number>, or Promise<Promise<number>>, the result of promised T would be number.
Perhaps @weswigham is correct and we need to bikeshed the keyword. Maybe promisedof T, or awaited T, etc. would be more explanatory.
Also, while Promise may be monadic, a promise-like is not. The unwrap/adopt behavior is not guaranteed in a promise-like, but that doesn't matter to a Promise, as it will continually adopt the state of any promise-like provided as the fulfillment value of the onfulfilled callback.

@masaeedu The real problem is that then does an implicit join based on the runtime value. While it makes sense for a dynamically typed language such as JS, it's really bad from a type system perspective (a separate map and bind would have been much better). Now, having this wonky runtime semantics, a patchy solution for Promise looks good at first, but I think it will become redundant and may even hinder future development if features such as conditional logic (e.g. https://github.com/Microsoft/TypeScript/issues/12424) get implemented.

@rbuckton Sorry, promise is a typo on my part, but I do understand what this is proposing: "express unwrapping of monadic types like Promise", i.e. getting T from Promise<T>. My point is that the unwrapping you are referring to, and the fact that you need to prevent Promise<Promise<T>> is not a special feature of promises: the Promise.then method is an instance of the more general monadic bind operation, which "flat maps" over the monadic type.
If you allow for type-level functions as @tycho01 has shown, you can express recursive unwrapping of the Promise type and a great number of other features besides. The fact that it becomes possible for users to correctly express flatmap over promises is simply emergent from that feature. In addition, unlike this promised keyword, that concept is agnostic to Promises themselves, it works for any monadic type; whether I'm trying to express a "list-that-is-always-flat" type, or a set, or any number of such things.

@gcnew With type-level functions, we already have a powerful way to encode base-cases for pattern matching on types: overloaded functions. This is actually very close to how type families in Haskell work, so I feel it is good enough, but I guess whether or not we need some other mechanism of conditional matching on types is a debate for a different issue (probably #12424).

whether or not we need some other mechanism of conditional matching on types is a debate for a different issue (probably #12424)

My hunch is also that with { 0: a, 1: b }[c] plus the demonstrated overloaded functions we might already have enough to cover conditional logic... which isn't to say no additional syntax sugar like c ? a : b could be added, but I guess with 6606 we could just make type If<Cond, Then, Else> = { (v: true) => Then; (v: false) => Else }(Cond); anyway.

Open items from design meeting on 2017-08-04:

[ ] Review high-order type relationships for correctness.
[ ] Bikeshed on operator name. Options discussed included:

promised T (current)
promisedof T
await T
fulfilled T

In the design meeting on 2017-08-25 we decided on the name awaited T

I now got to the point of being able to try that UnwrapPromise idea for a more general solution. Unfortunately it is not automatically union-proof as I had hoped. Trying to think of potential solutions.

if #21613 lands, that should probably address the issues raised here.

@tycho01, we discussed this in our last design meeting and unfortunately there are still [issues] (https://github.com/Microsoft/TypeScript/pull/21613#issuecomment-363526656) with higher-order assignability between generic Promise<Awaited<T>> and Promise<T> that aren't currently resolvable without some kind of additional syntax. It may be that a syntactic awaited T is still necessary.

With conditional types in now, we might want to rethink our approach here. closing the PR for house keeping purposes since it is unactionable at the moment, but leaving the branch for further investigations.

We may still need to pursue this approach given the fact that conditional types cannot solve this.


Add a design docs page

Signed-off-by: Julien Pivotto<EMAIL_ADDRESS>

I will add more design docs once we agree on the principle.

I think the thing is good, just those nits.
Sent by mobile; please excuse my brevity.
On Sat, May 29, 2021, 01:09 Julien Pivotto @.***> wrote:

I will add more design docs once we agree on the principle.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/docs/pull/1961#issuecomment-850714709, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFYII4ZC2UTYMHSW3FSO33TQAPDPANCNFSM45XTOQTQ
.

Looks great in general.
Do you want to fill in more design docs here right now? Or do that in later PRs?

In case it's useful, here my brainstorm:

prometheus/client_java & micrometer (status: under review, I guess): https://docs.google.com/document/d/1vROky2aIw3kAllfi95gwDJy5P2DyWnCihsjPXGpLwwo/edit#
Configuration handling in exporters and Prometheus 3.x (status: under review): https://docs.google.com/document/d/1BK_Gc3ixoWyxr9F5qGC07HEcfDPtb6z96mfqoGyz52Y/edit#heading=h.zcana55kzmxi
http_sd_configs (status: under review, being implemented): https://docs.google.com/document/d/1tVeuzjpU4-TiYPNWJXKmcyIuZF6A2tUq270RbBT5zho/edit
Prom Agent (status: approved, more or less, and being implemented): https://docs.google.com/document/d/1cCcoFgjDFwU2n823tKuMvrIhzHty4UDyn0IcfUHiyyI/edit
Sparse high-resolution histograms (status: approved): https://docs.google.com/document/d/1cLNv3aufPZb3fNfaJgdaRBZsInZKKIHo9E6HinJVbpM/edit
OpenMetrics transition (status: TODO): (as per dev-summit consensus: "We will create a design document exploring upgrade paths.")
Metadata (status: empty, oops): https://docs.google.com/document/d/1XiZePSjwU4X5iaIgCIvLzljJzl8lRAdvputuborUcaQ/edit
topk/bottomk aggregation over time (status: implemented): https://docs.google.com/document/d/1uSbD3T2beM-iX4-Hp7V074bzBRiRNlqUdcWP6JTDQSs/edit
Semantics of muting in Alertmanager (status: TODO): (as per dev-summit consensus: "We will create a document for the community to collect current pain points and desired behaviour"
First-class network monitoring support in the Prometheus & Grafana ecosystem (status: under review): https://docs.google.com/document/d/1oEpjiWfTHF352NCAOGolwij3EIkrprCkdQmaQMpjg4M/edit
Persist Retroactive Rules (status: approved, partially implemented): https://docs.google.com/document/d/16s_-RxYwQYcb4G4mvpmjPolEbD24o54a1LPqJ538Vhc/edit
TSDB Head Improvements (status: implemented, at least partially, or all? paging @codesome ): https://docs.google.com/document/d/184urkLQnM7rqLmGvS66I15jU2pyPk_qwd8v_qDlXczo/edit# and https://docs.google.com/document/d/1pnEsxB0CDLOxQipGw_vhkJpoDZfZPs_KjqCriumDAXQ/edit

(This is not meant to be a complete list. ;)

Secure Alertmanager cluster traffic (status: being implemented in https://github.com/prometheus/alertmanager/pull/2237): https://github.com/prometheus/alertmanager/blob/master/doc/design/secure-cluster-traffic.md

TSDB Head Improvements (status: implemented, at least partially, or all? paging @codesome ): https://docs.google.com/document/d/184urkLQnM7rqLmGvS66I15jU2pyPk_qwd8v_qDlXczo/edit# and https://docs.google.com/document/d/1pnEsxB0CDLOxQipGw_vhkJpoDZfZPs_KjqCriumDAXQ/edit

Only the m-mapping of "full" chunks is done among them. The idea about "partial chunks" is in-progress (the snapshot PR).
Plus, everything in that doc is not planned to be implemented (for example the number 5 in second doc about series and tombstones). And the doc might/will not be 100% in sync with what was finally implemented or being implemented.

Thanks @codesome .
I guess a certain degree of "we did this differently after all" is inherent to most design docs. So I don't think we have to call that out explicitly (but perhaps it's worth mentioning in the preamble on this page?).

An now there is the goreleaser design doc.
List is growing quickly. I guess it makes sense to merge this rather sooner than later so that we all can iterate on it easily.
(But see my syntax remarks above. And my question if we can't just use markdown tables, which would avoid those syntax quirks altogether.)

I guess we should also add a TODO entry for reconsidering extrapolation with range selectors (rate/increase/delta) AKA "the (x)rate controversy". At the dev summit 2020/2, we stated: "We want to rethink this from first principles. We will collect our research, thoughts, considerations, and results in 'Prometheus is not feature complete' and discuss at a future dev summit."
I think the topic deserves a fully fledged design doc. I guess we just hadn't developed the habit back then and thought, we could shove it in that existing "Prometheus is not feature complete" document.

Thanks!

Thanks!

I hated this :)

Note: in my last push, I have used "unbreakable dashes" instead of "dashes" for the dated. It keeps them on the same line in the page, I think it renders better.


New component: Slider

I would like to use it to change font-size line-height and similar in an ebook reader webapp I'm creating. Thanks ^^
References:
https://vuetifyjs.com/en/components/sliders/#usage
https://mui.com/material-ui/react-slider/

(from firefox devtools)

I'm working on notification component requested by our sponsor @husayt ATM. Will add this after we finish that 👍🏻
Thanks for your suggestion 😇

thanks @jd-solanki. both components would be very appreciated. They are part of essential set, I believe. Once library has all the essential ones in its list, then it's ready for wider adoption.

Hey, @husayt @jsmnbom We now have enough browser mode support in vitest. I will write more tests and make the anu more robust. Additionally, I will also try to add accessibility support on the way as much as I can. So I might have to introduce this in upcoming releases later.
I hope you understand. Awaiting your response 👀

that's totally valid yea ^^


Package proposal: blobrunner64.vm

Package Name
blobrunner64
Tool Name
blobrunner64
Package type
ZIP_EXE
Is the tool a console application?
false
Tool's version number
0.0.5
Category
Utilities
Tool's authors
OALabs
Tool's description
BlobRunner is a simple tool to quickly debug shellcode extracted during malware analysis.
Download URL
https://github.com/OALabs/BlobRunner/releases/download/v0.0.5/blobrunner64.zip
Download SHA256 Hash
325e3e26ccdce53cdd8b6665c7ed7d1765fc1c56cd088a5b4433593682c9f503
Dependencies
No response
Why is this tool a good addition?
This quote from BlobRunner's README says it all:

BlobRunner is a simple tool to quickly debug shellcode extracted during malware analysis. BlobRunner allocates memory for the target file and jumps to the base (or offset) of the allocated memory. This allows an analyst to quickly debug into extracted artifacts with minimal overhead and effort.

See #825 for 32-bit version.

@mike-hunhoff do we want to install both the 32 and the 64 versions?

@mike-hunhoff do we want to install both the 32 and the 64 versions?

Yeah my experience is that I've needed the 32-bit blobrunner for 32-bit shellcode and vice versa.

@mike-hunhoff

Yeah my experience is that I've needed the 32-bit blobrunner for 32-bit shellcode and vice versa.

Thanks for the info @mike-hunhoff! Then I suggest that we add a blobrunner.vm packages that installs both version. @mandiant/flare-vm does this sound good? 😄

ok, thanks @mike-hunhoff! I think both are console app applications. Other than that the information LGTM!


huggingface demo has an error

it has an error when I want to try its inpinting
https://huggingface.co/spaces/shgao/EditAnything

Can you give me more details? I didn't find the error you mentioned. Thanks!

when I input image, mask, and prompt, I got an error when I submit this task, it has no error a week ago, maybe the reason is that you update the sam2edit.py recently

when I input image, mask, and prompt, I got an error when I submit this task, it has no error a week ago, maybe the reason is that you update the sam2edit.py recently

Can you give me a screenshot of how you use the demo?

Can you give me these two pictures? I cannot reproduce this error on my side using my image and mask.

Can you please test on the gradio demo again? Maybe the error is caused by the network instability. I tried your image and mask on the demo site, and it works.

OK， I will try again,  but the demo has an error now
https://huggingface.co/spaces/shgao/EditAnything


How to preview changes for a PR using the demo

Hello, I've forked your library to create a PR but I can't preview the changes I wanted to implement. Trying to run the demo I get this error:
Module not found: Can't resolve 'material-ui-pickers' in 'D:\projects\material-ui-pickers\docs\src\Demo'
I also tried using symlinks but with no luck, webpack import the components as they are a static asset.
How can I run the demo locally?

Hi!
First of all want to thanks for contributing 🎉
First of all you need to link material ui pickers from root
npm link

Than do
cd docs && npm link material-ui-pickers

Thats it!

Also I have updated documentation for docs folder
https://github.com/dmtrKovalenko/material-ui-pickers/blob/master/docs/README.md

Thanks, it's working now!


Bones do what they want

Godot Version 3.2.1 x64
Linux Mint 19.3 Tricia
First child of Skeleton 2D move correctly but other bones move weird and diferent between them. This results in unpredictable behavior when I try to create an animation.
https://www.youtube.com/watch?v=JO6fGsY-Uaw

I solve it. The bones had an enlarged scale and that caused them to malfunction. Sorry


RuntimeException while uploading image if the license if invalid

Summary:
While uploading a media, if the license is somehow invalid we throw a RuntimeException and as it is not handled, the app crashes
Steps to reproduce:
How can we reproduce the issue?
Provide invalid license while uploading image.
System logs:
java.lang.RuntimeException: Unable to resume activity {fr.free.nrw.commons/fr.free.nrw.commons.upload.UploadActivity}: java.lang.RuntimeException: Unrecognized license value: CC BY-SA
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3421)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3461)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2730)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1473)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6123)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)
Caused by: java.lang.RuntimeException: Unrecognized license value: CC BY-SA
at fr.free.nrw.commons.Utils.licenseUrlFor(Utils.java:135)
at fr.free.nrw.commons.upload.UploadActivity.updateLicenseSummary(UploadActivity.java:275)
at fr.free.nrw.commons.upload.UploadPresenter.updateLicenses(UploadPresenter.java:335)
at fr.free.nrw.commons.upload.UploadPresenter.addView(UploadPresenter.java:312)
at fr.free.nrw.commons.upload.UploadActivity.lambda$checkStoragePermissions$2$UploadActivity(UploadActivity.java:204)
at fr.free.nrw.commons.upload.UploadActivity$$Lambda$4.run(Unknown Source)
at fr.free.nrw.commons.utils.PermissionUtils$1.onPermissionGranted(PermissionUtils.java:77)
at com.karumi.dexter.MultiplePermissionsListenerToPermissionListenerAdapter.onPermissionsChecked(Unknown Source)
at com.karumi.dexter.DexterInstance$1.run(Unknown Source)
at com.karumi.dexter.MainThread.execute(Unknown Source)
at com.karumi.dexter.DexterInstance.checkMultiplePermissions(Unknown Source)
at com.karumi.dexter.DexterInstance.checkPermissions(Unknown Source)
at com.karumi.dexter.Dexter.check(Unknown Source)
at fr.free.nrw.commons.utils.PermissionUtils.checkPermissionsAndPerformAction(PermissionUtils.java:103)
at fr.free.nrw.commons.upload.UploadActivity.checkStoragePermissions(UploadActivity.java:202)
at fr.free.nrw.commons.upload.UploadActivity.onResume(UploadActivity.java:190)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1291)
at android.app.Activity.performResume(Activity.java:6776)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3398)
... 10 more
java.lang.RuntimeException: Unrecognized license value: CC BY-SA
at fr.free.nrw.commons.Utils.licenseUrlFor(Utils.java:135)
at fr.free.nrw.commons.upload.UploadActivity.updateLicenseSummary(UploadActivity.java:275)
at fr.free.nrw.commons.upload.UploadPresenter.updateLicenses(UploadPresenter.java:335)
at fr.free.nrw.commons.upload.UploadPresenter.addView(UploadPresenter.java:312)
at fr.free.nrw.commons.upload.UploadActivity.lambda$checkStoragePermissions$2$UploadActivity(UploadActivity.java:204)
at fr.free.nrw.commons.upload.UploadActivity$$Lambda$4.run(Unknown Source)
at fr.free.nrw.commons.utils.PermissionUtils$1.onPermissionGranted(PermissionUtils.java:77)
at com.karumi.dexter.MultiplePermissionsListenerToPermissionListenerAdapter.onPermissionsChecked(Unknown Source)
at com.karumi.dexter.DexterInstance$1.run(Unknown Source)
at com.karumi.dexter.MainThread.execute(Unknown Source)
at com.karumi.dexter.DexterInstance.checkMultiplePermissions(Unknown Source)
at com.karumi.dexter.DexterInstance.checkPermissions(Unknown Source)
at com.karumi.dexter.Dexter.check(Unknown Source)
at fr.free.nrw.commons.utils.PermissionUtils.checkPermissionsAndPerformAction(PermissionUtils.java:103)
at fr.free.nrw.commons.upload.UploadActivity.checkStoragePermissions(UploadActivity.java:202)
at fr.free.nrw.commons.upload.UploadActivity.onResume(UploadActivity.java:190)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1291)
at android.app.Activity.performResume(Activity.java:6776)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3398)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3461)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2730)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1473)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6123)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)

Device and Android version:
WUSER_COMMENT=
ANDROID_VERSION=7.0
BRAND=motorola
PHONE_MODEL=Moto G (4)
Commons app version:
APP_VERSION_NAME=2.10.2
Would you like to work on the issue?
Yes

@maskaravivek @misaochan @neslihanturan @nicolas-raoul, The crash is because, license urls for "CC BY" & "CC BY-SA" is not handled. Does any one knows what url's need to be returned for these license names?

The Upload Wizard uses https://creativecommons.org/licenses/by-sa/4.0/deed.en for CC BY SA 4.0, and https://creativecommons.org/licenses/by/4.0/deed.en for CC BY 4.0, so I think we can go with that. For 3.0 just replace the corresponding string in the URL.

@misaochan Thanks JO,  but the app already had the same for CC BY SA 4.0 and CC BY 4.0, the ones matching exactly "CC BY" & "CC BY-SA" are not there. Seems like they are deprecated. I was wondering if it will be okay to use the ones for CC BY SA 4.0, and CC BY 4.0 respectively ?

I don't think there is a need for a "CC BY" & "CC BY-SA" license without any version number. The Upload Wizard only has 3.0 and 4.0 for these corresponding licenses, and CC0 (so 5 licenses in total). In fact I don't think there is even a legal definition for "CC BY" without a version? Let's ask @nicolas-raoul to confirm.

"CC BY" & "CC BY-SA" are not valid license, they must not be applied to any of our uploads.
Was the image that triggered the RuntimeException uploaded from the app? Or from another tool?

Was the image that triggered the RuntimeException uploaded from the app? Or from another tool?

I am not sure about that, the logs are not sufficient to conclude that, if they are not valid licenses, can we remove it from the list of valid license names from the license drop down shown in the upload?

If the image is triggering the exception via UploadActivity, it would be uploaded via the app, right?

if they are not valid licenses, can we remove it from the list of valid license names from the license drop down shown in the upload?

@ashishkumar468 I am not seeing "CC BY" or "CC BY SA" in the license drop down shown in step 3 of the upload at all. Do you see it? I only see the 5 options that are similar to upload wizard.

@misaochan We do not show it in the drop down, but the old images which are already licensed by them , the app needs to recognise with their license as well. Are we supposed to update the license of one of the defaults from the app or is there a better way to handle this ?

@misaochan  @nicolas-raoul I have probably found the root cause for the issue. For some of the users who have been using the app since a long time, the older licenses ("CC BY" & "CC BY-SA"), were most probably stored by the BasicKvStore which when being applied while upload used to throw a RuntimeException. I have added a PR for the same to remove the deprecated licenses and use the default one (CC_BY_SA_4 (the one used by the commons web app)). Please let me know if this needs to be improved.

Makes sense. Thanks @ashishkumar468 . :) I'll close this issue now that your PR is merged.


Bun support?

With bun v1.0 officially out, do you plan to add a bun support option? Maybe the plugin auto-configures based on how it was invoked (if thats possible)... I can try to make the PR if you want.

Hi, sorry for such late response. I don't think there is anything to do in regards to bun support. vite-express can be used with it out of the box, just as in node (at least default template generated by bun create vite-express is working just fine.
If you have any idea how would that integration look like or work, I'd be happy to listen and also accept any kind of PR!

I ran into some sort of issue but can't remember what it was. I'll try to find it again sometime. Will close this for now.

Sure thing! As soon as something will pop up let me know. I promise, I won't take that much time to respond next time 😅


Feature/maps

@Schmluk about 90% there on the maps; just need to actually take care of printing keys instead of indices (and cleaning up some unintended changes). Will pick this up and finalize it tomorrow morning

@Schmluk should be ready. I opted to rework how the ADL dispatch works, which lets us now define specializations before declare_config is actually defined (which is useful for stl types). I think this is cleaner (it lets us directly use setValues and getValues on vectors and maps), but lmk if you feel different