Assertion failure in -[UICollectionViewData layoutAttributesForSupplementaryElementOfKind:atIndexPath:]

Hey guys,
I just came across a crash while trying to work with supplementary views in a section controller using the IGListSupplementaryViewSource protocol. Nothing fancy going on with the collection view layout, just using the default UICollectionViewFlowLayout on the collection view. See the assertion failure below:
2017-08-31 13:26:17.194 IGListKitExamples[2181:15665308] *** Assertion failure in -[UICollectionViewData layoutAttributesForSupplementaryElementOfKind:atIndexPath:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3600.7.47/UICollectionViewData.m:994
no UICollectionViewLayoutAttributes instance for -layoutAttributesForSupplementaryElementOfKind: UICollectionElementKindSectionFooter at path <NSIndexPath: 0xc000000000000016> {length = 2, path = 0 - 0}
(null)

To provide some context, the collection view is displaying a list of items using an ItemSectionController. This is the only section controller type being returned to the list adapter. There is a search field in the navigation bar, and text input is used to filter the results and sort by relevance. The section controller conforms to IGListSupplementaryViewSource, and returns a supplementary view of kind UICollectionElementKindSectionFooter if self.isLastSection is YES.
So this means you would see a list of results, and below the last cell a supplementary view is displayed with a label saying there are no more results. Note: Before switching over to using a supplementary view for this, it was set up to be its own section controller.
I thought I would checkout the IGListKitExamples to verify if I could reproduce the same issue. The perfect demo to test is the Search Autocomplete example provided. It's very similar to our app. I setup a new supplementary view for a footer, and made LabelSectionController conform to ListSupplementaryViewSource. At this point the crash is not reproducible, so I continued to investigate. I noticed the SearchViewController always returns a SearchSectionController which contains the search bar. So I got rid of the SearchSectionController and used a UISearchBar in the navigation bar. Now, the issue is reproducible.
So it seems that if the section controller that contains a supplementary view is moving to the first index path, it crashes. In the example app, the SearchSectionController is always the first index path so this doesn't crash. In fact, I checked this theory against our app and if I returned a different section controller as the first index path, it does not crash.
New issue checklist

[x] I have reviewed the README and documentation
[x] I have searched existing issues and this is not a duplicate

General information

IGListKit version: 3.1.0
iOS version(s): iOS 10.3.1
CocoaPods/Carthage version:
Xcode version: Xcode 8.3.1
Devices/Simulators affected: iPhone 7, iPad Air 2
Reproducible in the demo project? (Yes/No): Yes, with modifications
Related issues:

Debug information
# Please include debug logs using the following lldb command:
po [IGListDebugger dump]
IGListAdapter 0x608000141ef0:
  Updater type: IGListAdapterUpdater
  Data source: <IGListKitExamples.SearchViewController: 0x7fe1f4502e20>
  Collection view delegate: (null)
  Scroll view delegate: (null)
  Is in update block: No
  View controller: <IGListKitExamples.SearchViewController: 0x7fe1f4502e20>
  Is prefetching enabled: No
  Registered cell classes:
  {(
    IGListKitExamples.LabelCell
)}
  Registered supplementary view nib names:
  {(
    FooterView
)}
  IGListAdapterUpdater instance 0x6080000d6dc0:
    Moves as deletes+inserts: No
    Allows background reloading: Yes
    Has queued reload data: No
    Queued update is animated: Yes
    State: Executed batch update block
    Batch update data:
      Insert sections: <_NSCachedIndexSet: 0x60800003c9e0>(no indexes)
      Delete sections: <_NSCachedIndexSet: 0x60800003c9e0>(no indexes)
      Move from section 3 to 0
      Move from section 2 to 1
      Move from section 1 to 2
      Move from section 0 to 3
  Section map details:
    Object and section controller at section: 0:
      tacos
      <IGListKitExamples.LabelSectionController: 0x6080001331a0>
    Object and section controller at section: 1:
      viral
      <IGListKitExamples.LabelSectionController: 0x608000133100>
    Object and section controller at section: 2:
      skateboard
      <IGListKitExamples.LabelSectionController: 0x608000133060>
    Object and section controller at section: 3:
      Humblebrag
      <IGListKitExamples.LabelSectionController: 0x608000132fc0>
  Previous section map details:
    Object and section controller at section: 0:
      Humblebrag
      <IGListKitExamples.LabelSectionController: 0x608000132fc0>
    Object and section controller at section: 1:
      skateboard
      <IGListKitExamples.LabelSectionController: 0x608000133060>
    Object and section controller at section: 2:
      viral
      <IGListKitExamples.LabelSectionController: 0x608000133100>
    Object and section controller at section: 3:
      tacos
      <IGListKitExamples.LabelSectionController: 0x6080001331a0>
  Collection view details:
    Class: UICollectionView, instance: 0x7fe1f5846400
    Data source: <IGListAdapter: 0x608000141ef0>
    Delegate: <IGListAdapter: 0x608000141ef0>
    Layout: <UICollectionViewFlowLayout: 0x7fe1f4502250>
    Frame: {{0, 0}, {375, 667}}, bounds: {{0, -64}, {375, 667}}
    Number of sections: 4
      1 items in section 0
      1 items in section 1
      1 items in section 2
      1 items in section 3
    Visible cell details:
      Visible cell at section 0, item 0:
      <IGListKitExamples.LabelCell: 0x7fe1f460aa60; baseClass = UICollectionViewCell; frame = (0 0; 375 55); text = 'Humblebrag'; layer = <CALayer: 0x60000023d980>>
      Visible cell at section 1, item 0:
      <IGListKitExamples.LabelCell: 0x7fe1f46070b0; baseClass = UICollectionViewCell; frame = (0 55; 375 55); text = 'skateboard'; layer = <CALayer: 0x60000023e2e0>>
      Visible cell at section 2, item 0:
      <IGListKitExamples.LabelCell: 0x7fe1f46150f0; baseClass = UICollectionViewCell; frame = (0 110; 375 55); text = 'viral'; layer = <CALayer: 0x60000023d360>>
      Visible cell at section 3, item 0:
      <IGListKitExamples.LabelCell: 0x7fe1f4615890; baseClass = UICollectionViewCell; frame = (0 165; 375 55); text = 'tacos'; layer = <CALayer: 0x60000023ed80>>
IGListAdapter 0x6080001413f0:
  Updater type: IGListAdapterUpdater
  Data source: <IGListKitExamples.DemosViewController: 0x7fe1f4700b50>
  Collection view delegate: (null)
  Scroll view delegate: (null)
  Is in update block: No
  View controller: <IGListKitExamples.DemosViewController: 0x7fe1f4700b50>
  Is prefetching enabled: No
  Registered cell classes:
  {(
    IGListKitExamples.LabelCell
)}
  IGListAdapterUpdater instance 0x6080000d9670:
    Moves as deletes+inserts: No
    Allows background reloading: Yes
    Has queued reload data: No
    Queued update is animated: Yes
    State: Idle
  Section map details:
    Object and section controller at section: 0:
      <IGListKitExamples.DemoItem: 0x60800009a4f0>
      <IGListKitExamples.DemoSectionController: 0x6080000f9200>
  Collection view details:
    Class: UICollectionView, instance: 0x7fe1f6019c00
    Data source: <IGListAdapter: 0x6080001413f0>
    Delegate: <IGListAdapter: 0x6080001413f0>
    Layout: <UICollectionViewFlowLayout: 0x7fe1f4707010>
    Frame: {{0, 0}, {375, 667}}, bounds: {{0, 0}, {375, 667}}
    Number of sections: 1
      1 items in section 0
    Visible cell details:
      Visible cell at section 0, item 0:
      <IGListKitExamples.LabelCell: 0x7fe1f4602500; baseClass = UICollectionViewCell; frame = (0 0; 375 55); text = 'Search Autocomplete'; layer = <CALayer: 0x60000023d440>>

@MathieuWhite thanks for the report! So from the debug dump, I can see that

You're using UICollectionViewFlowLayout
The footer suppl view is created from a XIB called FooterView

Is that right?
Could you provide a zip of the example project setup that can repro the crash? That way I can look into it a little deeper. I'm unclear if this is an issue w/ IGListKit or some UIKit bug w/ UICollectionViewFlowLayout.

@rnystrom Yes, that is exactly the layout and supplementary view used.
Here is a zip of the example project setup used.
You can launch the iOS Example.
To reproduce this issue, type the letter 'T' in the search bar.
IGListKit-SupplementaryFooter.zip

@MathieuWhite your bug is in dynamically changing if a supplementary view exists or not in supportedElementKinds. UICollectionViewFlowLayout isn't meant to dynamically insert/remove supplementary views w/out calling invalidateLayout. A SO question that is exactly the same issue:
https://stackoverflow.com/questions/30153793/crash-on-collectionview-performbatchupdates-when-trying-to-hide-footer-header
One solution is to move the isLastSection check to the size and use a non-zero size.
func sizeForSupplementaryView(ofKind elementKind: String, at index: Int) -> CGSize {
    guard let width = collectionContext?.containerSize.width else {
        fatalError()
    }
    return CGSize(width: width, height: isLastSection ? 40.0 : 0.01)
}

I verified that this works. A little bit of a hack, but since this is a limitation of UICollectionViewFlowLayout I'm going to go ahead and close this.

Thanks for the quick turnaround, @rnystrom!
Much appreciated.


networking.nat - can't access services on the NAT box host

Describe the bug
I have a bit of a NAT scenario that doesn't work. Either due to a bug in the scripted NAT setup or due to gaps in my understanding/expectations here.

Physical Network: <IP_ADDRESS>/24.
Gateway is <IP_ADDRESS>.
Clients:

xeep: <IP_ADDRESS>
denon_receiver: <IP_ADDRESS>

I have a WG interface configured to live on <IP_ADDRESS>. It has two clients. The clients connect fine.
wg_client0 can (when forcing ALL connections through the VPN via Android 10) access: the Internet, other LAN devices (aka, the denon receiver). But NOT services on the WG host itself <IP_ADDRESS>.
I have Home-Assistant running, for example, but the same thing happens when I try to just start python3. In both cases I've confirmed they're listening on all interfaces.
networking.nat = {
  enable = true;
  internalInterfaces = [ "wg0" ];
  externalInterface = "eth0";
}

I've also tried with forwardPorts like so ....
networking.nat.forwardPorts = [
  { destination="<IP_ADDRESS>:8123"; proto="tcp"; sourcePort=8123; }
];

But no matter what I do I can't access services on the NAT host.
Additional problems: I have limited experience with iptables (and what I have came from lots of reading last night), and I'm not even sure what level of support there is for this. But I can't imagine I'm the only one trying to run an additional accessible service on a VPN host/gateway.

pinging some NAT module contributors: @volth @ryantrinkle @lovesegfault

Is it related?
https://github.com/NixOS/nixpkgs/pull/35161

I'm not sure. I'm pretty confused and I've looked at this on a few occasions. I'm not sure that I actually want anything related to forwardPorts. If I think of the analogue of a router with forwarded ports... that's not what I'm looking for.
In the picture below, the wireguard client can access the receiver server, but cannnot access the python server running on the wireguard/web server.
My expectation is that it should be accessible via <IP_ADDRESS>:8000 (possibly also <IP_ADDRESS>:8000 as well).
                  +--------------------------------------------------+
+-------------+   |  +--------------------------+  +----------------+|
| <IP_ADDRESS> |   |  |                          |  |                ||
| wg client   |   |  | wireguard/web server     |  | receiver       ||
+-------------+   |  | <IP_ADDRESS> (en....)    |  | <IP_ADDRESS>  ||
        |         |  | <IP_ADDRESS>/24 (wgo)     |  |                ||
        |------------------------------wg0- -----------> OK!        ||
                  |  |                          |  |                ||
                  |  | python3 -m http.server   |  +----------------+|
                  |  | (http://<IP_ADDRESS>:8000)    |                    |
                  |  +--------------------------+                    |
                  |           home network = <IP_ADDRESS>/24          |
                  +--------------------------------------------------+

It looks like it simply came down to updating networking.firewall.allowedTCPPorts to allow access to home-assistant's port (or in my example, the python server port). Ouch.
I know the discussion about default opening ports has been had but it'd be cool to have a linter/warning system/tool that could tell users about potential misconfigurations. (If the user wanted to only run it locally, they could hint/declare this somehow, via some mechanism I'm handwaving into existence).


Make it possible to use repl getting the contract's abi from etherscan when is possible

There are some cases where the contract source code have been verified in Etherscan, for example this one dai, in those cases would be great if there is an option to start repl mode without passing the abi explicitly. Like how is it doing for ERC20 tokens.
Perhaps it could be something like: eth repl etherscanAbi@contractAddress

Some notes for whomever implements this (including maybe my future self) after a failed attempt at doing it.
Interface
I think the most ergonomic interface is:
eth repl --mainnet https://etherscan.io/token/0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359

You could argue that the --mainnet is redundant, since the network could be inferred from the etherscan URL, but let's just not go there. Note that the token in the URL could also be address and the result should be pretty much the same.
Also, I have no idea what name should be used for the loaded contract.
Detecting URLs as arguments
Here's a working RegExp:
const etherscanUrlPattern = new RegExp('^https?://etherscan.io/(?:address|token)/((?:0x)?\\w{40})')

And you can use it like this to extract the address:
    const etherscanMatch = arg.match(etherscanUrlPattern)
    if (etherscanMatch) {
      const address = etherscanMatch[1]
    }

Obtaining the ABI
After obtaining the address, you can use this endpoint for getting the ABI:
https://api.etherscan.io/api?module=contract&action=getabi&address=${address}

This might be an unauthorized use of the Etherscan API, I don't know. If that's the case, we could require an Etherscan API Key, although that would make this feature a lot less useful. Alternatively, we could bundle an API Key with eth-cli, if that's allowed.
Where to fetch the ABI
This is the part where I stumbled. I tried to do it inside loadABI, but that means converting it to an async function, and that caused a lot of other dependent functions to be converted too. I think we should do a big refactor and make a function that receives the raw arg and returns an object with the name, address and ABI. This function should be completely tested, since it would implement a logic that will be used in a lot of places.


Avoid modifying frozen string

Attempts to fix a spec failure in https://github.com/dependabot/dependabot-core/pull/7929.

Closing as this was fixed in https://github.com/dependabot/dependabot-core/pull/7926


Prevent admins from walking out non-existent exits.

This just prevents a condition where unquelled exploration can result in the admin user going through a door to a square of map that doesn't exist.  I don't know if this belongs in minimud or in the wilderness contrib, but I feel like it should exist somewhere.

It's a good question, but yeah, this is the sort of PR that should be put against the contrib itself. Personally though, having actually run into this issue before, I'm inclined to leave it to help emphasize that you should never do testing as superuser. ;)

