Restrict XCC mapping to gfx942

The feature currently only applies to gfx942 and is untested on older architectures. Add reject case for other architectures for now until the feature is fully tested on those devices.

Does sk test pass on 90a with this change?
I thought it would generate an error if no kernel was generated.

I think you were trying to fix extended, right?  So I added the label.

Does sk test pass on 90a with this change? I thought it would generate an error if no kernel was generated.

90a tests are in progress.

I am thinking it might better to just skip the sk test cases for now.
We need to change the code again when we have new architectures.
We can put some comment in common.py to let users know this is verified on gfx942 only.

Does sk test pass on 90a with this change? I thought it would generate an error if no kernel was generated.

Yes it passes on 90a with this change. The test files you mentioned include both test cases for xccmapping=0 and 8. Tests with xccmapping enabled hang on gfx90a. Though it doesn't make sense to use the feature on 90a, it's possible the hang could also happen in other configurations as well so I've created a ticket to debug the issue. For now, the feature works in standard use-cases for 942 so this change restricts it to that until more testing is done.

Looks good, makes sense.
+1 Koji's comment, a config-level system to filter capabilities (e.g. Stream-K) for different architectures would be nice. It also speaks to our goal of extending support to a wider set of architectures.

Looks good, makes sense.
+1 Koji's comment, a config-level system to filter capabilities (e.g. Stream-K) for different architectures would be nice. It also speaks to our goal of extending support to a wider set of architectures.

There is a system for this already. We can filter features based on the "AsmCaps" which poll for capabilities available on a given compiler+architecture. This system is preferred over checking for a specific architecture number, because sometimes features are not necessarily architecture specific but based on rocm versions. Also some architectures can have multiple variants with different capabilities.
For this change, the goal is to have all stream-k features working on all hardware, so this change is temporary (and hopefully to be improved soon). Also, I couldn't think of a specific asm cap that related to this feature in a way that made sense, so just wrote it to check the ISA for now.


Add emmet support to html editor in web ui

See https://github.com/emmetio/codemirror

Now will be https://github.com/emmetio/codemirror-plugin

I think this is closed with #11366
feel free to ask for reopen if this is not the case


Add files via upload

https://github.com/adobe/xdm/issues/1008

@jbranson000 , few general comments/questions on these Schemas.

The Schema Ids need to be unique, Please fix the schema Ids in your file, Are are defined as
"$id": "https://ns.adobe.com/xdm/mixins/experienceevent-social"

Schema names doesn't need to be camel case. it could be defined for example as
"$id": "https://ns.adobe.com/xdm/mixins/experienceevent-advertising-details"

I see all the schemas are created as mixins. Is there a need of these many mixins or they could be combined under one mixinn with each property referring a data type ? My concern here is that if the customers would use multiple  (or may be all) mixins to compose their scehemas, then too many mixins might be overwhelming to start with.

I see, you are defining just 1 property per mixin and that too is referring to a data type. Is there a use case that these data types would be used outside these mixins ? If no, then could you just put the properties from the data types at the root of each mixin ?

I am assuming, you are yet to create the schemas for each data type right ?

@jbranson000 , few general comments/questions on these Schemas.

The Schema Ids need to be unique, Please fix the schema Ids in your file, All are defined as
"$id": "https://ns.adobe.com/xdm/mixins/experienceevent-social"
I updated the script that is generating the JSON to properly define the IDs - this should be resolved now.
Schema names doesn't need to be camel case. it could be defined for example as
"$id": "https://ns.adobe.com/xdm/mixins/experienceevent-advertising-details"
I also update the script to make sure camelCase was not being used for the name.
I see all the schemas are created as mixins. Is there a need of these many mixins or they could be combined under one mixin with each property referring a data type ? My concern here is that if the customers would use multiple  (or may be all) mixins to compose their schemas, then too many mixins might be overwhelming to start with.
These mixins are being setup to be used in various verticals - and when we were defining them we tried to keep them as granular as possible to give the clients more flexibility as they incorporated them into their own schemas.  They could probably be combined per vertical when after we include the vertical metadata tags.
I see, you are defining just 1 property per mixin and that too is referring to a data type. Is there a use case that these data types would be used outside these mixins ? If no, then could you just put the properties from the data types at the root of each mixin ?
Yes, several data types that we are creating will be used outside these mixins.
I am assuming, you are yet to create the schemas for each data type right ?
I have not created any data types yet, although we do have them defined in our workbook.


User Testing Video - Galaxy Note - Weird ~Slowness

It's not actually slowness, but something is preventing the scroll from continuing
About a year ago, I was very deeply involved with iscroll dynamics, but right now, I just hope there is a simple cause and solution
Here's the video, any ideas?
https://www.geobird.com/s/5571576403853312

Seems that adding "touch-action: none;" on the main div solves the problem ... https://github.com/cubiq/iscroll/issues/1135
Could that be solved without this hack ? ping @sculove

@MJBGO Sorry for the late replay. you're right.
The version of Google Chrome is updated quickly, but the iscroll is difficult to respond effectively.
and the iscroll does not respond quickly to browser changes.
I tried to write the test code, but I can not afford it.
@cubiq is also like that.
I am now trying to find a better way.

Yes, indeed the proposed solutions does solve the issue well
It's indeed extremely hard to keep up with HTML technologies in general, mobile devices, highly segmented android devices, and now webkit itself started breaking things ...

Hi There,
Met same issue here... The slowness happens on mobile devices while it's totally OK on desktop chrome. Tried "touch-action:none" but it didn't work this time - First, adding it to the wrapper's CSS touch-action will get covered by iScroll's own touch-action. Second, even if I manually change it to "none", the slowness is still there.
Any ideas?


Simplify boilerplate

[x] Just use npm scripts instead of gulp

[x] webpack, webpack-dev-server, eslint, mocha, crx use CLI tool instead.
Move replace-webpack-code to webapck config, it's sync code of purely.
Don't use jade, just use chrome/*.html, dist/*.html.
No manifest.{env}.json, just use chrome/manifest.json, dist/manifest.json

[x] Remove redux-devtools monitor dependencies, and recommend use redux-devtools-extension.
[ ] Implement all #8 tasks.

any news on this?


Fix ctr using overlayfs on zfs

Some ctr commands use a snapshotter locally. By default this is overlayfs, but when using zfs we need to use native (or zfs) snapshotter.
#1000 fixes this issue for containerd, but ctr doesn't use the containerd config.
Commands affected by this are:

ctr containers create
ctr images check
ctr images import
ctr images pull
ctr run
ctr snapshots

Snapshotter selection should probably be consolidated into one place.

I did the consolidation of the snapshotter detection part.


/liveness endpoint

An endpoint which checks if everything needed to provide the service is there. E.g. this can check if the postgres db is reachable.
From a Kubernetes-bases article:

Liveness probe. This is for detecting whether the application process has crashed/deadlocked. If a liveness probe fails, Kubernetes will stop the pod, and create a new one.

We can use this endpoint now where we monitor /ping.

I think this task is completed:
https://github.com/FlexMeasures/flexmeasures/blob/main/flexmeasures/api/v3_0/health.py

Liveness and readiness are technically not the same, see the linked article.
We can move this issue further along and decide here:

is it a simple 200 response?
Is startup probe and liveness the same for us?

It might be simple to have an implementation here.

In our case, I think we can let both to be the same endpoint (just a 200 response).
At first, I was thinking if readiness would also test for DB connection but the POD can be up while the database is not. Kubernetes would check both services independently.

Did you mean "liveness" when you wrote "readiness"?
Because readiness is checking the database connections.

True, I was thinking more on liveness. However, it applies in both. Let's say the DB falls, the web POD could still be ready (if it could connect) so when the DB is back can work again. In case to also check the DB state in the web POD, we would restart it when it wasn't needed.


Mistake in the document of PIXI.Filter's argument

/**
 * @class
 * @memberof PIXI
 * @extends PIXI.Shader
 * @param [vertexSrc] {string} The source of the vertex shader.
 * @param [uniforms] {object} Custom uniforms to use to augment the built-in ones.
 * @param [fragmentSrc] {string} The source of the fragment shader.
 */
function Filter(vertexSrc, fragmentSrc, uniforms)

uniforms should be after fragmentSrc
The document confused me, until i saw the source code  : )

I believe this has been fixed in the latest dev. Thanks!


[Doc request] Roadmap for going live

I've come across this project as what seems to be the best attempt to work around Anaconda's change in TOS moving away from offering free hosting of conda packages.
It appears as though Quetz is not yet in production, can you confirm? This is not explicitly stated in the Readme, so I just want to make sure I'm not being stupid, not finding the link.
Maybe it'd be a good idea to be transparent about your rollout plans, how far away are you from going live? Good luck, I'm happy to see someone is working on breaking Anaconda's unhealthy monopoly on conda package hosting.

the best attempt to work around Anaconda's change in TOS moving away from offering free hosting of conda packages.

