Expand the list of frontend template options

What problem does your feature solve?
contract init command (https://developers.stellar.org/docs/tools/stellar-cli#stellar-contract-init) provides a flag (--frontend-template) allowing to generate UI code for contracts via a repository (if I'm not mistaken). But there's only one [publically-available/searchable] template now (https://github.com/stellar/soroban-astro-template) and no specific pointers on where to find other options, or how to create them (minimal requirements for such a repo?)
What would you like to see?
Other options/examples for UI generation, or short documentation on how to create one (for instance, with Preact, Svelte, Vue, or whatnot)
What alternatives are there?
Manual creation? Which probably requires a lot more stuff to take care of...

Please document how to best to contribute to add more frontend templates, and we could pass over  devrel.

@janewang is it a request to the reporter or to the assignee? 😅 (I mean, I could, but maybe I'm not the most competent champion for that here yet)

This is a request for the assignee @chadoh

@chadoh Were you able to add a how-to contribute doc as the the first step as you offered on the call 2 week ago? Subsequently, as discussed we are planning to find community contributors.

I believe this document, Develop contract initialization templates, is probably most of what we need. I'll go through it and make sure it has what was in my head, as a foundation for creating a community initiative around getting new templates.

This a really good thorough doc, I wish I knew about that earlier 👍 What I did basically is just used an arbitrary frontend repo as a template with soroban init, and then augmented it with the stuff from the existing Astro template 😅 This doc explains everything of that in a detailed way, kudos!
What would help too is probably to underpin more explicitly that you can use any existing repo as a basis actually, and highlight what are the integral parts of a soroban template after that (the init script, the packages, and all that jazz). Also, some starters use shell scripts instead of Node scripts, and that's totally legit too, I would also describe shortly what you need to include in an initialization script in general, in language-agnostic way.
Sorry for the unsolicited two cents, feel free to ignore if that's irrelevant 😅

Closing this issue and can discuss with dev rel


[Azure] Failed to create vm resource

Creating the file azure_vm.json with the below contents:
{
    "location": "eastus",
    "properties": {
        "hardwareProfile": {
            "vmSize": "Standard_B1s"
        },
        "osProfile": {
            "computerName": "sample-compute",
            "adminUsername": "weit",
            "adminPassword": "pas43920$rejkfjsdklwe48i@@9023d"
        },
        "storageProfile": {
            "imageReference": {
                "offer": "0001-com-ubuntu-minimal-jammy",
                "publisher": "canonical",
                "sku": "minimal-22_04-lts-gen2",
                "version": "latest"
            }
        }
    }
}

and invoking:
glide resource create azure vm-1 azure_vm.json

produced the below error message:
failed to create resource: Put "http://localhost:8080/namespaces/default/clouds/azure/resources/vm-1": EOF

which seems to cause the orchestrator to crash:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x13f4ce9]

goroutine 118 [running]:
github.com/paraglider-project/paraglider/pkg/azure.(*AzureSDKHandler).GetAllVnetsAddressSpaces(0xc001229860, {0x30b0308, 0xc0013c26f0}, {0xc001307d60, 0x7})
        /home/weit/paraglider/pkg/azure/sdk_handler.go:310 +0x2c9
github.com/paraglider-project/paraglider/pkg/azure.(*azurePluginServer).GetUsedAddressSpaces(0xc0000905a0, {0x30b0308, 0xc0013c26f0}, 0xc001378800)
        /home/weit/paraglider/pkg/azure/plugin.go:383 +0x273
github.com/paraglider-project/paraglider/pkg/paragliderpb._CloudPlugin_GetUsedAddressSpaces_Handler({0x2bcdee0, 0xc0000905a0}, {0x30b0308, 0xc0013c26f0}, 0xc00092c880, 0x0)
        /home/weit/paraglider/pkg/paragliderpb/paraglider_grpc.pb.go:271 +0x1a6
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000f18a00, {0x30b0308, 0xc0008f5a10}, {0x30bc460, 0xc000835680}, 0xc000e08900, 0xc000f0cbd0, 0x4ac9800, 0x0)
        /home/weit/go/pkg/mod/google.golang.org/grpc@v1.64.0/server.go:1379 +0xdf8
google.golang.org/grpc.(*Server).handleStream(0xc000f18a00, {0x30bc460, 0xc000835680}, 0xc000e08900)
        /home/weit/go/pkg/mod/google.golang.org/grpc@v1.64.0/server.go:1790 +0xe8b
google.golang.org/grpc.(*Server).serveStreams.func2.1()
        /home/weit/go/pkg/mod/google.golang.org/grpc@v1.64.0/server.go:1029 +0x7f
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 117
        /home/weit/go/pkg/mod/google.golang.org/grpc@v1.64.0/server.go:1040 +0x125

