Problems in producing the area for Gibson glb files

❓ Questions and Help
Hello. I would like to compute the total area and navigable area for Gibon scenes. I found the Habitat-sim Basics for Navigation tutorial  is the one I should follow.
So I firstly installed habitat-sim by running "conda install habitat-sim headless -c conda-forge -c aihabitat-nightly" on my desktop.
Then I create a tiny version of the tutorial by copying some parts of the tutorial on my desktop as follows;

# @title Configure Sim Settings

test_scene = "./data/scene_datasets/mp3d/17DRP5sb8fy/17DRP5sb8fy.glb"
display=False

rgb_sensor = True  # @param {type:"boolean"}
depth_sensor = True  # @param {type:"boolean"}
semantic_sensor = True  # @param {type:"boolean"}

sim_settings = {
    "width": 256,  # Spatial resolution of the observations
    "height": 256,
    "scene": test_scene,  # Scene path
    "default_agent": 0,
    "sensor_height": 1.5,  # Height of sensors in meters
    "color_sensor": rgb_sensor,  # RGB sensor
    "depth_sensor": depth_sensor,  # Depth sensor
    "semantic_sensor": semantic_sensor,  # Semantic sensor
    "seed": 1,  # used in the random navigation
    "enable_physics": False,  # kinematics only
}

def make_cfg(settings):
    sim_cfg = habitat_sim.SimulatorConfiguration()
    sim_cfg.gpu_device_id = 0
    sim_cfg.scene_id = settings["scene"]
    sim_cfg.enable_physics = settings["enable_physics"]

    # Note: all sensors must have the same resolution
    sensors = {
        "color_sensor": {
            "sensor_type": habitat_sim.SensorType.COLOR,
            "resolution": [settings["height"], settings["width"]],
            "position": [0.0, settings["sensor_height"], 0.0],
        },
        "depth_sensor": {
            "sensor_type": habitat_sim.SensorType.DEPTH,
            "resolution": [settings["height"], settings["width"]],
            "position": [0.0, settings["sensor_height"], 0.0],
        },
        "semantic_sensor": {
            "sensor_type": habitat_sim.SensorType.SEMANTIC,
            "resolution": [settings["height"], settings["width"]],
            "position": [0.0, settings["sensor_height"], 0.0],
        },
    }

    sensor_specs = []
    for sensor_uuid, sensor_params in sensors.items():
        if settings[sensor_uuid]:
            sensor_spec = habitat_sim.SensorSpec()
            sensor_spec.uuid = sensor_uuid
            sensor_spec.sensor_type = sensor_params["sensor_type"]
            sensor_spec.resolution = sensor_params["resolution"]
            sensor_spec.position = sensor_params["position"]

            sensor_specs.append(sensor_spec)

    # Here you can specify the amount of displacement in a forward action and the turn angle
    agent_cfg = habitat_sim.agent.AgentConfiguration()
    agent_cfg.sensor_specifications = sensor_specs
    agent_cfg.action_space = {
        "move_forward": habitat_sim.agent.ActionSpec(
            "move_forward", habitat_sim.agent.ActuationSpec(amount=0.25)
        ),
        "turn_left": habitat_sim.agent.ActionSpec(
            "turn_left", habitat_sim.agent.ActuationSpec(amount=30.0)
        ),
        "turn_right": habitat_sim.agent.ActionSpec(
            "turn_right", habitat_sim.agent.ActuationSpec(amount=30.0)
        ),
    }

    return habitat_sim.Configuration(sim_cfg, [agent_cfg])

def print_scene_recur(scene, limit_output=10):
    print(dir(scene))
    print(
        f"House has {len(scene.levels)} levels, {len(scene.regions)} regions and {len(scene.objects)} objects"
    )
    print(f"House center:{scene.aabb.center} dims:{scene.aabb.sizes}")

    count = 0
    for level in scene.levels:
        print(
            f"Level id:{level.id}, center:{level.aabb.center},"
            f" dims:{level.aabb.sizes}"
        )
        for region in level.regions:
            print(
                f"Region id:{region.id}, category:{region.category.name()},"
                f" center:{region.aabb.center}, dims:{region.aabb.sizes}"
            )
            for obj in region.objects:
                print(
                    f"Object id:{obj.id}, category:{obj.category.name()},"
                    f" center:{obj.aabb.center}, dims:{obj.aabb.sizes}"
                )
                count += 1
                if count >= limit_output:
                    return

# Print semantic annotation information (id, category, bounding box details)
# about levels, regions and objects in a hierarchical fashion

cfg = make_cfg(sim_settings)
# Needed to handle out of order cell run in Colab
try:  # Got to make initialization idiot proof
    sim.close()
except NameError:
    pass
sim = habitat_sim.Simulator(cfg)

scene = sim.semantic_scene
print_scene_recur(scene)

The code produced corrected result for the test scene.
But when I replace the test_scene by a scene "Adrian.glb" in Gibson dataset. The outputs  are quite strange, as follows

House has 0 levels, 0 regions and 0 objects
House center:[0. 0. 0.] dims:[-inf -inf -inf]

Could anyone give any hint on this problem? Any suggestion would be highly appreciated.
By the way, what's the difference between the result returned by region.aabb.sizes and "sim.pathfinder.get_bounds()" of NavMesh?

sim.semantic_scene access whatever semantic annotations a dataset has.  Only a very small subset of Gibson has semantic annotations (and I forget if that has region annotations or not). sim.pathfinder.get_bounds() returns the AABB of the navigable space as computed by the navmesh.

sim.semantic_scene access whatever semantic annotations a dataset has.  Only a very small subset of Gibson has semantic annotations (and I forget if that has region annotations or not). sim.pathfinder.get_bounds() returns the AABB of the navigable space as computed by the navmesh.

Hi @erikwijmans ,
Thanks so much for your help. In fact, I would like to compute the area for environments. I tried two ways to compute the area.
The first way is by using sim.pathfinder.get_bounds(). I assume sim.pathfinder.get_bounds() returns [xa,ya,za] and [xb,yb,zb], which are the coordinate of diagonal points. I compute the area, denoted by bound_area, by bound_area = |xb-xa|*|zb-za|. I assume x,y,z denotes length, height and width respectively (right?).  As far as I understand, bound_area is the total area of an environment.
The second way I tried is by calling sim.pathfinder.navigable_area. I believe sim.pathfinder.navigable_area returns the area which is traversable, excluding some objects, such as furnitures.  The area it returns is named nav_area.
If my above understanding is correct, nav_area<= bound_area.
I computed bound_area and nav_area for the scene in Gibson v1. The distribution is shown below.

The figure shows that in some cases, nav_area> bound_area, which is against my understanding.  In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.
Would you mind giving me any hint on the aforementioned two inconsistence? Thanks.

Hi @erikwijmans ,
Thanks so much for your help. In fact, I would like to compute the area for environments. I tried two ways to compute the area.
The first way is by using sim.pathfinder.get_bounds(). I assume sim.pathfinder.get_bounds() returns [xa,ya,za] and [xb,yb,zb], which are the coordinate of diagonal points. I compute the area, denoted by bound_area, by bound_area = |xb-xa|*|zb-za|. I assume x,y,z denotes length, height and width respectively (right?).  As far as I understand, bound_area is the total area of an environment.
The second way I tried is by calling sim.pathfinder.navigable_area. I believe sim.pathfinder.navigable_area returns the area which is traversable, excluding some objects, such as furnitures.  The area it returns is named nav_area.
If my above understanding is correct, nav_area<= bound_area.
I computed bound_area and nav_area for the scene in Gibson v1. The distribution is shown below.

The figure shows that in some cases, nav_area> bound_area, which is against my understanding.  In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.
Would you mind giving me any hint on the aforementioned two inconsistence? Thanks.

By the way, it seems that there is a ".json.gz" and a ".glb" file for each scene. What data do they contain respectively?

By the way, it seems that there is a ".json.gz" and a ".glb" file for each scene. What data do they contain respectively?

nav_area> bound_area

That is fine.  Your bounded area is approximating the navigable surface as a flat plane.  When the navigable surface is not a flat plane (i.e. a multi-story house), having nav_area > bound_area is expected.

In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.

I do not know how those numbers were computed so I can't comment on this.

nav_area> bound_area

That is fine.  Your bounded area is approximating the navigable surface as a flat plane.  When the navigable surface is not a flat plane (i.e. a multi-story house), having nav_area > bound_area is expected.

In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.

I do not know how those numbers were computed so I can't comment on this.

nav_area> bound_area

That is fine. Your bounded area is approximating the navigable surface as a flat plane. When the navigable surface is not a flat plane (i.e. a multi-story house), having nav_area > bound_area is expected.

In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.

I do not know how Gibson computed those numbers were computed so I can't comment on this.

Thans so much for your quick answer.
After some learning, it seems that there are 3 ways to compute the area. Beside bound_area and nav_area,  another way to compute the area is by calling top_down_map = sim.pathfinder.get_topdown_map() . top_down_map corresponds the top down map of the current story. The area can be computed by _top_down_area = width(top_down_map)*length(top_down_map)*meter_per_pixel.  The relationship among bound_area , nav_area and _top_down_area is
If story=1, bound_area=top_down_area>=nav_area
If stroy>1, bound_area=top_down_area. nav_area may be larger or less than bound_area.
Is my understanding corrected?

nav_area> bound_area

That is fine. Your bounded area is approximating the navigable surface as a flat plane. When the navigable surface is not a flat plane (i.e. a multi-story house), having nav_area > bound_area is expected.

In addition, the gibson website gives an official total area for each scene. My computed bound_area is different from the officially given area by a large margin.

I do not know how Gibson computed those numbers were computed so I can't comment on this.

Thans so much for your quick answer.
After some learning, it seems that there are 3 ways to compute the area. Beside bound_area and nav_area,  another way to compute the area is by calling top_down_map = sim.pathfinder.get_topdown_map() . top_down_map corresponds the top down map of the current story. The area can be computed by _top_down_area = width(top_down_map)*length(top_down_map)*meter_per_pixel.  The relationship among bound_area , nav_area and _top_down_area is
If story=1, bound_area=top_down_area>=nav_area
If stroy>1, bound_area=top_down_area. nav_area may be larger or less than bound_area.
Is my understanding corrected?

bound_area=top_down_area (modulo rounding errors) has to be true as the size of the top_down_map image is determined by the pathfinder bounds.
The relationship between nav_area and top_down_free_area is hard to say anything concert about.  top_down_free_area makes approximates that could both increase area, i.e. a cell being marked as navigable even when < 50% of it is actually navigable, or decrease area, i.e. the environment have slight level changes even when being one floor or a cell being marked as not navigable even when most of it.
To be clear, the only of these that is the actual navigable area is nav_area.  top_down_free_area is a reasonable approximation of the navigable area for a given height Y.  Neither bound_area nor top_down_area are good approximates of anything.

