Improve std.algorithm.iteration.each

This addresses some concerns/confusion brought up in this SO question.
The first is that each will accept a 2-arg lambda, but assumes that the first is for an index and doesn't pass by ref. This means that if you try to pass two args by ref (e.g. using lockstep), one will not reference the source.
The second is that each cannot iterate with an arbitrary number of variables (e.g. iterating over a range produced via lockstep/zip with >2 args). This adds support for such a scenario, but is a bit messy (involving a mixed-in generated foreach loop), and doesn't work for a templated opApply (cannot determine the arity).
I can break apart the PR if people like the first (simple) fix but feel that the latter is too complicated for a somewhat edge-case-y scenario.

The problem is lockstep, which is an ancient rarity that uses opApply. Now that we have enumerate I don't think lockstep is of any significant utility. I think each as a whole was a mistake in the first place, but supporting opApply was especially arcane. Sigh...
The same fix just happens to work with zip because of tuple expansion in foreach over ranges of tuples, but can be implemented much simpler and more structured by using Tuple.expand.

Now that we have enumerate I don't think lockstep is of any significant utility

I don't think enumerate really replaces lockstep. It only provides indices, not other arbirtrary ranges.
In theory we should be able to replace lockstep with zip, but the tuple returned by zip does not allow access to elements by ref. I was trying to figure out a reasonable way to accomplish this but couldn't. I guess it could return a tuple of Reference!T where each element would wrap a T* but behave like a T (I think someone was talking about a referencer type on to forums recently ... might be useful?)

but supporting opApply was especially arcane

Again, this usually comes down to wanting ref variables in your loop. Aside from that, yeah, I'd rather be using range interfaces.

can be implemented much simpler and more structured by using Tuple.expand

Yeah, that would be cleaner than the mixin.

I think each as a whole was a mistake in the first place

It falls in the 'nice, but I could live without it' category for me. I didn't know it existed until I saw that SO question.

I don't think enumerate really replaces lockstep. It only provides indices, not other arbirtrary ranges.

I'm talking about using enumerate with zip.

It falls in the 'nice, but I could live without it' category for me.

Your code will be better off without using it.
Ah yes, I knew I was forgetting something, the ref-ness is the straggling issue. I think bearophile suggested a RefTuple library solution at some point, but I don't remember the details. I suspect the difficulty would be making it work with @safe.

This addresses some concerns/confusion brought up in this SO question.

FYI, the user cross-posted the same question on SO, D.learn, and IRC. I've replied on IRC and discussed the problem there.
There's several situations here to take into account:

Non-templated opApply - just pass the arguments to the predicate.
Templated opApply, non-templated predicate - here we can get the predicate's parameters to iterate over.
Templated opApply AND predicate - although each could take a stab at guessing the number of arguments, the sensible behavior here is probably a compile error.

Also, isn't it possible to use a tuple as an iteration variable? That would avoid the need to use string mixins.

Your code will be better off without using it.

FWIW, a lot of people have provided positive feedback about each before and after a D version including it was released. In contrast I don't remember anyone else being negative about it.

Also, isn't it possible to use a tuple as an iteration variable?

Only for the range interface. opApply requires distinct arguments.

I think bearophile suggested a RefTuple library solution at some point, but I don't remember the details

A quick search didn't turn up any implementations, but here's a rough draft: http://dpaste.com/3NX2JV4

I suspect the difficulty would be making it work with @safe

... yeah. not sure how to do this without slinging around pointers. Maybe its possible to capture it in a closure somehow? Though that might be overkill.

FWIW, a lot of people have provided positive feedback about each before and after a D version including it was released. In contrast I don't remember anyone else being negative about it.

I don't consider it a big issue. each is here to stay.

Only for the range interface. opApply requires distinct arguments.

Perhaps a solution that calls opApply directly would be better.

Perhaps a solution that calls opApply directly would be better.

I think that would be cleaner. I'll give it a try this week.

@JakobOvrum actually, calling opApply directly doesn't seem easier. opApply takes a runtime delegate, but I have a compile-time alias. Is there an easy way to convert one to the other? I can't just use opApply(pred).

Use binaryFun to convert pred to a function/delegate?
Also,
        enum args = iota(nArgs)
            .map!(i => "arg%d".format(i))
            .join(",");

can be written as
      enum args = "%(arg%d,%)".format(iota(nArgs))

Use binaryFun to convert pred to a function/delegate?

But its not a binary fun. Its an n-ary fun with n > 2.
If I figure out how binaryFun works maybe I could apply the same approach though.
Thanks for the format tip though.

Actually, the problem isn't that its n-ary, but that I need to pass a compile-time alias as a runtime delegate.
void useDelegate(int delegate(int) del) { writeln(del(42)); }
void useAlias(alias fn)() { useDelegate(fn); }
// implicit conversion from templated lambda to delegate
useDelegate(x => x + 1);
// d.useDelegate (int delegate(int) del) is not callable using argument types (void)
useAlias!(x => x + 1);

In that toy example, I can work around the limitation with
void useAlias(alias fn)() { useDelegate(i => fn(i)); }

In each, however, I don't know how many parameters the lambda would need, so it seems like I'd have to use a mixin anyways.

If you're going to accept things like "a" as the alias, then you will have no chice but to do the equivalent of what binaryFun does.  I remember a proposal for an naryFun or something similar, but I don't know if it ever ended up in phobos.  It will effectively need to convert string lambdas to real lambdas, change functions to delegates, etc.

If you're going to accept things like "a" as the alias, then you will have no chice but to do the equivalent of what binaryFun does

Are you suggesting that we should support something like each!"writeln(a,b,c)"? While each supports string lambdas for 1-2 args, like many other phobos functions, I got the impression that those were on the way out. Supporting regular (non-string) 2+ arg lambdas should satisfy the vast majority of use cases. I don't think there are other phobos functions that use 3-arg string lambdas.
Either way, naryFun wouldn't help convert an alias to a runtime delegate -- unaryFun and binaryFun don't do this either.

I'm suggesting that if string lambdas are supported by this function, they should be supported for all possible instantiations.  binaryFun and friends don't necessarily give you a delegate directly, but they contain the logic to convert a string lambda to something callable and provide a consistent call interface which can easily be wrapped in a delegate.

If you don't know how many parameters the lambda will need, what about letting the compiler figure it out for you?
void useAlias(alias fn, Args...)()
{
    useDelegate((Args args) => fn(args));
}

(or something along these lines.)

@quickfur I'm having trouble understanding how that will allow me to pass an alias to opApply without knowing how many args it expects. Who provides Args?

Hmm. I suppose you'll somehow need to introspect the alias to discover what kind of arguments it has. Perhaps std.traits.Parameters might do the job? Something like:
// Warning: untested code
void myFunc(alias userFunc)(...)
{
    auto proxy = delegate(std.traits.Parameters!userFunc args) { return userFunc(args); }
    r.opApply(proxy); // would this work?
}

Here's a (rather crude) proof-of-concept:
struct MyIterable
{
    string[] sdata = [ "abc", "def" ];
    int[] idata = [ 123, 456 ];
    int opApply(int delegate(string x, int y) dg)
    {
        foreach (s; sdata)
        {
            foreach (i; idata)
            {
                auto r = dg(s, i);
                if (r != 0) return r;
            }
        }
        return 0;
    }
}

void each(alias func, R)(R iterable)
{
    import std.traits : Parameters;

    auto proxyDg = delegate(Parameters!func params) {
        return func(params);
    };
    iterable.opApply(proxyDg);
}

void main() {
    MyIterable it;

    it.each!((string x, int y)
    {
        import std.stdio;
        writeln(x, y);
        return 0;
    });
}

In the real implementation, you should probably try to do the introspection the other way round, i.e., by finding an overload of opApply that func can be invoked with, so that the user code doesn't have to specify parameter types. I'm not sure if that will be possible, but it would be icing on the cake.

if you can think of a way to do that, great, but I'm not sure how that would work right now, and I'd rather not require users to provide types on their lambda.
That being said, IIRC the current approach won't work with a templated opApply. I guess I could add another overload that works with a templated opApply but requires a typed lambda...

whether to invoke opApply directly or use a generated foreach loop is a separate issue. Calling opApply is cleaner, but requires the user to provide a lambda that returns an int.
lockstep(a, b, c).each!((ref x, ref y, ref z) { ++x; ++y; ++z; });

becomes
lockstep(a, b, c).each!((ref x, ref y, ref z) { ++x; ++y; ++z; return 0; });

which I think is a bit more awkward.

Though the delegate we use internally could just return 0 itself.
void each(Iterable)(Iterable r)
    if (!isRangeIterable!Iterable && !isForeachIterable!Iterable &&
        __traits(compiles, Parameters!(Parameters!(r.opApply))))
{
    auto dg = delegate(Parameters!(Parameters!(r.opApply)) params) {
        pred(params);
        return 0;
    };
    r.opApply(dg);
}

That behaves the same as the mixin approach. Is there a benefit to prefer calling opApply as opposed to using the mixin'd loop? Faster compilation?

note that this:
  auto proxyDg = delegate(Parameters!func params) {
    return func(params);
};
iterable.opApply(proxyDg);

could lead to confusing situations like:
auto a = [0,1,2];
auto b = [3,4,5];
auto c = [6,7,8];

lockstep(a, b, c).each!((ref x, ref y, ref z) => ++x);

Afterwards, a == [1,1,2]. The delegate will return nonzero on the first iteration, ceasing the loop.

What I wrote, as I said, was just a crude proof-of-concept. You already found yourself that the wrapping delegate could just return 0, then the problematic cases you cited are moot.

Actually, that worked quite nicely. Thanks for the suggestion @quickfur! I replaced the delegate with a nested function to (maybe?) avoid allocating a delegate.

Cool, and by working directly with range primitives, there's no need to generate a mixin in either case. If/when #3882 gets in, I may be able to consolidate the unary/binary/n-ary cases into one function each for opApply and a ranges.

ping @JakobOvrum @yebblies
Anything more that needs to be done in this PR, or are we good to merge? Let's not let this sit here for much longer.

LGTM

Ping @JakobOvrum

Still waiting on #3882 to address an earlier comment by @yebblies.

Anything more that needs to be done in this PR, or are we good to merge? Let's not let this sit here for much longer.

Still waiting on #3882 to address an earlier comment by @yebblies.

Seems like you can't address this comment for now or you have to include a private naryFun.
What do other people think?

Well, my original approach was "if you want >2 params, you can't use a string lambda". That seemed reasonable to me, but it was suggested that it should support string lambdas for any param count.
That's why I implemented naryFun, but now that #3882 is closed based on, among other things, the assertion that string lambdas are on the way out, I wonder if the original approach is ok.

Well, my original approach was "if you want >2 params, you can't use a string lambda". That seemed reasonable to me ...  wonder if the original approach is ok.

