Vue Tiny Slider Component

Hello,
I'am using the vue-tiny-slider (https://github.com/viktorlarsson/vue-tiny-slider) as component.
Here is the script code in the page:

And this is the HTML
      <tiny-slider :mouse-drag="true" :loop="false" items="1" gutter="20">
                <post-resume v-for="post in $page.allPost.edges"
                             :key="post.node.id"
                             :title="post.node.title"
                             :media="post.node.media"
                             :path="post.node.path"
                             :excerpt="post.node.excerpt"></post-resume>
            </tiny-slider>

The slider works at development profile, but when i build the proyect it fails
throwing this error at the console:
Failed to render /blog
ReferenceError: window is not defined
    at Object.198 (node_modules/vue-tiny-slider/dist/index.js:1:234)
    at __webpack_require__ (webpack/bootstrap:25:0)
    at Module.203 (assets/js/page--src--pages--blog--index-vue.6a945117.js:138:12)
    at __webpack_require__ (webpack/bootstrap:25:0)

Why? Is the implementing ok?
Thanks!

Hi,
I've run into this issue as well. This will break in the build process because in node.js there's no window object, which this plugin exposes and most likely relies on. Please have a look at this page in the gridsome documentation https://gridsome.org/docs/assets-scripts/#without-ssr-support . What to pay attention to is the  tag and the dynamic import of requested components (tiny slider in this case).

Hello,
Thanks for the answer. I' have change my code to:

And the HTML is:
<template>
    <Layout>
        <ClientOnly>
            <carousel :mouse-drag="true" :loop="false" items="1" gutter="20">
                <slide>a</slide>
                <slide>b</slide>
            </carousel>
        </ClientOnly>
    </Layout>
</template>

And now i get this error:
vue.runtime.esm.js?2b0e:3586 Uncaught (in promise) TypeError: Cannot read property '__esModule' of undefined
    at ensureCtor (vue.runtime.esm.js?2b0e:3586)
    at eval (vue.runtime.esm.js?2b0e:3659)
    at eval (vue.runtime.esm.js?2b0e:336)
