Add optional parameter allow_nullptr to QPDFObjectHandle::getOwningQPDF

Also, inline method and add optional parameter error_msg.

Inspired by a fuzz test failure.
FYI, reformat-code reordered QOC includes (excluded from commit.)

I think getOwningQPDF should ultimately be converted to return a shared_ptr which it would obtain by locking a weak_ptr to the owning QPDF. This would protect against dangling pointers for libqpdf users. pikepdf currently avoids this by inspecting every QPDFObjectHandle for pointers and manipulating the Python reference count on the corresponding pikepdf.Pdf (i.e. QPDF). weak_ptr would be a cleaner solution.
If so this is a helpful refactoring step in that direction.
I was going to propose this earlier but given the extensive refactoring m-holger is doing I decided to stay out to avoid conflicting changes.

@jbarlow83
I am not sure it is possible to provide a shared_ptr given that the QPDF object itself is not dynamically allocated.
Would it help if  getOwningQPDF returned a nullptr if the QPDF object has gone out of scope / been destroyed?

Good point. (There might be a case for holding QPDF shared_ptr anyway - that's probably it would be done for a greenfield project. But it would be disruptive.)
It would suffice to return nullptr if the owner has gone out of scope although not I'm sure how that would work. Global list of QPDFs?

@jbarlow83
I think there are easier solutions than a global list.

I was going to propose this earlier but given the extensive refactoring m-holger is doing I decided to stay out to avoid conflicting changes.

On the other hand, this might make it a good time to share your thoughts.

Thinking about this some more, removing most raw pointers from the public API is eventually worth doing. Raw pointers have ambiguous ownership semantics and would be clarified by their removal. (For example in BufferInputSource's constructor, there's an a Buffer* and bool to signal ownership; changing this to a shared_ptr would make the ownership automatically correct.)
For getOwningQPDF specifically, I think in most cases it's not actually necessary to return the QPDF. A lot of the tests are e.g. "is this a direct object?", or "do these two objects have the same owner?". Most of the time we don't need to expose the actual owner. Maybe a proxy class could be used here instead (getOwningQPDFProxy?). I'd suggest deprecation first.
(My original concern was not the existence of getOwningQPDF, but that QPDFObjectHandles might attempt to access their owner even if the owner is invalid.)
The object cache and QPDFObject are probably the areas of QPDF I understand least. For the QPDFObject/Value change, it looks to me like it's heading in a positive direction, but you've both invested a lot more time in studying this. I'm a little unsure about the extra level of indirection (QPDFObjectHandle->Object->Value).

I was actually thinking just this morning that we should remove all raw pointers from the public API. Maybe it's time to start planning this for qpdf 12 along with fixing the behavior of QPDFObjectHandle. I'll be able to focus on this in a week or two and will try to distill my thoughts.

My original concern was not the existence of getOwningQPDF, but that QPDFObjectHandles might attempt to access their owner even if the owner is invalid.

This is one of the motivations behind the Object/Value split.
The fundamental problem is that a QPDF object cannot keep track of the object handles it owns, and therefore it cannot notify handles of changes. However, some of the information about objects is held at the object handle level, including the owning QPDF object.
As a result, there is no way for the QPDF object to notify object handles that it is being destroyed, or for object handles to know whether their reference to the QPDF object is still valid.

I'm a little unsure about the extra level of indirection (QPDFObjectHandle->Object->Value).

The problem is not confined to the qpdf member of the object handle but also affects the obj member. The only way for the object handle to know whether the obj member still point to the correct object is to check with the QPDF object (keeping it's fingers crossed that it still exists). The extra level of indirection is the price to be paid for being able to do away with (the cost of) those checks. On balance, having the extra indirection produces a saving.

I think getOwningQPDF should ultimately be converted to return a shared_ptr

I am not sure it is possible to provide a shared_ptr given that the QPDF object itself is not dynamically allocated.

There might be a case for holding QPDF shared_ptr anyway

When I worked on # 749 it occurred to me that in reality QPDF is a shared_ptr already. The "true" QPDF object is the QPDF::Members that it points to.  It should therefore be easy (and cheap) to return the owning QPDF object itself rather than a pointer to it (throwing an exception if the method is called on a direct object).
(I haven't fully thought this through - there may be a show-stopper that I've missed)
@jbarlow83 , would that make life easier for pikepdf?

@m-holger That's an interesting idea. I had never thought of QPDF as something that would be used that way. As an experiment, I did a test build with this addition to QPDF.hh
    QPDF(QPDF const&) = delete;
    QPDF& operator=(QPDF const&) = delete;

and qpdf builds and passes its test suite, which proves that there is no code in the qpdf library itself that ever makes copies of QPDF objects. I also did this test (with an unmodified libqpdf):
#include <qpdf/QPDF.hh>
#include <qpdf/QPDFWriter.hh>

int main()
{
    QPDF q;
    q.emptyPDF();
    QPDF q2(q);
    QPDFWriter w(q2, "/tmp/a.pdf");
    w.write();
    return 0;
}

and this results in
terminate called after throwing an instance of 'std::logic_error'
  what():  QPDFObjectHandle from different QPDF found while writing.  Use QPDF::copyForeignObject to add objects from another file.

So that probably means people aren't copying QPDF objects around now even though they could. If we made getOwningPDF return a QPDF object and opened up the pattern of officially treating QPDF objects like shared pointers, this problem would probably go away since it results from the comparison of getOwningQPDF with the address of the writer's own QPDF. This could be resolved by implementing operator== that compares the address of the Members variable.
I have a few concerns, which are not necessarily show-stoppers:

After seeing the results of some of your other optimizations, I had actually considered whether we could get a little more performance out of QPDF by moving some (but not all) of the contents of Members into the object itself. We'd keep Members for ABI flexibility but optimize by moving some stable and frequently accessed members out. But this discussion makes me realize that that changes the meaning of copying QPDF and wouldn't only be safe if I blocked copying of QPDF or only moved things out of Members that were themselves pointer types. "delete"ing the default copy constructor and operator= would seem like a good idea in this case.
I could delete the copy constructor and operator= now, but this would be a non-compatible change and could break code. I had never considered whether it would work to make a copy of a QPDF object to keep it in scope for copyForeignObjects (though there are other mechanisms for this), so that change could break working code.
While it is definitely true that QPDF is like a shared pointer, it's kind of by mistake, and I'm not sure it's really idiomatic C++. I have sometimes wondered whether my decision to do things this way very early on was a mistake. At the time, I was playing around with Python and Java and had wished for more of a pass-by-reference behavior in C++. There were no shared pointers in the standard library at the time. I had PointerHolder, but it didn't have weak references. I did that as kind of an experiment, of course never imaging that qpdf would ever succeed as an open source project. Anyway, it's too late to change that.

QPDFObjectHandle has always been intentionally like a shared pointer, as implied by its name. I suppose making it possible to treat QPDF that way may not be a big stretch. That said, I can't promise that there aren't places in the library that assume two QPDF objects are the same if and only if they have the same address. There definitely used to be assumptions like that, but at some point, I introduced a unique ID for all QPDF objects. QPDF has a good test suite, but there may be code that does this that isn't exercised in a code path that would involve working with copies of QPDF objects. Also, if anyone wrote code that treats QPDF address comparison as equality, that code would break in subtle ways, and there's no easy way to detect that.
Having written all this, I wonder whether it might not be a bad idea to actually disallow copying of (and assignment to) QPDF objects to go down the shared pointer route for getOwningQPDF, even knowing that it would cause a ripple effect since we would have to eliminate all regular pointers from the API. That could be an item for qpdf 12 as previously stated.

which proves that there is no code in the qpdf library itself that ever makes copies of QPDF objects

Interesting. I actually wondered on how much QPDF::Members cost and removed it to find out. It turned out that  removing QPDF::Members actually increased the run time. I assumed that this was due to some copying going on, probably due to QPDF being passed by value somewhere.

I had actually considered whether we could get a little more performance out of QPDF by moving some (but not all) of the contents of Members into the object itself. We'd keep Members for ABI flexibility but optimize by moving some stable and frequently accessed members out.

I had the same thought, but my experiment with QPDF::Members made me rather less enthusiastic. I suspect it may not be all that beneficial except for code that gets very heavily excercised.
Another thought that occurred to me and which I haven't had time to investigate or fully think through: are there situations where it would make sense to implement methods at the Members level where the data is  rather than directly at the owning object level?

@jbarlow83 , would that make life easier for pikepdf?

If getOwningQPDF became:
QPDF getOwningQPDF(QPDFObjectHandle h) { return QPDF(h->etc()->get_qpdf_members()); }

I'd end up with is two Python pikepdf.Pdf that relate to the same QPDF. The QPDF object would have the appropriate reference count. Currently the pikepdf assumes a 1:1 correspondence from pikepdf.Pdf to QPDF, and stores some Python-side data in the Python object that matches a C++ object, for example, a temporary input file if one is needed. That's an assumption I made for pikepdf, and it could be changed. I could use a custom InputSource for the temporary file case for example.
There could be other issues but that's the only one I can think of that I know I'd have to change. There's no corresponding issue for QPDFObjectHandle because I don't keep side channel information and there's always been an assumption that mulitple QPDFObjectHandles which are actually the same object can be floating around.
In terms of the design question, I think it's worth considering that in C++ a copy constructor can implement either a deep copy or a shallow copy, while shared_ptr has explicit shallow copy semantics. STL also tends to use deep copies (e.g. std::string since C++11, vector). Not saying you can't have a shallow copy constructor, but it's a bit less explicit what it will do.
https://en.cppreference.com/w/cpp/memory/enable_shared_from_this might be relevant to this situation, and would allow recovery of the owning shared_ptr from parts of the code that only a this-> pointer.

QPDF::Members performance

Considering cache, this result makes some sense. The memory footprint of a QPDF isn't that large and pimpl's are usually sequential allocated, so close to the rest of object. The penalty comes in when we are potentially making millions of an object type like QPDFObjectHandle.

A few other notes.
QPDF objects have a unique ID. This is used when copying foreign objects to keep track of which QPDF an object came from without having to cache pointers, which can be reused. This was to solve the problem of two unrelated QPDF objects that live at different times having the same address, not the problem of two co-existing QPDF objects that are the same, but it might be useful in here somewhere.
I did a quick read through enable_shared_from_this. I don't think I want to use it because I don't want QPDF to have to have a base class, especially a public one.
One idea that comes to mind is to have something like a QPDF::Handle, which would essentially be a custom shared pointer specifically for QPDF. I write this fully aware that I could be just repeating old mistakes, but I'm pretty sure it will work and have negligible cost since getOwningQPDF is not used that often and there aren't that many QPDF objects.
With this change, we would deprecate getOwningQPDF and introduce QPDFObjectHandle::getQPDFHandle instead. See #751 for a possible implementation. I didn't include the QPDFObjectHandle changes yet, but they would be trivial.
If we go with that, I would add the allow_nullptr semantics to the new method in place of this PR.

A flaw/limitation of my QPDF::Handle solution is that a std::shared_ptrQPDF::Handle created from a std::weak_ptrQPDF::Handle will contain an invalid pointer once the QPDF is destroyed, but I still think this is much better than where we are now and offers a reasonable solution. It's already not safe to use a single QPDF object simultaneously from multiple threads, so there shouldn't be any race conditions where one thread locks a handle and another thread destroys the underlying QPDF object. Anyway, if we go with #751, I would make sure all this is documented.

Another thing that might be worth doing would be to explicitly deprecate copying/assigning to QPDF, which I think I could do by just declaring a [[deprecated("...")]] default copy constructor and assignment operator, but I haven't tried it and have to run to an appointment. This comment will ensure I don't forget about it.

It also occurs to me that getOwningQPDF would trivially be able to detect if the owning QPDF had disappeared and could throw a logic_error if that happened. That way, old code would continue to work but be safer, throwing an exception rather than returning a pad pointer in the event of a QPDF that's gone bad. New code that called getQPDFHandle() instead could explicitly check. There should be no valid cases of QPDFObjectHandles associated with a QPDF that's gone bad. If you want to keep it around after the QPDF is gone, then makeDirect() should be called.

Another thought that occurred to me and which I haven't had time to investigate or fully think through: are there situations where it would make sense to implement methods at the Members level where the data is rather than directly at the owning object level?

@m-holger I think I'd rather not add member functions to Members. I like the pattern of just having it be a container for member variables. My hunch is that if we had a situation where we'd gain performance by adding a method to Members, we'd do better to pull that field out of Members and stick it in the object. So far, there are no cases that I recall of objects with Members and any other member variables, but I'd be more open to that than adding member functions to Members.

@m-holger I ran format-code and pushed the fixup of the header ordering in QTC.hh to main. I guess I just missed that earlier.

I had a quick look at #751, but at the moment I am getting stuck at working out the rationale for getQPDF returning a pointer rather than (a reference to) the actual QPDF object itself.
I don't think this change affects #726. Sticking with an ordinary pointer is the most straight forward and cheapest option (https://github.com/qpdf/qpdf/pull/726/commits/1e2437ddf848e23681ac02d180a50c7d00351b76 ensures the pointer is invalidated when the owning QPDF gets destroyed).

I had a quick look at #751, but at the moment I am getting stuck at working out the rationale for getQPDF returning a pointer rather than (a reference to) the actual QPDF object itself.

I don't like interfaces that return references to things that might be null pointers.

I had a quick look at #751, but at the moment I am getting stuck at working out the rationale for getQPDF returning a pointer rather than (a reference to) the actual QPDF object itself.

I don't like interfaces that return references to things that might be null pointers.

But maybe I'm misunderstanding the concern.

oops, clicked close by mistake.

To me, calling getQPDF when the QPDF has been destroyed is a logic error and should throw an exception.
I would have expected something like
    QPDF q;
    // ...
    auto wp = q.getHandle();
    // ...
     {
         if (wp->isValid()) {
             auto qpdf = wp->getQPDF();
         }
     }
    if (wp->isValid()) {
         // The original QPDF is still valid
    // }

Too me, the item returned by getQPDF should keep the QPDF  object alive until the user is finished with it. Having the returned item quietly turn into a nullptr does not feel safe.
What is the reason for disallowing copying of QPDF objects?

The more I think about it, the more confused I get. I think that when I observed that QPDF is already kind of a pointer I may have thrown a complete red herring into the ring.

To me, calling getQPDF when the QPDF has been destroyed is a logic error and should throw an exception.

The problem is that QPDF objects can be allocated on the stack. There's no way to control when they get destroyed. All we can do is notice it and not hand people an invalid pointer.

What is the reason for disallowing copying of QPDF objects?

There is code in the library that assumes that there's a one-to-one match between the address of a QPDF object and whatever source that QPDF object was created from. That assumption could exist in other people's code as well since it's been true about qpdf since the beginning. Copying QPDF objects basically doesn't work right now, so there's not much chance that anyone's relying on being able to copy QPDF objects. Now that I've noticed this, I'd rather explicitly block copying QPDF objects than make it work and potentially introduce deep, hard-to-detect bugs in people's code because the previously valid assumption that you can meaningfully do an equality test on two QPDF*s is suddenly no longer true.
As I see it, the problem @jbarlow83 raised is that getOwningQPDF may return a bad pointer and that there's no way to ever know this. We can't fix with std::shared_ptr because it's common to allocate QPDF on the stack or for library users to allocate QPDF objects in whatever way they want. I don't think we can return actual QPDF objects without creating extremely subtle bugs in code that's out of our control. So we have to have a way to detect when a QPDF pointer goes bad, and this provides a fairly simple way to do it.
If I were starting from scratch today, I'd probably have a factory method that returns std::shared_ptr and have that be the thing people passed around. Then the semantics would be clear, and the qpdf library would be completely free of this objects-are-really-references pattern, but sadly, it's too late for that now.
My brain might be stuck in old thinking patterns though, so if I'm making a mistake in my thinking, please call me on it.

Too me, the item returned by getQPDF should keep the QPDF object alive until the user is finished with it. Having the returned item quietly turn into a nullptr does not feel safe.

This is actually the line I meant to quote at the beginning of my last comment. I was trying to say why there's no way to "keep the QPDF object alive".

Maybe it would be better to, for v11, deprecate stack-allocation of QPDF, introduce a shared_ptr factory to get everyone to migrate; and then for v12: drop stack allocation interface and use that time to fix getOwningQPDF and other issues?
Changing all QPDF q; to auto qptr = QPDF::create(); auto &q = qptr.get(); is greppable and avoids changing . to ->.

Maybe it would be better to, for v11, deprecate stack-allocation of QPDF, introduce a shared_ptr factory to get everyone to migrate; and then for v12: drop stack allocation interface and use that time to fix getOwningQPDF and other issues?
Changing all QPDF q; to auto qptr = QPDF::create(); auto &q = qptr.get(); is greppable and avoids changing . to ->.

That seems like a pretty big change to me. I'd want to think this through a little more, and I'm eager to get qpdf 11 out. I'd have to think through a good migration path and a way to make it possible for people to write code that works with older versions and newer versions. I'm not sure whether I'm prepared to deprecate stack allocation of QPDF objects.

@m-holger I am ready to merge this change. Can you think of a reason not to? The other issue we're discussing is not resolved, but it's not really related. Your change here is a good incremental step regardless of where we land.

I think the PR is good to go.

As I see it, the problem @jbarlow83 raised is that getOwningQPDF may return a bad pointer and that there's no way to ever know this.

#726 solves that problem.

The problem is that QPDF objects can be allocated on the stack. There's no way to control when they get destroyed.

That is why the user needs to test whether the QPDF is still  valid prior to calling getQPDF. Calling getQPDF without making this check beforehand to me is a logic error

There is code in the library that assumes that there's a one-to-one match between the address of a QPDF object and whatever source that QPDF object was created from.

That to me makes the case for returning a QPDF& rather than QPDF* stronger.  Once copy/assignment has been outlawed it will allow callling  QPDF methods directly, but will not allow to easily store a pointer/ref to QPDF.


Failing to get transcription for videos that used to work

So as the title says, the module is failing when trying to get the transcript for programs that used to work completely fine before.
Any help would be appreciated.
Edit: I am running Python 3.7.3 on Mac OSX Mojave 10.14.6 but I am also running as a Cloud Function (worked fine until a few days ago).
Here is an example with one of such videos:
>>> transcript = YouTubeTranscriptApi.get_transcript(video_id)
Traceback (most recent call last):
  File "/anaconda3/envs/viziotagnlpenv1/lib/python3.7/site-packages/youtube_transcript_api/_api.py", line 93, in get_transcript
    return _TranscriptParser(_TranscriptFetcher(video_id, languages, proxies).fetch()).parse()
  File "/anaconda3/envs/viziotagnlpenv1/lib/python3.7/site-packages/youtube_transcript_api/_api.py", line 160, in parse
    for xml_element in ElementTree.fromstring(self.plain_data)
  File "/anaconda3/envs/viziotagnlpenv1/lib/python3.7/xml/etree/ElementTree.py", line 1315, in XML
    parser.feed(text)
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 2, column 972

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/anaconda3/envs/viziotagnlpenv1/lib/python3.7/site-packages/youtube_transcript_api/_api.py", line 95, in get_transcript
    raise YouTubeTranscriptApi.CouldNotRetrieveTranscript(video_id)
youtube_transcript_api._api.CouldNotRetrieveTranscript: Could not get the transcript for the video https://www.youtube.com/watch?v=wFdSFVzWeKk! This usually happens if one of the following things is the case:
 - subtitles have been disabled by the uploader
 - none of the language codes you provided are valid
 - none of the languages you provided are supported by the video
 - the video is no longer available.

If none of these things is the case, please create an issue at https://github.com/jdepoix/youtube-transcript-api/issues```

Facing the same issue with any video which has transcripts.

same issue

Try to upgrade your package
pip install --upgrade youtube_transcript_api

Fixed with v0.1.9


Fix custom dataloader registry

CustomDataloaders currently don't support advanced capabilities like scArches or celltype prediction in scANVI. We have to create a registry without setup_anndata that contains the same elements (see below).
https://github.com/chanzuckerberg/cellxgene-census/blob/222efddf2ce82f93f76329aa353962c1dc2400ac/api/python/notebooks/experimental/pytorch_loader_scvi.ipynb is the first working example. Currently, they use the following code to save the model:
user_attributes = model._get_user_attributes()
user_attributes = {a[0]: a[1] for a in user_attributes if a[0][-1] == "_"}

user_attributes.update(
    {
        "n_batch": datamodule.n_batch,
        "n_extra_categorical_covs": 0,
        "n_extra_continuous_covs": 0,
        "n_labels": 1,
        "n_vars": datamodule.n_vars,
    }
)

We want to create a new function that fills out the registry and passes it to the model at: model = scvi.model.SCVI(n_layers=n_layers, n_latent=n_latent, gene_likelihood="nb", encode_covariates=False). You can see all necessary entries and the structure at: scvi.adata_manager.get_state_registry(scvi.REGISTRY_KEYS.X_KEY).to_dict().
After fixing this, all uses of _module_init_on_train throughout the codebase should be removed as they are not necessary anymore.

Is there some documentation on what is expected of the custom dataloader's collate function? I can imagine a dict with keys like X, batch and labels just by following up on the different types of exceptions I am getting. But for poor souls like us who are not familiar with the codebase, it'd be amazing to have some documentation of what type of keys a collate function should return in the dictionary to work.

Hi, we are currently still exchanging ideas with lamin and CZI to make the implementation better (and hopefully work towards support throughout all models - currently scVI works). Overall, the final requirement will be that a registry as a dictionary is created similar to https://colab.research.google.com/drive/10sXec_TicMKtLA6hMcgfkado-FgoNKxw#scrollTo=e8vZgceklGdH. We use as a discussion channel https://github.com/laminlabs/lamindb/issues/1826 to work together on a better implementation. Happy to connect offline (best case scverse Zulip) to see how we can support your work.


Node module dependency on a JSON file fails

I'm not sure if it is a seed configuration or not but I'm trying to use the moment-timezone package and when I import it as:
import * as moment from 'moment-timezone';

And then run my app I get the following error:
GET /node_modules/moment-timezone/data/packed/latest.json.js 404 (Not Found)

The get request is adding a .js ad the end of the latest.json file which does exist at that location.

If this is not a seed configuration issue I will gladly close or delete this ticket.

You need to reconfigure SystemJS and do not allow js extension for /node_modules/moment-timezone/data/packed/latest.json. You can take a look at SystemJS docs for further information.

@omargon did you ever figure this one out?  Per the SystemJS Docs

Note that if using the defaultJSExtensions compatibility feature, plugins for resources with custom extensions will only work by using the package configuration defaultExtension: false option to override this for specific packages.

So in theory adding the following to project.config.ts should work but it is not:
this.SYSTEM_BUILDER_CONFIG.packages['moment-timezone'] = {
  defaultExtension: false``
};

@mgechev any idea what I'm missing here?

You can disable the defaultJSExtensions for this package.

@mgechev isn't that what I did above in my example? defaultExtension option on the package per the docs is the way to disable defaultJSExtensions for the moment-timezone package as far as I can tell.

So I got it sort-of working.
If I put import * as moment from 'moment-timezone/builds/moment-timezone-with-data-2010-2020.min.js'; in my component and the following in project.config.ts
this.NPM_DEPENDENCIES = [
      ...this.NPM_DEPENDENCIES,
      {src: 'moment', inject: 'libs'},
      {src: 'moment-timezone/builds/moment-timezone-with-data-2010-2020.min.js', inject: 'libs'},
      // {src: 'lodash/lodash.min.js', inject: 'libs'},
    ];

This allows me to use moment-timezone methods and member vars, however I get this error from my component on the import:
error TS2307: Cannot find module 'moment-timezone/builds/moment-timezone-with-data-2010-2020.min.js'.

I'm pretty sure I know how to fix this, however any modifications/additions I make to seed.config.ts::SYSTEM_BUILDER_CONFIG.packages are not taking effect
Is SYSTEM_BUILDER_CONFIG.packages even used in development? I can make one of the well known objects incorrect and app still works fine.  Ex I put in an invalid main for @angular/router:
'@angular/router': {
        main: 'blah.js',
        defaultExtension: 'js'
      },

I think the true fix is to configure SystemJS with the following, however I cant get angular2-seed to pass it along
//import * as moment from 'moment-timezone'; in component
'moment-timezone': {
  main: 'builds/moment-timezone-with-data-2010-2020.min.js',
  defaultExtension: 'js'
}

I figured it out.  For others that run into this issue here is how you fix:
npm install moment moment-timezone --save and npm install @types/moment @types/moment-timezone --save-dev
In my component I do import * as moment from 'moment-timezone';.
In project.config.ts I do:
...
 constructor() {

    this.NPM_DEPENDENCIES = [
      ...this.NPM_DEPENDENCIES,
      {src: 'moment', inject: 'libs'},
      {src: 'moment-timezone/builds/moment-timezone-with-data-2010-2020.min.js', inject: 'libs'},
    ];

...
    const mtzc = {
      main: 'builds/moment-timezone-with-data-2010-2020.min.js',
      defaultExtension: 'js'
    };

    this.SYSTEM_BUILDER_CONFIG.packages['moment-timezone'] = mtzc;
    this.SYSTEM_CONFIG_DEV.packages['moment-timezone'] = mtzc;
  }

I can then use console.log(moment.tz.guess());
@mgechev I'm guessing SYSTEM_BUILDER_CONFIG is used when doing production builds? So it is necessary to duplicate the SystemJS configuration in SYSTEM_BUILDER_CONFIG and SYSTEM_CONFIG_DEV correct?

I tried to get rid of one of the configurations in the past and I'm willing to do so in future but at this point we cannot cover all usage scenarios with only a single one.


The submitter does not receive an email upon form submission if the email field is updated

Background: The submitter does not receive an email upon form submission if the email field is updated
Environment: Dev
Steps to Reproduce:

Log in to the PSA-Digital-Journey portal with valid credentials.
Fill out the telework form.
Change the submitter email to a different valid email than the one you are logged in with.
Submit the form.

Actual Behavior:  The user does not receive an email upon form submission if the email field is updated
Expected Behavior: The user should receive an email upon form submission.

Update- Carried one round of testing.

The employee email was changed from what was prepopulated for my work email to my personal email.

filled out the rest of the form and made a submission.

Received confirmation email of submission in personal email address

Also received an attachment alongside a confirmation email of the filled-out form after manager approval was granted.

*scheduled to carry out one more test to close out the issue if the test goes without any errors.

Changing the email address of either the Employee(Submitter) or the Supervisor worked in DEV the updated email was received by the new recipient

This works in test as well sending to the address of whom ever it's addressed and using the 'name' in the email as it it left (or not)


Performance when having large data

Describe the bug
When having multiple columns to render, it takes a while and also receive a warning in the console.
This is when rendered for the first time

To Reproduce
Steps to reproduce the behavior:
Load a lot of data into the graph
Expected behavior
Performance should be smooth

any luck with this one


sorted the contributors list alphabetically

fixes #225 @Suyash-Purwar

@souviknsl07 Please provide a screenshot

@Abhishek-kumar09  All the names starting with lowercase are in their proper positions.  Sorted alphabetically


Analyze parser performance degradation with recent Vim versions

This issue is restricted to the (optional) formatting functionality of the plugin.

The first step of auto-formatting an *.smt2 file is parsing it
For reference, parsing a file of 27KB used to take <0.01s with Vim v8.2.2725.
Newer versions seem to be a bit slower, i.e. Vim v9.0.1107 needs 0.5s to parse the same file.
With Vim v9.0.1122, parsing the same file suddenly takes 17.5s :warning:
The latest release Vim v9.1.0912 is even slightly worse: 19s

The plugin's code didn't change -- it's Vim getting worse at executing vim9script.
We've got to at least remedy whatever happened between v9.0.1107 and v9.0.1122.
The goal of this task is to:

provide a minimal example, s.t. the Vim folks can investigate the performance degradation, or
pinpoint the problematic commit in the Vim repo

Note to myself: Tested with docker run --rm -it -v ~/:/root thinca/vim:v9.0.1107 /root/Desktop/smt2/append_fs_unsafe.c.mini.smt2

According to :help patches-9.1 one of these changes must have introduced the performance degradation:
Patch 9.0.1108
Problem:    Type error when using "any" type and adding [a](https://vimhelp.org/insert.txt.html#a) number to [a](https://vimhelp.org/insert.txt.html#a) float.
Solution:   Accept both [a](https://vimhelp.org/insert.txt.html#a) number and [a](https://vimhelp.org/insert.txt.html#a) float. (closes #11753)

Patch 9.0.1109
Problem:    Leaking allocated type.
Solution:   Reset the "static" flag in the allocated type copy.

Patch 9.0.1110
Problem:    Build fails on [Mac](https://vimhelp.org/os_mac.txt.html#Mac) OS [X](https://vimhelp.org/change.txt.html#X) 10.4/10.5 [.](https://vimhelp.org/repeat.txt.html#.)
Solution:   Check if the dispatch/dispatch.h header exists. (Evan Miller,
            closes #11746)

Patch 9.0.1111
Problem:    Termcap entries for RGB colors are not set automatically.
Solution:   Always set the [termcap](https://vimhelp.org/term.txt.html#termcap) entries when [+termguicolors](https://vimhelp.org/various.txt.html#%2Btermguicolors) [is](https://vimhelp.org/motion.txt.html#is) enabled.

Patch 9.0.1112
Problem:    [test_mswin_event()](https://vimhelp.org/testing.txt.html#test_mswin_event%28%29) can hang.
Solution:   Add the "execute" argument to process events right away.
            (Christopher Plewright, closes #11760)

Patch 9.0.1113
Problem:    Users cannot e[a](https://vimhelp.org/insert.txt.html#a)sily try out a PR.
Solution:   Add an "artifacts" [section](https://vimhelp.org/motion.txt.html#section) to the AppVeyor CI config. (Christian
            Brabandt, closes #11762)

Patch 9.0.1114
Problem:    CI does not use the latest [Python](https://vimhelp.org/if_pyth.txt.html#Python) version.
Solution:   Switch from [Python](https://vimhelp.org/if_pyth.txt.html#Python) 3.10 to 3.11. (closes #11761)

Patch 9.0.1115
Problem:    Code [is](https://vimhelp.org/motion.txt.html#is) indented more than needed.
Solution:   Use an early return to reduce indenting. (Yegappan Lakshmanan,
            closes #11758)

Patch 9.0.1116
Problem:    Compiler may complain about an unused function.
Solution:   Add #ifdef. (John Marriott)

Patch 9.0.1117
Problem:    Terminfo entries for bracketed paste are not used.
Solution:   Use the newly added [terminfo](https://vimhelp.org/term.txt.html#terminfo) entries for bracketed paste.
            Correct mixup of output strings and key codes.

Patch 9.0.1118
Problem:    Sporadic test failures when using [a](https://vimhelp.org/insert.txt.html#a) [terminal](https://vimhelp.org/terminal.txt.html#terminal) window.
Solution:   Adjust waiting times. (James McCoy, closes #11763)

Patch 9.0.1119
Problem:    Type of arguments not checked when c[a](https://vimhelp.org/insert.txt.html#a)lling a partial.
Solution:   Give an error for [a](https://vimhelp.org/insert.txt.html#a) wrong argument type. (closes #11753)

Patch 9.0.1120
Problem:    Tex [filetype](https://vimhelp.org/filetype.txt.html#filetype) detection not sufficiently tested.
Solution:   Add more test cases for "tex" detection. (Jonas Strittmatter,
            closes #11765)

Patch 9.0.1121
Problem:    Cursor positioning and display problems with ['smoothscroll'](https://vimhelp.org/options.txt.html#%27smoothscroll%27) and
            using "[zt](https://vimhelp.org/scroll.txt.html#zt)"[,](https://vimhelp.org/motion.txt.html#%2C) "[zb](https://vimhelp.org/scroll.txt.html#zb)" or "[zz](https://vimhelp.org/scroll.txt.html#zz)"[.](https://vimhelp.org/repeat.txt.html#.)
Solution:   Adjust computations and conditions. (Yee Cheng Chin,
            closes #11764)

Patch 9.0.1122
Problem:    [Class](https://vimhelp.org/vim9class.txt.html#Class) member access [is](https://vimhelp.org/motion.txt.html#is) not fully tested yet.
Solution:   Add more tests.

The problematic transition seems to be from Vim v9.0.1118 to v9.0.1119:

According to :help patches-9.1 this is the change:
Patch 9.0.1119
Problem:    Type of arguments not checked when c[a](https://vimhelp.org/insert.txt.html#a)lling a partial.
Solution:   Give an error for [a](https://vimhelp.org/insert.txt.html#a) wrong argument type. (closes #11753)


Suggest update Maven installation to use profiles

When trying to apply the installation instructions to a multi-JDK build project, I ran into cases where the specific JDK logic could not be used uniformly. I ended up just dropping it out of JDK 8, but kept it for JDK 9 and JDK 17 using the instructions for JDK 16, but I had to wrap it all in Maven profiles, a la
  <profiles>
    <profile>
      <id>java9</id>
      <activation>
        <jdk>[9,)</jdk>
      </activation>
      <build>
        …
      </build>
    </profile>
  </profiles>

Perhaps consider replacing the per-JDK instructions with a single <profiles>-based approach, with specific XML comments to indicate what consumers could pull out if they don't care about multi-JDK support. This would have the benefit that if they do float from an older version to a newer version, at least ErrorProne won't break on them.

The specific case I'm mentioning is https://github.com/googleapis/java-datastore/pull/592.


Add patch

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

See https://github.com/conda-forge/staged-recipes/pull/16147#issuecomment-927932988

@conda-forge-admin, please rerender

Thank you!

Should we mark the previous builds as broken as it took ages for the solver to use the new ones last time.


Allow reduction of OAuth2.0 scopes by refresh token grant

On refresh token grant, OAuth2.0 only requires the requested scopes to be a subset of the granted scopes (https://datatracker.ietf.org/doc/html/rfc6749#section-6). This is also reflected by the javadoc and error message in AccessTokenRefreshTokenGrantRequestExtractor::extractRequestedScopesByToken.
Contrary to the spec, the javadoc and the error message, the code only checks for equality and empty set.
This PR fixes the comparison and changes the creation of renewed RefreshToken to keep the original set of granted scopes. It furthermore addes two tests for scope reduction: one with and one without RefreshToken renewal.

One more note: please consolidate your puppeteer tests into an existing test. I don't think these necessarily need to stand on their own. Thank you!

Currently only one test fails: OidcAccessTokenEndpointControllerTests$MvcTests::verifyRefreshTokenUpdatesTicketGrantingTicket of the oidc test suite. According to the logs, the test fails due to a code expiring after 2 seconds, just before it is redeemed. This also happens on master.

You can let that go, but your patch still need to carry proper unit tests.

Are those unit tests sufficient or have I missed something?

Thank you, that is good enough for now. Please cross check with CI builds and go through the failures, and fix the stuff that might be relevant. I see some code style failures, etc.

Now all code style failures should be fixed.
The other two failures are tests that also fail on master.

@apereocas-bot runci


The version 3 not found

Error: Unable to resolve action mristin/opinionated-commit-message@v3, unable to find version v3
The README suggests using @v3 but the GHA is unable to find this version.

@groundf Thanks for reporting the issue! I'll try to have a look at it tomorrow in the evening (CET).


Add xSPWebAppPolicy resource

The xSPWebAppPolicy defines a specific policy to create against a web application. It should be structured as follows:
xSPWebAppPolicy AdminFullControlPolicy
{
Zones = "*"
User = "CONTOSO\SharePoint Administrators"
Permissions = "Full Control"
OperateAsSystem = $false
}
The Zones option here should use * to indicate that this is for all zones, otherwise an enum style value for the zones that are included (eg. "Intranet,Extranet,Default")

I'm on this one.

This is part of PR #120 and when that is closed and merged to dev this issue will be closed off

This has been merged in to dev, closing this issue


Search location name format edit

Adds comma between county name and state code in searchbar menu
Before:

After:

 Update format of location names in search dropdown menu items


API returns more data when queried

API now returns drs.data and drs edges (along with scores)
This should be straightforward, but I like to make sure someone else looks at these things before they get pulled in.

If we only sent one at a time, in some cases, we'd be asking Algebra to do the same queries twice.
Given that we don't know where the bottleneck will be, or how convenient the data will be for front end applications, I think that we should send both for now. If a user is just interested in the data, they can just use that.
It's always (very easily) changeable later on.

If we only sent one at a time, in some cases, we'd be asking Algebra to do the same queries twice.

The idea I propose is to send one or two, instead of always two. That way, if we know we only need the data, we can just retrieve that first. My worry is that the provenance graph can be quite big in many cases.
Having said that, and since it's easy to change anyway, I'm fine with doing this later.
Should I merge?

Yep!
Sorry, I should have said "If we only send data in some cases, if the user then asked for edges afterwards, we'd need to run the algebra twice."

All right, I'm merging. Can you open an issue (enhancement or similar) for later? Just to make sure we keep track of this.


[WIP] populate_db: Add emoji reactions in some messages.

I am supposed to add emoji reactions to around 10 percent messages generated by populate_db.
With these changes I am not facing any error while re populating but I am still not able to see any reactions. Any help would be appreciated.
THE ISSUE: #14991
Testing Plan:
./manage.py populate_db

Successfully added the emoji reactions in around 10 percent of the messages generated by the populate_db.

Closing in favor of #16238, which uses a more involved strategy and passes tests.


[GPU] Issue while building mod files using vector_capacity(void* v) and vector_vec(void* v)

Describe the issue
Recently some of the BBP mod files are updated to use vector_capacity and vector_vec:

NET_RECEIVE (weight, weight_AMPA, weight_NMDA, Psurv, nc_type) {
    : Psurv - survival probability of unrecovered state
    : nc_type:
    :   0 = presynaptic netcon
    :   1 = spontmini netcon
    :   2 = replay netcon

    LOCAL result, ves, occu
    weight_AMPA = weight
    weight_NMDA = weight * NMDA_ratio

    INITIAL {
        if (nc_type == 0) {  :// presynaptic netcon
    VERBATIM
            // setup self events for delayed connections to change weights
            void *vv_delay_times = *((void**)(&_p_delay_times));
            void *vv_delay_weights = *((void**)(&_p_delay_weights));
            if (vv_delay_times && vector_capacity(vv_delay_times)>=1) {
                double* deltm_el = vector_vec(vv_delay_times);
                int delay_times_idx;
                next_delay = 0;
                for (delay_times_idx = 0; delay_times_idx < vector_capacity(vv_delay_times); ++delay_times_idx) {
                    double next_delay_t = deltm_el[delay_times_idx];
    ENDVERBATIM
                    net_send(next_delay_t, 1)
    VERBATIM
                }
            }
    ENDVERBATIM
        }
    }

While compiling these mod files with CoreNEURON+GPU, we get:
NVC++-S-1061-Procedures called in a compute region must have acc routine information - coreneuron::vector_capacity(void *) (x86_64/corenrn/mod2c/DetGABAAB.cpp: 522)
NVC++-S-0155-Accelerator region ignored; see -Minfo messages  (x86_64/corenrn/mod2c/DetGABAAB.cpp: 512)
NVC++-S-1061-Procedures called in a compute region must have acc routine information - coreneuron::vector_capacity(void *) (x86_64/corenrn/mod2c/ProbAMPANMDA_EMS.cpp: 590)
NVC++-S-0155-Accelerator region ignored; see -Minfo messages  (x86_64/corenrn/mod2c/ProbAMPANMDA_EMS.cpp: 580)

To Reproduce

Install coreneuron with GPU support
Compile any recent synapse mod file from BBP model (or any other mod file with call to vector_capacity and vector_vec).

Expected behavior
Mod files should compile fine with GPU enabled CoreNEURON.
System (please complete the following information)

BB5

Additional context
Note that those mod files have:
#ifndef CORENEURON_BUILD
extern int ifarg(int iarg);

extern void* vector_arg(int iarg);
extern double* vector_vec(void* vv);
extern int vector_capacity(void* vv);
#endif

i.e. these functions were supposed to call from NEURON only. With the change for delayed connections, verbatim blocks now introduced these functions into CoreNEURON as well.
I am looking into annotation of above functions with OpenACC. But other question is, do we need to (or should we) use these functions on CoreNEURON side?
@ohm314 and @jamesgking can answer this?

At least in the current implementation they are needed in coreneuron too. The reason is that NET_RECEIVE itself now has a verbatim block, which calls vector_vec and vector_capacity.

The reason is that NET_RECEIVE itself now has a verbatim block, which calls vector_vec and vector_capacity.

And I don't think we can drop it, since we want to access a Hoc Vector (probably the only option to pass arrays from hoc/python to mod). Numpy C API is an option? (I guess not).
Either way, the problem is that these routines are not compiled with nvcc too?


Unable to export org-mode documents: Loading file build-27.1/org-mode/ob-c.elc failed to provide feature ‘ob-c’

Using default doom emacs, trying to run org-export-dispatch and then exporting as markdown, I get the following error:
Loading file /Users/user/.emacs.d/.local/straight/build-27.1/org-mode/ob-c.elc failed to provide feature ‘ob-c’
I'm running on macOS 10.15, and tried both on emacs-plus and on emacsformacosx, same result.
Also tried deleting the local straight build and rerunning doom-sync, but the issue persists. Any ideas what I'm doing wrong?
My .doom.d/init.el just enabled (org +present) btw

Getting same error on v27.2
This is happening only if C code blocks are present in org file.

As of c339bb0 this issue should be resolved. Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!

@hlissner Thanks for the fix! However I am now getting a different issue, possibly related. Given the same config and a very basic org file:
#+TITLE: Test

* Test
#+begin_src c
void foo(void) {}
#+end_src

Trying to publish (C-c e -> v -> b) gets me:
replace-regexp-in-string: Wrong type argument: arrayp, nil

Any idea what might be causing this?

I cannot reproduce this error.    ...)) :translate-alist ((headline . org-re-reveal-headline) (inner-template . org-re-reveal-inner-template) (item . org-re-reveal-item) (keyword . org-re-reveal-keyword) (link . org-re-reveal-link) (latex-environment . org-re-reveal-latex-environment) (latex-fragment lambda ... ... ...) (plain-list . org-re-reveal-plain-list) (section . org-re-reveal-section) (src-block . org-re-reveal-src-block) (special-block . org-re-reveal-special-block) (template . org-re-reveal-template) (bold . org-html-bold) (center-block . org-html-center-block) (clock . org-html-clock) (code . org-html-code) (drawer . org-html-drawer) (dynamic-block . org-html-dynamic-block) (entity . org-html-entity) (example-block . org-html-example-block) (export-block . org-html-export-block) (export-snippet . org-html-export-snippet) (fixed-width . org-html-fixed-width) (footnote-reference . org-html-footnote-reference) (headline . org-html-headline) (horizontal-rule . org-html-horizontal-rule) ...) :exported-data #<hash-table eq 2/4001 0x1ffd6b0d5a21> :input-buffer "testme.org" :input-file "/private/tmp/testme.org" :reveal-center t :reveal-control t :reveal-defaulttiming nil :reveal-fragmentinurl nil :reveal-generate-ids t :reveal-hashonebasedindex nil :reveal-height nil ...))
  #f(compiled-function (element) #<bytecode 0x1ffd6bf524e5>)((src-block (:language "c" :switches nil :parameters nil :begin 23 :end 64 :number-lines nil :preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "void foo(void) {}\n" :post-blank 0 :post-affiliated 23 :parent (section (:begin 23 :end 64 :contents-begin 23 :contents-end 64 :post-blank 0 :post-affiliated 23 :parent (headline (:raw-value "Test" :begin 16 :end 64 :pre-blank 0 :contents-begin 23 :contents-end 64 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 16 :title (...) :parent (org-data nil ... #47) :CUSTOM_ID "1") #31)) #1))))
  mapconcat(#f(compiled-function (element) #<bytecode 0x1ffd6bf524e5>) ((src-block (:language "c" :switches nil :parameters nil :begin 23 :end 64 :number-lines nil :preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "void foo(void) {}\n" :post-blank 0 :post-affiliated 23 :parent (section (:begin 23 :end 64 :contents-begin 23 :contents-end 64 :post-blank 0 :post-affiliated 23 :parent (headline (:raw-value "Test" :begin 16 :end 64 :pre-blank 0 :contents-begin 23 :contents-end 64 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 16 :title ... :parent ...      ...)) :translate-alist ((headline . org-re-reveal-headline) (inner-template . org-re-reveal-inner-template) (item . org-re-reveal-item) (keyword . org-re-reveal-keyword) (link . org-re-reveal-link) (latex-environment . org-re-reveal-latex-environment) (latex-fragment lambda ... ... ...) (plain-list . org-re-reveal-plain-list) (section . org-re-reveal-section) (src-block . org-re-reveal-src-block) (special-block . org-re-reveal-special-block) (template . org-re-reveal-template) (bold . org-html-bold) (center-block . org-html-center-block) (clock . org-html-clock) (code . org-html-code) (drawer . org-html-drawer) (dynamic-block . org-html-dynamic-block) (entity . org-html-entity) (example-block . org-html-example-block) (export-block . org-html-export-block) (export-snippet . org-html-export-snippet) (fixed-width . org-html-fixed-width) (footnote-reference . org-html-footnote-reference) (headline . org-html-headline) (horizontal-rule . org-html-horizontal-rule) ...) :exported-data #<hash-table eq 2/4001 0x1ffd6b0d5a21> :input-buffer "testme.org" :input-file "/private/tmp/testme.org" :reveal-center t :reveal-control t :reveal-defaulttiming nil :reveal-fragmentinurl nil :reveal-generate-ids t :reveal-hashonebasedindex nil :reveal-height nil ...))
  #f(compiled-function (backend &optional subtreep visible-only body-only ext-plist) "Transcode current Org buffer into BACKEND code.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.\n\nIf narrowing is active in the current buffer, only transcode its\nnarrowed part.\n\nIf a region is active, transcode that region.\n\nWhen optional argument SUBTREEP is non-nil, transcode the\nsub-tree at point, extracting information from the headline\nproperties first.\n\nWhen optional argument VISIBLE-ONLY is non-nil, don't export\ncontents of hidden elements.\n\nWhen optional argument BODY-ONLY is non-nil, only return body\ncode, without surrounding template.\n\nOptional argument EXT-PLIST, when provided, is a property list\nwith external parameters overriding Org default settings, but\nstill inferior to file-local settings.\n\nReturn code as a string." #<bytecode 0x1ffd7ebf82d9>)(re-reveal nil nil nil (:output-file "testme.html"))
  apply(#f(compiled-function (backend &optional subtreep visible-only body-only ext-plist) "Transcode current Org buffer into BACKEND code.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.\n\nIf narrowing is active in the current buffer, only transcode its\nnarrowed part.\n\nIf a region is active, transcode that region.\n\nWhen optional argument SUBTREEP is non-nil, transcode the\nsub-tree at point, extracting information from the headline\nproperties first.\n\nWhen optional argument VISIBLE-ONLY is non-nil, don't export\ncontents of hidden elements.\n\nWhen optional argument BODY-ONLY is non-nil, only return body\ncode, without surrounding template.\n\nOptional argument EXT-PLIST, when provided, is a property list\nwith external parameters overriding Org default settings, but\nstill inferior to file-local settings.\n\nReturn code as a string." #<bytecode 0x1ffd7ebf82d9>) (re-reveal nil nil nil (:output-file "testme.html")))
  (let ((old-async-init-file org-export-async-init-file) (org-export-async-init-file (make-temp-file "doom-org-async-export"))) (let ((temp-file org-export-async-init-file) (temp-buffer (generate-new-buffer " *temp file*"))) (unwind-protect (prog1 (save-current-buffer (set-buffer temp-buffer) (prin1 (list 'progn (list ... ... ... ... ...) (cons ... ...)) (current-buffer))) (save-current-buffer (set-buffer temp-buffer) (write-region nil nil temp-file nil 0))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))) (apply orig-fn args))
  +org--fix-async-export-a(#f(compiled-function (backend &optional subtreep visible-only body-only ext-plist) "Transcode current Org buffer into BACKEND code.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.\n\nIf narrowing is active in the current buffer, only transcode its\nnarrowed part.\n\nIf a region is active, transcode that region.\n\nWhen optional argument SUBTREEP is non-nil, transcode the\nsub-tree at point, extracting information from the headline\nproperties first.\n\nWhen optional argument VISIBLE-ONLY is non-nil, don't export\ncontents of hidden elements.\n\nWhen optional argument BODY-ONLY is non-nil, only return body\ncode, without surrounding template.\n\nOptional argument EXT-PLIST, when provided, is a property list\nwith external parameters overriding Org default settings, but\nstill inferior to file-local settings.\n\nReturn code as a string." #<bytecode 0x1ffd7ebf82d9>) re-reveal nil nil nil (:output-file "testme.html"))
  apply(+org--fix-async-export-a #f(compiled-function (backend &optional subtreep visible-only body-only ext-plist) "Transcode current Org buffer into BACKEND code.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.\n\nIf narrowing is active in the current buffer, only transcode its\nnarrowed part.\n\nIf a region is active, transcode that region.\n\nWhen optional argument SUBTREEP is non-nil, transcode the\nsub-tree at point, extracting information from the headline\nproperties first.\n\nWhen optional argument VISIBLE-ONLY is non-nil, don't export\ncontents of hidden elements.\n\nWhen optional argument BODY-ONLY is non-nil, only return body\ncode, without surrounding template.\n\nOptional argument EXT-PLIST, when provided, is a property list\nwith external parameters overriding Org default settings, but\nstill inferior to file-local settings.\n\nReturn code as a string." #<bytecode 0x1ffd7ebf82d9>) (re-reveal nil nil nil (:output-file "testme.html")))
  org-export-as(re-reveal nil nil nil (:output-file "testme.html"))
  #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>)(re-reveal "testme.html" nil nil nil nil nil)
  apply(#f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) (re-reveal "testme.html" nil nil nil nil nil))
  (let (before-save-hook after-save-hook) (apply orig-fn args))
  +org--dont-trigger-save-hooks-a(#f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) re-reveal "testme.html" nil nil nil nil nil)
  apply(+org--dont-trigger-save-hooks-a #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) (re-reveal "testme.html" nil nil nil nil nil))
  #f(advice-wrapper :around #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) +org--dont-trigger-save-hooks-a)(re-reveal "testme.html" nil nil nil nil nil)
  apply(#f(advice-wrapper :around #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) +org--dont-trigger-save-hooks-a) (re-reveal "testme.html" nil nil nil nil nil))
  (let ((old-async-init-file org-export-async-init-file) (org-export-async-init-file (make-temp-file "doom-org-async-export"))) (let ((temp-file org-export-async-init-file) (temp-buffer (generate-new-buffer " *temp file*"))) (unwind-protect (prog1 (save-current-buffer (set-buffer temp-buffer) (prin1 (list 'progn (list ... ... ... ... ...) (cons ... ...)) (current-buffer))) (save-current-buffer (set-buffer temp-buffer) (write-region nil nil temp-file nil 0))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))) (apply orig-fn args))
  +org--fix-async-export-a(#f(advice-wrapper :around #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) +org--dont-trigger-save-hooks-a) re-reveal "testme.html" nil nil nil nil nil)
  apply(+org--fix-async-export-a #f(advice-wrapper :around #f(compiled-function (backend file &optional async subtreep visible-only body-only ext-plist post-process) "Call `org-export-as' with output to a specified file.\n\nBACKEND is either an export back-end, as returned by, e.g.,\n`org-export-create-backend', or a symbol referring to\na registered back-end.  FILE is the name of the output file, as\na string.\n\nA non-nil optional argument ASYNC means the process should happen\nasynchronously.  The resulting buffer will then be accessible\nthrough the `org-export-stack' interface.\n\nOptional arguments SUBTREEP, VISIBLE-ONLY, BODY-ONLY and\nEXT-PLIST are similar to those used in `org-export-as', which\nsee.\n\nOptional argument POST-PROCESS is called with FILE as its\nargument and happens asynchronously when ASYNC is non-nil.  It\nhas to return a file name, or nil.  Export back-ends can use this\nto send the output file through additional processing, e.g,\n\n  (defun org-latex-export-to-latex\n    (&optional async subtreep visible-only body-only ext-plist)\n    (interactive)\n    (let ((outfile (org-export-output-file-name \".tex\" subtreep)))\n      (org-export-to-file \\='latex outfile\n        async subtreep visible-only body-only ext-plist\n        (lambda (file) (org-latex-compile file)))\n\nThe function returns either a file name returned by POST-PROCESS,\nor FILE." #<bytecode 0x1ffd6b02d5b5>) +org--dont-trigger-save-hooks-a) (re-reveal "testme.html" nil nil nil nil nil))
  org-export-to-file(re-reveal "testme.html" nil nil nil nil nil)
  org-re-reveal-export-to-html(nil nil nil nil nil)
  org-re-reveal-export-to-html-and-browse(nil nil nil nil)
  org-export-dispatch(nil)
  funcall-interactively(org-export-dispatch nil)
  call-interactively(org-export-dispatch nil nil)
  command-execute(org-export-dispatch)

@vmalloc This is certainly not a Doom issue. You (or a package you've installed) has added a function to one of these hooks:

change-major-mode-after-body-hook
prog-mode-hook
c-mode-common-hook
c-mode-hook

Use SPC h v (or C-h v) to inspect these hooks, and look for a function or closure that looks like:
(unless (or (file-exists-p "makefile")
            (file-exists-p "Makefile"))
  (set (make-local-variable 'compile-command)
       (concat "gcc " (shell-quote-argument buffer-file-name)
               " -o /tmp/output")))

You'll have to bisect your config to figure out what adds it.

@hlissner gotcha. Will look into it. Thanks!

Thanks for the help and sorry for the unnecessary hassle!


Enable tcmalloc VDSO support only on x86 to reduce static initializers

Background context
crrev.com/1466173002 switched the GN tcmalloc target from source_set
-> static_library. There are good reasons for keeping tcmalloc a
source_set (see "Note on static libraries" in [1]).  However, in the
current state source_set was exposing extra static initializers in the
GN build which, are not present in the gyp build due to the linker gc
sections.
Resolution of this CL
The fact that vdso_support.cc is GC-ed by the linker is the symptom
that such code is unreachable. A search in the codebase shows that the
only client is stacktrace_x86-inl.h, which depends on VDSO only when
defined(linux) && defined(i386) This CL is therefore matching
this condition in vdso_support.h and conditioning the #define
HAVE_VDSO_SUPPORT with the same conditions.
[1] https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/cookbook.md
References:
https://bugs.chromium.org/p/chromium/issues/detail?id=559766
https://bugs.chromium.org/p/chromium/issues/detail?id=564618

Merged. Thanks a lot.


Viewmodel weapon shadows rendered in first person

weapon shadows in first person can still be seen alongside the third person shadow

Fixed


Allow Zoom links to be sent

Remove the zoom link restriction, now that UCF uses SSO on zoom.
https://github.com/joey-colon/lion/blob/18445003e9492376846ebf9c12d46ae5e4b21b05/src/app/handlers/blacklist.handler.ts#L46-L51

thought we did this a while ago

thought we did this a while ago


Connection time out with multi-node

I follow the instructions in here to run in 2 nodes:
https://fairseq.readthedocs.io/en/latest/getting_started.html#distributed-training
Basically I added this line before a single node command and run on node 0 (each node has 4 GPUs):

python -m torch.distributed.launch --nproc_per_node=4
--nnodes=2 --node_rank=0 --master_addr="<IP_ADDRESS>"
--master_port=22015
and replace --node_rank=1 for node 1.

However, both processes wait for a minute and stop with "Connection time out". I wonder if I am missing anything or if anyone succeeded running fairseq on multi-node please let me how you did it.
| dictionary: 267744 types
| data-bin/wikitext-103 train 403231 examples
| data-bin/wikitext-103 valid 851 examples
| distributed init (rank 0): tcp://<IP_ADDRESS>:22015
Traceback (most recent call last):
  File "/home/tuan/anaconda3/bin/fairseq-train", line 11, in <module>
    load_entry_point('fairseq', 'console_scripts', 'fairseq-train')()
  File "/home/tuan/pytorch/fairseq/fairseq_cli/train.py", line 392, in cli_main
    distributed_main(args.device_id, args)
  File "/home/tuan/pytorch/fairseq/fairseq_cli/train.py", line 380, in distributed_main
    main(args, init_distributed=True)
  File "/home/tuan/pytorch/fairseq/fairseq_cli/train.py", line 47, in main
    args.distributed_rank = distributed_utils.distributed_init(args)
  File "/home/tuan/pytorch/fairseq/fairseq/distributed_utils.py", line 67, in distributed_init
    rank=args.distributed_rank,
  File "/home/tuan/anaconda3/lib/python3.7/site-packages/torch/distributed/distributed_c10d.py", line 354, in init_process_group
    store, rank, world_size = next(rendezvous(url))
  File "/home/tuan/anaconda3/lib/python3.7/site-packages/torch/distributed/rendezvous.py", line 95, in _tcp_rendezvous_handler
    store = TCPStore(result.hostname, result.port, world_size, start_daemon)
RuntimeError: Connection timed out

Thanks

Please make sure that that IP address is reachable from both hosts. Alternatively you can try passing any valid distributed_init method via the --distributed-init-method argument to fairseq. The available init methods are described here (scroll down a bit): https://pytorch.org/docs/stable/distributed.html#torch.distributed.init_process_group

Thanks a lot. I figured that the IPs were incorrect. The training runs fine after that.

Thanks a lot. I figured that the IPs were incorrect. The training runs fine after that.

Same issue here. https://discuss.pytorch.org/t/runtimeerror-with-distributed-package-using-nccl-or-gloo-backend/30992/3
Can you please explain? Were you using any cloud (aws, gcp) for this?


SPA: problems when walk between pages with audio elements.(sometimes)

(html5 player not flash fallback)Hi there. I don't know problem in me when i use it or in api but i when i trying to play audio when walk between pages my player time to time in sleep and after about 30 sec he start play track. during this he say that he is active and time 00:00. Can anybody check this. I'm trying to find any useful information but can't find it. Thanks.
Also i didn't find in api methods like destroy..may be problem in it. Is it need when make new instrance of player? But i think it will be very useful to have it.

not actual right now. work fine


Weapon capacity not decreasing when attacking

When making an attack with a weapon that has charges programmed and usage set, the capacity does not decrease in the character sheet. When the attack occurs, it shows the ammo decrease in the chat window, but it isn't saved and actually reflected in the owner's sheet. Subsequent attacks always show the initial charge less the attack. v
Example:
Created Azimuth laser pistol, capacity 20 / 20, usage 1 / 20 (or 1 / blank, or anything you want for testing purposes)
Assigned item to player.
Player makes attack.
Text in chat shows 19 /  20 charges.
Character sheet still says 20 / 20.
All future attacks show 19 / 20.

I had the issue too, and solved it randomly when importing a statblock with the NPC importer module.
It works if you write 1/shot for the usage. I think there are a few other phrases that work, but I couldn't find any documentation on that yet.

Can confirm, 1 / shot works! Thanks!

Yeah, that's my bad. The second field for usage is the "per" field, so it should be read "use 1 cartridge/charge/bullet/arrow/etc per shot". The two words here that matter for ammo consumption are "shot" and "round" (spelled exactly like that, casing matters). But, this has been changed in the upcoming release to be a drop down box, so it should be clearer what the intent behind this field is.

This should be clearer in the new release. Closing for now, but we can revisit this if it becomes necessary.


Add Bluetooth Disconnect Reasons

Is your feature request related to a problem? Please describe.
For better error investigation on client devices that we do not have access to, it would be helpful to determine the reason why Bluetooth has been disconnected.
Describe the solution you'd like
I hereby propose an enhancement to the onDisconnect-callback of the connect method to provide the disconnect reason, ideally in alignment with the HCI_DISCONNECT specification.

Host Controller Interface Functional Specification
Controller Error Codes

Unfortunately, we generally don't get any of this information passed back from OS itself.
Android simply returns the state as disconnected (source).
iOS gives an error which is converted into a string and reported back to the caller (source).

Android: https://developer.android.com/reference/android/bluetooth/BluetoothGattCallback#onConnectionStateChange(android.bluetooth.BluetoothGatt, int, int)
iOS: https://developer.apple.com/documentation/corebluetooth/cbcentralmanagerdelegate/centralmanager(_:diddisconnectperipheral:error:)

While I agree the information would be useful, I don't know what can be done here to improve the situation.


How to use?

I am currently working on a project to connect the warehouse system to shopee, is there any documentation to use this package?
does it support multiple shopee accounts?
can be used in laravel?
can I contribute?

this project still not finished, document not available yet
you're welcome to contribute, just open a PR
I'll give you some example for starting
use EcomPHP\Shopee\Client;

$client = new Client('partner id', 'partner key');

to generate authorization url
$auth = $client->auth();
$url = $auth->createAuthRequest('callback url');
redirect_to($url);

get token by authorization code
$token = $auth->getToken($request->code, $request->shop_id);

set access token before call api
$client->setAccessToken('access token');

call api to get order list
$client->Order->getOrderList(['response_optional_fields' => 'order_status']);

for other api you can view source code in Resources folder


[flutter_tools] maintain file manifest for create

Description
First pass at fixing https://github.com/flutter/flutter/issues/57985 and implementing https://github.com/flutter/flutter/issues/59602
This doesn't have enough metadata to be useful for IDEs yet, but it prevents the issue from getting worse while we iterate on it.

Friendly ping @jmagman @christopherfujino

though I'd like Jenn's approval too.

LGTM too, I'll run it again locally after the DS_Store update and approve.

Started Google testing for this PR

Google testing passed!


refactor(tf-gcp): Legacy Stackdriver was Decomissioned 21/03/31

Related to #140 and #137
Legacy Stackdriver was deprecated, then decomissioned March 31, 2021.  If you leave the fields undefined, GKE will default to using Stackdriver for both logging and monitoring.  This allows the fields to be undefined OR set, but must be set to the current stackdriver values.
Proposed Changes

Adds 'monitoring.googleapis.com' and 'logging.googleapis.com' as disallowed values for monitoring_service and logging_service, respectively
allows monitoring_service and logging_service to be undefined (default is Stackdriver)
updates tests, docs, and url text for both queries

I submit this contribution under the Apache-2.0 license.

Setting to draft because I thought it would be a good idea to branch of my master...so this includes the changes from my first PR...
If/when that one gets accepted, will update this accordingly.

Looks like the failing test is from a merge to the main kics branch, not my changes.  I'll update my branch when that's fixed.

Not sure where that would be failing...I'll poke around.

It seems to have been the addition of .logging_service/.monitoring_service in the searchKey in the tests.  I removed that again.

Hi @meldaravaniel,
The tests were probably failing due to the vulnerability detection line not being the same as in the positive_expected_result.json file. You can update the query to use still  .logging_service/.monitoring_service in the searchKey but you also need to update the expected line in the positive_expected_result.json  file.
Let me know what you think.

You can update the query to use still .logging_service/.monitoring_service in the searchKey but you also need to update the expected line in the positive_expected_result.json file.

Mmm...no, I don't think it's that. The expected lines in positive_expected_result.json refer to the lines in the positive.tf file, not the query. Changing the query shouldn't affect that. The expected lines match, otherwise the tests would be failing right now (I haven't changed the expected line values other than to match them to the new positive tests
I'm not running the tests locally, so I might try that, but is there a way to run them such that the error is better than just the exit code? Or maybe I can use a debugger...

Yes you can run the unit tests locally using the following command on the repo root
go test ./test

Hi @meldaravaniel hope you are doing great!
Regarding the changes, I suggested triggering problems on the tests
I have updated the values on my side and ran the Unit tests and E2E tests and seem to be ok, with no error whatsoever.
The changes I made:
assets/queries/terraform/gcp/stackdriver_logging_disabled/query.rego

added .logging_service to the search key in both policies
"searchKey": sprintf("google_container_cluster[%s].logging_service", [primary]),

assets/queries/terraform/gcp/stackdriver_logging_disabled/test/positive_expected_result.json

updated the vuln lines to 6 and 18
added "fileName": "positive.tf" in both results

assets/queries/terraform/gcp/stackdriver_monitoring_disabled/query.rego

added .monitoring_service to the search key in both policies
"searchKey": sprintf("google_container_cluster[%s].monitoring_service", [primary]),

assets/queries/terraform/gcp/stackdriver_monitoring_disabled/test/positive_expected_result.json

updated the vuln lines to 6 and 18
added "fileName": "positive.tf" in both results

Let me know if this helps!

@cxMiguelSilva omg my brain just turned back on and I understand the expected/actual line numbers now.  idk why that was so hard for me to get.  we'll pretend it was sleep deprivation. :P  I was thinking they just meant "the line at which each resource starts".  But it's linked to the search key, so in my other commits, that happened to be the same as "line where resource starts"...because the search key was just the parent level resource.  Had to read the test code a bit before that hit me. *sigh
Got Go up and running on my computer, much faster to test locally (obviously heh) and yes, that all works and makes sense now.

Hi @meldaravaniel,
Don't worry everyone has those moments 😅. I'm glad I was able to help.


Verification View

Problem
C2D-84 Jira
Solution
What I/we did to solve this problem

Cleaned up the styles for the verification page

Change Summary:

Updated Verify View, Resend Verification, and Verification Messages

Dev-Ops
If you added an ENV variable, please check off that you've updated the following

[ ] Key & Sample value to .env & sample.env
[ ] GCP Secret Manager (Both development and production)
[ ] Github Secrets (Added a development and production variable)
[ ] Github Workflows .github/workflows/dev.yml & .github/workflows/prod.yml
[ ] webpack-config.js

Images/Important Notes (optional):

Responsiveness and no design currently exists for this component

Mobile

Tablet

Desktop

I don't think we will get a design for this, since it's a small component and low priority. I'll send a picture using the error background but for now I'm using team page background as our temporary reference

@krishnakpandian Hmm, let's keep using the team page background as is then. Otherwise we'd have to adjust the font color as well. Sorry for the trouble.

I just made some edits, before I push, is this more in line in terms of fonts and background-colors? @w-gao

https://github.com/CruzHacks/cruzhacks-2022-website/pull/65#issuecomment-939394635


Allow @authorize directive on input fields

The @authorize directive should be applicable to input fields as well as output fields.
Use case:
I have a mutation that, among other actions, stores data.  One of the data fields is a date/time.  In production, I always want to use the current date/time, but when testing it's nice to be able to explicitly set the date/time to a specific value so that when the item is retrieved, I can validate the date/time that was used.
To achieve this, I want to expose a date/time field on the input type that is only accessible to callers with a specified policy (e.g. "TesterGroup").
If a caller does not have this policy and tries to set this value, an "unauthorized" error is returned, similarly to if a caller requests an output field they are not authorized to retrieve.
Our current alternative is to create a completely separate mutation that takes in another type that has the date/time field on it.  But this uses a different resolver, and thus different code, so I'm not testing the correct code path.

I am closing this as a duplicate. The conversation is happening on #1879

Odd that this one is marked as the duplicate of a later issue, but okay.

Just because the discussion evolved on the newer issue.


Fix misbehaving tests

(Edits by @vgkholla to delete tests that are no longer relevant)
The following tests were failing intermittently or hanging and were commented out in PR #294.  This ticket tracks their fixes.
In BlockingChannelConnectionPoolTest:

testBlockingChannelInfoForPlainText (fails intermittently)

com.github.ambry.network.BlockingChannelConnectionPoolTest > testBlockingChannelInfoForPlainText FAILED
java.lang.AssertionError at BlockingChannelConnectionPoolTest.java:242

testSSLBlockingChannelConnectionPool (fails intermittently)

com.github.ambry.network.BlockingChannelConnectionPoolTest > testSSLBlockingChannelConnectionPool FAILED
java.lang.Exception at BlockingChannelConnectionPoolTest.java:396

In SimpleByteBufferPoolTest:

testOneExpiredAnotherServed (hangs intermittently, seemingly deadlocked)

one thread:
at java.lang.Thread.join(Thread.java:1354)
at com.github.ambry.utils.SimpleByteBufferPoolTest.testOneExpiredAnotherServed(SimpleByteBufferPoolTest.java:220)

another thread:
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at com.github.ambry.utils.SimpleByteBufferPoolTest$BufferConsumer.run(SimpleByteBufferPoolTest.java:259)

Tagged with newbie. Might be useful for someone new to debug the tests and learn the code.

@sriramsub Hey, I am exploring the testRollingIndex test, can you give me the scenario for reproducing the test failure?

@greplog This is indeed a good starter issue to look into.
The test fails intermittently. @cgtz may have more idea about how to reproduce it. But when it does fail, we see the following:
com.github.ambry.store.PersistentIndexTest > testRollingIndex FAILED
java.lang.AssertionError at PersistentIndexTest.java:841
java.lang.NullPointerException: at com.github.ambry.store.PersistentIndexTest.testRollingIndex(PersistentIndexTest.java:837)

This is most likely an issue with the test being incorrect. Either way, I would recommend starting with these steps:

Get a basic understanding of what the PersistentIndex class is meant for and what all it does by going through the class here: ambry-store/src/main/java/com.github.ambry.store/PersistentIndex.java.
Go through the test to see what it is trying to test and if it is doing it the right way, if there is any obvious issues that you can see.
Enable testRollingIndex() test by uncommenting the @Test in this file: ambry-store/src/test/java/com.github.ambry.store/PersistentIndexTest.java

Feel free to ask us about anything at<EMAIL_ADDRESS>

@pnarayanan Thanks for the heads up and error log, as you suggested, I am going through the code, and will try to reproduce and fix it.

Hi @greplog! To help with reproducing this bug, after uncommenting the test you want to target, try running the tests in a loop using this bash command:
count=0; while (./gradlew clean && ./gradlew build && [ $count -ne 50 ]); do ((count++)); printf "\n\nDone with %d iterations\n\n" $count; done

Hi all, there are other tests also failing in the current system like DiskTest.testDiskSoftState
Plus, can somebody help me with the difference in task unitTest and test, I am assuming test is running integration plus unit tests, while unitTest is running only unit tests.
stacktrace of other failing tests
com.github.ambry.clustermap.DiskTest > testDiskSoftState FAILED
java.lang.AssertionError: expected: but was:
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:145)
at com.github.ambry.clustermap.DiskTest.testDiskSoftState(DiskTest.java:142)
26 tests completed, 1 failed
:ambry-clustermap:unitTest FAILED

Hi @greplog, thanks for finding this! What type of system did it fail on? I can add it to the list.
Regarding the test and unitTest targets, you are correct.  test runs the server integration tests as well.  We set it up this way so that the build target will just run the unit test suite but test will run both.

Hi @cgtz
I ran the test on mac OSX Yosemite, with Java Environment 1.8

testBlockingChannelInfoForSSL also failed recently


Docs: add instructions to README

Hihi,  I just saw this issue https://github.com/pahen/madge/issues/339 - very cool, would love to use madge with Svelte files.
Is this repo working or not complete?
Normally I use madge to search my project for circular depencies with:
pnpx madge --circular ./src --extensions js,ts,svelte -i ./madge.png

Works great for ts, js, but unfortunately it does not resolve any imports with svelte extensions.

Vue support was added to madge, so svelte support should be easy hopefully!


Support 1.19.4 on Modrinth (and CurseForge, probably?)

This mod works on 1.19.4, but Modrinth doesn't know it yet, and this fact kinda is preventing users who don't know it to use it.
So, yeah, probably the latest version should be marked as compatible with the latest update.

Modrinth CurseForge


Add completions for cmds with aliases

Fixed bug in comp.Cmd
Add completions for cmd names and aliases as comp.Alias
Added documentation for all completers.

The tests for comp.Cmd were disabled (commented) and were actually failing. The output block in the test was accurate which meant the completer code had a bug. The case in question is when the len(args) == 0. The code returns all possible values, but ideally it would mean that the command itself hasn't been completed yet.
This made me revisit how the completion works for Cmds. The Complete method is always going to be called with a cmd and args. The check for length of args is done in the x.detectCompletion method. Which allows you to safely assume that len(args) > 0 when the Complete method is called. So for every completer, if the len(args) == 0 then they should either return an empty list or not bother with that case ever.
However it should be noted that the first arg can be an empty string, in which case the completer must return all possible completions.

@rwxrob should the completers support case insensitive completions? For e.g. Cmd with sub-commands as "Foo", "far" and "bar", for the argument "f", the case insensitive completer would complete with "Foo" and "far".

As long as it is explicitly added with something like comp.Aliases.WithIgnoreCase().

I have implemented the new way of creating a Pipe of completers. Following is what the usage looks like.
func ExamplePipe_Complete() {
	cmd := bonzai.Cmd{
		Name: "foo",
		Opts: `fooc|foobar|foobaz`,
		Comp: comp.Pipe{comp.Opts, filt.Prefix("foo")},
	}
	fmt.Println(cmd.Comp.Complete(cmd))
	fmt.Println(cmd.Comp.Complete(cmd, ""))
	fmt.Println(cmd.Comp.Complete(cmd, "b"))

	// Output:
	// []
	// [fooc foobar foobaz]
	// [foobar foobaz]
}

The implementation checks whether the element in the Pipe is a Completer or a Filter. If it is a Filter then the list of completions that has been accumulated before the filter is passed to it to process. This makes the filter a post operation. This is a limitation that makes the implementation of filt.Prefix, filt.IgnoreCase impossible. Such filters require them to be a pre operation where the input args to the Complete method call needs to be modified. For reference following is the implementation of WithPrefix as of this comment in this PR.
func (f withPrefix) Complete(x bonzai.Cmd, args ...string) []string {
	if len(args) == 0 {
		return f.compelter.Complete(x, f.prefix)
	}
	args[0] = f.prefix + args[0]
	return f.compelter.Complete(x, args...)
}

Here you can see that the arguments to the Complete call are modified for required results. To achieve this with the new implementation, we would have to add some logic for postfix|prefix filter, which is a bit too complex that I would like it to be. I'll provide the other relevant code in the following code fold.

Relevant code for and old and new implementation
Old Impl
type withMinLen struct {
	len       int
	completer bonzai.Completer
}

// WithMinLen return a [bonzai.Completer] that limits the length of
// completions to a minimum length.
func WithMinLen(len int, completer bonzai.Completer) withMinLen {
	return withMinLen{len, completer}
}

func (f withMinLen) Complete(x bonzai.Cmd, args ...string) []string {
	var list []string
	for _, completion := range f.completer.Complete(x, args...) {
		if len(completion) >= f.len {
			list = append(list, completion)
		}
	}
	return list
}

type withPrefix struct {
	prefix    string
	compelter bonzai.Completer
}

// WithPrefix return a [bonzai.Completer] that filters completions that
// have the given prefix. This removes the requirement for the user to
// type the prefix to get complete completions.
func WithPrefix(prefix string, completer bonzai.Completer) withPrefix {
	return withPrefix{prefix, completer}
}

func (f withPrefix) Complete(x bonzai.Cmd, args ...string) []string {
	if len(args) == 0 {
		return f.compelter.Complete(x, f.prefix)
	}
	args[0] = f.prefix + args[0]
	return f.compelter.Complete(x, args...)
}

These are essential Special completers as Combine is
New Impl
package comp

import (
	"github.com/rwxrob/bonzai"
)

type Filter interface {
	Filter([]string) []string
}

type Pipe []any

func (pipe Pipe) Complete(x bonzai.Cmd, args ...string) []string {
	list := make([]string, 0)
	for _, elem := range pipe {
		switch typed := elem.(type) {
		case Filter:
			list = typed.Filter(list)
		case bonzai.Completer:
			list = append(list, typed.Complete(x, args...)...)
		}
	}
	return list
}

package filt

import "strings"

type Prefix string

func (prefix Prefix) Filter(s []string) []string {
	out := make([]string, 0)
	for _, v := range s {
		if strings.HasPrefix(v, string(prefix)) {
			out = append(out, v)
		}
	}
	return out
}

type MinLen int

func (minLen MinLen) Filter(s []string) []string {
	out := make([]string, 0)
	for _, v := range s {
		if len(v) >= int(minLen) {
			out = append(out, v)
		}
	}
	return out
}

Usage

Let's use the same package names as I used in the fn package since these things are effectively the same, just only with string input. In fact, we might want to keep all of this 100% compatible with all those other transformations in fn since that was always the intention, to collect a library of common filters and map transformations:

filt
mapf

Then the mapf.Interface interface could just be a transformation of a single string:
type Interface interface {
  Change(string) string
}

Also, we should probably change filt.Filter to filt.Interface to avoid stuttering.
Honestly, I think fn/mapf.Prefix is what we need to add and support. This stuff doesn't even belong in the comp module.

In fact, after thinking about it more. The only comp specific thing in comp.Pipe should be the Completer implementations, all the rest should take the form of a fn/mapf or an fn/filt so we don't get functional stuff in more than one place. I feel really strongly about that.

And I think we should standardize on some types in the fn package (which I will add:

fn.MapFunc - func[T any](in T) T
fn.FiltFunc - func[T any](in []T) []T
fn.Filter - specifically a struct that implements Filter()
fn.Map - specifically a struct that implements Change()

So that the type switch is consistent across all of Bonzai, more or less:
func (pipe Pipe) Complete(x bonzai.Cmd, args ...string) []string {
    list := make([]string, 0)
    for _, elem := range pipe {
      switch v := elem.(type) {
      case fn.MapFunc:
        list = v.Change
      case fn.Filter:
        list = v.Filter(list)
      case fn.FilterFunc:
        list = v.Filter(list)
      case bonzai.Completer:
        list = append(list, v.Complete(x, args...)...)
      }
    }
    return list
  }

And can we please use v := for type switches. More idiomatic to everything else.
I'm working on a PR for these changes to fn right now.


Org Query Side

[ ] Get Global Org by domain
[ ] Search Orgs
[ ] Search Org Members
[ ] Get Org Member Roles

[ ] generate domain on query side


Added the BlockCypher testnet parameters

The code looks fine, though I'd like you to add additional test vectors for these network constants.


Fix check of previously verified accounts when in feeless flow

Description
The feeless verification flow was incorrectly using the lookupIdentifiers method on the Attestations contract when it should have been using lookupAccountsForIdentifier. This was causing us to check if EOAs were verified instead of MTWs, which is why it was never detecting any previously verified accounts.
Other changes
Moving dekAndWalletRegistration into the endVerification generator to ensure that it's always called.
Tested
Yes
Related issues

Fixes #5853

Backwards compatibility
Yes

Hi @tarikbellamine i Have verified this issue latest test flight build v1.5.5 (34) and Android play store internal build v1.5.5<PHONE_NUMBER>) and observe the following

Feeless flow is not shown when a user is already verified.

Devices: iPhone 6+ (12.4.5) , Vivo v11 pro (10)
Can you please let us know if we need to test anything else.


V5: Handling Hover, Focus, and Other States by using only utility classes

Prerequisites

[X] I have searched for duplicate or closed feature requests
[X] I have read the contributing guidelines

Proposal
For example, to apply the bg-blue-500 class on hover, use the hover:bg-blue-700 class:
<button class="btn btn-lg bg-blue-500 hover:bg-blue-700 ...">
  Click on me
</button>

for more details about this feature: Check this out
Motivation and context
it will be great to have something like this in bootstrap

It already exists thanks to the utilities API.
As far as I know, this isn't used in the default build but building from Sass on your own would do the trick.