could not open disk image /dev/vghost/vol1: Image is not in qcow2 format

Version Reports:
Distro  version of host:
Centos7
Terraform Version Report
(Provided by running terraform -v.)
0.11.7
Libvirt version
virsh --version
3.9.0
terraform-provider-libvirt plugin version (git-hash)
 git log
0.4.2

Description of Issue/Question
Setup
(Please provide the full main.tf file for reproducing the issue (Be sure to remove sensitive info)
variable "domain_name" {
  type = "string"
}

variable "hypervisor" {
  type = "string"
  default = "aaa.in"
}

provider "libvirt" {
    uri =<EMAIL_ADDRESS>}

resource "libvirt_volume" "base_vol" {
  name = "${var.domain_name}_base_vol"
  source = "/home/jenkins/output-images/centos7-base"
}

resource "libvirt_volume" "base_disk" {
  name = "${var.domain_name}_base_disk"
  base_volume_id = "${libvirt_volume.base_vol.id}"
}

resource "libvirt_volume" "vol1" {
  name = "vol1"
  # vghost is a lvm storage pool
  pool = "vghost"
  size =<PHONE_NUMBER>0
  format = "raw"
}

resource "libvirt_domain" "terraform_test" {
  name = "${var.domain_name}"
  disk {
    volume_id = "${libvirt_volume.base_disk.id}"
    scsi = "true"
  }
  disk {
    volume_id = "${libvirt_volume.vol1.id}"
  }
  vcpu = "1"
  memory = "2048"
  running = "true"
  network_interface = {
    bridge = "br1"
    hostname = "${var.domain_name}"
    # wait_for_lease = 1
  }
  autostart = "true"
}

Steps to Reproduce Issue
(Include debug logs if possible and relevant.)
terraform init
terraform apply -var domain_name=test

Additional Infos:
The storage pool used is based on lvm:
pool = "vghost"
It seems that it always uses format qcows in the disk scope in the domain definition.
Error: Error applying plan:

1 error(s) occurred:

2018/08/15 00:57:34 [DEBUG] plugin: waiting for all plugin processes to complete...
* libvirt_domain.terraform_test: 1 error(s) occurred:

* libvirt_domain.terraform_test: Error creating libvirt domain: virError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2018-08-14T22:57:34.437492Z qemu-kvm: -drive file=/dev/vghost/vol1,format=qcow2,if=none,id=drive-virtio-disk1: could not open disk image /dev/vghost/vol1: Image is not in qcow2 format')

Do you have SELinux or Apparmor/Firewall enabled? Some special configuration?
Have you tried to reproduce the issue without them enabled?
Yes

Thanks for the report. I think the provider lacks logic in terms of what format to use given storage pool types.
Can you share a working domain definition? Do you need to specify the format or will libvirt automatically detect/select the right one? If we confirm that libvirt is smarter than I think, we may actually remove setting/hardcoding the format.
Sent with GitHawk

Hello,
A bit of framing: There is a LVM volgroup /dev/vghost. A VM shall get a logical volume in there as disk. The volgroup was added as storage pool via virsh pool-define-as 'vghost' 'logical' --target '/dev/vghost'. It is running and active:
$ virsh pool-list
 Name                 Status     Automatischer Start
-------------------------------------------
 default              Aktiv      ja
 [...]
 vghost               Aktiv      ja

The Terraform run @mjiao mentioned created the volume:
$ lsblk
NAME                                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                                     8:0    0  5,5T  0 disk
├─sda1                                  8:1    0    1M  0 part
├─sda2                                  8:2    0  768M  0 part /boot
└─sda3                                  8:3    0  5,5T  0 part
  ├─[...]
  ├─vghost-vm_jenkins.netzwerk.host   253:8    0  100G  0 lvm
  └─vghost-vm_openshift.netzwerk.host 253:15   0  100G  0 lvm

A working manual domain creation would look as follows (took a Jenkins test VM as example):
$ sudo lvcreate --name 'vm_jenkins.netzwerk.host' --size '100G' 'vghost'
$ sudo virsh pool-refresh 'vghost'
$ sudo virt-install --connect qemu:///system --hvm --graphics spice --noautoconsole \
  --name=jenkins.netzwerk.host --description 'The Jenkins' --os-type linux \
  --os-variant centos7.0 --arch=x86_64 --vcpus=2 --ram=4096 --check-cpu --cpu host \
  --network bridge=br4,model=virtio --cdrom=/var/lib/libvirt/iso/CentOS-7-x86_64-Minimal-1804.iso \
  --disk vol=vghost/vm_openshift.netzwerk.host,cache=none,bus=virtio

Resulting in
$ virsh dumpxml jenkins.netzwerk.host | less
[...]
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/vghost/vm_jenkins.netzwerk.host'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
[...]

Ok, this seems to be the relevant part of the documentation:

Valid pool format types
The logical volume pool supports only the lvm2 format, although not supplying a >format value will result in automatic selection of the lvm2 format.
Valid volume format types
The logical volume pool does not use the volume format type element.

So I guess we could fix it by not passing any format. However, I am suspicious of the XML dump, given that the volume was created by the provider code that mostly assumes that we are dealing with a dir pool and qcow2 files.
Reading libvirt documentation I notice there is a source="volume" supported since 0.8.7 that I suspect may help in referring to a volume in a pool in a more standardized way across pool types, instead of hardcoding something like file=. I will test once I get access to my laptop in a few days (on iPad right now).

Thanks for your reply @dmacvicar . In addition to the info provided by @andreashaerter, here is info regarding the successful and failed cases:
Success case
The following is an example of a working domain terraform code and its xml dump (only a Packer baked image is used as base of volume creation).
resource "libvirt_volume" "base_vol" {
  name = "${var.domain_name}_base_vol"
  # The centos7-base is in qcow2 format
  source = "/home/jenkins/output-images/centos7-base"
}

resource "libvirt_volume" "base_disk" {
  name = "${var.domain_name}_base_disk"
  base_volume_id = "${libvirt_volume.base_vol.id}"
}
resource "libvirt_domain" "terraform_test" {
  name = "${var.domain_name}"
  disk {
    volume_id = "${libvirt_volume.base_disk.id}"
    scsi = "true"
  }
  vcpu = "1"
  memory = "2048"
  running = "true"
  network_interface = {
    bridge = "br120"
    hostname = "${var.domain_name}"
    # wait_for_lease = 1
  }
  autostart = "true"
}

The xml dump:
<domain type='kvm' id='85'>
  <name>issue358</name>
  <uuid>069fdae8-305d-46b3-a9f1-1912a0e451c5</uuid>
  ...
  <devices>
  ...
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/issue358_base_disk'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/libvirt/images/issue358_base_vol'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='scsi'/>
      <wwn>05abcd97de317c75</wwn>
      <alias name='scsi0-0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
	...
  </devices>
</domain>

Failed cases

Failed case: trying to allocate from lvm pool in format raw/qcow2

resource "libvirt_volume" "vol1" {
  name = "vol1"
  pool = "vghost"
  size =<PHONE_NUMBER>
  # error message is the same while format = "qcow2"
  format = "raw"
}

Error: Error applying plan:

1 error(s) occurred:

* libvirt_domain.terraform_test: 1 error(s) occurred:

* libvirt_domain.terraform_test: Error creating libvirt domain: virError(Code=1, Domain=10, Message='internal error: qemu unexpectedly closed the monitor: 2018-08-16T22:33:00.528488Z qemu-kvm: -drive file=/dev/vghost/vol1,format=qcow2,if=none,id=drive-scsi0-0-0-1: could not open disk image /dev/vghost/vol1: Image is not in qcow2 format')

Failed case: Creating a volume using "default" pool of format "raw" and try to attach to the domain

resource "libvirt_volume" "vol1" {
  name = "vol1"
  pool = "default"
  size =<PHONE_NUMBER>
  format = "raw"
}

resource "libvirt_domain" "terraform_test" {
  name = "${var.domain_name}"
  disk {
    volume_id = "${libvirt_volume.base_disk.id}"
    scsi = "true"
  }
  disk {
    volume_id = "${libvirt_volume.vol1.id}"
  }
 ...
}

Error message:
* libvirt_domain.terraform_test: 1 error(s) occurred:

* libvirt_domain.terraform_test: Error creating libvirt domain: virError(Code=1, Domain=10, Message='internal error: qemu unexpectedly closed the monitor: 2018-08-16T22:11:05.933393Z qemu-kvm: -drive file=/var/lib/libvirt/images/vol1,format=qcow2,if=none,id=drive-virtio-disk1: could not open disk image /var/lib/libvirt/images/vol1: Image is not in qcow2 format')

Domain creation succeed however volume  is not usable. Volume is created on "default" pool which is not base on LVM:

...
resource "libvirt_volume" "vol1" {
  name = "vol1"
  pool = "default"
  size =<PHONE_NUMBER>
  format = "qcow2"
}

resource "libvirt_domain" "terraform_test" {
...
  disk {
    volume_id = "${libvirt_volume.vol1.id}"
  }
...
}

xml dump:
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/vol1'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...

I have started to work in this issue. I am still unsure what is the best way of fixing it.
Originally I thought it was directly related to the fact that we hardcoded the file type of volume, and I already have a branch improving this. However this was only part of it.
There are two format parameters. One is part of the volume definition, and then there is an attribute for the driver that the disk uses to access the volume. And those should match.
So my current idea would be:

For uploaded volumes (source=) use some mime library to find out if the file is a qcow2 and auto-set the volume format to qcow2. Right now we rely on a default and on looking at the extension.
For terraform created volumes, default to raw instead of qcow2 unless the format parameter is specified.
For the terraform disk referring to a volume, instead of hardcoding the qcow2 driver (which we do right now, except for iso files), get the volume definition and check the format.

I believe with all these pieces, the provider will behave better. There may still be corner cases, as we don't want to introduce the complexity of having to expose the driver in the disk definition.
I will post updates when I get to implement this and post the branch for testing.

@mjiao Are you able to build a test branch yourself in order to test?

Hi @mjiao. See the PR referenced above.

@dmacvicar thanks for the message. Will test that.

Thx @mjiao

Test summary:

Volume format is set correctly for both qcow2 and raw while creating on default pool. Domain is configured correctly. Tested using the examples below:

variable "domain_name" {
  type    = "string"
  default = "test"
}

resource "libvirt_volume" "base_vol" {
  name = "${var.domain_name}_base_vol"
  # source = "/home/jenkins/output-images/test-centos7-base.qcow2"
  source = "/home/jenkins/output-images/test-centos7-base.raw"
}

resource "libvirt_domain" "terraform_test" {
  name = "${var.domain_name}"
  disk {
    volume_id = "${libvirt_volume.base_vol.id}"
    scsi = "true"
  }

  vcpu = "1"
  memory = "2048"
  running = "true"
  network_interface = {
    bridge = "br120"
    hostname = "${var.domain_name}"
    # wait_for_lease = 1
  }
  autostart = "true"
}

raw volumes can be created correctly using vghost lvm pool. Domain is configured correctly with the correct format of volume attached. Tested using the example below:

variable "domain_name" {
  type    = "string"
  default = "test"
}

resource "libvirt_volume" "base_vol" {
  name = "${var.domain_name}_base_vol"
  pool = "vghost"
  source = "/home/jenkins/output-images/test-centos7-base.raw"
}

resource "libvirt_domain" "terraform_test" {
  name = "${var.domain_name}"
  disk {
    volume_id = "${libvirt_volume.base_vol.id}"
    scsi = "true"
  }

  vcpu = "1"
  memory = "2048"
  running = "true"
  network_interface = {
    bridge = "br120"
    hostname = "${var.domain_name}"
    # wait_for_lease = 1
  }
  autostart = "true"
}

Extra volumes can also be created and attached to the domain with the correct format.

Thanks a lot! @dmacvicar @MalloZup

merged closing :+1:


BREAKING CHANGE: Delay the choices object differently

This gives users a lot more flexibility in defining the choices used by a task; in particular, it lets us select arbitrary KVPs instead of just assigning arbitrary values to existing keys

I actually meant to make this change before making the grimoire release after the discussion in discord, but I forgot. Maybe it's time to increment the major version soon anyway.


File-Transfer does not work with crosswalk-webview plugin

My cordova project make use of the file-transfer plugin. When the Webview plugin is installed, all File-transfer (upload) Requests results in a 403 error: unauthorized :/
Sombebody knows why and can help me out with a quick fix?
update: also i can not open  geo: uri's with the crosswalk webview.

I upload a picture to http://cordova-filetransfer.jitsu.com/upload, it work finely.
Could you please try to verify without crosswalk plugin.

Thanks for your response.
I did. We are two days before releasing our App and i hoped i can have the crosswalk plugin to support Android 4.3 better. But now I'm going without crosswalk because of file-transfer and geo: uri's not working. Both of them are important for our App and it is working fine without crosswalk plugin (tested at least three times with new cordova projects - with and without crosswalk)

It would be helpful if you could describe test steps,  share your partial code or simplify your usage scenario to reproduce the issue.


Implement page visibility support

Fixes #111.
I hope everything is correct :)
Sometimes when switching quickly away from / back to a tab, the events seem to appear in wrong order. But it's probably just a demo logging issue.