```
I think the code is correct, is that so?

Thanks!

The vue-tiny-slider export is a bit different. Try with this code instead:
export default {
  components: {
    TinySlider: () => import('VueTinySlider')
  }
}

<Layout>
  <ClientOnly>
    <TinySlider :mouse-drag="true" :loop="false" items="1" gutter="20">

Slider item #1

    </TinySlider>
  </ClientOnly>
</Layout>

Perfect, now works in dev and i can build the project. Thanks!


New ways to run tunnelmole

npx tunnelmole 8080 will just work automatically with latest nodejs runtime

yep works well thanks.


Remove or replace driver/ppm_syscall.h

Motivation
As part of our continuous effort to align with CNCF IP Policy, we requested a license scan. This scan revealed no outstanding issues, but there were a couple of recommended action items.
One reported action item is:

Action Item 3:  Remove or replace one file that has the GPL-2.0 license.
-- https://github.com/falcosecurity/libs/blob/master/driver/ppm_syscall.h
-- NOTE: this file does not have the Linux-syscall-note exception, but appears to be a system header file, however it has a Red Hat copyright.  This file should be removed or replaced to avoid a license conflict.

Feature
TBD
Alternatives
:thinking:
Additional context
It looks like ppm_syscall.h is only require to support kernels <=2.6.20 cc @Andreagit97

yes it is required only to support  kernels <=2.6.20


pyright: 1.1.380 -> 1.1.381

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for pyright is: Type checker for the Python language
meta.homepage for pyright is: https://github.com/Microsoft/pyright
meta.changelog for pyright is: https://github.com/Microsoft/pyright/releases/tag/1.1.381
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.1.381 with grep in /nix/store/mckvwc71n0b6vyprrr7jx8kspqm9918c-pyright-1.1.381
found 1.1.381 in filename of file in /nix/store/mckvwc71n0b6vyprrr7jx8kspqm9918c-pyright-1.1.381

Rebuild report (if merged into master) (click to expand)

112 total rebuild path(s)

112 package rebuild(s)

First fifty rebuilds by attrpath

aider-chat
chatblade
chatgpt-retrieval-plugin
checkov
home-assistant-component-tests.openai_conversation
imaginer
khoj
llm
mealie
open-interpreter
open-webui
openai
openllm
pentestgpt
pyright
python311Packages.graphrag
python311Packages.guidance
python311Packages.inline-snapshot
python311Packages.instructor
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-chroma
python311Packages.langchain-community
python311Packages.langchain-core
python311Packages.langchain-huggingface
python311Packages.langchain-mongodb
python311Packages.langchain-ollama
python311Packages.langchain-openai
python311Packages.langchain-standard-tests
python311Packages.langchain-text-splitters
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langsmith
python311Packages.litellm
python311Packages.llama-index
python311Packages.llama-index-agent-openai
python311Packages.llama-index-cli
python311Packages.llama-index-core
python311Packages.llama-index-embeddings-gemini
python311Packages.llama-index-embeddings-google
python311Packages.llama-index-embeddings-huggingface
python311Packages.llama-index-embeddings-ollama
python311Packages.llama-index-embeddings-openai
python311Packages.llama-index-graph-stores-nebula
python311Packages.llama-index-graph-stores-neo4j
python311Packages.llama-index-graph-stores-neptune

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mckvwc71n0b6vyprrr7jx8kspqm9918c-pyright-1.1.381 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A pyright https://github.com/r-ryantm/nixpkgs/archive/fa4850bc95c59ba224f4382d848092bc6f091679.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/fa4850bc95c59ba224f4382d848092bc6f091679#pyright

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mckvwc71n0b6vyprrr7jx8kspqm9918c-pyright-1.1.381
ls -la /nix/store/mckvwc71n0b6vyprrr7jx8kspqm9918c-pyright-1.1.381/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


random keepers: terraform state to keep state

I'm still testing this, i tried it and couldnt seem to get it to work...
I'm wondering if its the way "${data.aws_secretsmanager_secret_version..secret_strirds_master_secretng}" is read, it always thinks its new (maybe it doesnt keep a state of it?) , or maybe i did something wrong

So you have applied that multiple times and it still keeps generating new ones?


Finish porting arachnid into dynamorse - HTTP in and out.

Finish porting the prototype implementation of arachnid into dynamorse and document. Arachnid provides a simple encapsulation of NMOS grains/flows in HTTP or HTTP transport that can be carried via push or pull. The streams can be transported in parallel and, within reason, out of order.

[ ] Link in with NMOS sender/receiver model.

Arachnid is labelled as Streampunk Media arachnid to make it clear that this is not an AMWA or NMOS RFC or specification at this time. This is intended as an open specification and will be offered to the AMWA as an RFC as soon as it is sufficiently mature.

Created new branch arachnid.

Drafted pull (arachnid specification)[/Streampunk/arachnid].

Initial implementation of arachnid is now merged onto the master branch. It has the following limitations:

pull mode only;
demo self-signed certificates at fixed paths for HTTPS;
client does not do authorization checks against known CAs;
TLS transportation appears to be serialized, possibly due to the use of a single session;
fragmentation mode not supported;
fixed limit to the maximum drift between each thread - should scale based on number of threads.

Tasks to fix:

[ ] Finish designing and implement push mode;
[ ] Add ability to start dynamorse with user-configured certificates;
[ ] Support authorization of certificates by well known authorities;
[ ] Investigate using multiple session IDs, one per thread;
[ ] Implement support for large grain fragmentation;
[ ] Add dynamic parameterisation of maximum timestamp drift per thread.


fix: prevent A <-> B @hasOne or @hasMany relationships with DS

If DataStore is enabled, Model A cannot have a @hasOne or @hasMany relationship with Model B if Model B also has a @hasOne or @hasMany relationship with Model A.

@cjihrig the expected error messages in the unit tests need to be updated as well, right?

@iartemiev we'll see how the CI run goes, but it should be fine according to https://jestjs.io/docs/expect#tothrowerror


Add print styles to show all profile details on need page when printing

This expands all the profile areas when printing, and makes the accordion titles more visible on a white background. I'm sure we could improve the print styles significantly, but for now I wanted to make sure at least those key fields are displayed (assuming a need may be printed out and handed to a driver).

 Printing a need should have all accordions expanded (and probably navbar hidden)


Events with the same ID are being received twice

We are encountering an issue where sometimes, events with the same ID are being received twice.
The events are being published via publishAndWaitForReply. We are not sure if the event is always received twice, or only sometimes. We also do not know if it's due to a race condition.
Is this known behavior? What are your thoughts?

It's important to emphasize that it could also be the publish method publishing the event twice. We're not fully sure, but there's definitely a bug there somewhere.

If you give me a reproducible example I will take a look at it.

If you give me a reproducible example I will take a look at it.

Sure thing! I think I can have that ready next week.

Here's a simple repro:
async function createFtrackEventSession() {
  const session = await createFtrackSession();

  session.eventHub.connect();

  const signal = AbortSignal.timeout(10_000);
  while (!session.eventHub.isConnected && !signal.aborted) {
    await delay(10);
  }

  if (signal.aborted) {
    throw new Error('Could not connect to the Event Hub within the timeout.');
  }

  return session;
}

test.only('Event hub receives event twice', async () => {
  const session = await createFtrackEventSession();

  const events = new Set<EventPayload>();
  await session.eventHub.subscribe('topic=*', e => {
    events.add(e);
    return { reply: 'hi!' };
  });

  await session.eventHub.publishAndWaitForReply(
    new Event('wats.test', {}),
    { timeout: 10_000 },
  ) as any;
  expect(events.size).toBe(1);
});

Here, for me, events.size is always 2 instead of 1.

Your test code is picking up the reply that the subscription is sending in return - it's endlessly sending itself "hi!" as a reply to itself.

Yes, but shouldn't the size then be 1? Where is the other event coming from?

Aaaah, I see. That's probably

Also, it seems the ID of the events are the same?

How do I detect if something is a reply?
It has the topic ftrack.meta.reply and a inReplyToEvent is not null

Also, it seems the ID of the events are the same?
Not in my tests

Also, would be awesome if this was clarified in the documentation. When people subscribe to events, I don't think they want to subscribe to replies.
Usually applications subscribe to specific topics.

Does the Python client also do this?
For this, the subscription parsing should work the same. There are some more advanced topic parsing available in the python client that is absent from the JavaScript client.

To me, the replies functionality should be internal behavior somehow.
Replies is just another event, but with specified syntax. But that could definitely be expanded upon in the documentation.

Thank you for the update!
Ah yes. That was based on what we saw in production, but perhaps that was because  didn't have a inReplyToEvent check.
I guess I need to extend my tests so they spam events a bit more.
But before I do that, I have one question. Can replies to events also have the same ID as the event itself?

If two events ever have the same ID, no matter if they are replies or not, that is a major bug and really needs to be investigated. All events created with the Event Constructor have a randomly generated UUID.

The same event might be handled multiple times (Multiple subscribers might handle it), but each event should have a unique ID.

Yeah okay.
It only happens rarely, but after all this, I suspect the error might be on our side. I'll reopen when I know more. Sorry for the inconvenience.

This is happening again. We are trying a better repro.

We were able to reproduce the issue, with random number of events coming through using this test format:
test.only('Event hub receives event once', async () => {
  const session = await createFtrackEventSession();
  // await createFtrackEventSession();
  // await createFtrackEventSession();
  // await createFtrackEventSession();
  const events = new Array<EventPayload>();
  session.eventHub.subscribe('topic=*', async e => {
    if (e.inReplyToEvent) {
      return;
    }
    console.log('event received', e);
    if (events.some(x => x.id === e.id)) {
      throw new Error(`Event received twice: ${e.id}`);
    }
    events.push(e);
    await session.eventHub.publishReply(e, {});
  });
  // const promises = [
  //   session.eventHub.publishAndWaitForReply(
  //     new Event(`wats.test${uuidv4()}`, {}),
  //     { timeout: 10_000 },
  //   ) as any,
  // ];
  // await Promise.all(promises);
  await session.eventHub.publish(
    new Event(`wats.test${uuidv4()}`, {}),
    { timeout: 10_000 },
  ) as any;

  await delay(5_000);
  console.log(events);
  await delay(5_000);
});

When running the test, the same event is received multiple times, with the exact same payload:

Thank you. I'll look into it.

Thanks

And here are the relevant functions we use for connecting.
let ftrackSessionPromise: Promise<Session> | undefined;

export async function createFtrackSession() {
  if (ftrackSessionPromise) {
    return ftrackSessionPromise;
  }

  async function createSession() {
    const credentials = ftrackWidget.getCredentials();

    const ftrackApiKey = credentials?.apiKey || await getParameterStoreValue('/ftrack/api-key');
    const ftrackServerUrl = credentials?.serverUrl || await getParameterStoreValue('/ftrack/server-url');
    const ftrackApiUser = credentials?.apiUser || await getParameterStoreValue('/ftrack/api-user');

    const session = new Session(
      ftrackServerUrl!,
      ftrackApiUser!,
      ftrackApiKey!,
    );

    return session;
  }

  ftrackSessionPromise = createSession();
  return ftrackSessionPromise;
}

export async function createFtrackEventSession() {
  const session = await createFtrackSession();

  session.eventHub.connect();

  const signal = AbortSignal.timeout(10_000);
  while (!session.eventHub.isConnected && !signal.aborted) {
    await delay(10);
  }

  if (signal.aborted) {
    throw new Error('Could not connect to the Event Hub within the timeout.');
  }

  return session;
}

Not sure if they can be the cause of it too, so here they are.

When I try to replicate it it still looks like it's an issue of multiple subscribers being registered, not multiple events being sent. If you add the UUID to the console log in the subscriber and in the final event console log you can more easily see that behaviour.

test.only('Event hub receives event once', async () => {
  const session = await createFtrackEventSession();
  const uuid = uuidv4();
  // await createFtrackEventSession();
  // await createFtrackEventSession();
  // await createFtrackEventSession();
  const events = new Array<EventPayload>();
  session.eventHub.subscribe('topic=*', async e => {
    if (e.inReplyToEvent) {
      return;
    }
    console.log('event received', uuid, e);
    if (events.some(x => x.id === e.id)) {
      throw new Error(`Event received twice: ${e.id}`);
    }
    events.push(e);
    await session.eventHub.publishReply(e, {});
  });
  // const promises = [
  //   session.eventHub.publishAndWaitForReply(
  //     new Event(`wats.test${uuidv4()}`, {}),
  //     { timeout: 10_000 },
  //   ) as any,
  // ];
  // await Promise.all(promises);
  await session.eventHub.publish(
    new Event(`wats.test${uuid}`, {}),
    { timeout: 10_000 },
  ) as any;

  await delay(5_000);
  console.log(uuid, events);
  await delay(5_000);
});

I don't know, sorry. But from the samples I've seen so far this does not look like a bug in the API Client.

Interesting. We'll see if we can dive more into the way we run the tests. Perhaps try it on brand new setups or something. Will re-open if relevant.
Sorry for all the ups and downs on this rollercoaster-type issue 😆


Accept "stop" command

This stops the search and outputs bestmove. We'll want to differentiate between search stop and search abort which is triggered when another search is kicked off (without sending stop).

2f5640da8a8aa62fd38703b035610091ca5b961c


[feat] better documentation for upgrading and backing up docker-compose based installation

I'm using these docs to run zwavejs2mqtt: https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/docker?id=run-as-a-service
My image is currently out of date.  What is the proper way to upgrade it?  Maybe docker compose down && docker compose up -d ?  Will that preserve my configuration?  Will it pull thew new latest image?
Also, it may be good to add some tips/ideas on how to back up the entire volume and thus the configuration that is on it.
Thanks!

About the backup there is an open issue to add an automatic backup of application/controller data that it's in my TODOs. About your question for upgrading just do:
docker-compose pull && docker-compose up -d


Linux getting "CompletionService: Could not find document for file" in LSP mode

I am using release 1.38.2 - omnisharp-linux-x64-net6.0.tar.gz
lsp server command:  dotnet [ '/lsp-server/omnisharp/OmniSharp.dll', '-lsp' ]
If I try to pass any input to the LSP server, I get this error:
"OmniSharp.Roslyn.CSharp.Services.Completion.CompletionService: Could not find document for file /13764770-cc63-11ec-aaac-b3713373339b/file.cs | 0='/13764770-cc63-11ec-aaac-b3713373339b/file.cs'"
And if I check the path of file.cs file which is created, then it's present  at exact same directory.
Can anyone help me with what might be wrong with the LSP server ? (Tested using Monaco editor)
This is not specific to net6.0, happens with mono as well (Given codebase is same, it's a different issue), so is there any configuration which I might be missing ?
Trimmed logs:
MESSAGE:  {
  jsonrpc: '2.0',
  method: 'window/logMessage',
  params: {
    type: 3,
    message: "OmniSharp.LanguageServerProtocol.LanguageServerHost: Omnisharp server running using Lsp at location '/app' on host 20. | "
  }
}
MESSAGE:  {
  jsonrpc: '2.0',
  method: 'textDocument/didChange',
  params: {
    textDocument: {
      uri: 'file:///13764770-cc63-11ec-aaac-b3713373339b/file.cs',
      version: 2
    },
    contentChanges: [ [Object] ]
  }
}
MESSAGE:  {
  jsonrpc: '2.0',
  id: 1,
  method: 'textDocument/completion',
  params: {
    textDocument: { uri: 'file:///13764770-cc63-11ec-aaac-b3713373339b/file.cs' },
    position: { line: 0, character: 1 },
    context: { triggerKind: 1 }
  }
}
MESSAGE:  {
  jsonrpc: '2.0',
  id: 2,
  method: 'textDocument/completion',
  params: {
    textDocument: { uri: 'file:///13764770-cc63-11ec-aaac-b3713373339b/file.cs' },
    position: { line: 0, character: 1 },
    context: { triggerKind: 1 }
  }
}
MESSAGE:  {
  jsonrpc: '2.0',
  method: 'window/logMessage',
  params: {
    type: 3,
    message: "OmniSharp.Roslyn.CSharp.Services.Completion.CompletionService: Could not find document for file /13764770-cc63-11ec-aaac-b3713373339b/file.cs | 0='/13764770-cc63-11ec-aaac-b3713373339b/file.cs'"
  }
}
MESSAGE:  {
  jsonrpc: '2.0',
  method: 'window/logMessage',
  params: {
    type: 3,
    message: "OmniSharp.Roslyn.CSharp.Services.Completion.CompletionService: Could not find document for file /13764770-cc63-11ec-aaac-b3713373339b/file.cs | 0='/13764770-cc63-11ec-aaac-b3713373339b/file.cs'"
  }
}

You need to have a project file available, since files are added to the workspace through projects.

Any update on this?

@filipw can you please check the filestructure and confirm if anything is missing out? cc/ @shashank-sharma


Question on Matrix

I am now exploring your Matrix modular and read the README file, but it is not working as I expect.
If you put a RED PIN in the top left position, shouldn't the output of OUT1 be INA+INA (which should be equal to 1.0). I have INA, INB, and INC set equal to 0.5 in the Voltmeter and then I leave the last volt meter reading to be OUT1.
I am on a Mac and just now compiled your modules.
LOGMatrixTest.vcv.zip

Hi,
you got it correct, but there is a scaling factor at the end that is the inverse of the number of inputs, i.e.
out1[i] = out1[i] / NUM_INPUTS_2
I put this to avoid too large values. Of course, if you feel that this behavior is not desired you can remove that line in the code (both for top and bottom matrices) or I can do that if this is not required by other users as well.

Thanks - I now follow the logic. I suggest though that you add the above to your README file when explaining the operation.

Thanks


[analyzer] Handle two kinds of implicit includes differently

There are two kinds of GCC-specific implicit include header files. One
is "include-fixed" and the other are those which contain an ...intrin.h
header files. Until now both of these have been skipped by default and
both could have been kept by --keep-gcc-include-fixed flag during
analysis.
It is clear that ...intrin.h headers are very much GCC-specific, so for
sure these have to be skipped most of the time. These header files
contain some function symbols on vectoriztaion operations (such as
_mm_xor_ps) of which the implementation is an 1-to-1 mapping to a
__buildin... GCC symbol. Of course these built-ins can't be seen by
Clang, however, Clang provides its own headers with the same
_mm_xor_ps-like functions that have some straightforward implementation
(i.e. no __builtin symbols used).
From now --keep-gcc-include-fixed flag keeps only include-fixed
directory from the implicit include path list and not the intrin.h
files. So this commit changes the semantics of this flag. In case
somebody wants to keep intrin.h files (I don't know why would he or she
do that, since these are incomatible with Clang) then --keep-gcc-intrin
can be used.
I don't know what error could occur if include-fixed is always kept by
default. I think this could be the default behavior. Anyway, in these
questions we are always defensive, so using it or not can be the
decision of the user. The only difficulty which remains is what happens
if there are some headers necessary for the analysis in a folder which
contains intrin.h headers too. Currently this case can't be supported.

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- analyzer/tests/unit/test_option_parser.py  1

Clones added
============
- analyzer/codechecker_analyzer/cmd/check.py  1
- analyzer/codechecker_analyzer/cmd/analyze.py  1

Clones removed
==============
+ analyzer/codechecker_analyzer/buildlog/log_parser.py  -1

See the complete overview on Codacy


[SC-40] end user needs access to provision products

We added deny GetTemplateSummary policy to restrict access to secrets however this also blocks provisioning of products.  Remove this policy to unblock provisioning.

We haven't needed this so far so going to abandone it.


Broken links in Class view

In puppetboard 4.3.0 when ENABLE_CLASS = True, in class view when you click on the class name you get 'Not Found' message. I presume it should lead to https://raw.githubusercontent.com/voxpupuli/puppetboard/master/screenshots/class.png instead

cc: @lcharreau

Hello @vchepkov
I'm sorry but I can't reproduce this case.
Here is my most minimal docker-compose configuration with a single worker, without a scheduler to pre-compute the results (default SCHEDULER_ENABLED=False) and using the cache memory (default CACHE_TYPE=SimpleCache):
services:
  puppetboard:
    container_name: puppetboard
    hostname: puppetboard
    image: ghcr.io/voxpupuli/puppetboard:4.3.0
    restart: unless-stopped
    ports:
    - <IP_ADDRESS>:8082:80
    volumes:
    - "/etc/puppetlabs/puppetdb/ssl:/etc/puppetlabs/puppetdb/ssl:ro"
    extra_hosts:
    - <puppetdb_hostname>:<IP_ADDRESS>
    environment:
    - PUPPETBOARD_WORKERS=1
    - PUPPETDB_HOST=<puppetdb_hostname>
    - PUPPETDB_PORT=8081
    - PUPPETDB_PROTO=https
    - PUPPETDB_SSL_VERIFY=/etc/puppetlabs/puppetdb/ssl/ca.pem
    - PUPPETDB_KEY=/etc/puppetlabs/puppetdb/ssl/private.pem
    - PUPPETDB_CERT=/etc/puppetlabs/puppetdb/ssl/public.pem
    - ENABLE_CLASS=True
    # - SCHEDULER_ENABLED=True
    # - CACHE_TYPE=MemcachedCache
    - UNRESPONSIVE_HOURS=16
    networks:
      app_net:
        ipv4_address: <IP_ADDRESS>
  # memcached:
  #   container_name: memcached
  #   hostname: memcached
  #   image: memcached:latest
  #   restart: always
  #   networks:
  #     app_net:
  #       ipv4_address: <IP_ADDRESS>

networks:
  app_net:
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: <IP_ADDRESS>/24

If I understand well, you see the list of Puppet classes with the columns "Nb nodes", "Failure", ...
and when you click on a class to display the concerned nodes, you have a 404 error "Not Found" ?
What do you have in the href link of the class?
${class_name}


bert_extraction - train_victim_squad.sh error fix

Fixes a couple of breaking issues in train_victim_squad.sh

This pair is very prevelant across many python scripts in the "bert_extraction" folder.

import tensorflow.compat.v1 as tf
app = tf.compat.v1.app

It throws the error
`AttributeError: module 'tensorflow._api.v1.compat.v1.compat' has no attribute 'v1'
I use tensorflow 1.15 and elsewhere in the project tf.app() is directly and correctly used. This incorrect usage has been observed in multiple files across bert_extraction project.