It seems to me that the SIGSEGV is related to azure/sdk_handler.go (where v.Tags exists but set with an empty map) at:
if v.Tags != nil && *v.Tags[namespaceTagKey] == namespace {
After updating the code with key existence check:
if val, ok := v.Tags[namespaceTagKey]; ok

I was able to create an azure vm with glide resource create CLI:
~/paraglider$ glide resource create azure vm-1 azure_vm.json
Creating resource: vm-1
Resource Created.
tag: default.azure.vm-1
uri: /subscriptions/my-subscription-id/resourceGroups/my-resource-group-name/providers/Microsoft.Compute/virtualMachines/vm-1
ip: <IP_ADDRESS>

I would like to ask whether I am missing something or perhaps a fix should be applied.
Thanks.

I encountered the same bug after pulling the latest commit and building from source.
Applying the change @aviweit suggested solved the bug.
Output of glide version:
Release: latest
Version: a05976c-dirty
Commit: a05976c146d49a984c6b06f673efdd0a28ed4159

Hi Avi, I pulled the latest commit on main and I tried replicating the error with the vm json you attached, and it works fine on my end. It seems there's a vnet within your resource group doesn't have a paraglider tag attached to it. The fix you provided should solve the problem as they may be non-Paraglider vnets in the resource groups. I can push a fix for this. (Unless you'd prefer to do that). Thanks for pointing this out!
Also, if I may ask, is there an external vnet within your resource group (one that wasn't created by Paraglider - which would make sense if there's no tag)? If there isn't, that may be something to worry about. (Why a Paraglider created vnet would not have the paraglider tag)

Hi @J-467 , please feel free to push the fix.
Yes, we have a few vnets not related to Paraglider with no tags. I think that may explain.
Thanks a lot.


support nested directories in template directories

i've been wanting something like #66 for a while.
my use case specifically is qbittorrent-themes.
they need a file called config.json (by that specific name) which is pretty generic.
i could post-process filenames before i run it through rcc, but i thought it would be nice for pywal16 to support child directories inside the template folder instead.
this way i can organize my qbittorrent-stuff and have room for more config.json files that might be needed for other programs.
the PR introduces a naive class which contains every reference needed to read templates and output them to the correct spot. this could also just be a tuple, or a dictionary or something if you prefer that.
walk is a super simple function that leverages os.path stuff. i went with a generator-type of function, idk if you like that lol.
i was thinking about defining some tests to verify its functionality, but it seems the tests use my personal config, so it's hard to make a test that will work in every environment.
running the export tests locally, i can at least verify that feature parity is maintained.

okay i like how this looks


Fragment.propType.isRequired undefined

Taking a peek at the new documentation for fragments, I got this code working (simplified):
// Users.js
import React from 'react';
import gql from 'graphql-tag';
import apollo from './Apollo';
import UserPreview from './UserPreview';

const Users = props => (

    {props.data.allUsers.map(u => <UserPreview key={u.id} user={u} />)}

);
const query = gql`{
  allUsers {
    id
    ...UserPreviewUser
  }
}`;
const withData = apollo(query, {
  options: {
    fragments: UserPreview.fragments.user.fragments(),
  },
});
export default withData(Discover);

// UserPreview.js
import React from 'react';
import gql from 'graphql-tag';
import Fragment from 'graphql-fragments';

function UserPreview({ className, user }) {
  return
{`${user.givenName} ${user.familyName}`}
;
}
UserPreview.fragments = {
  user: new Fragment(gql`
    fragment UserPreviewUser on User {
      givenName
      familyName
    }
  `),
};
UserPreview.propTypes = {
  user: UserPreview.fragments.user.propType.isRequired,
};
export default UserPreview;

Although everything works, I get the console error Warning: Failed prop type: UserPreview: prop type user is invalid; it must be a function, usually from React.PropTypes.
If I remove isRequired, the warning disappears. Maybe isRequired is missing from the fragment propType implementation?

Hi @sedubois.
I guess we can take this conversation to https://github.com/apollostack/graphql-fragments but the short answer is you don't need to (and shouldn't) use isRequired for a fragment.propType. They are always required.
I'm not sure if there is a valid use case where they are not required? If we can think of one perhaps we should change the default, add an isRequired version, and update the docs.

OK I agree that they are required, I just found confusing that the API is incoherent with what's done in React/Relay proptypes. Here the propTypes is implicitly required, whereas it's flagged explicitly in React/Relay. (Might confuse people.)

Interestingly, Relay doesn't even have proptypes for fragments: https://facebook.github.io/relay/docs/api-reference-relay-proptypes.html

@stubailo what do you think? I'm inclined to make it optional by default and add an isRequired(), this has confused a couple of people already.

Sounds great! Let's talk on the other issue.


Upgrade template out from extension of Definition Spec

Before：
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  definitionRef:
    name: deployments.apps
  extension:
    healthPolicy: |
        healthy: isHealth: output.status.replicas == output.status.readyReplicas
    customStatus: |
        output: "type: "+ context.outputs.service.spec.type +",\t clusterIP:"+ context.outputs.service.spec.clusterIP+",\t ports:"+ context.outputs.service.spec.ports[0].port+"/"+context.outputs.service.spec.ports[0].protocal+",\t domain"+context.outputs.ingress.rules[0].host
    template: |
      output: {
        apiVersion: "apps/v1"
        kind:       "Deployment"
        spec: {
          selector: matchLabels: {
            "app.oam.dev/component": context.name
          }
          template: {
            metadata: labels: {
              "app.oam.dev/component": context.name
            }
            spec: {
              containers: [{
                name:  context.name
                image: parameter.image
                if parameter["cmd"] != _|_ {
                  command: parameter.cmd
                }
              }]
            }
          }
          selector:
            matchLabels:
              "app.oam.dev/component": context.name
        }
      }
      parameter: {
        // +usage=Which image would you like to use for your service
        // +short=i
        image: string
        cmd?: [...string]
      }

After:
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  definitionRef:
    name: deployments.apps
  template: |
      output: {
        apiVersion: "apps/v1"
        kind:       "Deployment"
        spec: {
          selector: matchLabels: {
            "app.oam.dev/component": context.name
          }
          template: {
            metadata: labels: {
              "app.oam.dev/component": context.name
            }
            spec: {
              containers: [{
                name:  context.name
                image: parameter.image
                if parameter["cmd"] != _|_ {
                  command: parameter.cmd
                }
              }]
            }
          }
          selector:
            matchLabels:
              "app.oam.dev/component": context.name
        }
      }
      parameter: {
        // +usage=Which image would you like to use for your service
        // +short=i
        image: string
        cmd?: [...string]
      }
  status:
    healthPolicy: |
        healthy: isHealth: output.status.replicas == output.status.readyReplicas
    message: |
        output: "type: "+ context.outputs.service.spec.type +",\t clusterIP:"+ context.outputs.service.spec.clusterIP+",\t ports:"+ context.outputs.service.spec.ports[0].port+"/"+context.outputs.service.spec.ports[0].protocal+",\t domain"+context.outputs.ingress.rules[0].host

I think we take out parameters in the future as well.

@resouer  helm , terraform and json-schema can have  new field with template, for example:
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  definitionRef: # this also means you can directly use CRD as a "module"
    apiVersion: apps/v1
    kind: Deployment
  template: |
        output: {
          apiVersion: "apps/v1"
          kind:       "Deployment"
          spec: {
            selector: matchLabels: {
              "app.oam.dev/component": context.name
            }
            template: {
              metadata: labels: {
                "app.oam.dev/component": context.name
              }
              spec: {
                containers: [{
                  name:  context.name
                  image: parameter.image
                  if parameter["cmd"] != _|_ {
                    command: parameter.cmd
                  }
                }]
              }
            }
            selector:
              matchLabels:
                "app.oam.dev/component": context.name
          }
        }
        parameter: {
          // +usage=Which image would you like to use for your service
          // +short=i
          image: string
          cmd?: [...string]
        }
  helm:
      # helm specific fields
  terraform:
      # terraform hcl specific fields
  json-schema:
      # plain json-schema

@wonderflow it doesn't make sense to me ... what is the type of template field then?
Also, cue, helm chart, terraform etc are modules rather than templates. It's a good timing to fix this name.

apiVersion: core.oam.dev/v1alpha2
kind: ComponentDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  workloadType: deployments.apps
  module:
    cue:
      template: |
        output: {
          apiVersion: "apps/v1"
          kind:       "Deployment"
          spec: {
            selector: matchLabels: {
              "app.oam.dev/component": context.name
            }
            template: {
              metadata: labels: {
                "app.oam.dev/component": context.name
              }
              spec: {
                containers: [{
                  name:  context.name
                  image: parameter.image
                  if parameter["cmd"] != _|_ {
                    command: parameter.cmd
                  }
                }]
              }
            }
            selector:
              matchLabels:
                "app.oam.dev/component": context.name
          }
        }
        parameter: {
          // +usage=Which image would you like to use for your service
          // +short=i
          image: string
          cmd?: [...string]
        }
    helm:
      # helm specific fields
    terraform:
      # terraform hcl specific fields
    json-schema:
      # plain json-schema
    raw-resource:
      # old school cr template + parameter

@wonderflow, I am in favor of having ComponentDefinition. But we also need to make sure users (i.e. component providers) author ComponentDefinition only, otherwise two objects to define one component is too verbose to me.
Hence, we need to generate WorkloadDefinition from ComponentDefinition. Considering workload template also need revisioning (see: https://github.com/oam-dev/kubevela/issues/1064), we can actually do 1: N mapping (mutable -> immutable mapping).
For example:
# mutable object
apiVersion: core.oam.dev/v1alpha2
kind: ComponentDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  definitionRef:
    apiVersion: apps/v1
    kind: Deployment
  module:
    cue:
      # template data
  # other per ComponentDefinition fields ...

---
# immutable objects
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: deployments.apps-v1-{revision number} # this name is generated from ComponentDefinition.definitionRef
spec:
  definitionRef:
    apiVersion: apps/v1
    kind: Deployment
  module:
    cue:
      # template data of {revision number}

/cc @ryanzhang-oss, please review if this solves your request for https://github.com/oam-dev/kubevela/issues/1064

Similar pattern: https://github.com/mattmoor/boo-maps

@wonderflow, I am in favor of having ComponentDefinition. But we also need to make sure users (i.e. component providers) author ComponentDefinition only, otherwise two objects to define one component is too verbose to me.
We can generate WorkloadDefinition from ComponentDefinition. Considering workload template also need revisioning (see: #1064), we can actually do 1: N mapping (mutable -> immutable mapping).
For example:
# mutable object
apiVersion: core.oam.dev/v1alpha2
kind: ComponentDefinition
metadata:
  name: worker
  annotations:
    definition.oam.dev/description: "Long-running scalable backend worker without network endpoint"
spec:
  definitionRef:
    apiVersion: apps/v1
    kind: Deployment
  module:
    cue:
      # template data
  # other per ComponentDefinition fields ...

---
# immutable objects
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: deployments.apps-v1-{revision number} # this name is generated from ComponentDefinition.definitionRef
spec:
  definitionRef:
    apiVersion: apps/v1
    kind: Deployment
  module:
    cue:
      # template data of {revision number}

/cc @ryanzhang-oss, please review if this solves your request for #1064

Similar pattern: https://github.com/mattmoor/boo-maps

I love this idea

@wonderflow I updated the design a bit, because I think in implementation we should ensure the latest workload def always have a fixed name (e.g. deployments.apps), this is the key for workload type discovery.

will align with https://github.com/oam-dev/spec/issues/443


Make AutowareRider Android Studio compatible

I made AutowareRider android studio compatible and replaced c/c++ socket with java socket., see README.md for more details. Please let me know if there is issues. Thanks.

I tried to build and validate.
I can build using Android Studio, but the following problems were found.

B,N,D,R,AUTO CRUISE and NORMAL CRUISE buttons did not change when I clicked them.
The indication of middle was bright first, but it became dark later.

If you know about that please let me know.

@mingrutar I'll close. Please remake pull request after confirm and fix.


store.writeQuery On Mutation Only Takes Effect If optimisticResponse Provided

I struggled for a bit getting updates to the store to work in a reactive way. I could see that update on my $apollo.mutate was being called, and could poke the store and see that the value changed in there, but it wasn't updating the UI. This was for a simple case of adding an item to a list, like the standard Todo example.
Only after defining an optimisticResponse response on my $apollo.mutate did things work as expected. I don't see anything in the documentation about this being required. Is this a requirement, or a bug?
I still can't get the delete mutation working with update. Again, everything looks correct, but no UI update. Without the optimisticResponse, nothing visually happens, with it, there's a flash as the item is removed, then put back. The response from the server is simply a boolean, and the optimistic response value is true since I expect to to succeed. Switching that to false (so that it actually differs from the server response) has no effect. However, changing anything in the code and letting HMR refresh the code, then trying the delete again succeeds.
Any suggestions?
export default {
  data () {
    return {
      items: []
    }
  },
  methods: {
    async addItem () {
      const input = { name: 'Test' }

      try {
        await this.$apollo.mutate({
          mutation: ADD_ITEM_MUTATION,
          variables: { input },
          update: (store, { data: { addItem } }) => {
            const data = store.readQuery({ query: ITEMS_QUERY })
            data.items.push(addItem)
            store.writeQuery({ query: ITEMS_QUERY, data })
          },
          optimisticResponse: {
            __typename: 'Mutation',
            addItem: {
              __typename: 'Item',
              id: null,
              created: utils.currentTimestamp(),
              ...input
            },
          }
        })
      catch (err) {
        console.log(err)
      }
    },
    async deleteItem (item) {
      const itemId = item.id

      try {
        await this.$apollo.mutate({
          mutation: DELETE_ITEM_MUTATION,
          variables: { itemId },
          update: (store, { data: { deleteItem } }) => {
            // Update the list of items
            const data = store.readQuery({ query: ITEMS_QUERY })
            const idx = data.items.indexOf(item)

            if (idx) {
              data.items.splice(idx, 1)
              store.writeQuery({ query: ITEMS_QUERY, data })
            }
          },
          optimisticResponse: {
            __typename: 'Mutation',
            deleteItem: true
          }
        })
      } catch (err) {
        console.log(err)
      }
    }
  }
}

See: https://github.com/apollographql/apollo-client/issues/4031#issuecomment-433668473

If you follow my link, you will see it's an issue with recent versions of apollo-client and apollo-utilities.

@Akryum, thanks for the link, and makes sense that it would be upstream. There's a comment there that<EMAIL_ADDRESS>fixes the issue for me (and I tested it in your reproduce CodeSandbox and it works there too).
I did, however, notice that there's no need to do the store.writeQuery on delete, as it appears the result from store.readQuery is not a deep copy, so modifying the list via splice will immediately affect the store state.
So I guess bumping the apollo-client version in this project's package.json would close this issue?

It should be fixed in the latest apollo client related packages.


Upstream molecular weight fixes

This is simply #569 upstreamed with doc updates

These changes are "approved" in the linked PR


several small fixes.

parameter_parser.py: Make it work to run hyperparameter optimization with only one config of layer_size and dropout with multiple layers.
hyperparam_search_wrapper.py: Make it work to include additional commands in slurm script, such as "module load ampl".

For the get_multitask_perf function, I checked with Amanda and her function only works with Model Tracker. So I kept my modified function as a new one. And Kevin's old get_multitask_perf_from_filesystem function was kept unchanged.

For the get_multitask_perf function, I checked with Amanda and her function only works with Model Tracker. So I kept my modified function as a new one. And Kevin's old get_multitask_perf_from_filesystem function was kept unchanged.


#28 Support JDK21 for base image

Close #28

verified via
sh-5.1# ./opt/openjdk-21/bin/java -version
openjdk version "21.0.1" 2023-10-17 LTS
OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode, sharing)


Web client script sftp-0.8.0.min.js

Can you provide the sftp-0.8.0.min.js file? The site is offline.

@lucasdidur One way to get this file is to checkout this project, install dependencies (npm install or yarn install), and then run the build command (npm build or yarn run build). You'll end up with sftp.js and sftp.min.js in the ./build/web folder.
Attached are the distribution files for 0.8.0, compiled on NodeJS v12 using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>to make the install and build process work with NodeJS 12.
build-0.8.0.zip

@lucasdidur Also wanted to mention that I have forked this project and published the web version of the client on npmjs.com. You can find that package here:
https://www.npmjs.com/package/@inveniem/sftp-ws-web
Usage information is in the README of the parent project:
https://www.npmjs.com/package/@inveniem/sftp-ws#using-with-webpack-in-a-browser-basedspa-app


istioctl bug-report: use .tar.gz

To fix https://github.com/istio/istio/issues/30836

@shamsher31: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
fa1fc2ea0414ba88d8f6712b6953b3c3b2f0b285
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-pilot-k8s-tests_istio


Page links MUST be fixed

Incorrect document links exist:
Ex. Chemistry => -16cchemistry(2) =>17-18cchemistry(3) => 19cchemistry(4) => 20cchemistry(5)
(number) indicates page's rank. this is correct link. but,
Chemistry => -16cchemistry(2)
=> 17-18cchemistry(3)
=> 19cchemistry(4)
=> 20cchemistry(5)
Note that page links should connect pages in rank order(i.e. consecutively, 1->2->3->4->5).

Prototype will be removed in future.
Closing issue.


Use the glc crate to generate expressions for tests

Using the glc crate we can generate random expressions based on a context-free grammar. With this we are able to randomly and programatically generate the arithmetic expressions that are accepted by mexe in bulk for more comprehensive testing. Can help with issue #4.

Done in https://github.com/yds12/mexe/commit/58202092b33ae13667bf733a5d631c7c417cdc95


New Extension: Species Type

This pull request has a new file for standardizing the names of particle species. See #176 .
Affected Components: None.
Writer/Reader/Data converter Changes: At this point none since the present standard does not reference particle species names.

Left-over to do's from #177:

[ ] hardons: define protons & anti-protons
[ ] separate anti-particles by , instead of putting them in brackets
[ ] remove extension-ID (2.0.0)

@ax3l There also should be a version number associated with this. I assume it should be 1.0.0 .

@DavidSagan the version number will simply be the one of the standard it gets in with.

@ax3l

the version number will simply be the one of the standard it gets in with.

OK just to make sure I understand: Say in the future changes to an extension necessitates that it is to be bumped up a version. Then even if the base standard has not changed it will be bumped up to? Yes?

Exactly so far.

@ax3l Should we merge this?

ok, I addressed the last inline comment about the location of the SpeciesType attribute, so reader implementors know where to expect it

Minor detail: Since neutron is a common standard name do we want to use neutron, anti-neutron rather than other:neutron, other:anti-neutron?

We can do that. It's just not too common for us since it's not charged ;-)
I did just draw a line (arbitrarily) since (anti-)protons are the only stable free hadrons.

@DavidSagan moved (anti-)neutron to common and added sigma baryon as another example. now we draw the line at the nucleus :D


feat(karma-runner): Support angular public api

Add support for angular's public API. It is save to merge, the public api was already there since angular 6.0, but never documented. The private API we're now using will be removed when https://github.com/angular/angular-cli/pull/12499 is merged.

Nice find!


fix: poster slot fade after play before playing

fix #823

Per @luwes's advice: before/after smoke tested using

Before: https://media-chrome.mux.dev/examples/vanilla/advanced.html
After: https://media-chrome-git-fork-luwes-fix-poster-mux.vercel.app/examples/vanilla/advanced.html

Using dev tools, disabled cache and throttled network to slow 3g. Once controls rendered, attempted to play using play button.

Before: poster image would fade with controls
After: poster image stays rendered until the media has loaded.
🎉


Switch wastewater data source

Switch the wastewater data source from e.g. https://www.mass.gov/doc/covid-19-weekly-wastewater-report-raw-data-february-23-2023/download to https://www.mwra.com/biobot/biobotdata.htm.  The latter has fewer gaps and duplicates.

Switching data sources is of questionable value.  The 2nd URL also has many data gaps.

Switched to the weekly, no-gap data that also begins earlier: https://github.com/biobotanalytics/covid19-wastewater-data
See git commit 6bb38d.


Move pulling base image into a plugin

For backwards compatibility the plugin is automatically enabled when not explicitly listed - we can remove that once we're sure everyone's osbs-client is updated.
Closes #218.

@mmilata your change LGTM, please review mine addition, thanks

This is definitely something we should aim for. The only problem I have with current implementation is the code in inner.py. I think this is where we should probably introduce build types. Because I think that configuration of pulling base image should be as simple as possible. We should not force users to write json.

@jpopelka Thank you! I'll try running the tests with NOMOCK=1 next time.
@TomasTomecek Right, I didn't realize that when the code that automatically enables the plugin is removed it becomes impossible to start a build from API without providing a build json. Does this mean we need to solve #85 before moving the base image code to a plugin?

I've fixed the issue with cli/api builds based on offline discussion with @TomasTomecek. I also removed the change_source_registry plugin which doesn't do anything when pulling base image happens in a plugin.

Would be nice to see a couple of tests in tests/plugins/test_pull_base_image.py for the new plugin.

Oh, ignore me, I missed them before.
Looks good to me.

Found a little bug, pushing once again ...

Rebased.

LGTM, nice work!


build: support holochain beta rc2

Fabulous, thanks! I'd say we can merge it, what do you think @guillemcordoba?

OMG this is so good @mattyg ! Thanks :)
May I ask for which project do you need this?
The main thing I would change for this PR to be perfect would be to replace the name field of the RankingIndex struct to link_type: ScopedLinkType. The function of the name was to differentiate two rankings in the same DHT, but actually we can just do this with the link type now. I don't think we want the link type to be a dynamic input for one specific ranking, it should be fixed.
Thoughts on this @matthme @mattyg ?

Makes sense to me! I updated the PR to make the change. I also bumped the package version to 0.2.0, in case anyone was relying on the prior version. Let me know if that makes sense or I should revert.
I'm thinking about possibly using / forking it to use in clutter -- though I'm not exactly sure if it makes sense.
Basically I want to collect aggregated metrics like "top 10 licked mews" or "top 10 most active conversations" over the past week / month / year. Rather than having each agent perform a huge get_links query for this potentially huge amount of data, and aggregate the results themselves, I was thinking it might work to setup a "caching" layer, where some subset of agents perform the query, aggregate the results, and publish them as a ranking index. Then other agents who just want to view the aggregated metrics can simply query the ranking index.

That's perfect, @mattyg . Almost there :)


Make errors about metrics which we failed to generate readable

Right now errors are reported as below, which makes them completely unreadable.
WARN[0000] Job kube-state-metrics ran with errors: populate errors:, error generating entity ID for default_cockroachdb-2: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_storage-provisioner: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for default_sh: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kube-apiserver-minikube: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kube-controller-manager-minikube: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_coredns-5c98db65d4-pgnvj: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for default_cockroachdb-0: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kube-scheduler-minikube: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_etcd-minikube: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_metrics-server-67fb648c5-xcx7h: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kube-state-metrics-6766c6d46b-rwzpw: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kube-proxy-njc6c: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_coredns-5c98db65d4-m76hk: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for kube-system_kindnet-hdg22: cannot fetch label pod for metric kube_pod_status_phase, metric not found, error generating entity ID for default_cockroachdb-1: cannot fetch label pod for metric kube_pod_status_phase, metric not found

Ya, this error message is very long. It sounds like a situation that could be caused by using something like hashicorp/multi-error in a for-loop, and returning all errors at once.


feature: Adding codegen config support for spm module type versions

Adding new codegen config options for supplying a version to the SPM module type to allow for pointing to specific branches or local versions.
Closes apollographql/apollo-ios#3017

🛠 Docs Preview Building...

Configuration
{
  "repoOverrides": {
    "apollographql/apollo-ios-dev@main": {
      "remote": {
        "owner": "apollographql",
        "repo": "apollo-ios-dev",
        "branch": "feature/package-config-3017"
      }
    }
  }
}

b32dcc9e13ff25fd5c88b22315b35c2cc4fcd3f9

I just had the thought that maybe allowing something other than https://github.com/apollographql/apollo-ios.git makes the CLI version checking less useful BUT is this whole PR change doing that? How do we now ensure generated code compatibility with the runtime used by that generated code?

I just had the thought that maybe allowing something other than https://github.com/apollographql/apollo-ios.git makes the CLI version checking less useful BUT is this whole PR change doing that? How do we now ensure generated code compatibility with the runtime used by that generated code?

Likely you're just making some changes in your fork that don't affect codegen compatibility, but yeah any manual dependency here means you may generate incompatible code. That's something the user needs to accept and deal with on their own. If you're using anything but the default package version, we shouldn't even be using the version checker at all actually.
The version checker isn't foolproof right now anyways. It only runs on the CLI, not Swift Scripts, and if it can't find a package.resolved file, it won't run at all. But worse case, you generate code that doesn't compile properly and you know it when you try to build. This is just to attempt to detect that early and give you a clear error message.
But I'm actually wondering if we should move this into ApolloCodegenLib now. We are currently only running it when using CLI, but could probably run it while using Swift Scripts also. Doesn't need to be in this PR if we decide to do so.

But I'm actually wondering if we should move this into ApolloCodegenLib now. We are currently only running it when using CLI, but could probably run it while using Swift Scripts also. Doesn't need to be in this PR if we decide to do so.

Yes we probably should, and in a separate PR.

Reviewing this again got me thinking. Is it worth adding an option for users to point their Apollo dependency to their own fork? Right now you can point to a branch or commit hash, but it's still only on the url https://github.com/apollographql/apollo-ios.git.
@BobaFetters @calvincestari do you think that's worth doing at this time?

I don't see a reason not to add that, I guess maybe add a url associated value that defaults to apollo-ios to the existing cases? Although we dont currently have a case that supports version numbers since for Apollo we want it to match the codegen version, so may need a new case that can support the from and exact versions.


[add] opendata harvest spec

Coverage decreased (-0.02%) to 80.204% when pulling 2a757afecbe84dfd76537af893339c24ab78a795 on itowtips:fix-harvest into ac7b75948d2438c56b8b57e56029b468d9dd6c62 on shirasagi:master.


Special case for openrss.org feeds — download one feed per refresh session

This is as a result of conversation with openrss.org — we hit their servers too often and too rapidly.
Also: just for them we’ll include more info in the User-Agent field (platform/version/build), which they need to be identify which clients to block.

Other changes in this release are also driven by them — paying attention to Cache-Control and to 429 responses.


WinUI 3: AppBarButton's Flyout cannot be dismissed

Describe the bug
In Win UI 3, the flyout of an AppBarButton is buggy after we clicked the button in the CommandBar overflow popup, the anomalies includes:

light-dismiss overlay is not shown.
AppBarButton's flyout cannot be closed
AppBarButton's flyout is shown on the right instead of the bottom

In contrast, the behavior of the DropDownButton's flyout is normal.
Code used to reproduce the bug
<Window
    x:Class="WinUIBugRepro.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <CommandBar DefaultLabelPosition="Right">
            <AppBarButton Icon="SetLockScreen" Label="Test AppBarButton">
                <AppBarButton.Flyout>
                    <MenuFlyout LightDismissOverlayMode="On">
                        <ToggleMenuFlyoutItem Text="Item 1" />
                        <ToggleMenuFlyoutItem Text="Item 2" />
                    </MenuFlyout>
                </AppBarButton.Flyout>
            </AppBarButton>
            <AppBarElementContainer>
                <DropDownButton Content="Test DropdownButton">
                    <DropDownButton.Flyout>
                        <MenuFlyout LightDismissOverlayMode="On">
                            <ToggleMenuFlyoutItem Text="Item 1" />
                            <ToggleMenuFlyoutItem Text="Item 2" />
                        </MenuFlyout>
                    </DropDownButton.Flyout>
                </DropDownButton>
            </AppBarElementContainer>
        </CommandBar>
        <Button Content="Click Me" HorizontalAlignment="Center" VerticalAlignment="Center" />
    </Grid>
</Window>

Steps to reproduce the bug

Create a new WinUI 3 Packaged project in VS2022
Replace the content of MainWindow.xaml by the code above
"Run" the app using F5 or Ctrl+F5
Click the AppBarButton and DropDownButton in the CommandBar, the behavior is normal now
Narrowing the window size so the AppBarButton and DropDownButton are moved to the overflow popup of the CommandBar
Click the DropDownButton in CommandBar's overflow popup, the behavior is normal
Click the AppBarButton in CommandBar's overflow popup, the light-dismiss overlay is not shown
Expanding the window so that AppBarButton and DropDownButton are moved back to the primary commands area
Click the DropDownButton, the behavior is normal
Click the AppBarButton, the light-dismiss overlay is not shown, the flyout is shown on the right
Click the "Click Me" Button in the Window content, the AppBarButton's flyout cannot be dismissed

Expected behavior
The AppBarButton's flyout should always behave normally when it is in the primary command area:

the light-dismiss overlay is shown
the flyout can be dismissed by clicking outside
the flyout should be shown at the bottom

Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.0 (If you're seeing your issue in older previews of WinUI 3, please try this release)
Windows app type

[ ] UWP
[x] Win32

Device form factor
Desktop
Windows version
Windows 11 Pro 21H2
22000.348
Additional context
This bug also exists in Windows Explorer ("Sort" DropDown & "View" DropDown).

@llongley FYI, thoughts on what might be happening?


Check which readers work and don't.

Go through the Data Challenge submissions for folder C-time-series-extracted-1D-spectra.
Figure out which extracted spectrum files can be loaded, and which can't.
Keep track in a google doc shared with Zach.
Make sure you're starting from version 0.0.13.
@will-waalkes , could you help with this?

Yes! I'll send you a google doc by tomorrow morning

With @will-waalkes 's help, we got through all the files that were submitted by the (start of the) spring ers-transit data challenge. This gist shows how each of them can be read.
The necessary new readers were tidied up and documented in #56 .


Bug with specifying config on dev

Previously I can just do 'python pokecli.py -cf ./configs/config.json' and specify a config file. Now it breaks and gives me this error. The config file is fine, when I run it with ./run.sh or ./pokecli.py it runs without any problems.
I'm guessing it's because an environmental path is not set correctly?
Traceback (most recent call last):
File "pokecli.py", line 46, in
from pokemongo_bot import inventory
File "/Users/xxx/PokemonGo-Bot/pokemongo_bot/init.py", line 28, in
from pokemongo_bot.event_handlers import LoggingHandler, SocketIoHandler, ColoredLoggingHandler, SocialHandler
File "/Users/xxx/PokemonGo-Bot/pokemongo_bot/event_handlers/init.py", line 4, in
from social_handler import SocialHandler
File "/Users/xxx/PokemonGo-Bot/pokemongo_bot/event_handlers/social_handler.py", line 4, in
import paho.mqtt.client as mqtt
ImportError: No module named paho.mqtt.client

pip install -r requirements.txt --upgrade

That worked! thanks. I thought the ./setup -u script does put the --upgrade parameters. I guess not!


Testing steps

Hello,
Would be great to have MSI for Intune deployment, strange why not included.

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

ID: 00a00a3e-a0df-7ee5-4733-7231bd7a024f
Version Independent ID: 94361683-e1e7-7e55-6993-86d3c2486a14
Content: Connect Windows computers to Azure Log Analytics
Content Source: articles/azure-monitor/platform/agent-windows.md
Service: log-analytics
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@lightupdifire Thanks for the feedback. We have assigned this request to the content owner to review and update as appropriate.
@MGoedtel Could you please share your thought on the above query?

@lightupdifire - I'd like to hear more about this scenario.  Can you explain why you would want to have an the Log Analytics agent deployed via Intune?  Thanks

@MGoedtel, I try to get WIP analytics data, like explained here:
"https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/collect-wip-audit-event-logs"
The "Reporting CSP" solution not clear, so the way how I could use WIP logs was using Windows Monitoring Agent, but to deploy it to device i can use Intune solution only, but file is EXE...
So to deploy file via Intune i need supported files, which could be MSI:
"https://docs.microsoft.com/en-us/intune/apps-windows-10-app-deploy"

@MGoedtel, I could deploy by extracting MSI.
So maybe you can add a note to this article, that it is possible to install MSI package via Intune,
I did extract "MMASetup-AMD64" to get "MOMAgent.msi",
Then used MSI line like:
"MOMAgent.msi /q /norestart NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID= OPINSIGHTS_WORKSPACE_KEY= AcceptEndUserLicenseAgreement=1"
BTW. just tested to deploy MSI and this parameters line via Intune and it worked well, even on non-AzureAD joined device, only AADRegister+MDM Enrolled. Now need wait if will show up in logs/detected devices.
Regards TLS 1.2, is it mandatory to deploy?

@lightupdifire - Deploying the agent using Intune wasn't a use-case/scenario that we planned to support or see customer interest in.  Reporting CSP isn't a solution that integrates wtih Azure Monitor from what I can tell by reading the documentation.  Because this isn't a real issue with the documentation and you are trying to implement something custom, based on the basic information you provided, I'm requesting we close this issue - @SadiqhAhmed-MSFT  - #please-close.
In answer to your question, yes TLS 1.2 is mandatory.
Thanks.

@MGoedtel,
This case is related to another case:
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/2376#issuecomment-491980079
In short:

Microsoft offer WIP
WIP procedure says that to analyze WIP logs we should use Reporting CSP
Reporting CSP not working
At this step WIP logs analyze not possible, this means that solution is not workable
Collecting logs from device is possible to use Windows Monitoring Agent

During my tests I can use now Windows Monitoring Agent, which is installed on AAD joined or non AAD joined device...

@MGoedtel,
My test "Windows 10 1809" device worked without TLS 1.2 registry applied, so possibly it is mandatory for have secure transfer and not for making tool to work..

@mypil,
If Microsoft Monitoring Agent is compatible with Windows 10 desktop, then there is no need to deploy "Device Health" solution to Azure tenant in order to work with WIP App Data learning:
https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/wip-learning
Because using Microsoft Monitoring Agent I can read data from device AAD joined or ADD registered + MDM Enrolled from this event log:
"Microsoft-Windows-EDP-Application-Learning/Admin"
This log give me info about applications access towards WIP protected files and can use that info to trust/block access..

@lightupdifire - I'm not suggesting we are rejecting deploying the MMA agent to Windows 10 system, whether it is virtual/physical.  I was specifically calling out the scenario of deploying it via Intune is something we haven't tested/documented and commonly hear from customers that want to use as a deployment method for the agent.  That being said, I'm happy to create a work item for this and then update the docs to call out that you would use the same method I have described for using other automation tools for extracting and deploying using the MSI package will work with Intune.  The agent has no dependency on AAD to authenticate with AzMon and the workspace, its based on the workspaceId/PriKey that you configure with the MMA agent.

@MGoedtel,
Super! Then this MMA will help to fix 2x issues for WIP product:

WIP Log analyze
WIP App learning

I landed here looking to leverage the same agent to stream windows 10 logs into azure sentinal - Microsoft's SIEM. Unless I am missing another method, I see the agent being the quickest solution deployed through intune MDM to all devices to ensure full monitoring across all devices, servers and desktops.

I'm evaluating the suggestion as part of our sprint planning for documentation.  Since there isn't an issue with this article, but questions around supportability by deploying the Windows agent (MMA) with Intune, which I've answered, I'm suggesting we #please-close this article.


contact us section is added on nav bar

Description 📝

Fixes/Closes: #295
Please provide a brief description of the purpose and goals of this pull request.
Changes 💬
contact us button is added in nav bar so when ever user click on the contact us it will redirected to that section.

High-level overview of the changes introduced.
Step-by-step breakdown of the implementation, if applicable.

Additional Notes 📒
Include any additional information or context that might be helpful for the reviewers.
Also if you are fixing the already made PR and the reviewer demands some change in it then, in each PR you have to mention the issue you have fixed in it.

please create a new pr with only required files and close this pr


Error: app/src/main/res/values/colors.xml already exists when adding plugin

Issue resolved so believe it must have been a local issue.


Permission issue for Postgresql 14 using a strict security context

I think the arm build is setting the permissions different here as well

Maybe it has been fixed.

@ZCube the latest 14.5 version is published a month ago? https://github.com/ZCube/bitnami-compat/pkgs/container/bitnami-compat%2Fpostgresql/versions?filters[version_type]=tagged

@roderik There was a typo in the build script.

Works!


How to alter POD to use local version of js api

Hi there,
Would someone be able to let me know to modify the js of POD so it referenced a local copy of the api instead of using https://js.arcgis.com/3.13/...?
At present, we are experiencing intermittent 403 errors when trying to load different components of the api (eg. BasemapLayer.js, BasemapGallery.js, etc) from https://js.arcgis.com/3.13.
Thanks

@aryan200o You can download a copy of the API here: https://developers.arcgis.com/downloads/
From there, you would have to deploy the API on your own web server, and change the URLs in the POD code to point to the location where you are hosting it.

skmoore,
I was able to setup the local version and alter to the urls within POD to use this copy. Working so far.


Getting started with RestFul web API in Dart programming

Proposed article introduction
Key takeaways
By the end of completing reading this tutorial the learner or reader will gain:

Basic knowledge in Dart language
Gain knowledge on how to build restful api in Dart
Be able to deploy web application in Dart

Article quality
hope that the article is a new topic.
References
Dart programming language
Conclusion
Finally, after going through this tutorial you will gain knowledge in building Web APIs using Dart language and be able to determine the importance of using Dart to JavaScript.

👀
@josephotienoowino
The content provided here seem a bit light for us to make an informed decision - I'll refer to the expertise of the @section-engineering-education/content-moderator-team for more insight.

Agree with you @hectorkambow
This topic is already covered by a lot of tutorials. Please feel free to suggest a new topic to explore! @josephotienoowino


Browser and PlatformProperties are null

deviceService is good but other parts their property is null
I haven't tested _engineService but the other 2 parts their properties are null

Me too! Yeah same problem here.

Sorry, Browser, Engine, and platform doesn’t not have work solution yet.

Browser module is functional and will be release with beta7

This issue will be close and the remaining feature of platform would be tracked via #54


Nested JSON

It would be great to see a couple more example in the Readme.
I am looking to create model for the following JSON:
"pricing": {
        "USD": {
            "price": 42
        },
        "CAD": {
            "price": 60
        },
        "MXN": {
            "price": 510
        },

    }

the currency codes are not predictable. Can be anything.

Hey @oscarmorrison,
I think the PropertyDictionary class is what you're looking for.
If you define a couple of models:

PriceContainer: contains a dictionary of all the prices
Price: contains the price value

Then you can parse the JSON you posted like this:
final class PriceContainer: Model {
    let prices = PropertyDictionary<Price>(key: "pricing")
}

final class Price: Model, JSONTransformable {
    let price = Property<Int>(key: "price")
}

let json: JSON = [
    "pricing" : [
        "USD" : [
            "price" : 42
        ],
        "CAD" : [
            "price" : 60
        ],
        "MXN" : [
            "price" : 510
        ]
    ]
]

let container = PriceContainer(json: json)

for (currency, price) in container.prices {
    print("Currency: \(currency), price: \(price.price.value ?? 0)")
}

// prints:
// Currency: USD, price: 42
// Currency: CAD, price: 60
// Currency: MXN, price: 510

Thanks very much @jlandon exactly what I was looking for


Support mod 'puppetlabs-apt', '4.5.1'

I had to modify init.pp since the latest apt module changed parameters

Hey @lrfurtado, thanks for this - would you be able to fix the linting failures (seems to be just alignment of => operators) - other than that this should be good to go.

This has been superseded by #83, which has been merged and released as v1.0.0. Thanks!


initialRouteName ignored after passing navigation prop to nested navigator

In my app I have two navigators. One TabNavigator and a StackNavigator. Both are wrapped by components.
AppNavigator (Tabs: DishesScreen, DealsScreen, FavoritesScreen)
All screens are rendering a StackNavigator (consisting of DishList, DishDetails)
Everything works fine until I need to pass the navigation prop from the AppNavigator down to the screens and set the router after each class (like DishesScreen.router = DishesStack.router) to navigate back to the DishList if the user taps to time on the same tab (This works fine).
In my AppNavigator I have this:
export default TabNavigator({
  Deals: { screen: DealsScreen },
  Dishes: { screen: DishesScreen },
  Favorites: { screen: FavoritesScreen },
}, {
  initialRouteName: 'Dishes',
....
})

But if I start the app the FavoritesScreen is alway appearing...
And: The header of DishesScreen or DealsScreen are not visible randomly..
If I remove the  navigation={this.props.navigation} from the DealsScreen, DishesScreen and FavortesScreen everything works fine but navigating back the StackNavigator from the TabNavigator is not working anymore...

software
version

react-navigation
1.0.0-beta.13

react-native
0.50.1

Duplicate https://github.com/react-community/react-navigation/issues/2609


bug: prank takes effect on local event emissions

Component
Forge
Have you ensured that all of these are up to date?

[ ] Foundry
[ ] Foundryup

What version of Foundry are you on?
forge 0.2.0 (6ca977f 2022-05-29T02:05:46.434519993Z)
What command(s) is the bug in?
forge test
Operating System
Linux
Describe the bug
Details
Does not work:

Works:

prank is not used up by calls to vm which is my alias for HEVM_ADDRESS/cheatcodes.

As such, it stands to reason that the event emission is being treated as a CALL?
I would have thought emitting an event is a JUMP and would not have used up prank?

Proposed Next steps

[ ] Confirm/deny this is expected behavior
[ ] Optionally open a PR handling the case of local event emissions consuming prank
[ ] Optionally document this behavior in the book or Vm.sol inside forge-std

Isn't the prank used by the owner() call you're making? Pranks are not consumed by log emission

That's embarassing, gotta check my eyesight it seems - closed

all good - thx for flagging!


OpenSSL 1.1.0-stable Branch Broken?

The OpenSSL 1.1.0 Stable branch builds are failing:
https://travis-ci.org/openssl/openssl/builds/410827758
https://travis-ci.org/awslabs/s2n/jobs/411023270#L2993
Looks like this commit is missing #include "internal/refcount.h" that was present in the cherry-picked commit?

Addressed in #6843. Thanks for heads up!


S3 Bucket - acl - Argument is deprecated

Found a bug? Maybe our Slack Community can help.

Describe the Bug
╷
│ Warning: Argument is deprecated
│
│   with module.build.aws_s3_bucket.cache_bucket,
│   on .terraform\modules\build\main.tf line 11, in resource "aws_s3_bucket" "cache_bucket":
│   11:   acl           = "private"
│
│ Use the aws_s3_bucket_acl resource instead
╵

Expected Behavior
Running the module does not throw any warnings
Steps to Reproduce
Steps to reproduce the behavior:

Run the module

Screenshots
If applicable, add screenshots or logs to help explain your problem.
Environment (please complete the following information):
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

The default value for acl is private anyways, so can just remove the line entirely

Should also be BucketOwnerEnforced


February tasks

[ ] Request Kaiser Permanente family health survey.
[ ] Update RAPID SOW to include Graciela's contribution
[ ] Develop sample VT dataset for USU team
[ ] Schedule all team virtual meeting
[ ] Clinical Health repository follow-up

Develop data sharing policy

Action items from Christina and Miguel 2/12/2018


UFH-5914 Filters

UHF-5914 News archive filters
Feature for adding filters to news archive app.
What was done

Added upgraded version of news archive app

Added capability to filter results via dropdowns

Read more here: https://github.com/City-of-Helsinki/helfi-etusivu-news-search/pull/4

How to install

Make sure your instance is up and running on correct branch.

git checkout/UHF-5914-filters
make fresh

Make sure your elastic is up and running and has news indexed to it:

Run docker-compose ps and seet that the elastic container is up
Check the index management page: https://helfi-etusivu.docker.so/en/admin/config/search/search-api/index/news

Run rebuild tracking information
Run Index now

make shell into container

Run drush locale:check && drush locale:update to get translations

Run make drush-cr

How to test

Navigate to the news page: https://helfi-etusivu.docker.so/fi/uutiset
Search functionality things to test for:

Filters components should work
Filters and results should consider the language context
Query should be executed only when pressing the submit button OR the 'clear all' button
No results should render 'no results' text
Changing the filter values should be represented in the url query string

Things to consider when testing:

Fallback listing and react app are being displayed at the same time for now.. to be fixed in an upcoming ticket. Meaning there are two same looking news lists. This PR is for testing the top-one (with filters).

Making "Most read news" -block work with react-app needs work (upcoming ticket) so the search app is 100% width for now.

Filter pills are not implemented yet.

Some translations are missing (pending PO).

[ ] Check that this feature works

[ ] Check that code follows our standards

Designers review

[ ] This PR does not need designers review
[ ] This PR has been visually reviewed by a designer (Name of the designer)

Other PRs

*https://github.com/City-of-Helsinki/helfi-etusivu-news-search/pull/4

The filter button moves when a filter is selected from the dropdown
Also the "tyhjennä valinnat" text should be black and maybe the styles (hover etc) revisited? Now it looks like it's not inline with the filters above since it uses button styles

Margin missing with the no results text

Results pager is not using the correct styles


fwup: init at 0.14.2

Motivation for this change
adds fwup package
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@Mic92 Thanks, added maintainer and patch.

For some strange reasons some tests fail on my machine, while functional on travis:
https://gist.github.com/Mic92/cda72ea4f028ff33e440c22dc2df15de

@Mic92 Hmm, strange. Are you using NixOS? Which filesystem? I will try to replicate.

Oh, could be that it does fail on zfs, I will checkout on ext4.

ok, ext4 works fine.

@Mic92 thanks, I replicated this on ZFS and reported upstream

This seems to be failing:
https://hydra.nixos.org/job/nixpkgs/trunk/fwup.x86_64-linux

Looks also filesystem related.

FAIL: 105_require_path_on_device
================================

1c1
< fwup: correct
---
> fwup: catchall

Test failed!

Leaving test work files in '/build/fwup-v0.14.2-src/tests/work-105_require_path_on_device.test'
FAIL 105_require_path_on_device.test (exit status: 1)

@matthewbauer @Mic92 Thanks, have reported upstream. The ZFS issues have been resolved, I will open PR to update the derivation once a new version with fixes has been released.


Test: cupyx_tests/distributed_tests/test_comm.py times out in ROCm

https://jenkins.preferred.jp/job/chainer/job/cupy_master/1839/TEST=rocm-4-3,label=mnj-mi50/console

It seems the issue disappeared. Let's revisit if it occurred again.


Implementation of /context-docs endpoint

This addresses #123. One important point to add is that context_type only accepts values "docs" or "url".
Scenarios tested:
Sample request

Missing context

Missing content

Missing context_type

Invalid context_type

Two detectors

Threshold filtering (compare to the previous scenario)

Detector returning 404

Detector returning 503

Detector returning 500 (further details are shown on logs)

Detector returning 422

Client method names should follow the names of the calling endpoints.
Currently:
text_contents -> /../text/contents (good)
generation_detection -> /../text/generation
detect_for_context_documents -> /../text/context/doc
Also, aren't some of these endpoint names being changed?

I was trying to name functions using verbs as functions "do things", but I see your point.
Done!


Keysfirst

Changed the main page so that it populates based on the salt-keys. Previously that was done based on the actual minion status retrieval. The updated method always provides a quick load of the page. Even when one or more minions are not reachable.
The visual effect is that the page first shows the key status (accepted/denied/unaccepted/rejected). The accepted state will then be replaced by the actual state of the minion.
Also fixed a mixup between the denied and rejected keys.

strange, that is why variable "minionsLoaded" was removed.
The gui should be shown as soon as both jobs and keys are available.
The minionstatus will continue on the background.
Until the minionstatus is available, the screen displays the key status of the active minions, which is of course always "accepted".
just tested in firefox and chrome again --> ok

I r(e)tested this a bit by manually triggering the goTo('/') and now I see indeed what is happening. It is only not happening when you login, only when you press the 'SaltGUI' button when you inspect a recent job. (at least here, with both Chrome and Firefox).

In my case the home screen is properly updated both after login and when clicking on SaltGUI logo.
Any browser cache effects?
Any javascript errors on the login sequence?

I think the difference in behavior is explainable by different salt versions. I see the expected behavior using salt 2018.3.x vs 2017.7.x Can you confirm?
As a sidenote, I see the following with salt 2018.3.x:

I was on 2018.3.x
reverted to 2017.7.x --> everything still working fine with FF+chrome+edge
on the sidenote: these are the internal jobs that are behind the api calls. since I introduced wheel.key.list_all, I've added that one to the list of ignored jobs in _updateJobs.

Ah, maybe I found it:

So your installation is processing MINION information for which no KEY information is available.
I'll investigate the root cause for that.
(and also add some more error handling anyway)

The docker image results in "404 Not Found /// The path '/app' was not found." Any hints?

Added simple error handling.
Can you please retest?
The console will now log the cases for which no gui element could be found.
2 possibilities that I can think of:

the minion list really has an item that is not in the key list (and will never be in that list)
the minion list has an item that is not yet in the key list

For me to reproduce:

First login, then it works fine.
Press logout, login again, then it says it can't find these minions

OK, this proves it is possibility #2 "the minion list has an item that is not yet in the key list".
On this system, retrieving the Keys from the Master is actually slower than retrieving the Minion data.
The fact that it happens when you login again should be a coincidence, probably caused by the fact that the minions are now even faster.
In my case, there is always a few minions unreachable, due to scheduled shutdown.
Just a moment while I fix this...

Reproduced by simulated fast /minions call.
Now fixed so that return values from /keys and /minions can now be processed in any order.

the requested changes have been made, anything else I should do for this PR?

@erwindon Thnx! I will test it later today, if it's ok I'll merge it!


Character garbled

I use 'ng build' command to create a library. but library import a js module。like this

and after build, result is this

How to solve this problem？

done.


importccl: cleanup how we ignore stmts in IMPORT PGDUMP

PR: https://github.com/cockroachdb/cockroach/pull/57827
From release notes:

Users will now need to specify ignore_unsupported to ignore all unsupported import stmts during an IMPORT PGDUMP. [#57827][#57827] {% comment %}doc{% endcomment %}

Made obsolete by #10147.


[FEATURE] Add checkstyle support in repo

Description
Adding spotless support for the repo
Issues Resolved
#1591
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

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

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

Integration tests are failing. Could you please check?

Integration tests are failing. Could you please check?

@dhrubo-os  I cannot replicate the error on my laptop, do you have any suggestion on how to discover the error?


Getting error after updating to 1.1.0

I have this
var Sticky = require('sticky-js');
var sticky = new Sticky('.sticky-item');

And it worked before updating but now it's throwing Cannot call a class as a function via sticky-compile.js
  function Sticky() {
    var selector = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : '';
    var options = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : {};

    _classCallCheck(this, Sticky); <-- line

Hi @bbashy
Thanks for reporting the issue. Can you please tell me on what browser your are getting this error?

OS: macOS Sierra
Browser: Chrome: version 54.0.2840.41 beta (64-bit)
or
Browser: Safari: version 10.0 (126<IP_ADDRESS>.10)
I looked into it a bit more and it could be something with webpack. This is what got updated on npm
npm update
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>

I can also confirm the samwe with Firefox 49.0.1.
With @bbashy mentioning webpack I've also just tried it with browserify as well and it's producing the same error.

There was a conflict in exporting function. Fixed it by moving CommonJS export above AMD #bdc56ba.
Please update sticky-js to the newest version 1.1.1.
I've tested it with webpack & browserify and it works but it would be great if you could confirm me that it works for you too.

@rgalus Top work. Fixed. :+1:


Temporarily ignoring the intermittent test

https://issues.jboss.org/browse/UF-512
@manstis @porcelli @paulovmr
This test is randomly failing on Jenkins and avoiding us to having green builds.
I don't like to do that, but as I know that everyone is busy at the moment I would like to temporarily ignore this test.

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

See how the build is green now? 😢

@ederign @paulovmr @porcelli Theses tests were re-written using Byteman to remove a Thread.sleep(..) for an arbitrary delay as such delay was not guaranteed to be sufficient in some environments (whilst massively long in others). So, if the test is now failing IMO we should look why as it should no longer fail sporadically; but only for a good reason.

Yes. I hope someone has time to take a look on this soon. But for now, I've created the JIRA for this issue and merge this. Red builds really disturbs me.

Closing this after talking with @porcelli because can be a real issue.
@manstis I'll try to prioritize this with kris and edson.


We should have a linter for go mod vendoring

In dep we had a test that would fail if you didn't vendor correctly.
Now with go mod require devs to follow https://github.com/istio/istio/wiki/Vendor-FAQ and go mod tidy && go mod vendor but we don't actually test this, so a lot of bad changes get in.
@kyessenov @geeknoid

I'd rather simply stop vendoring. We're not vendoring in other repos and it's been working well.

+1 to stop vendoring.

wait until 1.2 is out so we can move forward with go 1.12
update license checker script
add a few module proxies; the default one went down last Sunday

On Thu, Jun 13, 2019 at 8:27 AM Martin Taillefer<EMAIL_ADDRESS>wrote:

I'd rather simply stop vendoring. We're not vendoring in other repos and
it's been working well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/14795?email_source=notifications&email_token=ACIYRRWVTNW47E32LDEKXCDP2JRO7A5CNFSM4HX2R6H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUCD3I#issuecomment-501752301,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACIYRRWNF2U736GZN2NYVV3P2JRO7ANCNFSM4HX2R6HQ
.

We all adapted to vendor,  please do not remove it.
Just need to add a CI for it

@hzxuzhonghu Why do you think vendor is worth keeping?

Without vendor, users have to get all the vendors before compile, even just reading code requires all the vendors.

How does having multiple branches work without vendor? If I hop between 1.0, 1.1 and 1.2 there are different dependencies, do I need to figure out all the dependencies every time I switch branches? Does it impact CI speed?

When you don't use vendor, packages are stored in an invisible module
directory. Multiple versions of these packages exist, based on the hash or
version #. So you can switch branches all you want and you get the correct
version of the modules as specified in the branch's go.mod file. It
actually works well.
On Fri, Jun 14, 2019 at 8:01 AM John Howard<EMAIL_ADDRESS>wrote:

How does having multiple branches work without vendor? If I hop between
1.0, 1.1 and 1.2 there are different dependencies, do I need to figure out
all the dependencies every time I switch branches? Does it impact CI speed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/14795?email_source=notifications&email_token=AFNZYHNHPW7ZG4IW5FKK7KTP2OXD3A5CNFSM4HX2R6H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXXBQBY#issuecomment-502142983,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFNZYHMVKC2YXRF5A4RTA2TP2OXD3ANCNFSM4HX2R6HQ
.

We can't remove vendor yet since it's actually used during the build iirc. Some more investigation to be done on the current build process.

I don't believe we actually are doing as @geeknoid mentions else we would be broken as we were using Golang 10 for the builds up until yesterday.

@hzxuzhonghu Without vendor you would only need to pull once to get the files into the go mod cache. But you are correct that you have to do it once to prime the cache so you can do some of the more advanced IDE things.

@howardjohn
Modules are a standard part of the language now, so sooner or later vendor will have to go. There is no difference between keeping code in the vendor git directory, or in some shared infra cache, such as the one provided by the google module proxy. There are just two possible problems:

module cache can go down (e.g. recent GCP outage brought it down); we need several alternatives, as well as a GCS backup (go modules can read directly from files instead of HTTP servers) any time we make an important build.
external repository can disappear: one would question why we would even depend on such a repository to begin with, but a GCS backup can surely help here.

This all said, we do need a linter for the short term. We build from the vendor directory, not the cache, so someone putting a change into the go.* files won't really see the change during a build (they won't when building locally either (unless the set GO111MODULE=on or are using a non-standard dev path). Now that we have 1.12 in master we can decide on the best way forward. I suspect we'll keep the path for consistency, so start with GO111MODULE=on. and so forth. @kyessenov had some comments earlier. I'll gladly help with the move forward to modules fully in our dev environment.

 Then we can disable vendor.
We're already on the no-vendor go module plan in other repos.

I think @costinm  has some strong opinions on this, may want to get his opinion before we make such a change

Also take those who can not access the vendors (like in private cloud or firewall stopping from accessing outside ) in to consideration,

I think we can simply do something like this somewhere in prow (we used to do this in circles but that is going away)
	GO111MODULE=on go mod tidy && GO111MODULE=on go mod vendor
	git diff --name-only HEAD -- vendor | grep -v vendor/modules.txt | wc -l and compare to zero

I had to grep out vendor/modules.txt as on my laptop I had one line moved in the file running the above command.
I'll see if I can maybe come up with something in my free time.

We can refer to kubernetes vendor linter as well, i see it is there.

/vendor has 2 main purposes:

Make sure we can reproduce a build - git repos can go away. There are a couple of 'archives' that use go mod and keep old versions - I think it should be a requirement to integrate with one and test that it works.

Speed. We did tests and it appears a build using vendor is faster, or at least it was for dep. Any change to remove vendor should include numbers and tests to confirm we don't regress.

For the first issue - the proper solution is to make sure our releases include the source code of all
dependencies ( i.e. what vendor contains now ) and  it is possible to take the released .src.tar.gz and make it to produce a binary.
For the second issue - I believe some of the mod proxies may be close to the speed of having vendor, most of the overhead is in making connections and fetching N repositories (with full history) instead of one connection downloading all.

In other words: we should have a test that verifies we can reproduce a build ( maybe by adding a full .tar.gz and doing a make build from the .tar.gz without any network access ), and a second test for the build speed, before we can remove vendor.

have a look at #15056

@hzxuzhonghu What failure do you have with particular repos? You mention you don't have access to certain ones. Just trying to figure out a path moving forward if we remove vendor. As mentioned, most IDEs don't need the vendor anymore.
If you simply deleted vendor (or rename it) and try GO111MODULE=on go mod vendor, what happens? I would hope that Go would pull all the required repos into a new vendor directory. I understand it might take a bit (you might be able to set GOPROXY to local proxy to help with that). This would be a simple step to get a vendor directory if it was no longer in our repo.
I do see a change being made locally after testing myself:
	modified:   go.mod
	modified:   vendor/modules.txt

that I want to see about. Maybe the lack of a linter has allowed some changes...

@costin I agree with your #1 in that the lack of a vendor directory can make it harder to reproduce a build. I'm not sure if we, Istio, want to get into hosting a GOPROXY (Athens, go proxy, etc) that would keep old versions, etc. It would need to use some storage that is adequately backed up. This was always one of my reasons to say that the vendor directory should be checked in with the source. It seems that the new dependency management is making that tougher. The question is if we really think we can rely on the GOPROXY to cache versions or just fall back indirect access to the repos.
Network/no network test. I'm not sure how valid this is. We have to be able to have network access to at least get to a starting point (clone our current repo for example). If we simply say that we also need to pull the modules from the proxy (which is mimicking the clone of the vendor directory), is that allowed? In the later case, the tar would be the Istio directory plus go/pkg/mod.
For speed in #2, the actual go build post getting the modules seems to be equal. I'll see about getting some specific timings. The difference will be in cloning the repo with the vendor vs the time to clone the repo minus vendor and doing a go mod download (the build time should be approx equal post that) vs cloning the repo and doing a go build and letting it download modules during the build.

A quick check averaging over several attempts (clearing go modcache before each run)

go mod download (direct, no proxy): 82 seconds
go mod download (go proxy.io): 47 seconds

If we're paranoid about goproxy.io disappearing or losing old versions, we
could host this proxy ourselves. It's pretty simple. modules.istio.io
anyone?
On Thu, Jul 11, 2019 at 12:50 PM Eric Van Norman<EMAIL_ADDRESS>wrote:

A quick check averaging over several attempts (clearing go modcache before
each run)

go mod download (direct, no proxy): 82 seconds
go mod download (go proxy.io): 47 seconds

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/14795?email_source=notifications&email_token=AFNZYHNIUOH42QTTRHH5NODP66FIZA5CNFSM4HX2R6H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZXZIVQ#issuecomment-510628950,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFNZYHK7YLTBOAQM54T26FLP66FIZANCNFSM4HX2R6HQ
.

https://proxy.golang.org is in beta, has on-call support, and is almost ready for general consumption.

For setting up our own, I've also looked at https://github.com/gomods/athens which has storage drivers and https://github.com/goproxyio/goproxy which uses disk. The later doesn't seem like something to depend on, unless we have a way to back up the disk occasionally. Not sure what's available storage wise for setting up the former.
I did try the https://proxy.golang.org, but found a number of our modules aren't there yet.

@hzxuzhonghu What failure do you have with particular repos? You mention you don't have access to certain ones. Just trying to figure out a path moving forward if we remove vendor. As mentioned, most IDEs don't need the vendor anymore.

@ericvn It is because we have network limit from accessing google in China. We have to set a proxy, which may introduce unknow error. Also think about the hosts, which may have no access to the internet at all.

my understanding is that once you build once and the dependency are pulled down you can continue to build without internet - just like with vendor.
if we set up a proxy would you he able to access it? can you access other existing proxies?

I will test it later.

@howardjohn Yes. I could build fine once the modules are pulled down and in my local Go module cache and removing internet access.
@hzxuzhonghu I'm hoping your testing does show things will work. To simply get the modules into the cache you can try GO111MODULE=on go mod download which uses GOPROXY to define where to pull the modules. If unset, it will try to get them directly from the repos, else you can try export GOPROXY=https://goproxy.io and point to one of the caches (sorry if you already know all this).
If your IDE needs to find the files in the vendor directory you can run the go mod vendor which will place them there as well.

Feel very sad, We are already using a proxy to access internet from office, and do the above, a lot of errors occur.
$ go mod download
go: finding github.com/grpc-ecosystem/go-grpc-prometheus v0.0.0-20160910222444-6b7015e65d36
go: finding github.com/Microsoft/go-winio v0.4.12
go: finding github.com/alicebob/gopher-json v0.0.0-20180125190556-5a6b3ba71ee6
go: finding github.com/gotestyourself/gotestyourself v2.2.0+incompatible
go: finding github.com/Azure/go-autorest v11.1.0+incompatible
go: finding github.com/sethgrid/pester v0.0.0-20180227223404-ed9870dad317
go: finding github.com/ryanuber/go-glob v0.0.0-20160226084822-572520ed46db
go: finding github.com/coreos/go-oidc v0.0.0-20180117170138-065b426bd416
go: finding github.com/gogo/status v1.0.3
go: finding github.com/gogo/protobuf v1.2.1

go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/sethgrid/pester/@v/v0.0.0-20180227223404-ed9870dad317.info): 401 authenticationrequired
go: finding github.com/googleapis/gax-go/v2 v2.0.4
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/gogo/protobuf/@v/v1.2.1.info): 401 authenticationrequired
go: finding github.com/cenkalti/backoff v2.0.0+incompatible
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/ryanuber/go-glob/@v/v0.0.0-20160226084822-572520ed46db.info): 401 authenticationrequired
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/alicebob/gopher-json/@v/v0.0.0-20180125190556-5a6b3ba71ee6.info): 401 authenticationrequired
go: finding github.com/docker/docker v1.13.1
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/grpc-ecosystem/go-grpc-prometheus/@v/v0.0.0-20160910222444-6b7015e65d36.info): 401 authenticationrequired
go: finding k8s.io/kube-openapi v0.0.0-20180216212618-50ae88d24ede
go: finding github.com/istio/viper v1.3.3-0.20190515210538-2789fed3109c
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/%21azure/go-autorest/@v/v11.1.0+incompatible.info): 401 authenticationrequired
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/gotestyourself/gotestyourself/@v/v2.2.0+incompatible.info): 401 authenticationrequired
go: finding github.com/keybase/go-crypto v0.0.0-20190416182011-b785b22cc757
go: finding github.com/circonus-labs/circonus-gometrics v2.3.1+incompatible
go<EMAIL_ADDRESS>unexpected status (https://goproxy.io/github.com/coreos/go-oidc/@v/v0.0.0-20180117170138-065b426bd416.info): 401 authenticationrequired

...

I added go mod tidy to the make format. So we are 90% of the way there. I wasn't sure if doing go mod tidy and then git status was a good idea for the lint though

@geeknoid added some new gen-checks that will run go mod tidy and others and check git status, so I am closing this as done


Fix casing in include

For some reason this particular file has inconsistent casing with the rest of the files in the UE4 codebase and Linux is obviously case sensitive, so this causes build failures.
I've updated the include to match the casing of the actual file from UE4

@KieranChandler Will this still work in UE5 though?
I guess adding some extra checks might be worth consideration:
#if ENGINE_MAJOR_VERSION >= 5
#include "HAL/PlatformFileManager.h"
#else
#include "HAL/PlatformFilemanager.h"
#endif

I can check the casing of the file in UE5 and if its different then i could do that

Its good you asked that. because they fixed it in 5.0: https://github.com/EpicGames/UnrealEngine/commit/57baf1e5c77a7e6d26537927a705316ef67a4452

@KieranChandler Please add a corresponding changelog entry and I think we should be good to merge this. Thank you for bringing it up!


Document link to RQL Reference is a 404

Your docs are linking to an RQL Reference that no longer exists.
Replace this:
https://connect.cloudblue.com/community/api/rql/
With this:
https://connect.cloudblue.com/community/developers/api/rql/

Fixed, thx!


Create code generation implementation for Go 💙

The original code generation implementation was written for TypeScript, but it can be re-implemented to generate Go code. See https://gobyexample.com/structs for an example.

The logic for the Go code generation can be found in go-code-template.ts.


[bug] decimal typed column is always adopted as change_column

Columns typed decimal are shown in logs as changed_column.
After first time insertion, it endlessly tells that is changed.
Is this a bug?
create_table 'foo' ...
    ...
    t.decimal 'latitude', precision: 9, scale: 6, default: 0.0, null: false
    t.decimal 'longitude', precision: 9, scale: 6, default: 0.0, null: false
    ...
end

-- change_column("foo", "latitude", :decimal, {:precision=>9, :scale=>6, :default=>0.0})
   -> 0.0325s
-- change_column("foo", "longitude", :decimal, {:precision=>9, :scale=>6, :default=>0.0})
   -> 0.0183s

How about change default: 0.0 to default: "0.0"?

Fixed, and thanks for a quick response.
But is this the expected setting?
Cause' of ., should it braced with double quotation?

Ridgepole compares Schemafile and dumped DSL by ActiveRecord::SchemaDumper.
The default value of decimal (with scale) type is dumped as a string.
Therefore the default value in Schemafile should be a string.

Thanks, and now I found it on ActiveRecord::SchemaDumper.
But if the default value type was wrong,
should SchemaDumper return alerts on log?

I don't know what the case your mentioned (the default value type was wrong in SchemaDumper).
SchemaDumper extracts schema information from existing database (schema),
therefore all default values are valid.

Sorry, I misunderstood about that.
I'm so appreciate you answering so many times.
Finally, I just have a question where should this case be handled.
Until now, I couldn't know default type was invalid from ridgepole log.
(Because it shows just it was change_column.)

@timakin Sorry for the late reply 🙇
@kamipo Thank you for your comment!!

Until now, I couldn't know default type was invalid from ridgepole log.

Please use --verbose option.
It show column definition mismatch in console.
$ ridgepole -c '{adapter: mysql2, database: test}' -a --verbose
Apply `Schemafile`
# Parse DSL
# Load tables
#   foo
# Compare definitions
#   foo
 {:definition=>
   {"latitude"=>
     {:type=>:decimal,
-     :options=>{:precision=>9, :scale=>6, :default=>"0.0", :null=>false}},
+     :options=>{:precision=>9, :scale=>6, :default=>0.0, :null=>false}},
    "longitude"=>
     {:type=>:decimal,
-     :options=>{:precision=>9, :scale=>6, :default=>"0.0", :null=>false}}},
+     :options=>{:precision=>9, :scale=>6, :default=>0.0, :null=>false}}},
  :options=>{:options=>"ENGINE=InnoDB DEFAULT CHARSET=utf8"}}