This project does not really have to do with the Anaconda terms of services (also, I don't think that the recent change really has much impact on e.g. conda-forge and other open-source hosting).
However, deploying an instance of a Quetz server is a good way to host conda packages if you are unhappy with other solutions.

It appears as though Quetz is not yet in production, can you confirm? This is not explicitly stated in the Readme, so I just want to make sure I'm not being stupid, not finding the link.

Quetz is a open-source project that implements a conda package server. There is not a public-facing deployment of Quetz at the moment - if that is the question, besides test instances used for development and testing.

Maybe it'd be a good idea to be transparent about your rollout plans, how far away are you from going live?

Some people have plans for public-facing hosting of Quetz instances, but it is somewhat independent from the software project.

hi @corneliusroemer, if you plan to deploy your instance of quetz, we have some docs that may help: https://quetz.readthedocs.io/en/latest/
Please don't hesitate to ask if something is not clear, or find some missing information.


How can i pass extra parameter when color changed?

Hello
I want to pass some addition parameter like this when the color changed?
<color-picker` ng-model="account_type.type_color" options="options" event-api="eventApi(extraParameter)">
Can you please help me solve this issue?
Thanks

@jaydeeptops See this example html and javascript for how to use the event api. Let me know if that helps you or not.

@ruhley
Let me brief about the scenarios.
In my project, I have 3 buttons of the color picker. As per event, I am getting which color selected in the onchange event but i need something to pass in the event api that which button type clicked. Like i have 3 buttons A, B, C. When color changed for A button then I want to pass type A in the onchange event. Can you please provide me a solution how can I pass it?
Thanks

@jaydeeptops I think you would have to create separate event apis and do something like this
$scope.onChange = function (color, type) {
    console.log(color, type);
};

$scope.eventApiA = {
    onChange: function(color) {
        $scope.onChange(color, 'A');
    }
};

$scope.eventApiB = {
    onChange: function(color) {
        $scope.onChange(color, 'B');
    }
};

$scope.eventApiC = {
    onChange: function(color) {
        $scope.onChange(color, 'C');
    }
};

Let me know if that solves it for you.

@ruhley Thanks for the solution. But is there any other solution to pass parameters in the function?

@jaydeeptops Unfortunately not.

@ruhley  Thanks for the reply.  I have implemented as you suggested.
I have one more question is there any button that I can put to save the color? Right now what happened I changed the color and it suddenly fires the onchange event of the apiEvent function. But I want to put one select button if the user confirmed which color he need then he clicked on save.

In the click event of the other button you should be able to get the value from ng-model without using the onChange event - https://github.com/ruhley/angular-color-picker/blob/master/examples/01-simple.html#L254 and https://github.com/ruhley/angular-color-picker/blob/master/examples/app.js#L29


Generate typed return values for arrays.

Fixes #38.

NVM, godot does not make this so easy: https://github.com/godotengine/godot/issues/72627


Add support for ES modules

Hi
First of all, thank you for your efforts. Working with tsconfig paths is very frustrating and your module is the closest one to work for me, out of 5 different ones I had to try.
But in order to compile to ES modules, we have to use relative paths, including a .js extension.
Example
Imagine I have two files:
src/
├ compiler/
│   └ index.ts
└ bin/
    └ index.ts

And a tsconfig.json like the following:
{
  "compilerOptions": {
    "module": "ESNext",
    "baseUrl": ".",
    "paths": {
      "compiler/*": ["src/compiler/*"],
    }
  }
}

If I have an import like this
// src/bin/index.ts
import { compile } from "compiler/index.js"; // actual file is src/compiler/index.ts

It should resolve to this:
// src/bin/index.ts
import { compile } from "../compiler/index.js";

Basically we have to import the file with a .js extension, even though the actual file has a .ts extension.
This currently does not work because of the existsSync() check in generateChanges.ts, which adds ext to the modulePath that already has the .js extension from the import.
https://github.com/benyap/resolve-tspaths/blob/5754ef5052477bfa4a9821b19302dfa6f998a783/src/steps/generateChanges.ts#L143
Furthermore the file extension currently gets removed in the replaced path but the file extension should stay as it is in the original import.

Hey @schoero, thanks for raising this issue. Appreciate the detail you've provided too - very helpful especially if it's something I'm not familiar with! Will look into this as soon as I can when I have time.
In the mean time, if you have any more examples, test cases or edge cases you can think of, please let me know as they'll be invaluable when I get around to implementation and testing.

Hi @benyap, thank you for your response. No pressure from my end. I got it working for my use case with some quick and dirty changes. They also pass the existing tests :)
I currently only have one project that outputs ES modules and uses the "paths" feature of TypeScript and I didn't had too much time to think about this in the last few days, so I can't provide much more information right now.
But I will get back to this as soon as possible.

TypeScript imports are also based on how nodejs resolve commonjs modules, but nodejs uses a slightly different strategy for resolving ES modules. The biggest change is that extensions are mandatory for relative imports. I think fixing missing extensions also belongs into this package.
I think it would make sense to fix the extensions, if TypeScript always generates ES modules.

@schoero support for ES modules has been released in v0.8.0. Feel free to give it a shot and leave any feedback you have!


Add response for animated Qr tokens

This PR fixes #275 .
Added a simplified fallback on autoStartTokenRequired for backward compatiblitity (string.replace). Thought about adding another class for v5 regarding requirement or changing it on serialization but felt a bit overkill. One perhaps could add both datamembers as well.
I've tried it out with generation of qr token with:
        public AuthResponse Response { get; }

        public DateTime InitTime { get; } = DateTime.Now;

        /// <summary>
        /// Calculates QR token according to https://www.bankid.com/utvecklare/guider/teknisk-integrationsguide/qrkoder
        /// </summary>
        /// <param name="orderref"></param>
        /// <returns></returns>
        public string GetQrToken(string orderref)
        {
            if(Response?.OrderRef is string refOrderRef &&
                string.Equals(refOrderRef, orderref, StringComparison.InvariantCultureIgnoreCase) &&
                Response.QrStartSecret is string startSecret && Response.QrStartToken is string startToken)
            {
                var time = ((int)(DateTime.Now - InitTime).TotalSeconds).ToString();

                using (var mac = new HMACSHA256(Encoding.ASCII.GetBytes(startSecret)))
                {
                    var qrAuthBytes = mac.ComputeHash(Encoding.ASCII.GetBytes(time));
                    var qrAuthCode = string.Concat(qrAuthBytes.Select(b => string.Format("{0:x2}", b)));
                    return string.Join(".", new[] { "bankid", startToken, time, qrAuthCode });
                }
            }
            return null;
        }

Which works fine.

Thank you for this PR! Will try to find time during the week to review it.

Thank you for this great work @ellinge!
I've changed the base branch of your PR to a feature branch in our repo. There are a few more things related to v5.1 I'd like to add when doing this. So will continue your work from there.
Also, this release will only support 5.1 of the API - so I will remove your backward compatibility check. If support is needed for 5.0 people can always stay on their old version on NuGet.

@ellinge I'm happy to say I've just released the code in your PR to NuGet :) Thank you!
https://www.nuget.org/packages/ActiveLogin.Authentication.BankId.Api/5.0.0-alpha-2
All packages for 5.0.0 are flagged as alpha, but I'm pretty confident that the .Api package will stay pretty much solid until stable release.


How commit unmodified file to SVN

we want to commit unmodified/unchanged file over and over
How can I do that

Not a issue. It's a question. Please, next time post to the discussions.
that being said: https://stackoverflow.com/questions/206183/how-can-i-force-subversion-to-commit-an-unchanged-file


Visual-block insert does not support DEL

When inserting in visual block mode, deleting a forward character with DELETE will erase the next character for the first line, but not the ones after.
Is this a bug or intentional behavior?
Example:
abcde
abcde
abcde

with the cursor on (0,0):
<C-v>GItest<DEL><ESC>
yields:
testbcde
testabcde
testabcde

instead of the expected:
testbcde
testbcde
testbcde

The Visual-block mode insert repeats the insertion, not any other changes.
Maybe there could be another command to record the keystrokes and repeat them on the Visual range.


Adjust error message for to long/to short function.

Display expected min/max function length.
Example output:
Target: powerOfThree, Length: 33, Lines: 1
Error: Solution is too long: no more than 29 characters expected.

Landed in https://github.com/HowProgrammingWorks/Labs/commit/2dc1f1423565b3fc65e3d8da7b1a168d22dc5982


want to change about section

will give some transition ,want to

change some layout and color and want to add some hover effect.

@rani620 assigned

I am a SSOC participant.


zero byte response from server throws ugly exception

When an http server closes the connection abruptly, the thrown exception is "From argument to subbuf out of range. Is: -2, should be in 0..0":
#!/usr/bin/env perl6

use Net::HTTP::URL;
use Net::HTTP::Request;
use Net::HTTP::Transport;

my $server = start {
   my $listen = IO::Socket::INET.new( :listen,
      :localhost<localhost>,
      :localport(9999) );
   my $conn = $listen.accept;
   my $line = $conn.get;
   say $line;
   $conn.close;
};

my $url = Net::HTTP::URL.new("http://localhost:9999/");
my $request = Net::HTTP::Request.new(:$url, :body('foo'), :method('GET'), :header({}));
return Net::HTTP::Transport.new.round-trip($request);

I think it's correct to throw an exception under the circumstances, but I think this specific exception does a very poor job conveying the actual issue. A custom die along the lines of "Unexpected EOF in server response (while looking for CRLF)" whenever $buf is < 2 bytes would be a lot easier to understand :)

Seems it will not be so simple.
diff --git a/lib/Net/HTTP/Utils.pm6 b/lib/Net/HTTP/Utils.pm6
index 32baf29..20caa2c 100644
--- a/lib/Net/HTTP/Utils.pm6
+++ b/lib/Net/HTTP/Utils.pm6
@@ -16,6 +16,7 @@ role IO::Socket::HTTP {
         my $buf = $.recv(1, :bin);

         repeat {
+            note $buf.bytes;
             my $byte = $.recv(1, :bin);
             last unless $byte.DEFINITE;
             $buf ~= $byte;

After applying this diff and modifying the example script to include $conn.print("ab\r\n"); I get the following output:
GET / HTTP/1.1
1
2
3
4
0
"From argument to subbuf out of range. Is: -2, should be in 0..0
  in method get at /Users/ugexe/repos/Perl6-Net--HTTP/lib/Net/HTTP/Utils.pm6 (Net::HTTP::Utils) line 16
  in code  at /Users/ugexe/repos/Perl6-Net--HTTP/lib/Net/HTTP/Utils.pm6 (Net::HTTP::Utils) line 29
  in method round-trip at /Users/ugexe/repos/Perl6-Net--HTTP/lib/Net/HTTP/Transport.pm6 (Net::HTTP::Transport) line 30
  in block <unit> at test.pl6 line 20

so for some reason $buf loses its contents. And because a call to $.recv can return an empty Buf when its not finished reading I'm not entirely sure how I can make the necessary check (although INET sockets have been reworked since -- they used to be based on libuv async sockets -- so maybe recv(1) will block now until 1 byte is received and never return an empty Buf anymore).

$conn.print("ab\r\n") is still an illegal HTTP response, though. A legal response AT MINIMUM has:

status-line + CRLF
one or more header lines, each terminated with CRLF
CRLF indicating end of headers

... and I'm nearly certain that every case where $buf.bytes < 2 after the repeat block means the response was invalid.

(in case it's not clear, the $buf isn't losing its contents during a call to get(), it's that round-trip calls get() more than once, and the second call to get() is breaking (correctly) because of the lack of CRLF.)

(in case it's not clear, the $buf isn't losing its contents during a call to get(), it's that round-trip calls get() more than once, and the second call to get() is breaking (correctly) because of the lack of CRLF.)

🤦♂

I don't think the check can occur after the repeat block since the exception is being thrown on the conditional expression that fires the loop block. So I changed the loop construct and check for a failure when reading the subbuf but before exploding the failure with eq $CRLF


unknown revision 0x0100000D

Hi!
My Homebridge reports that my Rasperry Pi is unsupported
[11/22/2020, 1:35:26 AM] [RPi] NAME: connected to IP:8888
[11/22/2020, 1:35:26 AM] [RPi] warning: NAME: got file handle 1
[11/22/2020, 1:35:26 AM] [RPi] warning: NAME: RangeError: 0x0100000D: unknown revision
    at Function.parseRevision (/usr/lib/node_modules/homebridge-rpi/lib/RpiInfo.js:157:13)
    at Function.parseCpuInfo (/usr/lib/node_modules/homebridge-rpi/lib/RpiInfo.js:127:25)
    at RpiPlatform.checkDevice (/usr/lib/node_modules/homebridge-rpi/lib/RpiPlatform.js:236:27)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

root@raspberrypi:~# cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2835
Revision	: 100000d
Serial		: 00000000c0f62527
Model		: Raspberry Pi Model B Rev 2

root@raspberrypi:~# pigs hwver
13

Any ideas? According to https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md this is the correct revision.

000d
B
2.0
512MB
Egoman

So what’s the 1 doing in /proc/cpuinfo?  pigs hwver does report 0x0D (13) correctly, without the 1.

[11/22/2020, 7:02:08 PM] [RPi] Flightradar: connected to IP:8888
[11/22/2020, 7:02:08 PM] [RPi] warning: Flightradar: got file handle 1
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: Raspberry Pi B v2.0 (BCM2835, 512MB) - SN
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Serial Number to "..."
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Manufacturer to "Egoman"
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Model to "Raspberry Pi B"
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Hardware Revision to "2.0"
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Temperature Display Units to 0
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Heartrate to 15 seconds
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Log Level to 2
[11/22/2020, 7:02:08 PM] [RPi] Flightradar: set Smoke Detected to 0
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: warning: got file handle 1
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Current Temperature to 31.5°C
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Frequency to 700MHz
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Voltage to 1.2V
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Throttled to false
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Under Voltage to false
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Load to 1.19
[11/22/2020, 7:02:23 PM] [RPi] Flightradar: set Last Boot to "Wed Nov 04 2020 17:35:18"
[11/22/2020, 7:02:38 PM] [RPi] Flightradar: warning: got file handle 1
[11/22/2020, 7:02:38 PM] [RPi] Flightradar: set Load from 1.19 to 1
[11/22/2020, 7:02:53 PM] [RPi] Flightradar: warning: got file handle 1
[11/22/2020, 7:02:53 PM] [RPi] Flightradar: set Load from 1 to 1.28

Thank you!

In v1.2.1.


Use graphemes instead of bytes for string operations

Fixes #92.

[x] length
[x] substring
[x] indexOf
[x] contains
[x] startsWith
[x] endsWith
[x] filtered
[x] sorted?
[x] compareTo
[x] index operator str[idx]

@chucker any test cases I should add? Maybe some with more diacritics?

@chucker any test cases I should add? Maybe some with more diacritics?

I’d add
a👨👩👦👦b reversed == b👨👩👦👦a
and maybe something with zalgo.


AssurancyOfAEP is throwing an exception

I am getting the following exception when trying to create the results for the scenario:

This is where i call that line:

My unit test with non-overlapping stages (stage discharge with stages both entirely above and entirely below stages of stage damage) passes with expected assurance of AEP (0 and 1, respectively)


Use readme as crate-level docs

https://github.com/openrr/ros-nalgebra/runs/4648350827?check_suite_focus=true
error: no rules expected the token `::`
 --> src/lib.rs:96:33
  |
5 | ros_nalgebra::ros_nalgebra_msg!(::some_other_crate::msg, Point);
  |                                 ^^ no rules expected this token in macro call

The syntax mentioned in the readme does not seem to work.

Updated to support path in ros_nalgebra and ros_nalgebra_msg macros.
ros_nalgebra::ros_nalgebra_msg!(some_other_crate::msg, Point);

Note that the leading :: in path is not currently supported. To support it correctly, we'll probably need to rewrite implementation to use tt-muncher or rewrite ros_nalgebra_msg with proc-macro.


Add segmentation pipeline widget

This solves #139

The failing test is a change to a notebook that should not have been part of the PR in the first place.


WC2-217: add param to get form descriptor

Needed to get form descriptor from instances API (list), and make payload more consistent between list and detail
Related JIRA tickets : IA-2140, WC2-217
Self proofreading checklist

[X] Did I use eslint and black formatters
[X] Is my code clear enough and well documented
[ ] Are my typescript files well typed
[ ] New translations have been added or updated if new strings have been introduced in the frontend
[ ] My migrations file are included
[ ] Are there enough tests
[ ] Documentation has been included (for new feature)

Changes

Make  Instances  as_full_model return created_by and make as_dict return last_modified_by. This will make the UI more consistent.
Add as_dict_with_descriptor which is then used when the front end passes the with_descriptor query param

How to test
If you're set up for deduplication (I'll post the doc when it's available, otherwise just ping me):

Go to the details of a duplicate and expland one of its submissions. you should see the labels of the questions, not just the keys
Also, the Information part should have values for both "Created by" and " Last modified by"

If you're not set up:

Go to submission page and search for a specific form (to avoid making to the call too heavy)
In the codebase, find the api call and add the query param: with_descriptor=true
In the inspector or in Django's browsable api page, check the payload of the api call to instances, it should include the form descriptor for each instance

In any case:

Go to the details page of any instance: you should see values for both created by and last modified by

Print screen / video

Instance details has both created by and last modified by fields:

Deduplication details before:

Deduplication details after:

Notes
Merges into a the dev branch for deduplication

@mathvdh  There's a python test related to analyze that is failing


Add dependency status badges

Hi. I want to add dependency status badges for your repo :relaxed:
Thank you.

LGTM :+1: Thank you for adding the badge and developing shards.rocks :exclamation:

Thanks!


Auto-piolot tries to forum contracts before funds are confirmed

Current Behavior
If you set up your renting parameters and have your node synced but funds are not yet confirmed, auto-pilot tries to form contracts and fund ephemeral accounts. This fails and spams your logs as so:

Expected Behavior
renterd should wait until funds are confirmed to try to move funds around.
Steps to Reproduce

Install renterd
Sync consensus
Set renting parameters
Fund your account

Generally people won't run into this issue as it takes a really long time to sync a node, but especially in a future where poor sync times are addressed this could be annoying for users.
Version
v1.0.5
What operating system did the problem occur on (e.g. Ubuntu 22.04, macOS 12.0, Windows 11)?
Debain 12
Autopilot Config
{ 	"contracts": { 		"set": "autopilot", 		"amount": 50, 		"allowance": "17696317800000000000000000", 		"period": 6048, 		"renewWindow": 2016, 		"download":<PHONE_NUMBER>0, 		"upload":<PHONE_NUMBER>0, 		"storage":<PHONE_NUMBER>0, 		"prune": false 	}, 	"hosts": { 		"allowRedundantIPs": false, 		"maxDowntimeHours": 336, 		"minRecentScanFailures": 10, 		"scoreOverrides": null 	} }
Bus Config
{ 	"default": "autopilot" } { 	"hostBlockHeightLeeway": 6, 	"maxContractPrice": "1000000000000000000000000", 	"maxDownloadPrice": "567337822000000000000000000", 	"maxRPCPrice": "1000000000000000000000", 	"maxStoragePrice": "41373151775", 	"maxUploadPrice": "53496277000000000000000000", 	"migrationSurchargeMultiplier": 10, 	"minAccountExpiry":<PHONE_NUMBER>0000, 	"minMaxCollateral": "10000000000000000000000000", 	"minMaxEphemeralAccountBalance": "1000000000000000000000000", 	"minPriceTableValidity":<PHONE_NUMBER>00 } { 	"minShards": 10, 	"totalShards": 30 } { 	"enabled": true, 	"slabBufferMaxSizeSoft":<PHONE_NUMBER> }
Contract Set Contracts
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100 37581    0 37581    0     0  3792k      0 --:--:-- --:--:-- --:--:-- 4077k 47
Anything else?
No response

What is the actual error for the account refill? This is unlikely to be related to unconfirmed funds

What is the actual error for the account refill? You can see it by clicking the dropdown arrow next to "error". It's unlikely to be related to unconfirmed funds. The EA alerts in general are too spammy (#1044)

failed to fund account: couldn't fund account: insufficient funds to fund account: 0 H <= 1 H
I have 2KS in my account right now.

I updated the title of the thread to be more accurate.

The error indicates that your contract doesn't have enough funds left, not your wallet. This should resolve itself as soon as the contract gets refreshed. We will update the alerts in the meantime to be less spammy.


feat(flags): add bulkMigrateFeatureFlags mode

All Submissions:

[yes ] Have you followed the guidelines in our Contributing document?
[yes ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

[ yes] Have you created new unit?
[ yes] Does your submission pass all tests?
[ yes] Have you lint your code locally prior to submission (automated)?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

yeah, probably some further examples would be worth adding.  next i'm thinking about catering for release rollback.  could use getFeatureFlags before release as part of migrate job to capture the current project state to json, and then we need a mode along the lines of:
restoreFeatureFlags <proj> <target> <env> <flagNames> <backupJsonFile>
..that iterates over flagsNames supplied, looks at backupJson, and patches the target env..  a little unclear if you could end up with hybrid config with the patch approach..

looks like if we add an example to jsdoc for each function it will be rendered in API.md as part of build. eg.
@example ldutils migrateFeatureFlag my-project my-flag dev test


Add prettier script to root package.json

Summary
Same as the script in the OP of #3057

Mostly so I can run it when doing changes to the code base
Test plan
Run it? 😄

The bot should check for changes in dependencies and devDependencies, not the whole thing...

Thanks @SimenB.


Removed redundant v_Normal in shader

I want to be a contributor :slightly_smiling_face:

I like the honesty!

Welcome to the club :smile:


TransactionArgument representation

We need to expand transaction arguments to include vectors of primitives as well.
That is what the VM accepts and what is not represented in TransactionArguments today.
Following is a list of possible solutions collected by conversations with most (or all) of you.
It is not exhaustive, and it is intended to give a sense of alternatives and tradeoffs.
It will also help to make us think about the problem in a more general way.
Thanks all for the conversations... and needless to say feel free to add other alternatives you think may be good...
// 1.
//
// All arguments are passed as a single blob in LCS format.
// That would be equivalent to serialize a structure that is
// represented by the signature of the `main`.
// Except `&Signer` of course... :)
// But a tool (ABI?) could consider the part of the signature
// "deprived" of `&Signer`.
// In that case it is truly a structure where each field is one of the arguments.
//
// `main(u64, address)` would be equivalent to LCS `struct anon { f1: u64, f2: address }`
// `main(&Signer, &Signer, u64, address)` would also be equivalent
// to LCS `struct anon { f1: u64, f2: address }`
//
// This has the benefit of being a solution that allows any extension.
// It is also the most breaking of the changes we can push, and it has to be
// clear people can deliver on that in a short timeline.
//
pub struct TransactionArgument(Vec<u8>);

// 2.
//
// We add a `Vector` entry to the existing `TransactionArgument`.
// This is the simplest solution but it's also an incomplete one.
// Specifically it is not possible to express an empty vector given
// the runtime representation of vectors.
// A `Vector<address>` - as a Move `Value` - is a `Vec<AccountAddress>` and
// with this representation we don't have the vector type expressible with
// an empty vector.
// Moreover the vector is not really a vector in any form, it is more of a struct,
// but we need runtime checks anyway so it may not be an issue (the recursive nature
// of the enum makes it possible to express a vector that contains different and
// heterogeneous value (a struct).
// This also would be the worst representation in terms of size.
// Every vector would have the type tag being duplicate for each element and
// effectively wasting one byte for each element, instead of the whole vector.
//
// We could consider defining a special `Value` for a generic empty vector.
// It would be a bit odd but a possible solution...
//
pub enum TransactionArgument {
    U8(u8),
    U64(u64),
    U128(u128),
    Address(AccountAddress),
    U8Vector(Vec<u8>),
    Bool(bool),
    Vector(Vec<TransactionArgument>),
}

// 3.
//
// We split `Vector` to its own "production", and we type the vector
// in that production (enum).
// Following is a possible representation of many.
// This representation still can produce bad vector but at least it is
// possible to define a type for it.
// This solution removes the need to type every single element of the
// vector and start saving space with any vector of more than one element.
//
pub enum TransactionArgument {
    U8(u8),
    U64(u64),
    U128(u128),
    Address(AccountAddress),
    U8Vector(Vec<u8>),
    Bool(bool),
    Vector(Vector),
}

// Vector carries the type of the vector but `Nested` can still
// generate heterogeneous vector (that is invalid vectors).
// At runtime we will spot it and fail.
pub enum Vector {
    Bytes(Vec<u8>),
    BoolVector(Vec<bool>),
    U64Vector(Vec<u64>),
    U128Vector(Vec<u128>),
    AddressVector(Vec<AccountAddress>),
    Nested(Vec<Vector>),
}

// 4.
//
// Another alternative for the vector production. We split at the top level,
// define the vector type at the top, and we nest within each vector type.
// This still can generate invalid vectors, but we cannot create any longer
// a vector with mixed primitive in it.
//
pub enum TransactionArgument {
    U8(u8),
    U64(u64),
    U128(u128),
    Address(AccountAddress),
    U8Vector(Vec<u8>),
    Bool(bool),

    BytesVector(BytesVector),
    BoolVector(BoolVector),
    U64Vector(U64Vector),
    U128Vector(U128Vector),
    AddressVector(AddressVector),
}

pub enum BytesVector {
    Nested(Vec<BytesVector>),
    Bytes(Vec<u8>),
}

pub enum U64Vector {
    Nested(Vec<U64Vector>),
    U64Vector(Vec<u64>),
}

pub enum U128Vector {
    Nested(Vec<U128Vector>),
    U128Vector(Vec<u128>),
}

pub enum AddressVector {
    Nested(Vec<AddressVector>),
    AddressVector(Vec<AccountAddress>),
}

pub enum BoolVector {
    Nested(Vec<BoolVector>),
    BoolVector(Vec<bool>),
}

// 5.
//
// Type the vector at the top level with all type info and
// rely on LCS only for vectors.
// It would be something along this line...
//
pub enum TransactionArgument {
    U8(u8),
    U64(u64),
    U128(u128),
    Address(AccountAddress),
    U8Vector(Vec<u8>),
    Bool(bool),

    Vector(Type, u8, Vec<u8>),
}
// where `Type` is one of the primitive, `u8` is the "dimensions" and
// `Vec<u8> is the LCS representation of whatever that vector was

#5578 as a reference too

please add people that should know about this, or may have interest in the decision

Option 3 seems like a reasonably good compromise, although it would be nicer to put U8Vector inside the Vector enum (in place of "Bytes). Is there some reason that won't work?

Option 1 seems like the simplest approach to me.

We already solve a very similar deserialization problem for top-level resources using this approach.
The main purpose of TransactionArgument seems to be client convenience in constructing type-safe transaction arguments. That is a good goal, but it doesn't seem like one that should be implemented inside move-core-types or one that the VM should need to know about.
If you look at the generated code in transaction-builder, most of it is already type-safe at the function level. So much of the code is just boilerplate repackaging function arguments into TransactionArguments; e.g.

pub fn encode_add_to_script_allow_list_script(hash: Vec<u8>, sliding_nonce: u64) -> Script {
    Script::new(
        ADD_TO_SCRIPT_ALLOW_LIST_CODE.to_vec(),
        vec![],
        vec![
            TransactionArgument::U8Vector(hash),
            TransactionArgument::U64(sliding_nonce),
        ],
    )
}

If we went with Option 1, this code could look something like:
pub fn encode_add_to_script_allow_list_script(hash: Vec<u8>, sliding_nonce: u64) -> Script {
  let args = vec![LCS::serialize(hash), LCS::serialize(sliding_nonce)];
  // .. no transaction argument repackaging
}

Option 1 seems like the best to me. To me the nicest thing it does is moves us to the path of making Value private to the VM. It deeply bothers me that the runtime representation of values in the VM is a public API
Would love to see TransactionArgument blown away. Anyone that wanted a clean AST-like experience to serialize values could use the same API we use for constants, move_core_types::MoveValue. Constant's everywhere!

OK, I like the generality of Option 1. Would that imply that you can't easily see the arguments without knowing the signature of the script? If so, is that a concern?
How much work would it be to use that approach and how disruptive would it be?

Would that imply that you can't easily see the arguments without knowing the signature of the script? If so, is that a concern?

Good question. I think the answer is "yes, but not a concern". My reasoning is:

There is a small allowlist of script types and clients probably already know the signatures of the most common ones (e.g., p2p payment) without any decoding
The transaction contains the script, so an interested party that doesn't know the signature can always recover it by decoding the transaction script

How much work would it be to use that approach and how disruptive would it be?

Looking at git grep TransactionArgument, most hits are in the script bindings codgen, so I think most of the work will be there (but hopefully in a small number of places). @matbd would be the best judge of how hard that is. It looks like there is some other code to refactor as well, but not a ton.
I don't think this would be disruptive to any code outside Libra core. I think basically what's happening is that we have a pipepline:
typed function params -> serialize to TransactionArguments -> deserialize from TransactionArguments -> serialize to LCS
that we are changing to a simpler pipeline typed function params -> serialize to LCS. Clients should still see only the typed function params and not care that the subsequent steps have changed.

Regarding option 1:

This was my favorite solution a few months ago in terms of documentation simplicity and encoding performance.
On my side, I would be able to remove a good amount of codegen for sure at the end

However, I'm not sure if we can simply replace the definition of TransactionArgument at this stage of the project because not every client may be using the transaction helper libraries + it would be "very" breaking / requiring coordination (need to ask around).
Please let's keep the names of the Script parameters in the struct (preferred) or use LCS tuples.

On the move side, I have a few comments/questions:

txn-to-value converters have no context on types right now and with LCS you really must have this information. How much does it entail and for how long?
should we replace ArgumentABI::type_tag by a LCS value format description? (or even ArgumentABI by a LCS container format)
what should we do with type parameters Vec<TypeTag>? (stays the same?) This makes me think we might want a better visibility on the codegen/ABI story for Move resources to decide.

Regarding option 2:

This would be my preference in the short term but Dario pointed out that internally generic vectors are not allowed to be U8 vectors, address vectors etc instead each of the particular vector has its own value kind (AddressVector). With options 2 a user has no way to signal that it wants an empty AddressVector.

Regarding option 5:

I don't understand the dimension thing. Isn't that clear from the value expression?

Regarding option 4 and 3:

Similarly, I don't understand which problem we solve with the "nested" stuff

Personally, my money would be on the following "option 4bis" in the short term:
pub enum TransactionArgument {
    U8(u8),
    U64(u64),
    U128(u128),
    Address(AccountAddress),
    U8Vector(#[serde(with = "serde_bytes")] Vec<u8>),
    Bool(bool),

    U64Vector(Vec<u64>),
    U128Vector(Vec<u128>),
    BoolVector(Vec<Bool>),
    AddressVector(Vec<AccountAddress>),

    /// Generic vector for the remaining cases.
    /// Note that the specialized vectors above (U8Vector, U64Vector, etc) must be used when applicable.
    Vector(Vec<TransactionArgument>),
}

For the sake of the argument I updated my draft PR https://github.com/libra/libra/pull/5578

(one more idea) If we feel that LCS-encoded arguments are the future of Move encoders/decoders, we could make this (easy) breaking change now:
struct Script { code: Bytes, ty_args : Vec<TypeTag>, args : Vec<TransactionArgument>}

becomes
struct Script { code: Bytes, ty_args : Vec<TypeTag>, args : TransactionArguments}

enum TransactionArguments { Legacy(Vec<TransactionArgument>) }

in preparation of
enum TransactionArguments { Legacy(Vec<TransactionArgument>), LcsEncoded(Bytes) }

I also prefer (1) as it aligns with the way we treat scripts in the Libra layer. It is potentially the simplest representation we could have and I'd expect it to simplify a lot of interactions in the long run.
I don't actually see much difference among other solutions. They share a common philosophy that the value needs be typeable by themselves and the tricky case is the empty vector, for which you cannot determine its element type. They are fundamentally similar and it's only a matter of where you inject that missing information and what invalid combinations you create as a side effect. This actually seems redundant to me as the type info is already available -- transaction arguments are almost always bundled with a script.
@matbd To answer your questions on the Move VM:

convert_txn_args

IMO the answer is, once you go opaque, you don't even bother converting it to a value first. The new model would simply pass in the arguments as bytes and let the Move VM try to deserialize them according to the types declared in the script. We may produce different errors before and after but they should be in the same bucket so clients shouldn't care. TBH we would celebrate with tears if this could happen.
TypeTag is self descriptive and completely open. It's just a name after all. Given a TypeTag you can convert it to and from bytes at any time, without the need to access any additional information so I'd say it doesn't really make a fundamental difference. struct Script { ty_args: Vec<TypeTag> } and struct Script { ty_args: Vec<Vec<u8>> } are probably gonna get serialized in the very same way using LCS. The only difference is whether you require the clients convert the TypeTags to bytes themselves. Still something to think about but just saying this can be switched around very easily.
In general my reasoning about ArgumentABI is similar to that of TypeTag. You can always convert between the expanded and serialized representations at any time so it's not really an issue in the sense of getting the information a client requires. Also please correct me if I'm wrong, but from my understanding, ArgumentABI is currently only produced by and consumed by ABI gen, which gives us a bit more leeway that we don't really need to make a hard decision for v1.

I searched for TransactionArgument throughout the repo and here's a categorization of the usages:

Creating a transaction argument (in order to create a Script).

Can be easily replaced with something like encode_txn_arg_u64(x: u64) -> Vec<u8>.

Testing the transaction argument against a known type.

if let TransactionArgument::Address(...) = ...
Can be replaced with deserialize_txn_arg_u64(bytes)?

Functional tests: parsing transaction arguments.

Can use encode_txn_arg_xxx for now and we'll add support for more diverse types later.

Fuzzing/Arbitratry

Didn't look closely into this but I assume we can either delete or reimplement easily? My understanding is that we just need it to create a random script and we're only testing for ser/de.

stdlib: generated Rust APIs for encoding scripts

Essentially same as (1), just that we need to modify the generator logic instead of the code directly.

transaction-builder/generator

It seems to me we'll need to rewrite the definition for TransactionArgument (or maybe just remove it) for a few languages. There's some work here but still trivial I think?

There's definitely a lot of things we'll need to change if we decide to go with option 1, but most of the work are mechanical and seem doable within a timeframe of a few days. Particularly, I didn't see patterns like match deserialize_txn_argument(bytes) {  TransactionArgument::U64(...) => ..., TransactionArgument::Bool(...) => ... }, meaning that our clients are not currently exploiting its self-descriptive nature. (Correct me if I'm wrong on this.)
@matbd I understand where you're coming with the Legacy/LcsEncoded proposal and I agree it'll allow us to delay some of the work above. However given the mechanical nature and simplicity of them I'm not sure if it's worth it. Having two systems in parallel means we won't be able to get rid of the TransactionArgument => Value conversion in the Libra layer, and it will make the Move VM interfaces messier than its current state, which is a huge step backward.
With all being said, it seems to me that option 1 is really what makes everyone happy and I think it's still possible we make it happen. Would there be strong opposition from the Libra core teams citing this as being too breaking/ too late or other non-technical factors that would prevent this from happening? If not, then I'd suggest one of us spend a day or two experimenting with this and see if it ends up working. Let me know how you guys think!

That sounds like a good plan. If you're fairly confident that it will work, it would be good to write the SEV and Workplace post describing the proposed change to see if anyone wants to object.

Regarding option 5:

I don't understand the dimension thing. Isn't that clear from the value expression?

the point I was trying to make is that any of the other representations can create an improper vector.
TransactionArgument::Vector(vec![TransactionArgument:: U64Vector(vec![10]), TransactionArgument:: BoolVector(vec![true, false])])
or
TransactionArgument::Vector(vec![TransactionArgument::Vector(vec![TransactionArgument:: U64Vector(vec![10])]), TransactionArgument:: U64Vector(vec![1, 2])])
with 5 you have one shot to define the type and that is it.
In other words all other representations imply you look for the first element in the vector and assume all others are the same.
So if at position 0 you find a vector<vector<u64>> that is the type expected and any value not matching is an error.
With 5- you don't have that issue in the sense that you know the vector type up front.
Or that was the intent. Not sure it is completely correct but it seemed reasonable (is it?)

Regarding option 4 and 3:

Similarly, I don't understand which problem we solve with the "nested" stuff. (EDIT: I think I now understand the goal but is it true that Move values for matrices of u8/u64 are optimized as well?)

I think your solution is fine too, those were examples we came up with, alternative solutions are all good too


Convert the flip angle maps to B1+ efficiency maps [nT/V]

The notebook currently uses the same code that is used in the RF shimming project: https://github.com/shimming-toolbox/rf-shimming-7t/blob/main/content/index.ipynb to convert flip angle maps [degrees] to B1+ efficiency maps [nT/V].
The code code contains the following line:
requested_fa = 90  # saturation flip angle -- hard-coded in sequence
Could someone @jcohenadad @dpapp86 confirm that the 90degree flip angle is not hard-coded and that it should be whatever flip angle that was used for the acquisition? I am unsure if this 90 degree flip angle pertains to a pulse that is run before the actual image acquisition itself. @dpapp86 I seem to recall you mentioning something like that.
The turboFLASH scans acquired at VE sites all have a 90 degree flip angle. However, those acquired at the VB17 site have different flip angles (which can be found in the .json). Should our code be retrieving the flip angle recorded in the .json file at all times?
Moreover, DREAM flip angle maps are not acquired with a 90 degree flip angle at VE or VB17 sites. Does this flip-angle-to-B1+-efficiency code still apply for DREAM maps? And if so, should the flip angle be adjusted accordingly?

Hello!
Wrt the saturation pulse:
That flip angle, the saturation flip angle (the pulse that is used to probe B1+ efficiency, and not the excitation pulse), is hard-coded into the sequence on VE (to the best of my knowledge). On VB17 (Mt Sinai, so far), it is set in the "Sat Flip Angle" field under Sequence/Special.
For our acquisitions, this has always been set to 80 deg in Mt Sinai (which has caused some workflow issues with the SOP, as Alan documented in the scan notes and you picked up on here: https://github.com/spinal-cord-7t/coil-qc-code/issues/13#issuecomment-1965270613
For VE scanner (all but Mt Sinai), this 90 degree does not show up anywhere in the default json files. The "FlipAngle" value refers to the excitation FA, 10 degrees.
For VB, however, this field, "FlipAngle", describes the saturation flip angle, being either 80 or 60 or so, as per the name of the sequence.
Needless to say, this is going to make processing annoying. I suggest you treat all VE sites the same, with an assumption of Saturation FA=90, and parse the Mt Sinai site separately, using the FlipAngle field of the JSON file.
WRT DREAM:
How to deal with the DREAM sequences and how to convert them into nT/V maps is described in my original processing code, here: https://colab.research.google.com/drive/1HZYovXC4X-skmH-PcvumpXXXcOWESb0L#scrollTo=621d4320
Luckily, the FlipAngle in the JSON files of the DREAM sequences is the saturation flip angle, so it is easy to exctract it, and my code does it.

Thanks @dpapp86 this is very helpful. If I'm following your code correctly, the conversion for FA-to-nT/V seems to be the same equation for both TFL and DREAM?
My last comment is that, the "flip angle" field in the .json files I've generated seems to be 90 degrees for all TFL scans, and not 10 degrees ... Should I trust this to be the saturation flip angle?

1, Yes, I used the same conversion, and got appreciably similar values. But
I think Johanna has some ideas about DREAM. Have you talked to her about
the issue?
2, Ah.
I was always looking (for TFL_B1map scans) at the first scan (the GRE-like
anatomical) and the corresponding JSON. Maybe the second scan's (the B1+
map) JSONs have the saturation flip angle in them? If this is true, then
yes, you should use those JSON files.
A good sanity check is if the FA is below 15 degrees, its likely to be
excitation, if its 80 or 90 for TFL, or above 20 for DREAM, its likely to
be saturation. Bear in mind that the DREAM is acquired with higher and
lower reference voltages, and that the sequence adjusts its saturation FA
accordingly (as I recall).
On Mon, Mar 11, 2024 at 3:02 AM evaalonsoortiz @.***>
wrote:

Thanks @dpapp86 https://github.com/dpapp86 this is very helpful. If I'm
following your code correctly, the conversion for FA-to-nT/V seems to be
the same equation for both TFL and DREAM?
My last comment is that, the "flip angle" field in the .json files I've
generated seems to be 90 degrees for all TFL scans, and not 10 degrees ...
Should I trust this to be the saturation flip angle?
Screenshot.2024-03-10.at.9.58.50.PM.png (view on web)
https://github.com/spinal-cord-7t/coil-qc-code/assets/6652194/bc377316-fa19-460d-b7fc-d59427bc6705
—
Reply to this email directly, view it on GitHub
https://github.com/spinal-cord-7t/coil-qc-code/issues/18#issuecomment-1987498882,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATDM6U3UNSX5S5SAK2GW6ODYXUND5AVCNFSM6AAAAABEOOG2O2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGQ4TQOBYGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

This issue has been resolved. The code now looks for the saturation flip angle in the json files.


python312Packages.google-ai-generativelanguage: 0.6.4 -> 0.6.5

Changelog: https://github.com/googleapis/google-cloud-python/blob/google-ai-generativelanguage-v0.6.5/packages/google-ai-generativelanguage/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 319754 run on x86_64-linux 1

6 packages failed to build:

python311Packages.llama-index-embeddings-gemini
python311Packages.llama-index-embeddings-gemini.dist
python311Packages.llama-index-embeddings-google
python311Packages.llama-index-embeddings-google.dist
python311Packages.llama-index-vector-stores-google
python311Packages.llama-index-vector-stores-google.dist

11 packages built:

home-assistant-component-tests.google_generative_ai_conversation
open-webui
open-webui.dist
python311Packages.google-ai-generativelanguage
python311Packages.google-ai-generativelanguage.dist
python311Packages.google-generativeai
python311Packages.google-generativeai.dist
python312Packages.google-ai-generativelanguage
python312Packages.google-ai-generativelanguage.dist
python312Packages.google-generativeai
python312Packages.google-generativeai.dist

#319639 was merged.


Please help me in installing 7B my knowledge is not enough to solve this error.

Installed via GPU and CPU. Please help me in installing 7B my knowledge is not enough to solve this error.
Gpu - started, but gives an error
File "E:\AI\oobabooga-windows\text-generation-webui\modules[chat.py](https://chat.py/)", line 173, in cai_chatbot_wrapper
for _history in chatbot_wrapper(text, max_new_tokens, do_sample, temperature, top_p, typical_p, repetition_penalty, encoder_repetition_penalty, top_k, min_length, no_repeat_ngram_size, num_beams, penalty_alpha, length_penalty, early_stopping, seed, name1, name2, context, check, chat_prompt_size, chat_generation_attempts):
File "E:\AI\oobabooga-windows\text-generation-webui\modules[chat.py](https://chat.py/)", line 144, in chatbot_wrapper
cumulative_reply = reply
UnboundLocalError: local variable 'reply' referenced before assignment
CPU - ran but says no module.
Running with the following flag call python server.py --auto-devices --cai-chat --model alpaca-native-4bit --wbits 4 --groupsize 128 --no-stream
Please help.
Starting the web UI...
===================================BUG REPORT===================================
Welcome to bitsandbytes. For bug reports, please submit your error trace to: https://github.com/TimDettmers/bitsandbytes/issues
================================================================================
CUDA SETUP: Loading binary E:\AI\one-click-installers-oobabooga-windows\installer_files\env\lib\site-packages\bitsandbytes\libbitsandbytes_cpu.dll...
E:\AI\one-click-installers-oobabooga-windows\installer_files\env\lib\site-packages\bitsandbytes[cextension.py:31](https://cextension.py:31/): UserWarning: The installed version of bitsandbytes was compiled without GPU support. 8-bit optimizers and GPU quantization are unavailable.
warn("The installed version of bitsandbytes was compiled without GPU support. "
Loading alpaca-native-4bit...
Traceback (most recent call last):
File "E:\AI\one-click-installers-oobabooga-windows\text-generation-webui[server.py](https://server.py/)", line 275, in
shared.model, shared.tokenizer = load_model(shared.model_name)
File "E:\AI\one-click-installers-oobabooga-windows\text-generation-webui\modules[models.py](https://models.py/)", line 100, in load_model
from modules.GPTQ_loader import load_quantized
File "E:\AI\one-click-installers-oobabooga-windows\text-generation-webui\modules\GPTQ_loader.py", line 13, in
import llama_inference_offload
ModuleNotFoundError: No module named 'llama_inference_offload'
Press any key to continue . . .

hi how did you close this?


Create lesson page with questions and answers (dummy data)

We need someone to create a page when you click a certain lesson, We want each lesson to have questions and answers.

assign to me @duraanali


filter chain match: support source CIDRs and ports

This PR also fully deprecates the tcp_proxy v1 configuration.
This will be deleted following the standard deprecation cycle.
All new uses should use filter chain matching.
Fixes https://github.com/envoyproxy/envoy/issues/4457
Risk Level: Medium
Testing: New tests
Docs Changes: Added
Release Notes: Added
Deprecation Notes: Added

@PiotrSikora @htuch PTAL
@htuch This PR contains a fix for the docs build on master. Feel free to pull it out into a different PR in the morning if you want since this might take a few iterations.

@PiotrSikora thanks for the review. Updated.


ffs: filesystem data model

this will support many ui features. could use unixfs
maybe there's a way to make this modular, have a couple different data model implementations? pure cid/opaque data and unixfs

Question about storing unixfs data in filecoin... when you move files/folders around, and therefore create a new root cid, and that cid is stored in filecoin: How does that interact with the storage and price model of filecoin? We'll want to be sure you're not storing any data more than once or paying more than once.

Moving some comments from the team over here:
@jsign:

I think that's a quite complex question in FIL to deserve being answered by Lotus/Filecoin guys. From my outside knowledge, I haven't seen anything about the miner deduping and storing only DAG blocks that hasn't been sealed in the past.
The problem that I can think about that situation is that the hole pinned DAG can be scattered around many sealed sectors... and retrieving the data would imply unsealing multiple different sectors which might be unviable. I can imagine other proof of spacetime complexities.... since if only a partial dag of the root cid is stored, then the proof of storage would be partial for that deal (since stripped data is in a past deal)
1:17
The above isn't an answer to your question (which is a quite important one to have a clear answer), just my limited thoughts about that situation (edited)
1:19
The above answer it's more related to Filecoin solving the dedup problem. Of course, the client could make deals only on changed data... but retrieving the data would imply retrieving data from multiple deals, and joining the correct parts about each dag

@carsonfarmer:

I don't know much at all from the filecoin side, but this is a HUGE big deal for the pinning services on IPFS. They all struggle with it.
1:20
Some have found solutions, but since you aren't dealing with the same level of complexity as filecoin, they likely don't translate at all.
1:21
I know RTrade for instance, does some pretty smart dedup, even between  clients (so if multiple clients store the same data, they all get a discount basically). Pinata doesn't handle this at all yet AFAIK...

@jsign:

Interesting. I don't know what the IPFS pinning services does... I kind of imagine them as running a really big ipfs-cluster and just throwing cid pins in there. that would make automatic dedup for all clients (if all ipfs pinning is done in single big ipfs cluster)
1:23
but of course, i'm sure im missing something since I guess you can't make a business just by running a big ipfs cluster :stuck_out_tongue:

@carsonfarmer:

well, they still need to track who pinned what and when

@jsign

1:26 PM
doesn't sound that bad
:man-shrugging:
@sanderpick

1:27 PM
In the filecoin case, we should consider another option, which is just leave everything as cids and then manage the unix fs layer in a side-carred IPFS node
1:29
Then maybe some key value (badger) thing that records some meta data about each hash: what deal is belongs to, etc.
1:29
You could explode a DAG into a bunch of deals via UnixFS + the key val store (edited)

@carsonfarmer:

1:31 PM
Heads up here guys, from my research into pinning a few months back, the above ^ is essentially exactly how 'pinning' in IPFS handles pinning unixfs things.

@sanderpick

1:32 PM
That’s true carson but you’d need something additional to do the deal mapping I think

@carsonfarmer:

I don't know enough about it to really give you details, but tracking unixfs pins is a big part of that whole pinning API, and I think @sanderrr essentially just descrived how they do it :stuck_out_tongue:
1:32
right yes totally (edited)

@jsign

1:33 PM
How about fogetting about UnixFS, and just saving the directory tree (with cids) in a simple recursive datastructure?
I guess it mostly depends on what the UI is demanding. AFAIK, it seems they're uploading single files.

After some research and discussion, we decided this is an application level concern. There's not an efficient way to model a filesystem-like structure in filecoin without re-storing all data each time the directory tree changes. You'd end up paying for storing duplicate data. So the plan is to model a directory tree in the application layer, and track file path to filecoin cid associations in the application layer.


Multi Bar Mode: add option for console text output

It would be cool to have a text output option for every new MultiBar(). Right now a console.log interruptes the progressbars. So my idea was to have a fixed line where you can output text.  So its possible to write Text without interrupting progressbars. Something like multibar.log()

please take a look into the other related issues, it's a repeating feature request

See #57


[GitInfoContributor] commit time is not human readable

Is your feature request related to a problem? Please describe.
The GitInfoContributor transforms the git.commit.time into a timestamp (in general any value associated to a key named "time"). This appears to be done on purpose (see permalink below), so I don't know if it's needed for a specific case. Nonetheless the timestamp is not human readable as the ISO8601 data representation. Currently Spring does not perform this value transformation and from SpringBootAdmin this value does not seem to be processed at all. The result is that SBA shows git.commit.time value with different formats:
# spring
2021-06-28T07:46:08Z
# steeltoe
1624613217000

Describe the solution you'd like
In my opinion datetime values retrieved from this actuator should always be sent using a human readable format. In any case using ISO8601 format will result in a value that it's both human and machine readable.
Additional content
Here is the custom code that performs the value transformation:
https://github.com/SteeltoeOSS/Steeltoe/blob/9322d0627673c9c96d71b584d190284649c4005d/src/Management/src/EndpointBase/Info/Contributor/GitInfoContributor.cs#L84-L99

@DaviGia thanks for pointing this out. I can't find any reason there should be a mismatch between Steeltoe and Spring here, I'm not sure why the code is that way today. We'd be happy to accept a PR for the fix if you're willing

@DaviGia thanks for pointing this out. I can't find any reason there should be a mismatch between Steeltoe and Spring here, I'm not sure why the code is that way today. We'd be happy to accept a PR for the fix if you're willing

I've created the PR.


Port signals to Windows

This issue is about porting Signal to Windows and therefore making it possible to implement other relevant features like Process.
Short introduction (moved from #5430):
Microsft doc about signals
I already looked at this page, and I think these signals are only there because they are part of the C standard library. From wikipedia:

The C standard defines only 6 signals. They are all defined in signal.h header (csignal header in C++):
SIGABRT - "abort", abnormal termination.
SIGFPE - floating point exception.
SIGILL - "illegal", invalid instruction.
SIGINT - "interrupt", interactive attention request sent to the program.
SIGSEGV - "segmentation violation", invalid memory access.
SIGTERM - "terminate", termination request sent to the program.
Additional signals may be specified in the signal.h header by the implementation. For example, Unix and Unix-like operating systems (such as Linux) define more than 15 additional signals; see Unix signal.

And these 6 signals are the only ones "supported" by Windows.
There is already an issue about this topic on the Node.js repo.
sam-github commented there:

[...] Windows as an O/S has absolutely no signal support. [...]
If SIGTERM was supported on Windows, you could listen for it and receive it... but you cannot. You can listen..., but you'll never receive it.

And I guess this is exactly the case. You have a function for listening to signals (signal()), but there is nothing like kill() for sending signals on Windows.

So this is about finding replacement functions to "fake" signals on Windows. I already found some replacements for signals one might want to send:

SIGTERM: SendMessage(WM_CLOSE) <- this is also what taskkill.exe uses; works for windowed processes
SIGKILL: TerminateProcess() <- used by taskkill.exe /f; works for windowed and console processes
SIGINT: GenerateConsoleCtrlEvent() <- works for console processes, simulates Ctrl + C

List of UNIX signals: https://en.wikipedia.org/wiki/Signal_(IPC)
Another microsoft doc that mentions replacements for UNIX signals: https://docs.microsoft.com/en-us/previous-versions/ms811896(v=msdn.10)#signals-and-signal-handling

@rdp True, after more consideration I think the work here @maltevoos has done is the best approach and there's already a good chunk of progress.

@markrjr Just wondering because it's on the to-do list in #5430.

Signals are more complex than they seem on POSIX platforms; writing signal-safe code in signal handlers is tricky, which is why we merely write the signal to a pipe and later handle 'em through the event loop, not even talking about its implications to fork/exec (fork inherits sigmask).
TBH there are lots of things to work on to support win32; I'm not sure signals has much priority, and even thought maybe a correct implementation could depend on Fiber, EventLoop, Mutex... maybe something else, or maybe not. I don't know anything about win32.

@ysbaddaden Exactly. Fibers and IO are far more important to implement for win32 because a lot more depends on them.

I wouldn't do that at all. Signals are not just a concept of async inter-process messaging, it's a concrete and very well defined mechanism that people have been using for ages. It would be extremely conter-intuitive for the users to use something that is called a Signal, but has in fact nothing to do with posix signals.
Instead you would be much better off introducing a new abstraction that will wrap signals on posix systems and winapi on windows, however the utility of such a concept may be less than you think.
In general I think the goal of linux-windows cross-platform development looks noble at the first sight, but contains so much devils in the details that it harms users more than helps them.

Some kind of abstraction layer might make sense...you know like
Process.alive?(pid) or what have you (that kind of thing) :)
On Fri, Mar 8, 2019 at 7:26 AM undead robot<EMAIL_ADDRESS>wrote:

I wouldn't do that at all. Signals are not just a concept of async
inter-process messaging, it's a concrete and very well defined mechanism
that people have been using for ages. It would be extremely
conter-intuitive for the users to use something that is called a Signal,
but has in fact nothing to do with posix signals.
Instead you would be much better off introducing a new abstraction that
will wrap signals on posix systems and winapi on windows, however the
utility of such a concept may be less than you think.
In general I think the goal of linux-windows cross-platform development
looks noble at the first sight, but contains so much devils in the details
that it harms users more than helps them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/crystal-lang/crystal/issues/7339#issuecomment-470945763,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAw0J0Wim7xazYayWXnR5O96Wrx-xFTks5vUnL2gaJpZM4aU0lE
.

Should we perhaps have a UNIX module in the standard library, move signals to UNIX::Signal and then make it very clear that the UNIX module just will not be there on windows?
Obviously, we'd have cross-platform abstractions for the most common usecases (exit handlers, killing a process, etc.)

I think platform-dependent stuff should be in shards, not in the std. Otherwise a crystal program without external dependencies can't be reliably compiled on any platform (I experiences this in Haskell where there are modules named Posix and such, it looks very messy in my opinion and a big leaky abstraction).

Moving Signal out of stdlib is going to be hard. We need 'em in stdlib on POSIX targets. For example:

we ignore SIGPIPE so read/write syscalls fail with EPIPE instead;
we must handle SIGCHLD to be notified that a child process exited, so we can reap it, resume waiting fibers, get its exit code to fill Process::Status, ...

For this, we need the whole signal sink logic (sighandler -> IO pipe -> event loop -> fiber handler) to be implemented (signal handlers are unsafe) + setsigmask to disable signals during fork/exec when running sub processes (because of the sink).
Hiding signals inside a shard would mean to either replicate everything we already have in stdlib (bad), or merely expose whatever stdlib provides (sic).
AFAIK we need Signals on Win32 (thought there are signals on Win32). I don't see any reason to introduce yet another namespace to contain it. It would be quite empty. Go doesn't have fork (we're likely to ditch it too) nor daemonize (we don't either, a specialized tool like supervisord is better), it merely exposes a few syscalls like chroot and a few methods to get/set the real/effective user/group (half of them being dummies returning -1 or erroring on Win32). And that's about it.

Moving Signal out of stdlib is going to be hard.

Agreed that this isn't feasible.
Go seems to only handle SIGINT, which is fine with me.

What should we do about the desire to have all possible values be available at compile time?
I.e. if we have Signal::PIPE on Linux then it must also be available on Windows? But it cannot be used for anything
And in case it turns out relevant, I'd like to point out that there's 1 collision of values:
Windows SIGABRT = 22, Linux SIGTTOU = 22

The values can be different on different OSes. I think that a good compromise is to have a commonly used set available, but their value is set to -1 on unsupported OSes and we just raise when they're passed anywhere to be used.

It's a tough call to put those values into enum Signal specifically because it is an enum.
Errors could very easily sneak by undetected, if organized like this:
enum Signal
  A = -1
  B = -1
end

p! Signal.new(-1) # => A

If, instead, the real enum contained only actually defined signals but Signal was a namespace with constants like PIPE = ActualSignal.new(-1), they would error upon first use.
Which is a bit silly still.

I think regardless of what the actual enum values are, Signal should be an enum, should be identical on all architectures, and methods should raise only when an unsupported signal for that platform is used.

I suppose we should have our own set of enum values then, and translate them to the appropriate POSIX/Win32 values when used.

@straight-shoota  how will .value work?

Like with any other enum. We'd need a separate method to return the platform-specific signal number.

I think people will be really tempted to use Signal.value anyway, any time they want to look at it or pass it to some unsupported low-level call.

What would signals even mean in Windows? Why not just make them unix-specific, like unix sockets?

I think the main point is that signals can't feasibly be dropped from standard library and we also have a policy that code that compiles on one platform will always compile on another. So there has to be some placeholder even if it doesn't actually work. So we're discussing what that would be.

signals can't feasibly be dropped from standard library

Could you elaborate on this point? Wouldn't this be solved by conditional compiling? I'm almost sure it's already in wide use, something akin to ifdef windows

As I was saying,

we also have a policy that code that compiles on one platform will always compile on another.

If I write process.signal(Signal::KILL) and it works on Linux, it must also compile on Windows even if it's a runtime failure. Hence, Signal::KILL must be an existing value of some sort.

Let me bring back my refrence to Unix sockets. There are basic fundamental differences between operating systems that will not go away. You may go C++ route and leave them "implementation specific" and out of stdlib, but that would be very unhelpful for the users.
If you insist on a universal higher-level API, then make Signal this implementation detail only available on some systems and wrap winapi for windows. Good luck designing this API though.
Basically I understand this policy as: "even if a thing only exists and makes sense in a particular case, we'll mock it up as a universal case so it's gonna explode in runtime rather than in compile time", am I correct?

The last point is correct. I don't like that policy myself but this is not the place to rethink it.

Can't we just do what Go does?

Well, what does Go do? Specifically in terms of the actual values of the signal constants

https://github.com/crystal-lang/crystal/issues/7339#issuecomment-458936421

The info was not enough. "Supported" could mean anything. So I dug a bit myself.
So I think what Go does is declare that these 2 are the only signals that exist and if you use anything else, you need an OS-specific library.
enum Signal
  Interrupt
  Kill

The only signal values guaranteed to be present in the os package on all systems are os.Interrupt (send the process an interrupt) and os.Kill (force the process to exit).

AFAIK only signals that exist on the target are defined. I.e. Signal's enum should only contain valid signals, not fake ones. On POSIX systems you get all signals, on Windows you have the few supported. Overall, only Interrupt and Kill are guaranteed to be available. Using other signals isn't portable.

Overall, only Interrupt and Kill are guaranteed to be available.
Using other signals isn't portable.

So how do you portably use even these two? Is it possible to kill(pid, SIGKILL) on Windows? Is it possible to trap(SIGINT)?

For the record, the value SIGKILL doesn't exist anywhere in Windows API.

trap(SIGINT) is possible but I'm not sure exactly what it does.
"Sending a signal" in general is not a thing on Windows.

As was stated previously:

If SIGTERM was supported on Windows, you could listen for it and receive it... but you cannot.
You can listen..., but you'll never receive it.
And I guess this is exactly the case. You have a function for listening to signals (signal()),
but there is nothing like kill() for sending signals on Windows.

So how do you portably use even these two?

That's already answered in the issue description. And the same thing as Go does: When win32 Process#signal implementation receives SIGKILL it calls TerminateProcess.
SendMessage(WM_CLOSE) for SIGTERM probably isn't worth implementing when it only works for windowed processes.
I'm not sure about SIGINT in Go it's not implemented, but a TODO in the code =)
So for a MVP I'd suggest to only implement custom handling of SIGKILL on windows for now.

So for a MVP I'd suggest to only implement custom handling of SIGKILL on windows for now.

That's the obvious part.
So then, what should the value of Signal::KILL be on Windows?

Why not introduce like Process.terminate() rather than emulate one special posix signal with something that has nothing to do with signals?

We are indeed moving in that direction, so perhaps we wouldn't need to fake-implement signals, but this is not a universal solution.

(terminate was recently added and now is being decoupled from signals, look for it in https://github.com/crystal-lang/crystal/pull/9035/files)

I really like what go does, in that it defines a list of signals, and all the signal values are always there on every OS, even if using them is an error. That go has the same guarantees that compiling always works on every OS and any failures happen at runtime is a really good sign.
But only providing 2 enum values is not feasible in crystal. It's a simple extension of go's approach to add more signal values than just two.

and all the signal values are always there on every OS, even if using them is an error

-- all two of them -   Interrupt and Kill.
I'm not sure how commendable that is

@RX14 To use signals you must use values from the syscall package, which only defines some signals for each target.
For example, syscall.SIGHUP is available for both GOOS=linux and GOOS=windows, but syscall.SIGTTOU will only compile for linux targets. On windows you get a compilation error:
$ GOOS=linux bin/go build foo.go

$ GOOS=windows bin/go build foo.go
./foo.go:14:28: undefined: syscall.SIGTTOU

I.e. using signals easily breaks Go programs portability. It's a good demonstration that the "compiles everywhere" policy is meant as a goal, that shouldn't be enforced blindly.
In Crystal terminology, this means that there isn't a Signal enum, and to use signals, you must use LibC constants. For example LibC::SIGTTOU and handle portability, for example with {% if flag?(:unix) %} wrappers (if you care about it). I'd be fine with this.

I'm fine with that general approach, since it's obvious that LibC and Crystal::System are unstable APIs.
In fact I'd like to move LibC under Crystal...

Neither Crystal nor Crystal::System namespaces should be accessed outside of core/stdlib. Putting signal constants there... undermines the whole point of these namespaces.
Putting LibC is also nonsensical. It's not unstable. It's unsafe and not portable but the C API is very stable. Let's remember that easy interaction with C API is one of the very powerful feature of Crystal...

@ysbaddaden This goes a bit off topic, but just to clarify: The Crystal namespace actually provides some features that are definitely intended for usage outside stdlib. Most inside that namespace is not intended as public API and thus nodoc, though. Especially everything in Crystal::System.

Putting LibC is also nonsensical (especially if we're meant to access signal constants from LibC). It's not unstable.

LibC certainly is unstable - it's not identical between platforms and some future platforms may not even have it. Symbols from LibC may be removed between releases. I don't want to make any guarantees about stability on LibC at all, and as such I'd like it to be moved to Crystal. Then we can simply say "anything under Crystal that's not documented is subject to change"

That suggestion could be nice, it'd expose usages of LibC which are outside Crystal::System, as only those usages would need to be prefixed Crystal::LibC.
Still, this wouldn't get us closer to the solution of the problem at hand.

easy for human . run fast for machine .


Allow editing metadata blocks for HDR10+, madVR sourced generation

Currently, the shots are overwritten by those created with only L1 metadata.
It should technically be replacing the metadata blocks (probably excluding L1?) by those in the JSON.
Then comes the question, how do we define a default list of blocks for all shots?

Previous versions used a globally defined L2 (like the old generator_example.json had) for the entire video that wasn't discarded when generating from madvr data.  I think this worked out fine even if it's technically supposed to be per-shot.  I actually had to revert to an older version for the time being because of it.
I'm converting regular 1080p Rec.709 bluray to 1080p BT.2020 HDR10 8.1 DolbyVision using incredibly generic zscale conversion and abuse power and slope values found through trial and error to compensate for something that seems to be more or less constant across every source disk tried that could probably be better done by applying a LUT if I had any reasonable way of generating an appropriate one at the moment.  I'm pretty convinced that the upscaling being done in hardware on modern TVs is better than any algorithm studios had access to (or were willing to spend the time running) until recently...  so doing it this way looks better than some 2k upscale UHD BDs...  which is very, very sad.
Currently either global or shot-list metadata is overwritten when generating so there isn't a way to use L2 as the bug says.  If the shot specification from the current generator_example is used for metadata that can vary in the future, I'd suggest allowing the duration to be left out (where the default would be the entire length of the generated data).   It can currently be set to an extremely high value for the same effect but I don't know how correct this is or if it will actually get "fixed" in the binary data.

At first I wanted to make the first shot the list of default metadata, but that wouldn't work for people that want to actually edit shots even for HDR10+/madVR sourced metadata.
So I might just make a new "default metadata" array of blocks that would disallow L5/L6/L11 blocks (because those already have a defined config).
And of course will have to correctly set metadata according to the initial shot/frame edits.

@GabeBlincoln It should now again be possible to do what you're looking for.
Example:
{
    "level6": {
        "max_display_mastering_luminance": 1000,
        "min_display_mastering_luminance": 1,
        "max_content_light_level": 1000,
        "max_frame_average_light_level": 400
    },
    "default_metadata_blocks": [
        {
            "Level2": {
                "target_max_pq": 2851,
                "trim_slope": 2048,
                "trim_offset": 2048,
                "trim_power": 1800,
                "trim_chroma_weight": 2048,
                "trim_saturation_gain": 2048,
                "ms_weight": 2048
            }
        }
    ]
}

Sounds good to me, I'll test later but don't forsee any issues.  :)
On Sun, Jan 2, 2022, 11:25 PM quietvoid @.***> wrote:

@GabeBlincoln https://github.com/GabeBlincoln It should now again be
possible to do what you're looking for.
Example:
{
"level6": {
"max_display_mastering_luminance": 1000,
"min_display_mastering_luminance": 1,
"max_content_light_level": 1000,
"max_frame_average_light_level": 400
},
"default_metadata_blocks": [
{
"Level2": {
"target_max_pq": 2851,
"trim_slope": 2048,
"trim_offset": 2048,
"trim_power": 1800,
"trim_chroma_weight": 2048,
"trim_saturation_gain": 2048,
"ms_weight": 2048
}
}
]}
—
Reply to this email directly, view it on GitHub
https://github.com/quietvoid/dovi_tool/issues/91#issuecomment-1003865156,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHTZ3BEP6QNXEAZ3PA3WDG3UUEQNLANCNFSM5K4JDSOQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>


fix: audio stays muted even after pressing unmute

Why
This can happen if physical silent button on iOS is turned on

How
set playsInSilentModeIOS to true in expo-av Audio

Test Plan
Audio plays in video on unmute if physical silent button is turned on

🤣 same time review.


[FEATURE REQ] New readme.md repo PR check to enforce Azure service versioning

API Spec link
NA
API Spec version
NA
Please describe the feature.
Each Azure service version must consist of operations that all share the same api-version.
Also, a service cannot mix & match stable and preview operations.
This is required for docs, SDK versions, and more.
This feature request is to add a PR check that looks at a new readme.md file, finds the latest default "tag".
This value MUST be of the format YYYY-MM-DD and can have an optional -preview suffix, or the tag value is an error and the PR cannot be merged.
In the readme.md's "input-file:" section, all paths MUST have a version that matches the tag value exactly, or the PR cannot be merged. SIDENOTE: This ensures that a preview version consists of only preview json files and a stable version consists of only stable json files.
It is an error and the PR cannot be merged if a json file exists in the version folder that is missing from the "input-file:" section. This catches a bug where the json file exists but was forgotten to be added to the "input-file:" section.

@JeffreyRichter: This has significant overlap with #29065.  I'm fine merging the issues or tracking separately.
Your request would be implemented in a new check named something like Versioning Validation, consisting of a TypeScript-based tool encapsulating the business logic, and a GitHub Action to run the check on PRs.
What should be done about existing specs?  Try to validate them and fix them, either in bulk or by adding suppressions?  Or make this check only run on PRs, so specs are only forced to fix (or suppress) in their next PR?
Note this may come as a surprise, when spec authors make a small bugfix PR, and are confronted with a versioning violation.  If needed, we can try to reduce the scope of when the check runs.  It's fairly easy to only run when certain files (like readme.md are edited).  It's more difficult to scope to changes within a file (like "only run if a new version was added to readme.md").
Or, we can just tell spec authors to add a suppression in suppressions.yaml in their spec folder.  But, if we want spec authors to fix this eventually, we'll need to ensure the suppressions have a limited scope, say limited to a single spec version.

You can merge #29065 and this issue. I had forgotten that #29065 was created. I added something to this issue missing from #29065 (an error to have a file in the version dir not in the input-file section) and #29065 has something that I'm missing from this issue (stable and preview API versions ❗cannot❗ have the same date) but we do want it ALL.
Right now, only run on PRs that have changed the readme.md file. Let's hold off on allowing suppressions. But, maybe Mike or I could add a label to counter the "BrokenServiceVersioning" (my initial proposed label name - may change) such as "BrokenServiceVersioning-TemporaryException" (also initial proposed label name - may change).
It would be nice to have a tool that can identify existing broken specs and then @mikekistler and & I can reach out to those teams and work with them to get things fixed. You won't be able to auto-fix existing specs that are broken; the service team must make some decisions first.

Right now, only run on PRs that have changed the readme.md file
I don't think this is sufficient, and we'll need to run on any changes under the folder containing readme.md.  This is required to catch issues like "added a json file in the version folder that's not listed in readme.md`.

Let's hold off on allowing suppressions.
Easy to add later.

But, maybe Mike or I could add a label to counter the "BrokenServiceVersioning" (my initial proposed label name - may change) such as "BrokenServiceVersioning-TemporaryException" (also initial proposed label name - may change).

Since the problem is in the source code (readme.md), rather than specific to the individual PR, I think suppressions should also live in the source code.  So instead of a PR label, I'd recommend adding an entry to the spec's suppressions.yaml.  We can even require this suppression to be limited to a single version if we want, so the spec author will be required to fix the problem in their next spec version.

It would be nice to have a tool that can identify existing broken specs and then @mikekistler and & I can reach out to those teams and work with them to get things fixed. You won't be able to auto-fix existing specs that are broken; the service team must make some decisions first.

This should be standard for all new checks, which should support all the following "modes":

Local dev machine, verify one spec
Local dev machine, verify all specs
PR, verify impacted specs and block build
CI, verify all specs (with suppressions unique to the "all" check), requires immediate attention if failing

We may also want to require a "formal azure service name" in the readme.md, that will appear in the documentation at the Azure Learn website.


git sumbit input box crash when auto fetch

git sumbit input box crash when chinese input method actived，git auto fetch, can't focus

Please include some more details, what version of VSCode are you using? Does this only happen when git auto fetch is on?

Please include some more details, what version of VSCode are you using? Does this only happen when git auto fetch is on?

version 1.52.1, every time

version 1.52.1, every time

Duplicate of #112621

Duplicate of #112621