How to hide the calendar dropdown picker

Hi,
there's an option to hide the calendar picker? I can't find it!
I want only to use the check over field without showing the calendar.
Regards, Luca

Sorry but I do not understand which dropdown picker? this plugin do not use any dropdown, list, select, etc.
If you're not using the calandar, then for what to include the picker?

I want only to use the check over field without showing the calendar.

I don't really understan maybe an image example?

I would like to disable the calendar picker, letting just the input field. There isn't an option as "hideCalendar" to set to true or something similar?
(Sorry for my english!)
Luca

Hi, sorry but for what just an input? and not the calendar, the calendar is what it make this plugin works!
Or do you mean something like not showing the calendar icon in the input? something like this:

If yes just follow this link:  http://eonasdan.github.io/bootstrap-datetimepicker/#no-icon-input-field-only
and if not, then sorry but I think you're in the wrong place or I really don't understand what are you looking for.

Sorry, I'm explaining a bit bad. I have this situation:

       Birth Date
       <input type='text' class="col-xs-12 form-control" placeholder="gg/mm/aaaa"
                   id='datePicker' name="dateBirth"  required/>

......
......
$('#datePicker').datetimepicker({
     viewMode: 'years',
     format: 'DD/MM/YYYY',
     minDate: '01/01/1900',
     maxDate: 'moment',
});

With this result: https://ibb.co/ivFEDw
So, when i click on the field, calendar is showed (inside the red circle in my image). I want this calendar is not showed, never. In other words, i want to use the plugin only to check if the format of date (hand-written) inside the field is valid.
I see the documentation, but i can't find an options to do it!

Hi, for yo to do that it not necessary to use this plugin the only that you need is moment.js
just doing something like this will suffice your needs:
console.log(moment('14-14-2012', 'DD-MM-YYYY',true).isValid());
Just follow this guide: http://momentjs.com/docs/#/parsing/string-format/ almost at the end of that part you can see the isValid() function.

I want this calendar is not showed, never.
I see the documentation, but i can't find an options to do it!

That's because is not possible to do it at least not with an option form this plugin.
For more question about this please use StackOverflow

I know this is an old conversation, but I was looking for the same thing and I did this and it works great!
$('date-selector').focus(function () {
$('.bootstrap-datetimepicker-widget').css('display', 'none');
});


Log status on log

Fix link to next incomplete section (CLDC-1085)
Update text for a log that has not been started: This log has not been started.
Update text for in progress log: X of X sections completed. (removal of another ‘you’ – multiple users can collaborate on a log)

Closed for https://github.com/communitiesuk/submit-social-housing-lettings-and-sales-data/pull/410


Add Docker support

Add Docker build to containerize the project.

I have this running in cloudrun as of a few days ago which may help contribute back to see the setup.
https://github.com/groovybits/gaib/blob/main/Dockerfile
https://github.com/groovybits/gaib/blob/main/cloudbuild.yaml
https://github.com/groovybits/gaib/blob/main/CLOUDRUN.md
I actually saw this one and it helped me quite a bit craft it all to work in Cloudrun nicely. In Vercels it times out for me, although GAIB may be different in that regard than this chatbot GAIB evolved out of.


[codegen] Output-versioned function invokes

Description

Fixes #163
This PR is my initial attempt at getting function invokes to return Output<ResultType> instead of CompletableFuture<ResultType>
My thought at first was to generate syntax sugar around existing function invokes that return CompletableFuture<ResultType> and wrap them using Output.all,  Output.apply and Output.of(CompletableFuture) but then I saw that the SDK itself has the function that can be used immediately:
Deployment.getInstance().invoke(....) // returns Output<T>

Questions are

Should both types of function invokes co-exist? if we have functions that return Output<T> is there any need for CompletableFuture alternative?
Am I on the right track with this implementation?

TODO

Generate code from all providers
Remove workaround in programgen that wraps function invokes with Output.of(....)

Checklist

[ ] I have added tests that prove my fix is effective or that my feature works

[ ] I have updated the CHANGELOG-PENDING file with my change

[ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

Should both types of function invokes co-exist? if we have functions that return Output is there any need for CompletableFuture alternative?

this is a very good question, I second this

A kind reminder, to clear the codegen test errors we currently need to manually commit the changes to the generated test code.
Running PULUMI_ACCEPT=true; make codegen_tests and committing the result should clear the current CI error IIRC.
Sorry for the inconvenience, we probably should automate this somehow in the future.

Hi @pawelprazak, been trying to debug what is going on here to no avail 😓 I ran the command you sent but the tests keep failing. It is showing code diffs telling that the generated code has changed ... well, that's what the PR is supposed to do 😅 any leads?

@Zaid-Ajaj I'm sorry you're having troubles with this, if you'd like we could pair on this over zoom.
Feel free to reach out to me on Slack.

@pawelprazak thank you! Tomorrow I will have another look and reach out if I am still stuck 🙏

NOTE to self:

Remember to PUMULI_ACCEPT=true make codegen_test
Having an outdated build of the SDK in your local maven build will cause the tests to fail unless you make install_sdk first before running the tests

Alright so this is really frustrating to work with, after having changed how function invokes are implemented, regenerated code from providers and installed them locally, the test examples failed in the CI. For example
make test_example.gcp-java-gke-hello-world

would fail in the CI but if I run it locally it tells me that everything is good while using a older version of the provider (gcp in this case)
This means I was in the unfortunate state of ✅ locally and 🔴 on CI and had to rewrite the function invokes in the test examples by hand to make them work in CI but locally it was red squiggles all over the place.
Somehow even when I install a provider after regenerating it, the test examples were still using a cached build somewhere on my machine. I would expect that make test_example.gcp-java-gke-hello-world would take care of removing cached builds of providers.
The test examples are now all green which is good but still need to update azure-java template. Specifically, the following
    private static Output<String> getStorageAccountPrimaryKey(Output<String> resourceGroupName,
                                                              Output<String> accountName) {
        return Output.tuple(resourceGroupName, accountName).apply(tuple -> {
            var actualResourceGroupName = tuple.t1;
            var actualAccountName = tuple.t2;
            var invokeResult = StorageFunctions.listStorageAccountKeys(ListStorageAccountKeysArgs.builder()
                    .resourceGroupName(actualResourceGroupName)
                    .accountName(actualAccountName)
                    .build(), InvokeOptions.Empty);
            return Output.of(invokeResult)
                    .applyValue(r -> r.keys().get(0).value())
                    .asSecret();
        });
    }

should change into:
    private static Output<String> getStorageAccountPrimaryKey(Output<String> resourceGroupName,
                                                              Output<String> accountName) {

            var invokeResult = StorageFunctions.listStorageAccountKeys(ListStorageAccountKeysArgs.builder()
                    .resourceGroupName(resourceGroupName)
                    .accountName(accountName)
                    .build());

            return invokeResult
                    .applyValue(result -> result.keys().get(0).value())
                    .asSecret();
    }

I guess I should update that in the templates repo and then update the templates submodule from here

NOTE: function invokes here also suffer from pulumi/pulumi#9593 which is why wrapping with Output.tuple(...).apply(...) is still necessary sometimes when doing a pulumi preview

TODOs

[x] Generate code for all providers
[x] Refactor program-gen to use output-versioned invokes
[ ] Disable testing templates because these are out of date with latest providers
[ ] Bring back function invokes that return CompletableFuture<T> as there is no (easy) way to obtain T from Output<T> and use it in control flow unless from within apply and applyValue (thanks @mikhailshilkov for the note)

Should both types of function invokes co-exist? if we have functions that return Output is there any need for CompletableFuture alternative?

Both must coexist, unless we opt to expose Output.join() : Output<T> -> T. There are scenarios where invokes need to run in plain context and lifting them to work on Output modality is too much pain on the user.

My thought at first was to generate syntax sugar around existing function invokes that return CompletableFuture and wrap them using Output.all, Output.apply and Output.of(CompletableFuture) but then I saw that the SDK itself has the function that can be used immediately:

There's some leeway here, I think in most of the SDKs we went with syntactic sugar implementation, but there was some blocker making it too difficult/impossible in the C# SDK case.
Ah I remember what it was exactly. FPlainArgs and FInputArgs types differ in deeply nested Outputs. There was no way in the C# SDK to convert FInputArgs to Output<FPlainArgs that would be required by the "syntactic sugar". And implementing the transformation at code-generation time was distasteful to me (mildly complex).
Java implementation started the port from C# so some of the same considerations can apply here.

Yes, we need an update in templates repo unfortunately. Yes, the Makefile does not understand dependencies correctly which is quite frustrating. We could try working this out that'd help everyone. Providers team is experimenting and adopting with Task util instead of make also if that helps https://github.com/go-task/task
One wrench here is that the provider team is taking over the provider code trees and moving them out of the repo, so the capability to "test my changes on provider X" will have to be able to work around the source being somewhere else. I'm open to input how to make this all better, it clearly is a time sink right now.

MOre review comments in https://github.com/pulumi/pulumi-java/pull/636 - since this current PR breaks GH UI

Actually @Zaid-Ajaj I have tried testing the azure-template with modifications, and it's not working. Unfortunately that's blocking. We have a bug in here somewhere.
Here is the modification I've made to take advantage of the new features:
    private static Output<String> getStorageAccountPrimaryKey(Output<String> resourceGroupName,
                                                              Output<String> accountName) {
        return StorageFunctions.listStorageAccountKeys(ListStorageAccountKeysArgs.builder()
                                                       .resourceGroupName(resourceGroupName)
                                                       .accountName(accountName)
                                                       .build())
            .applyValue(r -> r.keys().get(0).value())
            .asSecret();
    }

 modified:   azure-java/src/main/java/myproject/App.java
Here's how I tested the change:
make install_sdk
make provider.azure-native.install
make test_template.azure-java

    io.grpc.StatusRuntimeException: UNKNOWN: invocation of azure-native:storage:listStorageAccountKeys returned an error: request failed /subscriptions/0282681f-7a9e-424b-80b2-96babd57a8a1/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}/listKeys: autorest/azure: Service returned an error. Status=404 Code="ResourceGroupNotFound" Message="Resource group '{resourceGroupName}' could not be found."