Any news on this, @thenikso? Is anything missing from me?

Expanded with considerPageFocus support.


fix!: remove .value field from type declarations for boolean literal types

PR Checklist

[x] Addresses an existing open issue: fixes #528
[x] That issue was marked as status: accepting prs
[x] Steps in CONTRIBUTING.md were taken

Overview
Ostensibly, this is the code change, but it looks pretty intentional that it was written this way in the first place, so.... maybe needs some more investigation in order to understand why it was written this way.
I'm not really sure how to test for this, either. I've written a test that proves the bug's existence, but wouldn't prevent it from regressing. Open to suggestions 🤔

Looks like the CI failures are occurring on main, not due to the changes

@kirkwaiblinger @JoshuaKGoldberg I've made a couple of updates to the branch. I think it should be good to go now.


Introduce Windows compat layer

Windows does not have <unistd.h>.
When using #ifdef _WIN32 macro simply, it makes flood of #ifdef _WIN32.
Then, we should create compat layer and use it.

thanks for this work.
would you please rename the latest commit to "compat: new windows layer", so next changes over that interface can follow the same pattern.

Updated.

thanks.


Added Bengali translation of title template, headings, labels, etc

Summary

Adding Bengali translations to https://github.com/cicirello/user-statistician/blob/main/src/StatConfig.py
Closing Issues
Closes #70
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvements to existing code, such as refactoring or optimizations (non-breaking)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] I have read the CONTRIBUTING document.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

#Hacktoberfest pull request

@ponickkhan This just went live with release v1.9.0. :rocket:


contrib/podex: use registry API to resolve image metadata

use the registry API to resolve image metadata instead of the docker remote API

remove the need to run docker locally to run podex
remove go-docker-client depedencies
remove the possibility to generate pod manifest for local docker image

It seems unfortunate to lose the ability to generate pod manifest for local docker image
I don't think you meant to check a podex binary in.

The PR is actually removing the binary that was checked in.


Endpoints not being found in 0.9.0-beta5

Hi,
Ran into a weird issue earlier today where beta5 wasn't finding the endpoint for one of my apps, causing it to constantly fail.
https://gist.github.com/apenney/dafabe9a4093b7521a7019042f9e94d9 is the endpoint/service for the app, and the log message printed by the nginx pods.  I just switched to beta4 and it started working.
I'm not sure what you'd need to troubleshoot this more so if you let me know I can switch back to alpha5 and feed you whatever would help.

I'm pretty sure gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.5 is the latest release, perhaps try that?

Sorry, I meant beta5 and beta4.

Could you verify that kubectl get endpoints/qa-tempo-tempo --namespace=flaming-potatoes works, also which version of kubernetes are you using, and do you have RBAC enabled?

@malet it does, when I switch to beta4 it finds that endpoint and works.  It's 1.6.2 and no RBAC (upgraded from 1.5 with kops)

Same problem with the 0.9.0-beta5 some of my app doesnt get the endpoint refreshed by nginx and if I delete the nginx container it will recreate and find the endpoint. I will try reverting to beta4 if it works better.
kubernetes is 1.6.2 with kops.
ingress nginx is 0.9.0-beta5
I'm also using the external dns controller to manage the url.

maybe related #520 I had no time to test

Please update the image to gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.6

Closing. Please reopen if the issue persists after the upgrdade to 0.9.0-beta.6.


Update to use GeoviewCompose - SceneView

Description
PR to update the 3 missed SceneView compose samples to use geoview-compose SceneView:

ShowViewshedFromPointInScene
AddSceneLayerWithElevation
DisplaySceneFromMobileScenePackage

Links and Data
Sample issue: runtime/kotlin/issues/3776

Thanks, @ruiqima, I addressed the feedback. Ready for your review


router: type-safe helpers for multiplex routes

Component
Core framework
Middleware
n/a
Is your feature request related to a problem? Please describe
Currently multiplex routes are supported via:
f.Routes("/", http.MethodGet, http.MethodPost, <my handlers>)

// or

f.Routes("/", "GET,POST", ...)

But neither of are both elegant and type-safe.
Describe the solution you'd like
Something like
f.RoutePath("/").Methods(http.MethodGet, http.MethodPost).Handlers(...)

Describe alternatives you've considered
Live with it
Additional context
Derived from https://github.com/flamego/flamego/issues/113#issuecomment-1125895280
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Related in terms of underlying types: https://github.com/flamego/flamego/issues/132


ACL allows user to perform any action in endpoints not related to tables, such as /zk, /instances, etc

I was testing the ACL feature based on this doc, and everything is working fine regarding table/schema operations (CREATE, READ, UPDATE, DELETE), but I found that if I call any other endpoint that is not related to a table operation using an user that should only have READ access to tables, such as a PUT, DELETE, GET and POST in endpoints like /zk, /instances/, this user is allowed to perform the operation.
Is this the intended behavior or only for table access control? I feel it could lead to a potential problem for our cluster if users decides to call these endpoints without the knowledge of what they are doing (I was even able to delete the cluster path in Zk). In our use case we'll be managing Pinot and having it as a service for other teams and thus we don't intend to let users update any config that isn't related to their own table.
Cluster ACL configs:
Controller ACL conf:

# ACLs
# Enable ACL enforcement in the controller
controller.admin.access.control.factory.class=org.apache.pinot.controller.api.access.BasicAuthAccessControlFactory

# Create users "admin" and "user". Keep in mind we're not enforcing any ACLs yet.
controller.admin.access.control.principals=admin,user
# Set the admin's password to "verysecret"
controller.admin.access.control.principals.admin.password=verysecret
# Set the user's password to "secret" and allow "READ" only
controller.admin.access.control.principals.user.password=secret
controller.admin.access.control.principals.user.permissions=READ
controller.admin.access.control.principals.user.tables=events,events_upsert_full,events_upsert_partial
# Enable the controller to fetch segments by providing the credentials as a token "Basic " + base64encode("admin:verysecret")
controller.segment.fetcher.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="

Server ACL conf:
# ACLs
# Enable the Server to fetch/upload segments by providing the credentials as a token "Basic " + base64encode("admin:verysecret")
pinot.server.segment.fetcher.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="
pinot.server.segment.uploader.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="
pinot.server.instance.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="

Broker ACL conf:
# Enable ACL enforcement in the Broker
# The factory class property is different for the broker
pinot.broker.access.control.class=org.apache.pinot.broker.broker.BasicAuthAccessControlFactory

# Create the users and password (must be exactly the same as the ones created for the controller)
pinot.broker.access.control.principals=admin,user
pinot.broker.access.control.principals.admin.password=verysecret
pinot.broker.access.control.principals.user.password=secret

# No need to set READ permissions here since broker requests are read-only

# This configuration option allow specification of usernames and passwords as well as optional ACL restrictions on a per-table table basis (access type is always READ)
pinot.broker.access.control.principals.user.tables=events,events_upsert_full,events_upsert_partial

Minion ACL conf:
# ACLs
segment.fetcher.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="
task.auth.token="Basic YWRtaW46dmVyeXNlY3JldA=="

Example of working endpoint calls (which I expected not to be allowed):

Untagging Servers:

instances=("Server_pinot-server-0_8098" "Server_pinot-server-1_8098" "Server_pinot-server-2_8098" "Server_pinot-server-3_8098")

for instance in ${instances[@]}; do
  curl -X PUT \
    "http://localhost:9000/instances/${instance}/updateTags?tags=server_untagged&updateBrokerResource=false" \
    -H "accept: application/json" \
    -u user:secret
done

Deleting Zookeeper path for our cluster:

curl -X DELETE "http://localhost:9000/zk/delete?path=%2Fpinot-example" -H "accept: application/json" -u user:secret

This obviously destroyed the cluster.
General cluster info
Apache Pinot version: 0.12.1
Thank you very much!

