fix(ios,v10): location manager race condition with initial location update

Fixes: #2980
The issue is on initial update. These are the operations, normally
1.) subscribe to location updates from CoreLocation
2.) Mapbox maps viewport subscribes to locationProvider
3.) first update is received
Now when we use our own UserLocation component the order is (1) (3) (2), as we listen to updates a bit earlier,  so the first update might be received before Mapbox maps viewport subscribes to updates. Therefore the first update might be lost.
To fix this I've modified the code so when the delegate is attached to LocationProvider, and we have a location, we send this location to the delegate.
To reproduce on iOS simulator set location to a static location like (Features/Location/Apple). Then run the following component:

import React, { useState, useRef } from 'react';
import Mapbox, {
  MarkerView,
  PointAnnotation,
  UserLocationRenderMode,
  UserTrackingMode,
  ShapeSource,
  Images,
  LineLayer,
  ImageSource,
  UserLocation,
  MapView,
  MapState,
  Camera,
} from '@rnmapbox/maps';
import { StyleSheet } from 'react-native';

const Bug = () => {
  const camera = useRef<Camera>(null);
  const map = useRef<MapView>(null);
  const [followingUser, setFollowingUser] = useState(true);
  const [customStyle, setCustomStyle] = useState(
    `mapbox://styles/mapbox/streets-v12?fresh=true&t=${new Date().getTime()}`,
  ); // THIS STYLE IS THE STANDARD STREET STYLE
  const [zoom, setZoom] = useState(17);

  const onCameraChanged = async () => {
    const currentZoom = await map.current?.getZoom();
    if (currentZoom != zoom) {
      setZoom(currentZoom);
    }
  };

  return (
    <Mapbox.MapView
      ref={map}
      styleURL={customStyle}
      style={styles.mapContainer}
      scaleBarEnabled={false}
      logoEnabled={false}
      compassEnabled={true}
      compassFadeWhenNorth={false}
      onDidFinishLoadingStyle={() => console.log('loaded style')}
      onMapIdle={() => console.log('IDDDDLEE')}
      onDidFinishLoadingMap={() => console.log('finish')}
      attributionEnabled={false}
      onCameraChanged={onCameraChanged}
    >
      <Camera
        ref={camera}
        followUserLocation={followingUser}
        followUserMode={UserTrackingMode.Follow}
        animationMode={'flyTo'}
        followZoomLevel={17}
      />
      {false && <UserLocation renderMode={UserLocationRenderMode.Native} />}
      {true && (
        <UserLocation
          androidRenderMode={'gps'}
          renderMode={UserLocationRenderMode.Normal}
          showsUserHeadingIndicator={true}
          visible={true}
          onUpdate={() => console.log('on update')}
          requestsAlwaysUse={true}
          minDisplacement={3}
          animated={true}
        />
      )}
    </Mapbox.MapView>
  );
};

const styles = StyleSheet.create({
  mapContainer: {
    flex: 1,
    width: '100%',
    height: '100%',
  },
});

export default Bug;

I believe this introduced an intermittent race condition for us on iOS. We are unable to replicate it in a Expo Development Build, but it occurs quite frequently in Production (exhibited as a stuck splash screen - and resolved by force closing and trying again) and began after upgrading to 10.0.12. Last night I downgraded to 10.0.11 and made a TestFlight build and have not seen it since.
I know that it is impossible to understand what may be the issue without seeing code. But I don't have a simple reproducible app with the issue to share (plus again, I was not seeing it in dev).
The Sentry errors are "App Hanging", and the details are fairly unclear. Many of them note things like PointAnnotation.feature.getter (we are using Point Annotations still). I would be happy to provide more details, as possible. But for now, > 10.0.11 appear to be unusable for us in iOS.


Options for default values

Currently the values for height and width are set to 16 pixels.
But most of the times icons are used corresponding with text, so they are used to be set to 1em.
Right now one has to pass height/width to each and every component.
Would't it be possible to set additional option in Vue.use('svgicon', {})?
Regards,
Manuel

@tornography Add in v1.2.4


Docs update for Bootstrap Token Feature

What this PR does / why we need it:
Documentation updates for #484
Updated docs for -

getting started guide
local dev
Update the arch diagram here

Codecov Report

Merging #640 (819a40b) into main (46c48f6) will increase coverage by 0.69%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #640      +/-   ##
==========================================
+ Coverage   68.88%   69.58%   +0.69%
==========================================
  Files          19       20       +1
  Lines        1967     2025      +58
==========================================
+ Hits         1355     1409      +54
- Misses        500      504       +4
  Partials      112      112

Impacted Files
Coverage Δ

...rastructure/v1beta1/bootstrapkubeconfig_webhook.go
93.10% <0.00%> (ø)

For the sequence diagram, Flows 6 and 11 are not there. Also, should we create another task to include puml file as well?

For the sequence diagram, Flows 6 and 11 are not there. Also, should we create another task to include puml file as well?

Thanks for pointing it out. Updated.
Also, yes, puml makes more sense.

lgtm


Force docker to pull FROM images when building

same as in https://github.com/src-d/ci/pull/106
Otherwise, we're building using old versions of our FROM images.
some info: https://www.databasesandlife.com/docker-build-pull-option

Didn't paid much attention because master is also failing because of the same reason with no relevant changes.
https://travis-ci.com/src-d/ci/branches
I wonder if this is caused by ci-tricks, which is also failing in master
https://travis-ci.org/smola/ci-tricks/branches


Change filter to TX packet from APRS-IS

IGate will TX packet from APRS-IS server.
I changed the default filter to "r/" + String(currentWiFi->latitude, 7) + "/" + String(currentWiFi->longitude, 7) + "/" + String(Config.aprs_is.reportingDistance)
In JSON, I set a new property in aprs_is call filter which override the default one by the user one.
TX only occured for packet without TCP, qAR, NOGATE, RFONLY and if the IGate has heard someone from RF during the rememberStationTime

this will be closed as this will be implemented in new release , thanks for the idea Valentin!

Sorry for not providing more updates. Thank you for your future implementation :)


Update NavigationComponent.js

When I try to logout this is the error I get rather than a redirect: "Cannot GET /auth/login"

Thank you Anna! I think it is a problem of client side rendering. Change the redirect link to "/” would fix this problem.


New Member: Rep. Tim Kennedy (D-NY)

Tim Kennedy won a special election to replace former Rep. Brian Higgins. He will be sworn into Congress shortly. Can we please add him?

@prdurkin23 when he gets sworn in we will; that could be anytime within the next two weeks, after the election has been certified.


Kubernetes Cluster Grafana Dashboard should move to Calico