I guess I should update that in the templates repo and then update the templates submodule from here

Here's a reason we can't do that - updating the templates repo would BREAK the templates for all Pulumi users since these changes are not released yet. Hence my suggestion of having a branch in that repo tracking pulumi-java/main that we sync to master whenever we release.

Actually @Zaid-Ajaj I have tried testing the azure-template with modifications, and it's not working. Unfortunately that's blocking. We have a bug in here somewhere.

@t0yv0 I've actually seen this error before, it is a manifestation of pulumi/pulumi#7030 where function invokes fail when populating their parameters with instances Output<T> during pulumi preview
pulumi/pulumi#9593 Also demontrates the same behaviour
The suggested workaround during a pulumi preview seems to be guarding the function invoke with an unknownOutput.apply(unused -> invokeHere()) where unknownOutput can be any ID of any resource since these unknown during a preview.
Another workaround in the template code is to guard the function invoke with an if statement that checks if we are executing a dry run
    private static Output<String> getStorageAccountPrimaryKey(Output<String> resourceGroupName,
                                                              Output<String> accountName) {

        if (Deployment.getInstance().isDryRun())
        {
             return Output.secret("*** StorageAccountPrimaryKey ***");
        }

        return StorageFunctions.listStorageAccountKeys(ListStorageAccountKeysArgs.builder()
                                                       .resourceGroupName(resourceGroupName)
                                                       .accountName(accountName)
                                                       .build())
            .applyValue(r -> r.keys().get(0).value())
            .asSecret();
    }

