Foreign objects are not properly accounted for in GC

While looking at heap/GC implementation in the Pony runtime, I came across the following comment (https://github.com/ponylang/ponyc/blob/master/src/libponyrt/mem/heap.c#L481-L483):

// Foreign object sizes will have been added to heap->used already. Here we
// add local object sizes as well and set the next gc point for when memory
// usage has increased.

I didn't notice any code in the GC/heap marking logic that accounted for adding foreign objects to the heap used that was analogous to the code in recv_remote_object (https://github.com/ponylang/ponyc/blob/master/src/libponyrt/gc/gc.c#L310-L317) so I added a @printf[I32] at heap.c#L480 to print out the value of the heap used if it was greater than 0 and then ran our application at Sendence (a multi-actor stream processing engine) and the printf was never triggered.
It seems there's a bug where foreign object heap accounting is not occurring properly resulting in undercounting of heap usage for any actor that has references to foreign objects. This has a ripple effect where it impacts how often GC is run for these actors because the next heap level for GC is not reached as quickly as it should have been if the foreign objects were accounted for.

One additional point on this, each time after we start a gc, we reset used to 0.
https://github.com/ponylang/ponyc/blob/master/src/libponyrt/mem/heap.c#L364
So when we fix this we need to make sure it takes that resetting after each gc into account. It's not enough to account for the memory when recv the object.

in mark_remote_object we need to do the same ponyint_heap_used call for a heuristic hint that we use in recv_remote_obj.
in mark_remote_actorwe want to do the same ponyint_heap_used call that we do in recv_remote_actor
in the recv_* we only do the ponyint_heap_used based on the rc >0.
in the mark_* ones we can do this ponyint_heap_used anytime after   if(obj->mark == gc->mark)     return;


[SPARK-18200][GRAPHX] Support zero as an initial capacity in OpenHashSet

What changes were proposed in this pull request?
SPARK-18200 reports Apache Spark 2.x raises java.lang.IllegalArgumentException: requirement failed: Invalid initial capacity while running triangleCount. The root cause is that VertexSet, a type alias of OpenHashSet, does not allow zero as a initial size. This PR loosens the restriction to allow zero.
How was this patch tested?
Pass the Jenkins test with a new test case in OpenHashSetSuite.

Test build #68026 has started for PR 15741 at commit d157ea1.

Test build #68030 has started for PR 15741 at commit d7bd9a9.

Test build #68026 has finished for PR 15741 at commit d157ea1.

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

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

Merged build finished. Test FAILed.

Test build #68030 has finished for PR 15741 at commit d7bd9a9.

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

Merged build finished. Test FAILed.

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

Test build #68040 has started for PR 15741 at commit b4dd73d.

Test build #68040 has finished for PR 15741 at commit b4dd73d.

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

Merged build finished. Test FAILed.

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

The only failure seems to be irrelevant.
[info] BasicSchedulerIntegrationSuite:
[info] - job with fetch failure *** FAILED *** (1 second, 889 milliseconds)
[info]   java.util.concurrent.TimeoutException: Futures timed out after [1 second]

Retest this please.

Test build #68046 has started for PR 15741 at commit b4dd73d.

LGTM pending Jenkins.

Test build #68046 has finished for PR 15741 at commit b4dd73d.

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

Merged build finished. Test PASSed.

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

Thank you for review and merging, @rxin .


Transform jumps when sharing zoom between components

I've got two components sharing the same zoom. Depending on which component I use the scroll wheel on, I get different zoom levels because the __zoom transform in each component is not kept in sync.
Expected behaviour:

Zoom in on component A, observe component B also zooming to the same scale.
Zoom in on component B, observe component A also zooming in further to the same scale as B.

Actual behaviour:

Zoom in on component A, observe component B also zooming to the same scale.
Zoom in on component B, components A and B jump back out to the original zoom level before linked zoom commences.

I've worked around the problem by copying d3.event.transform into each component's __zoom member inside the corresponding component's zoom event listener. It doesn't seem right though, I shouldn't be fiddling __zoom directly. I don't want to kick off a full zoom.transform inside the zoom handlers.
Is this how it's supposed to work? Am I expected to do this transform sync myself? If so, what's the right way to do it?

The expected behavior you describe is not the expected behavior. Each element gets its own zoom state (hence d3.zoomTransform) and zooms completely independently. If you want to synchronize zooming, you must apply the zoom transform from the active element to the other elements. If you don’t want to synchronize zooming, you should be careful to only redraw the active element with its zoom transform (and not inadvertently apply this transform to the other elements).


On supporting non-github release('d) cores

As per the Snow Bros 2 core & following on from the chat in the discord.
(I'll just talk about the output JSON in this rather than the input yml)
I think what could work is something along the lines of (forgive the typescript notation):
type CoreRepo = {
  platform: "github",
  owner: string,
  repo: string
} | {
  platform: "github-within-tree",
  owner: string,
  repo: string,
  path: string, // "releases" for the snowbros 2 core
  filename: string // "pram0d.snowbros2_*" for the snowbros 2 core
} | {
  platform: "bitbucket", // just shoving this in here as another example
  owner: string,
  repo: string
}

Then in updaters they'll do their current behaviour for platform: "github", and switch to a new download method for "github-within-tree" (which is a rubbish name, there'll be a better one...)
The "new method" (for whatever better name github-within-tree ends up getting) would compose the API call for https://api.github.com/repos/psomashekar/pram0d-pocket-dist-public/contents/releases then find the most recent file which matches the filename glob & download it (which isn't actually as different from using the releases API as I thought it would be...)
There's a couple of terminology things that might change since release.tag_name doesn't apply since it's not tagged & repository itself might make more sense as download but that's small fry stuff.

Thanks for writing this up! I've been talking a bit more with @mattpannella, and our current position is that using GitHub releases is the standard that we want to stick with, at least for now. If someone releases a core on something like GitLab, I think it makes sense for us to support that, and GitLab has its own version of releases that should be compatible with how we're set up currently.
Unless more developers choose not to use releases for whatever reason, I'm not sure we want to add complexity and sink time into this for a single repo.

Seems a bit of a shame to be the inventory for almost everything, but I can see how difficult it'd be given the format of the yml files etc

I decided to look at this again and see if I could square it in my head, but I don't think I can get there still. One big question I have, is how do we know when there is a new release if there is no git tag? There's only a single develop branch in the repo. The only way we could handle this would be to re-download the ZIP every single time the script runs. We could maybe look at the file creation date of the ZIP, but that's different across platforms.
We would also have to maintain two separate ways of parsing out information. We switched to using the GitHub API response to get the release date and core version info after initially going off of the JSON files in the cores, because we found that core authors don't do things in a standard way. For instance, the Space War core listed the version and release date of the original game, not the core.
I agree that it's kind of a shame we can't include these, but we're looking at maybe dozens of collective hours changing the API and updaters versus the core author just adding a release.

I suspect what's likely to happen is the .zip files will be added to that repo with a new date appended (so you'll have multiples of each core with different dates appended). You'd probably need to look at the date on the zip (or, yeah, download it and inspect inside) - or find the most recent & check the git hash.
The author might be amenable to adding the semver into the filename snowbros2_20221<IP_ADDRESS>.zip style, which would solve that without them having to do releases.
Yeah - I had the same issue with the SpaceWar core when I wrote the first JSON, pretty annoying that Analogue immediately broke their own rule in the example core...

re: checking the SHA, i think pram0d said he plans to add a new zip for each release and add a date to the file
pram0d.snowbros2_20221019.zip
pram0d.snowbros2_20221020.zip
etc
so i think what you'd need is to do is look for any file named {core_name}* and then parse the date strings to find the most recent one

Bleh. Well, at least that's something to work with potentially. I got bored and very roughly started extracting out the current script as its own library. Working to see what it would look like to make this more modular, so we could plug in different classes to handle different things. I might keep experimenting with this as I get time/motivation, with the end goal being supporting GitLab as well, and if it's not too terrible, maybe the pram0d stuff.

Another update on this. @mattpannella pointed out that Jotego releases his Mister cores in a mono repo as well. It is also the same structure as pram0d. With his cores being publicly released in the near future, I think it makes sense to put in the effort to support them.

was thinking about this a little bit, going off @neil-morrison44's structure in the op
- username: agg23
  cores:
    - display_name: Atari's 1972 Pong
      repository: openfpga-pong
- username: psomashekar
  cores:
    - display_name: Snow Bros 2
      repository: pram0d-pocket-dist-public
      mono-repo-directory: releases
      filename: pram0d.snowbros2

so if the mono-repo-directory is set (can pick a prettier name) the cronjob knows to look for releases in that directory of the repo, with the filename as the pattern to check for. and each release will have _DATE tacked on that we can use for versioning. (could also be semver as well. i guess as long as we assume everything after the _ is the version, the comparison can be handled by the updater. because the cronjob can just grab the most recent file that matches the filename
and the filename can(should?) be the core name
and then json output could look something like. would only have a release, since there's no clean way to have pre-release.:
  {
    "identifier": "agg23.Pong",
    "platform": "Pong",
    "repository": {
      "platform": "github",
      "owner": "agg23",
      "name": "openfpga-pong"
    },
    "release": {
      "tag_name": "1.2.0",
      "release_date": "2022-09-09T01:56:30Z",
      "platform": {
        "category": "Arcade",
        "name": "Pong",
        "manufacturer": "Atari",
        "year": 1972
      },
      "assets": []
    }
  },
  {
    "identifier": "pram0d.snowbros2",
    "platform": "Snow Bros 2",
    "repository": {
      "platform": "github",
      "owner": "psomashekar",
      "name": "pram0d-pocket-dist-public",
      "mono-repo-directory": "releases",
      "filename": "pram0d.snowbros2"
    },
    "release": {
      "version": "20221019",
      "release_date": "2022-10-07T18:27:05Z",
      "platform": {
        "category": "Arcade",
        "name": "Snow Bros 2",
        "manufacturer": "i dont know",
        "year": 1983
      },
      "assets": [
        {
           "platform": "snowbros2",
           "filename":"snowbros2.rom"
        }
      ]
    }
  }

I would advise having the repository.platform property be the sole thing that the updaters use to key off how they should download the core - this one's of a similar (or perhaps more) difference from the "normal" "github" one as a bitbucket or gitlab release would be & it'd allow the updaters to just check repository.platform to know if they can handle it or not -- also neater to add to later if others release cores in even more unexpected ways.
-- but that'd mean big changes to the .yml files (but they might end up in a better place after the changes)

I'll take some time this week to hash things out and come up with a generic solution that can be applied the repositories va releases.

@neil-morrison44 @mattpannella @goronfreeman
Sorry for the delay, I've been a little caught up in things. I also wanted to take the time to go through and not jump to any conclusions while trying to keep things flexible.
I'd like to propose adding a new section to the repos.yml under each core:
distribution:
  type: ""            # Mandatory - Can be one of the following: release, contents or url
  release:            # Optional - Contains the configurations for type 'release'
    asset_prefix: ""  # Optional - If specified, the prefix will be used to filter release assets. If multiple files match, only the first will be returned. If omitted, the first result will be returned.
  contents:           # Optional - Contains the configurations for type 'contents'
    path: ""          # Optional - If specified, the path will be used to resolve the directory / file. If omitted, the content of the repository's root will be used instead.
    file_prefix: ""   # Optional - If specified, the prefix will be used to filter repository contents. If multiple files match, only the first will be returned. If omitted, the first result will be returned.
  url:                # Optional - Contains the configurations for type 'url'
    release_date: ""  # Mandatory - The release date of the core.
    link: ""          # Mandatory - The URL to download the core.

Here's a brief explanation of the different distribution types:

release: This is the method currently used by most of the cores hosted on GitHub.
contents: This method is currently used by the pram0d cores.
url: This method would allow cores to be hosted elsewhere / allow us to quickly support new cores while we iron out the details.

Some of the changes listed above will require some modifications to the logic used to retrieve the release_date.
Furthermore, I'd also like to add a url property to the release / prerelease property in the cores.json. This would allow updaters to completely bypass GitHub API (for the release and contents distribution types) and download cores directly.
"release": {
  "tag_name": "0.9.0",
  "release_date": "2022-09-03T20:45:09Z",
  "url": "https://github.com/agg23/openfpga-arduboy/releases/download/0.9.0/agg23.Arduboy.0.9.0.zip",
  "platform": {
    "category": "Handheld",
    "name": "Arduboy",
    "manufacturer": "Arduboy",
    "year": 2016,
   },
   "assets": [
     {
      "platform": "arduboy",
      "extensions": [
        "hex"
      ]
    }
  ]
}

I believe these changes should be sufficient to cover all the scenarios that we've currently encountered, however, I'm looking to you guys in case I missed anything.

this all looks really great to me
i think the only thing that jumps out at me that could bring up an issue is including the url to the github release.

this isn't terrible, cuz i'm already handling in my updater, but you have to iterate through the assets if there's multiple and make an educated guess on which zip is the actual core. i just check for a folder named "Cores" in the zip and assume thats safe enough to guess that its the actual release zip i want
the more annoying one: multiple cores in one repo. aka the gb/gbc repo haha. there's not a single release zip there

The url property would point directly to the core's archive. For repositories that host multiple cores, the *_prefix property can be used to filter the correct file.

oh duh, ok yep. thats great i like it. not sure if there's anything else we'd really need?

I need to give this one more good read through when I'm a little less frazzled, but I think this makes sense. I've thought before that we should just add the URL directly, so I think that's a great addition here. I have a rough plan in place to make this happen. First, I think this is getting complex enough that instead of cramming all the code into the workflows directory in this project, it should be extracted out.
I created the new repo corekeeper where I'm going to completely rewrite the logic for this and package it as a rubygem that we can easily include in this repo. My hope is that I can make the mode more modular, so we can plugin classes here and there to give us special behavior. This should be especially nice once we have to support another git hosting site. We can transfer the gem to the organization whenever we get around to creating that.
I want to get this gem spitting out an identical JSON file to what we're currently producing, then once that is working, move on to adding the new functionality that @joshcampbell191 described above.
Thanks for once again putting in the legwork to come up with a clean structure for us to start building on! 😃

@neil-morrison44 / @mattpannella does this approach work for you guys?

Think so yeah, so the existing cores would get something like
distribution: {
  type: "url"
  url: {
    release_date: "2022-09-03T20:45:09Z",
    link: "https://github.com/agg23/openfpga-arduboy/releases/download/0.9.0/agg23.Arduboy.0.9.0.zip"
  }
}

and the snowbros core (etc) would get something like
distribution: {
  type: "contents",
  contents: {
    path: "releases/"
    prefix: "pram0d.snowbros2_"
  }

If I'm understanding correctly?

Ah wait - confusion between yml & json, I see what you're saying now, they'd all get output as the url on the JSON side.
The point about the release notes still stands I think, I'd still like to know something about where the core lives (at least if it's on github with the release system)

the repo info would still be in the api response i think. so that wouldnt change. this is just additional, right?

lol should we discuss changing this to support jotegos stuff or just make that a new issue

I reckon there’ll probably be an additional step (mirror repo / building the zips somewhere / some sort of transformation) in between JOTEGO’s cores and this so I think a new issue probably makes sense & it’ll just feed into the url system discussed here

The JOTGEO cores should, hopefully, be going up in JTBIN soon as individual zips with their own version numbers (and no date suffix) - I think what we discussed for the pram0d cores should work

@neil-morrison44 @mattpannella
I know it's been a little while, but I'm just about finished with this feature.
I noticed that if we go with this approach, the tag_name field will be empty for cores that come from a url or a repository's contents. After some thinking, I was wondering if we can get rid of this in favor of the core.metadata.version field from core.json. However, some cores (JOTEGO) don't seem to implement this.
What are your thoughts?

Neil setup a GitHub action to inject the version into jotegos cores and save them as zips
https://github.com/jotego/jtbin/tree/master/pocket/zips
and yeah using the version is ideal. I think we already switched to that instead of tag in the current API version

Sounds like we need to revisit the cores.json format another time. I'll see if I can put something together shortly and ensure it meets everyone's needs.

Yeah that workflow should be putting a version into the JOTEGO cores now (it's just the git hash of the commit that last updated something within the core).
There is a problem with the workflow though where it replaces the zips even without any changes - I assumed it'd create the same zip file & git would ignore it but that's not the case (not sure if it's not the same zip file or if it's a timestamp / metadata thing)
That might cause issues, not sure.
& yeah, I don't think Pocket Sync looks at the tag name anymore, just the version so that's fine

@neil-morrison44 i think the issue in the jt release zips is it's adding the latest commit hash to every single core, so thats why its creating a new zip for every one
i just ran the v2 api in my updater it every jt core updated with the same version

Update Process Complete
Cores Updated:
jotego.jtcontra 64d5ae0
jotego.jtdd 64d5ae0
jotego.jtdd2 64d5ae0
jotego.jtgng 64d5ae0
jotego.jtkarnov 64d5ae0
jotego.jtkicker 64d5ae0
jotego.jtkunio 64d5ae0
jotego.jtmikie 64d5ae0
jotego.jtpang 64d5ae0
jotego.jtpinpon 64d5ae0
jotego.jtroadf 64d5ae0
jotego.jtroc 64d5ae0
jotego.jtsbaskt 64d5ae0
jotego.jttrack 64d5ae0
jotego.jtvigil 64d5ae0
jotego.jtyiear 64d5ae0

Oh - it should be looking at the latest commit hash that affects the files which end up in the zip rather than just the latest commit hash full stop.
Could be something to do with the depth of the checkout, if that makes the logs useless.
(Also, v2 is up?)

josh said he's still got some stuff to tweak, but you can start testing
https://github.com/openfpga-cores-inventory/analogue-pocket/commit/baeb51c8201201996edac17edb5783f3d8148fc0

v2 of the API is now up and ready for testing. You can find the documentation here: https://github.com/openfpga-cores-inventory/analogue-pocket/blob/main/_docs/v2.md
Note: v0 and v1 of the API will only support cores that are distributed via the GitHub releases.
Let me know if you come across any issues or would like to make changes.

@joshcampbell191 Trying it out in Pocket Sync now & it works perfectly, absolutely no issues - can see & install all the JOTEGO, pram0d cores etc.
Lots of my nasty code, including some ugly regex stuff for finding the download zip goes in the bin so that's great too.
Assuming @mattpannella finds the same are you reading for our updaters to start using V2?

yup i'm good to go on this end

I was just waiting on you both to confirm things are working on your end before locking in the changes.

@neil-morrison44 now that you mention it, I don't have a good solution for the pram0d cores (specifically garegga) since the logic I wrote for the file prefix captures the first match. I don't do any ordering by published dates since this could return incorrect results depending on how assets are uploaded / modified.

Is that where garegga & kingdmgp & sstriker are all included in one zip?
I noticed that, it isn't too much of an issue for Pocket Sync but I guess it'd be hard to know which core the version number etc relates to + it's a little annoying that the user has to manually deselect the other files in the zip preview.
Not sure how to solve that beyond splitting the zips per core & re-hosting them somewhere but that's a bunch of work & ongoing file hosting.
(The Pocket Sync version that talks to V2 is going up just now by the way)

Yes, that's the one.
The fact that they are packaged together doesn't matter on my end. My only issue with it is that there's multiple versions of the zip in the release folder and my prefix approach returns the first match based on the name. I chose that instead of GitHub dates since dates can be unreliable depending on when the assets are updated.

Got you, yeah no better solution to that comes to mind - first by filename should work assuming it's timestamps & numerically descending.
Looks like there's a pram0d.garegga_20221029.zip & a pram0d.garegga_20221030.zip just now & the API shows the 20221030.zip one so hopefully that holds up long term.

On the zips with multiple cores thing - which one gets chosen as the one you take the version string etc from?

what if we further complicate the repo yaml config and add a flag for when there will be multiple zip releases (with dates) per core.
then if that's true you grab all files that match your prefix filter instead of just one and sort them to get the latest based on the date.
it's pretty gross but it would work haha

Let's close this for now and leave things as is. Either way, the issue would be on my end and shouldn't stop you.


Slushy storybook deployment to GitHub pages

Storybook has been integrated to Slushy library and that has to be now deployed as GitHub pages through GitHub actions CI pipeline
Acceptance Criteria : It must be deployed to GitHub pages on PR merge

I'll try to have Color Design Tokens codified in Storybook ready before we start to deploy our Storybook


[WIP] Resolve circular reference of imports

WIP
Need to discuss:

Should we stop re-exporting Base* classes and Base*Params types from types.ts?
Should we move definitions of Base*Params types to types.ts and import them from base/*.ts?

Current dependencies graph:

Ideal:

Should we stop re-exporting Base* classes and Base*Params types from types.ts?

It should.

Should we move definitions of BaseParams types to types.ts and import them from base/.ts?

It should not.
Because base/*.ts files are already exported.

We have stopped re-exporting, but the problem continues to persist.
types.ts defines User{Column,Fiter,Source,Ui which depends on Base{Column,Filter,Source,Ui}Params, so we cannot make types.ts independent.
To solve the problem we have to define Base*Params in types.ts in the same way that we do BaseActionParams in types.ts.

Hm... If so, User{Column, Filer, Source, Ui} should be exported in base/*.ts files.

Oh, I have found DduOptions also depends on Base*Params.
Is there any way to keep DduOptions in types.ts other than defining Base*Params and User* in types.ts?
export type DduOptions = {
  // ...
  columnParams: Record<ColumnName, Partial<BaseColumnParams>>;
  filterParams: Record<FilterName, Partial<BaseFilterParams>>;
  kindParams: Record<KindName, Partial<BaseKindParams>>;
  // ...
  postFilters: UserFilter[];
  sourceParams: Record<SourceName, Partial<BaseSourceParams>>;
  sources: UserSource[];
  // ...
  uiParams: Record<UiName, Partial<BaseUiParams>>;
};

DduOptions must be defined in types.ts.
Hm...
Base*Params can be defined in BaseParams in types.ts.
Because it is just Record<string, unknown>.

Remaining circular reference:

ddu.ts and types.ts
context.ts and types.ts
loader.ts and base/source.ts

I think the following way is better to resolve a circular reference between loader.ts and base/source/ts:

Define Loader interface in types.ts.

export interface Loader {
  async initStaticImportPath(denops: Denops): Promise<void>;
  async autoload(denops: Denops, type: DduExtType, name: string): Promise<void>;
  registerAlias(type: DduAliasType, alias: string, base: string): void;
  async registerPath(type: DduExtType, path: string): Promise<void>;
  getUi(index: string, name: string): BaseUi<BaseParams> | null;
  getSource(index: string, name: string): BaseSource<BaseParams> | null;
  getFilter(index: string, name: string): BaseFilter<BaseParams> | null;
  getKind(index: string, name: string): BaseKind<BaseParams> | null;
  getColumn(index: string, name: string): BaseColumn<BaseParams> | null;
  getAlias(type: DduAliasType, name: string): string | undefined;
  getAliasNames(type: DduAliasType): string[];
  getSourceNames(): string[];
}

Implement the interface in loader.ts.

import type { Loader } from "./types.ts";

export class LoaderImpl implements Loader {
  // ...
}

Import Loader from types.ts in base/source.ts.

context.ts and types.ts

Hm.
export { ContextBuilder } from "./context.ts";

can be removed in types.ts.

ddu.ts and types.ts

export type { Ddu } from "./ddu.ts";

can be removed in types.ts

loader.ts and base/source.ts

Hm...
loader.ts is only used for the arguments.
export type OnInitArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  loader: Loader;
};

export type OnEventArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  event: DduEvent;
};

export type GatherArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  context: Context;
  options: DduOptions;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  input: string;
  parent?: DduItem;
  loader: Loader;
};

You can split the file.

Why base/source.ts requires loader?
Because some sources uses loader...

https://github.com/4513ECHO/ddu-source-source/blob/main/denops/%40ddu-sources/source.ts
Hm...  ddu-source-source uses the feature.

Remaining circular references:

types.ts and base.ui.ts
among ext.ts, ddu.ts and base/ui.ts

If we move the definition of UiActionArguments to types.ts, ① and ② is going to be resolved.
However, because of UiActionArguments depends on Ddu, a new circular reference between types.ts and ddu.ts is happening.

This dependency was added at https://github.com/Shougo/ddu.vim/commit/3202e53453d082cce9e829048d2c285864d5ceab. Why UiActionArguments requires Ddu?

This dependency was added at https://github.com/Shougo/ddu.vim/commit/3202e53453d082cce9e829048d2c285864d5ceab. Why UiActionArguments requires Ddu?

Because user actions want to use ddu like this.
    args.contextBuilder.patchGlobal({
      ui: "ff",
      profile: false,
      uiOptions: {
        ff: {
          actions: {
            kensaku: async (args: {
              denops: Denops;
              ddu: Ddu;
            }) => {
              args.ddu.updateOptions({
                sourceOptions: {
                  _: {
                    matchers: ["matcher_kensaku"],
                  },
                },
              });
              await args.denops.cmd("echomsg 'change to kensaku matcher'");

              return ActionFlags.Persist;
            },
          },
        },
        filer: {
          toggle: true,
        },
      },

This pull request is now ready to use now.
@Shougo Could you release pre-release version to test?
Current dependencies graph:

OK.


Changed the internally used System.Linq.Dynamic namespace

Changed the internally used System.Linq.Dynamic namespace so it is project specific, to avoid interfering with references in other projects.
Means that we can reference both this and System.Linq.Dynamic in the same project.  Fixes issue #114
the options were
-reference the nuget for System.Linq.Dynamic (which can't be done thanks to strong naming hell)
-change this library to not be strong named (which will result in gnashing of teeth from those who are currently using strong naming)
-do as this checkin does, and change the namespace so it's project prefixed and won't collide with other libraries.
Went with the last option as it seems path of least resistance.  Only breaking issue could be users who have decided to reference this library, and then gone on to use the dynamic linq contained package will have to update their own referenecs.  Ideally they should instead be referencing the nuget package, but irrespective, they definitely shouldn't be referencing this package for the purpose of using dynamic linq, and this chagne will not cause unexpected behaviour, it will cause a very obvious compile error.

I'm seeing an ambiguity issue when trying to do a Where clause with the string predicate. Is it possibly related to this? I'm running dev build 146 and it's still happening. Have both Dynamic and Extended (reference in separate NuGets) in the same project. As soon as I uninstall Extended the problem goes away. Thanks!

Is there any update on this?
@pwelter34


compose multiplatform animation has high CPU usage in IOS

Development environment: any iPhone

IOS Native Animation

Below is the CPU usage, only 1%

Below is the code

- (void)viewDidLoad {
    [super viewDidLoad];

    UIView *rotatingView = [[UIView alloc] initWithFrame:CGRectMake(100, 100, 100, 100)];
    rotatingView.backgroundColor = [UIColor redColor];

    CABasicAnimation *rotationAnimation = [CABasicAnimation<EMAIL_ADDRESS>    rotationAnimation.toValue = [NSNumber numberWithFloat:M_PI * 2.0];
    rotationAnimation.duration = 1.0;
    rotationAnimation.repeatCount = HUGE_VALF;
    rotationAnimation.cumulative = YES;
    rotationAnimation.removedOnCompletion = NO;
    [rotatingView.layer addAnimation:rotationAnimation forKey:@"rotationAnimation"];

    [self.view addSubview:rotatingView];
}

Compose Multiplatform Animation

Below is the CPU usage, which has been fluctuating at a high level

Below is the code

@Stable
@Composable
fun Spinner() {
    val infiniteTransition = rememberInfiniteTransition()
    val angle by infiniteTransition.animateFloat(
        initialValue = 0f,
        targetValue = 360f,
        animationSpec = infiniteRepeatable(
            animation = tween(1000, easing = LinearEasing),
            repeatMode = RepeatMode.Restart
        )
    )

    Box(
        contentAlignment = Alignment.Center,
    ) {
        Surface(
            color = Color.Blue,
            modifier = Modifier.size(50.dp).graphicsLayer {
                rotationZ = angle
            }
        ) {
            // Any
        }
    }
}

CPU tracing for Compose Multiplatform UI animation

I would like to ask, is there a way for me to hand over more tasks to the GPU, or does your company consider optimization?

Sorry, I reposted it on YouTrack
https://youtrack.jetbrains.com/issue/CMP-7187/Compose-Multiplatform-Animation-has-high-CPU-usage-in-IOS


Profiles API

This PR fixes issue #13  and configure he Profiles API along with a well structured mongoose Schema keeping in mind the future expansions.

Update the dto according to schema


Support End-User Configuration for set of encrypted resources

How to categorize this issue?

/area control-plane
/kind enhancement
/priority 2
What would you like to be added:
Enable end users to configure additional resources for etcd encryption.
Why is this needed:
So far only secrets are encrypted in shoot clusters. Because there may be other custom resources in shoot clusters
that may contain sensitive data, it is required to be able to influence the set resources intended to be encrypted.
As far as I understood this info is taken from an API Server config file, that is not yet configurable via the shoot manifest.
An actually important use case for this feature is the landscaper. It uses resources for data objects and deploy items
that may contain sensitive data and therefore urgently need to be encrypted in etcd.

Work has been started and pushed to https://github.com/timebertt/gardener/tree/enh/encrypted-resources.

/unassign @timebertt @rfranzke

/priority 4
/remove-lifecycle stale

/remove-lifecycle stale

It looks like with Kubernetes 1.26.x, encrypting custom resources will be supported: https://github.com/kubernetes/kubernetes/pull/113015
Are there any plans to support this for in Gardener? This would be really helpful to encrypt custom resources that contain sensitive data.

Interesting, so without https://github.com/kubernetes/kubernetes/pull/113015 the feature would not even have worked as expected. In this case, it's actually good that we haven't implemented it yet 😅
@reshnm We plan to eventually support it, yes, but we don't have a timeline for it yet. But given that it would only work for 1.26+ it isn't too urgent either. Probably we won't make it in 2022, but hopefully early next year.
/remove lifecycle/stale

@rfranzke Thank you for the clarification 👍

/remove-lifecycle rotten

In order to deploy the Gardener control plane with gardener-operator (ref https://github.com/gardener/gardener/issues/7016), this issue is a prerequisite.

/remove-lifecycle stale

Hey guys, is there a timeline for this ?

Hi @In-Ko, not yet - we still have it on our radar, and we implemented a few prerequisites as part of #7016 (ref https://github.com/gardener/gardener/issues/4606#issuecomment-1434299846), however the majority of the story is still missing. #7016 is completed now and we plan to focus on #8023 next, perhaps we can come back to this issue after that. Please keep watching it for updates.

/assign


Release v0.4?

I tested the May 3rd master branch with Python 3.5 in WinPython.  Working well.  Thanks for the updates to support Python 3.6 and NumPy 1.12.  The WinPython distribution is more likely to accept supersmoother as a new package if v0.4 is officially released on PyPi.  Any blocking issues for this?

No blocking issues, I'm just solo caring for a 2 week old infant at the moment :smile:

OK, pushed to PyPI!

Thanks for the release under stressful conditions!  I proposed inclusion in WinPython in https://github.com/winpython/winpython/issues/535


Docs: Update PowerSync Localfirst Recipe

Description
This updates the PowerSync and Supabase for Local-First Data Management recipe. The PowerSync SDK has been updated with many improvements which simplify the installation and usage. The changes here are to align the recipe with the latest SDK changes.
Some notable changes:

Removed polyfill installation steps and Flipper network inspector step. This is no longer required since the SDK now pre-bundles polyfils and connects via WebSockets by default.
Added Metro config step for inline requires. This seems to be required as highlighted here https://github.com/infinitered/ignite-cookbook/issues/175.
Fixed minor inconsistencies in recipe code blocks. Some steps included importing code which is only created later in the guide.
Updated hooks to use useQuery instead of the deprecated usePowerSyncQuery
Removed the need for the expo-crypto package by using built-in uuid() SQLite function.
Fixed incorrect table names exported variables being used in recipe.

Open Source License Notice for Contributors
If you are contributing a recipe to this repository, you agree to license your contribution under the terms of the CC BY-SA 4.0 license.
If you have any questions, please reference the CONTRIBUTING.md or LICENSE.md file for more information.
Thank you for your contribution!

Thanks for the updates!
I'm following along in my project and I seem to have run into this:
Unable to resolve "fast-base64-decode" from<EMAIL_ADDRESS>
Deps
    "@journeyapps/react-native-quick-sqlite": "^1.3.0",
    "@powersync/react-native": "^1.11.0",
    "expo": "~51.0.31",
    "react-native": "0.74.5",

I found this related issue powersync-ja/powersync-js#273 but removing node_modules didn't work. This is via the yarn package manager.
It looks like this is issue is being fixed in a future release? powersync-ja/powersync-js@b4d64f0

Thanks for spotting this. This issue should be fixed in<EMAIL_ADDRESS>which will be released soon.


Only allow the creation of 2D renderers if there is 2D data present and same for 3D

Fix #1199
Fix #1619
Fix #1650

Does this PR also fix #1650

@clyne Yes, it does fix #1650 and I've added that to the PR description
I see what you mean. I fixed the title.
Since DataMgr::GetDataVarNames(int dim) includes derived variables then it will work as expected. A dataset would need to have a 2D grid to output the variable to, however, which I assume a 3D-only dataset would not have.


Unable to install via npm due to preinstall requiring root access

package.json contains:
"scripts": {
	"preinstall": "npm install grunt-cli markitdown -g"
},

Global installation requires root privileges, and that's quite problematic for us, e.g. our CI servers don't allow it.
Could you move these packages to (dev)dependencies and use npm bin (./node_modules/.bin) instead?

@pornel that was missed in our just-released v1.4.0. We replaced markitdown as part of #142. We'll get that preinstall cleaned up...

@brianbaker please review and merge? Thanks.

preinstall has been removed from package.json in 1.4.1-wip


Fix usage of EndpointType.JAX_WS_WSDL

Hi,
I am upgrading a project from Grails 2.x to Grails 3.x. In Grails 2 project, there are few endpoints with value expose = EndpointType.JAX_WS_WSDL
Sample code is
@GrailsCxfEndpoint(address = 'someService', expose = EndpointType.JAX_WS_WSDL)
As per the updated document of Grails 3, I should still be able to use EndpointType.JAX_WS_WSDL to expose a service endpoint as a wsdl first jax web service endpoint. However, JAX_WS_WSDL isn't part of EndpointType enum anymore.
What do you suggest?

Facing the same, any luck?


"Automatically delete from queue completed downloads" setting

I suggest adding this setting to save users from manually deleting all successfully completed tasks.

That defeats the purpose of the queue, if downloads are removed automatically from there there is no point to it


MPPT 100/20 strange issue no solar

Hi, I updated to the latest release but I continue to have this problem or when there is no sun I have this error,
[15:03:25][D][victron:1026]: Unhandled property: PRt\xe3\xc160H\xc8U(\xb2\x8a\x8fSER#B*ɱ06V\xe6V\xd5UHȕ26\xbf10
\xfb\xe3K\xa6\x82j
V\xf8V 39680
\x8fERR \xb8
[15:03:25][D][victron:1026]: Unhandled property: L*%O\xef
I\xec 140\xb8\xec\x8c?\xcaJ12\xbb770
[15:03:25][D][victron:1026]: Unhandled property: \x8fH20B7\xa2\x8fH21 436

in fact during the night and in the morning all the Victron sensors don't work then when the sun is high enough in the sky it starts to go up until it descends under the mountains (blue arrow) and the error appears

when the power of pv is very low i have this error
[15:16:00][W][component:215]: Components should block for at most 20-30ms.
[15:16:00][W][victron:093]: Last transmission too long ago
[15:16:01][W][victron:093]: Last transmission too long ago
[15:16:02][D][sensor:093]: 'WiFi Signal Sensor Sottoscala 2': Sending state -58.00000 dBm with 0 decimals of accuracy
[15:16:02][W][victron:093]: Last transmission too long ago
[15:16:03][W][victron:093]: -

you can see from 14:30 all works fine, at 15:00 start Unhandled property error and at 15:20 Last transmission too long ago.
logs_sottoscala-esp8266-1_logs (3).txt
https://github.com/KinDR007/VictronMPPT-ESPHOME/issues/134#issuecomment-1817959026

How did you resolve the issue?

How did you resolve the issue?

I have changed the board from esp8266 d1mini supply by a dc dc isolated converter, to a esp32 UNO board supply by 12v so i removed the gnd cable to the victron MPPT, now i use only the tx pin .....   I had used this second configuration since 2019 to 2022,  but it start to disconnect from wifi i replace the esp32 board but it doesn t work (now i have found the mistake, i have 3 of 6 esp32 UNO board, bought from Ali,  that have a very bad wifi module, it works fine when i do the test in my lab, but when i connected it to the real Victron MPPT it doen t works because the wifi strength wasn t enough ), so i switched to  d1mini at the start of 2022 and now i come back to the esp32 UNO board with good wifi module and it works fine but It drove me crazy :)


Background notification does not working in 1.4.x

For Android 5.0 with phonegap-plugin-push 1.4.2 - notification background is not working, but 1.3.0 is fine working... When app is open, did not get any notification, after closed app (minimzed) and clicked notification that push.on('notification') is fired. Anyone has the same problem?
Now I am working with phonegap-plugin-push 1.3.0...

If I understand correctly, I believe I am having the same issue.  On android, when the app is in the background, an incoming notification will trigger GCMIntentService.onMessageReceived, buzz the app, open the app, but will not trigger my listener (via push.on('notification') in js) to the "notification" event.

FYI, downgrading to 1.3.0 also seems to resolve the issue for me.

I'm not sure that I understand your problem. Here is the way it should work.
App Open
With the app open your on('notification') event handler will always be called. You will not see anything in the notification shade unless you set options.android.forceShow to true.
App in Background
With the app open you will see a notification in the shade as long as your payload from GCM has a title or message component. Your on('notification') will not be called in this case. If the user clicks on the notification in the shade your app will start and your on('notification') event handler will be called.
If you do not provide a title/message in the payload from GCM then your on('notification') event handler will be called as it is assume this is a silent or data only notification.
App Close (ie not running)
You are pretty screwed at this point. Need to work on some code to restart the GCM service if the app is killed.
Please let me know if you are running into a problem in any of the above scenarios or if you have a new scenario.

This is what is not true for me with 1.4.2:

If the user clicks on the notification in the shade your app will start and your on('notification') event handler will be called.

The app starts, but the event handler is not called.  Not completely sure that is the same scenario as sonrebmax.

Also, note that if the app is not in the background (no instance running), clicking on the notification in the shade will open the app and in fact call the notification event handler correctly.  The issue I have is strictly when the app is in the background.  I'm using a Moto G on Android 4.4.4, Cordova Android 4.1.1, phonegap-plugin-push 1.4.2.

App Open
With the app open your on('notification') event handler will always be called. You will not see anything in the notification shade unless you set options.android.forceShow to true.

I done with this options.android.forceShow to true. As I wrote working fine in 1.3.0 not in 1.4.x (I checked 1.4.0 and 1.4.2)

@sonrebmax is your issue when the app is open or when the app is in the background?  If we are talking about different things, I'll create a separate thread.

I wrote

.. When app is open, did not get any notification, after closed app (minimzed) and clicked notification that push.on('notification') is fired.

Would you be able to elaborate on that statement a little bit?  Might help me (and maybe @macdonst) understand a little bit more.

@macdonst do you understand what I mean? (my english is not good)

App Open
With the app open your on('notification') event handler will always be called. You will not see anything in the notification shade unless you set options.android.forceShow to true.

in 1.3.0  = OK
in 1.4.2 = does not working - only showing push notification (on('notification') not called in app, so I must to click a push notification then on('notification') is called

App in Background
With the app open you will see a notification in the shade as long as your payload from GCM has a title or message component. Your on('notification') will not be called in this case. If the user clicks on the notification in the shade your app will start and your on('notification') event handler will be called.

in 1.3.0  = OK
in 1.4.2 = OK

If you do not provide a title/message in the payload from GCM then your on('notification') event handler will be called as it is assume this is a silent or data only notification.

in 1.3.0 = does not working
in 1.4.2 = OK (interesting feature)

Hello @macdonst,
I am trying to prove/use your comment and the readme instructions regarding silent notifications.
I think that some of the confusion may be coming from the various server side implementations.
For instance: the problem that I am having is that when I pass notification: {}, which is where I normally put my title and message properties, I am not getting the onnotification to fire while my app is running, on the other side, in the background.
Can you offer any clarification as to what else may be happening when gcm takes this format or the proper format that gcm will properly deliver? My server logs indicate that it is accepted but since I never get anything back I am unsure if it was mangled somehow to prevent final delivery.
Or any insight within the assumption that gcm did perform final delivery and this plugins expected final result was what got mangled during transit?

Nevermind, it appears that the issue was related to other conflicts that I monkey patched with stuff like library overrides. I got rid of the conflicting playservices plugin and now everything is working as it should.

Same problem - silent notifications not received with 1.4+
I post them with curl string from google docs - successfull answer but nothing on phone.


spaces added between buttons

Updated UsersListScreen.js and ProductListScreen.js to add spaces between buttons

I need to verify whether everything works fine. Could you add screenshots both in mobile and desktop view?

Sure!

desktop view:

mobile view

In mobile view, the buttons are placed vertically. Could you do anything about that?

Is this ok?

Would like to know how you achieved this?

I have imported button group from react bootstrap and then used it to group buttons

@roopeshsn forgot to commit. Please check now


Create spright-components package

Pull Request
🤨 Rationale
Resolves #1974
👩💻 Implementation

Created packages/spright-components

has spright-accordion component with unit tests
README and CONTRIBUTING

Created packages-level shared configs (and updated configs in other packages to import/extend these):

.eslintrc.js (package root config)
.eslintrc-src.js (package src config)
karma.config.js
karma-webpack.conf.js
rollup.config.js

Storybook for spright-components will be a separate submission.
🧪 Testing
Builds and tests pass
✅ Checklist

[x] I have updated the project documentation to reflect my changes or determined no changes are needed.

@jattasNI Not sure it makes sense for someone else to buddy this, so I thought you could take an initial look before having other people review.


Update Database

Hi,
I was thinking to the ways to update the csv database or even use some other datasources like osm names and etc. Is there any way to modify the datasource which is used in this library? I know it reads data from csv files, but what is the standard for making those CSV files?
thanks

@am2222  thank you for your question. The default lookup database is created by a SPARQL query on Wikidata. See https://github.com/somnathrakshit/geograpy3/blob/master/geograpy/wikidata.py. The result is cached in a SQLite database that is downloaded. If you'd like to have a more configurable solution just let us know via a specific issue.


In for loop assignment done as second argument

The assignment within for loop was done as second argument which throws error and also which is incorrect

Ok I have signed the CLA .


Documentation Addition, Fill out Grand Exchange on Wiki

Only 1 feature of the plugin is discussed in the original wiki.

https://github.com/jflgators/runelite/wiki/Grand-Exchange
Updated


Map qol

Summary
Various Map Improvements: Go and play!
Testing
Play through the map changes and yell at me if they aren't good and how you think they would be better.
Has this been tested in multiplayer? yes sir

Next up will be NPC additions and tweaked dialogue


Route lib / midi io / dupl time sel

Also adds insertEmptyItem

This issue has conflicts as well. Please resolve

l have built the foundation for a routing lib which allows for pretty much anything. It is based on a special type of string that you type and this allows for one to specify any kinds of mult to mult tracks. You can use str.match to batch route many tracks based on target guids or search strings.
Duplicate timeseection, ie. repeat segments of an arrangement.
midi device selection by keyvommand.
I created another repo called reaper-jsfx where I started to work on a vim-midi-controller
lib so that on can access lots of midi functionality fast. As an example if i switch between
my split keyb and my real piano i want to have my personal vim settup for each devick.
where i switch to arpeggiator, chords, trahspode etc.
basically handle all midi device stuff with eel.

I also tried to setup a new virtual keyboard mode for testing but i am not getting it to work.
I have done the foundation necessary to send midi messages but I don't get the mode to work
properly from the beginning I think. Could you please take a look at that and tell me what i am doing wrong. I am thinking that is maybe obvious to you what i am doing wrong.

I can also tell you that with this route lib you never will have to use the mouse for routing.
however it might need some more improvements but this is getting quite good actually.
I am still using log statements to show data. I haven't learnt the gui yet so I am logging route info. I'll try to checkout the gui more now.

oh an I also added a function for splitting track name up into regex_prefix and main name incase
one wants to dive into more structured naming of tracks etc

I also see that you have made many improvements with the bindings. it is awesome to now that the gui is back. it reappeard after i pulled master now before making the pr

i have found some minor bugs in the routing lib that i am fixing atm

Hey I just realized I should probably have made the pr to development branch, or no??

One more thing i realize now is that i included my fx lib. I am coming up with many more ideas for working w fx bow that i am looking at sidechaining fx

I added fx lib as well!

something that i want to add i an fx_mode where one can move up/down and navigate params fast. I think I have some
good ideas on how to solve some of the annoying ux obtacles that would require mouse normally.

i have a tiny fix that i am doing before you if you merge

Thankx @molleweide! I'll have more time to really delve into this in a couple of days

Im looking forward to your feedback

l am working on a scheme so that one can easilly have the same midi_keys layout between
regular laptop keyboard, ergodox/qmk. i am trying to set this up now in the jsfx project.
my goal is to be able to seemlessly be able to move between my laptop, ergodox, (i'd like to get a pair of dactyl manu also) without every having to rethink muscle memory.
i  have come up with some nice ideas. but for now since i cannot get key-release events I only
create fixed length notes on laptop with vkb. but this works fine for now.
as i  mentionned in another issue, i think, one interesting thing to do would be to suspend repear
keys when one is entering virtual keyboard mode somehow and let events pass through to the
built-in vkb. and only use eg. ESC to go back to normal mode. this would be the easiest i am imagining but i am unsure of how rk could be "turned off" during vkb mode.
on my ergodox this is not necessary since i have created a midi layer.
my idea above is to come up with some kind of generalized lyout that is easy to mirror on laptop.
tell me what you think later.

also please checkout the pr but i am still finishing up my temporary custom vkb for laptop with US international qwerty

i am going to add my ergodox midi layout in the reaper-jsfx repo so that you can understand how it is mirrored to my laptop keyboard.

just FYI if you are looking at the library/io_devices.lua and library/midi.lua they
are sort of work in progress because I haven't finished the latest version of the reaper-jsfx
project but hopefully you will be able to see sort of where I am going.

i am surprised how fast/responsive vkb is when I access it through rk. not much percieved latency at all!

If you look at https://github.com/molleweide/reaper-jsfx/tree/molleweide you can see how
far i have gotten so far. In my first version every thing worked but now there is something that is not quite right so I have to fix that. But here you will be able to see where I am trying to go sort of.
I am not sure what the error is. I jsfx is a bit annoying because it is much harder to debug logic than with lua. i am still trying to figure out a way of how one could 'log' stuff? in jsfx.
but when everything works it is very nice.

Hey @molleweide I'm happy you're having fun working on Reaper-Keys. I took a look through the entire PR (sorry it took me so long  😅).
I'm still a bit confused about what all this does, I don't use many MIDI devices myself. Could you explain a user case maybe?

It might be that it will have to live on your fork of the repo, and you could point the people that need it there through the Reaper-Forum or something of the like. This is just because the functionality is rather advanced for most users, and if I'm understanding the use case right, only a few of the users of Reaper Keys would be using it, so it's best not to include it I believe. I say this because of there are already many menu items already, and it would take a lot of time to really get into this PR and do a back & forth to get it into a mergeable state - right now the code sticks out compared to the code style of the rest of the repository, so there would have to be a lot of changes made.
Nevertheless, it's great you managed to get RK working for your usability issue with your MIDI devices, I hope more people learn about it. I wish you luck on your coding adventures :)

yo!
Thanks for checking out my code. I hope you see some of it useful. I have tried to keep things as well structured as i can.
Please do give me feedback and tell me if I am making some beginner mistakes.
Yeah you don't have to include reaper-jsfx. It was mostly just for showing you how I connect rk to jsfx AND I think that the project is in its very early stage. It might become good but I have to work more on it.

You have to tell me what you think of the routing stuff. it has to be tested more but i think that it is a great foundation. all though it can probably be refactored and bit more compacted.

Okay I'll leave some feedback for you! I'm not an expert software engineer but I had a co-op for a year and had to handle a lot of pull request feedback before I managed to push my first code, so I could try to do the same here.

If you really want to learn to code I think your best bet is to find something similar to a co-op so you can work in a team with more senior software people and get a lot of feedback.

yeah i mean just tell me if you think i am being stupid or something. :D

Great. I will fix everything you say!

in some cases i wanted stuff that I wrote to stand out so that you could comment on it but i realize that it becomes obvious
since pr highlights changes etc.

Yo check out the route docs and tell me if you understand it.

I am trying to learn linux atm. i am using virtualbox to test my configs on lots of linuxes.
it's gonna be fun to try reaper on linux!! i also just installed a program called kmonad for keys and mirroring my qmk. have you used it?

Hey I've been sick for a while now :face_with_thermometer: I'll get back to you when I feel better :smile:

I am trying to learn linux atm. i am using virtualbox to test my configs on lots of linuxes.
it's gonna be fun to try reaper on linux!! i also just installed a program called kmonad for keys and mirroring my qmk. have you used it?

I have not used it. Good luck! The biggest issue I had with reaper on Linux is getting all the vst's to work

Hey I've been sick for a while now :face_with_thermometer: I'll get back to you when I feel better :smile:

No worries. I hope you get well soon 👊

yo I think that I am ready to take on spacemacs soon. lately I have been checking out a lot of functional programming stuff and I am realizing that neovim is written in lua which is imperative and emacs is written in lisp which is functional. A couple of days ago I played around with virtualbox to learn how to install my dotfiles on linux and I also decided to upgrade some tools. I started using nyxt web browser, also written in lisp, and I also started using kmonad for keymappings n stuff, which is written in haskell, and so I am starting to shift my world a bit more towards functional stuff. I am really looking forward now to learning spacemacs and see how it differs to neovim. However, I also adopted a guys dotfiles whose configs were highly geared towards emacs so I have the really nice spacebar legend.
On macos you can do automation stuff with hammerspoon and this allows for pretty much Lua programming everywhere. And now taking on some functional stuff is exciting. Btw, kmonad was amazing. Now I have been using it for a couple of days and my macbook pro feels exactly like my ergodox now with identical layout.

have you seen this https://forum.cockos.com/showthread.php?t=250419
I'm not really sure how it works but it seems to be a "big deal" according to many in the thread.

I'm closing this to close this because I decided not to merge it.

great! I'll create a new PR in the future when I have worked more on this.

Hi Mike,
I hope you're doing well!
How is the music project going that you told me about? I have
been thinking about you from time to time now and so I wanted to see
how everything is going? Have you been coding a lot recently or
are you doing other stuff?
Would you mind also setting up a discussions area for reaper-keys?
// Hjalmar

Hey! Do you have a telegram?

Yes! What is your username on there? I'll try to find you.

@gwatcha


Give option to hide filter options in Match History Overview

Filter options are very intrusive on smaller screens. There should be an option to hide them.

Implemented


Add missing properties for some OBM classes

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: diegoalexdiaz:x: elvistincuYou have signed the CLA already but the status is still pending? Let us recheck it.


Remove merge_source_id columns

Do not merge this PR until #1108 is merged
This PR removes the merge_source_id columns from the LocationDescriptions and NameDescriptions tables in the db.
(PR #1108 removes all the code associated with those columns, which are unused.)
Also, as the columns are completely unused (i.e., all values are nil), it probably makes sense to merge this PR at the same time that we're ready to merge another migration; that will avoid an extra change to the db snapshot.

I will fix the failures tomorrow.

Coverage increased (+0.1%) to 92.103% when pulling 140ea60c35f8d2ec77dc28809c72bd0ca58745a7 on jdc-merge_source_id_columns-182778592 into 7925e8022946ea9080c0df8d2bc3376283dbe557 on master.

Yes, it's identical. It's my fault that it's so confusing. I branched from #1108 instead from master.
I think I'll do a new PR that has just the migration and schema.

I would have thought that would be the right way to do it.  Weird that it
didn't show just the differences between this and 1108...  No need to make
a new PR.
On Sat, Jul 23, 2022 at 11:16 PM Joseph D. Cohen @.***>
wrote:

Yes, it's identical. It's my fault that it's so confusing. I branched from
#1108 https://github.com/MushroomObserver/mushroom-observer/pull/1108
instead from master.
I think I'll do a new PR that has just the migration and schema.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/1109#issuecomment-1193237495,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNNKFJYUJCEUT6DNF23VVSYPJANCNFSM54GPMHLQ
.
You are receiving this because your review was requested.Message ID:
@.***>

I'll leave it as it.
It's showing the differences vs master (not #1108) because it's going to be merged to master -- the base branch for the PR is master.

I'm going to make this PR ready for review.
I would like to merge it so that it gets deployed with @mo-nathan's #1113.

My confusion is that if the PR is against 1108, why is github showing
differences against master?  I would have expected it to show the
differences against the branch it is made against.  I bet there is a
pulldown menu somewhere that would let me change which branch it is showing
differences against for the purposes of reviewing a PR.  So, I'm sure it's
not a big deal.  But I'm just surprised github doesn't default to the
branch the PR was made against (1108 in this case).  Ignore me.
On Sun, Jul 24, 2022 at 12:27 PM Joseph D. Cohen @.***>
wrote:

I'll leave it as it.
It's showing the differences vs master (not #1108
https://github.com/MushroomObserver/mushroom-observer/pull/1108)
because it's going to be merged to master -- the base branch for the PR is
master.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/1109#issuecomment-1193351755,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIUNDC5NLFBEZZAXK3VVVVGJANCNFSM54GPMHLQ
.
You are receiving this because your review was requested.Message ID:
@.***>

That's a great question. I had some problems finding the answer.
You can do it, but you can't navigate there from the PR page or even the
repo page.
Instead, you have to manually add "/compare" to the repo's path, taking you
to:
https://github.com/MushroomObserver/mushroom-observer/compare
Now you can compare (among other things) two branches.
https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits#comparing-branches
Problem: I've been aggressive about deleting branches for my merged PRs.
(That gives me cleaner displays in my various GUIs.)
The work-around is to restore the deleted branch:

Go to the PR page
https://github.com/MushroomObserver/mushroom-observer/pulls
Click Closed
Click the PR (Remove merge_source_id code) having the branch you want to
restore.
Scroll to the bottom, click Restore branch.
Now you can compare the branches via
https://github.com/MushroomObserver/mushroom-observer/compare

On Sun, Jul 24, 2022 at 9:33 AM Jason Hollinger @.***>
wrote:

My confusion is that if the PR is against 1108, why is github showing
differences against master? I would have expected it to show the
differences against the branch it is made against. I bet there is a
pulldown menu somewhere that would let me change which branch it is showing
differences against for the purposes of reviewing a PR. So, I'm sure it's
not a big deal. But I'm just surprised github doesn't default to the
branch the PR was made against (1108 in this case). Ignore me.
On Sun, Jul 24, 2022 at 12:27 PM Joseph D. Cohen @.***>
wrote:

I'll leave it as it.
It's showing the differences vs master (not #1108
https://github.com/MushroomObserver/mushroom-observer/pull/1108)
because it's going to be merged to master -- the base branch for the PR
is
master.
—
Reply to this email directly, view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/1109#issuecomment-1193351755
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAYTNNIUNDC5NLFBEZZAXK3VVVVGJANCNFSM54GPMHLQ
.
You are receiving this because your review was requested.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/1109#issuecomment-1193352686,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFDRI4DV7CRPGPV4T53VVVV5JANCNFSM54GPMHLQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Problems about the derivation of adding mono prior depth in base_surface_model

In base_surface_model.py L252 converting point to point depth to camera coord depth, you simply divide the ray bundle direction norm. The ray bundle direction norm is much different from the depth scale in the original monosdf, is here a potential bugs?

Hi, please refer to https://github.com/autonomousvision/monosdf/issues/22#issuecomment-1276294258.


[BD-46] fix: resolve security vulnerabilities

Updated packages that caused vulnerabilities. This led to small eslint fixes because precommit hook didn't allow to make push.
JIRA: PAR-631

Thanks for the pull request, @monteri! I've created BLENDED-1071 to keep track of it in Jira.   More details are on the BD-46 project page.
When this pull request is ready, tag your edX technical lead.

@monteri 🎉 Your pull request was merged!  Please take a moment  to answer a two question survey so we can improve your experience in the future.

:tada: This PR is included in version 17.5.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Docs]: add hindi translation the project

in which language do you want to translate?
I want to translate documentation to HINDI.
Code of Conduct

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

please assign me this issue.
"I'm in GSSOC'23"

assigned to you @akkshayTandon

@priyankarpal I want to contribute.Please assign me

Completed. Thanks for your contributions 🎉 ❤


dep: Reduce deps restriction

Signed-off-by: Xuanwo<EMAIL_ADDRESS>This PR will reduce the deps restriction so that end users can link to more versions.
Checklist

[x] Updated guide with pertinent info (may not always apply)
[x] Squash down commits to one or two logical commits which clearly describe the work you've done. If you don't, then Dodd will :).

This change is

I do not know if it's a good practice. We once had a condition with an unstable minor version:

https://github.com/datafuselabs/databend/pull/841
https://github.com/datafuselabs/databend/pull/862

By loosening the minor version constraint, one dependency upgrade may suddently break user applications.

Nice consideration.
First:

abc = "1.x.y" means allow building with all abc >= "1.x.y"
abc = "1.x.y" means allow building with all abc >= "1.x"

So no matter which style we are using (unless we choose to use ~1.x.y), an unstable dependency upgrade may suddenly break user applications (they should be addressed by upstream).
This PR intends to allow openraft built on more older versions.
As tokio v1.7 seems buggy, may It be better to roll back to a more recent version like v1.8 instead?

Nice consideration.
First:

abc = "1.x.y" means allow building with all abc that >= 1.x.y, < 2.0.0
abc = "1.x" means allow building with all abc that  >= 1.x, < 2.0.0

So no matter which style we are using (unless we choose to use ~1.x.y), an unstable dependency upgrade may suddenly break user applications (they should be addressed by upstream).

 Lesson learned!
Then it seems like nothing is getting worse:|

This PR intends to allow openraft built on more older versions.

For curiosity, why do you need to build on some older version?

As tokio v1.7 seems buggy, may It be better to roll back to a more recent version like v1.8 instead?

Hmm? What do you mean? It is 1.8 before this patch and 1 in this patch.

For curiosity, why do you need to build on some older version?

No obvious reason, just because we can... (and makes Cargo.toml more clear)
In this way, we don't need to bump the version unless we really need some new features.

Hmm? What do you mean? It is 1.8 before this patch and 1 in this patch.

If tokio v1.7 is buggy, I will change tokio = "1" to tokio = "1.8" to avoid 1.7 been chosen.

BTW, we are using https://github.com/renovatebot/renovate to check and update dependencies in our company. It automatically checks and increments dependencies and runs the CI with them (and optionally automatically merges the updates). I'm not responsible for it, so I don't have much knowledge about it, but it might be interesting. But it's more geared towards the "end product" to keep its dependencies fresh than for a library, which might still be used by an older dependant, forcing it to upgrade its dependencies.
Independent of that, I'm also in favor of making the dependencies more flexible.

Thanks for the nice idea! @schreter
I think the dependence policy is different for rust's lib and bin:

lib SHOULD specify the oldest version that it can build
bin SHOULD specify the newest version that it can use

It's different for vendored-deps language packages like in Node.js. And this is also part of the reason why Cargo.lock should be kept for the bin but not for lib.
So both dependabot and renovate are great choices for binaries, but for libs like openraft, it's better to keep depends unchanged unless we need new features.

@Xuanwo
IMHO, a lib should allow an application to upgrade the dependencies of the lib to the greatest compatible version, but also should specify the least working version, such as abc = "1.x.y".
The changes in this patch allow an application to install an older version of dependency that may have some
known bugs, such as:
derive_more = { version="0.99.9" } to derive_more = { version="0.99" }, there are several fixes in:
https://github.com/JelteF/derive_more/blob/master/CHANGELOG.md

So both dependabot and renovate are great choices for binaries, but for libs like openraft, it's better to keep depends unchanged unless we need new features.

Agreed. I just wanted to point it out, but I also wrote that it's unlikely going to help here.

Independent of that, I'm also in favor of making the dependencies more flexible.

...of course, only in case it doesn't break things :-). It seems that I misunderstood a bit the dependency management. Therefore, I'll abstain from the further discussion.
For my use case, the current dependencies (except serde issue, but that's being worked on) are just fine.

@drmingdrmer @schreter Thanks for all the comments. I have a better understanding of rust's dependencies :laughing:
I agree that current dependencies work fine. Let's close this PR for now.


Use defcon

The biggest thing this does is replaces robofab with defcon, but it also tries to improve py23 compatibility and makes a couple of small fixes.
cc @behdad

LGTM

lgtm as well.


Fix: sglang API response does not contain 'object' field.

Fix: sglang API response does not contain 'object' field.

做了一点修改，默认先解析usage


Flynn unusable

Not sure what going on with the latest version of Flynn but I'm finding it pretty much unusable as I can no long push updates to my apps without fear of it bringing down 1 or more of the apps running on the servers.
I'll email you my latest logs where when I pushed 1 app another app went into a service unavailable state straight away.

@dottodot is your app perhaps crashing due to memory constraints?
Run the following to check if your app is hitting the memory limit:
flynn -a sticky log --init | grep -F 'lack of available memory'

Also, check /var/log/syslog to see if the kernel is killing processes due to the host running low on memory.

Going to try a cluster with 4G of memory to see if that resolves it. Thankfully found alternative hosting for the same price so I don't have to double my costs.

@dottodot did you confirm it was a memory issue though? I didn't see evidence of it in the logs, it was just more of a suspicion because the debug logs don't include your app logs / syslog.

I seem a lot of these errors in the log
2017-02-13T11:21:21.389274Z app[web.cluster3-a7576a8e-0894-495a-97fe-c9b1fad9562c]: t=2017-02-13T11:21:21+0000 lvl=warn msg="healthcheck error" component=containerinit name=bailey-live-web port=8080 proto=tcp component=monitor check=tcp://<IP_ADDRESS>:8080 err="dial tcp <IP_ADDRESS>:8080: getsockopt: connection refused"

@dottodot that is an expected error when your app is starting up (containerinit does checks on the process to wait for it to start accepting connections before registering the service and thus leading to existing jobs being stopped).
If your app is being killed due to memory issues, you will see the following in the log:
FATAL: a container process was killed due to lack of available memory

Is that appearing? Do you have any OOM warnings in /var/log/syslog?

I can't see anything like that but since I upgraded the memory I seem to be able to push updates without issue now.

@dottodot are you happy to close this issue then? You should also keep an eye on /var/log/syslog.

Yes, If I run into more issues I'll create a new one.


Enhancement: Update command line help message for --platform

Description
Address #44

Update the command line help message to mention that maccatalyst platform is not included when --platform argument is omitted.

Detailed Design
N/A
Documentation Plan
How has the new feature been documented? Have the relevant portions of the guide been updated in addition to symbol-level documentation?
N/A
Test Plan
How is the new feature tested?
N/A
Source Impact
What is the impact of this change on existing users? Does it deprecate or remove any existing API?
This PR adds additional information to the help message of command option --platform to explain the actual behaviour when the option is omitted.
Actual behaviour:
Line 182 - Sources/CreateXCFramework/PackageInfo.swift
func supportedPlatforms () throws -> [TargetPlatform] {

        // if they have specified platforms all good, if not go everything except catalyst
        let supported = self.options.platform.nonEmpty ?? TargetPlatform.allCases.filter { $0 != .maccatalyst }

        // Omitted ...
}

Checklist

[ ] I've added at least one test that validates that my change is working, if appropriate
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

Hi @bok- do you think it's worthwhile to add this to --platform's argument help message?


Roll Engine from 82ffcced5d1d to b9de8bb20391 (2 revisions)

https://github.com/flutter/engine/compare/82ffcced5d1d...b9de8bb20391
2021-12-16<EMAIL_ADDRESS>[fuchsia][flatland] Tests for FlatlandPlatformView (flutter/engine#29999)
2021-12-16<EMAIL_ADDRESS>maybeGetInitialRouteFromIntent: check if URI data getPath() is null (flutter/engine#29766)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


TypeError when running example plan and version 0.8.0

When running the example with version 0.8.0 I get the below error.

When I pip uninstall titan-core and pip install titan-core==0.7.4, the plan works.
» titan core
» Plan: 3 to add, 0 to change, 0 to destroy.

BTW, Titan looks very nice, looking forward to testing more.

I get the same error.  It appears to be related to GrantedPrivilege.from_grant and PRIVS_FOR_RESOURCE_TYPE returning None, resulting in a NoneType error not ValueType.
granted_priv = GrantedPrivilege.from_grant(
                    privilege="READ",
                    granted_on="IMAGE REPOSITORY",
                    name="SNOWHOUSE_IMPORT.IMAGES.SNOWFLAKE_IMAGES",
                )

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 9, in from_grant
TypeError: 'NoneType' object is not callable

To fix this, I am manually raising ValueError
@dataclass
class GrantedPrivilege:
    privilege: Priv
    on: str  # probably should be FQN

    @classmethod
    def from_grant(cls, privilege: str, granted_on: str, name: str):
        resource_type = ResourceType(granted_on)
        priv_type = PRIVS_FOR_RESOURCE_TYPE[resource_type]

        if priv_type is None:
            raise ValueError(f"{resource_type} has no valid privilege resource")

        priv = priv_type(privilege)
        return cls(privilege=priv, on=name)

Print out:
Privileges for type: IMAGE_REPOSITORY not currently supported: IMAGE REPOSITORY has no valid privilege resource
Cheers

Fixed in v0.8.1. If you have any other questions or issues let me know!

Looks good! Thanks


REST for Octo functions

This Issue depends on https://gitlab.com/YottaDB/DBMS/YDBOcto/-/issues/864
Using the example in the URL above, a GET request to <serviceroot>/Octo/CURRUSERS(10000,19999) would return the users in zip codes 10000 through 19999 whose status is 'Current'.

@ksbhaskar The _weburl.m file I showed you is to be taken by a different project and adapted to its needs. Your request assumes that the code will be created as part of the MWS project itself; but that's not really true. Here's an example of how to use the file: https://gitlab.com/YottaDB/UI/YDBGDEGUI/-/blob/master/r/_weburl.m.


fix(modshare): ensure Bitswap Getter is started

What title says.  Likely forgotten from #3637

Let's not merge this; I suspect this is actually detrimental, and yet it can work without Getter being started. Do you think we should disable that?

Robusta test proved this change useful when used without #3813. #3813 on itself makes timeout issues more prevailing.


#52 Issue with different slides having different words

@rakshith-arch We have some conflicts on this PR, please fix and re-submit! Thanks!


Remove experimental annotations for BQ storage API source

This change removes the Experimental annotations for BigQuery storage API sources. The storage API is now GA, and the sources have been updated to use the GA API surface.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @chamikaramj

Retest this please

LGTM

Run Java PreCommit


Test Geospatial Extension with default table backend

Double check that the extension also works with the default table backend in KNIME AP

Tested with release candidate and default table backend and testflows did run through.


Instead of switching over to module typedefs when appropriate, recurs…

Issue #50 added a switch to typedef search from the "GeneralParent" to the Module Typedef. In some cases the GeneralParent can still contain typedefs that the modules does not have. So we should search both options instead of one of them.

Can you add bare minimal yang files(s) to parser/testdata/typedef/ that exhibit the error?

I will try next week, its a very complicated/nested module definition.


Slew of errors when running the getting started app from webdev.dartlang.org

I'm new to angular dart and upon my first time trying out, using the getting started guide on the webdev.dartlang site I got the following errors.

[x] Dart SDK Version Dart VM version: 2.0.0
[x] AngularDart Version 5.0.0
[x]  macOS

I'm new to angular dart and upon my first time trying out, using the getting started guide on the webdev.dartlang site I got the following errors.
Creating build script, took 8909ms
[INFO] Setting up file watchers completed, took 53ms
[INFO] Waiting for all file watchers to be ready completed, took 196ms
[INFO] Reading cached asset graph completed, took 715ms
[INFO] Checking for updates since last build completed, took 876ms
[INFO] Running build completed, took 559ms
[INFO] Caching finalized dependency graph completed, took 510ms
[SEVERE] build_web_compilers|entrypoint on web/main.dart (cached):
Unable to find modules for some sources, this is usually the result of either a
bad import, a missing dependency in a package (or possibly a dev_dependency
needs to move to a real dependency), or a build failure (if importing a
generated file).

Please check the following imports:

`import 'package:angular/app_component.template.dart' as ng;` from influencer|web/main.dart at 2:1

[SEVERE] build_web_compilers|entrypoint on test/app_test.dart.browser_test.dart (cached):
Unable to find modules for some sources, this is usually the result of either a
bad import, a missing dependency in a package (or possibly a dev_dependency
needs to move to a real dependency), or a build failure (if importing a
generated file).

Please check the following imports:

`import 'package:angular/app_component.dart';` from influencer|test/app_test.dart at 4:1
`import 'package:angular/app_component.template.dart' as ng;` from influencer|test/app_test.dart at 5:1

[SEVERE] build_web_compilers|entrypoint on test/app_test.dart (cached):
Unable to find modules for some sources, this is usually the result of either a
bad import, a missing dependency in a package (or possibly a dev_dependency
needs to move to a real dependency), or a build failure (if importing a
generated file).

Please check the following imports:

`import 'package:angular/app_component.dart';` from influencer|test/app_test.dart at 4:1
`import 'package:angular/app_component.template.dart' as ng;` from influencer|test/app_test.dart at 5:1

[SEVERE] Failed after 1.1s
Serving `web` on http://localhost:8080
Serving `test` on http://localhost:8081
[INFO] Terminating. No further builds will be scheduled
[INFO] Builds finished. Safe to exit

I really have no idea what to do form here as I'm new to the framework and seeing as how this is the getting started guide Sort of expected to just work.  I don't understand ho to debug or fix what seems to be errors concerning missing libraries from within the package itself.

package:angular/app_component.dart is not a file in the angular package. I think you need to update this import to point to a file in your own package.
Guessing that means package:influencer/app_component.dart and package:influencer/app_component.template.dart based on the error message.

yea, sorry about that, Im new to angular, it was a mistake on my part, was up late and didn't realize that I actually had the project in a folder named angular , which is what was causing the issue.
Thanks.


"Mixed Content" error in chrome related to Google Fonts

Bug Report
Issue Summary
On Chrome, there is a "Mixed Content" error in the console when loading any page. Issue is that the page is served through https but the google font is served through http
Expected Behavior
I expected no errors in Chrome.
Observed Behavior
I observed that in the Chrome Dev console there was an error. Fonts not loaded on the page.
Steps to Reproduce

Open page (in Chrome)
View console for message
Font "Poppins" and "Racing Sans One" not loaded

Screenshots (if any)

Fix coming soon

I want to work on this issue.


Executable output is not supported for this target

I download the latest binary and test with qjsc ..\examples\hello.js, however, it failed with Executable output is not supported for this target.
D:\apps\quickjs-2021-03-27-win32-all\bin>cat ..\examples\hello.js
console.log("Hello World");

D:\apps\quickjs-2021-03-27-win32-all\bin>qjs ..\examples\hello.js
Hello World

D:\apps\quickjs-2021-03-27-win32-all\bin>qjsc ..\examples\hello.js
Executable output is not supported for this target

D:\apps\quickjs-2021-03-27-win32-all\bin>ver

Microsoft Windows [Version 10.0.19042.1237]

D:\apps\quickjs-2021-03-27-win32-all\bin>

duplicated with https://github.com/mengmo/QuickJS-Windows-Build/issues/5.


server ingress fails to install/upgrade

Latest chart 4.5 fails to create ingress
helm upgrade --install --namespace aqua csp aqua-helm/server/ -f aqua-helm/values.yaml
UPGRADE FAILED
Error: unable to recognize "": no matches for kind "Ingress" in version "apps/v1"
Error: UPGRADE FAILED: unable to recognize "": no matches for kind "Ingress" in version "apps/v1"

Values.yaml (ingress section)
web:
  ingress:
    annotations:
      kubernetes.io/ingress.class: nginx
    enabled: true
    hosts:
    - aquasec.domain.com
    tls:
    - secretName: aquasec-tls
    - hosts:
      - aquasec.domain.com

Any work around found for this issue yet?

I disabled ingress in aqua chat and created it manually after. Still waiting on fix from them.

They should use v1beta1 as Ingress isn't yet GA - even in k8s version 1.16.x.
You could edit a local copy of the template to reflect the change e.g revert commit:658ba37
On the server/templates/web-ingress.yaml file


Feature request: Expose post scroll callback

This would help with integration with other plugins, for example hlslens.nvim.
Context: https://github.com/kevinhwang91/nvim-hlslens/issues/71#issuecomment-2179050589

Definitely! Hopefully soon I'll be doing a major refactor (switching to async delays etc) and I'll add this in

I've started refactoring here: https://github.com/declancm/cinnamon.nvim/tree/the-refactoring
I have only just started the refactoring so there will be many breaking changes and its missing many features but if you call the scroll function directly (require('cinnamon').scroll) you can play around with the new callback functionality
Note: Haven't updated the README yet so you'll need to check the source for the new function args

Thanks for the heads-up. I will gladly wait for when it's completely finished 🙂
Let me know if you need any help with the testing once it's done

Getting very close to completing the re-write! It would be great if you could try it out

@declancm I have tested the rewritten version. Looks good!
Is it still possible to limit max total scroll time as in the previous version? (if options.delta * nsteps > max_scroll_time, reduce options.delta)

I have also noticed that there is conflicting behavior when using with Aasim-A/scrollEOF.nvim, which I don't remember from the previous version.

I tried that plugin and it seems to be working fine, what behavior are you seeing?

Here's MWE
local root = vim.fn.fnamemodify("./.repro", ":p")
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

local plugins = {
    {
        "declancm/cinnamon.nvim",
        config = function()
            require("cinnamon").setup {
                keymaps = {
                    basic = true,
                    extra = false
                },
            }
        end
    },
    {
        'Aasim-A/scrollEOF.nvim',
        config = true
    }
}

require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

vim.o.scrolloff = 10
vim.o.nu = true

Sometimes when scrolling the blank space at the bottom is preserved, sometimes it is not. This is what happens when I start at the bottom of 29-line long file and try scrolling up and down (C-u and C-d):
https://github.com/declancm/cinnamon.nvim/assets/16707112/05804508-0b53-429d-a124-fc91fa318b32
When I'm moving up/down with j/k the blank space appears again

That commit should fix the issue :)


DELETE on Networks fails due to no owner?

Maybe the network is not being tagged on creation? Investigate
The network creation (?):
#21 02:34:13.385715 POST - /v1.22/networks/_service_use-jobtype-for-workdir_default/disconnect - 81b
#21 02:34:13.385978 Looking up identifier "_service_use-jobtype-for-workdir_default"
#21 02:34:13.386895 Labels for networks/_service_use-jobtype-for-workdir_default: map[]
#21 02:34:13.386905 Allow, networks/_service_use-jobtype-for-workdir_default has no owner
#21 02:34:13.392411 Copied 188 bytes from upstream socket
#21 02:34:13.392528 Error copying request to socket: read unix /var/run/docker/sockguard.sock->@: use of closed network connection
#21 02:34:13.392603 Copied 0 bytes from downstream connection
#21 02:34:13.392660 Done, closing
#22 02:34:13.394162 POST - /v1.22/networks/_service_use-jobtype-for-workdir_default/connect - 146b
#22 02:34:13.394566 Looking up identifier "_service_use-jobtype-for-workdir_default"
#22 02:34:13.395345 Labels for networks/_service_use-jobtype-for-workdir_default: map[]
#22 02:34:13.395363 Allow, networks/_service_use-jobtype-for-workdir_default has no owner
#22 02:34:13.399577 Copied 188 bytes from upstream socket
#22 02:34:13.399674 Error copying request to socket: read unix /var/run/docker/sockguard.sock->@: use of closed network connection
#22 02:34:13.399686 Copied 0 bytes from downstream connection
#22 02:34:13.399690 Done, closing

And the deletion:
#35 02:34:21.982979 DELETE - /v1.22/networks/_service_use-jobtype-for-workdir_default - 0b
#35 02:34:21.983093 Looking up identifier "_service_use-jobtype-for-workdir_default"
#35 02:34:21.986168 Labels for networks/_service_use-jobtype-for-workdir_default: map[]
#35 02:34:21.986217 Allow, networks/_service_use-jobtype-for-workdir_default has no owner
#35 02:34:21.990031 Expected 200 got 500 when detaching Container ID/Name '53593683f70a4d227ba0b62cc968e5b946618e68d701f1e47e2aba817b3b6907' from Network '_service_use-jobtype-for-workdir_default' (before deleting)

#4 19:40:51.250128 POST - /v1.22/networks/create - 76b
2020/03/12 19:40:51 Found unhandled label type <nil>: <nil>

This is likely the culprit...


Standalone map prerequisite: move map to its own primary/base route

workspace/maps/DS_6b79157ec1 ?

workspace/maps/DS_6b79157ec1 ?

You can visit https://qa.clinepidb.org/ce.b27/app/maps/DS_d6a1141fbf

Nice!

Link works. This looks good.


Fix service definition to apply the timeout

addArgument add only one argument at a time to the construtor, right now the timeout configured by the user is never applied and it's always the default (60) value, this fixes it.

@uro can you merge it please?

Hey @gam6itko
Unfortunately, I don't have write access to this repo.
@ASKozienko could you take a look into this pr? Thanks

Thanks for your pull request! We love contributions.
However, this repository is what we call a "subtree split": a read-only copy of one directory of the main enqueue-dev repository. It is used by Composer to allow developers to depend on specific Enqueue package.
If you want to contribute, you should instead open a pull request on the main repository:
https://github.com/php-enqueue/enqueue-dev
Read the contribution guide
https://github.com/php-enqueue/enqueue-dev/blob/master/docs/contribution.md
Thank you for your contribution!

Ok, i did : https://github.com/php-enqueue/enqueue-dev/pull/1084