Thanks for reporting the issue!
This framework is controller by the Authenticate annotation, and I do see it added for these ZK APIs (In ZookeeperResource introduced in #6507), so I don't know why the check is bypassed.
@sajjad-moradi Does it work properly in your environment?

It should, but we're using a custom AccessControl in our environment (auth token is not used)!
I just debugged and stepped through AuthenticationFilter for PUT /zk/putChildren endpoint, and it hits the right method for authentication:

Maybe something has changed for token based authentication 🤷


"Drop the feature" is not really an option

https://w3ctag.github.io/security-questionnaire/#drop-feature
Section 5.6 suggests that the simplest way is to drop the feature. This might be simple from the perspective of the reviewer, but presumably the design is being proposed with a motivation to solve an important problem for developers or end-users. Our work as reviewers is to help folks weigh this balance, rather than to suggest that they're simply wrong for wanting to solve problems. We have guidelines on the topic of putting powerful features behind permissions and I think the tone here contradicts with how we want the platform to advance. There are ways of balancing the risks, and we should be trying to help teams navigate that balance going forward. Suggesting they simply stop appears to put a thumb on the scales, suggesting the TAG is hostile to new features in general -- which we are not.
Ideally it should be reworded in a way that suggests tucking it behind a permission or dial down the granularity/power to mitigate the risks involved.
(Partially written by @slightlyoff.)

See also https://github.com/w3cping/security-questionnaire/issues/19

FWIW, I disagree. One of the conclusions that emerged from the permissions workshop last fall (which will hopefully prominently feature in the as-yet-unpublished workshop report) is that the first question that should be asked when someone proposes to add a powerful feature to the Web platform which would require a permissions prompt is "does such a feature belong on the Web"/"should we be adding this feature in the first place?"

+1 to @hober. The onus needs to be firmly upon those who want to extend the platform, not the other way around.

The advice the TAG gives to folks asking for review is about being collaborative in helping them sort out issues with the design. The TAG can't cause people to ship (or not) (as everyone on this thread knows).
What we should be asking for is evidence of need. That's what Explainers and most of the other process we have adopted are designed to do. As a collaborative review body, the TAG retains whatever standing it has by being collaborative. Striking an argumentative tone at the front of the document is, in that context, perhaps unhelpful.

the first question that should be asked when someone proposes to add a powerful feature to the Web platform which would require a permissions prompt is "does such a feature belong on the Web"/"should we be adding this feature in the first place?"

At the point where we have received the review, I suspect there was already a reasonable amount of self-assessment on this topic and I would like to think that it was deemed that the gain outweighs the risks.
The tone should be really about "how do we make this dangerous feature safe", not about "your problem isn't big enough to even consider in the first place". We can deal with the risk assessment in the review process, but the authors should be given something to work with rather than suggesting "no, please don't".
The conservative attitude in the past triggered numerous web-ish-but-not-quite-web forks which have been problematic to many of us. (JIL/BONDI come to mind, others I will not name as they are still being used and there are people still working on those standards.)

Hello. Thanks for your concern. I understand the concern expressed here. For starters, I could drop @mikewest under the bus as the original proponent, but why would I.
The spirit is more close as @hober highlighted, and we never meant to be aggressive here. I am all for improvement. This is why we have other suggestions in the document (and they are favored, we favor improvement and handling risk, it should be clear).
That said, we've seen in the past some UAs removing features or APIs due to privacy concern, so although the "drop the feature" (reword it?) mechanic sounds radical, it is actually being followed, even if very rarely. The rationale behind retaining this point was never towards "do not develop the web".
Furthermore, the environment (including state of the art, and knowledge) tends to evolve as well, and some features not seen as problematic today, may be - in the future.

+1 @lknik

Discussed in Reykjavik f2f. Consensus is the issue remains open and we're open for further feedback, but we keep this point in the questionnaire.

2¢: I think the questionnaire is correct to include the "drop the feature" section, and strikes a good tone in that section. It doesn't come across as argumentative to me, and it only presents "drop the feature" as one option it's important to consider, not the usually-preferred option.
One framework I tend to use when thinking about this, which I don't see mentioned in the document, is to ask both "What security/privacy risks are added by adding the feature to the web platform?" and "What security/privacy risks are removed by adding the feature to the web platform?" This led me to favor adding features like Web Bluetooth, where the simpler approach of asking only "what risks are added?" led Firefox and Safari to decide they shouldn't add it.

Thanks @jyasskin for your feedback. Indeed there are many options out there. Thanks also for sharing additional thoughts on the broad approach you use.

One framework I tend to use when thinking about this, which I don't see mentioned in the document, is to ask both "What security/privacy risks are added by adding the feature to the web platform?" and "What security/privacy risks are removed by adding the feature to the web platform?" This led me to favor adding features like Web Bluetooth, where the simpler approach of asking only "what risks are added?" led Firefox and Safari to decide they shouldn't add it.

I think that's a fine thing to consider, although I'm far from convinced that it would lead to the conclusions that you say it does regarding Web Bluetooth.  Detailed discussion of that specific point probably doesn't belong in that issue, though.
I also think there's a third piece that needs to be considered:  not just the specific security risks added from one specific feature, but the effect of adding those security risks to the overall picture that users have about the idea that it is safe to visit websites.  A big piece of the web's value is that it is safe for users to visit websites.  In order for this value to exist, users must understand that it is safer to visit websites than to install apps or software, and act based on that understanding.  Doing things that complicate that understanding or complicate what users need to understand about the safety of the web (e.g., adding features that are less safe) reduces the ability of users to act based on that understanding of safety, or to act in ways that correctly reflect the safety that exists.

I'd also note the TAG had a discussion of this specific point yesterday; minutes should be available within a few days, I hope.

Here are the minutes I mentioned.

Changed the title of this issue to reflect the lack of consensus on it.

If you want to help people with proposed new features, help them articulate what problem it solves, with something better than "the web doesn't have this feature".
The biggest problems for security and privacy are cross-layer attacks.

I don't believe there is a good reason to avoid mentioning any reasonable measure to reduce risk.


Demonstrate file uploads using CURL

I created this document with some ideas for the data structure to support the files based on Chris initial commit. I also added a few sample HTTP calls to "visualize" how this could work:
https://docs.google.com/document/d/1sD7fCNfmZkpdhUsxcD6V4PoyY-LlGy6TOp3UTmE_99c/edit

We determined devise-jwt is likely not appropriate for our use case. It might make sense if you were building a front-end javascript application, but its only affordance for getting signed tokens back out is part of the sign in workflow.
We need to consider alternative approaches to minting and managing organization tokens.


Delay before the first answer (= start) to the call

Actual behavior:
Between the actual call start from the user point of view and the actual start of the conversation, a long delay is observed:

3-4 bips if the backend has been used less than a minute ago
More than 10 bips of the backend is cold

Expected behavior:
The bot answer in 1-2 bips.
Version:
11.0.1

Mitigation applied in 0fe1426bb5dab1201a6cab3fc80f8b5ae486a324.
Benchmark:

4 bips for a cold backend
1 bip for a hot backend

Compute platform has been migrated to Container Apps in #316. It reduces first answer delay to 0-1 bips (less than 1 second), constantly.
More fine tuning it the queuing management and the scaling should be needed for production.


add info about distances/speed (actual vs. theoretical)

Is your feature request related to a problem? Please describe.
Can info be shared about what was learned during some deployments? (ex: 400m with clear line of sight between MomaDucks got this much bandwidth/error rate, etc.)
Describe the solution you'd like
Some info on what was found during deployments. Perhaps what is "optimal/maximal" vs. actual.
Describe alternatives you've considered
WiFi should be fast (somewhat normal 2.4 wifi network speeds) between DuckLinks, but from Mama to Papa, since going over 900MHz is limited. Document/share these speeds/info.
Additional context
Might be cool to show info on how using pringle cans and/or low-tech antennas might improve. (like lofting some Mama's via balloons in the video)

Thoughts on this @nfeuer?

@TimoWielink add this to wiki


2017 Status and Roadmap for F# and the Visual F# Tools

Current Status of F# and the Visual F# Tools per VS2017 RTM

F# 4.1 is feature complete

Multiple new features, including struct representation of types, a new Result type, and other areas that are “nip and tuck” in nature
Multiple bug fixes
One by-design breaking change for C#-style Extension Methods
One known regression (https://github.com/Microsoft/visualfsharp/issues/2373)
One known bug in multi-case Struct DUs (https://github.com/Microsoft/visualfsharp/issues/1678)

.NET Framework compiler in good shape
.NET Framework FSI in good shape
.NET Core compiler in RC

Type Providers and Codegen from Quotations are not supported due to changes made in reflection APIs for .NET Core. These will be in .NET Core 2.0+ timeframe.

.NET Core FSI works as a simple REPL

However, it does not support the .NET Core references model and thus does not support #r

Visual F# Tools in Visual Studio 2017 is sitting atop Roslyn Workspaces with many new features thanks to the OSS Community

It's much easier to add new features to the tooling now
However, there are numerous regressions that are going to be fixed

Visual FSI window in Visual Studio 2017 is in good shape
Debugging is in good shape, with multiple areas of improvement

Support for Portable PDBs and Desktop PDBs on .NET Framework
Support for Portable PDBs on .NET Core
Support for Embedded Portable PDBs on .NET Framework and .NET Core
Support for embedded source code with Portable PDBs on .NET Framework and .NET Core
Points of significance:

Still no Expression Evaluator (EE) for F#, so that means many debugging features are still unavailable as they always have been
Regression when debugging F# Lists: the .Items property is not invoked by the Roslyn EE used in Visual Studio
No other regressions that we can find
Legacy EE will be going away

The Visual F# Tools project system does not support F# on .NET Core

The new .fsproj file does not load in VS
No project system support for package load, cross-platform build, or publish
No .NET Core templates in-box
This means you can create something with the .NET CLI and have it fail to load in Visual Studio

Lightweight Solution Load is not compatible with F# for VS 2017 release.

Build/Rebuild/Clean do not work
Text searching through any F# projects do not work either.

Immediate Roadmap for 2017

Bug fixes

Fixing tooling regressions in VS 2017 tooling
Fixing serious bugs in new features in VS 2017
Fixing serious bugs in the compiler

Stability

It’s crucially important that we get our tooling stability up to spec.  Many new features were introduced, but we didn’t increase our test coverage by much.
There is currently a bug on our side which prevents the Connected Services node in VS 2017 from working with F# projects.
Performance and memory-consumption issues

There were regressions here introduced in VS 2017 compared with VS 2015.  It will be an ongoing battle to improve this, but we’ve already seen big improvements from Don just recently.

Build/Rebuild/Clean and Text Search do not work if Lightweight Solution Load is turned on.  We’ll work with the team that owns this to get this fixed.

Migrate the OSS Build to the latest .NET CLI and MSBuild and use the Multilingual App Toolkit (MAT) for localization builds

Migrating OSS Build to latest .NET CLI and MSBuild is necessary for .NET Core 2.0 support, which is in turn necessary to get Type Providers, Quotation support, and #r support in F# for .NET Core
Using the MAT will also bring down our internal build times for signed binaries tremendously

Support generating signed VSIXs of the latest master build, pushed directly to MyGet

This will enable people to get on a “Fast track” for F# tooling in VS 2017, test out brand-new features, and provide feedback early on
The artifacts produced will come with the assumption that people know they won’t be as well-tested and may introduce regressions

Project System support for .NET Core and .NET Standard projects in F#

Ability to load MSBuild 15-based .fsproj projects
Add gestures for cross-platform builds, publish, and adding package references
Consideration: Roslyn Project System

Add F# support to the new project system that C# and VB use for .NET Core/Standard projects
Remove our own project system entirely, making us “first-class” in that regard
This is pending an investigation into the work involved

Full FSI support on .NET Core 2.0

Properly handle the model for how .dlls are laid out on disk with .NET Core, thus fixing #r
Establish a good working model for how to do the above
Prompt to re-load an FSI session when #r’ing an assembly that targets a higher target than what FSI was launched with?

Error message asking user to re-load FSI manually?
Try to re-target and re-reference everything on the fly?

Full support for F# on .NET Core 2.0 and .NET Standard 2.0

Type Providers and Code Quotations
This also takes a dependency on RefEmit.  We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap

Build a Contract .dll between Roslyn and F# to remove our use of InternalsVisibleTo

This will allow Roslyn to determine when they break us if they make any breaking changes to their APIs
This will be a big improvement over the current situation, where we must manually check this

OSS Engineering Efficiency and Build needs some improvements

The .NET CLI does not use project.json anymore, but our OSS Build still relies on that
The .NET CLI uses MSBuild 15 and PackageReferences, which we need to support
Open Source Localization is needed to simplify our localization process and more easy leverage the OSS community

Using the Multilingual App Toolkit is a way to improve our internal process and reduce build times

In accordance with the above, what follows is where we expect work will come from.  In the case of the OSS Community, while we don't assume work will be done for us, we anticipate continuing to receive high-quality contributions which we will gladly accept.
@KevinRansom

VS support for loading .NET Core 1.x projects in Visual Studio

This is an issue being addressed in the short-term

F# Compiler support for .NET Core 2.0
FSI support for .NET Core 2.0
Type Provider and Code Quotations support for .NET Standard 2.0
System.ValueTuple work to deal with its migration to mscorlib in .NET Framework 4.6.3
Helping with concrete work in evolving F# 4.2
Bug fixes in the compiler, PDBs, debugging, and platform support

@brettfo

Bug fixes in the VS Tooling

Addressing regressions and serious bugs in new features
Connected Services Node bug and other issues with VS features

Addressing the OSS Build
Getting our internal builds to a place where we can publish signed VSIXs for people to use
Addressing Localization

Using the Multilingual App Toolkit to reduce build times and remove our internal clone of this repo
Improve OSS Localization

Investigating F# support on the Roslyn Project system, and acting on that if it's deemed reasonable
Support the community

@cartermp

Blog post with a focus on OSS attribution for F# 4.1 and the Visual F# Tools in VS 2017
Outreach to internal teams to address issues that affect us
Support the community
Low-impact bug fixes, if possible

@dsyme and the F# OSS Community

F# 4.2 evolution
Additional IDE features and improvements
Performance improvements
Bug fixes (note: this does not mean that we are punting bug fixes to the community.  It means we will accept any bug fixes from the community)

Roslyn Team

Helping us and the OSS community better understand Roslyn when working on features
Engaging with and helping unblock the OSS community

I'm surprised the project system support for .NET Core /  MSBuild 15-based .fsproj projects is so far down on the list.  Given that .NET Core presents an opportunity to use F# (in part at least) for greenfield/rewrite projects, I would have thought a higher priority would have been given to this since it could help increase adoption numbers.

@GiorgioG Supporting .NET Core and MSBuild 15-based projects is the top item for @KevinRansom.  I wouldn't interpret numbers in the list as an overall priority.

@GiorgioG I'm not sure if the order in Immediate Roadmap for 2017 is indication (localization and build optimization are high but they don't seem to be the most blocking) but I see it is first item @KevinRansom has on the detailed list.

Why isn't Windows Store support (related to .NET Native support) on this list?

@charlesroddie Because that depends on the Core CLR team improving support for a couple of big items.  dotnet native is and AOT compilation are absolutely a goal for us ... they just are longer term than this roadmap anticipates.
I hope this helps
Kevin

@georigiog @smoothdeveloper I am looking at it right now ... I am in fact torn about how to proceed.
I would like to go CPS since that is the long term right plan ... however ... CPS fundamentally orders files alphabetically ... this has been a long known bug in CPS and is still not fixed.  It has not been fixed because .. .csproj and .vbproj don't need it, and .fsproj doesn't load into CPS.  It's been kind of a chicken and egg problem.  Also CPS isn't OSS so fixing it's behavior requires somewhat more ceremony than we are used to.
Also would require that we continue to ship the old project system for legacy projects.
An alternative approach and in the short term less risky approach is to fix the F# project system to load them.  However ... there are a bunch of nice but large work items that we would then not have.

Built in support for Roslyn multi-targeting, especially intellisense
(API narrowing --- select two target platforms and get the sommon subset of APIs).
Support for package references

However ... file ordering will work ....
Anyway I am torn ....
Probably an overshare .... please forgive me if it was too much info ...
Kevin

@KevinRansom thanks, it is good to know what are the ongoing struggles.
It seems most people are looking for a quick fix to get .net core fsproj to load in VS, we all understand going toward CPS is a lot more work and will bring a lot to the table.
Getting out of box VS support for F# .net core projects is going to help with adoption of both .net core and F# for xplat (for windows/VS users), this is a quick win if we roughly what needs to be dealt with in current project system.

@KevinRansom Thanks for the details Kevin - it's helpful to understand that there are complex issues / tradeoffs / decisions to be considered.

Migrate the OSS Build to the latest .NET CLI and MSBuild and
The .NET CLI does not use project.json anymore, but our OSS Build still relies on that
The .NET CLI uses MSBuild 15 and PackageReferences, which we need to support

I'd like to do that.
Speaking with @cartermp , we can discuss (in another issue) how to that with @brettfo and community.
I already have a PR about that. Need to just complete it building also fsharp.core/fsharp.compiler, and replacing build coreclr for now, as @dsyme suggested
Signing/localization too, can be done like dotnet/cli team (ref .xlf localization files really nice ihmo so we can contribute to localization too!, like other ms projects)

@enricosada  ... reorganizing the build is about lot more than just changing the way we build the coreclr.  The current build is absolutely horrific, and we should take a stab at fixing it all up.

@KevinRansom i want to do that too (xplat, no hacks, from clone -> packages). But incrementally, first coreclr so we can clean and use sdk and unblock netstandard2,0 if needed, After that, the rest. with sdk i can remove pretty really a lot, see my PR https://github.com/Microsoft/visualfsharp/pull/2250#issuecomment-276718417 about cleanup and future work.
I have some ideas, we can discuss goals and how to proceed in another issue maybe? i dont want to monopolize this issue 😄 i am always a lot verbose

@enricosada  I will take another look and suggest an approach.

Thanks for  your work and achievements!
F# is a nice language,it will become perfect one after VS's full support.
VS is called "the most powerful IDE in Universe" in China.
Nice language+Great IDE,The Gospel of dummy Programmers

This also takes a dependency on RefEmit. We’ll need to investigate this further, since it’s currently not on the .NET Core 2.0 roadmap

How high priority is this issue? .Net core engenders for growth in  F#, but we can't do it without type providers.

@dbettin The breakdown is actually as follows:
Erasing Type Providers (which are more common) should not require System.Reflection.Emit, but Generative Type Providers will.  We'll first need to ensure that with the .NET Standard 2.0 APIs coming along, that we can at least support Erasing Type Providers.  If that's the case, then many of the type providers in the wild could conceivably be used, assuming there are no other issues we run into.
For Quotations, it's a somewhat similar story.  They don't require System.Reflection.Emit, but they are needed for fully-fledged quotation evaluators/compilers, and are needed if they are used as input to a Generative Type Provider.
What I think may be likely is that we'll have support for the "95% case" in these areas, but we could still be blocking key libraries and library authors if they are building full-on quotation compilers and Generative Type Providers.
All of the above is assuming that we don't do any work in those areas ourselves.  @KevinRansom can speak more towards the feasibility of that, but given the amount of work we're doing right now, I don't find it likely that rewrites of those areas of TPs and Quotations will come from someone in Redmond between now and .NET Standard/.NET Core 2.0.

Thanks @cartermp. It might be helpful to break these out into separate issues.  And maybe assign an up for grabs label to issues that are not assigned to Redmond devs?

@Huqin-China Thanks for the perspectives from China!

@dbettin @cartermp
The problem with generative TypeProviders is that ref emit on coreclr doesn't implement Save().  Ref emit is not actually a part of .Net Standard 2.0 the System.Reflection.Emit package will work with fine with .Net Standard 2.0, it's just those Apis are not part of the .Net Standard set of Apis and so ... there is no urgency to improve it's desktop compatibility.  The problem for F# is that generative type providers need to produce a P.E file and since the the Save() API doesn't exist, we need a clever solution to that problem.  There are in fact plenty of approaches we could take ... we just haven't settled on one that is the obvious winner.
I cornered Jan Kotas in the corridor the other day and tried to push him to commit to getting us Save,  he urged us to seek other solutions ...
So ... we need an alternate solution, regardless until .Net Standard 2.0 we can't do much with type providers given that Type has a private constructor on the coreclr, at least in the reference assemblies it is, the implementation still has a protected constructor.  So I suppose we could do type reference magic to get something working.
As for up for grabs ...  just express an interest in an area you want to work on and start a discussion.  Helping out is really very easy.  Most people just pick something they want to do and start work on it.
Kevin

@KevinRansom Thanks. My point around the up for grabs is it would beneficial to break these up so we can start tracking these issues independently.

@dbettin do you mind creating the few issues you have in mind? I think with github option, the maintainers can expand the description with additional technical and contextual information.

This roadmap makes it appear that, for my purposes, VS 2017 RTM is really more of an alpha release for F# support, at least wrt .NET Core. Will .NET 4.6 projects continue to work, or should we stick to VS 2015 and/or VS Code?

.NET Framework 4.6 projects should continue to work, yes.  Addressing any regressions there is a top priority for us.  RC4 is a good target to validate this on.  The bits in there are the bits which are shipping in VS 2017 RTM, barring some unexpected, massive error on our part.

Not a single word about .NET Native or UWP support. Nice!

@OnurGumus https://github.com/Microsoft/visualfsharp/issues/2400#issuecomment-278770906

@vasily-kirichenko  ah ok thanks. Didn't read all the comments.

What about project template for F# Roslyn analyzer?

@xperiandri Currently that's not possible, since F# does not use the same semantic model that Roslyn uses..  What I believe you're referring to is the F# lightbulbs.  These are controlled by adding a new type in the F# editor project which exports itself as a codefix provider, e.g. this.  It registers an error code to trigger on, and when that code is registered by the F# diagnostics service, the code fix will trigger the lightbulb.  I'm not sure that there's a good way to get a template for that going.

Why not? At least it can bootstrap fixes creation.
What about light bulb UI? Is it already reusable or still locked to C#/VB analyzers?

@xperiandri There's really two problems here, but first I'll clear this up
Lightbulbs aren't tied to C#/VB.  We use them today, with Roslyn Workspaces as our vehicle.  F# tools now sit on the Roslyn Workspace layer, which is why we're able to use the same UI.
Triggering Lightbulbs is only possible within the F# Tools repo itself right now.  There is no extensibility model.  That kind of model would have to use the Roslyn Analysis Platform, which we cannot interact with because we have our own semantic model.  We don't share the same semantic model as C# and VB.
Thus, any template could only be useful when developed within the F# Tools themselves.  After that, any template would also not trigger a lightbulb by default - they're triggered by a sepcific F# error code, which you would have to supply yourself.  So at best, a template would:

Only work with the Visual F# Tools themselves
Not trigger until you add the error code you want the lightbulb to trigger with

Given that, and that it's pretty easy to just copy/paste some code from one code fix provider and change some names around, we don't have a template.  We could consider such a template for people looking to improve these specific tools as part of a Visual F# Tools Developer Guide, perhaps.

In his comment on 9th Feb, @KevinRansom talks about the tradeoff between CPS vs fixing the existing F# project system to load msbuild 15 files. One particular benefit of CPS was "Support for package references."
Does this mean that if you don't go down the CPS route, package references will be unavailable?
That's distressing but also confusing. I was under the impression that if you build from the command line, it's possible to use a PackageReference in an MSBuild-15-based fsproj now. (At least, I remember seeing an example showing this.) So if you don't do CPS, what will the situation with PackageReferences be? Will they not work? Will they work but need manual authoring of the fsproj to add them?
The thing I most urgently want is the ability to use package references in an fsproj, and to have them work transitively across external projects (including C# ones). E.g., if my F# project has a reference to a csproj in the same solution, and that csproj has a PackageReference to some NuGet package, my F# project will also implicitly have access to that same package without needing to add it explicitly to my csproj.
(I don't care about .NET Core by the way. I'm targetting .NET FX 4.6.1. I just want to escape from the insanity of packages.config.)

PackageReferences work with command line tools and ionide - just not in VS
yet.
Am 08.03.2017 1:22 nachm. schrieb "Ian Griffiths"<EMAIL_ADDRESS>
:

In his comment on 9th Feb
https://github.com/Microsoft/visualfsharp/issues/2400#issuecomment-278774305,
@KevinRansom https://github.com/KevinRansom talks about the tradeoff
between CPS vs fixing the existing F# project system to load msbuild 15
files. One particular benefit of CPS was "Support for package references."
Does this mean that if you don't go down the CPS route, package references
will be unavailable?
That's distressing but also confusing. I was under the impression that if
you build from the command line, it's possible to use a PackageReference in
an MSBuild-15-based fsproj now. (At least, I remember seeing an example
showing this.) So if you don't do CPS, what will the situation with
PackageReferences be? Will they not work? Will they work but need manual
authoring of the fsproj to add them?
The thing I most urgently want is the ability to use package references in
an fsproj, and to have them work transitively across external projects
(including C# ones). E.g., if my F# project has a reference to a csproj in
the same solution, and that csproj has a PackageReference to some NuGet
package, my F# project will also implicitly have access to that same
package without needing to add it explicitly to my csproj.
(I don't care about .NET Core by the way. I'm targetting .NET FX 4.6.1. I
just want to escape from the insanity of packages.config.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2400#issuecomment-285027046,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNH9nbi2si0r-PTcYuzeFn3RGJizkks5rjp1vgaJpZM4L8b-o
.

Thank you @forki for confirming that you can indeed use PackageReference from the command line. (As I said, I thought this was so but wasn't certain.)
Rereading my comment I realised I didn't make it sufficiently clear that it's Visual Studio I'm interested in. I know it doesn't work today, but there are plans afoot to change this, and there's a tradeoff between two different ways this might be handled.
And that's what I was trying to understand: I gather there's a choice between moving to CPS and fixing up the existing project system to cope with the new fsproj capabilities.
Kevin's comment seemed to imply that if they go down the latter path - just fixing up the existing system - this would have an impact on package reference support in VS. I'd like to understand what that impact would be.

There are already commits in the roslyn repo that lead the path to CPS. It
will come eventually
Am 08.03.2017 1:47 nachm. schrieb "Ian Griffiths"<EMAIL_ADDRESS>
:

Thank you @forki https://github.com/forki for confirming that you can
indeed use PackageReference from the command line. (As I said, I thought
this was so but wasn't certain.)
Rereading my comment I realised I didn't make it sufficiently clear that
it's Visual Studio I'm interested in. I know it doesn't work today, but
there are plans afoot to change this, and there's a tradeoff between two
different ways this might be handled.
And that's what I was trying to understand: I gather there's a choice
between moving to CPS and fixing up the existing project system to cope
with the new fsproj capabilities.
Kevin's comment seemed to imply that if they go down the latter path -
just fixing up the existing system - this would have an impact on package
reference support in VS. I'd like to understand what that impact would be.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2400#issuecomment-285031742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNDYhLFu8HX6N6ZWZo0rl-EaFe5fiks5rjqNdgaJpZM4L8b-o
.

OK, so if I understand, this means that it's definitely going to be the CPS route, and F# will at some point get full support for package references on an equal footing with C#? Fantastic.
Are the roslyn updates you refer to https://github.com/dotnet/roslyn-project-system/pull/1670 ?
Is there any place I can keep track of F#'s progress towards being able to use new fsproj files from Visual Studio? I posted to this thread because when I looked in the Issues I didn't manage to find anything that was obviously tracking progress on this - Kevin's comment on this thread was the only thing I'd found.
After some more digging I've found a check list of things to be done here but that doesn't look like a definitive work item for tracking this stuff - more a proposal of what one might look like.
I'd like to be able to keep an eye on this partly so I can have some idea of when it'll arrive, but also so I can, if possible, try out work in progress to see if it works for me, and provide feedback if appropriate. But I've not been able to work out where I should be looking for this.

Yup, just to confirm that @forki is right.  F# will be using CPS in Visual Studio and adopt the new MSBuild PackageReference and other goodies.  I highly recommend using the CLI and VSCode to experiment with it today.  Any feedback you can provide about it would be helpful.

@cartermp, what about snippets?
https://github.com/Microsoft/visualfsharp/issues/1498
I can't see neither folder for snippets in Visual Studio user folder nor a command in context menu in Visual Studio.

@xperiandri Not on the immediate roadmap, but I know that @brettfo  was looking at this a while back.  He might pick that back up in a while.  For sure, snippets are something we're lacking in right now.

@xperiandri the roadmap sets the general direction, and identifies the large feature areas targeted.  We welcome community contributions of features that conform to the general direction we are headed whether they are called out in the roadmap or not.  Similarly smaller unmentioned features may well be handled by us, en-route as it were.
So that snippets, folders and context menu changes are not in the roadmap, it's because they are below the level of detail intended for it.
Does that help?
Kevin

One of the big things is that generative type providers service the wider ecosystem not just F#, they are the most important aspect in that respect.
Unchecked quotations for generative providers is also something that sorely needed to avoid having to reflectively call quotation builders to build the type provider.

@cartermp Could you please change the number/bullet points to check boxes in the original post so that it's possible to track the current status of the individual work items?

Hi guys! What about automatically list members like in C# ?

Closing in preference to most recent announcements here https://github.com/Microsoft/visualfsharp/issues/3069

Closing old discussion

@cartermp Is there a single issue we can follow to keep an eye on the status of F# support for VS 2017? The table here still indicates VS 2017 doesn't support dotnet -lang f# projects, and I can see that it is  not possible to use Intellisense or type hints.

@masaeedu The VS 2017 release notes track what's available for the current non-preview release, and there are links to past release notes which contain lists of features.
There is single issue to track the status of F# support for VS 2017, nor will there be.  There are simply too many things to track, some of which have been in the product since its inception.

@masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it.  It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.)  In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor.

@GiorgioG Two things:
a. Things change, such as releases, especially when things are difficult.
b. .NET Core has been the single highest priority for F#, and since we delivered stable support for .NET Core 2.0 and .NET Standard 2.0, we're focusing solely on the tooling inside of VS 2017.

@cartermp
a.  I understand I'm a software dev too ;)
b.  Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there?  That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

@cartermp I'm looking for some kind of checklist or issue label for the VS 2017 extension that will let me distinguish "oh this just isn't implemented yet" from "oh, I'm an idiot I just have it set up wrong".
If there isn't such a thing, is there an issue tracking implementation of Intellisense for dotnet CLI generated F# projects in VS 2017? I'm searching for "Intellisense" in the github issues, which brings up lots of different bugs/feature requests for Intellisense; which is incongruent with my experience of Intellisense simply not working all.

@GiorgioG

Totally understand, but correct me if I'm wrong, there's VS infrastructure outside of the F# team's control that needs to be changed to support some of the F# specifics around compilation order that isn't/wasn't there? That's what I meant by MS not prioritizing it, not saying the F# team isn't focused on it.

In this case, there are three layers:
F#
.NET project system, which is a plugin to the bottom later
CPS (Common project system), which is inside of VS
CPS has implemented a component which respects F# file ordering, but this is known as a "Data flow".  It used to not respect ordering, so IntelliSense would be hosed no matter what you did.  This component doesn't control the UI, it just makes sure that when we pass the file ordering down into the underlying project system, that this file ordering is preserved.  CPS is closed-source and internal to VS, and with no public bug tracker.
The .NET project system plugin to CPS needs to effectively wire up the UI to use that data flow when presenting F# files in compilation order.  However, given that:
(a) The project system now preserves the ordering of files, thus allowing IntelliSense to work (modulo our last bit of work here, which enables project-to-project references and seeing symbols from newly-added files in IntelliSense)
(b) Project files are palatable and can be opened without unloading a project
We're not blocking on the 15.5 release to get the visual ordering in the file tree.  The issue is being tracked here, and although it's still an annoyance, it's not the end of the world.  We still need to get gestures added, and CPS is also looking into click-and-drag in the tree, which would allow you to order using the mouse like VS for Mac.  The project system has had to deliver an immense amount of scope in a short amount of time, so issues like this which don't prevent someone from using the product aren't given top priority.  But it's coming.
@masaeedu My advice would be to try out VS 2017 15.5 Preview 1, which works aside from the following:

If you add a new file, the constructs in that file may not be visible to files which use it
If you add a new project and add a reference to it from an F#/.NET Core project, you won't get IntelliSense for things you use

These two issues are addressed in #3777 and targeted at the 15.5 release.  That said, IntelliSense works fully for .NET Core SDK-based projects in the preview, modulo those two issues.


Expose app version to juju

IAM-493

This change will expose the hydra version as seen below:

Most of our charmed applications do not have the v prefix, should we filter that out?

This change will expose the hydra version as seen below:
Most of our charmed applications do not have the v prefix, should we filter that out?

is that the version of the charm or the app version?if former i'd say filter that out


Ctrl + F3 does not close realtime csg tab.

Unity version 2021.3.27f1
Realtime CSG version 1.601
Nothing happens when I press ctrl + f3, ctrl+ f2 undocks the window.

I got around this by rebinding it. Don't know what was using my ctrl key as I have no issues with other applications?


images doesn't load

I forked and deployed to heroku.
Images are not loading:

what should I do to get the images to show?

I forgot to commit them — those images don't load on showterm.io either :).
Feel free to delete whatever code is trying to load them (I think I just
copy-pasted some jquery slider plugin).
Conrad
On Sat, Mar 14, 2015 at 8:22 PM, Di Wu<EMAIL_ADDRESS>wrote:

I forked and deployed to heroku.
Images are not loading:
[image: image]
https://cloud.githubusercontent.com/assets/380950/6654525/bcff4ac0-ca87-11e4-9d90-d85c14c7deef.png
what should I do to get the images to show?
—
Reply to this email directly or view it on GitHub
https://github.com/ConradIrwin/showterm.io/issues/28.


Namespace

Use a namespace (like namespace Parsedown;) would avoid name conflicts in some cases.

You might want to read about it in #64

Oh, thanks! ;~)


Ionic 2 slides sliding not working in RTL (From RC.5)

Ionic version:  (check one with "x")
[ ] 1.x
[ x] 2.x
I'm submitting a ...  (check one with "x")
[x ] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
When moving to the next slides in RTL app, the slide dissappear and it's impossible to click anywhere on the app.
Expected behavior:
Sliding to the next slide work as slides suppose to work in RTL apps
Related code:
<ion-slides pager *ngIf="showSlides">

  <ion-slide style="background-color: #1C4080">
    test
  </ion-slide>

  <ion-slide style="background-color: #1C4080">
    test2
  </ion-slide>

  <ion-slide style="background-color: #1C4080">
    test3
  </ion-slide>

</ion-slides>

If you will add style="direction:ltr", the slides will work.
Other information:
Ionic info: (run ionic info from a terminal/cmd prompt and paste output below):
Ionic 2 RC.5 (slides refactoring)

Same #10028

@theunreal   Hello,
Here's a solution I tried and worked. It turns out that you that there's a  _rtl property which is private and not exposed in the Slides API. When set to true, everything works fine. The problem is I'm not able to update this property on ionViewDidLoad or ngAfterViewInit. It only works if you explicitly set it true by clicking a button.
import { Component, ViewChild } from '@angular/core';
import { NavController, NavParams , ViewController, Slides} from 'ionic-angular';
import { StartPage } from '../start/start';

@Component({
  selector: 'page-tutorial',
  templateUrl: 'tutorial.html'
})
export class TutorialPage {
  @ViewChild(Slides) slides: Slides;

  constructor(public navCtrl: NavController, public navParams: NavParams) {

  }

 startApp() {
    this.navCtrl.push(StartPage);
  }

  ngAfterViewInit() {
    this.slides.freeMode = true;
  }

//TRY calling this function on a button click/tap. IT WORKS !
  fixrtl(){
      this.slides_rtl = true
  }

// Doesn't work here !
  ionViewDidLoad() {
      this.slides_rtl = true
  }

}

If you find a way to set/modify the _rtl property on Load, let me know.

I too have same problem in ionic2 slides in RTL direction
Its my HTML code
<ion-slides (ionSlideDidChange)="slideChanged()" dir="rtl">
When i am using this.slides.lockSwipeToNext(true) ts file for my last slide its misbehaving, Its not working properly. and if i swipe Previous its take me to first slide, that is index 0 slide.

@abehairy thanks for your solution
you can call this.slider._rtl inside ionViewDidEnter() event insted of ionViewDidLoad
Here's my code and working 👍
ionViewDidEnter() {
    if (this.translateService.currentLang == 'ar') { this.slider._rtl = true }
    console.log("ionViewDidEnter");
  }

Its very simple the above answers are right but no one know where to place it. Here is the sample code thats works perfectly. OnInit does everything for you.
import { OnInit } from '@angular/core';
class MyComponent implements OnInit {  @ViewChild(Slides) slides: Slides;   ngOnInit() {     this.slides._rtl = true;   } }


Alternate Audio Language ShakaUI

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
4.3.4
Please ask your question
I have a manifest with multiple audio of the same Language.
The Audio is Alternate Audio Described.
The current Shaka UI displays the Language of English for both
The markup for the manifest is as follows
 <AdaptationSet mimeType="audio/mp4" startWithSAP="1" segmentAlignment="true" lang="en" label="English Audio Description" subsegmentAlignment="true" subsegmentStartsWithSAP="1">
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="alternate"/>
      <Accessibility schemeIdUri="urn:tva:metadata:cs:AudioPurposeCS:2007" value="1"/>
      <!-- MPEG Common Encryption -->
...
</AdaptationSet>

My question is should I expect this to use the label property so that the user can distinguish between the Alternative Audio track?

Could this be a bug?

The player API lets you see both languages and roles, and to select by language and role together if you wish.  The UI is configurable to show roles IIRC.  Let me find the config for you.

Here it is.  Configure the UI's trackLabelFormat field:

https://shaka-player-demo.appspot.com/docs/api/shaka.extern.html#.UIConfiguration
https://shaka-player-demo.appspot.com/docs/api/shaka.ui.Overlay.html#.TrackLabelFormat

Quoting the docs:

field
type
description

trackLabelFormat
shaka.ui.Overlay.TrackLabelFormat
An enum that determines what is shown in the labels for text track and audio variant selection. LANGUAGE means that only the language of the item is shown. ROLE means that only the role of the item is shown. LANGUAGE_ROLE means both language and role are shown, or just language if there is no role. LABEL means the non-standard DASH "label" attribute or the HLS "NAME" attribute are shown. Defaults to LANGUAGE.

Here's a snippet, assuming video is a reference to your video element:
video.ui.configure(
    'trackLabelFormat',
    shaka.ui.Overlay.TrackLabelFormat.LANGUAGE_ROLE);

That is great thank you for that information @joeyparrish !

@joeyparrish Is there a reason shaka uses the non-standard label attribute instead of the Label element that is in the DASH specification?
Link to the specification: https://standards.iso.org/ittf/PubliclyAvailableStandards/c083314_ISO_IEC 23009-1_2022(en).zip

Shaka supports both forms. See https://github.com/shaka-project/shaka-player/blob/main/lib/dash/dash_parser.js#L1114-L1125

@avelad Would probably be a good idea to update the docs to say that, as they currently only say that it supports the non-standard label attribute.

@absidue Can you tell me where you have seen it? I'll try to do a PR to fix it.

In the description for the trackLabelFormat option in the UIConfiguration interface:

[...] LABEL means the non-standard DASH "label" attribute or the HLS "NAME" attribute are shown. [...]

https://shaka-player-demo.appspot.com/docs/api/shaka.extern.html#.UIConfiguration


Usage modify； Alamofire version 5 Session.default change  : Alamofire => AF

Issue Link :link:

Goals :soccer:

Implementation Details :construction:

Testing Details :mag:

Thanks!


fix fault 2 and 3 reporting from < 5 prct to > 5 prct

seems like percent_true should be > 5 for these to report that the amount of time the faults are True is too high

@bbartling a very small bug fix


Altair P2P

This PR is directed at a specs-repo copy of the branch by @ralexstokes, PR #2201, which implements the additive sync-committee related changes. When that PR is finished and squashed I will rebase this one to dev.
Changes:

Update Altair P2P header to not skip over req-resp changes
Define new additional <context-bytes> Req-Resp chunk field, compatible with phase0.
Define ForkDigest context, so we can parametrize the payload to decode. More specifically, to pick the SSZ type corresponding to the right fork, per chunk, enabling cross-fork sync.
Add blocks-by-range v2, and blocks-by-root v2, completely unchanged w.r.t. payload handling, but using the new ForkDigest context to select the SSZ type for the decoder.
Describe Req-Resp transition path
Describe GossipSub transition path

This is not final yet, but I think it looks like a good minimal change-set to support the Altair fork. Suggestions welcome. We can test and iterate in later release iterations also.
CC network crew @Nashatyrev @nisdas @AgeManning @arnetheduck

A small point for client implementer, would be to disable the mesh_message_deliveries score when subscribing to the new topics pre-fork to avoid penalizing peers.


push image to docker hub,but got "unauthorized"error

i have logged in successfully,but got this error.
someone said "Adding the X-Forwarded-Proto in the proxy configuration fixes it",but i am prohibited
from modifying my company's proxy server. Any other way?
Environment: Ubuntu 14.04 LTS + Docker 1.10.3
root@ubuntu:~#
root@ubuntu:~# docker login
Username: zdldocker
Password:
Email:
WARNING: login credentials saved in /root/.docker/config.json
Login Succeeded
root@ubuntu:~#
root@ubuntu:~# docker push zdlrepository/tomcattwo:latest
The push refers to a repository [docker.io/zdlrepository/tomcattwo]
f4ba23d94afc: Preparing
f4ade33f15c9: Preparing
501416a091a6: Preparing
35ee642fd1c2: Preparing
16879aa5082c: Preparing
5f70bf18a086: Waiting
f75f146a5022: Waiting
711b0bd2cb6a: Waiting
595d1d53a534: Waiting
unauthorized: authentication required

I have the same issue with beta  Docker for Mac and private Registry v.2.3.1
213.180:~$ docker push registry.yandex.net/echo
The push refers to a repository [registry.yandex.net/echo]
c5b0034201f2: Layer already exists
da61c8f6fafa: Layer already exists
8bfac3bbfefc: Layer already exists
631b7aecffd0: Layer already exists
6208212fc500: Layer already exists
08456b53c47e: Layer already exists
264f7eca249d: Layer already exists
5f70bf18a086: Layer already exists
ceddf6185bdf: Layer already exists
d5c8f5da98d4: Layer already exists
a523be55ce6e: Layer already exists
unauthorized: authentication required

tcpdump shows me that the last redirect is done without Authorization header
POST /v2/echo/blobs/uploads/ HTTP/1.1
Host: registry.yandex.net
X-Real-IP: <IP_ADDRESS>
Content-Length: 0
User-Agent: docker/1.11.0 go/go1.5.4 git-commit/a5315b8 kernel/4.4.6 os/linux arch/amd64 UpstreamClient(Docker-Client/1.11.0 \(darwin\))
Authorization: Basic <token>
Content-Type:
Accept-Encoding: gzip

HTTP/1.1 202 Accepted
Content-Length: 0
Docker-Distribution-Api-Version: registry/2.0
Docker-Upload-Uuid: f74400cf-741b-49be-8115-6038f8c7b1e8
Location: http://registry.yandex.net/v2/echo/blobs/uploads/f74400cf-741b-49be-8115-6038f8c7b1e8?_state=y8fcAuy-67ztJW51VD15obV3bvdVzl68qP5xMW4WQ-F7Ik5hbWUiOiJlY2hvIiwiVVVJRCI6ImY3NDQwMGNmLTc0MWItNDliZS04MTE1LTYwMzhmOGM3YjFlOCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxNi0wNC0yOFQxMjo1MDoxOS4xNDY1MzE5NzVaIn0%3D
Range: 0-0
Date: Thu, 28 Apr 2016 12:50:19 GMT
Content-Type: text/plain; charset=utf-8

PATCH /v2/echo/blobs/uploads/f74400cf-741b-49be-8115-6038f8c7b1e8?_state=y8fcAuy-67ztJW51VD15obV3bvdVzl68qP5xMW4WQ-F7Ik5hbWUiOiJlY2hvIiwiVVVJRCI6ImY3NDQwMGNmLTc0MWItNDliZS04MTE1LTYwMzhmOGM3YjFlOCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxNi0wNC0yOFQxMjo1MDoxOS4xNDY1MzE5NzVaIn0%3D HTTP/1.1
Host: registry.yandex.net
X-Real-IP: <IP_ADDRESS>
Content-Length: 4772
User-Agent: docker/1.11.0 go/go1.5.4 git-commit/a5315b8 kernel/4.4.6 os/linux arch/amd64 UpstreamClient(Docker-Client/1.11.0 \(darwin\))
Accept-Encoding: gzip

{<some big secret JSON here :) >}

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Basic
Date: Thu, 28 Apr 2016 12:50:19 GMT
Content-Length: 188

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Name":"echo","Action":"pull"},{"Type":"repository","Name":"echo","Action":"push"}]}]}

@noxiouz It would be helpful seeing the request that comes directly out of the engine to know if the authorization header was no added, or if it was stripped by the proxy.
@adezdl likewise more information about the request that came out of the engine. If you cannot get that debug logs from the engine will be helpful. Does it also seem as though some requests succeed and some fail (for example just PATCH requests fail). I am assuming authorization is not always being stripped since the login succeeded fine.

@dmcgowan Do you want tcpdump between Docker and nginx? It requires to switch off https

@noxiouz That is what I want. There are plenty of tools which will do https mitm if you are able to update your certificate list for it.

That's what I can provide now. I add insecure-registry to use http.
PATCH /v2/echo/blobs/uploads/2bcf7d5e-5456-473a-893a-741cad3a6f3b?_state=huFzHJcUG9ptT1Q3xY-TQImh6SfrwrmJnKUWZJ7gHKR7Ik5hbWUiOiJlY2hvIiwiVVVJRCI6IjJiY2Y3ZDVlLTU0NTYtNDczYS04OTNhLTc0MWNhZDNhNmYzYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxNi0wNC0yOFQyMTo0MjowMy45NjYxOTc1MDVaIn0%3D HTTP/1.1
Host: registry.yandex.net
User-Agent: docker/1.11.0 go/go1.5.4 git-commit/a5315b8 kernel/4.4.6-moby os/linux arch/amd64 UpstreamClient(Docker-Client/1.11.0 \(darwin\))
Transfer-Encoding: chunked
Accept-Encoding: gzip
Connection: close

HTTP/1.1 401 Unauthorized
Server: nginx/1.8.1
Date: Thu, 28 Apr 2016 21:42:04 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 188
Connection: close
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Basic

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Name":"echo","Action":"pull"},{"Type":"repository","Name":"echo","Action":"push"}]}]}

@noxiouz thanks. I don't think the server side packets will be helpful since it appears the Authorization header is missing leaving the engine. Engine debug logs may be useful in this case. Does the previous HTTP still have the Authorization and Location header?

I tried 1.11 on linux on the same host where registry is and eliminate nginx, and it works. I need some time to investigate reproducing conditions.

Closing as wildly outdated. Feel free to reopen.


Finally pushing to main from cleaning

After 36 commits and about a month of work, the cleaning branch has fulfilled its purpose.

Yeah, I removed the .NET tests, I'll fix them later.


Have a second worksheet in each spreadsheet file that contains some options for the generated page...

Have a second worksheet in each spreadsheet file that contains some options for the generated page...
Originally posted by @jlord in https://github.com/jlord/sheetsee.js/issues/26

Please find attached


more control over focus mode

Provides finer control over focus mode. Now their are four modes where
you change choose from.

Thanks for the PR and your patience in getting this merged.

Somehow I got lost. Where and how do I set the focus mode?


How to use Keras + tensorflow datasets and custom callbacks with validation datasets

Hello,
recently I've started to work with Keras together with tensorflow datasets.
The API I use is following:

I create net which inputs are tf.Tensors generated by iterator
Then I compile the model, by providing target tensors: target_tensors

model.compile(Adam(lr=lr), loss=losses, metrics=metrics, target_tensors=target_tensors)

Then fit the model by calling model.fit(...)

However, it's not clear to me how could I add validation datasets into training loop, like it was done in previous API. I understand that datasets are quite new in Keras, but maybe there are some examples which could be useful.
Thanks in advance.

I'm not sure whether I understand your question correctly. There are two easy ways in which you can include validation data in the training process:

Tell the model.fit() function to use part of your training data for validation, e.g.
model.fit(x, y, validation_split=0.3)

Tell the model.fit() function which validation data to use
model.fit(x, y, validation_data=(x_val, y_val))

Hi, thanks for answer, however my question was about how to add properly evaluation on validation data when working with tensorflow datasets API, which reads data directly from tfrecords. I mean this. Normally, I read data from e.g. *.tfrecords files and create model which inputs tensors take data from tf dataset. So basically for training data I run:
...
iterator = dataset.make_initializable_iterator()
training_filenames = ["/var/data/file1.tfrecord", "/var/data/file2.tfrecord"]
sess.run(iterator.initializer, feed_dict={filenames: training_filenames})

The workaround for my problem would be to write special callback, which evaluates model after each epoch on other dataset which reads from validation_filenames and then switch back to training_filenames. This works, but maybe there is a simpler one.


Combobox: Add select none pattern to read only variant (aka Picklist)

Fixes #2828
Fixes #2843
There is no SLDS pattern for this on the website. Selection of none, passes empty value and does not pass "none" to the onChange event.
Additional description
Demo:

CONTRIBUTOR checklist (do not remove)
Please complete for every pull request

[ ] First-time contributors should sign the Contributor License Agreement.  If you haven't before, wait a few minutes and a bot will comment on this pull request with instructions.
[x] npm run lint:fix has been run and linting passes.
[x] Mocha, Jest (Storyshots), and components/component-docs.json CI tests pass (npm test).
[x] Tests have been added for new props to prevent regressions in the future. See readme.
[x] Review the appropriate Storybook stories. Open http://localhost:9001/.
[x] Review tests are passing in the browser. Open http://localhost:8001/.
[ ] Review markup conforms to SLDS by looking at DOM snapshot strings.

REVIEWER checklist (do not remove)

[ ] TravisCI tests pass. This includes linting, Mocha, Jest, Storyshots, and components/component-docs.json tests.
[ ] Tests have been added for new props to prevent regressions in the future. See readme.
[ ] Review the appropriate Storybook stories. Open http://localhost:9001/.
[ ] The Accessibility panel of each Storybook story has 0 violations (aXe). Open http://localhost:9001/.
[ ] Review tests are passing in the browser. Open http://localhost:8001/.
[ ] Review markup conforms to SLDS by looking at DOM snapshot strings.

Required only if there are markup / UX changes

[ ] Add year-first date and commit SHA to last-slds-markup-review in package.json and push.
[ ] Request a review of the deployed Heroku app by the Salesforce UX Accessibility Team.
[ ] Add year-first review date, and commit SHA, last-accessibility-review, to package.json and push.
[ ] While the contributor's branch is checked out, run npm run local-update within locally cloned site repo to confirm the site will function correctly at the next release.

Thanks Gary!


New rule around use of negative variables.

I've made the mistake, and seen it often, of people doing
margin: 0 -$spacing-xs;

meaning to just have horizontal negative margin.
However, SCSS interprets it as a subtraction, and interprets it as
margin: -$spacing-xs;

Can we make a lint rule around this somehow? Maybe recommending parenthesis around expressions with -, or looking for the -$ pattern?

+1

Thanks for the suggestion, I'll tag it.

Hello, we've just run into this and possible "workaround" is:  margin: 0 (-$spacing-xs);

this is the correct way: margin: 0 -#{$spacing-xs};


[Pull Request] Detaching cost calculation into a function and introducing new filters

Detached new cost as separate function
the <int> getAttributeUpCost(key).

Added new filters at AttributeManager for {cost} (AttributeUpCost) and {invested} (InvestedAttribute)

Tomorrow I'm gonna check some functions which are recalcluating spent aka invested attribute points at PlayerData.java
regarding this function:
public int getInvestedAttribute(String key) { return attributes.getOrDefault(key.toLowerCase(), 0); }

It may conflict with these new methods

Yeah we'll need to check if distinguish spentAttributes is necessary
but there's attribPoints and attributes but calculating
(line 90 at PlayerData.java) It regards this PlayerData hashmap: HashMap<String, Integer> attributes
(line 403 at PlayerData.java) Check if the distinguish is necessary
Maybe only small fixes are necessary at (line 369)
    public int getInvestedAttribute(String key) {
        return attributes.getOrDefault(key.toLowerCase(), 0);
    }

To the:
    public int getInvestedAttribute(String key) {
        return attribPoints.getOrDefault(key.toLowerCase(), 0);
    }

Almost done here for next pull request with PlayerData fixes

Changelog:
Attribute stage, cost_base and cost_modifier were introduced.
cost_base and cost_modifier are available at attributes.yml file.
cost_base: 1 - cost_base is a base cost of one upgrade of the attr stage. in this e.g. initial costs is 1
cost_modifier: 0.33334 - cost_modifier is a modifier to the base cost for each stage of the upgrade. in this e.g. costs will increase every 3
so:
cost_base - initial cost of an attr upgrade
cost_modifier - incremental value increasing cost_base for each of the attr upgrade
Filters for attribute manager has been updated to according changes.
New placeholders for icon-lores:
{amount} - the stage value for invested points.
{total} - the stage value for invested points and class modifiers.
{max} - max stage value player can invest the attr points.
{cost} - cost in attr points for an upgrade to the next stage.
{invested} - total spent attr points for the attr.
{ap} - current value of attr points.

I think this is looking good, though could you revert changes in the .github folder and resolve merge conflicts for me?

I think this is looking good, though could you revert changes in the .github folder and pom.xml and resolve merge conflicts for me?

Rolled back them 😊~


Question: Will there be a macOS version?

I don't own a computer with windows, so i just wondered if there will be a macOS version anytime soon (I know there are other solutions in browser, but there are some features that are missing there, like trace notes and speed adjustments)

No plans for a mac version but you can use wine (there is a guide in the wiki). Be careful tho because GLFW is broken on mac and vsync does not work.


Add function to convert byte size to string

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

Project coverage is 100.00%. Comparing base (87aea52) to head (e8b7d8e).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #598   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           71        71
  Lines         1867      1879   +12
  Branches       219       223    +4
=========================================
+ Hits          1867      1879   +12

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


cutorch fails on getDeviceCount()

Installed torch, cuda.
test.py
import lutorpy as lua
lua.require('cutorch')

Output:
THCudaCheck FAIL file=/home/serj/torch/extra/cutorch/lib/THC/THCGeneral.c line=66 error=30 : unknown error
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    lua.require('cutorch')
  File "/home/serj/work/beautytorch/venv/local/lib/python2.7/site-packages/lutorpy/__init__.py", line 112, in require
    ret = luaRuntime.require(module_name)
  File "lutorpy/_lupa.pyx", line 318, in lutorpy._lupa.LuaRuntime.require (lutorpy/_lupa.c:6189)
  File "lutorpy/_lupa.pyx", line 1658, in lutorpy._lupa.call_lua (lutorpy/_lupa.c:25877)
  File "lutorpy/_lupa.pyx", line 1667, in lutorpy._lupa.execute_lua_call (lutorpy/_lupa.c:25987)
  File "lutorpy/_lupa.pyx", line 1620, in lutorpy._lupa.raise_lua_error (lutorpy/_lupa.c:25297)
lutorpy._lupa.LuaError: cuda runtime error (30) : unknown error at /home/serj/torch/extra/cutorch/lib/THC/THCGeneral.c:66

Related code:
{
  if (!state->cudaDeviceAllocator) {
    state->cudaDeviceAllocator = &defaultDeviceAllocator;
  }
  if (!state->cudaHostAllocator) {
    state->cudaHostAllocator = &THCudaHostAllocator;
  }
  if (!state->cudaUVAAllocator) {
    state->cudaUVAAllocator = &THCUVAAllocator;
  }

  int numDevices = 0;
  THCudaCheck(cudaGetDeviceCount(&numDevices)); // FAILS HERE!!!

Maybe the problem relates to the fact that my GPU is not NVidia, but cutorch is needed as a part of 3-rd party project which I'm trying to use

Please do not post the same question at multiple places. It is useless and creates a lot of noise.
cutorch/cunn only supports nvidia CUDA devices as explained here

Thanks for your comment.

cutorch/cunn only supports nvidia CUDA devices as explained here

Sure. Can I avoid crash when importing as a part of a bigger project, sometimes running with non-supported devices?

Do not require it? You won't be able to use anything from it anyway.

I would use other parts of the enclosing project. Do you mean it should fail in this situation by design? I suggest some other control path.

Any workaround ?...

Make sure the library does not require cutorch, cunn or cudnn when gpu_mode is set to false.

The problem is that I need those requirements. If I can do without them finally, there will be no issue (I don't like to spend your time).
This is the example code. It converts GPU model to CPU model so that I could run it without NVidia GPU.

--
-- Convert GPU model to CPU compatible version
-- Author: Eren Golge -<EMAIL_ADDRESS>require 'torch'
require 'cudnn'
require 'nn'
require 'cunn'
require "models/dropresnet"
cmd = torch.CmdLine()
cmd:text()
cmd:text()
cmd:text('convert GPU model to CPU version')
cmd:text()
cmd:text('Options')
cmd:option('-loadPath','','Path to load GPU model.')
cmd:option('-savePath','', 'Path to save CPU model')
cmd:text()
params = cmd:parse(arg)
print(params.loadPath)
local model = torch.load(params.loadPath)
model_cpu = cudnn.convert(model, nn):float()
torch.save(params.savePath, model_cpu)

As you can see the task doesn't require the hardware (does it?). At the same time it will fail on torch.load() without cudnn and cunn.

/home/serj/torch/install/share/lua/5.1/torch/File.lua:343: unknown Torch class <cudnn.SpatialConvolution>

The thing is that if you have a GPU model (with modules built to run on GPU and parameters in CUDA tensors), you need cutorch and cunn to load them. Unfortunately there is no workaround: you need a CUDA device to load a torch GPU model.
The simplest thing to do is to ask whoever gave you the GPU model (or someone with a GPU) to run the conversion script locally and give you the CPU model directly.

Thanks a lot, this is much helpful.


Support for inital starting acceleration?

Hi there, thanks for publishing your s-curve implementation!
I've been hunting around the net for an implementation that also accounts for an initial acceleration. I noticed that your implementation handles initial velocity, though assumes an initial acceleration of 0.0. The reason I'm interested in handling the initial acceleration is that I'm currently working with an interactive, kinetic artwork where the actuators' target positions change in real-time. I've been considering implementing something inspired by this paper, though am curious whether you have another approach in mind that you'd consider implementing in this crate?

Hi,
my implementation is based on the book "Trajectory Planning for Automatic Machinesand Robots" by Luigi Biagotti and Claudio Melchiorri. The book always assumes an initial acceleration of zero and that was enough for my needs. Therefore, I didn't spend any time on this. However, I already heard from other people that it would be nice if you could also specify initial and end acceleration. I haven't looked into the paper in detail but it looks good to me. So if you open a merge request I would happily merge it :sweat_smile:


Link to blog post url

The link in the readme to the blog post: https://www.naksyn.com/cobalt strike/2024/04/15/raising-beacons-without-UDRLs-teaching-how-to-sleep.html shows as 404 Not Found
This appears to be the correct url: https://www.naksyn.com/cobalt strike/2024/07/02/raising-beacons-without-UDRLs-teaching-how-to-sleep.html

thanks, fixed


Markdown support

@diasdavid, I saw that you are using markdown on features description. I didn't know we should be supporting that. I've found a library (react-markdown) that handles it very well. Can you please tell me in which sections we should support markdown?

It's useful to be able to addr urls to the description of some sections. Markdown or html, both work for me.


examples: Use web-time instead of instant

Recently, instant has been marked as unmaintained by the maintainer. A suggested replacement is web-time, which is used by winit and is already in our dependency tree.

This conflicts with both #590 and #593, but I'm happy to rebase as needed.


nodeId returned by events should be number as DrawflowNode::id

Not a big issue, but on events that returns the nodeId, the nodeId is a string, but DrawflowNode::id is a number.
User that needs to compare DrawfowNode to this nodeId have to cast the nodeId.

Thanks for pull request. I will check it! I do not have much time.


Images missing when using Swift Package Manager

Embedded resources were added in Swift 5.3, otherwise images for credit card types and any other assets is not showing up. Please see #198 for implementation, hopefully PR or steps are applied to canary.

We will check this. The problem here is that SwiftPM and CocoaPods use different Bundle or image resources. We should find solution that it works for all distribution frameworks.

SwiftPM need different bundle then CocoaPods. We are working on workaround to make it available when integrating SDK with each dependency manager.

@basememara we did update bundle resources in v1.7.2.


Fix delay

Delay is inaccurate if you attempt to delay for more than 1<<24 cycles. See this f4 PR This PR is identical. Props to @jamesmunns for writing this, and helping me on Matrix chat.

Hey just a quick tip: Before you have to close PRs, because you branched from the wrong commit, you can also you git rebase and then force push on your branch.
(git rebase --interactiv is also a really useful command  to cleanup commit histories :) )

Thanks for the tip on rebase. I'll check out the interaction flag. I've been extra struggling with rebase lately due to merge conflicts in cargo.toml.

@Sh3Rm4n once did a nice introduction on rebase for me. I summed it up in my personal documentation and am willing to clutter this PR with the totally unrelated information. here you go:
reabse
select new base
Option 1: see the logs (git log --all --decorate --oneline --graph) for the commit hash to rebase to and call git rebase -i <hash>
Option 2: rebase to a known branch (e.g. master) git rebase -i master
select targets
Your editor opens. See the text at the end on how to select different commits. On exiting the editor, git attempts to rebase the script.
If everything works, you’re done :tada:
If not:
resolve the conflicts step by step
See the conflict: git diff will print the filename. Let's say it's /PATH/TO/FILE
Option A: You simply want to pic an existing one
git checkout --SELECTION /PATH/TO/FILE
where SELECTION is

--ours if the solution from the base branch is what you want
--theirs if the solution from the fork is what you want

Option B: Manual modifications are needed
Edit the file like you normally would
continue
git add /PATH/TO/FILE
git rebase --continue

This is by no means exhaustive, but it helps me a lot when I'm rebase'ing once a month


background.js probably broken on firefox

The api is slightly different for firefox and chrome. In firefox it uses browser instead of chrome as seen here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/Runtime/onMessage#Syntax
So my assumption is that the methods for firefox does not work in firefox.

@jonathan-s are you sure it's not working?
I know that firefox supported chrome as a way to make chrome extensions easily workable on firefox.

I'm not 100% sure. I'd need to check, so created an issue to flag this potential issue.

Looks like it should be mostly compatible -> https://extensionworkshop.com/documentation/develop/porting-a-google-chrome-extension/
And a list of incompatibilities -> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities
So I'll close this issue. Browser testing should be able to find out any issues as well.

Some way to have automatic testing of extensions would be really cool to have. As the search plugins break sometimes due to changes in the search engines sites. It would also see issues with new api changes in the browsers themselves.