bound_area=top_down_area (modulo rounding errors) has to be true as the size of the top_down_map image is determined by the pathfinder bounds.
The relationship between nav_area and top_down_free_area is hard to say anything concert about.  top_down_free_area makes approximates that could both increase area, i.e. a cell being marked as navigable even when < 50% of it is actually navigable, or decrease area, i.e. the environment have slight level changes even when being one floor or a cell being marked as not navigable even when most of it.
To be clear, the only of these that is the actual navigable area is nav_area.  top_down_free_area is a reasonable approximation of the navigable area for a given height Y.  Neither bound_area nor top_down_area are good approximates of anything.

Hi @erikwijmans , Thanks very much for your explanation.  It helps me quite a lot.
One more question is the Gibson dataset used in habitat lab (named Gibson-h here) contains about 88 environments, total 1.5GB as shown in the link.  But the official Gibson contains more than 500 environments, may up to 89 GB, as given in the website.  It seems that Gibson-h doesn't match any split of the official Gibson dataset given at the website.
May I know the relationship between Gibson-h and the official Gibson? Is it possible to use the full set of the official Gibson dataset in habitat simulator without any additional settings?
Similar question for the MP3D dataset.

Hi @erikwijmans , Thanks very much for your explanation.  It helps me quite a lot.
One more question is the Gibson dataset used in habitat lab (named Gibson-h here) contains about 88 environments, total 1.5GB as shown in the link.  But the official Gibson contains more than 500 environments, may up to 89 GB, as given in the website.  It seems that Gibson-h doesn't match any split of the official Gibson dataset given at the website.
May I know the relationship between Gibson-h and the official Gibson? Is it possible to use the full set of the official Gibson dataset in habitat simulator without any additional settings?
Similar question for the MP3D dataset.

For Gibson, we curated it as most of the reconstructions are awful.  https://arxiv.org/abs/1904.01201. You can use full Gibson, although you will need to generate pointnav episodes for those missing scenes if that is your intended use.

For Gibson, we curated it as most of the reconstructions are awful.  https://arxiv.org/abs/1904.01201. You can use full Gibson, although you will need to generate pointnav episodes for those missing scenes if that is your intended use.


Custom prefix error being confused for kebab-case error

Latest update of this library is confusing the following 2 rules:

Custom Prefix for Components (Style 02-07)
Components Selector Naming (Style 05-02)

So if you have a selector app, the error you get is the the kebab-case (05-02) error instead of the custom prefix error.  Could it be updated so that kebab-case is proper checking where app would not fail?  That way if a user would want to turn off the custom prefix rule but keep the kebab case rule, they could.

This PR is related to the issue https://github.com/mgechev/codelyzer/pull/50.

Lets track the selectors validation progress here https://github.com/mgechev/codelyzer/issues/15.


update github actions versions

Build log
Preview build with this PR (cc8b6d31909ce0ce9cc208a09d604a3ce15d42d5)

more info:cloud: Storage Free space   1.07 GiB     7.13%:open_file_folder: 0 B    CI_WORK/GitHubActions/roki-web

Build log
Preview build with this PR (4ec67c625800058b25d840c82e68ff08daf46df2)

more info:cloud: Storage Free space 972.75 MiB     6.33%:open_file_folder: 0 B    CI_WORK/GitHubActions/roki-web

Build log
Preview build with this PR (a1a8150898b74fcffc1cb2203913e47d9b3169c5)

more info:cloud: Storage Free space 849.80 MiB     5.53%:open_file_folder: 0 B    CI_WORK/GitHubActions/roki-web


Invented Characters Included in Output Stream

Using Tesseract Windows 5.0, psm=6, oem=1, eng.traineddata 2018 LSTM + legacy
As shown in the attached example files, Tesseract sometimes just adds characters out of thin air into the output stream.  Attached are:
Invented Characters Input.png - file input to Tesseract
Invented Characters Output.txt - Tesseract text output
If you look at the sixth non-blank line down in the output which begins with "STYLE" you will see after "PRODUCTION DATE" on that line there are two tildes "~~" followed by a date "06/21/15".
If you look at the input .png file you will see that the image is completely and entirely blank between "PRODUCTION DATE" and the date.  So why and how is Tesseract essentially inventing the in-between characters out of thin air?
I have seen other cases like this, more frequently when using the FAST version of the eng.traineddata.
This is not likely the same issue as I reported on the following issue regarding duplicate characters in the output stream:
https://github.com/tesseract-ocr/tesseract/issues/2738
However, it might be related in some way or other.

Invented Characters Output.txt

Note I have downloaded and experimented with the latest master code under Ubuntu and have found that the issue of the invented characters seems to be resolved, at least for the samples I have used for testing.  However, I cannot find anything in the pull request history that seems to be related to that issue.


Fingerprint not showing all unqies values in changes tab

Describe the bug
The changes tab is not showing all fingerprint values for a fingerprint label
Available options

Changes dropdown

The datasets were not in sync with the uploaded data, re-transforming the datasets fixes this issue


/f kick (error)