The final workaround at runtime is to make function invokes smarter and expanding their logic as follows:
public static Output<ArbitFuncResult> arbitFunc(ArbitFuncArgs args)
{
    if (Deployment.getInstance().isDryRun())
    {
         // return Output<ArbitFuncResult> but it is unknown?
    }

    // execute invoke as usual...
}

I think making the generated function invokes smarter is the way to go so that users don't have to worry changing their code to adapt to preview/update runs. What do you think?

My preferred fix for this issue pulumi/pulumi-java/pull/671 which is also what we have in C#, Python, etc.
The suggestion to not invoke in preview is interesting but I can see some downsides, well, namely that invokes don't work in preview. Bookmarking it for further discussion. This would be a change across all SDKs not just Java.
I also would like to step through the ref'd issues myself to get a better understanding:

https://github.com/pulumi/pulumi/issues/7030
https://github.com/pulumi/pulumi/issues/9593

Confirming that I can pass the test with #671  merged here.
make install_sdk
make provider.azure-native.install
export PULUMI_JAVA_SDK_VERSION=0.0.1 # ouch, otherwise template test does not use the in-source SDK
make test_template.azure-java


Implemented a new reader of atomic coordinates

I implemented a function that reads the atomic coordinates. So far, GCEED part reads the atomic coordinates from a file in Cartesian coordinates, while ARTED part read that from input in reduced coordinates.

I would say this is a bit confusing for users, and thus, I extended the function.
Now, one can give the atomic coordinates either from a file (file_atom_red_coor/file_atom_coor) or input  (&atomic_red_coor/&atomic_coor). Also, either reduced or Cartesian coordinates can be used.

I removed results of GCEED/example since some of them can not be reproduced from example input anymore.

@uemoto1 san and @mn2007 san, I would like to ask you to review this PR. If both of you approve this, please merge this.

In previous meetins, there was a controversy whether atomic coordinates should be separated or not. GCEED handles large number of atoms, so coordinates are separated prevously. But come to think of it, I always write huge lines of atomic coordinates in input files when I use quantum espresso or cp2k. So, I think this modification causes no problem.
I have a question. We don't include output in examples even when we release stable version?

@mn2007 san, thank you for your comments. I did not know the discussion about the atomic coordinates, but I can imagine that the additional-file-input would be preferable for large systems. On the other hand, for standard users, the direct-input would be convenient. Thus, I extended SALMON to be able to employ either ways. So, if you want, still you can use an additional file file_atom_coor for atomic coordinate (see manual/input_variables.md for details).
About output, honestly, I do not see any reason why we have them in the code. They can be provided from input. Also, we can put them on web-tutorial. So, why do we need them in the code?

I checked some famous applications (cp2k and octopus) and found that there was no output in samples. I've thought that it's natural that samples contain output because RSDFT and SMASH have it. I understand your opinion and I change my mind.
I'm glad if you add option that we can use seperated atomic coordinate file because GCEED developers are used to use such file, but this is no urgent task.

@mn2007 san, thank you for reviewing.
Probably, my explanation was bad. Even at this moment, you can employ an additional file for atomic coordinates by using &system/file_atom_coor as before. For example, you can add file_atom_coor='coo.dat' in your input and remove &atomic_coor.

I understood what you wanted to say just after I commented. It was my fault. Thank you for your implementation.


feat: Create grant methods

Feature description:
I create grant methods to give permissions depend on different actions.
grant methods:

[ ] Grant()
[ ] GrantReadData()
[ ] GrantWriteData()
[ ] GrantReadWriteData()

Testing:

[ ] Unit test for Grant()
[ ] Unit test for GrantReadData()
[ ] Unit test for GrantWriteData()
[ ] Unit test for GrantReadWriteData()
[ ] I built and deployed the CDK app in ./test/cdk-test-integration

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Description:
The latest update(commit name as "Update global-table.test.ts" and id: b2d4836) updates:

implement grant(), grantReadData(), grantWriteData(), grantReadWriteData() in src/global-table.ts and with corresponding unit tests in test/global-table.test.ts

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license


.editorconfig does not work wirh StyleCop categories

