Grid align=stretch example not stretched

I haven't dug into the docs code to see if there's a quick fix, but for now just wanted to raise the issue. Comparison below between Mantine and Dash Mantine below:
Mantine
flex-start and stretch

Dash Mantine
flex-start and stretch

https://github.com/snehilvj/dmc-docs/blob/main/docs/grid/justify.py#L26
demo = dmc.Grid(
    children=[
        dmc.Col(html.Div("1", style=style), span=3),
        dmc.Col(html.Div("2", style={**style, "minHeight": 80}), span=3),
        dmc.Col(html.Div("3", style={**style, "minHeight": 120}), span=3),
    ],
    gutter="md",
)

Thanks for reporting, it has been fixed.


403 Error With Authentication , Without Authentication it is working fine.

After deploying the app to the cloud, it works fine without authentication, but enabling authentication leads to a 403 Forbidden error during the login process. This issue only occurs in the cloud environment, not locally. Any suggestions or guidance on resolving this would be appreciated.

You have to log in with your azure user account, top right. After this maybe you cannot receive any proper answer about your documents...


Upgrade guava to v18.0

Depends on #457. Fixes wiring problems with the new jclouds in Karaf.
jclouds 1.9.3 depends on guava [16-20), so it will bind to the latest version it finds - which is 18. And Brooklyn is stuck on 16.0.1. Bumping Brooklyn to 18.0 moves everything to depend on the same version of guava thus solving the wiring problems.
Note that guava-16.0.1 is still pulled in the Karaf distribution by jclouds. But is not loaded at runtime.

👍  looks good, will merge


Error:Failed to fetch gas estimate

My code:
let keystore = try! EthereumKeystoreV3(privateKey: "MyPrivateKey", password: "MyPassword")!
let name = "New Wallet"
let keyData = try! JSONEncoder().encode(keystore.keystoreParams)
let address = keystore.addresses!.first!.address
let wallet = Wallet(address: address, data: keyData, name: name, isHD: false)

let web3 = Web3.InfuraMainnetWeb3(accessToken: "fdde8c95e4704489aac3c8b014871980")
let contractAdddress = EthereumAddress("0x7a9E457991352F8feFB90AB1ce7488DF7cDa6ed5")
let keystoreManager = KeystoreManager([EthereumKeystoreV3(wallet.data)!])
web3.addKeystoreManager(keystoreManager)

let amount = "1.0"
var options = TransactionOptions.defaultOptions
options.value = Web3.Utils.parseToBigUInt(amount, units: .eth)
options.from = EthereumAddress(wallet.address)
options.gasPrice = . automatic
options.gasLimit = .automatic

let contract = web3.contract("MyABI", at: contractAdddress, abiVersion: 2)
let parameters = [EthereumAddress("0x000000000000000000000000000000000000000E"), Web3.Utils.parseToBigUInt(amount, units: .eth)] as [AnyObject]
let transaction = contract?.write("deposit",
                                               parameters: parameters,
                                               extraData: Data(),
                                               transactionOptions: options)

let result  = try transaction?.send(password: "MyPassword", transactionOptions: options)

In 'Web3+MutatingTransaction.swift' file, line 102, printing description of results:
expression produced error: error: /var/folders/z0/89zqhrn56hn16zv5y_h4vhlr0000gn/T/expr5-4bebed..swift:1:102: error: 'BigUInt' is not a member type of 'BigInt'
Swift._DebuggerSupport.stringForPrintObject(Swift.UnsafePointer<Swift.Array<PromiseKit.Result<BigInt.BigUInt>>>(bitPattern: 0x110307d20)!.pointee)
Please help me, THX!

Your passwords are not the same....

If "0x000000000000000000000000000000000000000E" is an address it needs to be EthereumAddress(whateverAddress).

@dangell7 Thanks！I have reedited my question, but I still get this error.

can I see the contract code?

Your putting the value of the transaction and the value of the parameters as the same...
Most likely you want one or the other? Or you wrote a bad sc.... You can always get the msg.value in the contract, so why are you passing the value in?

@dangell7 thank you for supporting this project and helping users. Feel free to apply for this bounty.
I want to release bounties for the pull requests and help to resolve issues like this. 👍

@AlleniCode Hey, is this still an issue for you? We recently merged a pr with a gas estimate fix into develop.
Could you please check it?

Authour of this issue haven't replied, so I suppose it was resolved and thus closing this issue.
To anyone still experiencing similar problems, feel free to reopen it.


the usage

Could you please tell me how to use the sam with napari? I confront this:

I have known how to use it by clicking middle mouse button


ButtonToggle: New Component

Summary
What changed?
New Component - ButtonToggle was added.
Why?
ButtonToggle is only used for buttons that have a selected/unselected state. They should not be used as directional/navigation elements.
Links

Jira
TDD
Figma

Checklist

[ Yes ] Added unit and Flow Tests
[ Yes ] Added documentation + accessibility tests
[ Yes ] Verified accessibility: keyboard & screen reader interaction
[ Yes ] Checked dark mode, responsiveness, and right-to-left support
[ Yes ] Checked stakeholder feedback (e.g. Gestalt designers, relevant feature teams)

@eniomoura Can we get tests to pass?

Can we add a Controlled component variant? Exactly like https://gestalt.pinterest.systems/web/datefield#Controlled-component


Output artifacts exposed in the Pipelines UI

Resolves #51
PR Checklist

[x] Tests added
[x] Changelog updated

Yep, there was a dependency between kfpclient and pipelines generator not separated in the unit tests. It should be fixed now

Yep, there was a dependency between kfpclient and pipelines generator not separated in the unit tests. It should be fixed now


Rename <InputLabel /> to <Label />

Our <InputLabel /> atom is just a styled HTML label.
It can be used to map both from inputs or other elements like select and textarea, hence it would be less confusing if we just name it as <Label />.
Otherwise might think from the name that's only meant to be used with <InputText />.

Addressed on the milestone/3.0 branch,  👀  PR above ☝


Use camel case consistently throughout the codebase

Description:
Reconfigure grpc services to use camel case throughout
Motivation and Context:
Codebase is annoyingly complex in some areas due the fact that the grpc services accept and return data in snake case yet we use camel case everywhere else in the codebase.
Fix #1911
How Has This Been Tested?
Manually + tests
Types of changes:
Refactor

Coverage decreased (-0.06%) to 22.434% when pulling 77362c19529e890fa7b53f910ec68b2b514d0f0d on mrfelton:refactor/grpc-case into ed035acd32ac3db21d1555e125dcd38e24198f66 on LN-Zap:next.


[feat] Enable Startup Hide All Windows

tauri_plugin_autostart
Hey👋, my current app has multiple windows, it shows all of them on manual startup, but I want to hide all of them on auto startup, how can I do this?

https://github.com/ayangweb/EcoPaste/pull/211
This is my current solution idea, it has no problem with windows and macos, linux I don't have a test machine and don't know what's going on!

The way you implemented it in https://github.com/ayangweb/EcoPaste/pull/211 is the correct way, closing this issue since there is nothing to do on our parts.


Fix message at the end of a survey to remove MyPreventiveCare

Fixed, will be ready for test in QA later today.


Body Index Map not properly transformed to colour camera

Describe the bug
Upon attaining the body index map from the body tracker, I convert it to the colour camera as shown here. Thereafter I go ahead and draw it out on the colour image for verification purposes but their seems to be an issue with the aspect ratio or some sort of offset since the map is never aligned to the person in the colour camera.
This is the body index map as seen from the colour camera space

But when I draw it directly on the colour image, this is the result

The problem becomes even more apparent when the body walks outside the depth camera's FOV as seen from the body index map in colour space shown below

and when drawn directly on the colour image, this is what I get

From this, it is evident that the body index map is not fully/properly transformed to the colour camera. Any ideas on how to resolve this?
I am using version 1.0.0 of the Body Tracking SDK with the following configurations
Colour Camera: K4A_IMAGE_FORMAT_COLOR_BGRA32, K4A_COLOR_RESOLUTION_1080P
Depth Camera: K4A_DEPTH_MODE_NFOV_UNBINNED
PS: I fully utilised the code samples for transformations and simply converted them to OpenCV Mat for visualisation

Hi @eshirima , thanks for posting this issue. When you draw the body tracking result on your color image, I will expect at least you won't see this color strip artifact... There seems to be something wrong with your drawing code instead of the body index mask. Could you share the code you use to draw the body index map?

@yijiew Thanks for the rather quick response. The artifact on the colour image is simply me colouring the mapped regions with a different pixel colour for differentiation as shown below. indexMap is the produced index map in colour camera space and colour is the raw RGBA image from the sensor.
Mat drawIndexMapOnColourImage(Mat indexMap, Mat colour)
{
	Mat result;
	colour.copyTo(result);

	for (size_t row = 0; row < indexMap.rows; ++row)
	{
		// grab first pixel in the row
		uchar* currentPixel = indexMap.ptr<uchar>(row);

		for (size_t col = 0; col < indexMap.cols; ++col)
		{
			if ((int)*currentPixel++ == 255) continue; // ignore background

			result.ptr<Vec3b>(row)[col][1] = 120;
			result.ptr<Vec3b>(row)[col][0] = 120;
			result.ptr<Vec3b>(row)[col][2] = 120;
		}
	}

	return result;
}

Hi @eshirima , one possible issue in your code is that the color image is BGRA format, which has 4-bytes per pixel instead of 3. But you are casting the color image to result.ptr. Could you try to change it to result.ptr and see whether it solves the problem?

Sorry @yijiew but I do not understand what you mean. Did you mean to say change it to colour.ptr? Correct me if I am wrong but regardless of the colour orientation, shouldn't the body map still correctly map to the colour camera? Isn't the problem stemming from the transformation itself and not the pixel orientation? Especially at the end, it is vivid that the map is not properly stretched out to fit the colour camera image as shown here. I converted the colour image to OpenCV Mat as shown here and simply changed the type to CV_8UC1 for the body map in colour space since it returns a single channel image.

Oh. My bad... I just realized that I missed the most important part in my instruction :P Try to change it to  result.ptr.

@yijiew your comment now makes more sense. And yes, that did solve the issue. I really appreciate it.


Fix/typo token & open manager button on instance & marketing footer

App Footer will show only when logged in, in the accounts ui pages