PocketMine-MP Crash Dump Tue Mar 29 04:10:57 UTC 2022
Error: Undefined array key ""
File: plugins/PiggyFactions.phar/src/DaPigGuy/PiggyFactions/commands/subcommands/management/KickSubCommand
Line: 24
Type: ErrorException
THIS CRASH WAS CAUSED BY A PLUGIN
BAD PLUGIN: PiggyFactions
Code:
[15] class KickSubCommand extends FactionSubCommand
[16] {
[17]     public function onNormalRun(Player $sender, ?Faction $faction, FactionsPlayer $member, string $aliasUsed, array $args): void
[18]     {
[19]         $target = $faction->getMember($args["name"]);
[20]         if ($target === null) {
[21]             $member->sendMessage("commands.member-not-found", ["{PLAYER}" => $args["name"]]);
[22]             return;
[23]         }
[24]         if (Roles::ALL[$target->getRole()] >= Roles::ALL[$member->getRole()] && !$member->isInAdminMode()) {
[25]             $member->sendMessage("commands.kick.cant-kick-higher", ["{PLAYER}" => $target->getUsername()]);
[26]             return;
[27]         }
[28]         $ev = new FactionKickEvent($faction, $target, $member);
[29]         $ev->call();
[30]         if ($ev->isCancelled()) return;
[31]
[32]         $faction->removeMember($target->getUuid());
[33]         $faction->broadcastMessage("commands.kick.announcement", ["{PLAYER}" => $target->getUsername()]);
[34]         $target->sendMessage("commands.kick.kicked");

Need to check why getRole() returns empty string

Not sure why this happens. You can only kick someone that is in your faction, and when they are in a faction, getRole() should be set. getRole() is only unset when player is not in a faction.
I'll just block the command if we aren't able to get their role. I don't want to set it to default to prevent hierarchy issues.


Add live_at field in /metatx/call_requests

Each /metatx/call_requests resource should have a live_at. The resource should only be publicly visible after the live_at time (check to be made in DB).
Users can view the call_requests that they have requested before the live_at time if they make authenticated requests to the /metatx/call_requests endpoint.

If necessary, we can have two endpoints.

Duplicates and resolves Issue https://github.com/moonstream-to/api/issues/921


JS classes extending generic TS classes should not use specified default type parameters

See minified description and example at the comment below
Here is original description involving React and JSX

~~~#14558 and #14881 already addressed this issue, however the fixes work only if legacy component does not have any properties.~~~

~~~**Code**~~~

~~~tsconfig.json~~~

```json
/* See minifed example below */
{
  "compilerOptions": {
    "module": "es2015",
    "target": "esnext",
    "jsx": "react-native",
    "strictNullChecks": true,
    "allowSyntheticDefaultImports": true,
    "allowJs": true,
    "noErrorTruncation": true,
    "lib": [
      "es5",
      "es6",
      "es7",
      "es2017",
      "dom"
    ],
    "outDir": "dist"
  },
  "include": [
    "**/*.ts",
    "**/*.tsx",
    "**/*.js",
    "**/*.jsx"
  ],
  "exclude": [
    "node_modules"
  ]
}
```

~~~hello.jsx~~~

```jsx
/* See minifed example below */
import React from 'react';

export default class Hello extends React.Component {
  render() {
    return <div>{this.props.baz}</div>;
  }
}
```

~~~index.tsx~~~

```tsx
/* See minifed example below */
import React from 'react';
import Hello from './hello';

class A extends React.Component<void, void> {
  render() {
    return (
      <div>
        <Hello baz="world">
          <div></div>
        </Hello>
      </div>
    );
  }
}
```

~~~Repo with this example: https://github.com/gagarski/tsx-jsx~~~

~~~**Expected behavior:**~~~

~~~No problems~~~

~~~**Actual behavior:**~~~

~~~TS compiler thinks that `Hello` properties type is `{}`. Thus, `Hello` component cannot be created in tsx file using JSX syntax. We can work this around using explicit `React.createComponent(...)` with type assertion or temporary properties variable but this is not very nice solution.

```
index.tsx(8,16): error TS2339: Property 'baz' does not exist on type 'IntrinsicAttributes & IntrinsicClassAttributes<Hello> & Readonly<{ children?: ReactNode; }> & Readonly<{}>'.
```

Another workaround is to use spread operator (see #16725). The bad thing that it is considered a bug.

Can confirm with latest version of TS - works fine only if JS component has no props. Really sad issue and breaks whole migration process from JS to TS :(
I beleive it can be solved via https://www.typescriptlang.org/docs/handbook/jsx.html and specifying typings for comonents but would be much easier if all JS components could be imported as any. We have 400 JS components, so migration is not 1 step for us

Just tied with latest '2.5.0-dev.20170712' and with master - same issue

Running into the exact same issue. Absolute blocker for converting our app to typescript. Can get around it with something like this:
import _VText from 'components/input/textComponent'; const VText = _VText as any;

But obviously hacky and prevents good linting practice. Any movement on this?

So I believe I understand the core of the problem. The default generics for React Component specify propShape as {}, which is what typescript assumes to be used as the default props for any jsx component. Thus, typescript validates the components, thinking that they shouldn't have any props. You can get around this by creating your own base react class:
// baseClass.ts
import React, {Component} from 'react';

export default class ReactComponent<P = any, S = any> extends Component<P, S> {

}

Your jsx components will need to extend this class instead. Not ideal.
Another solution I haven't investigated is to see if there is a way to override the generics of @types/react/index.d.ts:
interface Component<P = {}, S = {}> extends ComponentLifecycle<P, S> { }

to this:
interface Component<P = any, S = any> extends ComponentLifecycle<P, S> { }

unfortunately, you can't just override these definitions with declaration merging.

@psachs21
Yeah, seems like the underlying reason is that Typescript respects default generic types when processing JS classes extending TS generic classes.
So, here is more minimalistic example without React and JSX
generic.ts
export default class Generic<T> {
    f(x: T)  {
        return x;
    }
}

genericDef.ts
export default class GenericDef<T = {}>{
    f(x: T)  {
        return x;
    }
}

hello.js
import Generic from "./generic";

export class Hello extends Generic {}

helloDef.js
import GenericDef from "./genericDef";

export class HelloDef extends GenericDef {}

index.ts
import {Hello} from './hello';
import {HelloDef} from './helloDef';
import Generic from "./generic";
import GenericDef from "./genericDef";

let x: Generic<{x: number}> = new Hello();
// ^^ OK
let y: GenericDef<{x: number}> = new HelloDef();
// ^^
// index.ts(7,5): error TS2322: Type 'HelloDef' is not assignable to type 'GenericDef<{ x: number; }>'.
//     Types of property 'f' are incompatible.
//     Type '(x: {}) => {}' is not assignable to type '(x: { x: number; }) => { x: number; }'.
//     Type '{}' is not assignable to type '{ x: number; }'.
//     Property 'x' is missing in type '{}'.

tsconfig.json
{
  "compilerOptions": {
    "module": "es2015",
    "target": "esnext",
    "strictNullChecks": true,
    "allowSyntheticDefaultImports": true,
    "allowJs": true,
    "lib": [
      "es5",
      "es6",
      "es7",
      "es2017",
      "dom"
    ],
    "outDir": "dist"
  },
  "include": [
    "**/*.ts",
    "**/*.js"
  ],
  "exclude": [
    "node_modules"
  ]
}

A repo with this example: https://github.com/gagarski/ts-js

Does annotating your JavaScript class to specify the generic arguments help (e.g. https://github.com/Microsoft/TypeScript/issues/15251#issuecomment-294986145 )?

In a .js file does there is no mean to specify generic type arguments, that is why the compiler tries to figure them out as much as it can, and does not report errors for them. use @augments to override the generic type argument.

@billti @mhegazy
Yes, @augments helps and for the initial use-case (migrating from JS to TS) it's much easier to add @augments React.Component<any, any> to each JS file instead of rewriting the whole project to Typescript in one day.
However, default generic parameters do not seem a good source of truth for generic parameters of JS classes. Generic parameters in JS are omitted exactly because there is not mean to specify them, not because JS developer intended to rely on TS default generic parameters (he probably thought something like "Typescript? What is Typescript?" when he was writing this code). In this case the most we can rely on is any, as if there were no default generic parameters.
If it is intended behaviour and the guess about default generic parameters is right in most cases, then we probably should close this issue.

The default comes from the author of the declaration file. the default can be any. the compiler does not have a better source of information here. there is an optional type parameter, it has a default, the .js file did not specify it, then it uses that.

I still think that it's better to consider generic parameters information lost when the typed class goes through a typeless JS gap than to make inaccurate guess based on default argument, but maybe I totally misunderstand the whole purpose of default generic parameters :)
Also React typings seem correct for me (if you don't specify state type, you probably don't want state at all).

@psachs21 probably the @augments solution is much cleaner than hacking base classes in all of your JS files.

Yeah, the @augments makes the most sense to me. I was unaware that was an
option but it works great.
On Mon, Aug 21, 2017 at 7:22 PM Kirill Gagarski<EMAIL_ADDRESS>wrote:

@psachs21 https://github.com/psachs21 probably the @augments solution
is much cleaner than hacking base classes in all of your JS files.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/17104#issuecomment-323877232,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK61gEijL2V6PITOC2Eve760P9d294Edks5sahE1gaJpZM4OUyt6
.

This code is also working:
const helloProps = { baz: "world" }
<Hello {...helloProps} />

However at least it doesn't need to edit jsx files

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

I think I'm having a similar issue...
/**
 * @type {Reducer<IPoiState, any>}
 */
const poi = handleActions({
  [ADD_BOOKMARK_START]: (state) => {
    return { ...state };
  },
}, {});

The handleActions type comes from Definitey Typed and looks like...
export function handleActions<State>(
    reducerMap: ReducerMap<State>,
    initialState: State
): Reducer<State, any>;

So, I'm getting an error saying that...
Type 'Reducer<{}, any>' is not assignable to type 'Reducer<IPoiState, any>'.
  Type '{}' is not assignable to type 'IPoiState'.

Is there anyway to force the generic through?
@mhegazy


Paste option for Enter address manually

Everywhere there is an option to Enter address manually, there should be a way to "paste" text.

Verified this issue on dev app v1.8.5(324)


MySQL support

Let's also add a corresponding E2E test job for mysql, similar to postgres https://github.com/spiceai/spiceai/blob/c7a40ad7a46d1a3d3bb3a7b737c4923f6bee9d9e/.github/workflows/e2e_test_ci.yml#L342-L347


Update deprecated OS versions and actions in GitHub workflow

Update the Ubuntu and macOS versions specified in the GitHub workflow, since the currently specified versions aren't supported anymore and the action fails due to a lack of available runners. Also, update the checkout, cache, upload-artifact, and download-artifact actions due to deprecation warnings.

Thanks! Haven't updated these in a while.


Detect recursion and check for cancellation in analyser while loops

This PR fixes an infinite loop in AvaloniaPropertyAnalyzer, as was reported to us by Microsoft in #12864. I haven't been able to reproduce the issue, but by checking for analysis cancellation we can at least ensure that the loop will end when the analyser process requests it to.
I also speculatively added a recursion test to both ResolveOperationTarget (the reported method) and ResolveOperationSource, since the problem is presumably that the same operations (not symbols, operations) are somehow recursively their own parents or targets.
I don't understand how this could happen, but it seems to have at least six times since Avalonia 11 was released. This is a very small number of cases compared to the ~20 000 downloads of each version of Avalonia 11 so far, so I don't intend to spend any more time trying to work out what those six people were doing to enter this infinite loop state.
Lastly, I found a second infinite loop which can be reproduced by assigning an AvaloniaProperty field to itself. I added a recursion check to fix this. We just abandon analysis when this happens, as a warning will be emitted about the self-assignment by Microsoft's own analysers.
Breaking changes
None
Obsoletions / Deprecations
None
Fixed issues
Fixes #12864

You can test this PR using the following package version. 11.0.999-cibuild0039602-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


Can't generate private watch*() methods

A definition like queries: {'_searchTodos' : 'SELECT * FROM todos'} correctly generates a private Future-returning method, but the Stream-returning method is public.
  Future<List<TodoEntry>> _searchTodos(
      {@Deprecated('No longer needed with Moor 1.6 - see the changelog for details')
          QueryEngine operateOn}) {
    return (operateOn ?? this).customSelect('SELECT * FROM todos',
        variables: []).then((rows) => rows.map(_rowToTodoEntry).toList());
  }

  Stream<List<TodoEntry>> watchSearchTodos() {
    return customSelectStream('SELECT * FROM todos',
        variables: [],
        readsFrom: {todos}).map((rows) => rows.map(_rowToTodoEntry).toList());
  }

Yeah, this is unfortunate :/ It is a bug in the generator, but there are two released versions with that bug. Fixing this now would be a breaking change.
We could introduce a (opt-in) flag for the builder that fixes this in the next version. When moor 2.0 comes around (I've collected a bunch of other minor breaking changes in #61), we can remove that flag and always use the right name.

I added a builder flag on develop to fix this. There are some docs explaining how to enable the flag.


Shutdown actorSystem when tests are finished

Description
Shutdown actorSystem for tests which is inherited from TestKit to avoid memory leak
Related issue and scope

[ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[x] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[ ] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[ ] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #4452 into master will decrease coverage by 4.56%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4452      +/-   ##
==========================================
- Coverage   85.33%   80.76%   -4.57%
==========================================
  Files         170      170
  Lines        7929     7929
  Branches      552      552
==========================================
- Hits         6766     6404     -362
- Misses       1163     1525     +362

Impacted Files
Coverage Δ

...core/database/cosmosdb/RxObservableImplicits.scala
0% <0%> (-100%)
:arrow_down:

...core/database/cosmosdb/CosmosDBArtifactStore.scala
0% <0%> (-95.46%)
:arrow_down:

...sk/core/database/cosmosdb/CosmosDBViewMapper.scala
0% <0%> (-92.67%)
:arrow_down:

...whisk/core/database/cosmosdb/CosmosDBSupport.scala
0% <0%> (-84.62%)
:arrow_down:

...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala
4% <0%> (-52%)
:arrow_down:

...in/scala/org/apache/openwhisk/common/Counter.scala
40% <0%> (-20%)
:arrow_down:

...penwhisk/core/database/cosmosdb/CosmosDBUtil.scala
81.81% <0%> (-15.16%)
:arrow_down:

...nwhisk/core/database/cosmosdb/CosmosDBConfig.scala
94.11% <0%> (-5.89%)
:arrow_down:

...rg/apache/openwhisk/common/ForcibleSemaphore.scala
92.3% <0%> (-3.85%)
:arrow_down:

...in/scala/org/apache/openwhisk/common/Logging.scala
69.75% <0%> (-0.62%)
:arrow_down:

... and 1 more

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 7ecae17...2a0cb27. Read the comment docs.

@rabbah
I'm not sure, but as WskActorSystem has a different variable name for actor system, by mixin it will introduce bunch of code changes, I think this PR is more simpler


Moving customBaseFontSize to the end of string.

Basically, I am wondering if you would be open to having the custom font size section at the end so instead of   mobileFontSize, desktopFontSize, customBaseFontSize, customViewportMin, customViewportMax it would change to  mobileFontSize, desktopFontSize,  customViewportMin, customViewportMax, customBaseFontSize.  The reason for this change is because a user is more likely to change the viewports than the base font size.  It would remove unnecessary typing when you want to move from mobile -> tablet to tablet -> desktop.

Omg, I just saw this issue.
I'll do it, I've been thinking about it, too.


crashed when running the calculator

in the calculator, there is a crash when I connect the node "NumberSoure" and node “Addition”
QT  6.7.2
Windows 10
MSVC 2019

That looks pretty similar to #441 which I raised yesterday. https://github.com/paceholder/nodeeditor/issues/441

That looks pretty similar to #441 which I raised yesterday. #441

thanks!

I think this is fixed now. Please reopen if the problem persists


matrix-synapse: 0.31.1 -> 0.31.2

Motivation for this change
https://matrix.org/blog/2018/06/14/security-update-synapse-0-31-2/
I will open a separate PR for 18.03 backport in a moment.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Ignore this PR. Switched up a few commits.


Move to NextJS filesystem Routes

Motivations

We're getting contradictory input about how they are supposed to be handled on client-side from NextJSm and the behavior we observe in the frontend is inconsistent. This created some challenges while implementing the new admin panel.
File system routing is now the default approach promoted by NextJS, and thus the one that should receive the most support in the future.
It's an opportunity to organize the files in pages.

Risks

Not everyone likes it, it's arguably more complex to aprehend than a simple rewrite file
Regexps in paths are not supported (this can be resolved with some rewrite rules)
We need to meticulously test this to make sure we don't break anything

How

[ ] Set useFileSystemPublicRoutes to true
[ ] Re-organize all pages
[ ] Adapt the rewrites.js. We now have more flexibility there thanks to beforeFiles/afterFiles/fallback`
[ ] Make sure special routes from our custom server are correctly handled

There's a major update to come from NextJS on this topic, we probably want to dig into it before any refactor planning: https://nextjs.org/blog/layouts-rfc


Include minified version on bower

Currently being ignored on your bower.json.
Thanks!

Duplicate of #67

Read your issue #66:
https://github.com/sindresorhus/screenfull.js/issues/66
Found this stack overflow:
http://stackoverflow.com/questions/16761272/how-to-configure-grunt-to-replace-bower-dependencies-by-its-minified-versions
Pretty good arguments against you (lol) as to why include minified version:
Claiming that minifying 3rd party artifacts is user's responsibility is not only odd, but would collide with so many corporate practices it's scares me to even write about. You are not supposed to do that. The sheer blame-war if something goes south... –  ZenMaster Oct 10 '13 at 16:16
@SindreSorhus From the Angular Team, Best Practices. They specifically recommend using their minified file because they tweaked the settings just right. –  Jacob Eggers Jan 28 '14 at 1:59
--
My only request is to not ignore your minified version on your bower.json. Not everyone is familiar with JS, gulp, grunt, uglify, yeoman, etc. Especially if the people come from a Java background and the only build tool for the project is Maven. If we want to setup a simple web project, adding build annotations and whatnot will confuse non familiarized developers of the steps they need to take to run the project locally on their computer. I would say that if three issues have been raised trying to achieve the same thing, it's a clear indicative of the need and usefulness of a minified version of your awesome library.


"CLUJ-NAPOCA" is listed in the drop-down menu

Description:
"CLUJ-NAPOCA" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Cluj-Napoca" in the search bar.
Expected results
The location is listed in the drop-down menu as "Oraș CLUJ-NAPOCA, CLUJ (CLUJ-NAPOCA)".


Upgrade postgresql container from 9.4 to 9.5

Hello,
I am started with redmine 2.6.x container with was linked to postgres 9.4 container.
Current version is sameersbn/redmine:3.3.0-3 with is linked to sameersbn/postgresql:9.5-1
What is the right way to upgrade my containerized database? Make full db backup and apply it to fresh postgresql:9.5-1 container? But I am not sure, that pgdump of 9.4 is correct for 9.5
Or it possible to apply upgrade, for example as described here
Thanks

No any manual steps are required.
Just link postgresql container to new 9.5 image (sameersbn/postgresql:9.5-1) and viola!
New folder inside container
/var/lib/postgresql/9.5
and files
/var/lib/postgresql/analyze_new_cluster.sh
/var/lib/postgresql/delete_old_cluster.sh
will be created and migration from 9.4 will be performed.
Please close this issue.


haskell.packages.ghc882.http-media failed to build on 20.03

Describe the bug
Master builds just fine I think. Probably needs backporting.
To Reproduce
Steps to reproduce the behavior:

...
...
...

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

20.03 is still using ghc-8.6.5 as the main package set, so there may be lots of Haskell packages in the ghc-8.8 package set that don't work.
If you want to use ghc-8.8 packages, I suggest you use master, which is currently on LTS-15 (ghc-8.8).

Closing due to no follow-up.  Feel free to re-open if you're still interested in this.


There is no TS definition file on npm registry

Hi, I tried to use open-color with TypeScript, but something's wrong.
I have installed with yarn, and I just see that definition file has not installed.
As you know, there is a definition file on GitHub repository. I guess the definition file has not published because you have published on npm registry without running compile-templates.js. (not sure) So, I propose setting the prepublish hook for making sure generating compiled files.
Thank you!

Oh I understand. I would appreciate your work!


Improve implementation of get_available_triplets.

get_available_triplets was rewritten in a loop-less manner by means of PyTorch and NumPy

@DaloroAT do you want to add anything?


Fix float input label initial position

Summary
Use RNAv2 instead of RNAv1 for the Floating TextInput
NONE

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/21666
https://circleci.com/gh/mattermost/mattermost-mobile/21665

Artifact links:
https://output.circle-artifacts.com/output/job/8ed6f2f7-08ec-4c36-ab2f-c72fab493c32/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa
https://output.circle-artifacts.com/output/job/676878e2-bf33-4b45-aba0-bb71affe61c8/artifacts/0/tmp/artifacts/Mattermost_Beta.apk


KAFKA-6225: Adds an option to consume continuously

IMO this should actually be the default behaviour but it’s an “interface” change. This or setting the timeout to max int and exposing it as configurable.

I think the build failed on jenkins due to this infinite loop warning from FindBugs: https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/8934/findbugsResult/ . And indeed it is an infinite loop by design.
The other option could be to make the timeout in ConsumerPerformance configurable at the cli... Atm it’s hard coded to stop consuming if their haven’t been any new messages in 1 second.

It was pointed out the old consumer code path was invalid due to the iterator pattern that I hadn''t noticed (as opposed to the new consumer poll pattern). It's an option to just remove it from the old consumer code path.

Please check out this PR https://github.com/apache/kafka/pull/4818, gonna be merged soon. And KIP-281: https://cwiki.apache.org/confluence/display/KAFKA/KIP-281%3A+ConsumerPerformance%3A+Increase+Polling+Loop+Timeout+and+Make+It+Reachable+by+the+End+User

Hello is this still an issue?


New line in message breaks the email send

my $message = "asd\nasd2"

my $client = Net::SMTP.new(:server("your.server.here"), :port(587), :debug);
$client.auth($username, $password);
$client.send($from, @to, $message);
$client.quit;

with the error

Cannot resolve caller substr(Str:U: Int:D, Int:D); none of these signatures matches:
(Cool:D: *%)
(Cool:D: \from, *%)
(Cool:D: \from, \chars, *%)
(Str:D: *% --> Str:D)
(Str:D: Int:D $from, *%_ --> Str:D)
(Str:D: Int:D $from, Int:D $want, *%_ --> Str:D)
(Str:D: Int:D $from, &want, *%_ --> Str:D)
(Str:D: Int:D $from, Whatever, *%_ --> Str:D)
(Str:D: Int:D $from, Num:D $want, *%_ --> Str:D)
(Str:D: &want, *%_ --> Str:D)
(Str:D: &from, Int:D $want, *%_ --> Str:D)
(Str:D: &from, &want, *%_ --> Str:D)
(Str:D: Range:D \start, *%_ --> Str:D)
(Str:D: Regex:D, $, *%)
(Str:D: \start, *% --> Str:D)
(Str:D: \from, \want, *%_ --> Str:D)
in method get-response at /usr/local/lib/demayl/flux/bin/raku/share/perl6/site/sources/1D401641FA3CCFD20241C322CFF868A6EA34433F (Net::SMTP::Raw) line 12
in method send at /usr/local/lib/demayl/flux/bin/raku/share/perl6/site/sources/1D401641FA3CCFD20241C322CFF868A6EA34433F (Net::SMTP::Raw) line 22
in method rset at /usr/local/lib/demayl/flux/bin/raku/share/perl6/site/sources/1D401641FA3CCFD20241C322CFF868A6EA34433F (Net::SMTP::Raw) line 73
in method _check-response at /usr/local/lib/demayl/flux/bin/raku/share/perl6/site/sources/4253B30AA484C882FFC6D9F4F4857342A45DFFFE (Net::SMTP::Simple) line 244
in method send at /usr/local/lib/demayl/flux/bin/raku/share/perl6/site/sources/4253B30AA484C882FFC6D9F4F4857342A45DFFFE (Net::SMTP::Simple) line 202
in block  at test.raku line 22

Raku version

Welcome to Rakudo™ v2023.12-51-g5394496a2.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2023.12-14-gc3fea4f58.

Also \r is a problem.
See https://metacpan.org/module/Net::Cmd/source#L457

After further investigation i found that the issue is within Raku itself - joining with "\r\n" results in only "\n" :D
Here is the error from the mail server: bare <LF> received after DATA

raku -e'my @a = 1,2; say @a.join("\r\n").chars'
3

perl -E'my @a = (1,2); say length join("\r\n",@a)
4

After further investigation i found that the issue is within Raku itself - joining with "\r\n" results in only "\n" :D
Here is the error from the mail server: bare <LF> received after DATA

raku -e'my @a = 1,2; say @a.join("\r\n").chars'
3

perl -E'my @a = (1,2); say length join("\r\n",@a)
4


There are features that are not additive

Thanks for the super fast crate!
If you try to compile this crate with e.g. both the small and tiny features enabled the compilation fails.
This is a potential problem because if a user depends on two different crates that in turn both depend on machine-prime but use different features, that user will not be able to compile their program, as cargo assumes that features are additive and will only compile one version of the crate with both features enabled.
This can also result in semver-compatible changes in dependencies becoming breaking changes. If crate A doesn't change its external API, and so only bumps the patch in its version number, but changes which features it enables in machine-prime from small to tiny, a user that uses crate A and crate B, where B depends on machine-prime with small will now see breaking changes when they run cargo update.
This may also just be a normal bug that wasn't caught, in which case this is just a normal bug report :P

The exact error in the above example is this:

This may also just be a bug that wasn't caught and the features are intended to be additive, in which case this issue is just a normal bug report :P

Tagging you @JASory to ensure github lets you know about this.

I was able to implement feature precedence, going from slower to faster.
However, it will be about 2 weeks as I want to verify new parameters before I update the library.

It should be fixed now. I added some features and renamed the current ones. To get the same behaviour you need to add
version = "1.4.1"
default-features=false
features = ["lucas"]

If you want to access the internal montgomery arithmetic, you can now use the "internal" feature. And the "wide" feature, promotes the functions to u128. It simply uses a Baille-PSW test so it's not known to have no pseudoprimes under 2^128 and may be incorrect.

Cool!
If a program depends on two crates and one crate relies on the functions taking u64, and the other crate enables the wide feature, will this cause a compilation failure?

Good point. Switching the function signature seems like a bad idea. I'll just add a is_prime_128 instead, that's how I'm calling it in my other libraries anyway.


Occasionally lost highlighting

Love this plug in. Thanks.
But just noticed sometimes the highlighting bkground color get lost. My IDEA uses vertical tabs on the right hand side, which might be part of the problem?
Sorry haven't figured out a repeatable pattern to effectively reproduce the issue.

P.S.
Clicking in current editor will not bring highlighting back.
However the highlighting will come back when I click on another tab, or when I switch to another tab using Ctrl + Tab.

Upgraded to PHPStorm 2023.2 and the highlighting consistently disappears after a second :( . Happens on vertical and horizontal tabs. It was disappearing occasionally on the previous version of PHPStorm like jackliuau mentioned but this version it's happening all the time.

It seems that 2023.2 allows you to change the background of the active tab (new UI) so the plugin is no longer necessary.
Settings -> Editor -> Color Scheme -> General -> Selected Tab

To be exact it's:
Settings -> Editor -> Color Scheme -> General -> Tabs -> Selected Tab
... or just search for "Selected Tab". Finally!


Fix test_osx_platform_intel_issue_523 for macOS

Replace the hardcoded machine type, intel, with value returned by
platform.machine().

@maguro this LGTM! I'm sorry for the large delay getting to this. I just fixed up the merge conflict and will merge if this goes green.


Handling of top-level await

I'm not a modules expert by any means, and I know this is a very complex space, so I'm guessing there are good reasons for the current handling of top-level await within the dependency graph of a deferred import's module.
However, as a JS user, I find the current semantics pretty unexpected and error prone, assuming I'm understanding them correctly. In particular, it seems like an import marked with defer can still immediately trigger side effects, via this backdoor for eagerly evaluating the async portion of the dependency graph. To me, that is deeply unintuitive because, well, I'd expect a deferred import's evaluation to be (completely) deferred.
Is there anywhere I could read about the rationale, or alternatives considered, for the current handling of top-level await? How does the current approach compare to, say, throwing an error upon encountering an async module within the dependency graph of a deferred import?

As you pointed out, there are two possible alternatives:

eagerly evaluate async modules even in deferred modules subgraph
throw when using an async modules in a deferred modules subgraph

We picked the first option because it should be possible to add top-level await to a module without it being a breaking change (modulo global side effects, that with top-level await would obviously get delayed). With the current design, using top-level await has the only effect of "disabling" part of an optimization, for a specific module. If import defer threw whenever there is an async module, libraries would never be able to introduce new top-level awaits in non-major releases.

To me, that is deeply unintuitive because, well, I'd expect a deferred import's evaluation to be (completely) deferred.

Unfortunately this cannot be guaranteed even ignoring top-level await. When you do import defer * as b from "./b.js", there cannot be any guarantee that ./b.js is not evaluated because it might also be imported by some other module in your modules graph. This is a footgun we are aware of: adding defer to an import statement might be completely a no-op, and the language doesn't provide an easy way of debugging why: you need a separate tool that visualizes your modules graph and shows all the modules that import ./b.js.
For this reason, defer should be considered as a "best effort optimization" and not as a deferral guarantee: this also fits with the choice of eagerly evaluating asynchronous modules.
That said, now that we have import attributes I could see some platforms (or maybe the language itself one day) introducing something like
import defer * as b from "./b.js" with { ifAlreadyEvaluated: "throw" }

or
import defer * as b from "./b.js" with { onTopLevelAwait: "throw" }

We picked the first option because it should be possible to add top-level await to a module without it being a breaking change

Yeah, I see this. Of course, with the throw behavior, a module would be able to go from 1 to n top-level awaits without a breaking change; only adding the first top-level await would have to be considered breaking, and maybe that wouldn't be such a burdensome requirement?
However, on reflection, I'm convinced that the throw behavior is probably the wrong one anyway, because it limits the composability of different language features. Devs would now need to know that defer can't be used with an async module graph, even though it could still offer some benefit in those cases.

When you do import defer * as b from "./b.js", there cannot be any guarantee that ./b.js is not evaluated because it might also be imported by some other module in your modules graph.

I don't consider this unexpected. I think a natural mental model for devs to bring to import defer is that adding a deferred import shouldn't cause any evaluation/side effects, until the deferred import is used. If I'm understanding your scenario correctly, though, adding import defer * as b from "./b.js" wouldn't have caused b.js to be evaluated. Rather, it's simply that one deferred import can't prevent some other code from asking for b.js's immediate evaluation. To me, I think it's pretty unlikely that devs would expect a defer in one import to have that effect.
However, the partial immediate evaluation due to top-level await does mean that an  import defer can actually cause some new/immediate side effects. So, if the current behavior is desirable (and I think I'm convinced), then maybe my discomfort here has more to do with the naming of the defer keyword.
Perhaps a keyword like partialDefer or deferSync or something along those lines would be clearer, and justify the extra length?

@ethanresnick I'm closing this issue, but let's keep discussing the name/keyword in https://github.com/tc39/proposal-defer-import-eval/issues/6 :)


list index out of range

Fitting Models on Balanced Samples: 1\300Error: Unable to coerce to Series, length must be 1: given 52
Fitting Models on Balanced Samples: 1\300Error: Unable to coerce to Series, length must be 1: given 52
Fitting Models on Balanced Samples: 1\300Error: Unable to coerce to Series, length must be 1: given 52
Fitting Models on Balanced Samples: 1\300Error: Unable to coerce to Series, length must be 1: given 52```
Average Accuracy: nan%

I don't know what this means.
n majority: 7619
n minority: 26

This got resolved in pull request #50


Reusing workflows

I just found out that reusable workflows exist, which I think would be good for us. In all 3 repos we have the identical citation_check.yml workflow and an almost identical test_suite.yml. So it's a bit of a hassle that we have to edit all 3 when making changes. We could host these common workflows in mesh-adaptation-docs and make smaller workflows in the 3 repos that would call them. What do you think @jwallwork23?

Yeah I must admit the recent changes did make me think of the "shotgun surgery" bad "code smell" that people refer to in software engineering. I hadn't heard of this before, sounds like a great idea!

@ddundo Would you mind doing the same for the Docker build workflows? They have the same pattern and we are going to bring UM2N under the mesh-adaptation organisation, which will require another bespoke Docker build, implying another such workflow.

Sure :)

In which case I guess more sensible filenames would be docker_petsc-parmmg.yml and docker_firedrake-parmmg.yml


Replace goog.getUid with ol.getUid

As discussed in #5615. Fixes #5615.
A simplified version of the goog function, as I don't think there's any need to cater for 2 OLs in one page. So the uid property is simply called 'ol_uid'.

Very nice. Thanks @probins.


spider crawls first desired link successfully with proper naming conv…

First half of crawler, pushing second half by COB to scrape https://samm.dsca.mil/policy-memoranda/PolicyMemoList-All
Tested locally using
 $env:PYTHONPATH = "$(Get-Location)"
 $CRAWLER_DATA_ROOT = "./test-samm"
New-Item -ItemType Directory -Force -Path $CRAWLER_DATA_ROOT| Out-Null
$prevManifestFile = Join-Path $CRAWLER_DATA_ROOT "pre-manifest.json"
New-Item -ItemType File -Force -Path $prevManifestFile | Out-Null
$sammSpider = "dataPipelines/gc_scrapy/gc_scrapy/unfinished/samm_spider.py"
$outputFile = Join-Path $CRAWLER_DATA_ROOT "output.json"
scrapy runspider $sammSpider `
-a download_output_dir=$CRAWLER_DATA_ROOT `
-a previous_manifest_location=$prevManifestFile `
-o $outputFile

Ripped the @static method from stigg_spider so open to refactoring this method to match desired outcome

Finished second half of crawler, just submitting new PR to pull entire finished Samm_spider


SQL Config Discussion

Discuss changes for SQL Config to generate spec for #215 .

References to configStorage in the codebase:
steem/instance.py:2
steem/commit.py:23
steem/cli.py:33
steem/dex.py:1
steem/steemd.py:1
steem/wallet.py:6

Does it store just 1 account/creds or does it have multi account support?

Multi-account.

I propose we leave the account and defaults functionality in place, however remove any references to nodes from the storage and simply offer a default of https://api.steemit.com if none are specified by the user. And properly handle taking a list or single node.

for reference, internally we hardly use the defaults:

In a grep of steem/, the only defaults (besides accounts) referenced are:
default_vote_weight:2x
prefix:1x

Some thoughts, from the perspective that steem-python (particularly core) functions need to be seriously simplified and made more reliable if a wallet is ever going to be built on it:

Too much sugar, we need a solid and stable library; keys like "categories_sorting": "trending", and "default_vote_weight": 100.0, seem extraneous.
File-based config must be optional; one should be able to use steempy without writing to disk
How API nodes are handled is obtuse; agree it should be more explicit.
If we're removing this from sqlite we should probably first block writing to it, but continue to read (while printing deprecation messages), so existing scripts are not interrupted.
A specific storage should not be assumed.. there should be a single class which handles reading/writing config to sqlite (thus easily switched to e.g. json). If this is not the case we need it.

1 - Are you thinking that all of the config defaults should be pulled as too much sugar, or just those keys in particular?
2 - I like the thought of approaching configs through command line arguments and env vars in a .conf like file.
3 - This seems a reasonable enough approach short term. In the long term, would we want nodes to be specified through the same approach as the config values?
4 - Agreed. Functionality should be storage type agnostic.

#220 and #221 are issues created in response to this issue. I think they are sufficient based on discussion from this issue to close it.


feat(certs): use actual v1 spec for certs

Motivation
In #204, api version of the cert resources was updated to v1. This was insufficient because v1 has different spec from v1alpha1
This MR finishes the work that #204 and @lhotari started.
Modifications
Changed the spec of certs to match v1 cert manager spec.
Verifying this change

[ ] Make sure that the change passes the CI checks.

@smazurov Thanks for the contribution. I created a PR to first revert #204 changes so that we have time to prepare a better solution for migrating to use cert-manager.io/v1 api version in a backwards compatible way.
It seems that the backwards compatible migration might require more changes. For new installations ({{- if .Release.IsInstall }}) it should be fine to use the cert-manager.io/v1 api version. For existing installations, I'm not exactly sure to handle the backwards compatibility.
cert-manager documentation about the deprecated api versions: https://cert-manager.io/docs/installation/upgrading/remove-deprecated-apis/#upgrading-existing-cert-manager-resources

assuming kube is aware of both apis, upgrading is straightfoward. So the change is fine as long as the new spec for v1 is actually followed. Once cert-manager is upgraded to v1.6+, they dropped support for alpha versions, so it won't let you upgrade.

Is the PR still in progress? Any estimation of when it will be released? I have been facing issues with TLS and if I'm going to use the old version v1.1.0 then it's not working with the new pulsar 2.9.0.  Any idea which config will work with the newer pulsar version?

I am going to merge this now, and then I'll test it in https://github.com/apache/pulsar-helm-chart/pull/306


ISO 8601 with Timezone

Hi Soywiz,
How easy would it be to support ISO 8601 with Timezone, e.g.
2011-12-03T10:15:30+01:00 or
2011-12-03T10:15:30+0100
I would also be willing to implement this, but am unsure how to do it right 👍

Isn't this one? https://github.com/korlibs/klock/blob/f5c4f05a5a875da7d06a919ba8e8f1263989bc12/klock/src/commonMain/kotlin/com/soywiz/klock/DateFormat.kt#L11

I think the Z does only work fit ISO8601 Git UTC or does it also parse +01:00 or +0100? In my Tests lastly it didn’t work.

I'm having this issue on iOS only... trying to format like this: YYYY-MM-dd'T'HH:mm:ss'Z and I get output like this: 2021-09-DDT22:23:18Z
On the android side this does work though for some reason.


🐛 Bug Report: Okta 'additionalScopes' not reflected during auth

📜 Description
When adding additional scopes for Okta authentication as described in the docs, the configured scopes don't get reflected in the sign-in flow.
👍 Expected behavior
Adding the additionalScopes parameter will send the specified scopes with the sign-in request.
👎 Actual Behavior with Screenshots
The additional scopes are not sent with the sign-in request.
app-config.yaml

Parameters sent during sign-in:

...&scope=openid email profile offline_access&state=...

👟 Reproduction steps

Follow the instructions in the docs to configure Okta with additionalScope, e.g.,

    okta:
      development:
        clientId: <your_client_id>
        clientSecret: <your_client_secret>
        audience: https://<your-domain>.okta.com
        additionalScopes: groups

Sign in with Okta

📃 Provide the context for the Bug.
We would like to send additional scopes in order to receive custom claims in the response.
Problem
During sign-in, on the frontend:

In packages/app-defaults/src/defaults/apis.ts, the factory creates the Okta API via OktaAuth.create
In packages/core-app-api/src/apis/implementations/auth/okta/OktaAuth.ts, OktaAuth.create:

reads defaultScopes from options, and defaults to ['openid', 'email', 'profile', 'offline_access']
creates OAuth2 via OAuth2.create and passes it the defaultScopes

In packages/core-app-api/src/apis/implementations/auth/oauth2/OAuth2.ts, OAuth2.create:
i.  reads defaultScopes from options
ii. creates RefreshingAuthSessionManager and passes it defaultScopes
In packages/core-app-api/src/lib/AuthSessionManager/RefreshingAuthSessionManager.ts, it creates SessionScopeHelper and passes it defaultScopes, which it keeps for later

During authentication:

In packages/core-components/src/layout/SignInPage/SignInPage.tsx, login calls OAuth2.getBackstageIdentity
In packages/core-app-api/src/apis/implementations/auth/oauth2/OAuth2.ts, getBackstageIdentity calls RefreshingAuthSessionManager.getSession
In packages/core-app-api/src/lib/AuthSessionManager/RefreshingAuthSessionManager.ts, getSession calls SessionScopeHelper.getExtendedScope, which effectively returns defaultScopes
In packages/core-app-api/src/lib/AuthSessionManager/RefreshingAuthSessionManager.ts, getSession calls DefaultAuthConnector.createSession and passes it scopes it got from SessionScopeHelper.getExtendedScope
In packages/core-app-api/src/lib/AuthConnector/DefaultAuthConnector.ts, createSession calls showPopup/executeRedirect, and passes it options.scopes

Summary

additionalScopes gets combined with the defaultScopes "openid profile email" and set as scope in the Strategy object in plugins/auth-backend-module-okta-provider/src/authenticator.ts
OktaAuth.create in packages/core-app-api/src/apis/implementations/auth/okta/OktaAuth.ts provides the defaultScopes as ['openid', 'email', 'profile', 'offline_access'] during authentication on the frontend

🖥 Your Environment
Browser (Chrome)
Version 125.0.6422.61 (Official Build) (arm64)

yarn backstage-cli info
OS:   Darwin 22.4.0 - darwin/arm64
node: v18.16.0
yarn: 1.22.19
cli:  0.25.1 (installed)
backstage:  1.22.2
Dependencies:
@backstage/app-defaults                                          1.4.7
@backstage/backend-app-api                                       0.4.1, 0.5.10
@backstage/backend-common                                        0.18.3, 0.19.10, 0.20.1
@backstage/backend-dev-utils                                     0.1.3
@backstage/backend-openapi-utils                                 0.1.2
@backstage/backend-plugin-api                                    0.5.4, 0.6.9
@backstage/backend-tasks                                         0.5.14
@backstage/backend-test-utils                                    0.2.10
@backstage/catalog-client                                        1.5.2
@backstage/catalog-model                                         1.4.3
@backstage/cli-common                                            0.1.13
@backstage/cli-node                                              0.2.2
@backstage/cli                                                   0.25.1
@backstage/config-loader                                         1.6.1
@backstage/config                                                1.1.1
@backstage/core-app-api                                          1.12.0
@backstage/core-compat-api                                       0.1.1
@backstage/core-components                                       0.12.5, 0.13.10, 0.14.0
@backstage/core-plugin-api                                       1.9.0
@backstage/dev-utils                                             1.0.26
@backstage/errors                                                1.2.3
@backstage/eslint-plugin                                         0.1.4
@backstage/frontend-plugin-api                                   0.5.0, 0.6.0
@backstage/integration-aws-node                                  0.1.8
@backstage/integration-react                                     1.1.23
@backstage/integration                                           1.8.0
@backstage/plugin-app-backend                                    0.3.57
@backstage/plugin-app-node                                       0.1.9
@backstage/plugin-auth-backend-module-atlassian-provider         0.1.1
@backstage/plugin-auth-backend-module-gcp-iap-provider           0.2.3
@backstage/plugin-auth-backend-module-github-provider            0.1.6
@backstage/plugin-auth-backend-module-gitlab-provider            0.1.6
@backstage/plugin-auth-backend-module-google-provider            0.1.6
@backstage/plugin-auth-backend-module-oauth2-provider            0.1.6
@backstage/plugin-auth-backend-module-oauth2-proxy-provider      0.1.1
@backstage/plugin-auth-backend-module-okta-provider              0.0.2
@backstage/plugin-auth-backend                                   0.20.3
@backstage/plugin-auth-node                                      0.2.19, 0.4.3
@backstage/plugin-catalog-backend-module-incremental-ingestion   0.4.13
@backstage/plugin-catalog-backend-module-msgraph                 0.5.16
@backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.6
@backstage/plugin-catalog-backend                                1.16.2
@backstage/plugin-catalog-common                                 1.0.20
@backstage/plugin-catalog-graph                                  0.3.3
@backstage/plugin-catalog-import                                 0.10.5
@backstage/plugin-catalog-node                                   1.6.1
@backstage/plugin-catalog-react                                  1.9.3
@backstage/plugin-catalog                                        1.16.1
@backstage/plugin-events-node                                    0.2.18
@backstage/plugin-github-actions                                 0.6.10
@backstage/plugin-home-react                                     0.1.7
@backstage/plugin-home                                           0.6.1
@backstage/plugin-org                                            0.6.19
@backstage/plugin-permission-backend                             0.5.32
@backstage/plugin-permission-common                              0.7.12
@backstage/plugin-permission-node                                0.7.20
@backstage/plugin-permission-react                               0.4.20
@backstage/plugin-proxy-backend                                  0.4.7
@backstage/plugin-scaffolder-backend-module-azure                0.1.1
@backstage/plugin-scaffolder-backend-module-bitbucket            0.1.1
@backstage/plugin-scaffolder-backend-module-gerrit               0.1.1
@backstage/plugin-scaffolder-backend-module-github               0.1.1
@backstage/plugin-scaffolder-backend-module-gitlab               0.2.12
@backstage/plugin-scaffolder-backend                             1.20.0
@backstage/plugin-scaffolder-common                              1.4.5
@backstage/plugin-scaffolder-node                                0.2.10
@backstage/plugin-scaffolder-react                               1.7.1
@backstage/plugin-scaffolder                                     1.17.1
@backstage/plugin-search-backend-module-catalog                  0.1.13
@backstage/plugin-search-backend-module-pg                       0.5.18
@backstage/plugin-search-backend-node                            1.2.13
@backstage/plugin-search-backend                                 1.4.9
@backstage/plugin-search-common                                  1.2.10
@backstage/plugin-search-react                                   1.7.6
@backstage/plugin-search                                         1.4.5
@backstage/plugin-tech-radar                                     0.6.12
@backstage/plugin-user-settings                                  0.8.0
@backstage/release-manifests                                     0.0.11
@backstage/test-utils                                            1.4.7
@backstage/theme                                                 0.2.19, 0.4.4, 0.5.1
@backstage/types                                                 1.1.1
@backstage/version-bridge                                        1.0.7

👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

We have the same issue, and after some investigations we are thinking it was introduced by #21325
Hi @ataylorme / @Josh-Uvi could you help to correct me for the below finding
// Previously `plugins/auth-backend/src/providers/okta/provider.ts` would combine
// default and additional scopes when start authentication,
// and then pass combined scope to `executeRedirectStrategy` to override the value from http request.
async start(req: OAuthStartRequest): Promise<OAuthStartResponse> {
  const scope = this.combineScopeStrings(req.scope, this.additionalScopes);
  return await executeRedirectStrategy(req, this.strategy, {
    accessType: 'offline',
    prompt: 'consent',
    scope: scope,
    state: encodeState(req.state),
  });
}

// Currently `plugins/auth-backend-module-okta-provider/src/authenticator.ts`
// will save combined scope to `OktaStrategy` only, it will not pass to `helper` when start authentication.
// By default, the value will always read from http request which is hardcoded in
// `packages/core-app-api/src/apis/implementations/auth/okta/OktaAuth.ts`
async start(input, helper) {
  return helper.start(input, {
    accessType: 'offline',
    prompt: 'consent',
  });
},

Yep, these are indeed ignored since they're only configured as part of the strategy. I've got a fix for this on the way for all providers in #24743, but not sure whether we'll get that into the 1.28 release or not.

Hi @Rugvip thanks for the support, its verified `'additionalScopes' is working now for Okta provider.

Thanks, closing!


Umbraco 8.2 compatibility

Hi!
I've just update my website to U8.2
I think new functionalities of the RTE in v8.2 breaks the package giving this error (when a RTE is used)
System.NullReferenceException: Object reference not set to an instance of an object.
   at Umbraco.Web.PropertyEditors.RichTextPropertyEditor.RichTextPropertyValueEditor.FromEditor(ContentPropertyData editorValue, Object currentValue) in d:\a\1\s\src\Umbraco.Web\PropertyEditors\RichTextPropertyEditor.cs:line 117
   at Our.Umbraco.DocTypeGridEditor.Helpers.DocTypeGridEditorHelper.ConvertValue(String id, String contentTypeAlias, String dataJson)
   at Our.Umbraco.DocTypeGridEditor.Helpers.DocTypeGridEditorHelper.<>c__DisplayClass0_0.<ConvertValueToContent>b__0()
   at Umbraco.Core.Cache.AppCacheExtensions.<>c__DisplayClass5_0`1.<GetCacheItem>b__0() in d:\a\1\s\src\Umbraco.Core\Cache\AppCacheExtensions.cs:line 62
   at Umbraco.Core.Cache.FastDictionaryAppCacheBase.<>c__DisplayClass21_0.<GetSafeLazy>b__0() in d:\a\1\s\src\Umbraco.Core\Cache\FastDictionaryAppCacheBase.cs:line 285
--- End of stack trace from previous location where exception was thrown ---
   at Umbraco.Core.Cache.HttpRequestAppCache.Get(String key, Func`1 factory) in d:\a\1\s\src\Umbraco.Core\Cache\HttpRequestAppCache.cs:line 81
   at Umbraco.Core.Cache.AppCacheExtensions.GetCacheItem[T](IAppCache provider, String cacheKey, Func`1 getCacheItem) in d:\a\1\s\src\Umbraco.Core\Cache\AppCacheExtensions.cs:line 62
   at Our.Umbraco.DocTypeGridEditor.Helpers.DocTypeGridEditorHelper.ConvertValueToContent(String id, String contentTypeAlias, String dataJson)
   at ASP._Page_app_plugins_doctypegrideditor_render_DocTypeGridEditor_cshtml.Execute() in ..\Webproject\app_plugins\doctypegrideditor\render\DocTypeGridEditor.cshtml:line 26
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
   at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
   at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
   at System.Web.Mvc.RazorView.RenderView(ViewContext viewContext, TextWriter writer, Object instance)
   at System.Web.Mvc.BuildManagerCompiledView.Render(ViewContext viewContext, TextWriter writer)
   at Umbraco.Web.Mvc.ProfilingView.Render(ViewContext viewContext, TextWriter writer) in d:\a\1\s\src\Umbraco.Web\Mvc\ProfilingView.cs:line 25
   at System.Web.Mvc.HtmlHelper.RenderPartialInternal(String partialViewName, ViewDataDictionary viewData, Object model, TextWriter writer, ViewEngineCollection viewEngineCollection)
   at System.Web.Mvc.Html.PartialExtensions.Partial(HtmlHelper htmlHelper, String partialViewName, Object model, ViewDataDictionary viewData)
   at System.Web.Mvc.Html.PartialExtensions.Partial(HtmlHelper htmlHelper, String partialViewName, Object model)
   at ASP._Page_Views_Partials_grid_editors_Base_cshtml.Execute() in ..\Webproject\Views\Partials\grid\editors\Base.cshtml:line 20

Me too... same problem here. Even when i'm using a textarea in stead of a rte.

I'm also experiencing this exact same issue.

Same problem here. RTE seems to crash DTGE.

The exception is coming from https://github.com/umbraco/Umbraco-CMS/commit/03a4affbde4948afbcccc7fbea6a2327c97f8c40#diff-99ef99ed499fd7e582df2066ec073f41R89 As this is coming from the front end where there is no Umbraco user so CurrentUser is null apart from when in preview mode
Attached is a modified 8.2 Umbraco.Web.dll with a fix
Umbraco.Web.dll.zip

Good find @Jeavon
I'm curious if something can be done in DTGE to make it work with 8.2. Do you know if there is something we can do, or do we just have to wait for 8.2.1 (assuming your PR gets merged)

The issue is already on Umbraco bugfix list for 8.2.1 to be released soon, so it will be fixed. I used the build with the fix, and didn't see any other problems continuing using the same version of DTGE

The issue is already on Umbraco bugfix list for 8.2.1 to be released soon, so it will be fixed. I used the build with the fix, and didn't see any other problems continuing using the same version of DTGE

I can't see that here: https://our.umbraco.com/download/releases/821   - how can you tell it will be part of 8.2.1?
Is there a way to get the PR by @Jeavon noticed by the HQ? It doesn't seem to have any versions assigned to it.

No you are right, I mistook it for another issue. It's not there.

Can someone on Twitter perhaps notify Umbraco about it? :)

Don't worry, it will be included in v8.2.1

Good find @Jeavon
I'm curious if something can be done in DTGE to make it work with 8.2. Do you know if there is something we can do, or do we just have to wait for 8.2.1 (assuming your PR gets merged)

I don't think so, I had a quick look and I don't see a workaround. Until 8.2.1 I suggest people use the patched DLL I attached

When I add a "Embed"-grideditor (a Youtube video for example) the property the property data is show instead of the video html. Is this related to the bug with the RTE editor?
When I use the DLL that Jeavon provides, i still having the problem with rendering embeds

Hi @mcl-sz, are you using the default Embed grid editor in Umbraco? That does not have anything to do with DTGE. Or are you embedding a macro in an RTE inside a DTGE?

Hi @skttl! No, when DTGE is installed, the Embed-editor (the grid control, not RTE) that's shiped with Umbraco doesn't work anymore.
This is the model without DTGE installed:

And this with DTGE installed:

The Value property disapears after installing DTGE

I encounter the same issue on v8.3 now. I've updated from 8.1.x to 8.3. All my RTE's break in doctype grid editor. Can someone point me in the right direction for a fix?

Hi Frans,
The cause indeed turned out not to be at all in DTGE but in the Grid partial "Embed" that is included with Umbraco. The structure of the Embed has changed but the partial supplied by Umbraco has not been updated for this.
Just try to add a Embed in a fresh Umbraco installation without having  DTGE installed, then the same error will occur. We created a new Grid partial view for Embed elements meeting our own requirements.

Just to be clear... I only have a string and RTE in the doctype. Or does DTGE use Embed to render the doctypes?

DTGE does not use the Embed partial, but it's own.
Looking at the history, it seems to be merged 22/10 which was before 8.3 https://github.com/umbraco/Umbraco-CMS/commits/v8/dev/src/Umbraco.Web/PropertyEditors/RichTextPropertyEditor.cs

@FransdeJong are you sure your update went well?
I just tried on 8.3 and it works here.

It's a cloud project so I assume it went well.... But yeah... Assumtion is...
I'll investigate further.
Thanks for looking in to this

Mine was too, but only tried locally :)
Let me know if you find anything!

Umbraco Cloud forgot to update Umbraco.Web... Now all is fine


Add Microsoft.CodeAnalysis.PublicApiAnalyzers (OSOE-345)

See here. This is basically approval testing for public APIs.
Only useful for projects with an important published interface, like Helpful Libraries, especially libraries. So maybe we shouldn't add the analyzer package, just some common config and then you may add the analyzer to your own project only. However, the only available configuration is a single line.
Jira issue

This would be the same as "Baseline version validator" under https://github.com/Lombiq/GitHub-Actions/issues/45. And we don't use that because of: https://github.com/Lombiq/GitHub-Actions/issues/45#issuecomment-1240568296


Checkpoint Challenge required....

Please follow the guide below

Issues submitted without this template format will be ignored.
You will be asked some questions and requested to provide some information, please read them carefully and answer completely.
Put an x into all the boxes [ ] relevant to your issue (like so [x]).
Use the Preview tab to see how your issue will actually look like.

Before submitting an issue, make sure you have:

[ ] Updated to the latest version
[ ] Read the README and docs
[ ] Searched the bugtracker for similar issues including closed ones

Purpose of your issue?

[X ] Bug report (encountered problems/errors)
[ ] Feature request (request for a new functionality)
[ X] Question
[ ] Other

The following sections requests more details for particular types of issues, you can remove any section (the contents between the triple ---) not applicable to your issue.

For a bug report, you must include the Python version used, code that will reproduce the error, and the error log/traceback.
Paste the output of python -V here:
Code:
# Example code that will produce the error reported
from instabot import Bot

bot = Bot()
bot.login(username="user", password="pass")
followers = bot.get_user_followers(bot.user_id)

Error/Debug Log:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero

Running the bot off a VPS, whenever checkpoint challenge occurs and user clicks "this was me" then re logs in a new challenge occurs. Im guessing that this is because the code randomizes what kind of device it logs in from?

Hello, has this situation been updated? I'm having the same problem, instagram asks for login confirmation and I can't access the account.
2020-02-03 13:47:33,997 - DEBUG - Responsecode indicates error; response content: b'{"message": "challenge_required", "challenge": {"url": "https://i.instagram.com/challenge/6525713726/yCJm9h2FwX/", "api_path": "/challenge/6525713726/yCJm9h2FwX/", "hide_webview_header": true, "lock": true, "logout": false, "native_flow": true}, "status": "fail", "error_type": "checkpoint_challenge_required"}'
2020-02-03 13:47:34,000 - ERROR - Request returns 400 error!
2020-02-03 13:47:34,001 - INFO - Instagram's error message: challenge_required
2020-02-03 13:47:34,003 - INFO - Error type: checkpoint_challenge_required
2020-02-03 13:47:34,004 - INFO - Checkpoint challenge required...

getting this error as well, login info is correct, 2fa is not enabled on ig, what else could be the issue? even after manually clearing challenge it just repeats

Your password needs to be changed. Change your password. Remove the secret file and the json cookie file and you're good to go.

@bruvv 'Remove the secret file and the json cookie' Remove what where? I have the same issue..

encountered same error here, any solution?

Same error here

Please see https://github.com/instagrambot/instabot/issues/1293#issuecomment-610935629 for a quick workaround.


Bug on define labels

In some circumstances, when assigning labels to columns on the define function, label parameter is not being honored.  Still not sure of the circumstances.

This was because the user was not setting the first parameter to attach the define to a table.  So the define was not getting applied at all.  No problem with the code.

This was because the user was not setting the first parameter to attach the define to a table.  So the define was not getting applied at all.  No problem with the code.


http_listener_enabled not working for me

Hello !
In my beanstalk env, my load balancer listens on https. I would like to listen on http too, to redirect http -> https. I know, there is already a patch on it, and I'm using the http_listener_enabled parameter.
But... It doesn't work for me.
Here a screenshot of AWS console 👍

And terraform :
module "elastic_beanstalk_environment" {
  source                              = "git::https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment.git?ref=tags/0.4.8"

...

  healthcheck_url                      = "${var.healthcheck_url}"
  http_listener_enabled	               = true
  loadbalancer_type                             = "application"
  loadbalancer_certificate_arn        = "${aws_acm_certificate.cert.arn}"

  loadbalancer_security_groups      = ["${module.metabase_sg.this_security_group_id}"]
  loadbalancer_managed_security_group = "${module.metabase_sg.this_security_group_id}"

}

tfsate :
"all_settings.232565.namespace": "aws:elbv2:listener:default",
"all_settings.232565.resource": "",
 "all_settings.232565.value": "false",

What am I doing wrong?
Thanks

@pabardina Have you tried specifying true as string "true" instead of boolean true?

please try the latest version https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/releases/tag/0.44.0


[Question] SBUS to PWM converter

Would this library be suitable for creating an SBUS to PWM converter to control 5 servos on an airplane?
There doesn't seem to be many options for compact 5 (or 6) channel PWM receivers. The DR4 is the right size but only 4 channels while the 8 channel RX is physically too big for my model.
I'm contemplating using an XSR along with a Trinket (or something similar) to get 5 channels in a smallish footprint.

Yes. I've done this quite a lot with the tested boards (Teensy 3.x, Teensy LC, and STM32L4 Ladybug). Keep in mind the board you would like to use would need to have a hardware serial port supporting 8E2 and inverted logic. Also the board would need to have PWM capable pins and PWM library support.


[RFC] NestJS based API

Summary
New, fully extensible, more flexible, hard-typed API that has autogenerated API specs with Swagger.
Motivation
Current API is extensible for new features but modifying existing endpoints might be a little bit troublesome. Moreover, it contains a lot of legacy code that should be reviewed and refactored. It's lacking some useful features like proper logging or autogenerating OpenAPI Specification, not mentioning code coverage with tests, docs and typing. The new API based on easier to maintain NestJS is the answer to our needs. It needs to provide a more separated and easy to use layers for data transformation and multi-platform support.
Drawbacks

a lot of work on rewriting
backward compatibility for old modules might be a little bit troublesome
noticeably higher entry-level for devs

Q&A
What about modules written for current version of vue storefront api?
New API should provide a wrapper that would enable old modules to work but new modules structure will most likely be much different.
Does development of new API mean leaving old API on it's own?
No, the old API will still be supported until the new version will be fully featured, stable and production-ready. Security fixes for old API will be provided even afterward.

Please, let us know what you think, what features you would like to see implemented and what are your concerns?

DON’T KNOW. But some insights from my side:

NestJS is cool because Kamil did a great job bulding this thing and maybe would help us promoting the project across hiscommunity
I 100% agree with Sander: one single update
guys we can have “alternate” API till we feel it’s stable enought to replace the core vue-storefront-api (the  same way we did with indexers); API is not changing a lot, it’s pretty stable
maybe some PoC for 2-3 days? showing how it could look like?
it’s for sure not a priority for 2.0
-but it can be done in parallel/in the unspecified future as long as we’ll keep up with the endpoint spec - and I think we’ll (@lromanowicz) as it’s not a point here - to change the data formats, whatever; just rewrite the code right?


Increase the sensitivity of the microphone

Correspondents report that the audio level of the broadcast is low, even raising the sensitivity to 15db. Firmware v0.18

In my opinion, this is the maximum value that can be achieved in radio.
Was it with the internal or external microphone?
I recommend an external microphone of better quality than the 3 euro versions.
K-type 780 Mic. Costs 6 to 7 euros and works very well for me.

I didn't test with an external microphone. I own a Baofeng microphone made by Abbree. I'm going to try it out. Do you leave the value of the microphone gain at its maximum?

Yes. Max value.

Thank you very much.


sh compile bug

compilation terminated.
compile_ops.sh: 10: compile_ops.sh: /usr/local/cuda-10.0/bin/nvcc: not found
g++: error: ./grouping/tf_grouping_g.cu.o: No such file or directory
compile_ops.sh: 13: compile_ops.sh: /usr/local/cuda-10.0/bin/nvcc: not found
g++: error: ./sampling/tf_sampling_g.cu.o: No such file or directory

I encountered the same problem, did you resolve it?

no, still cannot run

Hi，@cuge1995 , sorry for the late response, please try an operation ':set ff=unix' after using vim/vi. If still doesn't work, you need double-check your CUDA 10 is successfully installed.


South Carolina Onboarding - Validate Test Data

Acceptance Criteria

[ ] Created and sent data using fake data generator
[ ] Created and sent data using synthesized data generator
[ ] Confirmed with STLT that data passes validation

To Do

[ ] RS engineer: update this ticket with comments with every interaction with receiver
[ ] RS team member who originates this ticket: add any dependencies, as needed
[ ] RS team member who originates this ticket: complete the following when creating this Issue.

[ ] Pipelines: Onboarding & Operations (New)
[ ] Labels: "Onboarding-ops" and "Receiver" and state label
[ ] Epics: [select the epic for this API onboarding sender]

Notes from the last meeting on 9/28/2023
@LaFreda1 did we decide who will replace Don on this?

@sliu1000 no, as I mentioned at sprint planning I am waiting for CDC to let us know about SC. We will leave them in the backlog until we can get a response.

Update and Context to this ticket: South Carolina reached back out (Greg Fowler, an analyst programmer). Max and Glenn met with him on 9/28/23. The conversation was generally focused around RS, asking questions about future states and potential pilot ideas. However, Greg is not a decision maker and it felt more like a general inquiry rather than a STLT read to take an active step. Glenn is going to set up a conversation in the future to continue the dialogue, but I do not anticipate this STLT will be onboarding any time soon.


Add https://github.com/AlexC-ux/Arina-OSINT

Added in 9c31ead1f90a0ae3fef9c85dbc5266cceeba2ecd

Thank you for your support!
Publishing my project in your repository shows that my work is not in vain.
printf("Thanks, %s", username);

Thank you for your job! 👍


client-cookie logout not working

Hello,
I am working on a Single Page Application and use mod_auth_openidc on my reverse proxy. Now the login is working fine. I use
OIDCSessionType client-cookie
to prevent a stateful proxy. The problem that I have is, that the logout mechanism is not working as expected with this setting. For logout I redirect to http://localhost/xxx/redirect_uri?logout=http%3A%2F%2Flocalhost. The redirect works and now I see the apache default page. Also the session in Keycloak (OP that I use) is removed for the user. But if I access the application again, the old session gets restored somehow (I dont need to login). What confuses me is, that the initial page-load of my app after logout does not contain a session-cookie, but mod_auth_openidc can restore the session nevertheless.
If I use
OIDCSessionType server-cache
logout works as expected (login is required to access app after logout).
Any idea what is the problem here and how I can solve it?
Thank you!

please attach a sever debug log and a browser trace of the client-cookie event

This should be debug-log:
error_logout.txt

it depends on your browser; for Firefox there's e.g. Live Headers, for IE there's Fiddler etc.

it appears that indeed when OIDCSessionType client-cookie is used and cookies are chunked because of the size, those cookies wouldn't correctly be cleared; that is fixed in the commit above on the "feature" branch, to be released in 2.2.0; as a workaround today you could try and minimize the number of claims that end up in the session so the cookie does not need to be chunked

Thanks for your response! I will try to limit the claims or find a workaround until 2.2.0 is released


Peers Module

There is no existing PG abstraction for data about node peers, so for now we'll create a new PG Peers module that exposes the data available from Lotus apis. This will drive some of the web UI in addition to being generally available for any client.

@jsign, do you think we should implement this with a PG module that defines some simple data models and methods, or should we just pass the Lotus API straight into a gRPC service and implement it there?

Sounds like a better long-term plan to build the Peer Module abstraction. Most prob because will make things easier in the future to define some general-level API that a Filecoin node should provide. (To support other impl than Lotus).

Cool sounds like a plan.


Multiple foward declarations of menuItem-callbacks when reusing the same callback in different menuItems

Hi Dave,
I've tried to re-use an already existing menuItem-callback in several menuItems. The automatic code creation produces repeats of the same callback forward declaration in XYZ_menu.h which of course leads to a complier error. In XYZ.ino (XYZ.cpp) yet the callback is correctly inserted only once.
Commenting out / deleting the superfluous declararions is not big issue, but a little bit annoying when dealing with large menus and many repeats.
Thanks for your help, Frank

Yes agreed, it should not repeat the same declaration many times. Could you tell me which designer you are running from the about box?  I'll add this to the unit tests so that it gets fixed in the next version.

Yes, of course. I'm running TcMenu Designer 1.7.13, downloaded from MS. Project devlopement for esp32.
Frank

I managed to recreate this and add a unit test around it. It no longer duplicates the forward declaration on the development branch. I'll be doing another beta for all platforms in the next week or so. A  store release will follow a little after.

This should be fixed in tcMenu 2.0, it is also added to the designer automated unit tests for both Xamarin and Java versions.

It is in the current beta version


version 2.x-dev does not solve issue #536

Hi @rahmatalmubarak
I tested version 2.x-dev but bug is not solved, same symptom as #536
composer.lock
...
"name": "uasoft-indonesia/badaso",
"version": "2.x-dev",
"source": {
"type": "git",
"url": "https://github.com/uasoft-indonesia/badaso.git",
"reference": "036cf8e9c924d2ca328ef6471b1acd01c6037d9e"
},
Originally posted by @Dri372 in https://github.com/uasoft-indonesia/badaso/issues/594#issuecomment-1066497464

badaso not support int[] from postgres, so if you create a table directly on postgres with int[] or create the migration manually. So the PR #525 make badaso will show the popup that tell us the badaso not support it instead of error.
So we can change it first manually to int instead of int[]
you can also add a PR to make badaso support int[] datatype if you want too
thank you

@rizkiheryandi Thanks for your answer.
Communication is always a difficult art, especially since English is not our native language.

badaso not support int[] from postgres

Yes, understood and not a problem (for me).

So the PR https://github.com/uasoft-indonesia/badaso/pull/525 make badaso will show the popup that tell us the badaso not support it instead of error.

Ok with this solution, that I suggested in my original post.
I understood that your pull/525 was in the version "2.x-dev", either I misunderstood or I did a wrong test ... never mind it's not very important, I saw this error on existing application where I used such field for test only. So it's easy for me to change/delete the 'array types'. If you are confident with your pull/525, let's go ahead, close this thread, i'll wait for the ext version of the package.
Have a good day.

youre welcome @Dri372 , have a good day too :)

For further information, this pb can be solved by modifying this file : vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php
        ◦ $this->doctrineTypeMapping = [
           ….
            'int4'          => 'integer',
            '_int4'          => 'integer',	# <-------------
            ….
            'text'          => 'text',
            '_text'          => 'text',		# <-------------
``
From the doc ( https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#types ) this can be changed with the function AbstractPlatform::registerDoctrineTypeMapping($dbType, $doctrineType)

I don't know where to call this function in the Badaso code.


train_test_split function does not work properly

The current sp.SqlDataFrame.train_test_split function does not work properly when y_column is explicitly designated.

This is due to typos in pandas.read_sql_query, and have been resolved in the PR #2