Okay, I'll suggest it over there.


Export the root object

Instead of importing functions individually
import { compose, mapProps, pure, withHandlers ... } from 'recompose'

we can just import the root object
import Rc from 'recompose'

One of the benefit of importing the root object is preserving the namespace, which is useful when we use recompose with other functional libraries.
Considering optimizing the bundle size, we can still use babel-lodash-plugin.

curious, what's the advantage for users to do
import Rc from 'recompose'

instead of
import * as Rc from 'recompose'

?

@nfcampos both works similarly. As you can see, I also use import * as ... here.
IMHO import Rc from 'recompose is more concise and kind of a convention now.

I am getting used to import * as ... now, so I am going to close this issue.


Cannot open /dev/tty0

Hi
I have this error when i try to start my xubuntu with startxfce4
I have already try to update my crouton, on the process i got the same  error
xf86OpenConsole: Cannot open /dev/tty0
How can I fix it? please help?

I Fix it!

I Fix it!

Cool, let us know how so we can all learn from it.


Tune Cassandra options for faster startup

We never attempted at tuning Cassandra options to make it start faster. Apparently, there are a few low hanging fruits (focused on single-node scenario) that make it start significantly faster:
Before:
Container cassandra:3.11.2 started in PT32.628781S

After:
Container cassandra:3.11.2 started in PT10.720409S

@kiview yep! (are you also thinking about BitBucket? ;))


Fractal Pyramid

I would you like add Fractal Pyramid collection for the community.

I can't find the error for the moment... Someone can help me ? Thanks :)

hi, can't find the inscriptions in your collection.
e.g, 8b8e1d9d50123583c25121e0a867871f9b98acf503c7acae0fae1cf0a23139aai0

Please have a check first. And please also add your discord or twitter account link in the meta.json file.
@IBW3B


MacOS Big Sur freezing issue

Hey @CLAY-BIOS , let me start with showing my gratitude for the wonderful work that you have done here. So Thank you.
After installing MacOS Big Sur and using your EFIs, I find the system crash and freezing. Sometime it just go to login screen. Sometimes mouse pointer goes missing and screen freezes nothing works ( I have to restart with long press power button). Sometimes in idle situation it freezes (like I am browsing and all of sudden everything stops working).
I have verified that Memory/CPU usages is very low/idle at the time of issue. Please guide me if I am doing anything wrong which causes these issues.
Thanks.

Ok. So after disabling 'FeatureUnlock.kext' it's working fine. No freezing issue till now.

@PeaShooterR do you know why big sur is taking more than 40s to boot? And is there way to optimize it?

One more think my camera output video with dark filter applied with some grains. Do you know what is the issue here?

I'm glad it helped!
It takes me the same time to boot, you mean too slow?
This is my first time using hackintosh, I thought this was normal, idk.
Seems that my camera works fine.

😭 My camera output looks like black filter applied and grainny. 😞 .

It takes me the same time to boot, you mean too slow?

I read somewhere in the issues or somewhere in this repo that one guy was able to boot up in 25sec with some tweak in his EFI and he also shared his EFI. Now I am not able to find his message/issue/thread.


network_id remains empty after creating IP address resource

Greetings everyone.
I ran into an issue where the assigned network_id doesn't get saved in the terraform.tfstate file. As a result, subsequent terraform applies will destroy/recreate the IP addresses because it thinks the network_id has changed.
Edit: I'm using the latest version of this provider built against cloudstack-go v2.12. Terraform version 1.1.7. CloudStack version 4.16.1.
Here is how I create an IP address:
resource "cloudstack_ipaddress" "public_ip" {
    count = "${var.num_vms_to_create}"

    vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.mynet.id}"
}

When applying this on multiple runs, Terraform will show the following (note that network_id is being added even though the resource is created properly in CloudStack):
Terraform will perform the following actions:

  # cloudstack_ipaddress.public_ip[2] must be replaced
-/+ resource "cloudstack_ipaddress" "public_ip" {
      ~ id            = "c823415a-32d4-4fe1-ac7d-65e5c38b5a6b" -> (known after apply)
      ~ ip_address    = "<IP_ADDRESS>" -> (known after apply)
      ~ is_source_nat = false -> (known after apply)
      + network_id    = "0aa28065-2d46-4367-a7c0-0e065218aea5" # forces replacement
      + project       = (known after apply)
      ~ tags          = {} -> (known after apply)
        # (2 unchanged attributes hidden)
    }