Documentation from Microsoft says that we can change severity for whole category. It work only for categories without dots (.) StyleCop rules contain dots in category names therefore it fails to be set. Real pain.
dotnet_diagnostic.category-StyleCop.CSharp.DocumentationRules.severity = error this will not work

@mavasani this seems like a bug in the compiler

@s-krawczyk @sharwell Can you file a bug on Roslyn repo?

Actually this works fine for me:

@s-krawczyk Which version of Visual Studio/compiler toolset are you using? NOTE: This needs VS2019 16.5 or later and compiler toolset 3.5.0 or later.


Cannot disable bad-import-yang-version

Thank you for making this extension!
I have YANG models that I am using with Cisco NSO (Network Services Orchestrator), and cannot disable bad-import-yang-version error.
I have set up my ~/.yang/yang.settings file like this:
{
  "yangPath": "/Path/to/ietf:/tailf/modules",
  "diagnostic": {
    "bad-import-yang-version": "ignore",
    "ambiguous-import": "ignore"
  }
}

I have also tried placing this same configuration into yang.settings at my project root.
Setting "ambiguous-import" to "ignore" works just fine, as those warnings are now disabled.
I currently have some "duplicate-name" errors in my YANG, and as an experiment, successfully changed/disabled those errors using yang.settings as well.
The bad-import-yang-version errors do not disappear until I explicitly put
module my-module {
    yang-version 1.1;

at the top of the module (which isn't usually necessary for Cisco NSO to infer the version).
Adding the explicit yang-version leaf at the top of the modules isn't a huge pain, but wanted to report this behavior. I am wondering if it is a bug, or if I should be using some other configuration.

Same for me

@Sparrow1029
Empty yang-version assumes version 1.0
This kind of validation bad-import-yang-version  and bad-include-yang-version is currently explicitly set to error and is not configurable.
I could change that, but I'm not sure yet if it can break the consistency of the LS.
https://datatracker.ietf.org/doc/html/rfc7950#section-12

Hello @dhuebner, I have a related issue on TypeFox/yang-lsp#228 where it is requested to refine the diagnostic to match the RFC, as it is allowed to import yang-version 1.1 models from yang-version 1.0 models as long as the import is not with a revision-date.
Also, this ticket was helpful, since I had struggled in isolation when trying to downgrade bad-import-yang-version to a warning severity, due to the false positive against the RFC compliant import behavior.

@esmasth
We need to make severity for bad-import-yang-version and bad-include-yang-version validation configurable. Unfortunately I don't have much time currently to implement this now.
Maybe you could talk to @RimShao to change the priorities, so we can work on this issue.

Thanks @dhuebner, I have discussed with Rim and this is rather an independent engagement from my side hence it should not not interfere. I may provide a draft PR for consideration, if welcome, for TypeFox/yang-lsp#228 when I get my development environment up and running.

Making validation configurable bei the user is pretty easy, see:
https://github.com/TypeFox/yang-lsp/pull/237#issuecomment-2009212302

Thanks @dhuebner . The other cases of using error(...) in yang-lsp seemed to be consistent with MUST/SHALL/... statements in the YANG RFCs on a quick check. Unless there's a motivation brought forth on why bad-import-yang-version and bad-include-yang-version need to be worked around, especially after the fix for TypeFox/yang-lsp#228, it would seem to me that configurability could be limited to SHOULD/RECOMMENDED/..., best practices, and inconsistent spec/implementation domain.

@esmasth
If you already have a list of  SHOULD/RECOMMENDED/ validation to make configurable, maybe you can provide a PR for that?

@dhuebner it would need a dedicated exercise to comb through the layers of RFC text to create that definitive list. I don't have that readily available for contribution, sorry.


Fix README pnpn -> pnpm

Fix typo and link to it

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Drop base64; always use hexadecimal strings for binary data

The parser will no longer be able to parse and decode base64 encoded strings in .glyphs files.
And the builder will always treat the userData as hexadecimal strings when decoding to/encoding from UFO data files.
See discussion in #352
Related issue #119
I think if DaMa has UFO files floating around with base64 data, they can easily write a simple script to re-encode them as hexadecimal strings.

FYI, I'll be away until Wednesday next week so I won't be able to finish this. Feel free to pick it up where I left.

I'm no longer sure about using bytearray here.
When I open a .glyphs file containing such binary user data in Glyphs.app, and I print the type of the loaded object from the Macro Panel, I get _NSInlineData, a subclass of NSData (as wrapped by pyobjc). This is an immutable byte buffer, more or less equivalent to python3 bytes object.
I'm thinking that maybe we could be strict with str vs bytes in glyphsLib parser and writer, and:

always return (unicode) str from the parser (which I think we already do, no?)
always interpret bytes objects as binary data (that must be serialized as hexadecimal strings) in the writer

If some python2 user sets some str bytes strings instead of using the correct unicode type, we could ensure they are decoded in the classes' setters.

It would be interesting to know where in the glyphs file format this hex-encoded binary data can happen. I mean, what fields expect it or allow it. Is it only in the userData values? If that's the case, then we could enforce the use of unicode strings for the userData values that are meant to contain text, and let any bytes values be encoded as hexadecimal strings; whereas, in other parts of the glyphs file, we could be more relaxed and allow ascii bytes str be implicity coerced to unicode, as the writer currently does.

I ended up defining a new BinaryData class in glyphsLib.types that subclasses bytes, and adds two additional methods: fromHex (classmethod constructor, used by the parser) and plistValue used by the writer.
@belluzj PTAL


Are invalid triplet added as training instances during training stage?

Hi, thanks for such excellent work!
In the Sentiment Relation Classification section, are negative samples, i.e. invalid triplet, added as training instances during training?
Looking forward to your reply!

Oh, I found that you utilize AdjacencyField and add 1 to relation labels when calculating the loss!


amstrongnumber.cpp

created a c++ program to detect 3 digit amstrong number

Thank you for your contribution @subho004

Place the files in right folder before initiating a PR.

What happened?  I didn't get it. This is my first time. I just followed
some YouTube guide.    Pls suggest something
On Mon, 4 Oct 2021, 8:39 am Abhilash M Nair, @.***>
wrote:

Place the files in right folder before initiating a PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/abhilashmnair/HacktoberFest2021/pull/13#issuecomment-933106803,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AV3GSQMYSJJMVPPRK2ADCETUFELG5ANCNFSM5FIKZ2CA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


docs: Update develop.md

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Jenkins test broken

Jenkins test was broken after the merge #260:
http://jenkins.db.cs.cmu.edu:8080/job/Peloton/101/
It failed when trying to build tests on release mode.

I believe @eric-haibin-lin is looking into this.

Cool.

The tests are running on jenkins but it is not generating the xml files for the results of the unit tests. So we are not able to see the test result history.
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing GoogleTest-1.6
[xUnit] [INFO] - [GoogleTest-1.6] - No test report file(s) were found with the pattern '**/tests/unit_*.xml' relative to '/var/lib/jenkins/jobs/Peloton/workspace' for the testing framework 'GoogleTest-1.6'.  Did you enter a pattern relative to the correct directory?  Did you generate the result report(s) for 'GoogleTest-1.6'?
[xUnit] [WARNING] - No test reports found for the metric 'GoogleTest' with the resolved pattern '**/tests/unit_*.xml'.
[xUnit] [INFO] - Skipping the metric tool processing.

http://jenkins.db.cs.cmu.edu:8080/job/Peloton/100/console
How do I enable gtest to output xml files?


Unable to remove multiple params using docrep.delete_params()

Hello,  thanks for this package - I'm finding it really helpful.
I'm not sure if this is a feature request, a bug, or unclear documentation, but I'm having trouble removing more than one parameter from the DocstringProcessor.
From the documentation:

The new docstring without the selected parts will be accessible as base_key + '.no_' + '|'.join(params), e.g. 'original_key.no_param1|param2'.

Here's my workflow so far.
import docrep
docstrings = docrep.DocstringProcessor()

@docstrings.get_sections(
    base='base_values',
    sections=docstrings.param_like_sections,
)
def my_base_func():
    ...

docstrings.delete_params('base_values.parameters', 'method')
# Make a copy because we don't want to delete 'base_period' from the main DocstringProcesser.
core_params = copy(docstrings)
core_params.delete_params('base_values.parameters', 'base_period')

@core_params.dedent
def new_func():
    """My new func.

    Parameters
    ------------
    %(base_values.parameters.no_base_period|method)s
    """
    ...

So my issue is that I'm following the docs to try and remove both parameters "base_period" and "method" but I've had no luck in doing that using the workflow described above. If it's an issue in my implementation rather than a bug, then a clearer example  in the docs for dropping multiple parameters would be much appreciated.
Additional point:

Having to first do .delete_params() and then add extra syntax in the docstring seems like duplication of work. What's stopping configuring the API so the user doesn't have to even call .delete_params() on the docstring processor, instead just specifying which parameters they want to keep directly in the docstring  such as "%(base_values.parameters.param1|param2)s".

Thanks

Hey @mitches-got-glitches !
In your case, you are modifying the do string twice, so the correct code is something like
docstrings.delete_params('base_values.parameters', 'method')
# Make a copy because we don't want to delete 'base_period' from the main DocstringProcesser.
core_params = copy(docstrings)
core_params.delete_params('base_values.parameters.no_method', 'base_period')

And then access it through the 'base_values.parameters.no_method.no_base_period' key.

Having to first do .delete_params() and then add extra syntax in the docstring seems like duplication of work. What's stopping configuring the API so the user doesn't have to even call .delete_params() on the docstring processor, instead just specifying which parameters they want to keep directly in the docstring such as "%(base_values.parameters.param1|param2)s".

I see your point. There should be an inplace parameter for the delete_params method. Would you like to contribute a PR?

Thanks for explaining @Chilipp, that's very useful. I can certainly consider a PR, it might  be a couple of weeks before I get a chance to dig into the source code. Would you like me to modify this issue to a feature request, or close and open a new one once I can describe the work to be done a bit better?

hi @mitches-got-glitches! no worries, I'll take care of it, it's really just a minor thing :smiley: I'll let you know
We can keep this issue here open


about flow accuracy

The accuracy of ucf101 (split 1) with flow is only 81%, but I used the official code to extract the flow. And the acc is 87% on the paper.Can you tell me what is wrong? @yjxiong

I can't. You have to add more details here.

in my experiment，my experiment accuracy is only 81%. i use 5e-3 learning rate,5e-4 weight decay , 200 and 300 epoch decrease learning rate with factor 10,stop at 350 epoch, use tvl1 flow, and pretrained with inception v2 in tensorflow , and my training accuracy is about 97% without parital batch norm.The result is wierd

Not sure how you implemented it in TensorFlow. This codebase is for PyTorch.

Hi, @imnotk , I now reproduce TSN use Tensorflow, But I have no idea about how to copy the mean of Parameters to first convolution layer, could you give me some suggestion ?

@Flyzanetothesky just repeat its mean value of channel


Some councils will be integrating with Verify at LOA1 level

The linked stable prototype should reflect this.
@EUzkuraityte Do you know which councils will be using which LOA?

@sanjaypoyzer for PP only Cambridgeshire volunteered to use LOA1 (but others have until Thurs to express their interest)

[ ] Cambridgeshire,
[ ] Oxfordshire,
[ ] Northumberland

@sanjaypoyzer please add Sunderland to the list. They just emailed us saying that they'd like to use LOA1


too complex

why not simply
Object.prototype.entries || Object.defineProperty(Object.prototype, 'entries', { // shim
    enumerable: false,
    value: function() { return Object.keys(this).map(k=>[k,this[k]]); }
});

Because then it would violate the spec. Every single line of code in the implementation is absolutely required for spec compliance.

If you try it out locally, you’ll see how many tests fail.


Enable train data cut

Description
This feature enables the control over the number of training data. This contains part of PR https://github.com/deepjavalibrary/djl/pull/2070
Note:
Here the batch indices obtained from Sampler the interface is
Iterator<List<Long>> sample(RandomAccessDataset dataset);
However, this is not convenient for training. Like in this case, the cut of training data set, ideally should be implemented without modifying the library. In the future, we can consider utilizing the rich NDArray indexing features and enable Iterator<NDArray> as the type of indices. This will allow more flexibility, desired in training/experimenting.

Codecov Report
Base: 72.08% // Head: 70.28% // Decreases project coverage by -1.80% :warning:

Coverage data is based on head (90cc15a) compared to base (bb5073f).
Patch coverage: 71.29% of modified lines in pull request are covered.

:exclamation: Current head 90cc15a differs from pull request most recent head afa684b. Consider uploading reports for the commit afa684b to get more accurate results

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2082      +/-   ##
============================================
- Coverage     72.08%   70.28%   -1.81%
- Complexity     5126     6085     +959
============================================
  Files           473      606     +133
  Lines         21970    26941    +4971
  Branches       2351     2917     +566
============================================
+ Hits          15838    18935    +3097
- Misses         4925     6579    +1654
- Partials       1207     1427     +220

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

.../ai/djl/modality/cv/translator/YoloTranslator.java
27.77% <0.00%> (+18.95%)
:arrow_up:

...modality/cv/translator/wrapper/FileTranslator.java
44.44% <ø> (ø)

...y/cv/translator/wrapper/InputStreamTranslator.java
44.44% <ø> (ø)

.../modality/cv/translator/wrapper/UrlTranslator.java
44.44% <ø> (ø)

... and 530 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Support for @u.rochester.edu email domains

[-] lib
      [-] domains
            [-] edu
                  [+] rochester
                        [+] u.txt

Adds support for @u.rochester.edu email domains at the University of Rochester.

I hope I didn't mess up the pull request like I did last time.

@JNSStudios I am sorry, the domain rochester.edu is removed from our trusted domains list because the school allows to register an email address there even if you are not a student of the school. If you are the student of this school, please apply with official document (OFFICIAL DOCUMENT tab at https://www.jetbrains.com/shop/eform/students).


failure should indicate why it failed

API should return the reason, why the check failed. This may help when the initial reason is not more the case. Example (not sure about exact syntax yet):
[
  {
    "name": "Test",
    "web": "http://localhost",
    "failed": true,
    "why": "Get <IP_ADDRESS> failed"
  },
]

We probably should introduce a limit on reason's length (also applies to match).

See PR #17
I have added a new field error which contains the related err message.


Funds not recoverable

Consider the situation where two clients have an open channel with some funds deposited. Now the client devices both crash in a way such that their data is not recoverable (i.e., the devices are destroyed), while the private key wallets still survive. In this case, there is currently no possibility for any of the clients to recover the deposited funds, as they need to provide a mutually signed channel state for that. Hence, the channel funds are stuck forever.
It could be desirable to extend the contracts so that a client can always register withdrawal of its initially deposited funds if it still has access to the private key corresponding to the channel account.

So you propose a new way of disputing a channel?
If we do not require a fully signed state; anybody could call this function. Even someone who is not part of the channel.
This would then force the honest participants to always refute the challenge, hence wasting gas. @matthiasgeihs

I propose a method that allows the depositor to register the channel.

I propose a method that allows a depositor to register the channel. Only participants of the channel should be able to initialize such a transaction.

When the client loses everything besides the SK, he would not be able to re-calculate the channelId or depositId.
He would have to query a node for the depositId of his last deposit.
Something like challengeDeposit(id) could work, which can be refuted with any fully-signed state.

When the client loses everything besides the SK, he would not be able to re-calculate the channelId or depositId. He would have to query a node for the depositId of his last deposit. Something like challengeDeposit(id) could work, which can be refuted with any fully-signed state.

We could make the channel ID recoverable if we let the deposit function take as input the channel ID and the participant address instead of the funding ID. Then we could emit these with a deposited event.