# Update schema
-- change_column("foo", "latitude", :decimal, {:precision=>9, :scale=>6, :default=>0.0})
   -> 0.0382s
-- change_column("foo", "longitude", :decimal, {:precision=>9, :scale=>6, :default=>0.0})
   -> 0.0155s


Proposal - revise component configuration

@beepsoft
The component now has 15 configurable properties that are passed in to it as params. I'm thinking of revising the component signature to be simpler:
const configuration = {
    lookup,
    entityId,
    enableBrowseEntities,
    enableTemplateSave,
    .... all of the other configurable properties
}

<describo-crate-builder
        :crate="data.crate"
        :profile="data.profile"
        :configuration="data.configuration"
/>

What do you think?

In the world of Vue/React components, it's not uncommon to have many configuration properties. For example, <el-button> has around 20, and <el-date-picker> has over 30.
So, it's more a matter of aesthetics than performance or best practices; it depends on the kind of API you want users to see.
I'm okay with the configuration property; I have no problem with that.

I'm not sure one way or the other but I wanted to get this written down. Good points about the element component api's. I hadn't thought of those.
This isn't an important development so i'll leave the ticket around for now and maybe revisit in future.

Not going to do this. It works fine so leaving as is.


Provide a "maintenance mode" state

There should be a "maintenance" mode for Portus. The idea is that once enabled, any subsequent pushes would be disallowed. This is a similar idea to something that has already been implemented on distribution's side, but since it's a configurable option there, an administrator would have to effectively restart the registry. In this case, we would disallow pushes without having to restart anything.
This raises other problems like: what happens if an admin sets maintenance mode on but there were some pushes already taking place ? This is something to be discussed in terms of how to best fix this.