Make that a single line of Text. Remove Copy right symbol, z-index: 0 (to keep it behind things. Remove top gray border, transparent the background. Turn links the same color as text (so they are not blue)


Create bubble_sort.cpp

Good job !!! Thank you for contributing !!!😊

Hi Ayush,
Don't forget to change the repo tags to *hacktoberfest. *Otherwise, my
along with other contributors' PRs won't be counted towards
Hacktoberfest-22.
I think you were busy with things, so this is just a friendly reminder 😊
Thanks
Girija
On Tue, Oct 4, 2022 at 6:52 PM Ayush kumar @.***> wrote:

Good job !!! Thank you for contributing !!!😊
—
Reply to this email directly, view it on GitHub
https://github.com/Ayush0431/Data-structure-algoritms-hacktoberfest/pull/25#issuecomment-1266989861,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKFZBNBDPEGASJIMOD6R2ELWBQVPVANCNFSM6AAAAAAQ4QU54I
.
You are receiving this because you were assigned.Message ID:
<Ayush0431/Data-structure-algoritms-hacktoberfest/pull/25/c1266989861@
github.com>

--
Girija Nandan Kar
Phone: +91-8371095573
Email: @.***


Question: Are methods still supported?

Following the example noted in the tutorial, frb requires that methods be intentionally made public when implementing in api.rs.
impl SomeTrait for SomeStruct {
     pub fn do_something()...
}

However, the following error is expectedly thrown.
unneccessary visbility qualifier 'pub' not permitted here because it's implied
Is there something I am doing wrong here?

Self closing as I didn't know how to delete, and realized that methods couldn't be implemented via traits defined elsewhere.


Naming the axis in scatterplot

Is it possible to add the name of the variable along with the x and y axis? At the moment when we download the image it is not possible to understand which variable is assigned to which axis. Whereas if the variable names are there it will be more useful. This further can also be used in other distribution plots.

For now it's not possible, you should add it manually after the image creation.


Added Pre Build Event to Kill CEF Process

Added a pre-build event to kill the CefSharp.BrowserSubprocess that will lock the assemblies when debugging is stopped unexpectedly.

LGTM :+1:
Sorry it took so long for this, I'm quite picky :smile_cat:

Completely understand. This was an interesting and necessary learning experience in dealing with git.


Limit access to flynn API from inside a cluster (for cluster applications)

Applications run within Flynn are not fully sandboxed and have access to internal Flynn APIs that can be used to gain root access on the server. Do not run untrusted code in Flynn.

Is there any way to disable API access for applications?
Even if the code is trusted it can contain bugs, which means if somebody will do remote execution inside ANY app in the cluster he can do whatever he wants with the cluster, right?

Is there any way to disable API access for applications?

Not currently. I'm currently working on an authorization for all of the APIs.

Even if the code is trusted it can contain bugs, which means if somebody will do remote execution inside ANY app in the cluster he can do whatever he wants with the cluster, right?

Correct.

I'm currently working on an authorization for all of the APIs.
+1

@titanous is there any update on the sandboxing? My use case is letting students deploy apps in class without worrying about breaking the server. The deployment and sandboxing are really the only important things for me right now. Would you recommend trying to fit Flynn into this box, or is there something else we could use in the meantime?

@OmarShehata Security is a priority for us, though it will take a while to get to a point where you can run untrusted code in the way that you describe. You can track our progress here: https://github.com/flynn/flynn/projects/1

Flynn is unmaintained and our infrastructure will shut down on June 1, 2021. See the README for details.


A way to retrieve the validated data

Sometimes the input data object from a request has many fields that aren't allowed.
Is there a way to omit those fields not listed on rules object and retrieve the remaining ones after running validation?
Something like:
if (validation.passes()) {
  // Input data object clone without fields that aren't rule keys
  permittedParams = validation.output
  Model.create(permittedParams)
} else {
  // An object with fields from succesful rules (it would allow using the valid portion of the data)
  // Empty object when any required field was missing
  console.log(validation.output)
}

On Laravel docs it seems to be possible with
$validated = $request->validated()

I have created a helper function, I'm working on nested objects

export function validatedData(validator: Validator) {
  const { input, rules } = validator;
  const values = new Map();

  for (const attribute in rules) {
    if (typeof input[attribute] != 'undefined') {
      values[attribute] = input[attribute];
    }
  }

  return values;
}

Added in v3.5 using successes method

Added in v3.5 using successes method

@mikeerickson is successes released already? I couldn't find the method on v3.5.

@mikeerickson I've opened a new PR addressing this issue. https://github.com/mikeerickson/validatorjs/pull/444


Link to SharePoint Discussions Forums out of date

Hi,
The link in the 'Need Help' section at the end of this page to the 'SharePoint discussion forum' points to a now closed forum site.  This section should be updated to reference MS Q&A instead and link to https://docs.microsoft.com/en-us/answers/topics/office-sharepoint-online.html.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2f2abda5-9273-1a56-91b6-e4e77d5706b0
Version Independent ID: 6a85f2a5-b892-55f7-b49a-4ab15f1e8b73
Content: Control access from unmanaged devices - SharePoint in Microsoft 365
Content Source: SharePoint/SharePointOnline/control-access-from-unmanaged-devices.md
Service: sharepoint-online
GitHub Login: @kaarins
Microsoft Alias: kaarins

@Reeced40

@scanum this can be closed thanks.


is keyword extraction used?

what nlp techniques are used?

Hi @cosmo-001 ,
Could you please confirm which Tutorial you are referring to? Please provide more context. Thanks!


Add deployment id to zipdeploy event

Fixes https://github.com/microsoft/vscode-azureappservice/issues/2153
After messing with the kudu API endpoints, I realized that the response was coming back with the requested scm-deployment-id with our Kudu API call.  I couldn't tell you why-- it clearly states in the code that if the query parameter is false, to not add it, but it definitely is...
https://github.com/projectkudu/kudu/blob/2da32e6538ba90fa6bc1687dd2a31ca458027e2c/Kudu.Services/Deployment/PushDeploymentController.cs#L80
https://github.com/projectkudu/kudu/blob/2da32e6538ba90fa6bc1687dd2a31ca458027e2c/Kudu.Services/Deployment/PushDeploymentController.cs#L476-L480

The other change might help some of our timeouts.  The old logic works the same, but if we get the location url, it'll use that instead to ping the status of the deployment. There's a comment on their code that indicates not using it can cause the deployment to appear as if it timed-out so seems better to use the location url instead.

Deploy from zip url.   This may timeout depending on the size of zip file and load on the VM.

https://github.com/projectkudu/kudu/wiki/REST-API#zip-deployment

Depends on https://github.com/microsoft/vscode-azuretools/pull/1188

Gonna go ahead and merge this since stale approval dismissal sucks


Fixes an exception triggered by restoreState().

Please do not delete the branch; I can use it to submit a pull request to Jeremy.


Add confirmation warning for deletion of files

Summary
Add a confirmation/warning step when a user is about to delete OH files
Deadline
Feb 2023
What needs to be done?

[ ] Enact a warning (?page?) when request.user.openhumansmember.delete_single_file is called

Who can help?

@callummole
@helendduncan

Updates

That's probably obvious, but just waned to spell it out regardless in case it helps: To me both this and #406 are somewhat related in that the delete_single_file method will in either cases not be called directly from the front-end but in both cases this will probably be encapsulated in a view that reacts on a POST request.

I think this has been closed by #410?

Closed in #410


Error run mgatk

i am sorry to bother you.
My code is as follows
source ~/app/anaconda3/envs/mgatk/bin/activate
mgatk tenx -i /Sshare/tianchen/AML/3_sample_buce_merge/ZLH_10x_2/outs/possorted_bam.bam \
  -n ZLH -o ZLH_mgatk_50bp -c 8 \
  -bt CB -b /Sshare/tianchen/AML/3_sample_buce_merge/ZLH_10x_2/outs/filtered_peak_bc_matrix/barcodes.tsv

the error is as follows.
Fri Feb 11 16:21:19 CST 2022: mgatk v0.6.2
Fri Feb 11 16:21:20 CST 2022: Found bam file: /Sshare/tianchen/AML/3_sample_buce_merge/ZLH_10x_2/outs/possorted_bam.bam for genotyping.
Fri Feb 11 16:21:20 CST 2022: Found file of barcodes to be parsed: /Sshare/tianchen/AML/3_sample_buce_merge/ZLH_10x_2/outs/filtered_peak_bc_matrix/barcodes.tsv
Fri Feb 11 16:21:20 CST 2022: User specified mitochondrial genome matches .bam file
Fri Feb 11 19:25:14 CST 2022: Finished determining/splitting barcodes for genotyping.
Fri Feb 11 19:25:14 CST 2022: Genotyping samples with 8 threads
Error in checkGrep(grep(".A.txt", files)) :
  Improper folder specification; file missing / extra file present. See documentation
Calls: importMito -> checkGrep

the snakemake_tenx.log is as follows.
Building DAG of jobs...
Error: Directory cannot be locked. Please make sure that no other Snakemake process is trying to create the same files in the following directory:
/fshare2/tianchen/AML/mt_coverage/3_sample_mgatk
If you are sure that no other instances of snakemake are running on this directory, the remaining lock was likely caused by a kill signal or a power loss. It can be removed with the --unlock argument.

Can you send an ls -lRth of the output folder?

Can you send an ls -lRth of the output folder?

I have solved this problem. But a new phenomenon emerged. I have a sample that finds many G>C mutations using mgatk's method.

However, other samples did not show this phenomenon.

My sample is from the bone marrow of leukemia patients.  And the sequencing method is mtscATAC-seq. The sequencing is PE50.
mtscATAC-seq was performed according to the method of this article.
https://www.nature.com/articles/s41587-020-0645-6
Massively parallel single-cell mitochondrial DNA genotyping and chromatin profiling

Wild-- I've never seen anything like this. I'm not sure what even to suggest how to help-- this is very unusual.

I'm closing this issue now as I really don't have a comment but @tianchen2019 if you have anything else that you can uncover about this sample, do let me know


Are there more secure alternatives for ECU identifiers than supplier-name-prefixed serial numbers?

Is there a better way of identifying ECUs that would be inherently more secure (and/or more flexible) than supplier-name-prefixed serial numbers? Given that not all ECUs share the same resources (as @iramcdonald observed, "an ECU that does nothing but adjust the seat belt does not need symmetric cryptography"), what does an identifier actually need to share? The text should reference IEEE 802.1AR Device ID (see https://1.ieee802.org/security/802-1ar/), a standard that specifies Secure Device Identifiers (DevIDs) designed to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols. Stronger and clear text is needed as identity is too important to security to trust to just a part number.

@iramcdonald...please add, delete or modify text for clarity.

@iramcdonald...please add, delete or modify text for clarity.

Can someone review this issue and recommend a strategy to address this issue. Also, I'm assuming this is a 2.0.0 issue, but can someone confirm this and mark it as such a milestone?

Hi Lois,
Yes, this is definitely a v2.0.0 issue.
I still favor using IEEE 802.1AR Device Identity - which defines both
IDevIDs (immutable
manufacturer-supplied device identifiers) and LDevIDs (local device
identifiers generated by
a hash function from an IDevID and local network-specific context info -
these are mutable,
for example if a given ECU was moved from one vehicle to another vehicle).
TCG has new work-in-progress on TPM 2.0 Keys for Device Identity and
Attestation w/ device
certificates associated with IDevIDs and LDevIDs - coming to publication
soon.
Cheers,

Ira

Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
http://sites.google.com/site/highnorthincmailto: @.**
@.**>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434
On Fri, Apr 9, 2021 at 1:43 PM Lois Anne DeLong @.***>
wrote:

Can someone review this issue and recommend a strategy to address this
issue. Also, I'm assuming this is a 2.0.0 issue, but can someone confirm
this and mark it as such a milestone?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uptane/deployment-considerations/issues/86#issuecomment-816847397,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE33UO4JLUDSPVBWLT47NTLTH44DXANCNFSM4WEX3B4Q
.

At our 4/13 meeting, it was agreed we should add an "Emerging Issues" page to Deployment Best Practices that would address topics like this one where no definitive solution is on the horizon. PR # 104 opened a file for this page and @jhdalek55 will draft some initial text. In addition to this issue, the text will address Issue #162, #200,  and #201 on the Standards page.

Where are we at with this? We did include it in the Emerging Issues write-up, but how do we proceed with addressing the issue?

It was decided at the 8/3 Uptane Standards meeting that a Deployment entry should be drafted that would address the concept of secure identifiers and would encompass both issues #86 and Issue #87. Ira McDonald also suggested that we review the Standard document and make sure that we do not imply anywhere in the document that a serial number by itself is a secure identifier.

Issue #230 has been opened on the Standard issue as a reminder to make the necessary changes in policy once a clearer consensus on secure identifiers emerges. Therefore I am closing this issue and #87


Fix bundle2

This branch resolved the divergence issue in #119.

@pavlis Do you want me to merge it now or wait till you get the elog issue fixed too?

@pavlis Do you want me to merge it now or wait till you get the elog issue fixed too?


GCC 10 incompatability

Bug Description
Unable to compile lis and ldt (did not try with lvt but possibly affected) with GCC 10.
gfortran -c -pass-exit-codes -ffree-line-length-0 -O2   -fconvert=big-endian -DGFORTRAN -I/opt/lisf_libs/mod/modg/Linux.gfortran.64.mpiuni.default/  -I/opt/lisf_libs//include/ -I/opt/lisf_libs//include/  -I/opt/lisf_libs//include/  -I./ -I../lib/xmrg/ -I../params/VIC/ -I../USAFSI/ ../core/LDT_gfracMod.F90
../core/LDT_gfracMod.F90:478:65:

  478 |                        n, LDT_gfrac_struc(n)%gfrac%value(:,:,k) )
      |                                                                 1
Error: Missing actual argument for argument ‘_formal_8’ at (1)
make: *** [Makefile:108: LDT_gfracMod.o] Error 1

[ERR] Compile failed

Steps to Replicate
Compile LIS and LDT using gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 and GNU Fortran (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Solution
Add flag -fallow-argument-mismatch to lis and ldt compile scripts.
Additionaly add flag -fno-allow-invalid-boz for ldt. Due to errors in readSMOPSsmObs.F90
gfortran -c -pass-exit-codes -ffree-line-length-0 -O2   -fconvert=big-endian -DGFORTRAN -I/opt/lisf_libs/mod/modg/Linux.gfortran.64.mpiuni.default/  -I/opt/lisf_libs//include/ -I/opt/lisf_libs//include/  -I/opt/lisf_libs//include/  -I./ -I../lib/xmrg/ -I../params/VIC/ -I../USAFSI/ ../DAobs/SMOPS/readSMOPSsmObs.F90

Thank you for this bug report.  I successfully replicated the LDT compilation error with gfortran 10.1.0 on the NASA DIscover supercomputer running SLES 12.3.  I will investigate further.

Update:  The LDT compilation error also occurs with gfortran 11.1.0.

Thanks @emkemp .
Just wanted to update that additional flag for ldt  -fno-allow-invalid-boz might be -fallow-invalid-boz.  Please check.

Hi @pratiman-91
I think those extra flags may obscure a more serious bug.
The readgfrac function is implemented in C, and acts as a wrapper for a collection of Fortran subroutines; a particular Fortran subroutine is called based on the first argument (basically, the name of the dataset to be processed).  As I study the C code, I see a mismatch in the argument list.
Fortran is passing this:
call readgfrac( trim(LDT_gfrac_struc(n)%gfrac%source)//char(0),&
n, LDT_gfrac_struc(n)%gfrac%value(:,:,k) )
which is three arguments: a NULL-terminated string, an integer, and a real array.
The C function expects this:
void FTN(readgfrac)(char *j, int *n,float *array,float *marray,int len)
(The FTN business is just a macro for slightly renaming "readgfrac" based on whatever C naming convention the Fortran compiler expects; we can ignore this.)  The argument list has five arguments.  The first three correspond to the arguments passed by Fortran (the * indicates pointers, or passing-by-reference). That leaves two other arguments.
The comments in the C function indicate argument marray (the fourth argument) is optional.  But the compiler is not treating it that way, and I don't know why it should.  A rewrite may be necessary.
@jvgeiger @bmcandr @sujayvkumar  Thoughts?

Update:  I reviewed the underlying Fortran subroutines that can be called by readgfrac.  Only two of them (read_CLSMF25_gfrac and read_SACHTET356_gfrac) accept three arguments, and both of them treat the third argument as optional and never use it.  The remaining subroutines only accept two arguments (an integer and a real array).
I'm of the opinion that the two special Fortran subroutines should be changed to remove the third argument.  Also, the C wrapping code should be changed to reduce the pass-thru argument count to two.  Also, the readgfrac can have the fifth argument removed because it is never used.  Finally, the readgfrac function does not handle the case of an undefined greenness fraction dataset, so I will add some code for that as well.

Hi @emkemp:
Thank you for taking a closer look at these Fortran routines and the related C routines. If these are the only two Fortran routines for "gfrac" affected, I would agree with the approach that you outlined here.
Thanks!

Thank you @emkemp for such details. @karsenau I would like to add that there are multiple (5-7) instances in both LDT and LIS where I found the same compilation problem. Meaning, there could be multiple files that need to be verified.

Thanks for reporting that @pratiman-91.  If you have a list of when you encounter that issue, we would be happy to check and make any necessary updates.

Update:  The error reported by the compiler seems to be triggered by invocations of readgfrac with different numbers of arguments, and occurs before the C code is compiled.
I see the same error with calls to read_FLake_lakedepth, with different number of arguments.  In that case, the routine is written in Fortran (no C wrapping at all), but is not enclosed in a Fortran module -- thus, optional arguments are probably illegal, since the compiler can't check them without an interface block.
I'm guessing these recent gfortran versions are adding argument checks on their own, informing us of these problems.

Okay, my LDT revisions have expanded to four major directions:

Update gfrac and lai/sai Fortran read codes to use the same number of arguments (2).
Update the gfrac and lai/sai C codes to remove unnecessary arguments.
Update FLAKE code to ove read_FLake_lakedepth into FLAKE_paramsMode, allowing use of optional argument.
Modified readSMOPSsmObs to move usage of binary integer constants to DATA statements (standard Fortran does not allow for use with PARAMETERs, though ifort permits it).

...plus minor editorial changes.
The code compiles with gfortran 11.1.0, but further code clean-up is necessary; plus compilations with older GNU compilers and with Intel.  Also, I don't think I can actually run with gfortran 11.1.0 without recompiling all the external libraries.
An experimental branch is available for view at https://github.com/emkemp/LISF/tree/fix/ldt_arg_lists.  No pull request yet, it's not mature enough.

Thank you so much, @pratiman-91, for your help in compiling this list of routines affected with GCC 10.

I just submitted pull request #850 to address the problems with LDT.  Fixes for LIS (and LVT?) will be handled separately.

I replaced pull request #850 with #851, which targets the support/lisf-public-7.3 branch.

I've started reviewing LIS proper.  First problem is the use of readalbedo in LIS_albedoMod.F90.
The call signature in C is:
void FTN(readalbedo)(char *j, int *n, void *time1, void *time2, float *array1, float *array2,int len)
with len never being used.  The calls on the Fortran side are inconsistent.  I see:
call readalbedo(trim(LIS_rc%usealbedomap(n))//char(0),&
n,wt1,wt1,LIS_alb(n)%albsf1,LIS_alb(n)%albsf2)
which is mostly correct.  But then I see:
         call readalbedo(trim(LIS_rc%usealbedomap(n))//char(0),&
              n,t1,value1)
         call readalbedo(trim(LIS_rc%usealbedomap(n))//char(0),&
              n,t2,value2)

That's not correct.  I will fix.

Some more info:  The only Fortran routine called under-the-hood by readalbeo is read_ALMPIIIalbedo, which has a call signature of:
subroutine read_ALMIPIIalbedo(n, wt1,wt2,array1,array2)
where wt1 and wt2 are reals that represent weights.  But the two "bad" readalbedo calls are passing time indexes (t1 and t2), which are recalculated internally by read_ALMIPIIalbedo.
So, I am going to change the calls to all use wt1 and wt2 as reals.

Another problem is the reading of LAI data in LIS.  Unfortunately, this seems to be very broken.
The C function readlai uses this interface when calling Fortran:
current->func(n,time1,time2,array1,array2)
where the arguments are:
int *n, void *time1, void *time2, float *array1, float *array2
However, the underlying Fortran routines have very different argument lists:
subroutine read_ALMIPIIlai(n, wt1,wt2,array1,array2)
integer, intent(in) :: n
real                :: wt1
real                :: wt2
real, intent(inout) :: array1(LIS_rc%ntiles(n))
real, intent(inout) :: array2(LIS_rc%ntiles(n))
subroutine read_MODISlai(n, time1, array)
integer, intent(in) :: n
type(ESMF_Time)     :: time1
real, intent(inout) :: array(LIS_rc%ntiles(n))
subroutine read_MODIS_RT_lai(n, forward_search, array, file_time_stamp)
integer, intent(in)               :: n
logical, intent(in)               :: forward_search
type(ESMF_Time), intent (out)     :: file_time_stamp
real, intent(inout)               :: array(LIS_rc%ntiles(n))
The third call at least is probably not working correctly, since readlai will pass a float* for the file_time_stamp.  In any case, the calls to readlai will not compile with gfortran 10+ because the corresponding call signatures vary in LIS_vegDataMod.F90:
call readlai(trim(LIS_rc%uselaimap(n))//char(0),n,&
wt1,wt2,LIS_lai(n)%lai1,LIS_lai(n)%time1)
...
         forward_search=.false.
         call readlai(trim(LIS_rc%uselaimap(n))//char(0),n,&
              forward_search,LIS_lai(n)%lai1,LIS_lai(n)%time1)

         forward_search=.true.
         call readlai(trim(LIS_rc%uselaimap(n))//char(0),n,&
              forward_search,LIS_lai(n)%lai2,LIS_lai(n)%time2)

I think this requires a more serious redesign, perhaps using more modern Fortran constructs, e.g., Fortran 90 interfaces.

A correction:  The readlai calls involving 'forward search' are disabled by a #if 0 preprocessor statement.  It appears then that the
call readlai(trim(LIS_rc%uselaimap(n))//char(0),n,wt1,wt2,LIS_lai(n)%lai1,LIS_lai(n)%time1)
signature is the desired one, at least for ALMIPII data.

Hi @emkemp
I have been working on a fix to the LIS MODIS LAI RT code - see Issue #394
I have been meaning to come back to it.  Not sure if I will be able to in the next ~week, but can bump the priority.
David

Thanks @dmocko
SInce the MODIS_RT reader is broken (and I concur it is, based on the argument list mismatch), I think the default.cfg should be changed to disable MODIS real-time by default.
@jvgeiger @sujayvkumar  Thoughts?

Yes, - it should be disabled, until I have a fix to update to Collection 6.
The Collection 5 data is no longer available, I believe, and the current code (if it worked) would need this data to be pre-processed anyway by the MRT tool.

Okay, I'll add that to an upcoming pull request.

Whelp, GFORTRAN 10+ just found a bug in RDHM 3.5.6.
The source code in lis/surfacemodels/land/rdhm.3.5.6/sachtet is column-limited Fortran 77.  In htet_fland1.f, there is a call to pehman_ohd that extends past 72 columns, and is truncated by the compiler (line 647).  A different call further up is not truncated (different indentation), and the compiler noticed a different argument list between the two calls.
Simply changing the indentation by 2 columns fixes this bug.  I do wonder what affect this has on any science runs made with this code...

I just opened pull request #854 to fix problems with LIS 7.3.

I just opened pull request #855 to fix the compilation problems in LVT 7.3.  Fortunately this is small, just involving binary integer constants.

Looks like #851, #854, and #855 addressed the GCC10 compile errors. Can we close out this issue?

I have no objection to closing this issue.


[js] Tooltip for lables should prevent default on touch

To open a tooltip on a touch device one needs to touch the tooltip trigger. If this trigger is a label the touch event causes the default action of the label (i.e. click the input the label belongs to).

How to reproduce:
Consider this HTML
<form>
  <label for="myCheckbox">
    <span  class="has-tip" data-tooltip aria-haspopup="true" data-disable-hover="false" title="Tooltips are awesome, we should totally use them!">
      Touch me I'm a label
    </span>
  </label>
  <input type="checkbox" id="myCheckbox" />
</form>

Touch the label

What should happen:
Just the tooltip should pop up
What happened instead:
The tooltip pops up and the checkbox changes it's value.
Try it:
https://codepen.io/anon/pen/RVvGXz

This seems like an edge case. I'm not sure I'd recommend mixing labels that have for parameters with Tooltips. We should not change the default behavior of the label, which in this case is to change the checkbox value. I would recommend a different UI, perhaps an ℹ icon following the label which triggers the Tooltip.


test: enable PlaceTest and UnplaceTest on Windows

Fix: #550

@yegor256 please, check/merge

@rultor merge

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 10min)


Rails 5.1 compatibility

Hi @nathanvda !
I am trying to use cocoon with Rails 5.1 and cannot get it to work.
I still learning, but I think it's related with [ jquery + jquery_ujs ] used up to Rails 5.02 vs [ rails-ujs ] used in Rails 5.1.
Can you please give me some advice on this question?
Best regards!

Hi Peracchi, I'd advise that while you wait on Nathanvda, you check out this section here for trouble shooting the jquery with rails & cocoon ... https://github.com/nathanvda/cocoon/wiki/Trouble-shooting:-Jquery-issues

@peracchi  Just following up - were you able to use the guide to trouble shoot the issue or did you post to stackoverflow yet for general trouble shooting help?

@Mirv I still in the learning process, so for now I go back to Rails 5.02 to get the examples to to work. Thanks for asking! :)

If you open a stackoverflow with your exact error & copy of the controller, view's & models I'll take a quick peak & more than likely 5 people will pop up to help too!

I just successfully installed, configured, and integrated cocoon on Rails 5.1 so there doesn't seem to be an issue. Just needed to add jQuery to the application view template before any other JS: = javascript_include_tag "//cdnjs.cloudflare.com/ajax/libs/jquery/1.12.4/jquery.min.js" since Rails 5.1 no longer ships with jQuery installed by default.
Hope that helps!

Awesome thank you for testing this :+1:


When can a serializable enum be implicitly cast?

The specification states that "implicit casting from [a serializable] enum to its fixed-width (signed or unsigned) integer type" is supported in 8.3, but it is unclear when exactly that is doable. The spec shows that enum can be used as the left argument of bit shifts and the index of header stack access, so what about bit shift’s right argument, concatenation, unary operations, and bit slicing’s bitstring and indices?
After this is made transparent with either explanation or case-by-case rules, it should be probably re-emphasized or referenced in section 8.9.2 of implicit casts.
Example:
enum bit<8> E {
  e1 = 1,
  e2 = 2
}
E e = E.e1;
bits<8> x = e << 3;    // Allowed in the spec
bits<8> y = 8w0 << e;  // Unclear
bits<16> z = e ++ 8w0; // Unclear
bit<8> w = -e;         // Unclear
bit<4> u = e[3:0];     // Unclear
bit<4> v = 8w0[4:e];   // Unclear

Based on the spec, the expression in the initialization of x is allowed, but whether the expressions on e in the following initializations are legal is unclear.

I tested these examples in the BMV2 compiler, and the last three expressions are invalid.
enum bit<8> E {
  e1 = 1,
  e2 = 2
}

control compute(inout hdr h) {
    apply {
        E e = E.e1;
        bit<8> x1 = 8w0 << e;
        bit<8> x2 = -e;
        bit<4> x3 = e[3:0];
        bool x4 = 8w0 == e;
        bit<8> x5 = 8w0 | e;
        // bit<8> x6 = e << 3;     // Allowed in the spec; but not in BMV2: "<< left operand of shift must be a numeric type, not E"
        // bit<16> x7 = e ++ 8w0;  // BMV2 error: "Concatenation not defined on E and bit<8>"
        // bit<4> x8 = 8w0[4:E.e1];   // BMV2 error: "bit indexes must be compile-time constants"

For x6, it seems to be a problem with the compiler since shifting an enum field is a valid example in the manual.
For x8, it still seems to be a problem with the compiler since enum field is compile-time known as stated in 17.1.
For x7, it does not really make sense to prohibit it given that BMV2 allows implicit casts in shift (example x1).
Overall, I think the implicit casts of serializable enum should probably be allowed everywhere.

One more thing to note is that if I change from e to E.e1, more expressions failed in the BMV2 compiler
        // bit<16> x1 = 16w0 << E.e1;
        // bit<8> x2 = -E.e1;
        // bit<4> x3 = E.e1[3:0];

with the same error: E.e1: expected an integer value, leaving only x4 and x5 still valid.
Again, I think it is more likely a problem with the compiler.


request values struct during request context

Codecov Report

Merging #198 (1198c6b) into main (8200c03) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 1198c6b differs from pull request most recent head 1615eee. Consider uploading reports for the commit 1615eee to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #198   +/-   ##
=======================================
  Coverage   36.91%   36.91%
=======================================
  Files          14       14
  Lines        1070     1070
=======================================
  Hits          395      395
  Misses        625      625
  Partials       50       50


fix: fix code scanning alerts

Problem
Fix code scanning alerts and add deps-dev to scope-enum for dev dependencies update from dependabot
Solution

Additional Notes

Links
Ticket

GitHub issue:
Other links
Verification
Manual tests

Automated tests

[ ] Unit tests added/updated
[ ] E2E tests added/updated
[ ] N/A - (provide a reason)
[ ] deferred - (provide GitHub issue for tracking)

Housekeeping

[ ] No non-essential console logs
[ ] All new files contain license notice

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (2b911b2) 93.86% compared to head (ad12fa8) 93.86%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1155   +/-   ##
=======================================
  Coverage   93.86%   93.86%
=======================================
  Files         150      150
  Lines        6114     6114
  Branches     1838     1838
=======================================
  Hits         5739     5739
  Misses        357      357
  Partials       18       18

Continue to review full report in Codecov by Sentry.

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


Update to nimib 0.3 and nimibook 0.3

Nimib 0.3 is yet unreleased but before release I want to make sure scinim/getting-started will continue to work.

Something I'm noticing in the preview is that there are square brackets [] surrounding content of each page and code blocks and images are surrounded by commas ,. Feels like some artifacts from a list. Do you know what this might originate from?

Yep, noticed too and found the reason yesterday. In nimib I changed the part of template that renders the block from
{{&blocks}}

to
{{#blocks}}
{{&.}}
{{/blocks}}

We need to change that in nimibook too, started to work on it but finished my allotted time. Should have more time today.

work in nimibook has started. fix was very small but I am also doing a lot of much needed maintenance there: https://github.com/pietroppeter/nimibook/pull/50

putting also a fix for latex for units but note that the $..$ in line latex is not converted. in fact it is not supported by mathjax, see https://rust-lang.github.io/mdBook/format/mathjax.html (although there it also says that $$ is not supported but it seems to work)

the work on this PR is done, except that it is currently depending on the development versions of nimib and nimibook. Once I have the official releases I will update the dependencies.

putting also a fix for latex for units but note that the $..$ in line latex is not converted. in fact it is not supported by mathjax, see https://rust-lang.github.io/mdBook/format/mathjax.html (although there it also says that $$ is not supported but it seems to work)

The way I read it is that it's a mdBook problem, and not a MathJax problem. Also I would prefer if nb.useLatex enables this so that all themes activate latex the same way.

The way I read it is that it's a mdBook problem, and not a MathJax problem. Also I would prefer if nb.useLatex enables this so that all themes activate latex the same way.

could be. agree that it would be better to use a unique interface among themes, it should not be hard to support it indeed in the same way we do it in nimib, I will see if I am able to while documenting and releasing

now latex should use latex and activated in the standard way, taking advantage of the recent change in https://github.com/pietroppeter/nimibook/pull/52, see also https://pietroppeter.github.io/nimibook/latex.html

what do you think of also changing all chapters that do not contain nim code to markdown? it should be basically all index.nim. It should make the CI slightly faster and the result would be the same.

what do you think of also changing all chapters that do not contain nim code to markdown? it should be basically all index.nim. It should make the CI slightly faster and the result would be the same.

I won't say no to a faster CI 😎 and it feels unlikely that we will put any actual Nim code in them in the foreseeable future.

done.

unlikely that we will put any actual Nim code in them in the foreseeable future
if we do it is easy to get back to nim files.

Thanks!

if we do it is easy to get back to nim files.

Indeed :)

Should we merge this ? @HugoGranstrom approved it and it seems finished.

the thing is that neither nimib nor nimibook have officially released the 0.3, that is why here we install from head.
It was something I was supposed to do and then merge this, then I had a long period of not being able to work on nim stuff and I am catching up now. Releasing nimib 0.3 and nimibook 0.3 is now top of my list of priorities so I guess this could probably wait a little bit more time.

and to be honest what is lacking for release of nimib 0.3 and nimibook 0.3 is essentially documentation. I could in principle tag and update documentation later... let's say that if by this weekend I do not complete the documentation part I will just tag what is there. and then I will update this pr with correct versions and we could merge.
the relevant open issues that I need to tackle are:

https://github.com/pietroppeter/nimibook/issues/51
https://github.com/pietroppeter/nimib/issues/85

I think what we are waiting for is for nimib and nimibook 0.3 to be released. But it should be fine depending on #head as we do for now and change it once they are released

or we could do it like that, but we risk of breaking nimib/nimibook head and this would implicitly break this...

and to be honest what is lacking for release of nimib 0.3 and nimibook 0.3 is essentially documentation. I could in principle tag and update documentation later... l

No pressure, I just wanted to know the status of the PR before it becomes stale and we forget

yes, sure. indeed it started having conflicts with main (since @Vindaar added the ecosystem overview). I did resolve the conflict and merge the change. incidentally I changed the way that section was added (instead of section(name, filename): discard a normal entry(name, filename)). Now at least it will make another run of CI and preview... although I think merging conflict I added to the TOC the overview line and I did not merge with recent master, so I would expect it to fail... urgh!

Yeah, no need to rush it just for the sake of it. I'm not very up to date on how nimiBook is working nowadays but I could help writing some documentation for nimib at least when I'm done with my nbCodeToJs PR.

I just had a look at the preview and didn't see anything out of order. :+1:

I also gave a look and did not find anything strange.
At some point with the new default we could change the documentation comments in standard comments.
An unrelated issue I noticed is that there is no arrow for next in chapter 6.2.2

fair enough.. I am so late on everything! 🙄

although actually the CI broke on not finding some .log file... :(
looking into this

Ah sorry I assumed everything was fine after asking in interal coms since it hadn't moved for a while and preview looked fine.
I should have consulted you as well

No, this is fine. The issue in CI the end is not linked to this PR, but likely to the fact that an updated version of a library broke a chapter. We probably could have a periodic CI (eg running every weekend) so that we catch this thing early


Run tool plugins against all files at once when possible.

Significantly speeds up many of the tool plugin runtime durations.

Codecov Report

Merging #28 (bf3ced5) into main (a06f08a) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #28   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          271       270    -1
=========================================
- Hits           271       270    -1

Impacted Files
Coverage Δ

...tooling/plugins/tool/dockerfilelint_tool_plugin.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Optical Flow computation

Could you specify which is the frame stream (left or right) used to compute optical flow?

The optical flow is calculated based on the left frames. And it is the per-pixel motion from frame t to frame t+1, aligned with the RGB image at time t.

The optical flow is calculated based on the left frames. And it is the per-pixel motion from frame t to frame t+1, aligned with the RGB image at time t.


Unignore certain JS file

@garrettmflynn Let's see if it still complains

[error] src/renderer/src/stories/JSONSchemaForm.js: Error: Comment "Check self" was not printed. Please report this error!

Does that make any sense?

[error] src/renderer/src/stories/JSONSchemaForm.js: Error: Comment "Check self" was not printed. Please report this error!

There's an inline comment in that file with that text—though I have no idea why it would trigger an error.
Can you point me to where I can inspect this error myself? I couldn't see it in the pre-commit.ci details—though I may be looking in the wrong place

I imagine running pre-commit run --all-files should do what the bot is doing, but not 100% sure

@CodyCBakerPhD This is such a weird error—but I was able to get rid of it


The option --scope is not supported by docker network create

The doc is incorrect in listing the option --scope for docker network create command
File: engine/reference/commandline/network_create.md, CC @mstanleyjones

The CLI reference is generated using Docker 17.06, in which --scope is definitely a supported flag. If you're not using 17.06, please use the doc archive for the Docker version you are using. See https://docs.docker.com/docsarchive/ to choose your archive link. Thanks!


LiveScripts, Scripts and Functions

I created a live script file (.mlx) for the enzymatic catalysis example. I think that these live scripts are very cool, especially for explaining, but they have some disadvantages: Debugging is more complicated (or: less possible), and I had the impression that they have an overhead for computation time, but didn't test it particularly... Moreover, the plotting interface works differently, plots are displayed after they are finished, refreshing und updating plots seems not to work. So having ONLY a live script is maybe not the best idea, since also compatibility is not ideal...
I would suggest having for each example a live script AND a function version of the main file. The function is more flexible, the live script a (very) nice add-on. But PESTO should also work without them...

Not being able to update the plots is really a problem for the examples. Seems others were facing the same problem https://stackoverflow.com/questions/39231098/live-script-with-animation . So then back to regular scripts or functions, I guess. I really would have like the cleaner looks...

Since the LiveScripts are new, maybe they will be more powerful in the future... we can think of adding some of them, since they are really nice for comments. We can ask Jan, how we should proceed with that...

We may aim at liveScripts in a later version. For now we don't take the effort, since liveScripts also have some drawbacks: Plots are not updated, while a script part ist evaluated, meaning that dynamical updates for plot are not possible.


Chore/tweaks for v1

I'm going to push changes to this PR over the next few days / week in preparation for releasing v1.

@track0x1 I'm running into a problem with the reset-values example. Would you mind taking a look at it? Just run yarn examples, open up http://localhost:8080/reset-values/index.html and click the "Reset" button -- I can't figure out why the checkbox disappears. I've been trying to debug this for 2 days.
I'm thinking about using "defaultChecked" in Checkbox.js but will need to wait for react v15.6.2 since there's a bug at the moment

@aesopwolf Looks like its caused by the behavior of the browsers <form> API

type reset: The button resets all the controls to their initial values.

The problem is that in a field like a checkbox, you have to actually change the value of the checked attribute to check/uncheck it, which removes our initial state that would otherwise be used by reset() provided via form API.
Easiest solution is to avoid using reset button type and switch it to something like type="button".

Wow... I have no words. Thank you so much. I was going crazy.

It's been a while since I've touched this. I'm just going to merge it in to the beta branch as is and open up more PR's as need be.


Capability resolving

Describe the issue
The configuration for resolving dependencies does not specify any capabilities, therefore when an ambiguous set of capabilities is found by Gradle, the dependency cannot be resolved
Steps to reproduce
[libraries]
foundation = "androidx.compose.foundation:foundation:1.5.4"

Stacktrace
Cannot choose between the following variants of <Info>androidx.compose.foundation:foundation:1.6.0-beta03</Info>:
  - desktopRuntimeElements-published
  - releaseRuntimeElements-published
All of them match the consumer attributes:
  - Variant 'desktopRuntimeElements-published' capability androidx.compose.foundation:foundation:1.6.0-beta03:
      - Unmatched attributes:
          - Provides <Info>org.gradle.category 'library'</Info> but the consumer didn't ask for it
          - Provides <Info>org.gradle.libraryelements 'jar'</Info> but the consumer didn't ask for it
          - Provides <Info>org.gradle.status 'release'</Info> but the consumer didn't ask for it
          - Provides <Info>org.gradle.usage 'java-runtime'</Info> but the consumer didn't ask for it
          - Provides <Info>org.jetbrains.kotlin.platform.type 'jvm'</Info> but the consumer didn't ask for it
  - Variant 'releaseRuntimeElements-published' capability androidx.compose.foundation:foundation:1.6.0-beta03:
      - Unmatched attributes:
          - Provides <Info>org.gradle.category 'library'</Info> but the consumer didn't ask for it
          - Provides <Info>org.gradle.status 'release'</Info> but the consumer didn't ask for it
          - Provides <Info>org.gradle.usage 'java-runtime'</Info> but the consumer didn't ask for it
          - Provides <Info>org.jetbrains.kotlin.platform.type 'androidJvm'</Info> but the consumer didn't ask for it

This is only the case if there are no plugins applied that declare capabilities (like the kotlin jvm plugin etc), so it might not be a huge issue for the common case.


monopod to enforce README per image, regen all README.md files

This allows us to enforce READMEs per each image to show all available tags etc.

outstanding TODO to simplify some of the duplicated code here

LGTM, but it might be worth getting someone who knows Go and our workflow better to take a look before merging.


Assets/Avatars/Adults/Male_Adult_18/Textures/m023_head_normal.tga is broken

https://github.com/microsoft/Microsoft-Rocketbox/blob/8046857/Assets/Avatars/Adults/Male_Adult_18/Textures/m023_head_normal.tga is not a valid TGA file:
> file Assets/Avatars/Adults/Male_Adult_18/Textures/m023_head_normal.tga
Assets/Avatars/Adults/Male_Adult_18/Textures/m023_head_normal.tga: data

In contrast, other .tga files are valid:
> file Assets/Avatars/Adults/Male_Adult_18/Textures/m023_body_normal.tga
Assets/Avatars/Adults/Male_Adult_18/Textures/m023_body_normal.tga: Targa image data - RGB 2048 x 2048 x 24

Fixed it! let me know if you can try it. Thanks


Update pom.xml

$subject

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/7501140909

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/7501140909
Status: success


This project is working but seems outdated. Which fork to use?

I found different forks in the issues here and I ask myself, which one to use. All seems to have implemented the FlatList instead of ListView to address certain problems.

@riyga25 https://github.com/riyga25/react-native-modal-dropdown
@marshallshen https://github.com/BuildU/react-native-modal-dropdown
@siemiatj https://github.com/siemiatj/react-native-modal-dropdown

3 seems to be mostly updated. 2 seems to be more up to date than 1.
From this point of view, I would go with @siemiatj's version?
There is an open issue, created one month ago: https://github.com/sohobloo/react-native-modal-dropdown/issues/247 Is this a blocker?

Looks like it. Will fix it later today.

@siemiatj Perhaps it's better to create a new repo and not a fork, since it's not possible to open issues there.
Also, I am not able to run the example. Is it possible to upgrade the example to 0.62.2?

@donni106 Thanks for the list.
@siemiatj Thanks for this version. It works.
Everyone, I being a newbie, it wasn't easy for me to install a PR. This is how to install @siemiatj's version:
npm install --save https://github.com/siemiatj/react-native-modal-dropdown

@siemiatj Perhaps it's better to create a new repo and not a fork, since it's not possible to open issues there.
Also, I am not able to run the example. Is it possible to upgrade the example to 0.62.2?

Created a clone repo (same url) and will use that from now on.

Thanks @siemiatj. And you kept the old fork for history here: https://github.com/siemiatj/react-native-modal-dropdown-legacy
I will create an issue in the new one.

We should change the conencted repository on npm packages to @siemiatj's one.
It would be easier to install and other people will find the updated repository faster.
Has anybody expericence with npm registry? Is this even possible to contact them to change a package repository?
Current here: https://www.npmjs.com/package/react-native-modal-dropdown

We should change the conencted repository on npm packages to @siemiatj's one.
It would be easier to install and other people will find the updated repository faster.
Has anybody expericence with npm registry? Is this even possible to contact them to change a package repository?
Current here: https://www.npmjs.com/package/react-native-modal-dropdown

I believe repository is simply taken from repository field of package.json of the published package. Also there can't be two packages of the same name. I thing what you're asking for is @sohobloo to either remove the package from npm (so it can be published by @siemiatj), or somehow hand it over. Or... rename it.

I think it'd be easiest to just create a new npm package as @sohobloo seems to have abandoned this ship. But I'll try to reach out to both him and npm first.

@Bilal-Abdeen Thanks a lot for suggestion. It works!
@siemiatj Thanks a lot for this version. Please maintain this version.
I added it in my project and it works! Thanks a lot!

Thanks, @siemiatj . If you can't update this package by contacting npm, you really should upload your version as a new package.

I've just upgraded my app to RN 0.63 and added the @siemiatj version - all works apart from nothing happens when I select a row - any ideas what's causing that?

Updating the options dynamically shows loading icon instead of the updated options.

@siemiatj Updating the dropdown options dynamically shows loading icon instead of the updated options.

I've just upgraded my app to RN 0.63.2 and added the @siemiatj version - all works apart from nothing happens when I select a row - any ideas what's causing that?

Had the same problem.
I removed TouchableOpacity that was wrapping my component passed to renderRow prop.

Try this, added support for right component / dropdown icon as well
https://github.com/Kishanjvaghela/react-native-modal-dropdown

@Kishanjvaghela do you want to provide your new features as PR to https://github.com/siemiatj/react-native-modal-dropdown?

@siemiatj any news about the npm package? It feels like it's time to move on. Not trying to push, just showing interest for this thing to be sorted out.

Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

Please update the following components: %s, ModalDropdown

Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.
Please update the following components: %s, ModalDropdown

@tim92109 Please read the comments (or the topic of the discussion you are posting to) first. This project is outdated. Most actively maintained fork can be found here: https://github.com/siemiatj/react-native-modal-dropdown

@kub1x ok thx

@kub1x ok thx

Just wanted to let you know that I successfully took over the npm package and published a new version under the same name.

Awesome @siemiatj !  Stoked to use it again

Hello guys, is there any way I can know which option is selected at a given moment ? I've been struggling , haven't figured it out yet

Hello guys, is there any way I can know which option is selected at a given moment ? I've been struggling , haven't figured it out yet

You can use the onSelect prop and pass a method, for example a setter for a state variable, that you can use elsewhere. Please have a look at the examples, where you can find usages in dropdown_4, dropdown_5 and dropdown_6. Hope that helps.

Hello guys, is there any way I can know which option is selected at a given moment ? I've been struggling , haven't figured it out yet

You can use the onSelect prop and pass a method, for example a setter for a state variable, that you can use elsewhere. Please have a look at the examples, where you can find usages in dropdown_4, dropdown_5 and dropdown_6. Hope that helps.

Thanks for the help, got it.

Anyone here now ? Why I can't add Icon into input field in spite of I have used renderRightComponent like this

Can you solve this problem


Problem about coursesectionclass

Does a coursesection have two coursesectionclass at most?

Does a coursesection have two coursesectionclass at most?

No, a section can have (almost) infinite amount of classes.


Update pip install executable in command

#851  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @carolineechen and the rest of your teammates on  Graphite


fix(comment): hmr broken docs link

update rspack webpackHot docs link 😄

 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.


Legacy mappings don't handle the variant without the 'draft-' prefix.

This is related to #62
The existing production service for bibxml-ids recognizes 'foo-bar-baz' as an alias for 'draft-foo-bar-baz'. The current dev service does not.
See these (which return the same thing):
http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-sparks-sipcore-multiple-reasons-00.xml
http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.sparks-sipcore-multiple-reasons-00.xml
At dev.bibxml.org, the analogous link for the first URL above succeeds. The second fails.

The datatracker also recognizes these variants - see https://datatracker.ietf.org/doc/bibxml3/reference.I-D.sparks-sipcore-multiple-reasons.xml

This is related to #63 (in progress).

It doesn’t seem like reference.I-D.sparks-sipcore-multiple-reasons-00.xml exists here: https://github.com/ietf-ribose/bibxml-data-archive/tree/main/bibxml3/reference.I-D.sparks-sipcore-multiple-reasons-00.xml
So this is why fallback isn’t working.
I believe it should be helped when #63 is implemented, but I wonder why we don’t have that file🤔

It is in the sync point I provided (are you using it)?, and available from the datatracker...
% rsync rsync.ietf.org::bibxml-ids/reference.I-D.draft-sparks-sipcore-multiple-reasons-00.xml
-rw-r--r--         904 2022/01/14 11:02:47 reference.I-D.draft-sparks-sipcore-multiple-reasons-00.xml

% curl -s https://datatracker.ietf.org/doc/bibxml3/draft-sparks-sipcore-multiple-reasons-00.xml | grep title
      <title>Multiple SIP Reason Header Field Values</title>

Ahah - no. Note that the draft-<foobar> variant is present, but not the foobar variant. That is something you should just look for if the string after .I-D. doesn't start with draft-.

Specifically, I don't think #63 will help you here unless you adjust the scope of #63.

Well, the 63 might work in a way where we ask Datatracker any time we can't find a document, which would catch cases like these, although ideally it should only be used for new drafts and we should resolve the already existing ones without an extra request.

This is fixed now with new resolution logic. Both variants with and without the draft- prefix should work.
(However, it could be a problem that our bibxml data archive repository does not contain these path variants, I wonder if I should file a separate issue about xml2rfc path resolution tool having to support these aliases even if they aren’t listed separately in the archive.)

The ship sailed already - there are many references of that form in the draft archive.
For now, we have to.
In the long run, I expect we will deprecate the 'draft-'less versions altogether, but that will require community guidance.

The draft-less and number-less names have always been used to reference the series
The names with draft- prefix and -## suffix have always been used to reference the exact draft
Those are the only versions that were ever advertised as valid -- nothing else.

I did  confirm that the redirect did not do sufficient error checking for invalid names.

That's not particularly relevant to the reality of them being used. They are, and that's the clench-end of this decision.

no, I checked:
These are the only files that I see:
-rw-rw-r-- 2 henrik staff 1044 Aug  9  2018 reference.I-D.farmer-6man-exceptions-64.xml
-rw-rw-r-- 2 henrik staff 1133 Jan  6  2019 reference.I-D.farmer-6man-routing-64.xml
-rw-rw-r-- 2 henrik staff 1564 Sep 16  2009 reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml
-rw-rw-r-- 2 henrik staff 1218 Dec 18  2017 reference.I-D.ietf-tsvwg-ieee-802-11.xml
-rw-rw-r-- 2 henrik staff 1116 Mar  7  2007 reference.I-D.mahy-sipping-16.xml
-rw-rw-r-- 2 henrik staff 1017 Feb  7  2006 reference.I-D.songlee-aes-cmac-96.xml
-rw-rw-r-- 2 henrik staff 1138 Nov 29  2012 reference.I-D.srinivasan-fr-over-mpls-with-frf-16.xml
-rw-rw-r-- 2 henrik staff 1461 Jun 24  2016 reference.I-D.szigeti-tsvwg-ieee-802-11.xml
-rw-rw-r-- 2 henrik staff 1404 May 15  2019 reference.I-D.zhang-mif-api-extension-802-21.xml

and all of those -## are NOT the version numbers. For example,
$ ls *farmer-6man-exceptions*
reference.I-D.draft-farmer-6man-exceptions-64-00.xml  reference.I-D.draft-farmer-6man-exceptions-64-02.xml  reference.I-D.draft-farmer-6man-exceptions-64-05.xml  reference.I-D.draft-farmer-6man-exceptions-64-09.xml
reference.I-D.draft-farmer-6man-exceptions-64-01.xml  reference.I-D.draft-farmer-6man-exceptions-64-03.xml  reference.I-D.draft-farmer-6man-exceptions-64-06.xml  reference.I-D.farmer-6man-exceptions-64.xml

$ ls *ietf-16ng-ip-over-ethernet-over-802-dot-16*
reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.xml  reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.xml  reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml
reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08.xml  reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-11.xml
reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-09.xml  reference.I-D.draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12.xml

From the draft archive:
rjsparks@undex draft % ls -1t | egrep 'xml$' | xargs -n1 grep -H 'reference.I-D.' | grep -v 'reference.I-D.draft-' | egrep "\-[0-9][0-9].xml[^:]"
draft-spaghetti-idr-deprecate-8-9-10-00.xml:            <?rfc include="reference.I-D.ietf-idr-bgp-open-policy-18.xml"?>
draft-ietf-sidrops-rpki-rsc-05.xml:        <reference anchor="I-D.ymbk-sidrops-rpki-has-no-identity" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ymbk-sidrops-rpki-has-no-identity-00.xml">
draft-abhishek-coin-xr-edge-cloud-00.xml:<!ENTITY I-D.draft-defoy-coms-subnet-interconnection-04 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.defoy-coms-subnet-interconnection-00.xml">
draft-ietf-tsvwg-transport-encrypt-21.xml:<!ENTITY I-D.ietf-6man-ipv6-alt-mark SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-alt-mark-00.xml">
draft-farmer-6man-routing-64-02.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-farmer-6man-routing-64-01.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-farmer-6man-routing-64-00.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-jjmb-httpbis-trusted-traffic-00.xml:<!ENTITY IDSRH SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.I-D.ietf-6man-segment-routing-header-07.xml">
draft-ietf-bfd-seamless-use-case-02.xml:<!ENTITY I-D.geib-spring-oam-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.geib-spring-oam-usecase-04.xml">
draft-yourtchenko-colitti-nd-reduce-multicast-00.xml:<!ENTITY I-D.vyncke-6man-mcast-not-efficient-01 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vyncke-6man-mcast-not-efficient-01.xml">
draft-ietf-v6ops-v4v6tran-framework-02.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-ietf-v6ops-v4v6tran-framework-01.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-ietf-v6ops-v4v6tran-framework-00.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-carpenter-v4v6tran-framework-00.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-moskowitz-hip-rfc5201-bis-02.xml:<!ENTITY fundamental-ecc SYSTEM "http://medon.htt-consult.com/~rgm/hip/reference.I-D.fundamental-ecc-03.xml" >
draft-ietf-v6ops-isp-scenarios-00.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-carpenter-v6ops-isp-scenarios-02.xml:<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
draft-perkins-behave-dpinat-00.xml:    "http://www.psg.com/~charliep/txt/sourceIP/reference.I-D.source_IP-NAT.txt-00.xml">
draft-fajardo-dime-misc-app-test-suite-01.xml:'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fajardo-dime-base-test-00.xml'>
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06.xml:<!ENTITY ETHCS PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml" >
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.xml:<!ENTITY ETHCS PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml" >
rjsparks@undex draft % ls -1t | egrep 'xml$' | xargs -n1 grep -H 'reference.I-D.' | grep -v 'reference.I-D.draft-' | egrep "\-[0-9][0-9].xml[^:]" | grep -v 'dot
-16'
draft-spaghetti-idr-deprecate-8-9-10-00.xml:            <?rfc include="reference.I-D.ietf-idr-bgp-open-policy-18.xml"?>
draft-ietf-sidrops-rpki-rsc-05.xml:        <reference anchor="I-D.ymbk-sidrops-rpki-has-no-identity" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ymbk-sidrops-rpki-has-no-identity-00.xml">
draft-abhishek-coin-xr-edge-cloud-00.xml:<!ENTITY I-D.draft-defoy-coms-subnet-interconnection-04 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.defoy-coms-subnet-interconnection-00.xml">
draft-ietf-tsvwg-transport-encrypt-21.xml:<!ENTITY I-D.ietf-6man-ipv6-alt-mark SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-alt-mark-00.xml">
draft-farmer-6man-routing-64-02.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-farmer-6man-routing-64-01.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-farmer-6man-routing-64-00.xml:<!ENTITY I-D.farmer-6man-exceptions-64 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.farmer-6man-exceptions-64.xml">
draft-jjmb-httpbis-trusted-traffic-00.xml:<!ENTITY IDSRH SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.I-D.ietf-6man-segment-routing-header-07.xml">
draft-ietf-bfd-seamless-use-case-02.xml:<!ENTITY I-D.geib-spring-oam-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.geib-spring-oam-usecase-04.xml">
draft-yourtchenko-colitti-nd-reduce-multicast-00.xml:<!ENTITY I-D.vyncke-6man-mcast-not-efficient-01 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vyncke-6man-mcast-not-efficient-01.xml">
draft-moskowitz-hip-rfc5201-bis-02.xml:<!ENTITY fundamental-ecc SYSTEM "http://medon.htt-consult.com/~rgm/hip/reference.I-D.fundamental-ecc-03.xml" >
draft-perkins-behave-dpinat-00.xml:    "http://www.psg.com/~charliep/txt/sourceIP/reference.I-D.source_IP-NAT.txt-00.xml">
draft-fajardo-dime-misc-app-test-suite-01.xml:'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fajardo-dime-base-test-00.xml'>

sorry - editing the above to trim to the last run.

$ ls -l reference.I-D.ymbk-sidrops-rpki-has-no-identity-00.xml
ls: cannot access reference.I-D.ymbk-sidrops-rpki-has-no-identity-00.xml: No such file or directory
the references may exist, but they are not pointing at anything

nor have they ever resolved to real files

sigh

allowing them introduces an ambiguity in the naming scheme :(

I'd really prefer fixing the redirector to not handle those anymore and tell the 10 authors to fix their drafts

I see no more ambiguity than we already had.

before, you knew that if the prefix "draft-" was not present, any trailing -## HAD to be part of the name and not a generation number

and if draft- WAS present, a trailing -## HAD to be a generation number

Please reopen this. Despite Tony's misgivings, the following are both expected to work
https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-stir-certificates.xml
https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-stir-certificates.xml
Currently only one does.

As per @TonyLHansen :

I'd really prefer fixing the redirector to not handle those anymore and tell the 10 authors to fix their drafts

Is this perception no longer the case? If there are only a limited of people doing this, it might work better to ask them to switch instead of having to maintain a new pattern...

Yes, I meant it.
The goal will definitely be to support both patterns, as the datatracker already does so. Are you saying this is going to be exceptionally difficult for the bibxml service? (The intent was it would serve what the datatracker serves).
More globally, the naming pattern without "draft-"  introduced another bit of "magic knowledge" that authors would need to know to be able to function to avoid a difficulty we inflicted on ourselves with allowing things that looked like version numbers in names.
Yes, it's extra code to deal, but it's nicer for the authors in the long run to not have to know about the magic tricks.

The problem is with the I-Ds that have names that already end in 2 digits as @TonyLHansen provided examples above in
https://github.com/ietf-tools/bibxml-service/issues/110#issuecomment-1043823506
Given the existence of these identifiers, the service cannot distinguish whether I-D.ietf-tsvwg-ieee-802-11  is  "draft 11" or the name of the unversioned identifier.
This means the service would not be 100% consistent in resolution and will be extremely confusing to the authors.

yes, I recognize that and pointed it out myself earlier. It means checking heuristics to see if prefixes of things that end in -nn are existing drafts.
The pain of confusion then shifts to an edge case that we do not have in the draft namespace right now, and that we aren't going to allow to happen. The damage expresses only if we allow names to come into existence where we have both 'draft-whatever' and 'draft-whatever-11' as actual draft names. Again, we don't have this in the dataset right now, so the heuristics always succeed and authors are not confused.
The datatracker handles this in the following places:
The primary logic is at https://github.com/ietf-tools/datatracker/blob/main/ietf/doc/views_doc.py#L1013
To understand it in context, you need to be aware of
https://github.com/ietf-tools/datatracker/blob/main/ietf/doc/views_doc.py#L999
and
https://github.com/ietf-tools/datatracker/blob/main/ietf/doc/urls.py#L103 (and 104).


[WIP] Use mapping format for reading date values

Signed-off-by: Yury-Fridlyand<EMAIL_ADDRESS>Description
The fix is to collect formats from mapping and pass it to OpenSearchExprValueFactory.
I added mapping2 member to IndexMapping and OpenSearchExprValueFactory which hold required data. The original mapping is not removed yet to ensure that everything works as was before.
Test data
date_formats.json.txt
date_formats_mappings.json.txt
curl -s -XDELETE "http://localhost:9200/date-formats?pretty"
curl -s -H 'Content-Type: application/json' -XPUT "http://localhost:9200/date-formats?pretty" --data-binary @date_formats_mappings.json
curl -s -H 'Content-Type: application/json' -XPOST "http://localhost:9200/date-formats/_bulk?pretty" --data-binary @date_formats.json

Test queries
select * from date-formats;
select <format> from date-formats where name = '<format>';

search source=date-formats;
search source=date-formats | where name='<format>' | fields <format>;

For example, epoch_second (was reported on forum)
opensearchsql> select epoch_second from date-formats where name = 'epoch_second';
fetched rows / total rows = 1/1
+-------------------------------+
| epoch_second                  |
|-------------------------------|
| 1984-04-12 09:07:42.000123456 |
+-------------------------------+

Unsupported formats
weekyear
strict_weekyear
weekyear_year
strict_weekyear
year
strict_year
year_month
strict_year_month

(see links below)
They fall back to error: https://github.com/Bit-Quill/opensearch-project-sql/blob/f335101253b52395b3cccf161cc79b34f6dac80b/opensearch/src/main/java/org/opensearch/sql/opensearch/data/value/OpenSearchExprValueFactory.java#L258-L261
Time interpreting issue
https://github.com/Bit-Quill/opensearch-project-sql/blob/f335101253b52395b3cccf161cc79b34f6dac80b/opensearch/src/main/java/org/opensearch/sql/opensearch/data/value/OpenSearchExprValueFactory.java#L254
goes to https://github.com/Bit-Quill/opensearch-project-sql/blob/f335101253b52395b3cccf161cc79b34f6dac80b/core/src/main/java/org/opensearch/sql/data/model/ExprTimeValue.java#L62
There is no option to access queryContext there.
This could be fixed by one of

Returning ExprTimeValue
Applying time value on top of Epoch or any other fixed date. Note - this should be consistent across the plugin.

TBD

What to do with LocalTime?
What to do with unsupported formats?
Can we return not ExprTimestampValue for date and time columns? Note: ensure that entire column has the same or similar format(s).

TODO

See TODO comments in code
Fix SQLCorrectnessIT with query SELECT Cancelled, AvgTicketPrice, FlightDelayMin, Carrier, timestamp FROM opensearch_dashboards_sample_data_flights. Test results - Class org.opensearch.sql.sql.SQLCorrectnessIT.pdf
Wrong data returned for timestamp, mapping "format" : "yyyy-MM-dd HH:mm:ss"

Links

Formats documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html#built-in-date-formats
Formats code: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/common/time/DateFormatters.java

Issues Resolved
https://github.com/opensearch-project/sql/issues/794
https://forum.opensearch.org/t/sql-select-fails-on-date-fields-format-epoch-second/11521
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Superseded by #273


Add grpc-prefixed package generation script

Related: https://github.com/grpc/proposal/pull/177 https://github.com/grpc/grpc/pull/21531
This PR adds a generation script to generate all grpc-prefixed package with the behavior described in the gRFC.

Packages uploaded to PyPI and manually tested.


Does EChartOption.backgroundColor only support string?

Version
4.5.0
Steps to reproduce
I use typescript with echarts. I want to copy this case: https://gallery.echartsjs.com/editor.html?c=xEyDk1hwBx，however,  it throws error. I lookup the index.d.ts,  the backgroundColor only support string！But, in the https://www.echartsjs.com/zh/option.html#backgroundColor，tells me also support object to achieve gradient color. How can i use gradient color?
What is expected?
How can i use gradient color?
What is actually happening?
I don't know how to do

Maybe you can refer to this article to solve this issue!

@yufeng04
Thankyou very much! It does effect!
But, in order to solve this issue, i have to add type assertion in many places.
Ok, Let's do that first.


Add Android High Performance Programming book

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
This adds a link to an unofficial book under "official documentation"


Please add my work

Zero To Mastery - Canvas 2022 🎉🎉
👉 RainBow Canva 👈
PR contains:

New Rainbow Canva artwork.

Breaking changes

No breaking changes

Screenshots

Please consider closing this PR and follow the contributions guide exactly. At the moment you have completely removed and re-added every single contribution and sub-directory. I don't think we can accept this. @Kajanan02


Disable subtitles

Hi,
Is there a way to enable/disable the subtitles track?
Thank you in advance.

Here's a tentative fix: https://github.com/ZeBobo5/Vlc.DotNet/pull/102

PR #102 is merged, closing this


fix(chatbar): use typing indicator from State

What this PR does 📖

fixes a bug introduced in the chats refactor.
the typing indicator should once again appear on the chatbar.

Which issue(s) this PR fixes 🔨

Resolve #

Special notes for reviewers 🗒
Additional comments 🎤

@phillsatellite the chatbar is using the exact same typing indicator (from state) as the sidebar. did you check out the correct branch? the picture shows the behavior before the fix and I tested on Linux and mac 13.x.


Translate tasks/access-application-cluster/ingress-minikube into Japanese

Closes #22985.

Page preview: https://deploy-preview-22987--kubernetes-io-master-staging.netlify.app/ja/docs/tasks/access-application-cluster/ingress-minikube/
/assign @inductor

/cc @oke-py

/lgtm

/approve


Colors

This isn't done yet as it has some bugs. Pretty pictures:
Derived from "Mariana" scheme

Derived from "Blue Thunder" scheme

Derived from "Breakers" scheme

I've been fudging with getting the foreground and background colors switched because as you can see, for some reason it selects the background while it should select the foreground.

There is a bug/feature of add_region: if the background of the scope is exactly the same as the background of the theme. The foregound and background colors would be inverted.
That's why the theme background is #000000 while the scope backgrounds are #000001

Thanks, I never would have guessed the problem was there. add_regions foils my plans yet again ;)

Things are starting to look okay now. I'll have to think of another way to represent terminalview.black_black though.

Starts to work pretty good now:

One problem I have is that there's supposed to be a ninth color called "default", but pyte doesn't seem to care about that:

What is the expected result for the default color? Isn't it showing white color now?

How do think the idea of generating settings like
'terminal_color_0'  : '#000000',
'terminal_color_1'  : '#ff8787',
'terminal_color_2'  : '#87d75f',
'terminal_color_3'  : '#ffd75f',
'terminal_color_4'  : '#87afff',
'terminal_color_5'  : '#af87ff',
'terminal_color_6'  : '#d7ff87',
'terminal_color_7'  : '#bfbfbf',
'terminal_color_8'  : '#000000',
'terminal_color_9'  : '#ff8787',
'terminal_color_10' : '#87d75f',
'terminal_color_11' : '#ffd75f',
'terminal_color_12' : '#87afff',
'terminal_color_13' : '#af87ff',
'terminal_color_14' : '#d7ff87',
'terminal_color_15' : '#bfbfbf',

and applying them to TerminalView in run_time? It will give much more controls to users.

I think that's okay, but I worry for the startup time. Would that be noticeable?

If we only do it once until Sublime Text restarts, it should okay.

Very interesting - while personally I like the black/white scheme it is definitely nice that it can adapt to user color scheme. I'll just wait a bit with pulling this until we have 0.5 out then we can look into including this for 0.6 :+1:

Yeah, I'm aiming for 0.6 for this PR.

A few notes after testing this:
I ran into a bit of trouble since I don't have any dark blue color in my color scheme (I think). My light blue was used for cyan and magenta was used for blue (thus magenta was not visible):

I still like this approach but I'm worried about it giving users an inconsistent experience. Maybe TerminalView should ship with a default color scheme similar to what we have now + a few alternatives that can be selected through settings (like maybe a light version with white background). Among the alternatives this could be one of them - a sort of auto color scheme.
Another concern I have if we were to use this as default color scheme is that it doesn't set TerminalView apart from the rest of ST3. I think it's a good thing to have a somewhat different color scheme (atleast as default) since it signals to the user that it's not like the rest of ST3 (different keybindings etc.).
What do you think ?

I'm okay with this being an optional setting in the settings. Preferences differ from person to person and I like my terminal to look like any other view.
For the magenta being black, I think the function extracted only 5 colors and added a black color to get six (see here). Furthermore it then assigned "magenta-ish" to the blue reference color because blue just so happens to come before magenta. The magenta-ish color should have been assigned to the magenta reference. I think that's a bad idea now and I'd like to change the algorithm so that it can better handle schemes with few colors.
Can you put your color scheme in a gist so I can experiment with it?

Color scheme: https://gist.github.com/Wramberg/4c3701579a5c18b581f3f1df4fb521b1
Keep up the nice work - this is quite a cool feature :-)

Just to give an update: cie2000 works now, but it gives basically the same results as cie1994.
Also, your color scheme has 11 colors, so the problem is not that it has too few colors. The problem is actually that while it looks like the magenta color is black, it's actually fairly close (a distance of about 30 units, 15 units is "very close"). The problem is that it is also happens to be very close to the background color. My idea is to check the distance to the background color, and if it's "too close" to the background, change the lightness somehow to account for that. For this, I need to be able to convert from L*a*b* back to RGB, so I'll have to implement those conversion functions.

Thank you for the feature.
It wouldn't hurt to write in readme that you need to restart sublime in order for the changes to take place.
I finally read it from this pull request after almost giving up :P

Hi @johanson, glad you like it. I never got around to finishing this, because it needs a few things still:

It should be optional.
Probably should use the newly introduced .sublime-color-sheme format instead of the old .tmTheme format.

Like @Wramberg I'm occupied with work these days, I'll see if I can find the time to pick this up some day again.


Fix steplist bug in check_manifest()

Steplist defvalue is [], so we shouldn't compare to None to check if it's unset.
This change uncovered a few other hidden bugs which I've fixed:

Need to set the steplist in test_check_manifest(): since we're only setting up two steps here, we need to set the steplist accordingly.

Setting a steplist before calling the local _runtask() in remote_preprocess() - this one's a bit more complex. From the commit message body:
Another bug hidden by the check_manifest() steplist issue. In this case,
only the local step is set up before remote_preprocess() calls
_runtask(), so we need to override the steplist to force it to only
check the local step. This feels a bit hacky, but it shouldn't be
dangerous since we already overwrite the steplist for the remote run
immediately after.
I also snuck in a separate bugfix - it seems like the _runtask() call
needs to be outside of the if statement, otherwise the local step will
not run if the local step runs a builtin function.

Looks good!


CCO Infrastructure dashboard queries/bugs

Dear @josunefon,
Thanks for your effort in building this dashboard.
Could you please fix these errors.
1.From the overview section-->Subscription owners details. As discussed, count of the owners details in the visualization of Subscription owners not reflecting correctly. Can you please fix this?
2.Can you help me understand what this count is here( 171 highlited)? This is from NSG tabs

Based on name of the visualization, I am assuming this count may be the count of ACLs/rules count part of NSG. Please confirm? If this is part of NSG then i am wondering we don't have 170+ rules for any NSG. If they are not acls please help us know of these?

When it comes to RBAC i think we have RBAC permissions, I understand these are the users details scoped under subscription level. Can we reflect the user details that are part of tenant level as well?

Looking forward to hearing from you on this.
Thank you,
Warm regards,
Mahes.

Already fixed, now we're showing the data from the correct table "RBAC Role SP, Users and Groups"

This number is the count of all the rules for each NSG

This feature is not available yet


Setup Travis

For build & test automation.

This file can be used as a reference, it just needs some small tweaks to make it work with this repo. I've already enabled this repo in Travis, so once the config file is added everything should run.

Fixed in ca52b0035878b759c21551a8a5503456ec58e102


 There is no ./configure and no instructions in the README for initial setup. Thank you!

The entire project is just a python script with a bash wrapper. Place taapcrunchyroll-bot in /usr/bin and place the python files in /usr/lib/taapcrunchyroll-bot/
After installing you'll need to configure $HOME/.config/taapcrunchyroll-bot/taapcrunchyroll-bot.conf. I'll update the readmore to include more details how what the variables mean.
Feel free to let me know if you have any questions/concerns/suggestions

Thank you for your response. I did as you said and it seems I may be missing some dependencies or something. I should also mention that I made a slight change to the Python file; instead of sys.argv[1]   and sys.argv[2] for user/pass, I put some strings into variables (my own user/pass) and used those, so the line numbers are a bit off in a few places. Here is the bash output:

numberOfGroups '1'
getCredentialsScript '0'
updateUserInfoScript '0'
errorScript '0'
killTime '43200'
/usr/bin/taapcrunchyroll-bot: line 37: 0: command not found
Obtaining guest pass for  of Group 1
/usr/local/lib/python3.6/dist-packages/selenium/webdriver/phantomjs/webdriver.py:49: UserWarning: Selenium support for PhantomJS has been deprecated, please use headless versions of Chrome or Firefox instead
warnings.warn('Selenium support for PhantomJS has been deprecated, please use headless '
/usr/lib/taapcrunchyroll-bot/crunchyrollGuestPassFinder.py
43200
2018/05/15 15:21:23: starting bot
2018/05/15 15:21:23: attempting to login to<EMAIL_ADDRESS>Traceback (most recent call last):
File "/usr/lib/taapcrunchyroll-bot/crunchyrollGuestPassFinder.py", line 174, in
crunchyrollGuestPassFinder=CrunchyrollGuestPassFinder(user, passwd)
File "/usr/lib/taapcrunchyroll-bot/crunchyrollGuestPassFinder.py", line 35, in init
self.login()
File "/usr/lib/taapcrunchyroll-bot/crunchyrollGuestPassFinder.py", line 46, in login
self.driver.find_element_by_id("login_form_name").send_keys(self.username)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 353, in find_element_by_id
return self.find_element(by=By.ID, value=id_)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 957, in find_element
'value': value})['value']
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 314, in execute
self.error_handler.check_response(response)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/errorhandler.py", line 208, in check_response
raise exception_class(value)
selenium.common.exceptions.WebDriverException: Message: Error - Unable to load Atom 'find_element' from file ':/ghostdriver/./third_party/webdriver-atoms/find_element.js'
pyhton exited with error code 1