A typo on the flag to evaluate_squad.py.
`

If an author or maintainer can confirm the compat.v1 issue, I will bundle all the incorrect references covered in the python scripts called in run_extraction_squad.py too.

Thanks for the fix!


Unable to install package in Unity Package Manager

Before installing com.gamgaroo.mvvm, its required to manually install dependent package com.gamgaroo.reactive. At this moment I don't know if this is a UPM bug or "feature" or how to fix this.

This is solved by Scoped Registries (Docs). That's not an ideal solution, but for now this issue is closed.


read_until_da1 timeout cause slow startup

What system are you running Yazi on?
Linux X11
What terminal are you running Yazi in?
internal research
yazi --debug output

##### ↓↓↓ Paste the output here: ↓↓↓ #####
❯ yazi --debug

Yazi
    Version: 0.2.5 (23a56c2 2024-07-31)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.2.5

Emulator
    Emulator.via_env: ("xterm-256color", "")
    Emulator.via_csi: Ok(Unknown([]))
    Emulator.detect : Unknown([])

Adapter
    Adapter.matches: Chafa

Desktop
    XDG_SESSION_TYPE: None
    WAYLAND_DISPLAY : None
    DISPLAY         : None

SSH
    shared.in_ssh_connection: false

WSL
    /proc/sys/fs/binfmt_misc/WSLInterop: false

Variables
    SHELL              : Some("/bin/zsh")
    EDITOR             : Some("nvim")
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None
    ZELLIJ_SESSION_NAME: None

Text Opener
    default: Some(Opener { run: "${EDITOR:=nvim} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "${EDITOR:=nvim} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })

tmux
    TMUX   : false
    Version: 3.4

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: No such file or directory (os error 2)
    magick           : No such file or directory (os error 2)
    fzf              : 0.53.0
    fd               : No such file or directory (os error 2)
    rg               : 13.0.0
    chafa            : No such file or directory (os error 2)
    zoxide           : No such file or directory (os error 2)
    7z               : No such file or directory (os error 2)
    7zz              : No such file or directory (os error 2)
    jq               : jq-

--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "/root/.local/state/yazi" directory.

Did you try the latest nightly build to see if the problem got fixed?
Yes, and I updated the debug information above (yazi --debug) to the nightly that I tried
Describe the bug
just run yazi, will hint the read_until_da1 timeout 10s, it seems to start slowly.
thought this issue:
echo -e '\033[?12$p\033P$q q\033\\\033[?u\033[c'; cat
output:
^[P1$r2 q^[\

Expected Behavior
To Reproduce
just run yazi with default config
Configuration
default config
Anything else?
yazi.log
  2024-07-31T02:03:32.067602Z  WARN yazi_adapter::emulator: [Adapter] No special environment variables detected
    at yazi-adapter/src/emulator.rs:70

  2024-07-31T02:03:32.067625Z  WARN yazi_adapter::emulator: [Adapter] Unknown TERM_PROGRAM:
    at yazi-adapter/src/emulator.rs:84

  2024-07-31T02:03:32.067627Z  WARN yazi_adapter::emulator: [Adapter] Unknown TERM: xterm-256color
    at yazi-adapter/src/emulator.rs:92

  2024-07-31T02:03:42.068307Z ERROR yazi_adapter::emulator: read_until_da1 timed out: [], error: Elapsed(())
    at yazi-adapter/src/emulator.rs:213

  2024-07-31T02:03:42.068356Z  WARN yazi_adapter::adapter: [Adapter] Could not identify XDG_SESSION_TYPE
    at yazi-adapter/src/adapter.rs:101

  2024-07-31T02:03:42.068379Z  WARN yazi_adapter::adapter: [Adapter] Falling back to chafa
    at yazi-adapter/src/adapter.rs:113

  2024-07-31T02:03:42.068813Z  WARN yazi_adapter::ueberzug: ueberzugpp spawning failed: No such file or directory (os error 2)
    at yazi-adapter/src/ueberzug.rs:87

  2024-07-31T02:03:52.074349Z ERROR yazi_adapter::emulator: read_until_da1 timed out: [], error: Elapsed(())
    at yazi-adapter/src/emulator.rs:213

What's "internal research" terminal? How can I use it to reproduce the issue?

Terminal tools within the company, if use iterm with ssh, will working fine.

You need to ensure that your company's internal terminal tools have the capability to correctly respond to the DA1 sequence, see https://vt100.net/docs/vt510-rm/DA1.html
Closing as not Yazi


create user-friendly log for the TRAPI output

Currently, the TRAPI response contains a very verbose "log" object. That log is not very useful for most BTE users, but very useful for developers and experts to debug. In https://github.com/biothings/BioThings_Explorer_TRAPI/issues/304, we will change behavior so that verbose log can be retrieve on demand, leaving the log field in the TRAPI output to be empty (except for a link to the verbose log).  In this ticket, we want to design and create a new "log" object for inclusion in the TRAPI output that is a more user-friendly summary of the BTE execution.

This issue is to discuss and plan our approach. Later we may make a post w/ a checklist + open issues to tackle each bite-sized task.
I'm tagging others @andrewsu @newgene @tokebe @marcodarko @ariutta @ericz1803 so we can discuss what logs are actually useful and where those go.
My categories are:

Logs to keep in the TRAPI response for users / helping devs understand issues w/o needing to login to BTE's server or see a console
Console logs only for local dev troubleshooting / exploratory code

My thoughts:
Use consistent language to describe what's happening in logs: what are
Logs to keep in the TRAPI response (for users / helping devs understand issues):
A summary of the overall execution process:
What was the order of execution for QEdges? What QEdges were reversed?
A summary of the response, similar to ARAX?
Number of nodes / edges in the knowledge-graph
Number of results in the results section
Number of unique sources (involves pulling edge-property provenance info)
Or instead the number of APIs w/ data in the response?
List of APIs that are unavailable when the query is executed
These are APIs in our config file. But when the cron job is run, we sometimes fail to get the /meta_knowledge_graph response. Therefore our predicates file should lack that API's operations
A summary of sub-query failure: useful info for us to adjust timeout / size of batch / figure out downstream API issues
Probably one for each QEdge?
For each failure:
What API?
What was the operation (subject semantic type, predicate, object semantic type)?
How many input IDs
What was the failure? Often the 50-sec timeout was exceeded
Asyncquery's internal job ID - already implemented
Console logs (only for local dev troubleshooting):
Having a log that makes it clear when the workflow moves from 1 module to another, and what data is being handed off (its structure / format?)
Making the logs at the end of a hop's execution easier to understand / summarized:
What is happening to curies + records (  biothings-explorer-trapi:UpdatedExeEdge,NewQNode, and edge-manager)? It looks like an iteration is happening through the QEdges until no more revisions happen, but it's not clear to me what is happening and why…

@andrewsu @colleenXu Given that our TRAPI log responses have to conform to the TRAPI logEntry standard, which is used in ARAX to separate out different log levels, I think it might make sense to flip this problem slightly on its head.
Instead of returning a sort of execution summary and providing an endpoint to retrieve verbose logs as in #304, we may wish to instead return verbose logs by default as we currently do, and provide an endpoint to retrieve an execution summary, which we can link to in our verbose logs (similarly to how we provide the link to check the job status)?
Either way, I'm working on trying to come up with some standardized information structure we can side-load into our internal logEntry object to use for easily generating this summary based on the above desired info, will follow up with that when it's complete.

I'm not clear on what the LogEntry is meant to be used for, from the TRAPI team / Translator consortium perspective.... It certainly seems like other teams don't put as much info there as we do...

Things I think we can put into TRAPI logs (per discussion at our meeting):

The actual KG edges process (summarized in @colleenXu 's comment above)
Errors during the above process (fail to call an API, to do id normalization etc)
Execution summary at the end for a success run
Possible other required log msgs decided by the TRAPI standard

If needed, we can also potentially put some logs (e.g. execution summary?) as a link in the TRAPI log entry, just for the purpose of reducing the log size.

notes from 1/5 meeting:

Jackson said we could use the LogLevel part of TRAPI LogEntry better: organize them into info/debug/error/warning, which ARAX organizes in its display.

we are discussing a change to what we put into the TRAPI Logs vs elsewhere. We are generally talking about reducing the amount of TRAPI logs we currently make + changing the logs we do make (console / TRAPI) to be more useful

Jackson mentioned bull logging which is something separate as well...

Chunlei mentioned "progress" status

Some further ideas:

The TRAPI standard specifies log_level as part of a TRAPI query, implying that it's up to the user to decide the verbosity of the logs they receive
This in mind, we could keep the majority of current logs as DEBUG level, and set new summaries as INFO
We could then create summaries wherever appropriate, or at the end of execution, and they would be substantially easier to read on ARAX, or to filter for looking through raw JSON.

I think this could be a good solution.
However, I wonder if we still want to review / edit the current logs. I've found some of the TRAPI logs unhelpful or confusing, hence #379 and some discussion on how to make some things clearer like edge execution order / reversing and switching from 1 module to another...

@colleenXu Agreed, a general pass to make all logs more clear/useful is also in order and I'll be doing what I can there. Once I have a PR submitted it can be tested/reviewed for further worthwhile changes.

in our talk today @tokebe, we discussed next steps (after Jackson's first iteration). This would likely involve discussions with the whole teams and other devs' involvement:

discussing #379 and getting a standard for this team to use
reviewing the TRAPI log statements and making them useful / clear (might involve editing the underlying console logs)

We saw that there are a LOT of console log statements, and a step-wise approach would likely work best there (rather than reviewing all of them at once). For example:

@marcodarko reviewing the edge-handling logs (console/TRAPI) and making them easier to understand. For example, why are we iterating through the edges multiple times? During an intersection, what node and edges are involved?
reducing / removing logs that are super-long

Above are new PRs addressing most of what's been discussed here for the first pass.
Like @colleenXu said, next pass will be more refinement of TRAPI logs (cutting unnecessary ones, making others more informative/using proper log level, adding useful logs, conforming language usage to a clear standard). I will see where I can do this but some logs are better changed by devs who are more familiar with specific sections.
Console logs are a lower priority but a running list of console log items which could stand to be shortened/removed will help for making the console logs a little easier to follow visually.

related to https://github.com/biothings/BioThings_Explorer_TRAPI/issues/392

I'm marking this issue as closed. Obviously care must be taken as time goes on to find new areas to improve logging readability/information, however most of the issues with existing TRAPI logs have been fixed.
A sort of post-mortem list of continuing objectives determined in this issue (could stand to be added to a coding guide document):

TRAPI logs priorities (in order):

Readable
Informative
Short

Try to apply the above priorities to console debug() logs as well, where applicable.
Strive to use TRAPI log levels as best as possible. A general guide:

If a random user doesn't need to know or probably wouldn't care unless they're digging into execution, it should be DEBUG. Consider if it should even exist at the DEBUG level. Does it give routinely useful information to a developer, or just kind of say that a specific fine-grain stage happened? If the latter, perhaps keep it only as a console debug() log.
If the user might want to know, or it summarizes a lot of other debug logs in a way that might still be useful to a user trying to gain cursory execution understanding, then it might fit at the INFO level.
If something has gone wrong, but it doesn't affect how the user should consider their results (could be missing results due to an API being down, but nothing will be 'wrong', etc.), it should probably be a WARNING.
If something has gone wrong, and it constitutes an internal code failure, or affects how the user should consider their results (could be incomplete/incorrect/etc.), it should probably be an ERROR.


Add a base ffi

Use a generated lib.rs for compiling and testing
Make sure sys is a dependency

Most of this commit is generated by rust bindgen. We probably will want to pull in just the needed bits, but for now this gets us compiling and ready to start writing tests


Uncaught Error: Encryption scheme unsupported

I am trying to open an Excel 95-2004 password protected xls file and I get the console error, Uncaught Error: Encryption scheme unsupported. I was wondering why that could be? I saw that these excel files use RC4 Encryption and looking through the code I see a method parse_RC4CryptoHeader(), is that not the method that would decrypt the file?

@calebiosu issue will being tracked in the XLSX tracker


Fixed the calculation of ETH addition / refund for validator creation / exit

The calculation changes fixes bugs that could arise due to changing bond requirements after a node has already created validators.

Looks good 🙏


#1 Fix crashes on EmptyIterator

Codecov Report

Merging #2 (953aa3d) into main (1b601f5) will not change coverage.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##                main        #2   +/-   ##
===========================================
  Coverage     100.00%   100.00%
- Complexity         7         9    +2
===========================================
  Files              1         1
  Lines             27        27
===========================================
  Hits              27        27

Impacted Files
Coverage Δ

src/Synchronization.php
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Add Ror & Linters

Hello Code Reviewer 👋 👋
In this pull request following changes have been made:

[x] Created a new Rails API app called 'hello-rails-backend'.
[x] The project has a Postgres database set up.
[x] Created a table for storing messages and add 5 different greetings.
[x] Created an API endpoint that selects a random greeting from the table.

Front End link
https://github.com/ohyajk/hello-react-frontend

Hi @ohyajk
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉
Highlights
✔ App has both frontend and backend repositories correctly linked in readmes
✔  Created greeting route and controller
✔  App has a Greeting component
Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
You can also consider:

N/A

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification @prolajumokeoni.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Serializing trace context into binary protocols

I am interested in making TChannel implementations instrumented with opentracing API. The tracing is built into the protocol as a first-class citizen, the "trace ID" is accessible at a fixed position in the frame without parsing the whole request, which is critical when bouncing the requests through the routers to allow routers to participate in the traces. The current limitation of 64:64:64:8 bit length will be lifted in future revs, but the limitation of a fixed length will remain.
The trace context marshaller currently does not expose separate serialization for a trace ID, only for the whole context with metadata.
should we create dedicated methods to serialize just the trace ID as a binary blob?
can we impose a certain limit on the size of that blob?

It sounds like the metadata can't be guaranteed to fit given the fixed (and presumably small) length. As such, could you substitute a custom Marshaler+Unmarshaler that skips the trace tags / metadata?
Or is there somewhere aside from that narrow region where the metadata could go? (Sounds unlikely given what you've indicated)

Ben (mobile)

Specifically in TChannel protocol the trace ID is encoded in a fixed position with a fixed length, so that routers can access and update it efficiently. It also supports arbitrary app headers where I expect metadata to go to, but it's not being parsed out by the routers. There are different ways we can support it, one is by splitting the methods, another is to change the binary marshaller to return a tuple, e.g.
func MarshalTraceContextBinary(tcid TraceContext) (contextId []byte, metadata []byte)

yet another way is to define an optional interface that a TraceContextMarshaler can implement, that exposes split contextID+metadata methods, then TChannel would only work with tracing systems that support that extra interface.
Personally, I think since the metadata (tags) is already separated in the context API itself, it's not a stretch to have marshallers treat contextID and metadata separately, at least in binary marshaller.

I like that too. The reason I separated the id proper from the metadata a
few revs ago was because only the latter is actually needed to identify a
span. So there is a clear semantic division, and it's fine with me to reify
that. I'll make that change before Monday (or at least send out the PR).
On Saturday, December 5, 2015, Yuri Shkuro<EMAIL_ADDRESS>wrote:

Specifically in TChannel protocol the trace ID is encoded in a fixed
position with a fixed length, so that routers can access and update it
efficiently. It also supports arbitrary app headers where I expect metadata
to go to, but it's not being parsed out by the routers. There are different
ways we can support it, one is by splitting the methods, another is to
change the binary marshaller to return a tuple, e.g.
func MarshalTraceContextBinary(tcid TraceContext) (contextId []byte, metadata []byte)
yet another way is to define an optional interface that a
TraceContextMarshaler can implement, that exposes split contextID+metadata
methods, then TChannel would only work with tracing systems that support
that extra interface.
Personally, I think since the metadata (tags) is already separated in the
context API itself, it's not a stretch to have marshallers treat contextID
and metadata separately, at least in binary marshaller.
—
Reply to this email directly or view it on GitHub
https://github.com/opentracing/api-golang/issues/7#issuecomment-162244308
.

--
Sent via mobile

I think this is good to close.

sgtm!

This seems sound


Added crash resiliency, refactored Litejobqueue, got test suite consistently passing, and created a helper to simplify and standardize configuration

@oldmoe - This PR replaces #66 and handles requeueing dead jobs by considering jobs that have been running for a long time to be dead. An option for jobs to customize their considered dead time is provided with the considered_dead_after DSL that can be used in a Job class declaration.
In addition this contains a refactoring that should make Litejobqueue more maintainable by switching from a procedural to object-oriented style. A full suite of tests for these changes are included. And as an added benefit the job tests no longer intermittently fail.
I've also created LiteSupport::Configurable which standardizes and simplifies configurations and adds the ability to use a .configure block for those that prefer to place their configurations in an initializer. Unit tests for this are also included.
This also closes #63

Thanks a lot @RyanVasichko I will review and test this and merge if everything looks good

I have been reviewing the PR and this change is actually huge, I think we should break it down a bit before we can start applying these changes, there also some notes regarding the code:

I wouldn't want to move the sql statements from the *.sql.yml files and mix them with the Ruby code, this was intentionally to move them away from Ruby code, having them back is not something I would vote for.
The whole thing should live under litestack, if a component grows large enough, it can get its own folder under litestack, like with litesearch
I wouldn't want to have files called lite_job.rb and others called litejob.rb, same for folder names, I would stick to litejob throughout

Thanks for the feedback.

I don't believe there is any value in placing the SQL statements in a separate file, and doing so would create a more incoherent code base, something this project already struggles with.

Ruby convention is to place a module's classes/sub-modules in their own folder named in snake_case after the parent module

Ruby convention is to PascalCase class names and snake_case file names. So it should be LiteJob and lite_job

Thank you for taking the time to review this PR. Unfortunately the changes requested would be detrimental to the readability and maintainability of the code, and also violate well-established Ruby conventions. If there are smaller PRs you would prefer this broken down into due to the scope of the changes please let me know.

I am keen on separating the data layer "SQL" and Ruby as much as possible. My vision is that the *.sql.yml files should represent the bulk of functionality, and more (not less) should go there as more SQLite features get utilized. So no, I don't this makes for a more incoherent code base, at least not that particular aspect.

The new design loses the base classes litequeue, and it is a pity since I already use this class in different contexts, it provides basic functionality that is not tied to the Litejob interface, something I don;t want to lose.

Regarding the folders, I am not arguing against having sub modules in folders, I am just trying to make sure they are all children of the litestack folder

As for the naming convention, I am aware of that, still intentionally using lite* as a single word for all class names rather than something to be broken up by camel case. Appreciate your input but I would stick to the project's original convention regarding class/folder naming.

Furthermore, the breakage of functionality into small modules/classes (I know, SOLID, I know) actually makes the code splintered in a lot of files and much harder to grok for someone looking at the codebase for the first time.

That said, I really appreciate a lot of what went into the PR and appreciate your interest in Litestack (with a small s), so if you would like to approach this differently here is a list of smallish changes that can be useful

A separate PR for the configuration changes, allowing for the class.config{ } interface
Another PR for tests that use timecop and cover the different functionality aspects of litejob
Another PR that implements the crash resilience aspect as we discussed

Since I was planning to do 2 and 3 originally, I am happy to deliver on these anyway, but any help is welcome.


Node.js on server

Do I need to have Node.js running on production to use Webpack Module Federation? Will it work if I just do a build (host and consumer app) in Jenkins and promote to production?

You only need Node during the build process itself. The generated static files will have everything needed for module federation to work (depending on how you implement it).

Thanks for the prompt response! We have node available in Jenkins build. I will build and host in prod and see if it works.

Appears answered. Will close for now.


OneFuzz CLI Role Assignment Infrastructure

The CoSTR team is working with the OneFuzz team to build out the infrastructure to restrict user/admin CLI actions. Specifically, we are hoping to build out a process for specifying actions that can only be done by the service engineering team (CoSTR).
(Created for tracking purposes.)

The service will need the permission to check group  or role membership to enforce these rules.
At the moment these permissions require admin approval.


rkt garbage collections handling proposal

There are many places inside rkt that needs some form of garbage collections for different cases.
Garbage collection can be sometimes mitigated with good cleanup inside the code but cannot be completely avoided since they usually cover multiple non atomic operations and a process can be killed, segfault, the machine can reboot, panic etc...). Another need for garbage collection is when different parts of rkt are decoupled but need to be kept cleaned from data depending on another part (for example the aci treestore should be cleaned from old treestores for the same aci, fetching transport cache should be cleaned from blobs not available in the image store anymore)
Some cases:

Remove leftover data (like tmp files, store stale data due to failed non atomic file writing).
Clean data not needed anymore:
exited/prepare failed pods
With the ACI treestore remove old treestores generated with previous ACI dependencies
Fetchers transport cache

Some things aren't currently handled and other will be added.
My proposal is to define a rkt garbage collection command that will by default execute all the gc functions. Since gc is a process that should be executed at some intervals I'm proposing to just extend the current existing rkt gc to launch all different gc functions in addition to pod gc (to not add another rkt something gc command and since its already documented to be executed like a timer service). In addition some subcommand/options to just launch one kind of gc could be provided.
Instead rkt image gc is not a garbage collection type as the above but just a utility to remove images older than X time (for this reason I'm opening other issues/PRs to move the treestore gc outside it)
With oci images there'll be the need to remove unreferenced blobs, also this could live inside rkt image gc

So we would have rkt gc which will clean up everything, with some subcommands/flags to clean up only specific things and then rkt image cleanup (or should we keep gc?) to remove images older than X time. Then the treestores will be GCd with rkt gc.
Is that what you're proposing?

@iaguis correct

Instead rkt image gc is not a garbage collection type as the above but just a utility to remove images older than X time.

I'm not sure I've correctly understood this. It seems to be like a good example of your general proposal: a specific subcommand to cleanup specific resource (images), and the same routine can be re-used by the umbrella rkt gc. I fear you are trying to express a slightly different proposal perhaps?

My proposal is to define a rkt garbage collection command that will by default execute all the gc functions.

What is the integration point between these two components? Will gc subcommand be directly golang-calling methods in other component? How do we make this working with fetcher plugins proposal?

I'm not sure I've correctly understood this. It seems to be like a good example of your general proposal: a specific subcommand to cleanup specific resource (images), and the same routine can be re-used by the umbrella rkt gc. I fear you are trying to express a slightly different proposal perhaps?

yeah, this can be confusing. My thought was that, despite Remove leftover data and other points like exited/prepare failed pods, remove old treestores that will be needed to prevent an incremental increase of internal rkt unused data not under the direct control of the user, the rkt image gc can be an user choice, it could also choose to keep the images forever if it wants (also if I prefer to think about the image store as a local cache).
Thinking about this I'll move under this also With oci images there'll be the need to remove unreferenced blobs for the above reason.
Perhaps you have better views on this.

What is the integration point between these two components? Will gc subcommand be directly golang-calling methods in other component? How do we make this working with fetcher plugins proposal?

That will be different based on the gc kind, for example:

Remove store stale data due to failed non atomic file writing: This should be implemented as a function inside the image store, tree store since they have the control of their data and just called by the specific gc command
ACI treestore removal of old treestores generated with previous ACI dependencies: it cannot be implemented inside the treestore but controlled by an upper layers that will lock pod prepare and see if the treestore isn't referenced by any pod (now done here: https://github.com/coreos/rkt/blob/a36a9a2f7be03dd73dba138a79189e2f6e371e3d/rkt/image_gc.go#L80)
fetcher plugins: I was thinking about the gc function that will walk the transport cache, get the blob digest, check if it exists in the image store and if not existing remove it from the transport cache. During normal operation it's the transport plugin user that will check if the blob exists in the image store before using the cache data.

Related (abandoned?) PR https://github.com/coreos/rkt/pull/2047

Related (abandoned?) PR #2047

Yes, also if that was related to just pod GC adding fine grained selection of which pod GC function to execute.


Stopping a running test suite results in test results being hidden

I have a lot of tests that are running. As soon as I know that the needed group of tests are run, I clicked on Stop (square red button at the top). When I did this, all tests show a (?) icon and I have no idea which of the tests failed.
How do I figure out which of the specific tests that failed?
Environment data

VS Code version: 1.42.1 (system setup)
Extension version (available under the Extensions sidebar): 2020.2.63072
OS and version: Win 10, Version 2004 OS build 19564.1005
Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.10, conda 4.8.1
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
Relevant/affected Python packages and their versions: Python 3.6.10
Relevant/affected Python-related VS Code extensions and their versions: XXX
Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): XXX
Value of the python.languageServer setting: XXX

Expected behaviour
Tests should show "not started", "stopped", "failed", "passed" icons
Actual behaviour
You will see all tests showing (?) rather than "not started", "stopped", "failed", "passed" icons if any
Expected behavior
Steps to reproduce:

Run bunch of tests and wait for couple of them to fail
Click stop while everything is still running

Hi @skasturi! Thanks for reporting this. A work around is to let the tests finish running, then you’ll be able to see their final state. I’m turning this into a feature request for the extension to maintain the status of tests that had already finished running when execution stops.

Closing in favour of #6594 as it would provide a solution for this.


Projection of 3D box does not give tight 2D box

Hi @yiyiliao
Thank you for a great work. I wanted to get tight 2D boxes which are consistent with the camera projection equation. Hence, I visualized some 3D bounding boxes on the images, and the projection of the 3D box to the image plane does not give me tight 2D boxes.
e.g. Consider data_2d_raw/2013_05_28_drive_0004_sync/image_00/data_rect/0000003799.png with the 3D box.

Subfigure 1: Visualization from our custom viewer
Pink: Projected 3D box
Orange: Bounds of projected 3D box
Green: Expected Tight 2D box
Subfigure 2: Visualization from kitti360viewer.py script for a sanity check.
I expect the orange 2D box should be the same as the green 2D box. However, there are huge differences, especially for the nearby objects.
I wanted to ask if this caused by noisy annotations or something else. And also if it is possible to detect and remove / correct such cases.

Hi, thank you for your interest. It seems that the 3D bounding box of this car is indeed not as tight as it could be. However, even with a perfect 3D bounding box, it is not feasible to get the tight 2D bounding box you expected (the green one) from the projected 3D bounding boxes. I don't think there is a good way to solve this. You may use the 2D instance map to obtain a tighter 2D bounding box, or run a 2D detection network for this purpose.

Thankyou @yiyiliao, for your quick clarification. I completely understand.
However, I guess that the 3D boxes in KITTI-360 are bigger than the KITTI dataset, and the bigger car sizes in KITTI-360 lead to a not-so-tight projected 2D box. I calculated the average 3D dimension of the car boxes in the KITTI and KITTI-360 datasets to verify. Here are the 3D dimensions computed from the training splits of the two datasets:

Dimension (m)
KITTI
KITTI-360 (Mean)
KITTI-360 (Median)

h3d
1.53
1.64
1.57

w3d
1.62
2.07
2.03

l3d
3.88
4.56
4.53

I expected both these datasets to have very similar car sizes since both these datasets are collected in the same geographical location. It would be great if you can answer if my guess is correct.

Thank you for digging further into the problem! I agree that the average car sizes should be similar for KITTI and KITTI-360. I believe the reason that the 3D bounding boxes are larger in KITTI-360 is due to the following reasons:

The datasets are annotated using different annotation tools. I don't know the annotation detail of the KITTI dataset but I believe it should be annotated using per-frame point cloud. In KITTI-360, the cars are annotated using the accumulated point cloud, which means the observations are more complete. For example, the width could be larger when including the rear-view mirror:

There could be some noise in the annotation process. Our annotators are instructed to annotate the car as tight as possible but there could be a few cases where the bounding boxes are not that tight.

Thank you, @yiyiliao, for being spot on. I agree with you.

1. The datasets are annotated using different annotation tools. I don't know the annotation detail of the KITTI dataset but I believe it should be annotated using per-frame point cloud. In KITTI-360, the cars are annotated using the accumulated point cloud, which means the observations are more complete. For example, the width could be larger when including the rear-view mirror:

I agree the width would change because of including rear-view mirrors. However, the difference in l3d is a bit bigger.

2. There could be some noise in the annotation process. Our annotators are instructed to annotate the car as tight as possible but there could be a few cases where the bounding boxes are not that tight.

I guess both point cloud accumulation errors and annotators errors give rise to the differences we see.


feh: 2.27 -> 2.27.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/feh/versions.
meta.description for feh is: '"A light-weight image viewer"'.

Checks done (click to expand)

built on NixOS
/nix/store/ijdx5h87np7ag0gv310xrwzh4838l2pq-feh-2.27.1/bin/feh passed the binary check.
/nix/store/ijdx5h87np7ag0gv310xrwzh4838l2pq-feh-2.27.1/bin/.feh-wrapped passed the binary check.
2 of 2 passed binary check by having a zero exit code.
0 of 2 passed binary check by having the new version present in output.
found 2.27.1 with grep in /nix/store/ijdx5h87np7ag0gv310xrwzh4838l2pq-feh-2.27.1
directory tree listing: https://gist.github.com/587d2609e49e0ca64795c542968be776
du listing: https://gist.github.com/e3c4010317b70db69d51ad8a63c2f673

Test this build with Cachix (click to expand)

One time setup in nixpkgs Git checkout:
cachix use r-ryantm
git remote add r-ryantm https://github.com/r-ryantm/nixpkgs.git

Test this build:
git fetch r-ryantm && git checkout b49dada76c24bdd44f0593e80c3e8466c0ceab8f && nix-shell --pure -I nixpkgs=. -p feh

cc @viric @willibutz for testing.

Success on x86_64-darwin (full log)
Attempted: feh
Partial log (click to expand)
rmdir: failed to remove '/nix/store/v9rwb9w420a6v825yn7pmdnw121f9hpc-feh-2.27.1/share': Directory not empty
strip is /nix/store/8axizw5mf6dx7wip65nbkyrmlkhmjhc5-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/v9rwb9w420a6v825yn7pmdnw121f9hpc-feh-2.27.1/bin
patching script interpreter paths in /nix/store/v9rwb9w420a6v825yn7pmdnw121f9hpc-feh-2.27.1
gzipping man pages under /nix/store/1sqc4ccrr32dbrn5rpbs55hl2y7kkfhq-feh-2.27.1-man/share/man/
strip is /nix/store/8axizw5mf6dx7wip65nbkyrmlkhmjhc5-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/1sqc4ccrr32dbrn5rpbs55hl2y7kkfhq-feh-2.27.1-man
strip is /nix/store/8axizw5mf6dx7wip65nbkyrmlkhmjhc5-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/4d8q52k5dnillig2rs16gq834lg9m84g-feh-2.27.1-doc
/nix/store/v9rwb9w420a6v825yn7pmdnw121f9hpc-feh-2.27.1

Success on aarch64-linux (full log)
Attempted: feh
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/00k29npkif26jxw2jbipiiyjvgjzi8zh-feh-2.27.1-man
gzipping man pages under /nix/store/00k29npkif26jxw2jbipiiyjvgjzi8zh-feh-2.27.1-man/share/man/
strip is /nix/store/7iyn7gn33i7xxjgmwf25k20246y6nd9d-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/00k29npkif26jxw2jbipiiyjvgjzi8zh-feh-2.27.1-man
checking for references to /build in /nix/store/00k29npkif26jxw2jbipiiyjvgjzi8zh-feh-2.27.1-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/a1yqkhrl2paiz5ax9v8n6qck2j9dj2l6-feh-2.27.1-doc
strip is /nix/store/7iyn7gn33i7xxjgmwf25k20246y6nd9d-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/a1yqkhrl2paiz5ax9v8n6qck2j9dj2l6-feh-2.27.1-doc
checking for references to /build in /nix/store/a1yqkhrl2paiz5ax9v8n6qck2j9dj2l6-feh-2.27.1-doc...
/nix/store/74igvp0q6msijsv3812labp51z7a87jn-feh-2.27.1

Success on x86_64-linux (full log)
Attempted: feh
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/w5zdgmldh01rcw80jj0r41dridrhxz14-feh-2.27.1-man
gzipping man pages under /nix/store/w5zdgmldh01rcw80jj0r41dridrhxz14-feh-2.27.1-man/share/man/
strip is /nix/store/90vmpr41dzsx350k5argycaf693hnl1l-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/w5zdgmldh01rcw80jj0r41dridrhxz14-feh-2.27.1-man
checking for references to /build in /nix/store/w5zdgmldh01rcw80jj0r41dridrhxz14-feh-2.27.1-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/hpjhdyf75xzzlp7nh7jrjv39j52avidz-feh-2.27.1-doc
strip is /nix/store/90vmpr41dzsx350k5argycaf693hnl1l-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/hpjhdyf75xzzlp7nh7jrjv39j52avidz-feh-2.27.1-doc
checking for references to /build in /nix/store/hpjhdyf75xzzlp7nh7jrjv39j52avidz-feh-2.27.1-doc...
/nix/store/ijdx5h87np7ag0gv310xrwzh4838l2pq-feh-2.27.1


[Event request] Table 11401 CBG Statement Line OnBeforeCreateGenJournalLine

Hello, is it possible to add the following to the CBG statement line table (Dutch localisation)
procedure CreateGenJournalLine(var GenJnlLine: Record "Gen. Journal Line")
var
    CBGStatement: Record "CBG Statement";
    **SuspendTestAccountNo: Boolean;   // New Variable**
begin
    **// DINNL <<
    OnBeforeCreateGenJournalLine(SuspendTestAccountNo);
    if not SuspendTestAccountNo then
        // DINNL >>**
    TestField("Account No.");
    GenJnlLine.Init();
    GenJnlLine."Journal Template Name" := "Journal Template Name";
    GenJnlLine."Journal Batch Name" := Text1000016;// STRSUBSTNO('%1',"No.");
    GenJnlLine."Line No." := 0;

    GenJnlLine.Validate("Posting Date", Date);
    case "Account Type" of
        "Account Type"::"G/L Account":

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


directly from docs, getting an "off-by-one" error

Directly from the docs, I've created a test case. Instead of the expected value, I'm getting H9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk=, so the G and the H are the only difference.
Did I do anything wrong?
const bitcoin = require("bitcoinjs-lib"); // v4.x.x
const bitcoinMessage = require("bitcoinjs-message");

describe(
  'straight from the docs', () => {
    it('should work but does not', () => {

      const keyPair = bitcoin.ECPair.fromWIF('L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1')
      var privateKey = keyPair.privateKey
      var message = 'This is an example of a signed message.'

      var signature = bitcoinMessage.sign(message, privateKey, keyPair.compressed)
      console.log(signature.toString('base64'))
      // => 'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk='
      expect(signature.toString('base64')).toEqual(
        'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk=')
    })
  }
)

I made a test repo for anyone to try and verify or reproduce: https://github.com/pyramation/bitcoinjs-message-issue-24

looking at fixtures, and trying to guess a little, is there some mixup w compressed or uncompressed happening?

describe(
  'straight from the docs', () => {
    it('example from doc fails', () => {

      const keyPair = bitcoin.ECPair.fromWIF('L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1')
      var privateKey = keyPair.privateKey
      var message = 'This is an example of a signed message.'

      var signature = bitcoinMessage.sign(message, privateKey, keyPair.compressed)
      console.log(signature.toString('base64'))
      // => 'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk='
      expect(signature.toString('base64')).toEqual(
        'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk=')
    })
    it('compressed works', () => {

      const keyPair = bitcoin.ECPair.fromWIF('L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1')
      var privateKey = keyPair.privateKey
      var message = 'This is an example of a signed message.'

      var signature = bitcoinMessage.sign(message, privateKey, false)
      console.log(signature.toString('base64'))
      // => 'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk='
      expect(signature.toString('base64')).toEqual(
        'G9L5yLFjti0QTHhPyFrZCT1V/MMnBtXKmoiKDZ78NDBjERki6ZTQZdSMCtkgoNmp17By9ItJr8o7ChX0XxY91nk=')
    })

  }
)

Thanks for the catch. Someone asked us to change the README examples to compressed but I forgot to change the signatures themselves.
If you could make a PR I'll merge it.

Fixed in a5107632abe1477b337adffd1f4cd69652a2cbbf


kill prog if not root (or sudo)

added os.geteuid() to script to kill if user not root (or sudo).

thanks! that is definitely what I needed.


.NET Version Not Working Reliably

Having an issue with the .NET version.
It does not seem to populate TripUpdate consistently. Seems when Vehicle is available TripUpdate is not populated.
Tested the same feed using JAVA code from OneBusAway and TripUpdate is there on every entity item.
What could be the reason? Any ways to get TripUpdate to populate reliably ?

@AlexVPerl Could you please provide the GTFS-realtime feed that you are using?

So I believe this is actually a duplicate of https://github.com/MobilityData/gtfs-realtime-bindings/issues/32, so I'm closing it as a duplicate.


load_model causes TypeError when called with keyword argument filepath

Please make sure that this is a Bug or a Feature Request and provide all applicable information asked by the template.
If your issue is an implementation question, please ask your question on StackOverflow or on the Keras Slack channel instead of opening a GitHub issue.
System information

OS Platform and Distribution: Ubuntu 18.04.3 LTS
TensorFlow backend: yes
TensorFlow version:  1.14.0
Keras version:  2.2.4

Calling load_model with filepath keyword argument as load_model(filepath='my_file.h5') causes an TypeError:
    456                 os.remove(tmp_filepath)
    457             return res
--> 458         return load_function(*args, **kwargs)
    459
    460     return load_wrapper

TypeError: load_model() missing 1 required positional argument: 'filepath'```