An incomplete push is something that can happen anytime. It is in the responsibility of the client to recover from this error, and it is the responsibility of the regsitry admin to clean up any garbage arising from broken pushes. So there is nothing special about a broken push caused by a maintainance mode.
Since the current distribution's garbage collector works only with read-only registry, there is indeed a need for this maintainance mode.
One idea to make the transition to maintainance mode more smooth would be a grace period, where blob uploads are already prohibited, pushing of manifests and tags is still allowed. This would help for pushes nearly done, however I'm uncertain whether this would really change the picture...

But if the push is already on the way, than the connection is already opened and permitted. Only new connections (pushes) will be denied, or do I miss something?

Well, there is a limited time the authentication token is valid. It's 5 mins bei default and is configurable (see #510).
Thus we cannot enforce the maintainance mode immediately. However we know, when the last token expires (since the token are not stored at portus AFAIK we can iterate over all currently valid tokens.
Maybe we could store the time of last token issue so we know when the last token will expire.
As an goodie, we can define a scheduled maintainance time in advance and issue only token that will not exceed this point in time.
@mssola: Do you think about two different maintainance modes: ro mode and complete offline mode?

However we know, when the last token expires (since the token are not stored at portus AFAIK we can iterate over all currently valid tokens.
Maybe we could store the time of last token issue so we know when the last token will expire.

This is a smart idea, I think it could work.

@mssola: Do you think about two different maintainance modes: ro mode and complete offline mode?

Personally I was envisioning just a read only mode

However we could store the time of last token issued so we know when the last token will expire.)
As an goodie, we can define a scheduled maintainance time in advance and issue only token that will not exceed this point in time.

:+1:

Do you think about two different maintainance modes: ro mode and complete offline mode?

I'm thinking in read only mode.

I'm thinking in read only mode.

Fine. BTW reading helps, in this case your initial comment:

once enabled, any subsequent pushes would be disallowed


[Design] Add SQL Server Cache to the Session Sample

@Tratcher

This looks fine, pending my comments on the other PR.

@kichalla while you are mentioned SQL Server cache, any comment regarding this issue #21

commit 28dfa0f0c42a926b9666d29d3bb2110b9ff30738


Conv in Model_K with Dilation>1 gives Unexpected output shape

Describe the bug
On testing Model_k having Conv2d with dilation>1, the output shape is different from the expected output shape. Expected to have  same output shape of Torch Conv2 output and TTNN Conv2 output.
Note: Error is not reproducible. Comparing the printed output shapes of torch and ttnn convs.
To Reproduce
Steps to reproduce the behavior:

Checkout to the branch: harini/failing_conv_dilation
Run the command pytest tests/ttnn/unit_tests/operations/test_conv_dilation.py

Expected behavior
Expected to get same output shapes of torch and ttnn conv2d ops when dilation>1.
Please complete the following environment information:

OS: [e.g. Ubuntu 20.04]
Device: WH n150

@sankarmanoj-tt assigning this to you. I did a quick check on the issue, it looks like there is some issue with the output shape of the tensor -- the shape calculated is all good, but the tesnor seems strange as it shows the unpadded output size larger than padded size (they should both be same in this case):
ttnn.Shape([1, 1, 14884[14400], 48[64]])
ttnn.Shape([1, 1, 13924[12800], 56[64]])

Could you please debug?

The issue is resolved. I'm closing the issue.
Thank you.

@HariniMohan0102 have you ran the model_k end to end and verified that dilation>1 works as expected in the end to end model?

@dvartaniansTT I'll check in end to end model pipeline for dilation>1 and will let you know.


Immich requires version of 0.1.11

https://github.com/immich-app/immich/issues/5759#issuecomment-1859106095
As issue suggestes, 0.1.13 is not working yet, could you build for 0.1.11

Thank you. Issue should be fixed now. I downgraded the version to v0.1.11. Fair warning, I have not tested it so if you can kindly check if it works with the respective tags.

Thank you for quick response,  as for now
[Nest] 8  - 12/20/2023, 12:51:12 AM   ERROR [TypeOrmModule] Unable to connect to the database. Retrying (1)... QueryFailedError: pgvecto.rs: pgvecto.rs: IPC connection is closed unexpected. ADVICE: The error is raisen by background worker errors. Please check the full Postgresql log to get more information.

Thank you for quick response, as for now [Nest] 8 - 12/20/2023, 12:51:12 AM ERROR [TypeOrmModule] Unable to connect to the database. Retrying (3)... QueryFailedError: pgvecto.rs: pgvecto.rs: IPC connection is closed unexpected. ADVICE: The error is raisen by background worker errors. Please check the full Postgresql log to get more information. at PostgresQueryRunner.query (/usr/src/app/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:211:19) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async AddCLIPEmbeddingIndex1700713994428.up (/usr/src/app/dist/infra/migrations/1700713994428-AddCLIPEmbeddingIndex.js:9:9) at async MigrationExecutor.executePendingMigrations (/usr/src/app/node_modules/typeorm/migration/MigrationExecutor.js:225:17) at async DataSource.runMigrations (/usr/src/app/node_modules/typeorm/data-source/DataSource.js:260:35) at async DataSource.initialize (/usr/src/app/node_modules/typeorm/data-source/DataSource.js:148:17).

fixed itself after a while

If the pod lifecycle hasn't terminated. Can you exec into the pod and paste the output of /usr/src/app/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:211:19?

than you for you efforts,  now issue resolved =*


Sass error

c:\WEB\Art>jekyll serve --watch
Configuration file: c:/WEB/Art/_config.yml
Source: c:/WEB/Art
Destination: c:/WEB/Art/_site
Incremental build: disabled. Enable with --incremental
Generating...
Conversion error: Jekyll::Converters::Sass encountered an error while converting 'assets/css/all.sass':
Error: Invalid CSS after "$accent": expected 1 selector or at-rule, was ": #c99065;" on line 15:1 of all.sass >> $accent: #c99065; ^
------------------------------------------------
Jekyll 4.0.0   Please append --trace to the serve command
for any additional information or backtrace.
------------------------------------------------
c:\WEB\Art>

Hi guys can you please help me. Can not understand what is the reason for this error:
"Conversion error: Jekyll::Converters::Sass encountered an error while converting 'assets/css/all.sass':
Error: Invalid CSS after "$accent": expected 1 selector or at-rule, was ": #c99065;" on line 15:1 of all.sass >> $accent: #c99065; ^"


Fix slice clearing lists

What?
I updated the Extractor to stop clearing lists when extracting slices, and to stop overwriting existing fields.
Why?
Before this, when slices were being extracted, it would clear the whole list the slice was a part of. This means that if, for example, only one slice is updated, it would remove all the other slices.
How?
I check for a value in the list that we are slicing that matches the slice criteria, and pass that along instead of always creating a new value and overwriting the existing content.
Visuals
N/A
Testing
I added a field in the general note test case to test this behaviour.
Concerns
N/A

DNM. More unit tests are needed


Fix the Nsynth Jupyter notebook link

Fix the broken link of Nsynth Jupyter notebook.

I signed it!


how to save text on image in laravel 5.5

Hello,
I have issue to get text on images while upload, this is my store function to save image how should i call text method in this?
if ($request->hasFile('image')) {
        $image = $request->file('image');
        $filename = 'food' . '-' . time() . '.' . $image->getClientOriginalExtension();
        $location = public_path('images/');
        $request->file('image')->move($location, $filename);

        $food->image = $filename;
      }

thanks.

anyone?

Well, I guess if you have registered the Image facade in Laravel you need to create a new image instance from the stored image file write the text to it and then save it, after you have stored the image.
$image = \Image::make($location . $filename);

$image->text('The text');

$image->save($location . $filename);