As nobody objected for the last ten days - seems like that's the way to go!
Btw if you include "issue 15358" in the commit message and/or title the bugzilla bot will find it ;-)

Squashed, rebased on master, and referenced the issue.

LGTM

Auto-merge toggled on


Option to skip the auto trim

Greetings and thanks for the excellent software.
In the same spirit of the issue #76 the white spaces are getting removed in certain cases where they could be meaningful in the final render.
Taking advantage of the example given in the issue mentioned above, with the sole addition of a leading space before the word "Hey"

 Hey there, html2jade is awesome

In the current version it becomes:
html
  body
    p
      | Hey there,
      a(href='#') html2jade
      |
      strong is awesome

trimming the space before "Hey".
My request is that there should exist an option to indicate that whitespaces should not be auto trimmed, so the result of that same conversion could be
html
  body
    p
      |  Hey there,
      a(href='#') html2jade
      |
      strong is awesome

keeping the extra space before "Hey".
To allow for this behaviour to be optional my suggestion is the creation of a new option: skipautotrim.
The changes are simple, sorry for not making that a Pull request, not entirely familiarized with git yet.
html2jade.coffee, line 64
    @noEmptyPipe = options.noemptypipe ? false

becomes
    @noEmptyPipe = options.noemptypipe ? false
    @noAutoTrim = options.noautotrim ? false

html2jade.coffee, line 152
    line = line.trimLeft() unless node?.previousSibling?.nodeType is 1
    line = line.trimRight() unless node?.nextSibling?.nodeType is 1

becomes
    if @noAutoTrim
      line = line.trimLeft() unless node?.previousSibling?.nodeType is 1
      line = line.trimRight() unless node?.nextSibling?.nodeType is 1

That would be very helpful because in certain cases the trailing and leading whitespace adds to the total width of the element, font icons, for instance. Making the change this way is back compatible and optional.
Best regards

looks like a reasonable feature. can't promise when though.
if you need this in a hurry, please fork.

Thanks for the response.
No hurry, considering this is only a dev dependency of a private project I already changed what I needed locally.
If you prefer I can (learn how to and) send the change as a Pull Request. The change should be very similar to the one in the 693186f1bb1667a89f7612721744745b8acf5d4e commit.

@ferdinando-ferreira yes, PR would be wonderful. thx

Closing for lack of interest


[US2366055] Update "LabVIEW DataType to Message Element DataType.vi" to use gRPC "Enum Value"

Updated LabVIEW DataType to Message Element DataType.vi to convert Eum U8, Enum U16, Enum U32, and Enum U64 to use gRPC EnumValue Message Element DataType instead. Previously, the were converted to their corresponding UInt type.

AB#2366055

Where and how is this VI used? Are all of the callers in the other PR you created? ie: https://github.com/ni/measurementlink-labview/pull/213
The diff looks reasonable, but it is difficult to know if this would break any assumptions made by callers. Will caller VIs break with a compiler error because of this change? Or would it just be potential logic errors?

@JasonC512

Where and how is this VI used?

This VI is called by MeasurementLink Measurement Server.lvlib:Get MetaData from Configuration.vi and MeasurementLink Measurement Server.lvlib:Get MetaData from Result.vi to populate the configuration and output parameters.
See usage:

Are all of the callers in the other PR you created? ie: https://github.com/ni/measurementlink-labview/pull/213

The callers of this VI already exist in the MeasurementLink repo. My other PR adds no new callers.

The diff looks reasonable, but it is difficult to know if this would break any assumptions made by callers. Will caller VIs break with a compiler error because of this change? Or would it just be potential logic errors?

Based on previous discussions with Everett, we think that this should be pretty safe. The existing behavior is that LabVIEW enums get coerced to gRPC UInts and there is no LabVIEW types that converts to gRPC Enums. This change results in LabVIEW enums now being converting to gRPC Enums instead of gRPC UInts. The main issue I could see is that if an existing caller relies on LabVIEW enums being coerced to gRPC UInts they would need to update their handling, but I don't think there are any callers trying to use other than MeasurementLink. This would be more of a change in behavior rather and I'd lean towards this unlikely to cause compile errors.


ARROW-15386: [Integration] Unskip test cases

12198

 Quality gate: Passed
3 Issues

 3 Code issues

Details


Use selectable property almost everywhere

Add selectable property in some native Text blocks, to match desktop
side.
Remove globalStyles.selectable.

r? @keybase/react-hackers

Didn't test all the places I changed, just the easily accessible ones, on desktop and mobile. The changes are pretty straightforward, though.


Added the NLog file to the solution

This way the file is more accessible to developers.

Can you please add this to the Stratis.Bitcoin.csproj?
  <ItemGroup>
    <ContentWithTargetPath Include="Configuration\Logging\NLog.config">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <TargetPath>NLog.config</TargetPath>
    </ContentWithTargetPath>
  </ItemGroup>

It will automatically copy nlog.config to the build directory in case the config file is not present there.
This will basically make full logging a default option. If the logging is not needed for some reason developer can just edit the file in the build dir to log nothing.
This will solve the problem of noticing some bug and not being able to investigate it.
Also since the file was copied from \Documentation I guess it will be a good idea to remove it from the original folder to avoid duplicates.

That is very interesting suggestion. At 1st I was like no way, but then I like it!

Can you please add this to the Stratis.Bitcoin.csproj?

I don't really want to enable this by default, it logs 100MB/min. It's there for reference only.
What I've done, however, is add a config file that logs everything in StratisD. It's 'Off' by default and will be saved in the right folder so that devs can just edit it and be on their way.

I don't really want to enable this by default, it logs 100MB/min. It's there for reference only.

Ok, makes sense.
If it would log only on debug level and we had a good trace\debug separation so just a few MB/min is generated would you reconsider?

Yeah possibly. Another problem is that if we keep a cop of the file in Stratis.Bitcoin, Nlog.config is copied to every bin folder of every feature so it gets a bit messy.
I think we should only copy the NLog.config file in the console apps.
what do you think?

definitely not needed everywhere

Right, I'm going to merge this like this. let's reconsider later whether to set the minLevel to debug by default. @noescape00

Ok, sounds good.
Btw you didn't delete the config file from the original folder before merging so now we have it duplicated.


Choreos Break when using "make-space" tool

When creating vertical space, the choreos are broken up if they are on the horizontal line.

Fixed by #133


problem with messing up VERSION and ACCESSION

pharokka version: 1.7.3
Python version: Python 3.10.14
Operating System: Linux

Description
I used pharokka to annotate viral contigs. The run was finished successfully. However, some of the VERSION ids are messed up in the output file while the LOCUS and DEFINITION keep the same with the sequence headers of the input fasta file.
For example, in the below output file, the LOCUS is the same with the input sequence header, but the ACCESSION and the VERSION were changed. I subsequently used phold to further annotate the pharokka output genbank file. Phold would use the VERSION id as the sequence ID. Thus, my phold output has different information with the original input sequence headers. It brings me troubles with tracing information along the analysis. Could you please help me with this problem so that I can run pharokka in the future with large amount of data without correcting the sequence headers later?
Best,
Lingyi
LOCUS       BU_D1_MACV_NODE_1129_length_20832_cov_2.052837 20832 bp    DNA     linear   PHG 21-AUG-2024
DEFINITION  BU_D1_MACV_NODE_1129_length_20832_cov_2.052837.
ACCESSION   BU_D1_MACV_NODE_1129_length_20832_cov_2
VERSION     BU_D1_MACV_NODE_1129_length_20832_cov_2.52837

### What I Did

I ran the following code and it finished successfully.
pharokka.py \
        -i ten_seqs.fasta \
        -o pharokka_output \
        -d pharokka_database \
        -t 94

there is a error message in the begnining of the run:
DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  __import__('pkg_resources').require('Pharokka==1.7.3')
/miniconda3/envs/pharokka_env/lib/python3.10/site-packages/numpy/_core/getlimits.py:555: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero.
  setattr(self, word, getattr(machar, word).flat[0])
/miniconda3/envs/pharokka_env/lib/python3.10/site-packages/numpy/_core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero.
  return self._float_to_str(self.smallest_subnormal)
/miniconda3/envs/pharokka_env/lib/python3.10/site-packages/numpy/_core/getlimits.py:555: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero.
  setattr(self, word, getattr(machar, word).flat[0])
/miniconda3/envs/pharokka_env/lib/python3.10/site-packages/numpy/_core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero.
  return self._float_to_str(self.smallest_subnormal)