The terraform.tfstate file lists the IP address with an empty network_id string.
    {
      "mode": "managed",
      "type": "cloudstack_ipaddress",
      "name": "public_ip",
      "provider": "provider[\"registry.terraform.io/cloudstack/cloudstack\"]",
      "instances": [
        {
          "index_key": 0,
          "schema_version": 0,
          "attributes": {
            "id": "2bdbc636-f6cd-47cc-b462-ae76351b993e",
            "ip_address": "<IP_ADDRESS>",
            "is_portable": false,
            "is_source_nat": false,
            "network_id": "",            <----- shouldn't be empty
            "project": "",
            "tags": {},
            "vpc_id": "5df887ba-9085-4d4b-a613-e6a7ba2e5ad4",
            "zone": null
          },
          "sensitive_attributes": [],
          "dependencies": [
            "cloudstack_network.mynet",
            "cloudstack_network_acl.default",
            "cloudstack_vpc.default"
          ]
        },

Workaround
I was able to 'fix' this issue by removing the conditional d.GetOk("network_id") and always setting network_id based on the Associatednetworkid value from the CloudStack-go library. I'm not sure why that condition would be failing though.
Any advice? Thanks!

Hi @Pearl1594 @kohrar This seems like an interesting issue, and I will start looking into it today. I am going to try reproducing it locally and will keep you folks posted with the progress.

@Damans227 side note - please link to the instructions you used to install the simulator?

@Damans227 side note - please link to the instructions you used to install the simulator?

I used mbx:
https://github.com/shapeblue/mbx

@Damans227 thx

I think I can reproduce the issue. Following is the terraform configuration and the terraform.tfstate respectively, for a public ip address being created:
resource "cloudstack_ipaddress" "public_ip" {

    vpc_id = "ce9042a1-c818-4a93-803e-f86b5d38048e"
    network_id = "b9c953a0-8686-4240-b8a4-43849f7079ff"
}

{
  "version": 4,
  "terraform_version": "1.1.7",
  "serial": 1,
  "lineage": "03e88dc2-ac88-c672-421f-26098d9ba754",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "cloudstack_ipaddress",
      "name": "public_ip",
      "provider": "provider[\"registry.terraform.io/cloudstack/cloudstack\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "f245d0d3-46e3-4549-9ad9-dc1b0379c181",
            "ip_address": "<IP_ADDRESS>",
            "is_portable": false,
            "is_source_nat": false,
            "network_id": "", <-------------------------- network id is empty
            "project": "",
            "tags": {},
            "vpc_id": "ce9042a1-c818-4a93-803e-f86b5d38048e",
            "zone": null
          },
          "sensitive_attributes": [],
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}

@kohrar So, in your workaround, how are you always setting network_id based on the Associatednetworkid?
I tested this issue further, i.e., removed the conditional to set the network_id as follows and created a new provider binary:
d.Set("network_id", ip.Associatednetworkid)

Yet, the network_id remained empty in the terraform.tfstate for me.
Interestingly, when I use the combination of zone and network_id in main.tf, the network_id alwyas gets stored in the terraform.tfstate successfully.
resource "cloudstack_ipaddress" "public_ip" {
    zone = "DC"
    network_id = "b9c953a0-8686-4240-b8a4-43849f7079ff"
}

Hi @Damans227 -- Thanks for looking into this issue.

removed the conditional ...
d.Set("network_id", ip.Associatednetworkid)

Yup, that's exactly what I did.
Would the network resource I specify make a difference? This is what I do and that also includes the zone and VPC.
# Create a new VPC
resource "cloudstack_vpc" "default" {
  name = "leo-vpc"
  display_text = "leo-vpc"
  cidr = "<IP_ADDRESS>/16"
  vpc_offering = "Default VPC offering"
  zone = "zone1"
}

# Create a new network in the VPC
resource "cloudstack_network" "leosnet" {
    name = "leo-net"
    display_text = "leo-net"
    cidr = "<IP_ADDRESS>/24"
    network_offering = "UnrestrictedIsolatedNetworkOfferingForVpcNetworks"
    acl_id = "${cloudstack_network_acl.default.id}"
    vpc_id = "${cloudstack_vpc.default.id}"
    zone = "zone1"
}

# Create a new public IP address for this network
resource "cloudstack_ipaddress" "public_ip" {
    count = "1"

    vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.leosnet.id}"
}

Are you also using the latest version of cloudstack-go when compiling the terraform provider? At the time of my original testing, I had to use https://github.com/tetra12/cloudstack-go as a replacement since the API changed in 4.16 broke a few things. I noticed that the PR was merged last week and I can re-test in the next few days with the latest version of cloudstack-go and see if the behavior remains the same.

Hi @kohrar

Would the network resource I specify make a difference? This is what I do and that also includes the zone and VPC.

Umm, can you try adding zone1 in the cloudstack_ipaddress resource and then try again? Basically, like this:
resource "cloudstack_ipaddress" "public_ip" {
    count = "1"

    vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.leosnet.id}"
    zone = "zone1"
}

Are you also using the latest version of cloudstack-go when compiling the terraform provider?

So, I didn't change the default version of  cloudstack-go imported in the resource_cloudstack_ipaddress.go file. If I follow the location of the cloudstack-go import, it takes me to v2.11.0..

Hi @Damans227
I switched back to the default terraform CloudStack provider (v0.4.0) and tried to specify a zone to the IP address resource with the same result. This is what I have:

main.tf
# Configure the CloudStack Provider
terraform {
  required_providers {
    cloudstack = {
      source = "cloudstack/cloudstack"
      version = "0.4.0"
    }
  }
}

provider "cloudstack" {
  api_url    = "${var.cloudstack_api_url}"
  api_key    = "${var.cloudstack_api_key}"
  secret_key = "${var.cloudstack_secret_key}"
}

# Create a new VPC
resource "cloudstack_vpc" "default" {
  name = "test-vpc"
  display_text = "test-vpc"
  cidr = "<IP_ADDRESS>/16"
  vpc_offering = "Default VPC offering"
  zone = "zone1"
}

# Create a new ACL
resource "cloudstack_network_acl" "default" {
    name  = "test-vpc-acl"
    vpc_id = "${cloudstack_vpc.default.id}"
}

# One ingress and one egress rule for the ACL
resource "cloudstack_network_acl_rule" "ingress" {
    acl_id = "${cloudstack_network_acl.default.id}"

    rule {
        action       = "allow"
        cidr_list    = ["<IP_ADDRESS>/8"]
        protocol     = "tcp"
        ports        = ["22"]
        traffic_type = "ingress"
    }

    rule {
        action       = "allow"
        cidr_list    = ["<IP_ADDRESS>/0"]
        protocol     = "tcp"
        ports        = ["80", "443"]
        traffic_type = "ingress"
    }
}

resource "cloudstack_network_acl_rule" "egress" {
    acl_id = "${cloudstack_network_acl.default.id}"

    rule {
        action       = "allow"
        cidr_list    = ["<IP_ADDRESS>/0"]
        protocol     = "all"
        traffic_type = "egress"
    }
}

# Create a new network in the VPC
resource "cloudstack_network" "testnet" {
    name = "test-net"
    display_text = "test-net"
    cidr = "<IP_ADDRESS>/24"
    network_offering = "UnrestrictedIsolatedNetworkOfferingForVpcNetworks"
    acl_id = "${cloudstack_network_acl.default.id}"
    vpc_id = "${cloudstack_vpc.default.id}"
    zone = "zone1"
}

# Create a new public IP address for this network
resource "cloudstack_ipaddress" "public_ip" {
    vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.testnet.id}"

    zone = "zone1"
}

# Create a port forwarding for SSH to the first VM we create
resource "cloudstack_port_forward" "ssh" {
    ip_address_id = "${cloudstack_ipaddress.public_ip.id}"

    forward {
        protocol  = "tcp"
        private_port = 22
        public_port = 22

        virtual_machine_id = "${cloudstack_instance.testvm.id}"
    }
}

# Create VMs. We can create multiples by specifying count=
resource "cloudstack_instance" "testvm" {
  name = "test-rocky1"
  zone = "zone1"
  service_offering = "rcs.c1"

  # This template was created by Packer with CloudInit support
  template = "RockyLinux 8.5, generated on 2022-04-19T17:00:43Z"
  network_id = "${cloudstack_network.testnet.id}"

  expunge = true

  user_data = <<EOF
#cloud-config

ssh_pwauth: yes
disable_root: false
chpasswd:
  list: |
    root:password
  expire: false

EOF
}

terraform apply output

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # cloudstack_instance.testvm will be created
  + resource "cloudstack_instance" "testvm" {
      + display_name     = (known after apply)
      + expunge          = true
      + group            = (known after apply)
      + id               = (known after apply)
      + ip_address       = (known after apply)
      + name             = "test-rocky1"
      + network_id       = (known after apply)
      + project          = (known after apply)
      + root_disk_size   = (known after apply)
      + service_offering = "rcs.c1"
      + start_vm         = true
      + tags             = (known after apply)
      + template         = "RockyLinux 8.5, generated on 2022-04-19T17:00:43Z"
      + user_data        = "f96d6fc6c87d153271bed7f13c557e517c137458"
      + zone             = "zone1"
    }

  # cloudstack_ipaddress.public_ip will be created
  + resource "cloudstack_ipaddress" "public_ip" {
      + id            = (known after apply)
      + ip_address    = (known after apply)
      + is_portable   = false
      + is_source_nat = (known after apply)
      + network_id    = (known after apply)
      + project       = (known after apply)
      + tags          = (known after apply)
      + vpc_id        = (known after apply)
      + zone          = "zone1"
    }

  # cloudstack_network.testnet will be created
  + resource "cloudstack_network" "testnet" {
      + acl_id           = (known after apply)
      + cidr             = "<IP_ADDRESS>/24"
      + display_text     = "test-net"
      + endip            = (known after apply)
      + gateway          = (known after apply)
      + id               = (known after apply)
      + name             = "test-net"
      + network_domain   = (known after apply)
      + network_offering = "UnrestrictedIsolatedNetworkOfferingForVpcNetworks"
      + project          = (known after apply)
      + source_nat_ip_id = (known after apply)
      + startip          = (known after apply)
      + tags             = (known after apply)
      + vpc_id           = (known after apply)
      + zone             = "zone1"
    }

  # cloudstack_network_acl.default will be created
  + resource "cloudstack_network_acl" "default" {
      + description = (known after apply)
      + id          = (known after apply)
      + name        = "test-vpc-acl"
      + vpc_id      = (known after apply)
    }

  # cloudstack_network_acl_rule.egress will be created
  + resource "cloudstack_network_acl_rule" "egress" {
      + acl_id      = (known after apply)
      + id          = (known after apply)
      + managed     = false
      + parallelism = 2

      + rule {
          + action       = "allow"
          + cidr_list    = [
              + "<IP_ADDRESS>/0",
            ]
          + icmp_code    = (known after apply)
          + icmp_type    = (known after apply)
          + ports        = []
          + protocol     = "all"
          + traffic_type = "egress"
          + uuids        = (known after apply)
        }
    }

  # cloudstack_network_acl_rule.ingress will be created
  + resource "cloudstack_network_acl_rule" "ingress" {
      + acl_id      = (known after apply)
      + id          = (known after apply)
      + managed     = false
      + parallelism = 2

      + rule {
          + action       = "allow"
          + cidr_list    = [
              + "<IP_ADDRESS>/0",
            ]
          + icmp_code    = (known after apply)
          + icmp_type    = (known after apply)
          + ports        = [
              + "443",
              + "80",
            ]
          + protocol     = "tcp"
          + traffic_type = "ingress"
          + uuids        = (known after apply)
        }
      + rule {
          + action       = "allow"
          + cidr_list    = [
              + "<IP_ADDRESS>/8",
            ]
          + icmp_code    = (known after apply)
          + icmp_type    = (known after apply)
          + ports        = [
              + "22",
            ]
          + protocol     = "tcp"
          + traffic_type = "ingress"
          + uuids        = (known after apply)
        }
    }

  # cloudstack_port_forward.ssh will be created
  + resource "cloudstack_port_forward" "ssh" {
      + id            = (known after apply)
      + ip_address_id = (known after apply)
      + managed       = false

      + forward {
          + private_port       = 22
          + protocol           = "tcp"
          + public_port        = 22
          + uuid               = (known after apply)
          + virtual_machine_id = (known after apply)
        }
    }

  # cloudstack_vpc.default will be created
  + resource "cloudstack_vpc" "default" {
      + cidr           = "<IP_ADDRESS>/16"
      + display_text   = "test-vpc"
      + id             = (known after apply)
      + name           = "test-vpc"
      + network_domain = (known after apply)
      + project        = (known after apply)
      + source_nat_ip  = (known after apply)
      + tags           = (known after apply)
      + vpc_offering   = "Default VPC offering"
      + zone           = "zone1"
    }