Currently the aforementioned dashboard is showing some metrics specific to Weave-net in one of the main dashboards ("Kubernetes Cluster) which have no data point if it's not deployed.
Given that Calico is now our default standard CNI we should move this graphs to a separate dashboard if these are still relevant and add Calico related relevant metrics if necessary to the main dashboard.

https://trello.com/c/4C1uxp2m

Thanks @phisco

 Replace networking dashboard

Since https://github.com/sighupio/fury-kubernetes-monitoring/pull/29 was merged, can we close this issue?

yes!


Consuming lot of RAM : Continous increase in RAM consumption

React Native version:
System:
OS: Linux 4.15 Ubuntu 18.04 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
Memory: 3.42 GB / 7.65 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 12.5.0 - /usr/bin/node
npm: 6.10.0 - /usr/bin/npm
Watchman: 4.9.0 - /home/linuxbrew/.linuxbrew/bin/watchman
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.60.0 => 0.60.0
npmGlobalPackages:
react-native-cli: 2.0.1

Steps To Reproduce

go to the project root folder
run "react-native start"

Describe what you expected to happen:
Expected
Bundler to get ready and a message
Loading dependency graph...done
Snack, code example, or link to a repository:

file:///home/rishabh/Pictures/reactnativeissue.png

file:///home/rishabh/Pictures/reactnativeissue.png

Duplicate of https://github.com/react-native-community/cli/issues/477


ADaM Date Format Issue

Feature Idea
Seems like all the date variables in ADaM(like ADT) are in ISO format similar to SDTM but generally it should be DATE9. format as per ADaM IG.
eg: ISO format 2023-07-25
Date9 format 25JUL2023
Is there any specific reason for not displaying dates in DATE9. format in ADaM datasets in admiral?
Relevant Input
No response
Relevant Output
No response
Reproducible Example/Pseudo Code
No response

@kanagd03 , thanks for creating this issue.
admiral does not use any specific formatting for date and datetime variables. The lubridate package is used to create these variables.
I could not find any guidance in the ADaM IG regarding formatting of dates except

Numeric date, time, and datetime variables should be formatted, so as to be human-readable with no loss of precision.

The ISO formats used in the ADaM Date Value column are for the purposes of illustration, and are not intended to imply any type of display standard or requirement. The DT variable is numeric and the producer will determine the appropriate display format.

Did I miss it?

Hi @kanagd03 I think @bundfussr  has answered this question sufficiently.  Perhaps we can make a recommendation in our guidance documentation on how to format like a DATE9?
@pharmaverse/admiral any thoughts?

Yes, I was thinking it would be good to mention how to apply formats like date9 in xportr

The tricky question is where we should add this information.
At the end of our vignettes ("Add Labels and Attributes") section we are referring to xportr but we do not mention formats explicitly. Maybe we should replace "associate all metadata information" with something like "associate label, length, and format metadata information".
We could also add a paragraph to the functions which create date and datetime variables (derive_vars_dt() and derive_vars_dtm()).

Hi Team,
Good day!
Thanks for your response for my issue.
Talking about derive_vars_dtm function I just found an issue.
Please correct me if I am wrong.
By default, while calling derive_vars_dtm function, even if we do not have Time still we are getting ATMF variable created with value “H”.
This is because highest_imputation argument has default value as “h”. Can you also check this issue?
@.***
Thanks,
Dhivya.K
From: Stefan Bundfuss @.>
Sent: 31 March 2023 14:01
To: pharmaverse/admiral @.>
Cc: Kanagaraj, Dhivya @.>; Mention @.>
Subject: [EXTERNAL] Re: [pharmaverse/admiral] ADaM Date Format Issue (Issue #1827)
The tricky question is where we should add this information.
At the end of our vignettes ("Add Labels and Attributes") section we are referring to xportr but we do not mention formats explicitly. Maybe we should replace "associate all metadata information" with something like "associate label, length, and format metadata information".
We could also add a paragraph to the functions which create date and datetime variables (derive_vars_dt() and derive_vars_dtm()).
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/pharmaverse/admiral/issues/1827*issuecomment-1491526094__;Iw!!H9nueQsQ!6jR7Uhs8STs9Ft4enwdYZCacVo5fEYKfLWWPnKwupdmEcervWS5KYpgVmmr0oNfp8EDjR85W2zZgld-4BpSyxs5L0XEYfA0$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A3KJY5T5IFEC4ZEF5GK6KHDW62I4VANCNFSM6AAAAAAV6KXTYA__;!!H9nueQsQ!6jR7Uhs8STs9Ft4enwdYZCacVo5fEYKfLWWPnKwupdmEcervWS5KYpgVmmr0oNfp8EDjR85W2zZgld-4BpSyxs5L8uqae7c$.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

@kanagd03 thank you for bringing this up - could you open a second issue for ATMF?  That way we can keep this issue focused on the formatting issue you brought to our attention

Sure Ben! Iwill issue a new issue for it.
Thanks,
Dhivya.K
From: Ben Straub @.>
Sent: 31 March 2023 19:56
To: pharmaverse/admiral @.>
Cc: Kanagaraj, Dhivya @.>; Mention @.>
Subject: [EXTERNAL] Re: [pharmaverse/admiral] ADaM Date Format Issue (Issue #1827)
@kanagd03https://urldefense.com/v3/__https:/github.com/kanagd03__;!!H9nueQsQ!4U-xuXfGMWuc8mjBuqPnhZawrz4M91qY7bHexdXZa6VcnxJxbiCYuNACXa53vFO0ybl5Eeo1-YazdlfuFG1BSos47PYnIg8$ thank you for bringing this up - could you open a second issue for ATMF? That way we can keep this issue focused on the formatting issue you brought to our attention
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/pharmaverse/admiral/issues/1827*issuecomment-1492007591__;Iw!!H9nueQsQ!4U-xuXfGMWuc8mjBuqPnhZawrz4M91qY7bHexdXZa6VcnxJxbiCYuNACXa53vFO0ybl5Eeo1-YazdlfuFG1BSos4wMpEFq8$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A3KJY5USJFT2FCCSPDS6BF3W63SQPANCNFSM6AAAAAAV6KXTYA__;!!H9nueQsQ!4U-xuXfGMWuc8mjBuqPnhZawrz4M91qY7bHexdXZa6VcnxJxbiCYuNACXa53vFO0ybl5Eeo1-YazdlfuFG1BSos40YyOBB4$.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

Can this just be made into a footnote in the documentation/vignette for these functions showing how to use lubridate::function to make this into date9.?

Yes, that’s a good idea!
Thanks,
Dhivya.K
From: Ben Straub @.>
Sent: 10 April 2023 19:49
To: pharmaverse/admiral @.>
Cc: Kanagaraj, Dhivya @.>; Mention @.>
Subject: [EXTERNAL] Re: [pharmaverse/admiral] ADaM Date Format Issue (Issue #1827)
Can this just be made into a footnote in the documentation/vignette for these functions showing how to use lubridate::function to make this into date9.?
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/pharmaverse/admiral/issues/1827*issuecomment-1501875837__;Iw!!H9nueQsQ!8nnP-df8lUsSQrBfaa1qB0e2H9wvF018MpGm812_FwyXf0D8BiIqUsM-j6LZ3VwLpXNzYnvb2t6P7HwXisb8xtCU0xk1T0s$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A3KJY5S7MSZEFRVD4SGCYK3XAQJDZANCNFSM6AAAAAAV6KXTYA__;!!H9nueQsQ!8nnP-df8lUsSQrBfaa1qB0e2H9wvF018MpGm812_FwyXf0D8BiIqUsM-j6LZ3VwLpXNzYnvb2t6P7HwXisb8xtCUM1jjN5o$.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

Hi all.  I updated the original question to include a proposal on how to address this issue identified.  Please give feedback if it is unclear.

@bms63 , what do you mean by "Identify code solution to convert ISO to DATE9 like format"? Do you want to change the way how date and datetime variables are displayed in the console or in the dataset viewer or do you want to add how to call xportr_format()?

@bms63 , what do you mean by "Identify code solution to convert ISO to DATE9 like format"? Do you want to change the way how date and datetime variables are displayed in the console or in the dataset viewer or do you want to add how to call xportr_format()?

I was thinking just in the console/dataset viewer.

Oh

@bms63 , what do you mean by "Identify code solution to convert ISO to DATE9 like format"? Do you want to change the way how date and datetime variables are displayed in the console or in the dataset viewer or do you want to add how to call xportr_format()?

I was thinking just in the console/dataset viewer.

@bms63 , I am not sure if this is a good idea. We tried something similar in the beginning. For datetime variables time is not displayed if it is "00:00:00". We added some code to force displaying "00:00:00". But it caused a lot of issues. At the end we removed it.

Sorry this is for 2023-07-25 to 25JUL2023

Just curious why do we need to display a specific date format in the R console/dataset viewer? Is it sufficient to only display the proper date format in the XPT file based on format.sas attribute?
> attributes(adsl$TRTSDT)
$label
[1] "Date of First Exposure to Treatment"

$class
[1] "Date"

$format.sas
[1] "DATE9"

After some more discussion with core team, we have decided that this issue will not be pursued/addressed.   We feel that this issue would require some significant updates to admiral codebase which would fall outside of our scope with using formats in R versus SAS.  The compromise solution around providing example code for converting to DATE9. would also requite a lot of updates to all our documentation, templates and vignettes that we don't think is worthwhile.
Perhaps enhancements to Bayer's https://bayer-group.github.io/sas2r/index.html could be helpful to address this issue - as other SAS programmers have brought this up.  @kaz462 what do you think?


Add a convenience method to work with a temporary file system

Summary
Problem
Apps require a user to login.
Impact
User's won't need to login anymore to start using an app.
Solution
A temporary file system is used to temporarily store a user's data so that it may or may not be moved to their actual account later on.
Example implementation:
https://webnative-temp-fs.glitch.me

Implemented on next branch.


Unified memcache parser

Parser implementing both text and binary memcache protocols

This change is

Needs adjusting e2e tests for binary memcache and e2e tests for text memcache. Coming tomorrow.

test-me-please

test-me-please

test-me-please

@ianvernon @jrajahalme @aanm please re-review

test-me-please

test-me-please

Unit tests are failing in ginkgo vm, but working fine on my dev machine, will investigate

test-me-please

@jrajahalme @ianvernon please re-review

Could not answer to all comments, GH doesn't show reply box.
@jrajahalme "Still find the double negative hard on the eyes..." double negative is because noreply is actually a string that exists in command if you want it to not get reply from server.
E.g. if you have set command set key 0 500 5\r\n which you don't want to get a reply, you form it as follows: set key 0 500 5 noreply\r\n. noreply acts as an additional flag for commands, that's why it's called like that. I can rename it to hasNoreply, maybe it will be easier on the eyes.
"Do we really need to queue an expected reply if the command does not generate a reply (noreply == true) or have I misunderstood the meaning of noreply?"
Good catch, fixed it.

test-me-please

@jrajahalme @ianvernon  please re-review

test-me-please

@nebril "if you have set command set key 0 500 5\r\n which you don't want to get a reply, you form it as follows: set key 0 500 5 noreply\r\n. noreply acts as an additional flag for commands, that's why it's called like that. I can rename it to hasNoreply, maybe it will be easier on the eyes."
This is a good clarification. The current code, however, does not seem to check that the last token is "noreply", and will behave the same regardless the actual content of the last token. While it works with well-formed commands, IMO it is too brittle as is.

test-me-please

@ianvernon thanks for review, please take a look if it's ok now


Convert to NPM package

[x] Add build script to compile to ES5 modules and UMD for web
[x] Add publish script to build and publish NPM module
[x] Add script to build demo or run demo in browser

@alyssaxuu note that you will need to choose a package name because "flowy" is already taken
Credit goes to #12 for the UMD build process.

@alyssaxuu let me know if you've got any feedback on this or if it can be merged. Next, I plan to explore integrating with React

@joelvh you did some good work here. 👏

@alyssaxuu wanted to see if you have any feedback or thoughts on this PR and #38 and #39

I appreciate the effort - although I personally would prefer to keep the library simple here in GitHub in terms of files & code. I also did some bug-fixing/improvements on my code so that would be lacking in this pull request I believe.
Maybe if there was a way to keep a "minimal"/compressed version of the code together with yours as to be able to convert to a NPM package would work. But yeah, the simplicity and conciseness of this library is important to me.

@alyssaxuu updates can be merged in, and .gitignore can be updated to include the generated output in the git repository if you like.

@alyssaxuu updates can be merged in, and .gitignore can be updated to include the generated output in the git repository if you like.

Hmm okay, so then there would be the original "vanilla" version of the library with the original demo (separate folder or whatever) & this version which works with NPM?

Yeah, this is the vanilla code in this branch: https://github.com/joelvh/flowy/tree/master/src/demo
The NPM package makes it possible to install the code along with other packages and reference it as described here: https://github.com/joelvh/flowy#installation
The NPM package also allows you to have some simple development tools available when working on the source code. You can see that there is a command that will launch the demo in your browser, and it will also live-reload that browser code if you edit the source files (e.g. when working on features or bug fixes): https://github.com/joelvh/flowy#demo
As that last link indicates, you can just build the compiled/compressed files and not run it in the browser -- the demo folder the README links to is a 404 because we are excluding those build files (or build artifacts) from git, but can easily include them again if you wish.

@alyssaxuu P.S. I'm happy to help get the latest updates merged into here.

Yeah, this is the vanilla code in this branch: https://github.com/joelvh/flowy/tree/master/src/demo
The NPM package makes it possible to install the code along with other packages and reference it as described here: https://github.com/joelvh/flowy#installation
The NPM package also allows you to have some simple development tools available when working on the source code. You can see that there is a command that will launch the demo in your browser, and it will also live-reload that browser code if you edit the source files (e.g. when working on features or bug fixes): https://github.com/joelvh/flowy#demo
As that last link indicates, you can just build the compiled/compressed files and not run it in the browser -- the demo folder the README links to is a 404 because we are excluding those build files (or build artifacts) from git, but can easily include them again if you wish.

Right, so you're suggesting different branches for each version in that case (also for the React one)?

@alyssaxuu no, once these changes are merged in, it's all on the main branch. I was just saying that those links I put in my comments above are to my branch with the changes in this PR so you can see what it looks like before merging. The "Files changed" tab in this PR doesn't really show where the files may have moved to, so linking to my branch just helps clarify things (hopefully).

@alyssaxuu no, once these changes are merged in, it's all on the main branch. I was just saying that those links I put in my comments above are to my branch with the changes in this PR so you can see what it looks like before merging. The "Files changed" tab in this PR doesn't really show where the files may have moved to, so linking to my branch just helps clarify things (hopefully).

Ooooh okay, got it yeah. I see, seems fair enough to me. So would just have to add the latest changes & bug fixes to this and that would be it I suppose. Although the NPM part would still have to be set up I assume (and also picking the name since it can't be just "flowy").

@alyssaxuu yeah, it's just bringing those updates in. I checked, and "flowy.js" is available, if you want to use that. You could rename the repo as "flowy.js" too, but you don't have to.
I'll take a look at getting your latest changes into this PR.

@alyssaxuu I've merged in your changes and also updated .gitignore to commit both the /demo and the /dist folders into the repo.
The /demo folder has the result of building the demo source code into a viewable demo using the command npm run build:demo.
The /dist folder has the result of building the .js and .css files into usable files in various js module formats for use on the CDN or importing into packages when downloading this project without NPM.
You can see both folders in my branch from this PR: https://github.com/joelvh/flowy

@alyssaxuu I've merged in your changes and also updated .gitignore to commit both the /demo and the /dist folders into the repo.
The /demo folder has the result of building the demo source code into a viewable demo using the command npm run build:demo.
The /dist folder has the result of building the .js and .css files into usable files in various js module formats for use on the CDN or importing into packages when downloading this project without NPM.
You can see both folders in my branch from this PR: https://github.com/joelvh/flowy

Got it, perfect! Re: name, flowy.js is fair enough. Is it ready to be merged already?

@alyssaxuu looks like the conflicts are resolved, so you can merge this if you're happy with it.

@alyssaxuu i would say, run it locally so you know it works as expected :-)

@alyssaxuu what you could do is merge it, then download the latest and run npm i to install dependencies and then npm run demo and it will setup the demo for you and will display the URL to open to see the demo live in your browser (which would be http://localhost:1234). If you edit code while that is running, it should automatically reload the latest in your browser too.

@alyssaxuu i see there are some updates on master. I can get this branch updated when that is done. Will you be able to merge this?

@alyssaxuu I've merged in the updates on master. I noticed the output function may be in there twice, duplicated?
Please merge this branch if it works for you.
Thanks!

@alyssaxuu I've merged in your latest updates. Will you be merging this PR?

hi @alyssaxuu will you be merging this branch?

hi @alyssaxuu will you be merging this branch?

I'm still adding some new things and currently it's easier for me to do so as it is. I've been thinking about adding a method to remove individual blocks and a few other enhancements to make the library more usable, as there's been high request for it, today I've also added a new method to allow the user to decide if rearranged blocks dropped in the canvas are deleted or re-attached to their previous parent. So I think before merging & turning it into a npm package I might want to make sure that there's some more new functionality.
On a side note, in the branch you shared a few comments above, I notice .editorconfig & .prettierrc - would those also be in the merge?

Makes sense that you have a lot of improvements you'd like to make. I think you can merge this and not worry about publishing as an NPM package quite yet. Merging this branch will make the project be setup structurally for NPM, and your workflow won't really need to change.
Just so you know, the changes in here are simply moving and renaming the files you've continued to make updates and improvements to in your branch. To illustrate, here's how the files were moved, but still exactly the same as what you have.
engine/flowy.js    ---> src/engine/index.js
engine/flowy.css ---> src/engine/index.css

Then to rebuild the minified files you run: npm run build:web and the files go into dist/*.*
Then to rebuild the demo files you run: npm run build:demo and the files go into demo/*.*
To answer your questions about .editorconfig and .prettierrc, those are in here as a way to make sure anyone making updates in PRs use the same formatting standards for javascript. That might be the only other change you see in the .js files is that if you use VS Code or Atom, the Prettier plugin should autoformat your code when you save your changes.
If you don't want that, it can be removed. But it helps make sure everyone's Javascript coding style is the same when making changes.
In the meantime, I'll merge your changes back in, but again, I just moved the files to a subfolder, so you can keep working there after the merge and don't need to do anything about publishing an NPM package yet if you don't want to.

@alyssaxuu one request I have - could you please add descriptions in your commits that explain what you changed or why? It's hard to make sure I'm pulling all the latest changes into this branch when they all have the same or similar commit messages. Thank you!

Makes sense that you have a lot of improvements you'd like to make. I think you can merge this and not worry about publishing as an NPM package quite yet. Merging this branch will make the project be setup structurally for NPM, and your workflow won't really need to change.
Just so you know, the changes in here are simply moving and renaming the files you've continued to make updates and improvements to in your branch. To illustrate, here's how the files were moved, but still exactly the same as what you have.
engine/flowy.js    ---> src/engine/index.js
engine/flowy.css ---> src/engine/index.css

Then to rebuild the minified files you run: npm run build:web and the files go into dist/*.*
Then to rebuild the demo files you run: npm run build:demo and the files go into demo/*.*
To answer your questions about .editorconfig and .prettierrc, those are in here as a way to make sure anyone making updates in PRs use the same formatting standards for javascript. That might be the only other change you see in the .js files is that if you use VS Code or Atom, the Prettier plugin should autoformat your code when you save your changes.
If you don't want that, it can be removed. But it helps make sure everyone's Javascript coding style is the same when making changes.
In the meantime, I'll merge your changes back in, but again, I just moved the files to a subfolder, so you can keep working there after the merge and don't need to do anything about publishing an NPM package yet if you don't want to.

Ahh okay, I swear I should have looked at it more closely haha, now it all makes sense. That works I guess then. As per the files, I'm not really sure if they would have to be kept in. I have a few enhancements in mind for the library, but I don't really plan on turning it into anything much bigger, so I don't really see a need personally to have that for PRs.
I do have to ask about the minified versions of the file. Currently I have jsDelivr as an option that pulls from flowy.min.js and flowy.min.css, for people who want to implement the library that way. In your repo I'm not sure what those files would be? Is it flowy.js and flowy.css in the dist folder?

@alyssaxuu one request I have - could you please add descriptions in your commits that explain what you changed or why? It's hard to make sure I'm pulling all the latest changes into this branch when they all have the same or similar commit messages. Thank you!

Yes, that's a good point, I'll be doing that.

I've been thinking of using this library and having it as an npm package would really help me! @alyssaxuu this library is amazing! @joelvh thanks a lot for the effort.. this is great work! Really looking forward to the PR being merged! 💯

@alyssaxuu I just merged in your latest changes in this branch. Regarding the files to put on your CDN (jsDelivr), yes, its the files in the dist folder here: https://github.com/joelvh/flowy/tree/master/dist
There are multiple formats that would allow users to load it as regular js files in a webpage, or as a commonjs package, and so on. I'd recommend uploading all of them to jsDelivr so people have options for which they need.
As for the files like .prettierrc, that is what auto-formats the js code so that if you use Visual Studio Code or other editors that have the Prettier plugin, you'll get consistently formatted contributions.
Can you merge this today?

@alyssaxuu I just merged in your latest changes in this branch. Regarding the files to put on your CDN (jsDelivr), yes, its the files in the dist folder here: https://github.com/joelvh/flowy/tree/master/dist
There are multiple formats that would allow users to load it as regular js files in a webpage, or as a commonjs package, and so on. I'd recommend uploading all of them to jsDelivr so people have options for which they need.
As for the files like .prettierrc, that is what auto-formats the js code so that if you use Visual Studio Code or other editors that have the Prettier plugin, you'll get consistently formatted contributions.
Can you merge this today?

Perfect! So flowy.js.js would be flowy.min.js and flowy.css would be flowy.min.css as I understand it?
And sure, I can merge it today :) I just want to make sure it's all good haha.

@alyssaxuu yup! And, great!

All right, it's done. So I guess all that's left now is create a NPM package. I wonder if it's best for me to try adding some new methods before doing so?  Just let me know your npmjs.org username.
By the way, would you be open to hopping on a call or screenshare? I can walk you though a couple things so you feel comfortable with the new setup (which isn't a huge change, but might give you more ideas too).

@alyssaxuu woohoo! 🥳
What I'll do is I'll create the "flowy.js" NPM package and add you as a collaborator. Just let me know your npmjs.org username.
By the way, would you be open to hopping on a call or screenshare? I can walk you though a couple things so you feel comfortable with the new setup (which isn't a huge change, but might give you more ideas too).

My username is "alyssaxuu". Also, I feel like the ReadMe is confusing, now that I've taken another look. There should be two ways to implement Flowy, 1) Through NPM, and 2) Using JsDelivr / self host. I see in the latter you put "Run npm run build:web", I assume this was meant for #1?
And appreciate it, unfortunately I am quite busy ^^ I'll just look into it to get more familiarized.

Just saw the package - I'm confused, shouldn't it be called flowy.js instead of<EMAIL_ADDRESS>

@alyssaxuu I've created issue #54 to discuss things to clean up and fix.
Regarding the name, unfortunately NPM didn't allow flowy.js as the package name because it was too similar to the existing flowy package. NPM is also urging developers to use an org "scope" for their packages, so I created the "flowy.js" org, and put the package "flowy" under it.
The benefit of that scope/namespacing is if you have multiple packages, you can put them all in there. Flowy could theoretically have @flowy/engine as the name instead, which might actually be clearer based on the naming you used in the code. In the future maybe there will be other packages you break Flowy into if you decide to adopt ES6. Maybe in the future there is @flowy.js/react or @flowy.js/vue for integrations into other frameworks. All possibilities, but not required.
Could you add more "tasks" by editing the description in #54 and make any more comments there regarding your thoughts from this thread? I figured that would be an easier place to track since this PR is now closed.

I can't see the changes in master, so I think @alyssaxuu just reverted them and deleted the history? or maybe Github is acting weird 🤷♂

@joelvh if you get a fork going I'm happy to work with you on that. I want to use this idea in a react project I have.

I can't see the changes in master, so I think @alyssaxuu just reverted them and deleted the history? or maybe Github is acting weird 🤷♂

Yeah I reverted the changes, I am working on something (optimization / simplicity side of things) so I'm keeping as it was originally for now.

@alyssaxuu was there something wrong with what was merged?

@dardanos I have a fork that I've made the pull requests from. I'm not sure what was wrong with this pull request. I also created Issue #54 to work on any additional improvements, but looks like that was deleted.
@alyssaxuu let me know what the issue was. maybe based on what you described about not wanting contributions means I should just work on my fork?

@alyssaxuu let me know what the issue was. maybe based on what you described about not wanting contributions means I should just work on my fork?

There was no issue, I've just been trying to optimize / simplify the library as well as deal with some methods, basically before taking the step to turn this into a NPM package I would like to make sure the library is at its best (adding several features / enhancements I've been getting both here & through email), so for the time being I will keep it as is.
Like I mentioned I don't really have plans to expand the library so I would like to ensure as much as possible that I don't have to keep on fixing bugs and adding new enhancements consistently.

@alyssaxuu I'm happy to help contribute and maintain the library for/with you, so you don't have to feel like it's all on you to make improvements. It seems like there are several people investing in using Flowy in their projects, so they are incentivized to make things better and help out.
If you don't want people to contribute or maintain this for you, I'm happy to make improvements on my fork. As you can see from the other pull requests, i think there are improvements that can also be made to use ES6 for more modern coding styles, and React integration examples.

@alyssaxuu I'm happy to help contribute and maintain the library for/with you, so you don't have to feel like it's all on you to make improvements. It seems like there are several people investing in using Flowy in their projects, so they are incentivized to make things better and help out.
If you don't want people to contribute or maintain this for you, I'm happy to make improvements on my fork. As you can see from the other pull requests, i think there are improvements that can also be made to use ES6 for more modern coding styles, and React integration examples.

I don't mind making improvements myself, it's not a matter of it being tedious - I just think rolling them out inconsistently makes it hard for people who want to use this library to stay up to date, so I just want to make sure it's polished and with all the enhancements and methods before I make any new releases.
I appreciate contributions to the library (as I've managed to fix some bugs for example early on thanks to those), but I'm happy keeping it small, simple, and minimal (as it is described). I'm just going to be setting a clear roadmap for the improvements, as well as I talk with people who use the library to understand the needs better to make a proper release.

@joelvh I think we can wrap the work @alyssaxuu did in a Lerna project as the "engine", provide storybooks, and a react wrapper. It will be tedious to maintain the engine initially, but maybe a lot of people are interested in contributing to a react library and it ends up deviating from what it is today.
@alyssaxuu, will you be ok if we work on @joelvh's fork so that we can make progress?
If the answer is yes, we just need to make sure we don't use the name flowy in the package, and we give credits to this project.

@alyssaxuu, will you be ok if we work on @joelvh's fork so that we can make progress?
If the answer is yes, we just need to make sure we don't use the name flowy in the package, and we give credits to this project.

Feel free to work on this fork & make your own version if you want - but like I said I am eventually going to turn it into a NPM package & have support for React and other frameworks, I'm just working on several enhancements: #53, #51, #50 (maybe), ~#29 (I want to handle logic / conditional blocks in a better way, so I want to think of a good approach), and aside from those I am also working on a function to delete blocks by ID, with the option to include all the children when being deleted, or just an individual block (if it has children, the children would be rearranged with the parent of the deleted block). I am also exploring the possibility to handle multiple trees at once as per request.
I just would like to make all those changes and enhancements + optimize & allow for creating a NPM package at the same time in a single release. Otherwise it would be confusing to roll things out progressively with the library changing constantly.

For what it's worth @alyssaxuu the nature of any project like this is that there will be multiple versions of it. If you think about everyone who already has started using Flowy, every time you make an update, they need to decide if they will upgrade to the latest or not. Of course, the goal is for everyone to upgrade to the latest. One thing that is currently hard to do is know what "version" is the latest. Updating the "version" property in package.json, adding a git tag with the version, and adding a GitHub "release" with the version and a list of updates, is what makes using a package like Flowy much more manageable.
Developers using Flowy are likely using many other frameworks as well, and need to keep up to date. Having Flowy use package.json and NPM only makes this easier for developers. Setting the project up like that, developers will know immediately when updating their project dependencies/packages when Flowy is outdated -- rather than having to check this GitHub page manually on a regular basis. Detailed commit messages also help developers understand what changed and why.
All this to say, it's great that you want to add more features before you release an NPM package, and that you're open to React/framework integrations. However, at the moment, for me and presumably other developers like @dardanos, working with Flowy is harder because it is extra work to know what the status of the framework is without some simple standards like versioning. Additionally, allowing others to submit PRs and take work off of your hands makes things more manageable for you. Flowy can remain simple and focused -- things that go beyond what you intend for the engine can be published in separate packages to build on the engine. I would very much like to create and maintain those, ideally in the flowy.js NPM org.
Lastly, as I said, releasing to NPM now (rather than waiting) is not publishing an "incomplete" package because developers are already using Flowy and might want to have a better experience keeping track of "how far behind" their copy of Flowy is from your latest updates. If you saw the version I had in package.json, it was version 0.1.0 -- that was intentionally not 1.0.0 because you are currently working toward what sounds like your "complete" 1.0 release. A version starting with 0.x is easily identifiable as "a work in progress" and lets developers know that by the time version 1.0 is ready things may change. But at least they have something to go on to know what the status of Flowy is. (Check out how most other open source projects use versioning here.)
I am personally stuck right now trying to build on Flowy, make incremental improvements and not diverge from Flowy because my changes (which keep everyone in mind, not just me) are not being merged in, I don't know if anything I submit in the future will be considered to be merged in, and working off of a fork for a long period of time begs the question whether I (and others) will ever be able to pick up speed in making Flowy better and better with/for you. So, I am purely advocating for allowing us to help you do things faster, while keeping all other developers using Flowy in mind. I'd like to be able to contribute (and help maintain) this project as I have helped with many other open source projects.
I've said my piece and hope that I can use Flowy as you're developing it, but in the meantime will maintain my fork and pull in the latest as you make updates.

For what it's worth @alyssaxuu the nature of any project like this is that there will be multiple versions of it. If you think about everyone who already has started using Flowy, every time you make an update, they need to decide if they will upgrade to the latest or not. Of course, the goal is for everyone to upgrade to the latest. One thing that is currently hard to do is know what "version" is the latest. Updating the "version" property in package.json, adding a git tag with the version, and adding a GitHub "release" with the version and a list of updates, is what makes using a package like Flowy much more manageable.
Developers using Flowy are likely using many other frameworks as well, and need to keep up to date. Having Flowy use package.json and NPM only makes this easier for developers. Setting the project up like that, developers will know immediately when updating their project dependencies/packages when Flowy is outdated -- rather than having to check this GitHub page manually on a regular basis. Detailed commit messages also help developers understand what changed and why.
All this to say, it's great that you want to add more features before you release an NPM package, and that you're open to React/framework integrations. However, at the moment, for me and presumably other developers like @dardanos, working with Flowy is harder because it is extra work to know what the status of the framework is without some simple standards like versioning. Additionally, allowing others to submit PRs and take work off of your hands makes things more manageable for you. Flowy can remain simple and focused -- things that go beyond what you intend for the engine can be published in separate packages to build on the engine. I would very much like to create and maintain those, ideally in the flowy.js NPM org.
Lastly, as I said, releasing to NPM now (rather than waiting) is not publishing an "incomplete" package because developers are already using Flowy and might want to have a better experience keeping track of "how far behind" their copy of Flowy is from your latest updates. If you saw the version I had in package.json, it was version 0.1.0 -- that was intentionally not 1.0.0 because you are currently working toward what sounds like your "complete" 1.0 release. A version starting with 0.x is easily identifiable as "a work in progress" and lets developers know that by the time version 1.0 is ready things may change. But at least they have something to go on to know what the status of Flowy is. (Check out how most other open source projects use versioning here.)
I am personally stuck right now trying to build on Flowy, make incremental improvements and not diverge from Flowy because my changes (which keep everyone in mind, not just me) are not being merged in, I don't know if anything I submit in the future will be considered to be merged in, and working off of a fork for a long period of time begs the question whether I (and others) will ever be able to pick up speed in making Flowy better and better with/for you. So, I am purely advocating for allowing us to help you do things faster, while keeping all other developers using Flowy in mind. I'd like to be able to contribute (and help maintain) this project as I have helped with many other open source projects.
I've said my piece and hope that I can use Flowy as you're developing it, but in the meantime will maintain my fork and pull in the latest as you make updates.

Yes, I understand that, and it is due to the versioning problem that I want to stop and add all the new changes that will "drastically" change the library (at least in terms of structure) at once. I know if I release a NPM package I will be able to update it with the new changes, I just simply want to take that step after making the improvements, that is all. It will just be easier for me to announce all the changes in bulk, as a "Flowy v2", and try to ensure that people will be satisfied with the library in that state. That's just how I personally see it.
Like I said I will stop pushing new commits (with the exception of some bugs I have recently fixed which I deemed critical due to the hectic updates I made the past weeks adding a new method & other little enhancements, which in retrospect could have waited) until I have this ready, so you shouldn't worry about "staying up to date".
That's basically what's currently happening, I'm just sort of "overhauling" the library to make it more useful for everyone.

OK, sounds good @alyssaxuu. On the subject of "overhauling", are you open to using more modern ES6 syntax? My other PR (a different branch from the NPM branch) was intended to introduce JS syntax that is used more and more, which uses features such as "destructuring" as you can see here: https://github.com/joelvh/flowy/blob/feature/react/src/engine/index.js#L15
It also uses import statements to split the code into separate files that get combined when building the "minified" code you're putting on jsDelivr.
Curious if you're open to that as well?

@dardanos for the time being I've published the NPM package to https://www.npmjs.com/package/flowy-engine - that may change to use the official NPM package when ready.

I like the idea of npm. And also if versions are named correctly (with major, minor, and patch) then there won't be an issue with breaking changes. For example the current version can be 1.x.x and then since we are changing the API we will release it as 2.x.x.
The latest version will always be on master branch while old versions and experiments can be branched out to have their own individual branches.


Beta hangs on websocket connection

    Having some trouble with the beta and not really sure how to debug. It was working for a bit and then I restarted my Rails server and now loading the `/lookbook` root page hangs in Chrome. Looks like it is waiting for actioncable to connect but never does?

Eventually the tab freezes and has to be killed because it's taking 100% CPU.
We don't use actioncable (though it is installed via rails) so there might be something on my end that is not setup correctly?
Originally posted by @swanson in https://github.com/ViewComponent/lookbook/discussions/310#discussioncomment-4987582

Rails <IP_ADDRESS>
Ruby 3.1.2
ViewComponent 2.82.0

Thanks @swanson - I've not been able to recreate this yet but I'll try again when I have a chance and let you know when I've figured it out.

Hi again @swanson. I'm afraid I've not had much more luck on this yet - I can't for the life of me recreate the issue.
As a partial workaround that may help with debugging, I've added a new live_updates config option that allows manual disabling of live UI updates in development even if the actioncable is present.
If you have a second at all it would be great if you could try disabling websockets by setting that option to false and seeing if Lookbook then functions normally for you (apart from having to refresh the pages to see any changes).
Docs are here: https://v2.lookbook.build/guide/config_reference#live_updates but the change hasn't yet made it's way into a new beta release yet, so you'd have to fetch the Lookbook gem from the v2 branch for now:
gem "lookbook", git: "git://github.com/ViewComponent/lookbook.git", branch: "v2"

I should get another beta release out within a few days that will include this in it however so it may be easier to wait for that.
Thanks!

Hi again @swanson. I'm afraid I've not had much more luck on this yet - I can't for the life of me recreate the issue.
As a partial workaround that may help with debugging, I've added a new live_updates config option that allows manual disabling of live UI updates in development even if the actioncable is present.
If you have a second at all it would be great if you could try disabling websockets by setting that option to false and seeing if Lookbook then functions normally for you (apart from having to refresh the pages to see any changes).
Docs are here: https://v2.lookbook.build/guide/config_reference#live_updates but the change hasn't yet made it's way into a new beta release yet, so you'd have to fetch the Lookbook gem from the v2 branch for now:
gem "lookbook", git: "git://github.com/ViewComponent/lookbook.git", branch: "v2"

I should get another beta release out within a few days that will include this in it however so it may be easier to wait for that.
Thanks!

That changes does seem to avoid the actioncable hang up (and would work for me, I dont particularly need live reload as long as changes to previews/components get picked up when I reload the page).
Now I did notice that lookbook was hanging / slow and got a bucket load of JS console errors (Maximum call stack size exceeded) and there is a noticeable lag when filtering in the left-hand sidebar

@swanson hmm yeah there is something odd happening here. A couple of things to check -  can you make sure the browser cache is cleared for this domain so that you are definitely getting the latest JS (you have probably done this already), and can you also clear local storage? There is a link in the debug menu at the top right if needed.
It may be that some settings have been saved in localstorage that are no conflicting with the updated UI, so clearing it out may help. But I'm just clutching at straws here really until I'm able to see replicate so similar behaviour at my end.
Sorry you can't kick the tyres on the beta yet because of this - I'd love to hear any other feedback you might have on it when this issue gets resolved :-)

@swanson sorry to ping you on this as I'm sure you are busy enough but I was wondering if you'd had a chance to see if clearing local storage had made any difference at all?
I've not been able to replicate this at all and haven't heard any other reports of anything similar so it's I'm not really sure with how else to proceed on trying to figure out what is going on here I'm afraid 😕

@allmarkedup Hey sorry, I have not had time to debug further. Please feel free to close if no one else is experiencing the issues!

@swanson no worries at all! Appreciate you getting back to me. I'll close this down for now then as it does (currently) seem to be an isolated issue but if you get a chance to come back to it and are still having troubles just reopen or let me know and I'l try to pick it up again. Many thanks :-)


General clean-up and opinionated coding style

As I recently commented in #434, here the first commits of the general clean up on django-helpdesk code base.
Along the path I have fixed some dead code and some ancient Django stuff. So it is not a pure coding style PR, as there is something more. However, no real changes should have been made (unless I messed up).
There is still work to do, and pylint complains about a lot of stuff. But as a starting point...

Current coverage is 45.51% (diff: 46.34%)

Merging #435 into master will decrease coverage by 0.06%

@@             master       #435   diff @@
==========================================
  Files            31         31
  Lines          2975       2909    -66
  Methods           0          0
  Messages          0          0
  Branches        475        482     +7
==========================================
- Hits           1356       1324    -32
+ Misses         1514       1483    -31
+ Partials        105        102     -3

Powered by Codecov. Last update 5e34033...94d51cb

Thanks for giving us some style @alexbarcelo !! 🎩


feature request: wall clicking

saw a server in ss13, where if you click on wall, you heard a sound and message in chat "you click that wall. its motionless" or something like that
dont remember if it was local message or people around could see that youre clicking walls
makes sense when youre checking for fake wall

Tapping a wall and getting a tap back from the other side could have some niche uses, especially when opaque doors are involved

It would be cool, but it seems like it could get annoying if you click on a wall accidentally.

the pr is closed soo


How to access the latest version of the tool

Hello,
How can i use the latest release of the tool instead of the previous one? Do i need to delete the previous one off my desktop?
@Alexander-Hjelm

Latest release here: https://github.com/solidify/jira-azuredevops-migrator/releases

I downloaded the latest version and ran the export but it still uses the previous release of the tool. @Alexander-Hjelm


Using Django in Visual Studio Code

saw the new tutorial released for Flask and its awesome ... can we get the same for Django ?
https://code.visualstudio.com/docs/python/tutorial-flask

This issue was moved to Microsoft/vscode-docs#1744


Pipenv

switch to pipenv for managing requirements

Feel free to squash this one

before we make a new tag + pypi release, could you please check installing it on AiiDA lab to see whether everything looks fine?


Upgrade kong version and openresty problem.

Add the stream module to kong and recompile openresty.
phenomenon:
1, pl_utils.executeex (cmd) in / usr / local / share / lua / 5.1 / kong / cmd / utils / prefix_handler.lua always returns an error.
local ok, _, _, stderr = pl_utils.executeex (cmd)
Where the stderr some do not understand, why should match from the error.
2, / usr / local / share / lua / 5.1 / kong / cmd / reload.lua will also be a problem.
What does kong depend on? Can I provide a document that can be compiled or passed?
demand:
Upgrade openresty to the latest version. You can add modules to openresty. At this time kong can be normal reload.
Can I provide a document? Or help solve the next. Too painful. Thank you
./configure --prefix=/usr/local/openresty
--with-stream
--with-stream_ssl_module
--with-cc-opt=-O2
--with-pcre=pcre-8.40
--with-openssl=openssl-1.0.2l
--with-pcre-jit
--with-ipv6
--with-http_realip_module
--with-http_ssl_module
--with-http_stub_status_module
--with-http_v2_module
Error:
/usr/local/share/lua/5.1/kong/cmd/reload.lua:24:
stack traceback:
[C]: in function 'assert'
/usr/local/share/lua/5.1/kong/cmd/reload.lua:24: in function 'cmd_exec'
/usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:88>
[C]: in function 'xpcall'
/usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:45>
/usr/local/bin/kong:7: in function 'file_gen'
init_worker_by_lua:47: in function <init_worker_by_lua:45>
[C]: in function 'xpcall'
init_worker_by_lua:54: in function <init_worker_by_lua:52>
The final analysis of the wrong location：
local ok, _, _, stderr = pl_utils.executeex (cmd)
1、/usr/local/openresty/bin/resty -v
2、chmod +x ......serf.sh

Hello, that error seems to indicate that the Penlight Luarock is not installed/available in your system. The documentation for installing Kong can be found here: https://konghq.com/install/ . Please follow the instructions that match your system (you seem to be installing the "Source" version of Kong, but I can't say for sure).
I am closing this is issue now, if you have more questions please use the gitter chat.


(GoogleGenerativeAl.RPCError error 1.)

Description of the bug:
I am using SDK version 0.4.4, and everything works well. However, a few users in different locations around the world, such as Norway, encounter an error when they run my app, rendering it unusable.
The operation could not be completed. (The GoogleGenerativeAl.RPCError error 1.)
What is this error? How can I fix it?

Actual vs expected behavior:
No response
Any other information you'd like to share?
No response

Hi @iTarek, at the moment, the Gemini API is only available in these regions. Unfortunately, I don't have any information on plans or timelines to expand the available locations (I sympathize since it's not available in Canada either).
In the meantime, we're working on improving the error message in unsupported regions.

As an example of how a developer could currently detect / handle this error (without #85):
do {
  let content = try await model.generateContent("Why is the sky blue?")
  if let text = content.text {
    print("Generated Content:\n\(text)")
  }
} catch let GenerateContentError.internalError(underlying: error) {
  if String(describing: error).contains("User location is not supported for the API use.") {
    // Do something app-specific if the API isn't available in the user's region.
    print("Unsupported region, see https://ai.google.dev/available_regions#available_regions")
  } else {
      // This is a different internal error
      print("Generate Content Internal Error: \(error)")
  }
} catch {
  // This is a GenerateContentError that isn't a GenerateContentError.internalError
  print("Generate Content Error: \(error)")
}

Pain points noted:

The internal error doesn't conform to LocalizedError so error.localizedDescription doesn't contain the "User location is not supported for the API use." message.

 in their app

The approach in #85 hardcodes this in the SDK (also not ideal) but it would be more convenient for devs to upgrade their version of the SDK vs. having to keep an eye on if/when our error messages change

Note: Removing status: awaiting user response since we're investigating this.

Hi @iTarek, version https://github.com/google/generative-ai-swift/releases/tag/0.4.7 of the SDK is now available, which adds an unsupportedUserLocation case to GenerateContentError. Our Chat Sample and unit-tests show examples of how you can catch this failure scenario in your code.
Will close this issue but feel free to re-open if you have additional feedback / concerns.


docs: added CameraStatus command to readme

Signed-off-by: Brian Osburn<EMAIL_ADDRESS>

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[X] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[X] I am not introducing a new dependency (add notes below if you are)
[ ] I have added unit tests for the new feature or bug fix (if not, why?)
[ ] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
[ ] I have opened a PR for the related docs change (if not, why?)

Testing Instructions

New Dependency Instructions (If applicable)

Codecov Report

Merging #74 (1b77855) into main (e0ef951) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main     #74   +/-   ##
=====================================
  Coverage   2.94%   2.94%
=====================================
  Files          6       6
  Lines        714     714
=====================================
  Hits          21      21
  Misses       693     693

Continue to review full report at Codecov.

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


[network] clean up channel counter spam

Previously, we were using a unique counter for each peer for each channel that gets spun up for the Peer actor. This lead to a ton of counters, even for very limited use cases like the validator network. For example, there are ~10 channel counters per Peer. In premainnet, each validator would be producing ~ 10 * 30 = 300 unique counters for these metrics. When collected to the shared metrics, you get ~ 10 * 30 * 30 = 9000 counters.

This diff removes the peer_gauge in favor of a single counter for each channel. Unfortunately this loses information (we can't isolate congestion to a single channel x peer); however, it's probably fine...

Clean up the channel docs and remove the shared global TEST_COUNTER so the unit tests aren't as clunky.

Remove some unused functionality that would allow users to configure a "timeout" so messages older than "timeout" would just get silently dropped. No one was using this, so I took the liberty of removing this.

Network no longer uses the deprecated OpMetrics : )

/land


Benchmark with Persy

I'm interested in seeing benchmarks with other KV stores like Persy.

Feel free to fork the benchmarks and implement it! I'd be interested to see it also, but am not interested in maintaining those benchmarks.

I'm interested in seeing benchmarks with other KV stores like Persy.

I have an extensive Rust KV benchmark repo: https://github.com/marvin-j97/rust-storage-bench @satvikpendem


pruned_transducer_sateless training with word pieces

Hi All,
I am looking on the tedlium3 training command and I see that this command does not receive BPE directory as one of parameters. Therefore I assume that this training job is based on characters only? Do you have transducer training system example that is based on BPE word pieces?
./pruned_transducer_stateless/train.py
--world-size 4
--num-epochs 30
--start-epoch 0
--exp-dir pruned_transducer_stateless/exp
--max-duration 200
--enable-musan 0
--enable-spec-aug 0
Thanks a lot,
AlexG.

You may pass the path to your BPE model by modifying the arg --bpe-model. https://github.com/k2-fsa/icefall/blob/fbc1d3b194cfb2be4d01de85d9c3a3ea13c961fb/egs/tedlium3/ASR/pruned_transducer_stateless/train.py#L119
Note that we don't show all possible args in the training commands in RESULTS.md. You should have a look at train.py to see all the options.


trino-iceberg-demo fails due to partitioning declaration on CL2 DEV cluster

Describe the bug
When I attempt to run Cell 7, I get this error message as a result of trying to execute this sql statement:
create table if not exists osc_datacommons_dev.sandbox.trino_iceberg_demo(
    quarter varchar,
    reduction double
) with (
    format = 'ORC',
    partitioning = array['quarter']
)

TrinoUserError: TrinoUserError(type=USER_ERROR, name=INVALID_TABLE_PROPERTY, message="Catalog 'osc_datacommons_dev' does not support table property 'partitioning'", query_id=20220319_141301_00002_thkmy)
To Reproduce
Steps to reproduce the behavior:

Start with Jupiter Notebook: https://jupyterhub-odh-jupyterhub.apps.odh-cl2.apps.os-climate.org/user/michaeltiemannosc/lab/tree/data-platform-demo/notebooks/trino-iceberg-demo.ipynb
pip install all prerequisites
ingest_catalog='osc_datacommons_dev'
ingest_schema='sandbox`
run notebook
See error when attempting to execute this code:

import osc_ingest_trino as osc
columnschema = osc.create_table_schema_pairs(df1)

tabledef = f"""
create table if not exists {ingest_catalog}.{ingest_schema}.{ingest_table}(
{columnschema}
) with (
    format = 'ORC',
    partitioning = array['quarter']
)
"""
print(tabledef)
qres = engine.execute(tabledef)
print(qres.fetchall())

Expected behavior
I expected the notebook would create a proper table for the iceberg world that is the CL2 dev cluster.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

These are the only 3 properties we should have:
format | Optionally specifies the format of table data files; either PARQUET or ORC. Defaults to ORC
partitioning | Optionally specifies table partitioning. If a table is partitioned by columns c1 and c2, the partitioning property would be partitioning = ARRAY['c1', 'c2']
location | Optionally specifies the file system location URI for the table

Err yeah, seems I used the wrong connector.
Comparison:

iceberg catalog in osc-cl1: link
catalog in osc-cl2: link

Notice: connector.name=hive-hadoop2 in the latter. Will change to iceberg.
To clarify we also want the following right?
iceberg.file-format=PARQUET
iceberg.compression-codec=GZIP
iceberg.max-partitions-per-writer=100

https://github.com/operate-first/apps/pull/1768

These are the general configuration properties, the ones i highlighted are only table properties and there are only 3 of them based on latest documentation: https://trino.io/docs/current/connector/iceberg.html

Yes, since the connector is not iceberg the first thing is to deploy it as such, so these table properties can be supported. Above I'm essentially asking if the configuration should emulate osc-cl1 iceberg catalog deployment exactly.

Success!  Closing...


refactor: Replace encoding with fetch-charset-detection.

This PR replaces the encoding optional dependency with fetch-charset-detection.
cc @bitinn @xxczaki

Also the diff view on GitHub is weird, I wouldn't expect large change on package.json, also writeToStream is somehow removed?

Also note the charset detection is not a part of the Fetch Spec, which is why we have been trying to deprecate it. In particular, I introduced them in v1 and I regret it ever since.

There is no reason is hook charset detection into our code neither, by doing encoding conversion you essentially need to cache the whole response in memory. Get them through res.body is basically the same.
Also this is why I asked about documentation, we are introducing a breaking API changes, people who use node-fetch as web crawler will need to use the new package, so documentation is needed to guide them on the upgrade.
(I am writing these comments for future reader's reference, because obviously people will hate breaking changes)

Also this is why I asked about documentation, we are introducing a breaking API changes, people who use node-fetch as web crawler will need to use the new package, so documentation is needed to guide them on the upgrade.

Charset encoding detection is already described in the v3 migration guide and the API is documented in the documentation.

@bitinn Just for clarification, which functions were we supposed to migrate to fetch-charset-detection?

Public API-wise it's really just textConverted, I do not believe we expose anything else. But we should remove code that's added only in support for textConverted, like convertBody.
I am not aware of any other dependency on encoding.

Given v2 code I would say fetch-charset-detection could expect a buffer input.
https://github.com/bitinn/node-fetch/blob/master/src/body.js#L151

Now that I have looked at fetch-charset-detection, I think it's doing a lot more than my original expectation. Sorry to not clarify early. I would have keep fetch-charset-detection minimal (and it's should be because it doesn't depends on anything else, just a buffer input, and a content-type header)

In short, I would just ask the users to pass the res.buffer and content-type header. fetch-charset-detection need not to know node-fetch, to be honest. It can be used for any other response that's compatible.

@bitinn It's ready for another re-review.

Oh.  I'll be back for another review.

@Richienb it's my bad, I should have been more clear on this. I thought it should be clear while the situation is more nuanced than my expectation.

BUT: our tests keep failing, can we fix that first? Is it pending on some PR?

@bitinn The failing build is related to Replace the calls to url.parse and url.resolve with calls to new URL to use the new UTF-8 awareness and remove the utf8 package. in the v3 roadmap and therefore does not relate to this PR specifically.

@Richienb it's also failing in a test for data uri support.
should accept data uri of plain text
https://travis-ci.org/bitinn/node-fetch/jobs/613306983

But I guess due to linting issues no PR to v3 will pass? Or was the linting test optional?

I would say we could have a test for using fetch-charset-detection in our test suite? It's not strictly necessary for unit testing, but nice to confirm it works integration-wise.

@bitinn

it's also failing in a test for data uri support.

That's not related to this PR.

But I guess due to linting issues no PR to v3 will pass? Or was the linting test optional?

It looks like VSCode autoformatted the code incorrectly. I'll run yarn lint --fix and push the changes.

I would say we could have a test for using fetch-charset-detection in our test suite? It's not strictly necessary for unit testing, but nice to confirm it works integration-wise.

https://github.com/Richienb/fetch-charset-detection/blob/master/test.js

@bitinn It looks like the build for the PR may be bugged. However, the build for this branch isn't.

then it's good to go.

All reviewers approve. Time to merge!


[Security] APT keys are not authenticated

See https://github.com/Nitrux/mkiso/blob/master/build.sh#L50-L51.
Seems like the same issue persists across most build tools.
Related:
https://github.com/nomad-desktop/nxos-docker-image/issues/2
https://github.com/nomad-desktop/nx-software-center/issues/20

Shouldn't those lines authenticate the packages?

The problem is the key files are downloaded without any authentication. Manipulation is possible here, and it's fairly easy to secure this. See nomad-desktop/nxos-docker-image#4 for how to ensure the keys' authenticity (hardcoding a message digest (SHA 256 hash sum) of the file in the script, so when the key is downloaded, you can make sure it's the one you want to have by hashing the downloaded file and comparing the resulting hash sum to the one you expect).
Actually, it's even possible to add the keys to this repository, and use the local files.

Great, @TheAssassin! Many thanks for the advice! :grin:

I think that adding the keys to this repo would be the most secure way of working with the keys, but the problem I see with that method is that if files containing the keys change, they won't work when adding them with apt-key. I'm not sure if this is something to really worry about (I mean using local files) because I haven't worked too much with apt-based systems (only a couple years ago, when I started using Linux, and again since January of current year, due to my job with Nitrux).

It's not very likely they will ever change. But if they did, any image you'd have built before would still contain them forever, using wget won't change that.
If you want to be able to notice changes, use wget with a hash, then when the hashs don't match, you'll notice as the build will fail.

Oh, I see. Thanks for your help, @TheAssassin. The issue got solved on the fork I maintain on my account (I needed to use a Githubtoken and don't have enough permissions in this repo, so I had to fork), and I will soon make a PR. Again, thanks a lot for your help! :grin:

You're welcome. Feel free to mention me in the PR, I'll have a look then.

Alright. :wink:

Done. I pushed the changes directly, without merging the pull request. Here are the changes.


Laravel 11.18.0 Shift

This pull request includes updates for the recent minor version release of Laravel as well as updates to your package dependencies. Feel free to commit any additional changes to the shift-ci-v11.18.0 branch.
Before merging, you need to:

Checkout the shift-ci-v11.18.0 branch
Review all pull request comments for additional changes
Run composer update
Thoroughly test your application (no tests?, no CI?)

:warning: The Shift build servers run PHP 8.2. If you are running a different version of PHP you should run composer update locally to ensure you have the proper versions of your dependencies to reflect your PHP environment.


Cotary Create: Add buttons to copy DAO addresses and logs

Adding feature from #376.

Maybe we have a copy icon in the bottom right that will copy the addresses to the user's clipboard.
Also we'll want a way to export the full deployment log for debugging sake... maybe we combine both of these options into one "popup" menu like it's done in V1: "copy addresses", "copy log"

Copy Logs (bottom right) W/ Hover Tip:

Save DAO Addresses Button:

@pimato please review the styling of these features

This def. needs a redesign!

can anyone explain me why someone wants to copy an address and about which addresses are we talking about?

Also, after a successful deployment, why do we want to let the user deploy it again?

can anyone explain me why someone wants to copy an address and about which addresses are we talking about?

The addresses are the  addresses you get from a deployment:
"Avatar": "0x77Ff0fb79642f9173D26745b104a032e7a596639",
"DAOToken": "0xAA3F1D38928c19a712eDAaaF74cC25eA036B936a",
"Reputation": "0xe64A2EBAC40b47abFB928c591F4C6558d3879954",
"Controller": "0x24B75D747474F1871f7E52F1e097Cf77F42Cb449"

Also, after a successful deployment, why do we want to let the user deploy it again?

So they can change settings and deploy a new one.

Those addresses are only important for devs. Normal people really don´t care about those addresses. The daocreator should be as simple af, including feature like that will do the opposite. Alchemy should do the job to let the user know the addresses of each module.

Why should the user create a dao, change settings and create a new one ?

@dOrgJelli

Why should the user create a dao, change settings and create a new one ?
@pimato
I think the motivation was that if lets say that you forgot to add another member or something, you are able to go back add such member, and then redeploy.

Why should the user create a dao, change settings and create a new one ?

@pimato @dOrgJelli
I think the motivation was that if lets say that you forgot to add another member or something, you are able to go back add such member, and then redeploy.

I agree @pimato, copying addresses shouldn't be necessary since they should be able to get to these addresses via Alchemy.

Okay, I'll remove the button.


⚠ Bofrost.lu has degraded performance

In 58c515f, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1745 ms

Resolved: Bofrost.lu performance has improved in 131b0bd after 7 minutes.


Add-subclass template has empty category, package name set

It was quite confusing since I clicked elsewhere, came back, and my class categories pane did not show my new class at all.
RowanSample1 rwSubclass: 'NameOfSubclass'
instVarNames: #()
classVars: #()
classInstVars: #()
poolDictionaries: #()
category: ''
packageName: 'RowanSample1-Core'
options: #()

Which view packages or dictionaries were you using?

Both

Ok, I see the bug.  The new subclass was added and can be seen by selecting All Categories in the Class Categories pane. However selecting the class category RowanSample1 or it's subcategory Core will not show the new class.
Workaround - Select All Categories to see the newly created class.

Interesting, the Show Changes browser shows this modification which is wrong:
RowanSample1 rwSubclass: '''NameOfSubclass'''
	instVarNames: #()
	classVars: #()
	classInstVars: #()
	poolDictionaries: #()
	category: '''nil'''
	options: #()

I think the problem is in this variant of the rwSubclass methods:
Object rwSubclass: 'FooSub2'
	instVarNames: #()
	classVars: #()
	classInstVars: #()
	poolDictionaries: #()
	category: ''
	packageName: 'NewPackage'
	options: #()

When I execute this in a workspace I see the problems described above. But when I execute this rwSubclass variant, both the Show Changes & missing category problem go away.
Object rwSubclass: 'NameOfSubclass'
	instVarNames: #()
	classVars: #()
	classInstVars: #()
	poolDictionaries: #()
	category: 'NewPackage'
	options: #()

Reassigning to Dale.

Reassigning back to me. Should only use this variant in alpha:
 Object rwSubclass: 'NameOfSubclass'
	instVarNames: #()
	classVars: #()
	classInstVars: #()
	poolDictionaries: #()
	category: 'NewPackage'
	options: #()


renamed msi-pro-z790-p.robot to msi-pro-z790-p-ddr5.robot: to reflect

Picked relevant changes to: https://github.com/Dasharo/open-source-firmware-validation/pull/588
I am not convinced by this commit right now why it was neede: https://github.com/Dasharo/open-source-firmware-validation/pull/566/commits/9f507d7d776e6009ab66a14b0b5fd9b6984887b0
Skipping it for now.

I am not convinced by this commit right now why it was neede: 9f507d7

It was an attempt (unsuccessful AFAIK) to fix the problem where SSHLibrary.Read was invoked immediately after SSHLibrary.Write, before the actual output of the command was produced. After taking a second look, it seems that in case of PiKVM, it is writing through KVM, but reading from telnet. There are also keywords that change connection method from KVM to SSH and back. Perhaps there was old output in one of the buffers between such switch.


FieldError in django_orm

IntegrityErrors (user email already exists). This includes all fields from details. This will result in a FieldError from Django because not all fields from details are found on the user model

Hi, I have some suggestions to help solving this issue!
Here is a list of similar issues:

1. [FieldError in django_orm](https://github.com/fjsj/python-social-auth/issues/57)

2. [FieldError in django_orm](https://github.com/omab/python-social-auth/issues/1010)

3. [Issue with new users (create_user) - redirects me to LOGIN_ERROR_URL](https://github.com/omab/python-social-auth/issues/775)

4. [Not getting correct GoogleOath2 details when signing up by OAuth access token](https://github.com/omab/python-social-auth/issues/499)

5. [Email Confirmation from different browser, Missing needed parameter email](https://github.com/omab/python-social-auth/issues/830)

Hope this is useful!
Cheers,
Cinnabot.


Additional images to return from reader (band contrast / ipf)

band contrast map (image quality)
ipf coloring (grain crystal orientation)

also kam (kernel average misorientation)


Loss value does not decrease

When I am training, the loss value fluctuates within a range and does not decrease after many epochs.The following error code was also output during training：
UserWarning: Detected call of lr_scheduler.step() before optimizer.step(). In PyTorch 1.1.0 and later, you should call them in the opposite order: optimizer.step() before lr_scheduler.step().  Failure to do this will result in PyTorch skipping the first value of the learning rate schedule. See more details at https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate
warnings.warn("Detected call of lr_scheduler.step() before optimizer.step().

hi, nekonekoni7
This warning will not cause any side effects, you can ignore it now.
As for your fluctuating loss, we suggest you check your data first according to my experience.
Since the lr and other hyper-parameters are validated, inappropriate data processing will prevent the model from learning useful knowledge.
Here's my preprocessing scripts link. Hope this can help you.

My training loss also did not decrease, even though I followed the preprocessing steps in the provided preprocessing scripts. Actually in the scripts, the preprocessing step is just resampling the spacing to <IP_ADDRESS> mm. Am I correct? If so, then what are the reasons for the issue of training loss?

I think the issue may lie in the mask. Could you provide more details about your tasks and the mask you used?

I'm using the MSD07_pancreas dataset. The dataset contains two classes, i.e., pancreas and tumor. For the mask, I only extract the tumor class to get a {0,1} mask. I tried different batch sizes. With the default batch size 10, the loss stuck around 17, but if I set the batch size to 2, the loss can decrease from 15 to 2.

I also experienced with this problem. I used my own dataset. anyone has a trick to improve the training?


Add TNT model

Add TNT model in paper 'Transformer in Transformer' - https://arxiv.org/abs/2103.00112

@contrastive thanks, I'll take a closer look in the next few days, I have to tweak a few things with the unit tests for models like this and vit as they fall outside the typical behaviour of CNN nets.

@rwightman I fixed the code to pass all checks.

@contrastive thanks for the good work here. Any plans to add pretrained weights for the base tnt size?


Fix Capitalization bug

fixes issue #33
Example:
title('diseño')
// Diseño
title('fernández')
// Fernández

Closing as stale, can reopen if this PR is updated 🙏

We can do this with unicode ranges as well, example:
const regex = /(?:(?:(\s?(?:^|[.\(\)!?;:"-])\s*)(\w))|(\w))([\w\u00C0-\u1EF3]*[’']*[\w\u00C0-\u1EF3]*)/g will cover many of the problematic characters.
The regex I posted almost solves the problem, unless for two letter words. This is the casing now:
Aaøøbbææccååaøbøcød å æ ø øL Lø åå Aå åA,  but I think it should be
Aaøøbbææccååaøbøcød å æ ø Øl Lø Åå Aå Åa?
Using the current code, it is Aaøøbbææccååaøbøcød å æ ø Øl Lø Åå Aå Åa, and using the one from this PR, it is AaøøbbææCcååaøBøcøD å æ ø øL Lø åå Aå åA..
I thought we could use Unicode property escapes for this, \p{L}, but even tho it looks like (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) it is supported from node 10, I can't get it to work correctly..


update Miri CI config

We don't need curl and https://rust-lang.github.io/rustup-components-history/ any more now that rustup can install "latest toolchain with certain tools".

Thanks!


add optional semicolon to cfg

Fixes #70

Seeing this error when trying to gen the lexer or parser
Some problems were found with the configuration of task ':generateLexer' (type 'GenerateLexerTask').
  - In plugin 'org.jetbrains.grammarkit' type 'org.jetbrains.grammarkit.tasks.GenerateLexerTask' property 'source' doesn't have a configured value.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 62ms
1 actionable task: 1 executed

Early on I tried using the grammar kit's grade plugin to do that generation. IIRC, at some point or other those tasks even ran automatically during the build so generated code was always ephemeral, which was nice. Memory is fuzzy but I bailed on that because the plugin didn't support some features of grammar kit. https://github.com/FacilityApi/FacilityIntellij/pull/1#issuecomment-951457494 The bespoke lexer generator task (generateFsdLexer) is still in there.
./gradlew tasks is misleading. It might be worthwhile to remove the grammar kit plugin from the build so it doesn't add those tasks to the project.
I typically used the grammar kit plugin in IntelliJ to regenerate the lexer and parser code.

You're probably going to need to update _FsdLexer.flex also. It annoyed me that the lexer was so involved, but it was the best way I could come up with to correctly tokenize method as a keyword in some syntactical contexts and as an annotation parameter name elsewhere (the HTTP annotation, I think).


vsphere install-pcf got stuck at deploy-ert with cert pem and private key errors

Using latest commit ea6eda5, running install-pcf on vsphere on concourse 3.1.1 was fine until deploy-ert, where it throws the following error at the configure step:
>_ configure
Status: 404 Not Found
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Tue, 20 Jun 2017 20:46:46 GMT
Server: nginx/1.4.6 (Ubuntu)
Strict-Transport-Security: max-age=31536000
X-Request-Id: ed082166-d986-47b9-b3df-3dd3ca760da9
X-Runtime: 0.003033
Status: 404 Not Found
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Tue, 20 Jun 2017 20:46:46 GMT
Server: nginx/1.4.6 (Ubuntu)
Strict-Transport-Security: max-age=31536000
X-Request-Id: 733319bf-2cf5-47c1-bcb9-e3824f1eb9d4
X-Runtime: 0.001802
configuring product...
setting properties
could not execute "configure-product": failed to configure product: request failed: unexpected response:
HTTP/1.1 422 Unprocessable Entity
Transfer-Encoding: chunked
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Tue, 20 Jun 2017 20:46:48 GMT
Server: nginx/1.4.6 (Ubuntu)
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 6cfc962f-4d76-4cdf-9c98-add07adcc533
X-Runtime: 0.494804
X-Xss-Protection: 1; mode=block

158
{"errors":{".properties.networking_point_of_entry.haproxy.ssl_rsa_certificate":["Cert pem can't be blank","Cert pem is invalid","Private key pem can't be blank","Private key pem is invalid"],".uaa.service_provider_key_credentials":["Cert pem can't be blank","Cert pem is invalid","Private key pem can't be blank","Private key pem is invalid"]}}
0

In my vsphere params.yml, I have:
## Wildcard domain certs go here
# Optional. Will be generated if blank using ssl_termination_point below.
ssl_cert:
# Optional. Will be generated if blank using ssl_termination_point below.
ssl_private_key:
ssl_termination_point: haproxy # (external_ssl|external_non_ssl|haproxy)

disable_http_proxy: false
security_acknowledgement: X  # Must be set to 'X'. See explanation here: https://docs.pivotal.io/pivotalcf/latest/customizing/config-er-vmware.html#app-security

## TCP routing and routing services
tcp_routing: disable                    # Enable/disable TCP routing (enable|disable)
tcp_routing_ports:                   # A comma-separated list of ports and hyphen-separated port ranges, e.g. 52135,34000-35000,23478
route_services: enable                 # Enable/disable route services (enable|disable)
ignore_ssl_cert_verification: true     # Whether to disable SSL cert verification for this environment
garden_network_pool_cidr: <IP_ADDRESS>/22  # Only change this if you need to avoid address collision with a third-party service on the same subnet.
garden_network_mtu: 1454                # Applications Network Maximum Transmission Unit bytes

How come it's not generating the SSL certificate for HAProxy?
PCF: 1.9

I've identified the issue. I was using install-pcf to deploy PCF 1.9. In v1.9 the API endpoint to generate certificates is /api/v0/rsa_certificates, not the /api/v0/certificates/generate in later versions.
In my concourse VM under the overlay mount folder (in this case /mnt/concourse/worker/volumes/dead/266303bf-cbfe-4597-4e28-67ad4043f9f1/volume/rootfs/usr/local/bin):
[beibei@workbench bin]$ ./om-linux --target "https://om.<FQDN.domain>" --username "pcfadmin" --password "password" --skip-ssl-validation curl --silent --path "/api/v0/certificates/generate" -x POST -d $data
Status: 404 Not Found
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Wed, 21 Jun 2017 15:10:49 GMT
Server: nginx/1.4.6 (Ubuntu)
Strict-Transport-Security: max-age=31536000
X-Request-Id: ae271ba8-43f3-4420-9550-15f00e389ef2
X-Runtime: 0.001432

[beibei@workbench bin]$ ./om-linux --target "https://om.<FQDN.domain>" --username "pcfadmin" --password "password" --skip-ssl-validation curl --silent --path "/api/v0/rsa_certificates" -x POST -d $data
{
  "certificate": "-----BEGIN CERTIFICATE-----\nMIIDZjCCAk6gAwIBAgIUbskDFWwjYfvqqLT70afPsLHdIQcwDQYJKoZIhvcNAQEL\nBQAwHzELMAkGA1UEBhMCVVMxEDAOBgNVBAoMB1Bpdm90YWwwHhcNMTcwNjIwMTUx\nNDQyWhcNMTkwNjIwMTUxNDQyWjBDMQswCQYDVQQGEwJVUzEQMA4GA1UECgwHUGl2\nb3RhbDEiMCAGA1UEAwwZKi5zeXN0ZW0ucGNmMi5haW1nYS5sb2NhbDCCASIwDQYJ\nKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO0mNx8PONJRGE686C0PzqSADFqPe1Ud\n/bCug1cI3CbgSuDmlyvq4aCQbdERbNDo2VJpvQ7eyfZBDqlqawkH9SmA/ff0iGCk\neN39G/zKeTQKcbe9QImGnzEqUkBBewz2R+cNVjyUSiQey3tajymNrf+qY5MENzUd\nwC1Ybc/uSXAjcBInuxe4CsZd2IVEUbEUz26LXPvJzc7nX60Cd2JN/5+UkWoCymJt\n7SmDoFiDfl6oh/5nwNqZT/ZvA4UWKixeY0OM5M72fYQ1qb6rdcdGZ/PEQkxEnNZp\nGnEpqoOpbVst8quz93/l3FCKPc78BEBAj8L/Y8VjGxtvq4yFtxUXrg8CAwEAAaN2\nMHQwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBQSRFUea2KGKvsVaSk98bZyfkBX\nTTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwJAYDVR0RBB0wG4IZKi5z\neXN0ZW0ucGNmMi5haW1nYS5sb2NhbDANBgkqhkiG9w0BAQsFAAOCAQEAy/FgCWao\nbm6e6+vL658GkjinvXnWRLJfA5VwtmMFeIy8DVUW595czW/UXbShbvxfhdBMpGTD\nGa7fOA3ud1dmKnBEM6BAWPN+eBDo3QDA8qUV1zeX4QtxdLPYBkPGvCDYi+Mov/lK\nh6jF7jzs4uYr2nW0w9QidwMU2YB+REA/kFwCol1TLTibHna0awdlw8z5AVaL6UgZ\nhXf3BzZAk0wVD5988tZdyWAEy3Wh/AiCxv3kgMsl44yb4iRYyern6ci7ygFEKpIy\nGxw8Yl20iNywFBhHnalCJ3kBK6Qy0IWkN76hWXryXnY4LoN8wCnHYX3gRStEouf4\nCkzxecjjuJCtKQ==\n-----END CERTIFICATE-----\n",
  "key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpQIBAAKCAQEA7SY3Hw840lEYTrzoLQ/OpIAMWo97VR39sK6DVwjcJuBK4OaX\nK+rhoJBt0RFs0OjZUmm9Dt7J9kEOqWprCQf1KYD99/SIYKR43f0b/Mp5NApxt71A\niYafMSpSQEF7DPZH5w1WPJRKJB7Le1qPKY2t/6pjkwQ3NR3ALVhtz+5JcCNwEie7\nF7gKxl3YhURRsRTPbotc+8nNzudfrQJ3Yk3/n5SRagLKYm3tKYOgWIN+XqiH/mfA\n2plP9m8DhRYqLF5jQ4zkzvZ9hDWpvqt1x0Zn88RCTESc1mkacSmqg6ltWy3yq7P3\nf+XcUIo9zvwEQECPwv9jxWMbG2+rjIW3FReuDwIDAQABAoIBAQDDPxRg0QKCPdwa\nb3NkLkB+tSH2qWzsTi3g+j0OOjAvHbjoY1ERCmfK7z5Kw+LoON07+ex6wrhas4Nj\nvkbzf4a8LgRq0fw6PQ96DPqu7PBPBU5M7VamI50LOIHRf1fU+yuFsjhO1fQYuvXi\n0FNP7eLUvK8Qiob9h0oCy2xVpiT2WdEdOl913IrihqMgWiWmuprdwh3ALC8xWrhb\nlNhHqMWYC3Q46A4ME0c73WgNag4Rpr5WSMERj8lk+33xsGABMabsN9Yu6L9UZ8bR\nU6npjWGfXzjGKRBxvXZkip90vGGt0tfuIdkS54emsQ/VUW/i2YBQvPjC5IBkgtEl\naCQ3UVNZAoGBAPifqjCHR+OtFT0iTMzXIXZb+d4awcfVn+EvUzt9NXn6iJO8xkd5\nWnxSHdWuYXR01HljoczFnoGMdmH4h7kc8dcHQEix4fn2T15n6Fy6hVLsKwbjgXVR\nWSXpUjdJra0OWTC/zieK9kIC206cZ/4aNiCwLQxRAA9VLFyj6lQpbRELAoGBAPQv\nZo0Bq7d0heJToZwkjpJQPNijozg0xqTSC7vXuvChNonbRp9Fxw11EH6+X2DZPg3t\nDWFojOPnKR7RVhBg5M56qFkR693QNCfQ8z1F8ELEnIdgbBbvEc4P4sevzNEBLWB1\nrfkd3TI1KQg1eJmH7YZVsvMTU7hHxecaK+4SBMGNAoGAegDf4zB/dppY8ccDKQHo\nycwYsYUv0oBiFH7EuUyYEWN/4f+gzTIf1SH2wgTwjdVG7sqVe4b+YVQsQ6dR8uTh\nSEOmqAWifqcAC7Oxss9U3XxHIPpDbO6ecJwuXDMrpuCDpAh7gawPbBU6yTi3T1pN\ndXz+niyheuSxAETvmJ07iEECgYEAgr/u1YoTfIQ0PGAzpPweK1Izgnz8pNf9lbuy\n9L4rJzXrkh2LzzT5xMbuMi+VurIYfDR2ebYV2uKoLgxBXTvEyJr9EdR6y6b0hm1o\nEWMlp1rHxeVne1A/5Gq1L99+eFt9BK1+nmnTS1MTyYV4Mh2Knee9jlLG/WHRIlHt\nO+kCCvECgYEAywx9c99lCeZHg6ODhdHyRamwl2PpZejda87qtFDMl4pP14+b0Cwt\n3w1eChGLTXYYr4xMakSqW/sit2sUyFdSfb859axLohzWlWrggajH08lpiBVytqMP\na+/tmGINgM4RomhNjUSMzHjd7K1UnlqL2KvJDQyU8nwPm3ogCpzExpE=\n-----END RSA PRIVATE KEY-----\n"
}

Hi @beibeiyang , thanks for filing this issue and for explaining how you figured out how to get around the issue.
Just for your information, because there are so many differences between the major versions of PCF that mean different required configurations, we aren't usually able to support the use of the install-pipeline for every PCF version. We therefore strive to support the latest version of PCF, since we expect many users to want to install the latest version of PCF (which is 1.11, as of today).
If you have reasons to install 1.9 only though, please let us know and we'll consider whether we should add more version support to the pipelines.
Thank you!


Create codeql-analysis.yml

Code scanning is a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors.

LGTM

Can we have this PR merged for code scanning?


[nrf noup] pm: remove dependency on devicetree

The symbols we need are already available in kconfig
Ref: NCSDK-7150
Signed-off-by: Håkon Øye Amundsen<EMAIL_ADDRESS>

See https://github.com/nrfconnect/sdk-nrf/pull/3368

@ioannisg please merge this when it suits the upmerge schedule.

I merged this in to the initial commit for all the pm.yml stuff
https://github.com/ioannisg/sdk-mcuboot/pull/1/commits/95cd6b26509825316448d0a9b43b1f9df2e41277
Note that this PR will contain all the downstream patches for this upmerge

Closing as this is now included in the upmerge PR


ADBDEV-5811: Add collection of test logs of resource groups

Add collection of test logs of resource groups
During the testing of resource groups, log files are created that can be useful
in analyzing problems.
This patch adds saving log files before deleting containers. The log files are
archived and saved to the /logs directory inside the container, which is a
volume mounted in the logs_cdw and logs_sdw1 directories for the corresponding
containers on the host.

Allure report https://allure.adsw.io/launch/74376

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1598885

Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1598883

Allure report https://allure.adsw.io/launch/75069

Allure report https://allure.adsw.io/launch/75079

Allure report https://allure.adsw.io/launch/75219

Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1639456


Error on build

Because every version of flutter_test from sdk depends on http 0.11.3+17 and flutter_client_php_backend depends on http ^0.12.0, flutter_test from sdk is forbidden.
So, because flutter_client_php_backend depends on flutter_test any from sdk, version solving failed.
pub get failed (1)

@muriminyaga hey buddy is your issue resolved or are you still facing it. Cuz I am not facing it on my side.

@muriminyaga hey buddy is your issue resolved or are you still facing it. Cuz I am not facing it on my side.

I sorted it by upgrading the flutter plugin.Thanks


PySpark kernell

Hi Quy Tang.
That is a great job, thank you.
Could you add (or provide instructions on how to do that on Windows) "Sparkmagic (PySpark)" kernel for Jupiter? Unfortunately, I am completely new in Docker technology and was able just to run a container you provided, not to build my own. But I need a kernel that will run Spark applications like it is done in AWS.
P.S. Attempt to include pyspark module in existing python kernel leads to that error:
ModuleNotFoundError: No module named 'pyspark'
Thank you.

You can try adding pyspark to https://github.com/qtangs/sagemaker-notebook-container/blob/master/envs/include_libraries.txt, it controls what libraries are added to the python environments.


Bump Android NDK version to r22

Per the GH issue here: https://github.com/actions/virtual-environments/issues/2420, the Mac images that ADO/GH-actions CI uses have removed Android NDK r21d (our currently pinned version) in favor of r22.
This PR bumps our version to r22.

Noticed that this was linked on the other issue. FYI, you should upgrade Android Gradle Plugin to 4.1.1, as per https://github.com/actions/virtual-environments/issues/2420#issuecomment-760988437 that includes a fix so the specified ndk version gets downloaded instead of throwing an error.

Noticed that this was linked on the other issue. FYI, you should upgrade Android Gradle Plugin to 4.1.1, as per https://github.com/actions/virtual-environments/issues/2420#issuecomment-760988437 that includes a fix so the specified ndk version gets downloaded instead of throwing an error.

Thanks for the note @carstenhag! I'll throw that on my backlog. I was hesitant to let the plugin auto-resolve an NDK version since we've been burned in the past with some fairly obscure incompatibility issues between libraries compiled with different NDKs, but I'm also being burned by pinning so 🤷

Thanks for the note @carstenhag! I'll throw that on my backlog. I was hesitant to let the plugin auto-resolve an NDK version since we've been burned in the past with some fairly obscure incompatibility issues between libraries compiled with different NDKs, but I'm also being burned by pinning so 🤷

Ah I see. Yeah, we got burned by pinning the version too (but we also used AGP 4.0). We now use the latest AGP, and pinning should work fine now, even if the image doesnt have it

Ah I see. Yeah, we got burned by pinning the version too (but we also used AGP 4.0). We now use the latest AGP, and pinning should work fine now, even if the image doesnt have it


remove rule summary from top of the scoreboard

This removes the summary of rules in SCOREBOARD.md.
Summarizing rules in the README as well as these ancillary files is begging to create inconsistency and confusion.

+1