Download
https://www.mediafire.com/file/7ybpxn8lil1av70/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Hi @lingyi-owl ,
The behaviour of the gff-gbk conversion program inside pharokka (bcbio-gff) will try and convert the pharokka gff to a genbank based on the genbank format.
https://www.ncbi.nlm.nih.gov/genbank/samplerecord/
I think there is no issue with the ACCESSION, as genbank accessions will omit everything before the first '.' .
GenBank records usually are like e.g  "{ACCESSION}.{VERSION_NUMBER}"
Which is the behaviour for your contig.
VERSION is strange,  it is cutting out the 0 - my guess is that is parses '052837' as '52837' (and e.g. would parse 01 as 1). I will have a look and may make an issue in bcbio-gff but I'm inclined to not make any changes regardless.
To be honest, in general, I'd advocate renaming your contigs before running pharokka from the complicated/long spades headers to something easier for software to parse.
In my opinion, the problem is really when we run something like pharokka, we are trying to do a bit too much with the GenBank format (which isn't optimal!). So that should mitigate the problem.
George

Hi @estebano11 - this is no bug in pharokka, just a warning, so it is not a big deal and I would just ignore it. There is nothing wrong with your configuration.
I am pretty sure it is caused by numpy v2. You can remove this warning by installing numpy v1 e.g. pip install numpy==1.26.4 I would assume.
George

I am pretty sure it is caused by numpy v2. You can remove this warning by installing numpy v1 e.g. pip install numpy==1.26.4 I would assume.
George

Dear George,
Thank you, it solved the warming message.
Esteban


Gridftp node type  modifications

This pull request includes changes into most of the data pipeline node types.
Main changes are

Deploying NiFi is now possible on ubuntu VMs
Can enable/disable access to web interface
Can change the NiFi port from 8080 to something else

This PR fixes issues #4  and #5 .
Discussion point:
It may be better to do a separate pull request from radon/particles and then this one. As right now it merges very many commits into this PR.

@pjakovits what would be your suggestion wrt. this PR? Do I still have to merge current radon-particles first and then this PR?


How to check that ws://selenoid-host.example.com:4444/vnc/ API is working?

In issue #582 you recommended to use noVNC for opening web-socket proxying VNC traffic provided by Selenoid API.
After running Selenium test I tried to connect VNC by running novnc http://localhost:4444/vnc command, it opens http://localhost:6080/vnc.html?host=localhost&port=6080 url that hanging in "Connecting" state.
How can I check that web-socket proxying VNC traffic is ok?

@pavelsr you can just try to do a websocket handshake with curl, e.g.: https://gist.github.com/htp/fbce19069187ec1cc486b594104f01d0 Usually VNC can stop working behind reverse proxy because of incorrect proxying of websockets.

Closing because of inactivity. Feel free to reopen if having more questions.


Client crashes when oppening shop (not charm incompatibility)

crash-2022-12-15_03.44.36-client.txt
I dont have charm installed on my server, but when players try to open a shop it crashes their client

Duplicate of #62
We have already fixed it, and it is planned for next release

Fixed in 0.2.6


Pass custom scale to flash attention

In current implementation custom scaled is not passed to flash attention.

@Subuday oh shoot, yes i think you are right, thanks!

wait, did they introduce the scale kwarg recently? i must have done it this way because they didn't have it previously. we'll need to enforce a certain pytorch version if so

@Subuday let's go with this for now


Start of rake tests, #315

This is the logic testing I was talking about. I know folks aren't fans, but gotta do something within the coming week, and this allows for fully examining edge case behavior. We'll see how long the tests take to run as we build up iterations.

@knod Just to be sure. Is this basically what you were trying to write?
const expected = {
  0: 192,
  100: 192,
  1000: 42.9
};

Object.keys(expected).forEach(earned => {
  const client = cloneDeep(CLIENT_DEFAULTS);
  client.current.earned = earned;
  it(`with household of __, current earnings of ${earned}`, () => {
    expect(getSNAPBenefits(client, 'current')).toBeCloseTo(expected[earned], 4);
  });
});

@wacii: No, actually, not quite. That doesn't account for further permutations. There will be a different result for a household with that earned income that has one member vs. one that has 8 members. I'm just showing the first of many iterators. If it would help, I'll add another one.

Ah, I see. So you will be looking at combinations of number of members and earned income. The underscores in the test case names make sense now.

Another layer has been added, so maybe it's a bit easier to see how this will grow. It adds a bit of utility testing.

Branches still exist on my repo, but wacii is taking the functionality shown in those to try to pre-build test those test cases instead of generating them at run-time.


import syntax don't like golang syntax

import syntax don't like golang syntax

Please be more clear about what the problem is. Can you include details including what you saw vs what you expected?

if tengo grammar same with golang. the code can optimize with native code.


Failing to verify requests

Bug Report
Current Behavior
Without any apparent trigger, the verifyAndReceive stopped verifying requests successfully:
probot.webhooks.verifyAndReceive({
  id: event.headers['x-github-delivery'],
  name: event.headers['x-github-event'],
  signature: event.headers['x-hub-signature'],
  payload: JSON.parse(event.body)
})

Ends up with:
{
  "errorType": "AggregateError",
  "errorMessage": "Error: [@octokit/webhooks] signature does not match event payload and secret at verifyAndReceive (/var/task/node_modules/@octokit/webhooks/dist-node/index.js:478:19)",
  "name": "AggregateError"
}

Expected behavior/code
No change was made on my end, not from a code or configuration perspective. This started happening last night, with no apparent reason.
I tried rolling back my bot to the version I can verify worked based on previous logs; I tried replacing the webhook secret and certificate. Nothing helped.
Environment

Probot version(s): v13.0.2 (tried with v12) (EDIT: I thought I tried with v12 before opening this issue)
Node/npm version: Node 18/npm 9 (tried with 20 for runtime)
OS: Amazon Linux 2023 (tried with Amazon Linux 2) (aws lambda runtimes)

Possible Solution
No solution yet - but as a temporary workaround, to keep my bot alive - I stopped verifying webhook requests:
probot.webhooks.receive({
  id: event.headers['x-github-delivery'],
  name: event.headers['x-github-event'],
  payload: JSON.parse(event.body)
})

Additional context/Screenshots
Bot in question: https://github.com/TomerFi/auto-me-bot

Starting from Probot v13 (And it should have been this way before, but apparently wasn't), you can no longer parse the body before passing it, you need to pass it as a string.
Please try
probot.webhooks.verifyAndReceive({
  id: event.headers['x-github-delivery'],
  name: event.headers['x-github-event'],
  signature: event.headers['x-hub-signature'],
  payload: event.body
});

This is because X-Hub-Signature contains a signature for the raw JSON, and parsing and re-encoding it could possibly change it.

I'm also seeing this error after upgrading to probot v13. Will try the fix and see what happens.

I'm also seeing this error after upgrading to probot v13. Will try the fix and see what happens.

Using the string body seems to have fixed the issue in our case. One difference in our case relative to @TomerFi's code is that we're using the x-hub-signature-256 header, and falling back to x-hub-signature:
await probot.webhooks.verifyAndReceive({
  id: headersLowerCase['x-github-delivery']
  name: headersLowerCase['x-github-event'],
  signature:
    headersLowerCase['x-hub-signature-256'] ||
    headersLowerCase['x-hub-signature'] ||
  payload: event.body
});

Starting from Probot v13 (And it should have been this way before, but apparently wasn't), you can no longer parse the body before passing it, you need to pass it as a string.

This should probably be stated clearly somewhere (v13 release notes) to prevent future issues. Out of curiosity, is probot wrapping the API from @octokit/webhooks, as its docs specify that passing an object should still work, but is deprecated.

Yes, Probot wraps many Octokit APIs.
The docs for @octokit/webhooks seem to be out of date on that.
The release notes should contain every breaking change made in v13.
It seems that this specific change did slip through the cracks.

I'm also seeing this error after upgrading to probot v13. Will try the fix and see what happens.

Using the string body seems to have fixed the issue in our case. One difference in our case relative to @TomerFi's code is that we're using the x-hub-signature-256 header, and falling back to x-hub-signature:
await probot.webhooks.verifyAndReceive({
  id: headersLowerCase['x-github-delivery']
  name: headersLowerCase['x-github-event'],
  signature:
    headersLowerCase['x-hub-signature-256'] ||
    headersLowerCase['x-hub-signature'] ||
  payload: event.body
});

Starting from Probot v13 (And it should have been this way before, but apparently wasn't), you can no longer parse the body before passing it, you need to pass it as a string.

This should probably be stated clearly somewhere (v13 release notes) to prevent future issues.
Out of curiosity, is probot wrapping the API from @octokit/webhooks, as its docs specify that passing an object should still work, but is deprecated.

Thanks @askoufis I'll give that a try and report back.

The docs for @octokit/webhooks have been updated, and an error is now thrown whenever an object payload is passed.
Simply update your lock files to pull in the latest version of @octokit/webhooks

@wolfy1339, @gr2m  Thank you, but my issue has not yet been resolved. I'm still getting, as originally reported:
signature does not match event payload and secret...

This bot had been up for a while, and this started happening without any change on my end. Initially, I thought, and perhaps I still do a little bit, that this is a GitHub issue because, around the same time, I noticed Tokens and Deploy Keys in various projects of mine acting out. See this discussion I started. Actually, initially, I figured the certificate generated by GitHub had expired. But since then, I have regenerated and replaced the certificate and webhook secret multiple times.
As I explained just now in https://github.com/TomerFi/auto-me-bot/pull/385, my current running versions are:

This is the currently running function in Lambda, implementing the change suggested by @AaronDewes and @askoufis in previous comments:
const { Probot } = require('probot');
const autoMeBot = require('./auto-me-bot');

// handler function for aws lambda >> 'Handler:src/app-runner.handler'
exports.handler = async (event) => {
    let probot = new Probot({
        appId: process.env.APP_ID,
        privateKey: Buffer.from(process.env.PRIVATE_KEY, 'base64').toString('utf-8'),
        secret: process.env.WEBHOOK_SECRET,
        logLevel: process.env.PROBOT_LOG_LEVEL || 'info'
    });

    await probot.load(autoMeBot);

    return probot.webhooks.verifyAndReceive({
        id: event.headers['x-github-delivery'],
        name: event.headers['x-github-event'],
        signature: event.headers['x-hub-signature-256'] || event.headers['x-hub-signature'],
        payload: event.body
    });
};

And these are the logs from CloudWatch:

The webhook secret isn't related to app certificates, tokens, or deploy keys. It's simply a SHA 256 HMAC of the payload
If you take the same payload and same secret, is the resulting signature the same signature?
const payload = "{}" // payload as received from github
const secret = "secret";
import { sign } from "@octokit/webhooks-methods";

await sign({ secret, algorithm: "sha256" }, payload);

So everything is working now, and here's the gist in case someone bumps into this:
I don't know what was the original error message; my logs aren't old enough. But something in the wording and the fact that in the days leading to the error, I noticed tokens and deploy keys missing (potentially expired, see discussion) made me think that probably, the certificate created by GitHub for my app has expired. Given I use environment variables to configure my app running on AWS Lambda, I replaced the environment variable content.
Turns out in AWS Lambda, based on the documentation, environment variables are locked to function versions. So, every time I changed the variable's content, I changed it for the next version. From this point on, all my tests and assumptions were based on the wrong environment and content.
To sum it up, switching the payload to string fixed my issue.
Thanks, everyone!


[wip] Starting to port Albert's scripts

Closes https://github.com/scenerygraphics/sciview/issues/373

I've started on https://syn.mrc-lmb.cam.ac.uk/acardona/fiji-tutorial/#find-peaks
I was able to get it running, but it is not the correct visualization yet. It currently looks like:

As you can see there are some scaling/offset issues to resolve. The script is also longer than I'd like, but I'm just trying to air it out for now. I also don't want this to use 3 separate volumes, but it was simply faster in this situation.
Tagging @acardona so he knows where the code is living.

Ok fixed, find-peaks is fixed:


making corrections to the P4₁₆ spec. based on reading version 1.2.2

Realize this is a WIP, but thanks in advance for all this work! Great stuff.

Can we merge this? You can submit more fixes in a separate PR.

This is fine.

Fixed the [mostly-fake] conflict.


Segmentation Fault

System information

Ubuntu 20.04
TensorFlow 2.2.0
Python version: 3.8.2
Installed via pip
ROCm/MIOpen version: 3.5.0
GPU model and memory: RX 5600XT

tensorflow is installed correctly. But when I try to run "tf_cnn_benchmarks.py --num_gpus=1 --batch_size=32 --model=resnet50" I get segmentation fault (core dumped)
I also tried running my own program and it says "WARNING:tensorflow:Layer lstm will not use cuDNN kernel since it doesn't meet the cuDNN kernel criteria. It will use generic GPU kernel as fallback when running on GPU"

RX 5600 is a RDNA gaming card. I don't think we support this card.
You can take a look at the output of $ /opt/rocm/bin/rocminfo to get your gfx architecture number. Then refer to here for the list of supported hardware.


Can't see events from calendar

Using google calendar. The default calendar pulls in events and displays but the bigger *week or month view( calendar you provide doesn't display them - am I missing something pls? have read and tried lots!

Possible reasons;

Maybe your configuration might be wrong (misspelled or something wrong)
You may need just to wait to represent all the data. Sometimes it will takes some minutes.
Other module may have interferences. (Error or something)

I need your configuration to guess what happens.
And read this doc; it may help;
https://github.com/MMRIZE/MMM-CalendarExt3/blob/main/.github/ISSUE_TEMPLATE/bug_report.md


Upload Performance

This PR adds UploadSectorTimeout to the WorkerConfig. The name is pretty self-explanatory, it allows setting a timeout on sector uploads to ensure a slab is not blocked by a single slow host before reaching full redundancy. When the timeout is triggered, the upload fails and we simply select the next host. The slab upload code returns a list of slow hosts which is taken into account for consecutive slab uploads.
I took a quick baseline of master
2023/01/31 14:33:55 upload succeeded, 142.4 MiB in<PHONE_NUMBER>96s (4.476922737883837 mbps)
2023/01/31 14:40:06 upload succeeded, 142.2 MiB in<PHONE_NUMBER>16s (3.214368380640808 mbps)
2023/01/31 14:43:12 upload succeeded, 142.4 MiB in<PHONE_NUMBER>66s (6.412339944826194 mbps)

vs the code in this PR
2023/01/31 17:10:33 upload succeeded, 49.0 MiB in 17.457930005s (23.54470386135564 mbps)
2023/01/31 17:10:59 upload succeeded, 142.2 MiB in 26.235298523s (45.45539921928183 mbps)
2023/01/31 17:11:29 upload succeeded, 142.4 MiB in 29.726371621s (40.17044256946652 mbps)

The sizes don't include the redundancy so we're effectively putting 3 times those amounts on the network. I think it's a decent performance improvement (almost) without adding any complexity to the upload code which is nice.
TODO: improve it so the host that timed out can still come in first with the upload (?)

No need to review yet, want to refactor it a little and avoid the detached context


Definition of index name node_loc not present in docu

This issue is a follow up discussion of comments in PR#275:

Francesco's comment
Paul's comment @khaeru
Daniel's comment @danielhuppmann

It popped up that the definition of index name node_loc is not present in docu. It is "hidden" in Java code. I think a definition of these index names should be clarified or at least properly referenced in the documentation, but please correct me if it's not the case.
As a way to easy understand the issue, read Paul's comment below:
@francescolovat —that's a great question. Let's also CC @danielhuppmann @gidden per #254.
There are at least three things going on here:

In ixmp (Python/Java code), every dimension of a parameter has both an index set and an optional index/dimension name.

See e.g. the init_par() docs.
The sets must be actual sets in the Scenario.
The names can be anything; e.g. you can have a dimension indexed by year but named 'foo'.

In the MESSAGE GAMS code, there are a number of aliases for sets.

See sets_maps_def.gms.
For instance, the lines: https://github.com/iiasa/message_ix/blob/d7a75e63e7d16632c7bd0ed88b0a220b70a8c42b/message_ix/model/MESSAGE/sets_maps_def.gms#L133-L136 show that e.g. node_share is always an alias of node.
This is needed because a GAMS parameter that has the same index set for two of its dimensions can't re-use the same name, e.g. you can't define a GAMS parameter foo(year, year);.

See #254. While the GAMS definition of MESSAGE's structure is in the .gms files, there is (must be) a parallel definition of the same structure for the Python code to use. At the moment, this is (wrongly, IMO) hidden in the non-open ixmp_source Java package.

See for instance here: https://github.com/iiasa/ixmp_source/blob/6c2afd932e10e284ff12c4a20a0d62372f609228/src/main/java/at/ac/iiasa/ixmp/modelspecs/MESSAGEspecs.java#L877 and here: https://github.com/iiasa/ixmp_source/blob/6c2afd932e10e284ff12c4a20a0d62372f609228/src/main/java/at/ac/iiasa/ixmp/modelspecs/MESSAGEspecs.java#L76-L82
These lines are basically equivalent to: scen.init_par('historical_new_capacity', idx_sets=['node', 'technology', 'year'], idx_names=['node_loc', 'technology', 'year_vtg'])

So what you've uncovered (I hadn't noticed myself!) is:

There is not necessarily a correspondence between a dimension name on the Python side and any alias on the GAMS side.

E.g. node_loc is a dimension name, but there is no GAMS alias.
E.g. land_emission is defined over the GAMS alias location, but on the Python side it does not have a dimension name.

Some index names, like node_loc, are hidden in the Java code and thus the correspondence between them and particular sets can only be guessed at.

I hope this helps to understand the situation and to propose improvements.
Originally posted by @khaeru in https://github.com/iiasa/message_ix/pull/275#issuecomment-565364522

No PR was opened for this by the feature freeze for v3.2.0, so we postpone to v3.3 (or later).

No PR was opened for this by the feature freeze for v3.2.0, so we postpone to v3.3 (or later).


Update sts to 2.13.28

Updates software.amazon.awssdk:sts from 2.13.21 to 2.13.28.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk", artifactId = "sts" } ]

labels: library-update, semver-patch

Codecov Report

Merging #348 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #348   +/-   ##
=======================================
  Coverage   46.26%   46.26%
=======================================
  Files          24       24
  Lines         281      281
=======================================
  Hits          130      130
  Misses        151      151

Continue to review full report at Codecov.

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


fullscreen mode z-index too low for spectre's avatar styles

spectre css sets a z-index of 100 for @z-index-1 used by its avatar styles which when you use simplemde in fullscreen mode leave you with avatars in front of the toolbar and edit area -- Not sure who should fix what here?

@prologic Do you have a online demo for that bug?
Thanks.

I can construct one; hold on
James Mills / prologic
E<EMAIL_ADDRESS>W: prologic.shortcircuit.net.au
On Sat, Jul 15, 2017 at 11:50 PM, Yan Zhu<EMAIL_ADDRESS>wrote:

@prologic https://github.com/prologic Do you have a online demo for
that bug?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sparksuite/simplemde-markdown-editor/issues/610#issuecomment-315589766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOv-iDqUroG12R6eCskqpkfkA3yqx_Iks5sObK2gaJpZM4OY7D0
.

@prologic I think that it is up to you to override the simplemde z-index as it doesn't seams feasible to me that simplemde can compute the maximum z-index  automatically.
As a developer you're the best person to know what is the maximum z-index and, as such, you can override simplemde fullscreen z-index as follow
.editor-toolbar.fullscreen, .CodeMirror-fullscreen { z-index: 101 !important; }


Id additions

Added identifiers to sections of the website so you can link others externally to specific sections in the site. This closes #164

Great, thanks!

Thanks !


Add CI for infinite redirects + fix existing issues

We've had a few infinite loops with redirects so let's detect these in CI pre-merge. The check is simple, if from == to then flag.
This detected a few live in production right now:
Found infinite redirect: /fundamentals/account-and-billing/account-security/securing-a-compromised-account/ -> /fundamentals/account-and-billing/account-security/securing-a-compromised-account/
Found infinite redirect: /fundamentals/account-and-billing/account-security/zone-holds/ -> /fundamentals/account-and-billing/account-security/zone-holds/
Found infinite redirect: /fundamentals/account-and-billing/account-security/review-audit-logs/ -> /fundamentals/account-and-billing/account-security/review-audit-logs/
Found infinite redirect: /fundamentals/account-and-billing/account-security/manage-active-sessions/ -> /fundamentals/account-and-billing/account-security/manage-active-sessions/
Found infinite redirect: /fundamentals/account-and-billing/account-security/cloudflare-access/ -> /fundamentals/account-and-billing/account-security/cloudflare-access/

Found 5 infinite redirects, please fix them before merging :)

(Example run: https://github.com/cloudflare/cloudflare-docs/actions/runs/6292877008/job/17082711880?pr=10845)
Fixed these as well (if I couldn't find the last location, I removed as they seemed to be a mistake)

Great add, @WalshyDev! We may want to expand our redirect validations in the future, and this is a great first step. Thanks!


Error on youtube downloading video

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[x] I've read about sharing account credentials and I'm willing to share it if required

Region
Russia, Saint Petersburg
Provide a description that is worded well enough to be understood
Trying load download video from youtube ends with error ERROR: [youtube] g9o12X6sG_4: Get the best YouTube experience. Sign in to save videos, subscribe, and more
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[x] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
appuser@2c3adf99f816:/app$ yt-dlp -vU https://www.youtube.com/watch?v=g9o12X6sG_4 --dump-json --verbose
[debug] Command-line config: ['-vU', 'https://www.youtube.com/watch?v=g9o12X6sG_4', '--dump-json', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [ff0779267] (pip)
[debug] Python 3.8.19 (CPython x86_64 64bit) - Linux-5.15.0-97-generic-x86_64-with-glibc2.34 (OpenSSL 3.0.11 19 Sep 2023, glibc 2.36)
[debug] exe versions: ffmpeg 5.1.4-0 (setts), ffprobe 5.1.4-0
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2024.02.02, mutagen-1.47.0, requests-2.31.0, sqlite3-3.40.1, urllib3-2.2.1, websockets-12.0
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets
[debug] Loaded 1810 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp)
[youtube] Extracting URL: https://www.youtube.com/watch?v=g9o12X6sG_4
[youtube] g9o12X6sG_4: Downloading webpage
[youtube] g9o12X6sG_4: Downloading ios player API JSON
[youtube] g9o12X6sG_4: Downloading android player API JSON
ERROR: [youtube] g9o12X6sG_4: Get the best YouTube experience. Sign in to save videos, subscribe, and more
  File "/usr/local/lib/python3.8/site-packages/yt_dlp/extractor/common.py", line 734, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/lib/python3.8/site-packages/yt_dlp/extractor/youtube.py", line 4182, in _real_extract
    self.raise_no_formats(reason, expected=True)
  File "/usr/local/lib/python3.8/site-packages/yt_dlp/extractor/common.py", line 1251, in raise_no_formats
    raise ExtractorError(msg, expected=expected, video_id=video_id)

[x] I've checked that all provided URLs are playable in a browser with the same IP and same login details

can you confirm this ^^? you can play this video in your web browser in a private/incognito tab?

sry, i cannot check it, coz app deployed in docker on vps
but curl returns valid webpage, without text "Get the best YouTube experience. Sign in to save videos, subscribe, and more"

So then you shouldn't have checked that box in the checklist, yeah?

yes, because this issue is not valid

app deployed in docker on vps

Can you specify hosting?


⚠ Processors has degraded performance

In dc5567c, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 118 ms

Resolved: Processors performance has improved in df6832d.


Connection Timeout

every time i used i get "Connection Timeout" on any version
is there any update or maybe i missing something?

Same here.

same, testing it against : RouterOS v6.49.15


feat(loader): create loader package

Closes #
📝 Description

Add a brief description

⛳ Current behavior (updates)

Please describe the current behavior that you are modifying

🚀 New behavior

Please describe the behavior or changes this PR adds

📝 Additional Information
✅ Pull Request Checklist:

[ ] :ok_hand: Design updates are approved by design team
[ ] :white_check_mark: Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] :wheelchair: Looked at the Accessibility Practices for this feature - Aria Practices

Ya quedó @ruloCode


Fix a use after free in c-ares on Windows

Fixes #18461
Fixes #20005
There's a straight forward bug here; we're currently accessing GrpcPolledFd objects in their associated socket's c-ares "close" overrides, even though, in general, GrpcPolledFd object lifetimes end earlier than their associated sockets.
See https://github.com/grpc/grpc/pull/20284 for repro of bugs in #18461 and #20005 using existing C# tests

basic tests linux C#: https://github.com/grpc/grpc/issues/18126
node linux, macos: https://github.com/grpc/grpc/issues/20254
RBE opt C/C++ failed with: Failed to run:pull image:Error response from daemon: Get https://l.gcr.io/v2/google/rbe-ubuntu16-04/manifests/sha256:2c925275fb30478602cd53651eeaaf015f964ad1b84d3947ed710802f054035b: dial tcp <IP_ADDRESS>:443: i/o timeout


Fixing dangling MetricContext creation in ForkOperator

The class InstrumentedForkOperatorBase would create a new MetricContext in its default constructor, but it would make it with no parent (the correct parent should get the Task level MetricContext). Then during the init() method it would create a new MetricContext (this time with the correct parent). The first MetricContext would be GC'ed quite quickly as it has no references, but it causes some duplicate reporting so it's best to remove it.
@ibuenros can you review

LGTM. Seems the build failed on Java 7 due to the following test failure. Maybe you can give a longer timeout to it in this PR:
Gradle test > gobblin.scheduler.JobConfigFileMonitorTest.testAddNewJobConfigFile FAILED
    java.util.concurrent.TimeoutException: Timeout waiting for condition '4 scheduled jobs'.
        at gobblin.testing.AssertWithBackoff.assertTrue(AssertWithBackoff.java:185)
        at gobblin.testing.AssertWithBackoff.assertTrue(AssertWithBackoff.java:134)
        at gobblin.testing.AssertWithBackoff.assertEquals(AssertWithBackoff.java:147)
        at gobblin.scheduler.JobConfigFileMonitorTest.testAddNewJobConfigFile(JobConfigFileMonitorTest.java:91)

Increased the timeout from 5000 ms to 7500 ms. The test also failed on Hudson, so this change should also prevent that from happening again.

LGTM.

LGTM

@sahilTakiar It looks like I just experienced something similar which caused my Java 8 default Travis build to fail. It happened during my latest commit to PR1074
From the raw log:

Sorry for the picture but I'm on my cell. Do you think this is related to this previous bug?

The test JobConfigFileMonitorTest has notoriously been very shaky on Travis. IIRC it fails semi often. Generally, just re-running the Travis build fixes it. It seems the Travis build for https://github.com/linkedin/gobblin/pull/1074 is working now, so it shouldn't be an issue.


Add ISO3166 2 lvl4

This is the last step for adding iso3166_2_lvl4.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-4 of 8 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 38.214%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sdx_controller/models/location.py
4
8
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.08%

Covered Lines:
609

Relevant Lines:
1432

💛  - Coveralls

@congwang09 "black -check" error? need to run black?

@congwang09 "black -check" error? need to run black?

True, somehow black stopped working on my vscode. It's fixed.


macros: Introduce some macros represeting program

Problem to Solve
At the moment, code for hosting services has to be written manually. Quite often it is the same repeating boilerplate which can be generated.
Possible Solution
Introduce a macro which usage would look like this
struct MyProgram {
    admin_id: ActorId,
}

#[gprogram]
impl MyProgram {
    // This associated method will be discovered by the macro and used for
    // instantiating a singleton for the program during invocation of the 'init' call.
    // exec_context should be optional
    // some other arbitrary params might be specified so client can pass them
    pub fn new(exec_context: impl ExecContext) {
        Self {
             admin_id: exec_context.actor_id(),
        }
    }

    // Method constructing a service hosted by the program. This method will
    // be used for instantinating a stateless service during each invocation of the 'handle' call.
    // The method can contain well-known services as parameters
    pub fn service(exec_context: impl ExecContext, sender: impl Sender) -> MyService {
         ...
    }
}

The MyProgram plays a role of IoC composition root.
The macro generates code for handling the init and handle methods
Notes
No response

Won't calling service() on every handle_message result in MyService not being a singleton anymore? If we initialize MyService from every single time then the state can't be mutated. I envision this should something like this:
#[gprogram]
impl MyProgram {
    /// called exactly once during program lifecycle
    pub fn init(exec_context: impl ExecContext, arg: u64) -> MyService {
        MyService {
             admin_id: exec_context.actor_id(),
             arg: u64
             // inject extra deps like ctx, sender
        }
    }
}

Maybe even just detect this method on #[gservice] and generate init and handle methods if it is present

My current vision is that:

A struct representing a program and annotated with the gprogram attribute will be a singleton. Its main responsibility is representing services hosed by the program. This will be done via a set of methods constructing the services. The program construction will be done once as a part of execution of the init method. The program struct can have or not have any data it works with. Another thing the program construction method can do is communicating the fact of initialization to any of the service it is aware of, for example doing something like this

#[gprogram]
impl MyProgram {
    pub fn new() -> MyProgram {
        let exec_context = GStdExecContext::default();
        SomeService::seed(exec_context);
    }
}

The service struct represents some behaviour. It is supposed to be stateless, i.e. it will be possible to construct it on every single call to the handle method. It is good to have it done this way as it highlights that our programs work with static data which requires appropriate handling of them. With that implementation such data can't be a part of the service. Taking account of the p.1, the service can look like

#[gservice]
impl SomeService {
    pub fn seed(exec_context: impl ExecContext) {
        unsafe { ADMIN_ID = Some(exec_context.actor_id() }
    }

    pub fn new(exec_context: impl ExecContext) -> Self {
        Self {
            exec_context
        }
    }
}

We can't have the service singleton as it will be allowed for it to have instance of execution context which changes between the 2 different calls to the service methods
I will adjust current example accordingly to this

Consider this issue to be closed with all the job done towrds this. Future job will done in the scope of more detailed issues: #111 , #112 , #113


Documentation Modification Suggestions

Hey there. I'm going through the process of moving a plugin to pample juce. I thought I would try to contribute by going through some problems as I face them in hopes to help with the documentation!
1. BinaryData
I was just wondering if you could explicitly write on this page that anything put in the /assets/ folder will be used to create a BinaryData.h / BinaryData.cpp like projucer used to generated for you. And also that the folder is not shown on the xcode project navigator but you should use finder to add the files. Lastly, a warning not to put files in here that are not needed for the plugin as it will be added as binary data to the plugin (maybe the pamplejuce.png should be moved to another folder)!
2. No CMAKE_CXX_COMPILER error
When I tried to run "cmake -B Builds -G Xcode" it failed and said
"No CMAKE_CXX_COMPILER could be found." "No CMAKE_C_COMPILER could be found."
Even though the OS recognizes they exist and where.
I found this command did the trick: sudo xcode-select --reset
3. Common <JuceHeader.h> replacements:
Plugin Processor
target_link_libraries addition: juce_audio_processors
#include <juce_audio_processors/juce_audio_processors.h>
Plugin Editor / GUI Components
target_link_libraries addition: juce_gui_basics, juce_gui_extra
#include <juce_gui_basics/juce_gui_basics.h>
#include <juce_gui_extra/juce_gui_extra.h>
juce::PropertiesFile
target_link_libraries addition: juce_data_structures
#include <juce_data_structures/juce_data_structures.h>
juce::dsp
target_link_libraries addition: juce_dsp
#include <juce_dsp/juce_dsp.h>
juce::AudioBuffer
target_link_libraries addition: juce_audio_basics
#include <juce_audio_basics/juce_audio_basics.h>
juce::OnlineUnlockStatus
target_link_libraries addition: juce_product_unlocking
#include <juce_product_unlocking/juce_product_unlocking.h>
juce::Thread
target_link_libraries addition: juce_events
#include <juce_events/juce_events.h>
juce::Logger
target_link_libraries addition: juce_core
#include <juce_core/juce_core.h>
BinaryData::
target_link_libraries addition: none
#include "BinaryData.h"
4. Make sure your Plugin Processor has this header at the top
#if (MSVC)

#include "ipps.h"

#endif

5. How to -o3 optimized build on debug builds
Still figuring out how to do this!
6. In test_helpers.h you need to replace "PluginProcessor" with the name of your processor class.
[[maybe_unused]] static void runWithinPluginEditor (const std::function<void (PluginProcessor& plugin)>& testCode)
{
    PluginProcessor plugin;
    const auto editor = plugin.createEditorIfNeeded();

    testCode (plugin);

    plugin.editorBeingDeleted (editor);
    delete editor;
}

7. In PluginBasics.cpp you also need to replace "PluginProcessor" with the name of your processor class.
TEST_CASE ("Plugin instance", "[instance]")
{
    PluginProcessor testPlugin;

    SECTION ("name")
    {
        CHECK_THAT (testPlugin.getName().toStdString(),
            Catch::Matchers::Equals ("My Plugin Name"));
    }
}

8. In Benchmarks.cpp you also need to replace "PluginProcessor" with the name of your processor class.
9. You can use this script to test the full build locally before spending CI minutes (and quickly figure out why the CI build failed)
test-ci-local.sh
#!/bin/bash

# How to test the CI/CD build phase locally on macOS:
# 1. Run `chmod +x test-ci-local.sh` to make the script executable
# 2. brew install ninja
# 3. Run `./test-ci-local.sh`

# Define variables
BUILD_DIR="Builds"
BUILD_TYPE="Release"

# Remove the entire Builds directory to start fresh
rm -rf "$BUILD_DIR"

# Create build directory
mkdir -p "$BUILD_DIR"

# Configure with CMake and Ninja generator, suppressing warnings
cmake -B "$BUILD_DIR" \
      -G Ninja \
      -DCMAKE_BUILD_TYPE="$BUILD_TYPE" \
      -DCMAKE_C_FLAGS="-w" \
      -DCMAKE_CXX_FLAGS="-w" \
      .

# Build the project, showing only progress and errors
cmake --build "$BUILD_DIR" --config "$BUILD_TYPE" --parallel 4 --

# Check if the build succeeded
if [ $? -eq 0 ]; then
    # Run tests and benchmarks only if the build was successful
    "$BUILD_DIR"/Tests
    "$BUILD_DIR"/Benchmarks
else
    echo "Build failed. Tests and Benchmarks will not run."
    exit 1
fi

10. Generating .icns from figma
Insteading of manually exporting and making the file yourself, you can use this tool: https://www.figma.com/community/plugin/742318143106037364/icns-ico-generator
11. AU3 path exists but no mention of packaging
echo "AUV3_PATH=$ARTIFACTS_PATH/AUv3/${{ env.PRODUCT_NAME }}.appex" >> $GITHUB_ENV
This is in the workflow, but it doesn't seem to be used anywhere. It's a bit confusing because the default cmake has this:
set(FORMATS Standalone AU VST3 AUv3)
So I guess we make it, build it, but never package it?
12. Missing step in code sign azure
In "Step 4: Create “App Registration” user credentials", after giving it a name, there are some options.

Mention which to choose here.
13. Label AZURE_ENDPOINT and AZURE_CODE_SIGNING_NAME like other secrets in documentation

14 Mention to choose "User, group, or service principal", not Managed identity?

15 Some screenshots for the personal identity part
The dropdown:

Action required:

**The Action Page **

The partner

When it's done

Now scan it, the QR code is below this message:

**Note: The scan QR code is the icon in the top right corner **
Note2: Your identity will expire when your government issued card does (ex drivers license expires). Might be a good idea to message the code signing team if this invalidates the identity and you gatta do this all again
Last step: AZURE_CERT_PROFILE_NAME

This is all great stuff, thank you! I will take a deeper look when I'm combing through documentation again.


Add documentation for AWS Lambda function integration

Task

Add documentation including how Lambda function was tested and designed

Deliverables

Markdown file with documentation
Markdown file for ADR on why needed

Size Estimation: Small (< 2 hours)

Duplicate.


Update Getting Started Guide to use Socket Mode

In line with changes introduced to Bolt for JS in #990, this PR updates the Getting Started guide to use Socket Mode as default, and links a separate Getting Started over HTTP guide with instructions for Request URL / HTTP setup.
Category (place an x in each of the [ ])

[ ] slack_bolt.App and/or its core components
[ ] slack_bolt.async_app.AsyncApp and/or its core components
[ ] Adapters in slack_bolt.adapter
[x] Document pages under /docs
[ ] Others

Requirements (place an x in each [ ])
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run ./scripts/install_all_and_run_tests.sh after making the changes.

When merging this pull request, you can use "Squash and merge" to easily squash the commits!


DRACO-encoded GLB Does Not Render textures

Describe the bug
When loaded in f3d v2.5.0 with DRACO support, a DRACO-encoded GLB does not render.
To Reproduce
Steps to reproduce the behavior:

Open the file:
odm_textured_model_geo.zip
Observe it does not render
Test the same file here: https://gltf-viewer.donmccurdy.com/
Verify report:

Validation report

    Format: glTF 2.0
    Generator: draco_decoder
    Stats:
        9 draw calls
        0 animations
        9 materials
        142397 vertices
        223185 triangles
    Extensions:
        CESIUM_RTC
        KHR_draco_mesh_compression
        KHR_materials_unlit

    NOTE: Extensions above are present in the model, but may or may not be recognized by this viewer. Any "UNSUPPORTED_EXTENSION" warnings below refer only to extensions that could not be scanned by the validation suite, and may still have rendered correctly. See: [three-gltf-viewer#122](https://github.com/donmccurdy/three-gltf-viewer/issues/122).

Report generated by[KhronosGroup/glTF-Validator](https://github.com/KhronosGroup/glTF-Validator/) 2.0.0-dev.3.9.
Info	Message	Pointer
UNSUPPORTED_EXTENSION	Cannot validate an extension as it is not supported by the validator: 'CESIUM_RTC'.	/extensionsUsed/0
UNSUPPORTED_EXTENSION	Cannot validate an extension as it is not supported by the validator: 'KHR_draco_mesh_compression'.	/extensionsUsed/1
UNUSED_OBJECT	This object may be unused.	/bufferViews/0
UNUSED_OBJECT	This object may be unused.	/bufferViews/1
UNUSED_OBJECT	This object may be unused.	/bufferViews/2
UNUSED_OBJECT	This object may be unused.	/bufferViews/3
UNUSED_OBJECT	This object may be unused.	/bufferViews/4
UNUSED_OBJECT	This object may be unused.	/bufferViews/5
UNUSED_OBJECT	This object may be unused.	/bufferViews/6
UNUSED_OBJECT	This object may be unused.	/bufferViews/7
UNUSED_OBJECT	This object may be unused.	/bufferViews/8

Expected behavior
The DRACO-encoded GLB renders properly.
System Information:

OS: Alpine Linux Edge x86_64
GPU and GPU driver: Intel N3450, Intel i915/MESA

F3D Information
Paste the content of f3d --version:
f3d --version
F3D 2.5.0

F3D - A fast and minimalist 3D viewer
Version: 2.5.0.
Build date: 2024-11-13 06:52:25.
Build system: Linux 64-bits.
Compiler: GNU 14.2.0.
External rendering module: OFF.
Raytracing module: OFF.
VTK version: 9.3.1.
Copyright (C) 2019-2021 Kitware SAS.
Copyright (C) 2021-2024 Michael Migliore, Mathieu Westphal.
License BSD-3-Clause.
By Michael Migliore, Mathieu Westphal and Joachim Pouderoux.

Additional context
The same file renders in Blender, MeshLab, CloudCompare, and WebODM's PoTree viewer.

I confirm that this file does not render as expected in F3D:

While it works fine in https://gltf-viewer.donmccurdy.com/

I confirm that this file does not render as expected in F3D:

While it works fine in https://gltf-viewer.donmccurdy.com/

I don't even get an empty-texture model!

I also do not note any errors printed to the console aside from:

Configuration file for "config" could not be found

I also do not note any errors printed to the console aside from:

Use --verbose

I can confirm this is the same from my side, for gltf meshes with draco + KTX2 compression (KHR_texture_basisu extension with etc1s compression), which are not rendering in f3d while they render in donmccurdy gltf-viewer or viewer.needle.tools
There are no obvious errors in the verbose output of f3d with the OP provided draco-compressed file, but there is error glTF extension KHR_texture_basisu is required in this model, but not supported by this loader. Aborting for my draco+ktx2 compressed meshes.
Should I open a dedicated issue for KTX2 texture compression support?
Found a reader for "\\gaia\CREA\_Archives\2021-11_Meta_GHA\99_Sources\Saved_From_Google_Drive\A. Sites\072-haghpat-monastery\30 - Packed Mesh\072-interior-5.0.1-mini-mini-model.rio\072-interior-5.0.1-mini.1.etc1s+draco.glb" : "GLTFDraco"
Loading 3D scene: \\gaia\CREA\_Archives\2021-11_Meta_GHA\99_Sources\Saved_From_Google_Drive\A. Sites\072-haghpat-monastery\30 - Packed Mesh\072-interior-5.0.1-mini-mini-model.rio\072-interior-5.0.1-mini.1.etc1s+draco.glb

ERROR: In vtkGLTFDocumentLoaderInternals.cxx, line 1339
vtkF3DGLTFDocumentLoader (00000105DDD1FC50): glTF extension KHR_texture_basisu is required in this model, but not supported by this loader. Aborting

ERROR: In vtkGLTFImporter.cxx, line 395
vtkF3DGLTFImporter (00000105D1B386D0): Error loading model metadata

ERROR: In vtkGLTFImporter.cxx, line 837
vtkF3DGLTFImporter (00000105D1B386D0): The GLTF model is nullptr, aborting.

Should I open a dedicated issue for KTX2 texture compression support (the same way it was done for KHR_texture_transform here #1696)

Lets create a dedicated issue, Ill then add it to https://github.com/f3d-app/f3d/issues/608.

Thanks, just did it here: https://github.com/f3d-app/f3d/issues/1707

Yes, just now sorry:
f3d ~/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/as
sets/odm_texturing/odm_textured_model_geo.glb --verbose
========== Initializing ==========
Loading plugin "alembic"
  Version: 1.0
  Description: Alembic support (version 1.8.7)
  Readers:
    Alembic
Loading plugin "assimp"
  Version: 1.0
  Description: Assimp support (version 5.4.3)
  Readers:
    Filmbox
    Collada
    AutoCAD DXF
    Object File Format
    DirectX File Format
    3D Manufacturing Format
Loading plugin "draco"
  Version: 1.0
  Description: Draco support (version 1.5.7)
  Readers:
    Draco
Loading plugin "exodus"
  Version: 1.0
  Description: VTK Exodus support
  Readers:
    Exodus II
Loading plugin "native"
  Version: 1.0
  Description: Native VTK I/O support
  Readers:
    Autodesk 3D Studio
    CityGML
    DICOM
    GL Transmission Format
    MetaImage
    Nearly Raw Raster Data
    Wavefront OBJ
    Polygon
    Point Cloud
    Standard Triangle Language
    TIFF
    VRML
    VTK Legacy
    VTK XML UnstructuredGrid
    VTK XML PolyData
    VTK XML ImageData
    VTK XML RectangularGrid
    VTK XML StructuredGrid
    VTK XML MultiBlock
    3D Gaussian splats
Loading plugin "occt"
  Version: 1.0
  Description: OpenCASCADE support (version 7.8.1)
  Readers:
    STEP ISO 10303
    Initial Graphics Exchange Specification
    Open CASCADE BRep
Configuration file for "config" could not be found
========== Configuring engine ==========
Engine configured
========== Loading 3D file ==========
Found a reader for "/home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb" : "GLTF"
Loading 3D scene: /home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb

ERROR: In vtkGLTFDocumentLoaderInternals.cxx, line 1305
vtkGLTFDocumentLoader (0x7fcecf853290): glTF extension KHR_draco_mesh_compression is required in this model, but not supported by this loader. Aborting

ERROR: In vtkGLTFImporter.cxx, line 387
vtkGLTFImporter (0x7fcecf859b10): Error loading model metadata

ERROR: In vtkGLTFImporter.cxx, line 796
vtkGLTFImporter (0x7fcecf859b10): The GLTF model is nullptr, aborting.

No animation available in this file
ERROR: In vtkGLTFImporter.cxx, line 581
vtkGLTFImporter (0x7fcecf859b10): The GLTF model is nullptr, aborting.

No camera available in this file

Scene bounding box: 1,-1,1,-1,1,-1

Camera position: 0,0,1
Camera focal point: 0,0,0
Camera view up: 0,1,0
Camera view angle: 30

========== Rendering ==========
Render done

F3D is not built with draco support afaict, what is the output of  f3d --scan-plugins ?

This is my package for Alpine, which I built with DRACO:
f3d ~/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/as
sets/odm_texturing/odm_textured_model_geo.glb --verbose
========== Initializing ==========
Loading plugin "alembic"
  Version: 1.0
  Description: Alembic support (version 1.8.7)
  Readers:
    Alembic
Loading plugin "assimp"
  Version: 1.0
  Description: Assimp support (version 5.4.3)
  Readers:
    Filmbox
    Collada
    AutoCAD DXF
    Object File Format
    DirectX File Format
    3D Manufacturing Format
Loading plugin "draco"
  Version: 1.0
  Description: Draco support (version 1.5.7)
  Readers:
    Draco
Loading plugin "exodus"
  Version: 1.0
  Description: VTK Exodus support
  Readers:
    Exodus II
Loading plugin "native"
  Version: 1.0
  Description: Native VTK I/O support
  Readers:
    Autodesk 3D Studio
    CityGML
    DICOM
    GL Transmission Format
    MetaImage
    Nearly Raw Raster Data
    Wavefront OBJ
    Polygon
    Point Cloud
    Standard Triangle Language
    TIFF
    VRML
    VTK Legacy
    VTK XML UnstructuredGrid
    VTK XML PolyData
    VTK XML ImageData
    VTK XML RectangularGrid
    VTK XML StructuredGrid
    VTK XML MultiBlock
    3D Gaussian splats
Loading plugin "occt"
  Version: 1.0
  Description: OpenCASCADE support (version 7.8.1)
  Readers:
    STEP ISO 10303
    Initial Graphics Exchange Specification
    Open CASCADE BRep
Configuration file for "config" could not be found
========== Configuring engine ==========
Engine configured
========== Loading 3D file ==========
Found a reader for "/home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb" : "GLTF"
Loading 3D scene: /home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb

ERROR: In vtkGLTFDocumentLoaderInternals.cxx, line 1305
vtkGLTFDocumentLoader (0x7fcecf853290): glTF extension KHR_draco_mesh_compression is required in this model, but not supported by this loader. Aborting

ERROR: In vtkGLTFImporter.cxx, line 387
vtkGLTFImporter (0x7fcecf859b10): Error loading model metadata

ERROR: In vtkGLTFImporter.cxx, line 796
vtkGLTFImporter (0x7fcecf859b10): The GLTF model is nullptr, aborting.

No animation available in this file
ERROR: In vtkGLTFImporter.cxx, line 581
vtkGLTFImporter (0x7fcecf859b10): The GLTF model is nullptr, aborting.

No camera available in this file

Scene bounding box: 1,-1,1,-1,1,-1

Camera position: 0,0,1
Camera focal point: 0,0,0
Camera view up: 0,1,0
Camera view angle: 30

========== Rendering ==========
Render done

Humm, what about this:
f3d --load-plugins=draco odm_textured_model_geo.glb ?

Just tried the above command, which says for me that the draco plugin is already loaded (I installed f3d 2.5.0 via winget install f3d).
What's weird is that the following sample assets with draco compression and png textures do load: Duck, Avocado, BoomBox, and Lantern. Could this be caused by the CESIUM_RTC glTF extension in the case of the OP mesh file?
Warning: In vtkGLTFDocumentLoaderInternals.cxx, line 1362
vtkF3DGLTFDocumentLoader<PHONE_NUMBER>0B5660): glTF extension CESIUM_RTC is used in this model, but not supported by this loader. The extension will be ignored.

Humm, what about this:
f3d --load-plugins=draco odm_textured_model_geo.glb ?

f3d --load-plugins=draco ~/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8
-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb --verbose
========== Initializing ==========
Loading plugin "alembic"
  Version: 1.0
  Description: Alembic support (version 1.8.7)
  Readers:
    Alembic
Loading plugin "assimp"
  Version: 1.0
  Description: Assimp support (version 5.4.3)
  Readers:
    Filmbox
    Collada
    AutoCAD DXF
    Object File Format
    DirectX File Format
    3D Manufacturing Format
Loading plugin "draco"
  Version: 1.0
  Description: Draco support (version 1.5.7)
  Readers:
    Draco
Loading plugin "exodus"
  Version: 1.0
  Description: VTK Exodus support
  Readers:
    Exodus II
Loading plugin "native"
  Version: 1.0
  Description: Native VTK I/O support
  Readers:
    Autodesk 3D Studio
    CityGML
    DICOM
    GL Transmission Format
    MetaImage
    Nearly Raw Raster Data
    Wavefront OBJ
    Polygon
    Point Cloud
    Standard Triangle Language
    TIFF
    VRML
    VTK Legacy
    VTK XML UnstructuredGrid
    VTK XML PolyData
    VTK XML ImageData
    VTK XML RectangularGrid
    VTK XML StructuredGrid
    VTK XML MultiBlock
    3D Gaussian splats
Loading plugin "occt"
  Version: 1.0
  Description: OpenCASCADE support (version 7.8.1)
  Readers:
    STEP ISO 10303
    Initial Graphics Exchange Specification
    Open CASCADE BRep
Plugin "draco" already loaded
Configuration file for "config" could not be found
========== Configuring engine ==========
Engine configured
========== Loading 3D file ==========
Plugin "draco" already loaded
Found a reader for "/home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb" : "GLTF"
Loading 3D scene: /home/USERNAME/Public/WebODM_MEDIADIR/project/1/task/0a5fd217-591d-40f8-b6c9-d9f64cd3e9f3/assets/odm_texturing/odm_textured_model_geo.glb

ERROR: In vtkGLTFDocumentLoaderInternals.cxx, line 1305
vtkGLTFDocumentLoader (0x7f20e4e9a290): glTF extension KHR_draco_mesh_compression is required in this model, but not supported by this loader. Aborting

ERROR: In vtkGLTFImporter.cxx, line 387
vtkGLTFImporter (0x7f20e4eb0b10): Error loading model metadata

ERROR: In vtkGLTFImporter.cxx, line 796
vtkGLTFImporter (0x7f20e4eb0b10): The GLTF model is nullptr, aborting.

No animation available in this file
ERROR: In vtkGLTFImporter.cxx, line 581
vtkGLTFImporter (0x7f20e4eb0b10): The GLTF model is nullptr, aborting.

No camera available in this file

Scene bounding box: 1,-1,1,-1,1,-1

Camera position: 0,0,1
Camera focal point: 0,0,0
Camera view up: 0,1,0
Camera view angle: 30

========== Rendering ==========
Render done

No change in behavior, unfortunately.

Found the issue:
# Needs https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10884
if(VTK_VERSION VERSION_GREATER_EQUAL 9.3.20240214)
  f3d_plugin_declare_reader(
    NAME GLTFDraco
    SCORE 90
    EXTENSIONS gltf glb
    MIMETYPES model/gltf-binary model/gltf+json
    VTK_READER vtkF3DGLTFReader
    VTK_IMPORTER vtkF3DGLTFImporter
    FORMAT_DESCRIPTION "GL Transmission Format"
    CUSTOM_CODE "${CMAKE_CURRENT_SOURCE_DIR}/gltf.inl"
  )
endif()

In order to get access to glTF + draco you need a more recent VTK (9.3.20240214) .
I wish there was a way to inform user of the issue though.
This issue should stay open anyway because the texture is not loading in the file you shared.

Ah, excellent find! It looks like vtk is in the RC phase for 9.4, so I will wait and re-build against that.
In the meanwhile, I am opening an MR against our DRACO to ensure it is built with mesh/pointcloud compression support enabled as well, to see if that improves things.
Does the CESIUM_RTC line look salient from jo-chemla?

Does the CESIUM_RTC line look salient from jo-chemla?

Indeed! Ill update the issue accordingly
Thanks for all your debugs @jo-chemla @Saijin-Naib !

I've update the issue and added it in the list: https://github.com/f3d-app/f3d/issues/608


Bug: XAML Controls Gallery: Accessibility: [MAS4.3.1]: In HC mode, Selected option is not visible when selected , in Expander and Pipspager cards

Tags
Accessibility, A11yCT, A11yMAS, A11yMediumImpact, MAS4.3.1, HighContrast, Sev3, XAML Controls Gallery (Debug), Win32, Wipro
Steps to reproduce the bug
1.Launch the XAML Controls Gallery (Debug) App
2.Go to the What's New-->Expander/PipsPager cards and activate.
3.Now navigate to Expand Direction/Orientation/Previous button visibility/next button visibility combo box with tab
4.Observe selected options are not visible when focused.
Actual behavior
Selected option is not visible when selected , in Expander and Pipspager cards
Expected behavior
Everything should visible properly in HC mode.
User Impact
People with Low vision are not able to identify the selected option when the combo box is focused.
Version Info
Microsoft OS: 21313.1000
App: XAML Controls Gallery (Debug) (Version <IP_ADDRESS>)

This would be a problem with the ComboBox control, but I am not able to repro on a newer build. I believe ComboBox HC focus state has already been fixed, so closing this issue. @v-amnat, I will provide you with a new build of Xaml Controls Gallery within the next couple of weeks to validate.


multivariate output

I have a time series data of 4 sensors, an anomaly happens if one or two sensors have a peak value. If all of them have a peak at the same timestamp it is not an anomaly. As far as I know your models detect an anomaly in only one column. Is that correct ?

If it is the case, does it make sense to run the model 4 times on each of my sensors data columns? because in my case an anomaly depends on all the 4 sensors values at the same timestamp.
Thanks in advance!

Hi @khadijakhaldi – thank you for using Orion!

yes, all currently available pipelines detect anomalies in only one column.
It definitely does. I recommend that you use all 4 sensors as input the pipeline. However, you alter the target column in each time you run the pipeline.

Hope this helps, let me know if you have any further questions!


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:39: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:39: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:39: missing_description: The recipe is missing a description
ERROR: /tmp/abs_12y7vk7j8i/clone/recipe/meta.yaml:39: missing_documentation: The recipe is missing a doc_url or doc_source_url
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:39: missing_description: The recipe is missing a description
ERROR: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:39: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:39: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_b5t6cpcbk_/clone/recipe/meta.yaml:39: missing_dev_url: The recipe is missing a dev_url
Errors were found


Can't login

when i click button "login with in google" return 400: redirect_uri_mismatch

Thank you for informing. Now you can login with google.


Build, test & bundle Lake

TODO:

[ ] adjust docs
[ ] ...

Support in the Nix setup is TBD after Nix gets proper submodule treatment :grimacing:

@tydeu Any idea on the Windows test failure?

@Kha it is kind of hard to debug this without access to the build results (especially as it neither occurs on my machine or my CI). 😆

@Kha My first guess at the error would be that it almost looks like leanc is missing.

I went ahead and downloaded the build results and ran make test with LAKE set to the built Lake and it ran successfully (on my Windows machine).

Oh, haha, it must work for you because your leanc is a binary - from elan. I was planning to rewrite leanc in Lean anyway, which will fix this.

@Kha On a different note, why are running make clean and then make test?  All the Lake tests clean the their outputs before running their test.

Ah. Hm. I guess I didn't expect that.

@Kha Well, it is a build system test -- the test not very useful if the build output is already there (unless that is the special case being tested). 😆

@Kha I just went ahead and release proper version 2.1.0 of Lake, so that you can pin the submodule at that tag/version rather than to a prerelease.

I feel like a github submodule for lake is going to be a bit of a pain, is it really necessary to maintain Lake in a separate repo?  WIth lean 4 evolving so fast I worry the Lake PR's will get a bit tricky... Breaking change in lean4, but lean4 is building lake via submodule, so submodule needs to be updated, but you can't build that yet until the new lean4 is out, which you can't build yet because...

@lovettchris doesn't as submodule make that easier? I.e., if necessary Lean can update the submodule code to make the Lean build happy, and then can PR to the main Lake repo so it can be merged when the new Lean is released.

@Kha one question I do have is: how are Lake submodule update going to be done. Will it be an intermittent chore like update stage0 or will it happen according to some scheduled CI job (e.g., along with each nightly release)?

I didn't have any automation in mind. I assumed you would open a PR whenever you want new changes to be distributed and we would merge it no questions asked.

This is also assuming that after an initial active phase, Lake development might quiet down a bit, much like with elan. Until the next big feature like cloud building at least :) .

@Kha okay, sounds good!

@Kha fyi, this PR is currently replaces today's functional JSON server code with yesterday's buggy code. That should probably be fixed.

Yeah, somehow I made a mess when moving LeanPaths to master while switching machines... to be honest, if I'd known that you had already implemented print-paths without LeanPaths, I wouldn't have bothered with that :) . I hope it's good now.

@Kha yep, server is working on a basic package now! 😄 Sorry for all the trouble my suggestion caused. 😢

Hmm, looks like that broke something. But only in one Linux CI job?

That job is using an older clang

Thanks. @leodemoura This should be ready for merge.

@Kha Lake should probably be updated once more (so that its JSON fix is also included).


[BUG]: SubjectAltName needs to be updated in the tls.crt

Bug Description
https://dell.github.io/csm-docs/docs/deployment/csmoperator/drivers/powermax/#csi-powermax-reverse-proxy
Here we need to provide a sample for the SubjectAltName that will be used with tls.crt
Better approach would be automatically generating this as self signed certificate by operator
Logs
https://dell.github.io/csm-docs/docs/deployment/csmoperator/drivers/powermax/#csi-powermax-reverse-proxy
tls.crt needs to be updated with SAN
subjectAltName = @alt_names
Screenshots
No response
Additional Environment Information
No response
Steps to Reproduce
In the tls.crt we need to product subjectAltName which is alternate names, we have to give samples how to create this
subjectAltName = @alt_names
Expected Behavior
Create a sample which defines what name needs to be created as an alternative names
CSM Driver(s)
PowerMax and wherever applicable
Installation Type
No response
Container Storage Modules Enabled
No response
Container Orchestrator
NA
Operating System
NA

@shanmydell a couple questions:

What is SubjectAltName? I don't see anything about it in documentation and haven't run into it the several times I've installed csi-powermax.
"Better approach would be automatically generating this as self signed certificate by operator" - this is a good idea but more a feature request than a defect

/sync

@jooseppi-luna : It is the alternative name that is going to be used, this ticket is to update that information in the documentation for tls.crt

/sync

link: 31041


Create new page

Ability to create pages in the content repo
Initial page class implementation
Integration with latest project structure

@andrew-thox other than a few comments lgtm and maybe squash and rollup your commit messages.

Updated to reflect these changes


feat: changed the migrations to reflect the new database schema

Resolves #919
Follows up PR https://github.com/ubiquity/ubiquibot-kernel/pull/33

I don't know enough about migrations to understand this pull well enough.

It is a literal db dump as I didn't know myself what functions were written in the database. It is useful to get the exact same state as the current DB is now for local or self hosted dev purposes. Since we gonna have one DB per module it shall be irrelevant soon.

Since we gonna have one DB per module it shall be irrelevant soon.

Perhaps one KV instead

@whilefoo I think it would be important to get this in because many newcomers do not have the schema migrations to work locally, and do not have access to the current production database. While I do understand your concern about cleanliness of the file, it is auto generated and I don't have much control over it, and there is no option to prettify the output, only options being documented here.

Sorry, I didn't know you were waiting for me


Moving OCI integration from experimental to full feature

Most of the work outlined in hip-0006 has been finished.
The upstream ORAS Go project that Helm imports now has a stable 1.0.0 release, with a backward compatibility guarantee. This was the last major step in unblocking releasing Helm OCI integration as a full feature.
Remaining steps

[x] Documentation only: https://github.com/helm/helm/issues/10169#issuecomment-976973309

#1249

[x] #10534

#10535

[x] #10166

https://github.com/helm/helm/pull/10521

[x] #10156

https://github.com/oras-project/oras-go/pull/92
#10536

[ ] #9694

https://github.com/oras-project/oras-go/pull/89
https://github.com/helm/helm/pull/10527

[ ] #9188

[ ] PR in progress (⏳ hold): #10447 Note this should be merged last, as it will need a rebase once other work above is complete
[ ] Note this PR should also properly remove the OCI experimental feature flag env var and gates throughout the codebase as well

Not identified as blockers
However, if someone has time to test these oci-related PRs, they may still get into 3.8.0.

[ ] #6324

PR ready for review 👀: #10408

[ ] #10175

PR ready for review 👀  #10430

Follow-up
This issue is only concerned with comprehensively listing any blockers for moving OCI support to a full feature. New features can be added after it is moved from experimental. After that point, only backward-compatible changes will be accepted until Helm 4.

Join the discussion about backward-compatible features here: https://github.com/helm/helm/issues/10312

Update (by mattfarina) 12/3: Connecting with technosophos and jdolitsky we reviewed the open issues from bacongobbler and added two additional tasks to the remaining steps.

Anything else?

Here's my laundry list... I started by searching the issue queue. Here's the search terms I used to look for open tickets:
https://github.com/helm/helm/issues?q=is%3Aissue+is%3Aopen+oci
https://github.com/helm/helm/issues?page=1&q=is%3Aissue+is%3Aopen+docker
https://github.com/helm/helm/issues?q=is%3Aissue+is%3Aopen+registry
This was just a casual search... It might be worth triaging the entire queue just to make sure no stone is left unturned.
Anyways, I saw a few tickets that might be worth evaluating (some have been discussed at length during previous developer calls):

https://github.com/helm/helm/issues/10013
https://github.com/helm/helm/issues/9694
https://github.com/helm/helm/issues/6324
https://github.com/helm/helm/issues/6214
https://github.com/helm/helm/issues/10156
https://github.com/helm/helm/issues/10123
https://github.com/helm/helm/issues/10166

#9694 in particular seems like a critical code path that should be addressed. No version range support for both helm install and dependencies is a big regression compared to chart repositories because users must now know what version they need to install. helm install wordpress --generate-name is currently not possible with OCI. Users MUST declare what version to install. To me that's a huge regression.
I know we've discussed helm search at great length during a few developer calls, but we need an answer whether the maintainers are going to work on a solution, or state that helm search does not support OCI registiries (and mark that as a ❌when comparing to chart repositories). Choosing to implement it could affect how information is stored in the registry, which would constitute a breaking change.
#10166 might also be worth taking a closer look as it pertains to how chart versions are stored in the registry.
I'd also recommend a bake-off between what you can do with chart repositories vs OCI registries before we can mark it as graduated. If only to inform users of the benefits and tradeoffs they make when choosing one or the other.
https://github.com/helm/helm/blob/main/CONTRIBUTING.md#semantic-versioning states that "Chart repository functionality MUST be backward compatible". But it doesn't state anything about OCI registry functionality.
Finally... The Helm documentation on chart registries would also be worth taking a closer look to make sure everything is up to date. Things like "why someone would choose OCI registries over chart repositories" would be worth documenting.

Doc suggestion: "migrating charts from a chart repository to OCI". Either as a plugin similar to https://github.com/helm/helm-2to3 or just a guide on what commands to run.

I'd also recommend looking at the oras issue queue to search for any open tickets that may be worth investing time fixing upstream. This one seems related to #9694: https://github.com/oras-project/oras-go/issues/19

Implement helm push/pull support insecure OCI registry in https://github.com/helm/helm/pull/10408, fix  How can I push chart to an insecure OCI registry with helm v3 #6324

Updates:
Folks are working hard on these issues leading up to and potentially during the holidays. In order for this to be moved from experimental to full feature in the next minor release (3.8.0) all blockers would have to be complete by the scheduled RC date (Jan 10, 2022). If not, we can re-target to the next minor release (3.9.0). Let's see what we can accomplish!
I have removed "Forthcoming issue: @jdolitsky re DOCKER_CONFIG" from our checklist in the issue description, and added a comment here with the current plan: https://github.com/helm/helm/issues/10156#issuecomment-999821534 @jdolitsky you can cross this off your list to explain in an issue ✨
@pytimer I have added #6324 and your PR #10408 to a new category above called "Not yet identified as a blocker", since I'm not yet clear whether this should be a blocker for moving OCI from experimental to full feature, or a nice to have by then and alternatively could be a follow-up. Will see if we can get this reviewed.

@scottrigby Thanks, i know. :-)  If something should i do, please tell me.

I assume target of 3.8.0 was not reached with this.. So :crossed_fingers: for 3.9.0 :)

@KlavsKlavsen today's RC was pushed back two days to accommodate completing this. This still gives a full week between RC and 3.8.0 to fix regressions. It is still possible we won't make the deadline, but a number of us are putting in a lot of work to make this happen, and it's looking very good right now.

Update: we are nearly there!

https://github.com/helm/helm/pull/10527 PR is solid. New test added. All checks pass. Just awaiting one other Helm maintainer to review/approve then I will merge
Oras maintainers can then cut oras-go v1.1.0, since we now confirmed tag API, auth, and docker config fallback all work now in v1.1.0-rc3
Last step will be to finish moving the package out of experimental, remove the experimental env var, and feature flag gates. Thanks to @runyontr for starting this – @dperaza4dustbit is planning to bring in his commits into a separate PR and finish that tomorrow. If for some reason David is pulled away, I can do that.

How everyone else here can help
Assuming we will get this into the Helm RC, we will want everyone interested in this feature to test it. There will be a week to fix regressions found before 3.8.0. Will confirm in this issue if/when that is indeed the case.
We are looking good! 🤞 will keep issue updated

Awesome! Just say the word, I'll be happy to throw some hours into testing out a project we have that currently uses the experimental flag to push some Helm Charts to both Github Packages and Azure Container Registry

link to Helm RC - and we'll update our docker images and CI pipelines to use this for OCI and see how it works

This is complete! Closing this meta tracking issue, and will add a comment once RC is out. Thank you all for your efforts, and thanks in advance for testing the oci feature in the RC ✨

📣  v3.8.0-rc.1 is out! Please test and promote widely for the most oci-related user regression testing possible before the 3.8.0 milestone on 1/19 .


make easier for user to understand how tensor_intrin works

This PR is same as https://github.com/apache/tvm/pull/14017

Closing as the upstream changes get merged, we will rebase it in