Plan: 8 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

   Resources: 8 added, 0 changed, 0 destroyed.

tfstate still has an empty value for network_id:
    {
      "mode": "managed",
      "type": "cloudstack_ipaddress",
      "name": "public_ip",
      "provider": "provider[\"registry.terraform.io/cloudstack/cloudstack\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "c1a607fa-8f3b-4264-b9db-e2654cc0430b",
            "ip_address": "<IP_ADDRESS>",
            "is_portable": false,
            "is_source_nat": false,
            "network_id": "",  <-- still empty
            "project": "",
            "tags": {},
            "vpc_id": "9b549e57-898f-4bc0-a15d-2cbb6e9362b7",
            "zone": "zone1"
          },
          "sensitive_attributes": [],
          "private": "bnVsbA==",
          "dependencies": [
            "cloudstack_network.testnet",
            "cloudstack_network_acl.default",
            "cloudstack_vpc.default"
          ]
        }
      ]
    },

So, I didn't change the default version of cloudstack-go imported in the resource_cloudstack_ipaddress.go file. If I follow the location of the cloudstack-go import, it takes me to v2.11.0.

I had to change the go.mod file so the cloudstack library uses a local copy I cloned. Basically, I appended these two lines to go.mod:
replace github.com/apache/cloudstack-go/v2 => ./cloudstack-go
exclude github.com/apache/cloudstack-go/v2 v2.11.0

Then re-run go build and copied the compiled terraform provider over the original binary.

Ok, I did some further testing, and it seems like when I define network_id and vpc_id together in an ip_address resource, the network_id ends up being stored as empty in the .tfstate file. I am not sure why that's the case, but I am looking into it.

Any update on this? Thanks!

@kohrar
I am not hitting the issue on the latest build.
Let me know if i can close the issue

Closing the issue for now as its not observed on the latest build

Hi @kiranchavala. Thanks for picking up this project.
I gave this provider a try on Apache CloudStack 4.18.1 but seem to have some issues. I compiled the provider with the most recent commits on the main branch at the time of this message and have the following results.
$ terraform -v
Terraform v1.7.4
on linux_amd64
+ provider registry.terraform.io/cloudstack/cloudstack v0.4.1

0.4.1 is what I versioned the compiled plugin to avoid confusing it with the 0.4.0 release.
Here's what I defined in my project:
resource "cloudstack_ipaddress" "galaxy_public_ip" {
    vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.galaxy-net.id}"
    zone = "zone1"
    project = "${var.cloudstack_project_id}"
}

When I apply it, I see:
Terraform will perform the following actions:

  # cloudstack_ipaddress.galaxy_public_ip will be created
  + resource "cloudstack_ipaddress" "galaxy_public_ip" {
      + id            = (known after apply)
      + ip_address    = (known after apply)
      + is_portable   = false
      + is_source_nat = (known after apply)
      + network_id    = "5282446c-a837-48a2-9e77-d3add3cfc6df"
      + project       = "d037175d-b0bc-4aaa-801b-a1a7557b4b94"
      + tags          = (known after apply)
      + vpc_id        = "38652dce-c027-4a2c-b747-0a799ec97923"
      + zone          = "zone1"
    }

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_ipaddress.galaxy_public_ip: Creating...
cloudstack_ipaddress.galaxy_public_ip: Creation complete after 1s [id=85010dc9-87e9-4f52-9ba3-3e107ea37d70]

When I look at the terraform tfstate file, network_id is still missing:
    {
      "mode": "managed",
      "type": "cloudstack_ipaddress",
      "name": "galaxy_public_ip",
      "provider": "provider[\"registry.terraform.io/cloudstack/cloudstack\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "85010dc9-87e9-4f52-9ba3-3e107ea37d70",
            "ip_address": "<IP_ADDRESS>",
            "is_portable": false,
            "is_source_nat": false,
            "network_id": "",
            "project": "d037175d-b0bc-4aaa-801b-a1a7557b4b94",
            "tags": {},
            "vpc_id": "38652dce-c027-4a2c-b747-0a799ec97923",
            "zone": "zone1"
          },

@kohrar
I am not hitting the issue on the latest build.
Let me know if i can close the issue

I noticed also your vpc_id is empty. As mentioned by @Damans227 back in May 1, 2022, this bug seems to happen when both vpc_id and network_id are defined together.

Thanks @kohrar
Able to reproduce the issue only when vpc_id and network_id are defined together.
Will look into it

associateIpAddress command ignores the networkid if vpcid is set. That is why when both vpc_id & network_id are set in the terraform, network_id is not set in the state file.
Ref. code: https://github.com/apache/cloudstack/blob/6dc3d06037c39019f29686281856443c37a3e6c0/api/src/main/java/org/apache/cloudstack/api/command/user/address/AssociateIPAddrCmd.java#L186-L189

Hi @kohrar
Could you please let me know the reason you want the network id in the  terraform state file.
If you want to use the obtained network id in some pipeline, you can achieve it via

terraform output

https://developer.hashicorp.com/terraform/language/values/outputs
output "networkid" {
value = cloudstack_ipaddress.galaxy_public_ip.network_id
}

Datasource

https://developer.hashicorp.com/terraform/language/data-sources
https://github.com/apache/cloudstack-terraform-provider/blob/main/cloudstack/data_source_cloudstack_ipaddress.go

@vishesh92 I don't think that's a valid solution. There are cases where I need to specify both VPC and network ID. For instance, when I need to assign a public IP address to a specific network within a specific VPC.
Not specifying both results in an error. Here's an example:
│ Error: Error associating a new IP address: Undefined error: {"errorcode":431,"errortext":"Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC"}
│
│   with cloudstack_ipaddress.test_public_ip,
│   on guacamole.tf line 151, in resource "cloudstack_ipaddress" "test_public_ip":
│  151: resource "cloudstack_ipaddress" "test_public_ip" {
│

This is what I'm using:
resource "cloudstack_ipaddress" "test_public_ip" {
    # vpc_id = "${cloudstack_vpc.default.id}"
    network_id = "${cloudstack_network.guacamole-net.id}"
    zone = "zone1"

    project = "${var.cloudstack_project_id}"
}

Perhaps I'm misunderstanding how public IPs are assigned to VPC and networks. I don't actually need to specify the network if I'm using VPCs.
The above example would work if I specified the VPC only as the network_id isn't necessary.

@kohrar You don't need to specify network id if you are specifying VPC. Public IPs get assigned to the VPC itself, which is the parent of its network tiers.


With Keyboard Remapping, source keys are also triggered

Microsoft PowerToys version
0.76.2
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Keyboard Manager
Steps to reproduce

Define any keymaps. e.g.

Open Text Editor

Type key which was mapped in Step 1

✔ Expected Behavior
Only see target key.
❌ Actual Behavior
We see sometimes source keys as well. e.g.

This case I only used "3" key, which I expect to see only "4".
Other Software
No response

I have problem like this for numpad digits:
https://github.com/microsoft/PowerToys/issues/32954


Terminal not working in mac OS Sierra.

I just installed and it opens a black terminal and i can't type anything.

+1

+1

+1

@ubergeekzone I installed and the issue remains.
Do i need to config something to work properly at Mac OS Sierra?

@ubergeekzone  I uninstalled the other plugin and now is running smooth.
Tks.


Redirects should not change the depth on the initial request

If allowInitialDomainChange is true crawls with maxDepth=1 will fail if depth is not reset.

Looks cool — would you mind adding a test for your desired behaviour? :)
Thanks!

Turns out that 2xx responses weren't setting _isFirstRequest to false and redirects further down the chain could cause a domain redirect if it was allowInitialDomainChange was true.
Also the depth problem was only happening if two redirects happened in a row. Sort of an edge case, but I did notice it in this type of scenario http -> https -> blogspot.com

Looks good to me! Thanks for adding the tests :+1:


Capture user stories in cypress test layout

Start laying out the cypress tests by walking through the 3 main paths users will take:

Crating a new project
Applying for a project
Awarding a project

Currently the curation process takes place outside of this app so it can be omitted from this for now.
Just go through and set up the appropriate "it" statements in a way that captures the above.

Additionally write the full test for gov user creating a CWU opportunity

This issue will be broken into smaller issues for individual tests


[BUG] Develco Heat Alarm HESZB-120

The device does not report battery status.
The device does not implemented as a IAS Zone ZigBee end point. (or it is not working correctly)
I think there's a lot of features not implemented, but I'm willing to test this device utill it's fully fuctional.
Technical manual localted here: heszb-120-technical-manual-heat-alarm.pdf
Device dignature:
{   "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.NONE: 0>, manufacturer_code=4117, maximum_buffer_size=80, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",   "endpoints": {     "1": {       "profile_id": 49353,       "device_type": "0x0001",       "in_clusters": [         "0x0003",         "0x0005",         "0x0006"       ],       "out_clusters": []     },     "35": {       "profile_id": 260,       "device_type": "0x0402",       "in_clusters": [         "0x0000",         "0x0001",         "0x0003",         "0x000f",         "0x0020",         "0x0500",         "0x0502"       ],       "out_clusters": [         "0x000a",         "0x0019"       ]     },     "38": {       "profile_id": 260,       "device_type": "0x0302",       "in_clusters": [         "0x0000",         "0x0003",         "0x0402"       ],       "out_clusters": [         "0x0003"       ]     }   },   "manufacturer": "Develco Products A/S",   "model": "HESZB-120",   "class": "zigpy.device.Device" }
heszb-120-technical-manual-heat-alarm.pdf

#1022

For me it connects in HA, displays all the settings such as temperature, binary sensor and ias_zone. However none of these update values past their first initial state when pairing.
I found a full data sheet for the clusters here: https://www.develcoproducts.com/media/1708/heszb-120-technical-manual-heat-alarm.pdf
The temperature sensor part for example should be reporting at least every 5 minutes so clearly something is wrong.
Any advice on what logs I could share to help diagnose this issue?


Server Port 5555 conflict with Android Studio's ADB

I presume that the choice of port was arbitrary, and therefore I would suggest to change the default server port from 5555 to any other one.
The reason is that it conflicts with Android Studio's ADB. I tried to change ADB's port, but I was unable to reach an happy solution.
Otherwise if a fix is known for ADB's can this be posted in the wiki?