**Describe the expected behavior**
It should accept a keyword argument.

**Code to reproduce the issue**
```from keras.models import load_model
load_model('my_file.h5')
load_model('filepath=my_file.h5')

The second call to load_model will cause the error.
Other info / logs
In keras/keras/engine/saving.py :+1:
    """Function decorator to support loading from Google Cloud Storage (GCS).
    This decorator parses the `filepath` argument of the `load_function` and
    fetches the required object from GCS if `filepath` starts with "gs://".
    Note: the file is temporarily copied to local filesystem from GCS before loaded.
    # Arguments
        load_function: The function to wrap, with requirements:
            - should have one _named_ argument `filepath` indicating the location to
            load from.
    """
    def extract_named_arg(f, name, args, kwargs):
        if name in kwargs:
            arg = kwargs.pop(name)
            return arg, args, kwargs
        argnames = getargspec(f)[0]
        for i, (argname, arg) in enumerate(zip(argnames, args)):
            if argname == name:
                return arg, args[:i] + args[i + 1:], kwargs
        else:
            raise ValueError('function {} has no argument {}'.format(f, name))

    @wraps(load_function)
    def load_wrapper(*args, **kwargs):
        filepath, _args, _kwargs = extract_named_arg(
            load_function, 'filepath', args, kwargs)
        if _is_gcs_location(filepath):
            tmp_filepath = os.path.join(tempfile.gettempdir(),
                                        os.path.basename(filepath))
            _gcs_copy(filepath, tmp_filepath)
            _kwargs['filepath'] = tmp_filepath
            try:
                res = load_function(*_args, **_kwargs)
            finally:
                os.remove(tmp_filepath)
            return res
        return load_function(*args, **kwargs)

    return load_wrapper

In load_wrapper the call to extract_named_arg will pop out the filepath argument and then in the last line return load_function(*args, **kwargs) filepath is not in kwargs anymore.

Sorry, but I think this is a bug. To summarise it, if you execute this line:
load_model(filepath='my_file.h5')
you will get an error, while the following line does not cause the error:
load_model('my_file.h5')
The reason is explained above.


Error running 'fzf'

Category

[ ] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[X] Vim
[ ] Neovim
[ ] Etc.

OS

[ ] Linux
[X] Mac OS X
[ ] Windows
[ ] Windows Subsystem for Linux
[ ] Etc.

Shell

[ ] bash
[X] zsh
[ ] fish

It has been working fine on another machine but when I try setting up a new machine with my .vimrc I'm getting an error when I try to run fzf
Error running 'fzf'  '--multi' '--prompt' '~/' --expect=ctrl-v,ctrl-x,ctrl-t --height=29 > /var/folders/n4/xblbdc593kz_vrfdwf
8vxkdr0000gn/T/v7RGKRg/1

Any help would be appreciated.

nm, I re-installed fzf with homebrew and it resolved the issue.


Per-corner borderRadius

I'd like to set a border-radius style so the wrapper has a border radius, while the inner selected option has a border radius on the outer corners, but not on the inner ones. This doesn't seem to be possible with the current exposed properties.
Here's an usage example:

Hey! thanks for reaching out.
It should be more feasible in v2.2.0
Please see the following Storybook example: https://gr34se.github.io/react-switch-selector/?path=/story/switchselector--outer-border-radius
hope that will fit your needs 🙂


fix reflection-docblock issue #352

Did you check that the generated file is still correctly parsed?

I added some tests an triggered a build with close/open. But as you can see, it fails the tests.
Some methods are not working in v3. You can see that the lower version is still working.

Used my fork of v2 for now, to avoid conflicts.