You can change it yourself in tools/config/project.config.ts
Just add a line in the constructor:
this.PORT = 9000 // or any port number

I'm perfectly aware of that and I already did, thanks.
You also need to change protractor.conf.js if you need to test (and that's exactly why I need Android Studio).
However the point stands. If, like I assumed, the choice of port was deliberate I am pointing out that this is causing issue with a tool that may be more or less widely used and with plenty of choices for a port number there's no need to use the same that Google's Android Studio uses while developing in Google's Angular2.

IMO you can throw a dart at a port array and conflict with something which is why the seed was designed to allow configuration settings to be easily overridden to fit a developers specific project needs.
We could change the default seed port and your exact argument could be made by someone else with different needs.


[tck] ConfigValueTest should be renamed to ConfigAccessorTest

to match the ConfigAccessor API name

txs, reviewed and applied.


Replace old renderer with new renderer

This makes the New Bevy Renderer the default (and only) renderer. The new renderer isn't quite ready for the final release yet, but I want as many people as possible to start testing it so we can identify bugs and address feedback prior to release.
The examples are all ported over and operational with a few exceptions:

I removed a good portion of the examples in the shader folder. We still have some work to do in order to make these examples possible / ergonomic / worthwhile: #3120 and "high level shader material plugins" are the big ones. This is a temporary measure.
Temporarily removed the multiple_windows example: doing this properly in the new renderer will require the upcoming "render targets" changes. Same goes for the render_to_texture example.
Removed z_sort_debug: entity visibility sort info is no longer available in app logic. we could do this on the "render app" side, but i dont consider it a priority.

What bits I've seen look good, but this is effectively unreviewable due to limitations in Github's tooling. Fortunately, it's already mostly been reviewed!  IMO we should merge this ASAP and open issues for any problems with the new examples and for the missing features listed above.

Could this be split into one commit removing the old renderer and another to rename the new renderer crates? This would improve the results of git blame. Currently git blame will consider most diffs in this commit as changing the old render source rather than renaming the files of the new renderer.

Could this be split into one commit removing the old renderer and another to rename the new renderer crates? This would improve the results of git blame. Currently git blame will consider most diffs in this commit as changing the old render source rather than renaming the files of the new renderer.

Hmm I'm torn on this one. In some cases (ex: bevy_text, bevy_ui, bevy_sprite, bevy_pbr), theres enough overlap that it might be worth treating this as an iterative change rather than a wholesale replacement. That should make it easier to identify + attribute the original authors of a line of code. Even bevy_render (which was basically a full rewrite) has some largely untouched code, such as the mesh module.

Finally got CI to run the examples properly, but it now takes a very long time. Curious to see what aspect of the new renderer is causing the slowness (maybe the extra complexity from shadows?). We might want to revisit how / when we run them if the extra CI time persists.

bors r+


Suggest to link Tutorial in Readme.md

The tutorial is available at https://github.com/metaOmic/tutorial/blob/master/metaOmics_turtorial.pdf.
I am suggesting link Readme.md with tutorial.
Or can I do this myself?

We will put this in in our next release, which will also incorporate newest metaClust changes.


Fixed icons hidden in wishlist or compare page for pt_BR locale #4115

BUGS:
Link: https://github.com/bagisto/bagisto/issues/4115

resolve conflicts

resolve conflicts

Conflicts Resolved.


loading hparams as tags_csv results in Dict not Namepsace being passed to init

🐛 Bug
Doctrstring indicates:
"""                However, if your checkpoint weights don't have the hyperparameters saved,
use this method to pass in a .csv file with the hparams you'd like to use.
These will be converted into a :class:~argparse.Namespace and passed into your
:class:LightningModule for use.
"""
This does not appear to be true.
""" class PurchaseEventsClassifier(pl.LightningModule):
def init(self, hparams: Namespace):
import pdb; pdb.set_trace()
embed_params = json.loads(hparams.embed_params) """
hparams is a a dict here not a Namespace as expected.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Run '....'
Scroll down to '....'
See error

Code sample

Expected behavior
hparams loaded from tags_csv should be a Namespace
Environment
Please copy and paste the output from our
environment collection script
(or fill out the checklist below manually).
You can get the script and run it with:
wget https://raw.githubusercontent.com/PyTorchLightning/pytorch-lightning/master/tests/collect_env_details.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py

PyTorch Version (e.g., 1.0):
OS (e.g., Linux):
How you installed PyTorch (conda, pip, source):
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version:
GPU models and configuration:
Any other relevant information:

Additional context

I will put a note here to see if we need to address it after #1271 .
csv file for hparams will be deprecated in the future.


"sidebar" has inconsistent spelling in various keyindings conditions

sidebarVisible | Side Bar is displayed.
sideBarFocus | Side Bar has focus.

from https://code.visualstudio.com/docs/getstarted/keybindings#_when-clause-contexts
I think we should make an alias, sidebarFocus for sideBarFocus and deprecate the latter
Version: 1.31.1
Commit: 1b8e8302e405050205e69b59abb3559592bb9e60
Date: 2019-02-12T02:19:29.629Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.14.103

Since we have Side Bar everywhere in the UX I decided to deprecate sidebarVisible and introduce sideBarVisible
sidebarVisible will still be supported in the march release, but in the next one we will remove it.
Marking this as feature-request as a reminder to put this into release notes.

@isidorn it might be a good idea to looks for other things whihc might use the wrong spelling. Ther's at least workbench.action.toggleSidebarVisibility

You are right.
But that one I will not change. Converting command ids is a pain, and we have much wors command names than that.

@isidorn Verified, but please update vscode-docs too.


IP address = None

So, I am getting bail 4 error and upon further investigation, it seems that the ip_address being returned is None. Any help?

Can you please supply the command that was run and the full error output?

I'm running the python script directly, so it's the standard command, but the output (there are no errors) is just None.

I had to modify the pyscript because of the VPC thing.
import time
import boto
import boto.ec2
import sys

keyname=sys.argv[1]
instance_type=sys.argv[2]
region=sys.argv[3]
ami=sys.argv[4]
port=sys.argv[5]
if region:
    conn_region = boto.ec2.connect_to_region(region)
else:
    conn_region = boto.connect_ec2()

def auto_vpn(ami=ami,
                    instance_type=instance_type,
                    key_name=keyname,
                    group_name="vpn-server",
                    ssh_port="22",
                    vpn_port=port,
                    cidr="<IP_ADDRESS>/0",
                    tag="vpn-server",
                    user_data=None):

    ec2 = conn_region

    try:
        f = {'group-name':group_name,'vpc-id':'vpc-11111111'}
        group = ec2.get_all_security_groups(filters=f)[0]
    except ec2.ResponseError, e:
        if e.code == 'InvalidGroup.NotFound':
            group = ec2.create_security_group(group_name,
                                              'A group that allows VPN access',
                                              vpc_id='vpc-11111111')
            group.authorize('tcp',ssh_port,ssh_port,cidr)
            group.authorize('udp',vpn_port,vpn_port,cidr)
        else:
            str('haller')
            raise

    if int(port) != int(1194):
        try:
            mgroup = ec2.get_all_security_groups(groupnames=[group_name])[0]
            mgroup.authorize('udp',vpn_port,vpn_port,cidr)
        except ec2.ResponseError, e:
            if e.code == 'InvalidPermission.Duplicate':
                '''fail here'''
            else:
                raise

    reservation = ec2.run_instances(ami,
        key_name=key_name,
        security_group_ids=['sg-11111111'],
        instance_type=instance_type,
        user_data=user_data,
        subnet_id='subnet-11111111')

    instance = reservation.instances[0]
    while instance.state != 'running':
        time.sleep(30)
        instance.update()

        instance.add_tag(tag)

    global host
    host = instance.ip_address
    print "%s" % host

if __name__ == "__main__":
    auto_vpn()

Actually, after checking my AWS console, I don't see that it got assigned IP addresses (public or private).

Okay, so I fixed that issue, but now the issue is the ssh-keyscan keeps returning 1 even though the instance is already running and when I run ssh-keyscan manually, after the instance is running, it is returning 0.

I haven't seen that issue before.  are you sure the ssh-keyscan is checking the correct ip address?

@ttlequals0 I figured this one out, it was because I didn't have an Internet Gateway.


Error with subtitle if one of lines is empty.

Hi Guys
I'm using clappr for my website and there's a problem with subtitle.
Clappr won't view subtitle if the subtitle text is empty like the example below
From srt file:
150
00:08:40,140 --> 00:08:43,000
حتّى أنا أستطيع العودة إلى البيت مبكّرًا أحيانًا

151
00:08:43,800 --> 00:08:44,440

152
00:08:45,340 --> 00:08:46,000
ما الخطب؟

as you see at 151 there was no text so whenever srt parser come to this line all subtitles after this line won't appear.
you can find a copy of subtitle file here: Subtitle file

I have the same issue

If you are using "externals tracks" feature, it is handled by the browser. Clappr only create the proper <track> element(s). So i don't think it is related to Clappr. (you should get the same behaviour even without Clappr).
I am not an SRT expert, but i think you must not add additional blank lineq. This script may helps you to fix your files.

@kslimani I'm using Clappr-subtitle as plugin, and I tried another media player and it's skipped the blank line and show the next subtitle.
I'll try to put the same issue to Clappr-subtitle repo.

@alimohammed AFAIK, SRT format is not supported by Clappr player, so it may be an issue with clappr-subtible external plugin. (are you talking about this one ?)
Also, WebVTT subtitles support has been added recently in Clappr latest version.

@kslimani OK I'm going to try the latest version with webvtt.
Thank you for your reply.


Simple Rich Text Editor is not working in Mx 7.16.0

Using the simple rich text editor in Mx 7.16.0 is showing the following error:
Version '0.1' of the 'Simple Rich Text Editor' widget is not compatible with Mendix 7.
I downloaded version 1.30 from the Appstore as well I tried version 1.30 from GitHub

Dear Tobias,
Thanks for reporting this issue. I have some trouble reproducing it.
I created a clean new 7.16 project and imported 1.3.0 from the app store
https://appstore.home.mendix.com/link/app/74889/
No trouble with the editor.
Could you please provide us with a sample project with this issue?
PS: Disdyou try remove the file from the /widgets
or pres F5 to reload?
With kind regards,
Andries

Hi Andries,
I did a new checkout and tried it again with having success. I'm not able to reproduce the initial issue again.
Can be closed.
Cheers,
Tobias


runtests.py: improve CRLF handling and popen working folder

Simplify help output
Improve CRLF handling
Set Javascript file path as a cwd for POpen to prevent the output/baseline path related differences

Updated and re-based the PR.

Simplify help output
Improve CRLF handling
Set Javascript file path as a cwd for POpen to prevent the output/baseline path related differences

@jianchun Thanks for the review

@obastemur Signed off


split db put to create and update

Current coverage is 45.57% (diff: 100%)

Merging #178 into master will increase coverage by 1.23%

@@             master       #178   diff @@
==========================================
  Files            16         16
  Lines          8925       8925
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           3958       4068   +110
+ Misses         3934       3828   -106
+ Partials       1033       1029     -4

Powered by Codecov. Last update a9e7ce1...cdfd894

LGTM


Package Structure - Part 3

$ABAPGIT_OBJECTS_OO:
ZCL_ABAPGIT_OO_BASE
ZCL_ABAPGIT_OO_CLASS
ZCL_ABAPGIT_OO_FACTORY
ZCL_ABAPGIT_OO_INTERFACE
ZCL_ABAPGIT_OO_SERIALIZER
ZIF_ABAPGIT_OO_OBJECT_FNC
#4253

on long term I'd like to get rid of the OO indirections, they only test that the mocks work


chore: add vscode recommendations; jira commit tagging

Description
Add a few VSCode suggestions to help streamline onboarding for new users - I can record a walk-through of how these can facilitate productivity as well. I also included the requisite workspace settings to make setting up these utilities easier.
Added some logic to postfix JIRA information (if it exists in the branch name) to commit messages.
To-do list

[x] I have read the CONTRIBUTING document.
[x] This pull request is ready to merge.

@jawinn I removed the commit message parsing tasks so we can merge this in with just the extensions recommendations 🥳


Breakdown generic writeOffsetTable

This is a broken down piece of https://github.com/prometheus/tsdb/pull/627
With this, I am avoiding allocating slice headers for postings by having the name and value as separate fields. This saves quite some allocs.
[Don't merge until Prometheus 2.11 is out]

This saves quite some allocs.

Any sense of how much? 10%? 20%?

I don't have numbers for individual optimizations. All combined numbers is in this comment https://github.com/prometheus/tsdb/pull/627#issuecomment-503453181. I will try to get number for each optimizations.

So the gains are mostly allocs.
benchmark                                                                                old ns/op       new ns/op       delta
BenchmarkCompaction/type=normal,blocks=2,series=1000000,samplesPerSeriesPerBlock=51-8<PHONE_NUMBER>5<PHONE_NUMBER>7     -0.49%

benchmark                                                                                old allocs     new allocs     delta
BenchmarkCompaction/type=normal,blocks=2,series=1000000,samplesPerSeriesPerBlock=51-8     15845398       14839951       -6.35%

benchmark                                                                                old bytes      new bytes      delta
BenchmarkCompaction/type=normal,blocks=2,series=1000000,samplesPerSeriesPerBlock=51-8<PHONE_NUMBER><PHONE_NUMBER>     -0.01%

I am not sure the minor improvement in allocs is worth this change.

I would still like to have it. Multiple small improvements will add up to a big gain. And the absolute gain from this PR will be bigger in different scenarios (more number of label-values and series than the benchmark).


Sender identification missing in SMS attributes?

I have configured Traccar to connect to a simple SMPP server using the following configuration in traccar.xml:
<entry key='sms.smpp.enable'>true</entry>
<entry key='sms.smpp.host'><IP_ADDRESS></entry>
<entry key='sms.smpp.port'>2777</entry>
<entry key='sms.smpp.destTon'>5</entry>
<entry key='sms.smpp.destNpi'>14</entry>

SMS transmission works very well, but I'm missing some sort of identifier which indicates which user or device (uniqueId) initiated the transmission of this SMS. This is the data I get:
{
  "body": {
    "mandatory_parameters": {
      "priority_flag": 0,
      "source_addr": "",
      "protocol_id": 0,
      "replace_if_present_flag": 0,
      "registered_delivery": 0,
      "dest_addr_ton": "alphanumeric",
      "source_addr_npi": "unknown",
      "schedule_delivery_time": "",
      "dest_addr_npi": "internet",
      "sm_length": 8,
      "esm_class": 0,
      "data_coding": 0,
      "service_type": "",
      "source_addr_ton": "alphanumeric",
      "sm_default_msg_id": 0,
      "validity_period": "",
      "destination_addr": "0987654321-xx",
      "short_message": "hello world"
    }
  },
  "header": {
    "command_status": "ESME_ROK",
    "command_length": 54,
    "sequence_number": 2,
    "command_id": "submit_sm"
  }
}

Is that information not available in the communication to the SMPP server at all, or have I simply not found the correct setting to configure?
If the former, would it be possible to add that? I'm thinking in terms of billing for transmitted SMS for a particular user/device.
On a related note, the server statistics obtainable via the REST interface consistently report mailSent and smsSent as 0 (actually the last four values shown here are always 0). Is that a bug?
  {
    "id": 30,
    "attributes": {},
    "captureTime": "2017-07-11T22:00:23.000+0000",
    "activeUsers": 4,
    "activeDevices": 9,
    "requests": 384,
    "messagesReceived": 2442,
    "messagesStored": 2059,
    "mailSent": 0,
    "smsSent": 0,
    "geocoderRequests": 0,
    "geolocationRequests": 0
  }

SMPP is used to send simple text messages. What kind of information are you expecting and in which field?

Of course; I hadn't thought it through.
Ideally the pyaload would contain device uniqueId and the user identifier with the text to be transmitted.
Is this maybe something I could add in a template? Say I transmit JSON and unpack on the SMPP server side?
{
  "d" : "deviceId",
  "u" : "userId",
  "t" : "hello world"
}

Yes, you can include it in the template.

I've tried this in an Online event template:
(d=$device.uniqueId) [u=$event.userId]

The first one works. The second doesn't ...
Is there a documented list of template variables somewhere?

user/userId is not passed to template at the moment. May be it make sense to do that.
Context initialization is happen here https://github.com/tananaev/traccar/blob/master/src/org/traccar/notification/NotificationFormatter.java#L40
Also you can determine user by destination address.

For posterity, I solved it with (d=$device.uniqueId) [p=$device.phone]. Thank you.

hi @jpmens, How did you host an SMPP server? where you able to send commands from the traccar web platform to the GPS? Thanks.


Fixes and Features

Motivation
This PR has a lot of modifications, fixes and new features:
Bug fixes:

Send notification with data when the user tap on the notification (even if the app is dead). (5a6b141, 2b95e6c, cddfcfb)

Features:

Firebase version configurable (b3d767c, 68161e3)
Cancel notifications (Android/iOS) (4d129e4, 30bd3c1)
Compatibility Cordova Android 7 (bbb9957)

Checklist:

[x] Code has been tested locally by PR requester
[x] Changes have been successfully verified by another team member

@pcsantana Thanks for you contribution and sorry for the long time to review it. For some reason a did not get the GH notification before @secondsun assign it to me.

Landed at https://github.com/aerogear/aerogear-cordova-push/commit/d14e02e45877d78abfee565e01c70a1aba50e803


mrt add, install and update doesn't work in the /vagrant2 folder (workaround included)

Cause: VirtualBox Shared Folder doesn't support symlinks. Meteorite uses symlinks for the packages.
Workaround: Execute mrt commands in /vagrant and copy smart.json, smart.lock and .meteor/packages from /vagrant to /vagrant2 after:
cp -f /vagrant/<MY_APP>/smart.* /vagrant2/<MY_APP>/
cp -f /vagrant/<MY_APP>/.meteor/packages /vagrant2/<MY_APP>/.meteor/

Hi Sanjo,
I make it work avoiding symlinks.
I connected to vagrant and installed mongoDB with:
sudo apt-get install mongoDB
Then I told meteor to use that external db:
export MONGO_URL=mongodb://<IP_ADDRESS>:27017/meteor
You have to put exactly <IP_ADDRESS> beacuse it won't work with "localhost"
Now the app launches in /vagrant2/my-app using either mrt or meteor commands.
My goal was to use a code editor on my PC shared guest folder and see the changes applied immediately on the meteor app while running. And it works :)
If someone has already installed some apps, just do a "meteor reset" in the app folder.
Hope you can include this workaround in the next master update if you think is valid.
Kudos for you job.
P.S: I do not know if it will work on Windows. On my machine I run GNOME 14.04


Fixed lifecycle issue when using the plugin in a single file componen…

Fixed issue: Error in created hook: "TypeError: Cannot read property 'subscribe' of undefined"

@anthonygore Hi, I found a lifecycle issue when running https://codesandbox.io/s/vjo3xlpyny and fixed it, please confirm it.

Sorry for the delay.
Can you explain why this.$store.subscribe is undefined in the created hook? If the Vuex plugin is already installed, it should be available in the created hook since that's when reactive data and observation has been setup. What made you change to the mounted hook and why does that work? I don't get it!

Okay I get it now.
So the issue in your code sandbox is that the VuexUndoRedo plugin was being installed in your store file. I know it's conufsing, but this plugin is actually a Vue plugin, not a Vuex plugin!
I've gotten your code working by simply installing the plugin after the Vuex store gets created. It works fine after that.
https://codesandbox.io/s/qqrj2v9xv6
I'll close this PR and I think I'm going to instead throw an error if the user attempt to install the plugin before their Vuex store is created.
Thanks for taking the time to provide this PR.


[SPARK-12297] Table timezone correction for Timestamps

What changes were proposed in this pull request?
When reading and writing data, spark will adjust timestamp data based on the delta between the current session timezone and the table time zone (specified either by a persistent table property, or an option to the DataFrameReader / Writer).  This is particularly important for parquet data, so that it can be treated equivalently by other SQL engines (eg. Impala and Hive).  Furthermore, this is useful if the same data is processed by multiple clusters in different time zones, and "timestamp without time zone" semantics are desired.
Design doc: https://docs.google.com/document/d/1mcbkVo-PSsFh6iOOYx6Rk_34aY25H_zT1E2f7KmLMOU/edit#heading=h.rj5dmsuhw2zg
How was this patch tested?
Unit tests.

Test build #81830 has started for PR 19250 at commit 5105b72.

Test build #81830 has finished for PR 19250 at commit 5105b72.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81830/
Test FAILed.

Test build #81833 has started for PR 19250 at commit c5571a8.

Test build #81833 has finished for PR 19250 at commit c5571a8.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81833/
Test FAILed.

Test build #81888 has started for PR 19250 at commit 950d33a.

Test build #81888 has finished for PR 19250 at commit 950d33a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81888/
Test FAILed.

Test build #81892 has started for PR 19250 at commit e36851e.

Test build #81892 has finished for PR 19250 at commit e36851e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81892/
Test PASSed.

Hi @ueshin @rxin, could you please review?  thanks!

Test build #81929 has started for PR 19250 at commit 2069b65.

Test build #81931 has started for PR 19250 at commit 74a9905.

Test build #81931 has finished for PR 19250 at commit 74a9905.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81931/
Test FAILed.

Test build #81929 has finished for PR 19250 at commit 2069b65.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81929/
Test PASSed.

Test build #81943 has started for PR 19250 at commit 515b38b.

Test build #81943 has finished for PR 19250 at commit 515b38b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81943/
Test PASSed.

also cc @yhuai @liancheng would appreciate a review since you've looked at sql & hive compatibility in the past

Test build #82037 has started for PR 19250 at commit a869c6e.

Test build #82037 has finished for PR 19250 at commit a869c6e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82037/
Test PASSed.

@HyukjinKwon you might be interested in this one also

FYI Imran is probably going to be out for a few weeks so I'll try to address the feedback here. It would be nice to have people take a look at this, though.

I pushed a bunch of changes to address feedback here and also my own feedback that I didn't bother to write down. Main changes:

cache the TimeZone instances in generated code
rename a bunch of things to names that sounded better to me
refactored the test internals so that individual combinations are run as separate tests instead of one humongous test; this makes it easier to debug failures
added support (and tests) for raw Hive tables

I have not cleaned up the timestamp correction rule yet; I think I have a better idea of the code now and will do that next.

Test build #82561 has started for PR 19250 at commit e74ce2d.

Test build #82561 has finished for PR 19250 at commit e74ce2d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82561/
Test PASSed.

Test build #82592 has started for PR 19250 at commit 5c03e07.

Test build #82595 has started for PR 19250 at commit 5607160.

Test build #82592 has finished for PR 19250 at commit 5c03e07.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class AdjustTimestamps(conf: SQLConf) extends Rule[LogicalPlan]

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82592/
Test PASSed.

Test build #82595 has finished for PR 19250 at commit 5607160.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82595/
Test PASSed.

Test build #82610 has started for PR 19250 at commit 7e44486.

Test build #82610 has finished for PR 19250 at commit 7e44486.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82610/
Test PASSed.

@attilajeges has just found a problem with the behavior specified in the requirements:

Partitions of a table can use different file formats.
As a result, a single table can have data files of different file formats at the same time.
Timestamps are already handled differently in these formats (this was our original problem to begin with).
As a result, no uniform adjustment can fix timestamps for all file formats of the same table at the same time.

We can still solve the issue using a file-format-specific table property though. @rxin, I would like to ask you opinion of such a solution:

It is implemented in the analyzer, as you asked.
It is writer-agnostic, as you asked.
It is not file-format-agnostic, but Parquet-specific instead for the time being.

Would you find such a soltion be acceptable, given that a file-format-agnostic fix seems infeasible at this point?
Thanks,
Zoltan

why is this patch so complicated? Based on the fact that data sources accept a "timezone" option for read/writre, I'd expect it to be just:

when CreateTable, set session local timezone to table property.
when planning InsertIntoTable to concrete data source write command, get the timezone from table property and put it in write options.
when plannin table scan to cocrete data source scan, get the timezone from table property and put it in read options.

For data sources that doesn't support "timezone" options, there is nothing we can do.

@cloud-fan I think you misunderstand the purpose of this change.
The primary purpose is actually to deal with parquet, where that option doesn't do anything.  We need this for parquet for two reasons:

Interoperability with Impala. Impala first used an int96 to store a timestamp in parquet, and it always stored the time as UTC (to go with the SQL standard definition of timezone).  But spark (and hive) read it back in the current timezone.  Even when you don't change timezones, and the timestamp with time zone vs. timestamp without time zone distinction doesn't matter, you get different values before this change.

SQL STANDARD TIMESTAMP.  SQL defines timestamp to be a synonym for timestamp without time zone.  The behavior of that type is defined so if you insert "08:30" with time zone "America/New_York", then load the data with time zone "America/Los_Angeles", you should still see "08:30".  Since parquet is stored as an instant-in-time, and spark internally applies a timezone, the change in timezone must be reversed, by using some consistent adustment when saving and reloading.  This doesn't give you real timestamp without time zone, but gets you closer.

To be honest, I see limited value in this change for formats other than parquet -- I added only because I thought Reynold wanted it (for symmetry across formats, I suppose?).  As the purpose of this is to undo timezones, you can already achieve something similar in text-based formats by specifying a format which leaves out the timezone.  But it doesn't hurt.
We could reuse "timezone" option for parquet for this purpose, but that would be rather strange as its almost doing the opposite as what that property does for text-based formats, as that property is for adding a timezone, and this is for "removing" it.  Its doing something special enough it seems like it deserves a more specific name than just "timezone".
(This is all discussed at greater length, including showing how this type behaves in other sql engines, and how spark's behavior is non-standard, and how it changed in 2.0.1, in the design docs.)

What's the interoperability issue with Impala? I think both Spark and Impala store timestamp as parquet INT96, representing nanoseconds from epoch, there is no timezone confusion. Internally Spark uses a long to store timestamp, representing microseconds from epoch, so we don't and shoud't consider timezone when reading parquet INT96 timestamp.
I think your problem may about display. When Spark displays a timestamp value, via df.show, we convert the internal long value to standard timestamp string according to the session local timezone. Some examples:
// 1000 milliseconds from epoch, no timezone confusion
scala> val df = Seq(new java.sql.Timestamp(1000)).toDF("ts")
df: org.apache.spark.sql.DataFrame = [ts: timestamp]

scala> spark.conf.set("spark.sql.session.timeZone", "GMT")

scala> df.show
+-------------------+
|                 ts|
+-------------------+
|1970-01-01 00:00:01|
+-------------------+

scala> spark.conf.set("spark.sql.session.timeZone", "PST")

scala> df.show
+-------------------+
|                 ts|
+-------------------+
|1969-12-31 16:00:01|
+-------------------+

This behavior, I think makes sense, but may not be SQL-compliant. A clean solution is to add TIMESTAMP WITE TIMEZONE type, so that when we convert the internal long value to string, we can know which timezone to use.
Your proposal seems to hack the internal long value and lie to Spark about the microseconds from eppch, which doesn't look good.

The interoperability issue is that Impala follows timezone-agnostic timestamp semantics as mandated by the SQL standard, while SparkSQL follows UTC-normalized semantics instead (which is not SQL-compliant). Please see the [design doc|https://docs.google.com/document/d/1XmyVjr3eOJiNFjVeSnmjIU60Hq-XiZB03pgi3r1razM/edit] for details.
The long-term solution is using separate SQL types for different timestamps semantics indeed as you suggest. However, until we get there we would like to have a short-term solution that fixes timestamps that are already written.

Ah now I understand this issue. Yes Spark doesn't follow the SQL standard, the Spark timestamp is actually TIMESTAMP WITH LOCAL TIME ZONE, which is not SQL standard but used in some databases like Oracle.
Although Impala follows SQL standard, it doesn't follow parquet standard, that's why we need to deal with the parquet INT96 issue here. I think we can follow what Hive/Impala did for interoperability, i.e. create a config to interpret parquet INT96 as timezone-agnostic timestamp in parquet reader.
However, I'm less sure about the parquet.timezone-adjustment table property. Is this a standard published somewhere? Do Impala and Hive both respect it? I think we need people from both Impapa and Hive to say YES to this proposal.

I think we can follow what Hive/Impala did for interoperability, i.e. create a config to interpret parquet INT96 as timezone-agnostic timestamp in parquet reader of Spark.

If I understand what you are asking correctly, I think this is what went into the original PR:
https://github.com/apache/spark/pull/16781

However, I'm less sure about the parquet.timezone-adjustment table property. Is this a standard published somewhere? Do Impala and Hive both respect it? I think we need people from both Impapa and Hive to say YES to this proposal.

All three engines were going to make the change, till it was reverted from Spark.  Now the process as a whole is blocked on Spark -- if this change (or the prior one) is accepted, then the other engines can move forward too.

Hive and Impala introduced the following workaround for timestamp interoperability a long ago: The footer of the Parquet file contains metadata about the library that wrote the file. For Hive and Spark this value is parquet-mr, for Impala it is impala itself, since it has its own implementation. Since Hive and Spark writes using UTC-normalized semantics and Impala writes using timezone-agnostic semantics, we can deduce the used semantics from the writer info. So, when Hive sees a Parquet file written by Impala, it will adjust timestamps to compensate for the difference. Impala has an option (-convert_legacy_hive_parquet_utc_timestamp) to do the same when it sees a Parquet file written by anything else than Impala.
There are two problems with this workaround:

Spark does not have a similar logic, so while Impala<->Hive and Hive<->SparkSQL can read each other's timestamps, the Impala->SparkSQL direction does not work. If SparkSQL implemented such a writer-dependent adjustment logic, it would already improve interoperability significantly.
The adjustment depends on the local timezone. This can be problematic if a table contains timestamps of mixed semantics, i.e. some data was written by Impala and some data was written by Hive or SparkSQL. In that case, if the local time used for reading differs from the local time used for writing, some of the timestamps will change and some others won't. Both of these behaviors are okay by themselves, since these are two valid timestamp semantics, but both of them happening on a single table is very counter-intuitive. This would be especially problematic for SparkSQL, since SparkSQL has a session-local timezone setting (Impala and Hive use the server timezone, which tends to remain unchanged).

To address both of these issues, we both added the recognition and adjustment of Impala-written timestamps to SparkSQL and also added a table property to record the timezone that should be used for these adjustments, so that mixed table do not lead to unintuitive behaviour any more. We also added this table property to Impala and Hive logic and tested that they can correctly read each other's timestamps.
However, our initial commit (which was the first of two commits and was meant to be followed by a follow-up change) got reverted in Spark due to some concerns. Because the table property only provides interoperability if respected by all affected components, we reverted our changes to Hive and Impala as well until we can reach an agreement with Spark.
To address the concerns that lead to Reynold to revert our initial commit, Imran made three changes compared to our original proposal:

The adjustment logic was moved to the analyzer.
The writer-specific logic was removed, all timestamps get the same treatment regardless of the component that wrote them. As a result of this, the code became simpler and nicer at the price of a behaviour change: Since Impala-written timestamps are already timezone-agnostic, the user now has to specify UTC in the table property for that table (earlier it didn't matter). It also means that it is no longer possible to fix a table that already has mixed semantics content, since you can not set the table property to UTC as that would make Hive/Spark timestamp wrong and you can't set it to the local timezone either because that would make the Impala timestamps wrong. Although more restricting than our initial proposal, this still seems acceptable, since most existing tables are single-writer only, and once you set the table property all writers will respect it, so after you set the table property you can have mixed-writer tables (they won't become mixed-semantics due to the table property).
The adjustment logic was made file-format-agnostic so that it does not only apply to Parquet but to any kinds of tables. However, we then realized that this will lead to further interoperability problems, thereby we would like to stick with a Parquet-specific approach as we originally proposed to avoid making the situation worse.

IIUC, using the parquet.timezone-adjustment table property requires changing the writer. e.g. Impala creates a table and Hive wants to write data to it, then Hive needs to write timezone-agnostic timestamp instead of UTC timestamp. And vice versa.
I think a better solution is the Parquet-specific approach. Impala keeps writing timezone-agnostic timestamp, and Spark/Hive keep writing UTC timestamp. At the read path, we should detect who wrote the parquet file and do timestamp adjustment based on this information(can also have a config to protect this behavior).
cc @rxin

Yes, you understand correctly, the table property affects both the read path and the write path, while the current workaround used by Hive and Impala only affects the read path. (Both are Parquet-specific though, I think you meant to write "writer-specific" when referring to the latter.)

actually I took a look at #16781 , It also proposed a table property, instead of a simple spark config.

Yes, that is correct. We introduced the table property to address the 2nd problem I mentioned above: "The adjustment depends on the local timezone." (details in my previous comment). But I think that a simpler workaround similar to what already exists in Hive would already be a big step forward for interoperability of existing data.

ok @squito  can we send a new PR to do it? basically in parquet read task, get the writer info from the footer. If the writer is impala, and a config is set, we treat the seconds as seconds from epoch of session local time zone, and adjust the seconds to seconds from Unix epoch.

@cloud-fan yes I can do that, will be next week before I get to it

@squito we can close this right?


B should be small in Bitcoin as we are talking about the currency here

Verified this issue on dev app v2.0.70(431)


[ui] Add/Edit service chart values

Summary
Fixes #252
Fixes #296

Technical Notes

How to create service chart settings for a Service Catalog: https://docs.epinio.io/howtos/create_custom_service#user-settable-configuration-values
Epinio 1.9.0 supports only basic key-value string maps.
Edit service chart values is not supported at the moment. The chart fields are disabled in edit mode.

Screenshots
View:

Create:

Edit:

in the shared epinio i've updated the mysql-dev service to include
    "ingress.enabled":
      type: "bool"
    "ingress.hostname":
      type: "string"

* clicking the ingress.enabled checkbox doesn't check the box until text is entered in the `ingress.hostname` field

* when saving this the service failed to be created (could be that it expects the settings to correlate with helm variables?)

  * Edit - this did eventually deploy. we might not be waiting long enough for the deployed state

* the detail view (read only edit view) shows quotes for the text

  * ![image](https://user-images.githubusercontent.com/18697775/259103587-8e5a64b9-c503-4ef0-90f9-df5e8bb84c73.png)

Note https://deploy-preview-265--epinio-docs-staging.netlify.app/next/howtos/using_custom_service_values
documenting how the various forms in a charts values.yaml, a service's settings, and the -v options correlate.
Note especially the array and map support.

clicking the ingress.enabled checkbox doesn't check the box until text is entered in the ingress.hostname field

I could verify this bug on Service charts, applications chart work fine. Needs investigation

when saving this the service failed to be created (could be that it expects the settings to correlate with helm variables?)

Edit - this did eventually deploy. we might not be waiting long enough for the deployed state

This is also happening testing main branch, I opened an issue for that: https://github.com/epinio/ui/issues/298

the detail view (read only edit view) shows quotes for the text

The UI correctly sends string values without double quotes, then gets back service details with quoted strings:

Request:

Response:

It seems to be a regression, needs to double check with the be team and open an issue, in case.

in the shared epinio i've updated the mysql-dev service to include
    "ingress.enabled":
      type: "bool"
    "ingress.hostname":
      type: "string"

* clicking the ingress.enabled checkbox doesn't check the box until text is entered in the `ingress.hostname` field

* when saving this the service failed to be created (could be that it expects the settings to correlate with helm variables?)

  * Edit - this did eventually deploy. we might not be waiting long enough for the deployed state

* the detail view (read only edit view) shows quotes for the text

  * ![image](https://user-images.githubusercontent.com/18697775/259103587-8e5a64b9-c503-4ef0-90f9-df5e8bb84c73.png)

Note https://deploy-preview-265--epinio-docs-staging.netlify.app/next/howtos/using_custom_service_values documenting how the various forms in a charts values.yaml, a service's settings, and the -v options correlate.
Note especially the array and map support.

I'm opening a new issue to support new array types.

Thanks @richard-cox , small issues from UI side are fixed. There are a few related pending issues :

Timeout error when creating services with bound apps: https://github.com/epinio/ui/issues/298
Support complex setting types: https://github.com/epinio/ui/issues/302
Quoted strings: verified by backend, to open a new issue for be.
Cannot edit services: https://github.com/epinio/ui/issues/303


Applying different layouts for 1809 and 1803

Our domain uses 1809 and 1803 builds, without putting these computers into different OUs can we edit the xml file to change both 1809 and 1803? Currently we have it so that the layout is correctly applied to 1809 but for 1803 it is simply locking the previous layout that the user had (All their start pins are fixed and can not be removed and nothing else can be added)

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

ID: 79fccecd-5484-0304-d82b-9425f1889a22
Version Independent ID: 4df6b138-c1b5-b551-22c9-19d3d1f9105d
Content: Customize and export Start layout (Windows 10)
Content Source: windows/configuration/customize-and-export-start-layout.md
Product: w10
Technology: windows
GitHub Login: @jdeckerMS
Microsoft Alias: jdecker

@edcion I'm checking on whether that's possible, I'll let you know when I get an answer.

Actually I should have included 1607 in my versions as well. We have pc's running 1607 LTSB and those also experience locked up start menus when i push the xml in GP

@edcion I've been told that a single layout XML should work on both builds. Since it isn't working for you, we recommend that you open a support case (https://support.microsoft.com/en-us/contactus/) so they can help you resolve the issues.


fix to use enum class value for default value in flinkoptions

Change Logs

Use Enum Class instead of constant string for option default value in FlinkOptions.
fix doc error for default value

Thanks, can we fire a JIRA issue here: https://issues.apache.org/jira/browse/HUDI-3096
and change the commit title to the form:
[HUDI-${JIRA ID}] ${your commit title}

Hi, the tests are failing, can you rebase the latest master and force-push again ?


feat: Use modelfiles with external API instead of ollama

With this change a modelfile from the ollama hub can be imported in a way that it uses an external model from openAI compatible API instead of ollama.
A pre requirement is to provide an API key and refresh the page so the models are loaded.
In my testing to achieve this we have to copy an existing model's name to two places:

the Tag name
the FROM part of the content

This works in my local instance.
I am rather not so sure about this changes as I never touched svelte before.
Probably a checkbox called: use external and a dropdown list to select from external models would be a more complete solution.
Should relate to #665

I haven't reviewed the frontend code enough to have an opinion on the correctness of this, but I posted some thoughts as to why we should probably do this whole thing differently in the related issue.

I agree with @explorigin, we might want to have our own "modelfile" format that's extensible and compatible with other LLM runners. I'll close this for now, let's continue our discussion here: https://github.com/ollama-webui/ollama-webui/issues/665


[BUG] - Accordion itemClassNames do not pass class strings

NextUI Version
latest
Describe the bug
No class strings are distributed to components of accordion
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Open you basic usage example for Accordion https://codesandbox.io/p/devbox/mystifying-bohr-k978ys
Add this property:
itemClassNames={{
base: "!px-0",
heading: "!px-0",
trigger: "!px-0",
titleWrapper: "!px-0",
title: "!px-0",
subtitle: "!px-0",
startContent: "!px-0",
indicator: "!px-0",
content: "!px-0",
}}
Notice there is no change in the rendering window + no classNames are found anyone using the devtools.

Expected behavior
Classnames are passed accordingly to the accordion
Screenshots or Videos

Operating System Version
macOS
Browser
Chrome

I've been able to see the className in some of the deeper children, but the more parent ones, namely what I perceive to be the base is not affected. Namely trying to disable the px-2 by default.

You need write 'itemClasses' instead 'itemsClassNames' and if you want, you could delete all the exclamations signs in case you don't need them
Like this:

Closing - answered here.

The px-2 you want to disable is not an "itemClass", so you don't need itemClasses at all.
It is the most outer class, put it in className is fine.


GitHub packages dependency updates

Description
This PR contains the following updates:

Replace GitHub packages dependencies with jitpack dependencies
Download evosuite and randoop jars via jitpack instead of using the maven download plugin on GitHub releases of those tools
Remove use of GitHub token in CI workflows (except the the release workflow, where it is used for publishing the docker image to ghcr) and docker/docker-compose files
Build consolidated jar with dependencies for tkltest-ui, which removes crawljax and other dependencies to be specified in test generation commands
Remove maven settings.xml template
Updated documentation

Related to # (issue)
Type of Change
Please check the types of changes your PR introduces.

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Refactoring (non-breaking code restructuring that preserves functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Build-related update (CI workflow, test cases)
[x] Documentation update
[ ] Other (please describe):

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so that it can be replicated.
Please also list any relevant details for your test configuration.

[ ] Test A
[ ] Test B

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Will create new PR after merging updates


Ignore files of IntelliJ resp. Webstorm

Added support to .gitignore to ignore files in project folders for IntelliJ resp. Webstorm.

great thanks!


Cross-platform line break support

For this particular case, require('os').EOL should be used instead of the constant LINE_SEPERATOR, which has a value of \n.
https://github.com/mohsen1/yawn-yaml/blob/d870fbe1767ae429fa012414404aaae2a49f44fb/src/index.js#L317-L320

Good idea! PR is welcome!

As I'm building on top of this project, I'm cataloguing some of the issues.  When I get a breather, I'll be happy to submit PRs!

Hey, @mohsen1, it looks like the contents of dist and cjs weren't built before this was published.  Still having issues, unfortunately.  :grimacing:

Oops sorry! Fixing it right now!

Done in<EMAIL_ADDRESS>


Quitting editing, or resetting field to null

Once a user has clicked on a field, there seem to be no way to get "out" of editing.
Is there a way to cancel the date picking? Escape doesn't seem to do the trick.
Help? :D

In the release 2.9.2 are a lot of changes made. If you click outside, press esc or click the x-button the picker should be canceled and closed.