text:
Prevent napari crashing after layer is dragged into trash

Description

This PR fixes behavior where napari crashes when a layer is dragged to the trash, while using PyQt5 backend.
Now we check if the selected layer has been deleted after being dragged, before trying to index it.
Type of change

[X] Bug-fix (non-breaking change which fixes an issue)
[ ] This change requires a documentation update

References

This closes #1484
How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

This bug fix does not have a test, in part because this file will not exist for much longer.
Final checklist:

[X] My PR is the minimum possible work for the desired functionality
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

in normally one would probably unit-test this by mocking the QMimeData object, which should hold all of the information about the object being dropped.  But the current class here stores some of the drag information on the class itself as well (self._drag_name) so probably not going to work here.  I would try to test this as  directly as possible by creating a QtLayerlist, and calling its mouseMoveEvent method with a madeup QMouseEvent , that has an appropriate .pos().
but again, don't worry about it too much if it's taking a lot of time.  The LayerGroup branch will have a new QMimeData object that will change what's happening here

You could also just set the self._drag_name and then call mouseMoveEvent and not worry about the pos, but I agree with @tlambert03 this is going to change soon anyway, even my QLayerList PR changed this logic, and we don't have any full drag/ drop tests with Qt like this either - not sure if we could use the Qtbot to simulate clicking/ dragging either.
As @tlambert03 said, let us know how it goes @hectormz as this could be a huge time sync that isn't worth it, but would be great if you got something we could keep using during the refactors.

Okay, got it. I'll look into this in the next day or two and report back if it seems like it would be too much time to get working

I haven't had a lot of time to look into this and figure the test out, but I did confirm that this is a PyQT + Windows behavior.

I have just updated from main, will merge once all tests pass. I think it is fine that this PR doesn't have a test for drag and drop given what @tlambert03 notes about the upcoming refactors. Thanks @hectormz for fixing this!!

authors: hectormz sofroniewn tlambert03

repo: napari/napari


text:
Add event filter to convert tooltips to richtext

Description

Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

Fixes #3096
How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

@sofroniewn I followed Pam's instructions and here is what came out. Feast your eyes 👀 😆

@tlambert03 added some tests and your suggestions. Could you take another look?

Perfect, I'm pretty sure the 20 minutes CI time we used for this extra commit are going to be quickly paid for by the 400ns we gain at each invocation of a tooltip.

source: gharchive/pull-request

authors: Carreau goanpeca

license_type: permissive

license_source: github-api


text:
layer views

Description
Non-instantiable mix-in class for views corresponding to an aspect of a layer.
Direct subclasses of LayerView (ones that explicitly list it as a base) are considered base classes.
Classes that inherit from base classes can specify the layer class definition keyword argument to associate themselves with a specific layer type.
When a base class is initialized with a layer of that type, it will return an instance of the class associated with that layer type.
>>> class Foo(LayerView): ...
>>> class ImageFoo(Foo, layer=Image): ...
>>> foo = Foo(Image(...))
>>> type(foo).__name__
'ImageFoo'

Changes

create layer view class
adapt vispy views to use layer view class
adapt qt properties to use layer view class
adapt qt controls to use layer view class
replace all usages of create_* functions with layer view base classes directly

References

see https://github.com/napari/napari/pull/485#discussion_r315848620

No, I haven't run into any patterns like this.
I guess the closest is as defined in PEP 487:
class PluginBase:
    subclasses = []

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        cls.subclasses.append(cls)

in combination with this blog's examples (see Python's documentation on __new__ for more information).


text:
[V5 beta] ERROR Error: Uncaught (in promise): NullInjectorError: R3InjectorError(AppModule)[NgtStore -> NgtStore -> NgtStore]:    NullInjectorError: No provider for NgtStore!

As soon as I add NgtPhysicBody to a component, I get the NullInjectorError.  Feels like I'm missing an import module, but not sure which.
@Component({
  templateUrl: './bounce.component.html',
  providers: [NgtPhysicBody],
})
export class BounceComponent {
  constructor(private physicBody: NgtPhysicBody) { }
}

This component needs to be inside of

Looks like your comment was truncated

The component needs to be inside of ngt-physics which needs to be inside of ngt-canvas.

It is.  All of my components where working with V4.  Here's the full code for the bounce example.

  <ngt-canvas [camera]="{ position: [10, 2, 0], fov: 45, near:1, far:100 }"
              [scene]="{ background: 'gray' | color }">
    <ngt-directional-light [args]="['white' | color, 1.75]"
                           [position]="[20, 20, 20]" [castShadow]="true">
    </ngt-directional-light>

    <ngt-physics>
      <ngt-cannon-debug [disabled]="true" [scale]="1.1" color="red">

        <ngt-mesh [ref]="sphere1Props.ref" [castShadow]="true">
          <ngt-sphere-geometry></ngt-sphere-geometry>
          <ngt-mesh-standard-material [parameters]="{ color: 'red' | color }"></ngt-mesh-standard-material>
        </ngt-mesh>

        <ngt-mesh [ref]="sphere2Props.ref" [castShadow]="true">
          <ngt-sphere-geometry></ngt-sphere-geometry>
          <ngt-mesh-standard-material [parameters]="{ color: 'white' | color }"></ngt-mesh-standard-material>
        </ngt-mesh>

        <ngt-mesh [ref]="sphere3Props.ref" [castShadow]="true">
          <ngt-sphere-geometry></ngt-sphere-geometry>
          <ngt-mesh-standard-material [parameters]="{ color: 'blue' | color }"></ngt-mesh-standard-material>
        </ngt-mesh>

        <floor></floor>
      </ngt-cannon-debug>
    </ngt-physics>

    <ngt-soba-orbit-controls></ngt-soba-orbit-controls>
    <ngt-stats></ngt-stats>
  </ngt-canvas>

import { Component } from "@angular/core";

import { NgtPhysicBody } from "@angular-three/cannon/bodies";
import { NgtTriple } from "@angular-three/core";

@Component({
  templateUrl: './bounce.component.html',
  providers: [NgtPhysicBody],
})
export class BounceComponent {

  sphere1Props = this.physicBody.useSphere(() => ({
    mass: 1,
    position: [-3, 5, 3] as NgtTriple,
    material: { restitution: 0.4 },
  }));

  sphere2Props = this.physicBody.useSphere(() => ({
    mass: 1,
    position: [-3, 5, 0] as NgtTriple,
    material: { restitution: 0.6 },
  }));

  sphere3Props = this.physicBody.useSphere(() => ({
    mass: 1,
    position: [-3, 5, -3] as NgtTriple,
    material: { restitution: 0.8 },
  }));

  constructor(private physicBody: NgtPhysicBody) { }
}

I added the following to AppModule, now the error changes to NullInjectorError: R3InjectorError(AppModule)[NgtStore -> ElementRef -> ElementRef -> ElementRef]
  providers: [NgtStore],

I've pushed the full cannon examples project to a v5 branch.  Hopefully, it will repeat for you.

I'm outside right now. can you see if you can replicate the error on the physic-cubes example in apps/sandbox on the v5 branch?

What's the command to run this standbox server?

Figure it out.  nx serve standbox

I think I see the problem. Your BounceComponent also includes the ngt-canvas which makes BounceComponent a parent (host) of NgtCanvas, not children.
Why don't you just bring the three spheres into the Bounce component instead of the whole canvas?

This is the whole example page.  This worked fine in V4.
Sound like if I want to pull NgtPhysicBody into a component, that component can't include ngt-canvas

As soon as I add those two lines to SandboxPhysicCubesComponent component, it starts failing in the same way.
@Component({
  selector: 'sandbox-physic-cubes',
  template: `

        <ngt-canvas
            [dpr]="[1, 2]"
            [gl]="{ alpha: false }"
            [camera]="{ position: [-1, 5, 5], fov: 45 }">

            <ngt-ambient-light></ngt-ambient-light>
            <ngt-directional-light [position]="10" [castShadow]="true">
            </ngt-directional-light>

            <ngt-physics>
                <sandbox-plane [position]="[0, -2.5, 0]"></sandbox-plane>
                <sandbox-cube [position]="[0.1, 5, 0]"></sandbox-cube>
                <sandbox-cube [position]="[0, 10, -1]"></sandbox-cube>
                <sandbox-cube [position]="[0, 20, -2]"></sandbox-cube>
            </ngt-physics>
        </ngt-canvas>

`,
  changeDetection: ChangeDetectionStrategy.OnPush,
  providers: [NgtPhysicBody],
})
export class SandboxPhysicCubesComponent {
  constructor(private physicBody: NgtPhysicBody) { }
}

Can you confirm this is the path forward for V5?
Does this only apply for objects with physics enabled?

Correct. That's how DI works. In v4, the physic body directives get attached on the mesh which are children of the Canvas. In v5, the PhysicBody service needs to be a child of Canvas. Your wrapper component wraps the Canvas which makes your component the Canvas's parent.

Ok, I'll split all my examples into two components.
Hopefully, that subtly can be captured in your updated documentation.
Once I have everything migrated, I'll make some V4 to V5 migration notes based on my own experience.

Please do! And definitely lemme know any feedback at all as we can make changes now if needed:

the whole Ref thing
Attaching (I'll write more about this when I get on my laptop)
BooleanInput (I'll write more about this when I get in my laptop)
Material with individual inputs instead of parameters object

@IRobot1 here's my list so far https://github.com/nartc/angular-three/blob/v5/libs/documentations/docs/getting-started/migrate-to-v5.mdx

Can you give an example of how to use instanced mesh with physics?  Its not clear to me how ref is applied to each instance.
Previously the following code worked, but now throws lots of errors in the tick method
  count = 400;

  private boxes: Array<NgtTriple> = []

  constructor(private physicBody: NgtPhysicBody) {
    for (let i = 0; i < this.count; i++) {
      // start with random positions
      this.boxes.push([
        (Math.random() * 2 - 1) * 5,
        Math.random() * 10,
        (Math.random() * 2 - 1) * 5
      ])
    }
  }

  cubeProps = this.physicBody.useBox((index: number) => ({
    mass: 1,
    position: this.boxes[index],
    args: [1, 1, 1],
  }));

  ready(inst: InstancedMesh) {
    for (let i = 0; i < this.count; i++) {
      inst.setColorAt(i, new Color().setHex(Math.random() * 0xffffff));
    }
  }

  tick() {
    const index = Math.floor(Math.random() * this.count)
    this.cubeProps.api.at(index).position.set(0, 5 + Math.random() * 15, 0);
  }```

`Uncaught TypeError: Cannot read properties of undefined (reading 'position')`

Looks like at(index) no longer returns a valid object

@IRobot1 There's a bug with InstancedMesh. I just released beta.2 that contains the fix. I also added the Kinematic Cube example to the sandbox. Please take a look

I confirmed instance mesh is now fixed with beta 2.

@IRobot1 https://github.com/nartc/angular-three/issues/96 can you chime in here all the findings that you've found so far?

source: gharchive/issue

repo: nartc/angular-three

license: MIT


text:
Splitkb aurora lily58 with double encoders working

Merges https://github.com/zmkfirmware/zmk/pull/1553 & https://github.com/infused-kim/zmk/tree/my-changes/split-encoder (https://github.com/zmkfirmware/zmk/pull/728)
Superceded #1

See #3

repo: narze/zmk


text:
Convert Simulink Controller to C++

The basics are currently working in simulation. Further testing is needed in simulation and on the robot, then the old controller needs to be removed (currently it runs both and gives an error if they have a different output).

It seems like a good idea to make the mode configurable (at run-time, without restarting FSW) between a few options like "old only", "use old but also compare with new and log errors as ROS telemetry", "use new but also compare with old and log errors as ROS telemetry", "new only". And make the default "old only" to start with.
Then this could be merged with develop and tested thoroughly, maybe even during facility CM sessions on the ISS, before switching to the new version for all users.

Tested in granite lab, succeeded at docking, undocking and square.

Now tested and working on an ISS bag (did find one bug with using the second queued command). Once you review @marinagmoreira we can merge to develop based on our earlier discussion.

Now tested and working on an ISS bag (did find one bug with using the second queued command).

Not to slow things down, but I'm confused about the purpose of the last commit. It seems like it should have exactly the same behavior as the previous version, just using a pointer instead of a reference. Usually the difference between using a pointer and using an "equivalent" reference involves the possibility of NULL values, but that doesn't seem to apply here. I must be missing something.

Now tested and working on an ISS bag (did find one bug with using the second queued command).

Not to slow things down, but I'm confused about the purpose of the last commit. It seems like it should have exactly the same behavior as the previous version, just using a pointer instead of a reference. Usually the difference between using a pointer and using an "equivalent" reference involves the possibility of NULL values, but that doesn't seem to apply here. I must be missing something.

That's what I thought too and how you would expect! This being C++, that is not the case--- with the first version, when we do curr = command_.current, we overwrite the value pointed to by curr, not change what it points to. Was a nasty bug to figure out.
https://isocpp.org/wiki/faq/references#assigning-refs

repo: nasa/astrobee


text:
Use CFE_MSG_SequenceCount_t for seqcnt in CFE_SBR_GetSequenceCounter

Is your feature request related to a problem? Please describe.
Not using CFE_MSG_SequenceCount_t:
https://github.com/nasa/cFE/blob/c8b5e00bb722d8f59787ae8f82634feba5d39f60/modules/sbr/fsw/src/cfe_sbr_route_unsorted.c#L172
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
None
Additional context
Code review
Requester Info
Jacob Hageman - NASA/GSFC

Ping @pepepr08

repo: nasa/cFE


text:
External CFE message definitions should not depend on values from cfe_platform_cfg.h or osconfig.h

Some structure definitions that define specific ground commands and telemetry messages use array sizes for strings that are either defined in osconfig.h (e.g. OS_MAX_PATH_LEN) or cfe_platform_cfg.h (e.g. CFE_ES_MAX_APPLICATIONS).
However, by definition, these header files contain parameters that are tunable to the specific CPU.  For instance, a resource-constrained CPU may need to reduce CFE_ES_MAX_APPLICATIONS to a small number to save memory.  It is therefore problematic to use these values to define messages that serve as a data definition across processors, particularly in a multi-board setup.
External message definitions must be limited to mission-wide configuration parameters only, such as cfe_mission_cfg.h, where all CPUs as well as the ground system will have the same values.

Imported from trac issue 12.  Created by jphickey on 2014-12-30T21:26:08, last modified: 2019-03-05T14:58:28

Trac comment by jphickey on 2015-05-04 10:11:10:
Will resolve this as part of next change set.
As a related note, {{{cfe_platform_cfg.h}}} should not be available for inclusion by applications.  The values defined within this file are tuning parameters for the CFE core, and should not be used by applications intended to be portable.  This keeps the build simpler, and also allows application binaries to be shared between multiple CPU builds that use the same architecture (i.e. the same binary for application "z" can be loaded onto cpu1 and cpu2 if they both use the same CPU architecture).
Most applications using this header are easily fixed:

Some apps were including it but not using it for anything - so removing it "just works" (probably originally a cut and paste)
The application can be modified to not require the actual value
The value of the parameter can be acquired at run time rather than compile time
The value can become a mission-level compile-time tunable for this application

Trac comment by sduran on 2015-05-15 15:07:13:
Changes look ok for cfe code, but there could be impacts to CFS apps, not to mention existing user apps.  Probably need an apps ticket to assess CFS apps for impacts and update.

Trac comment by jphickey on 2015-05-11 10:00:18:
Pushed commit 2ad6078 for review
EDIT 5/29/15 -- Per feedback - holding off on this commit until a later date. Please see below for updated commit ID for review.

Trac comment by jphickey on 2015-05-18 16:26:27:
Replying to [comment:4 sduran]:

Changes look ok for cfe code, but there could be impacts to CFS apps, not to mention existing user apps.  Probably need an apps ticket to assess CFS apps for impacts and update.

Replying to [comment:5 acudmore]:

I agree with Steve in the comment above. We need to determine the impacts.

Yes - this change is (unfortunately) not transparent to the apps that are currently including platform-specific files.  I have updated all of the CFS applications so they can all be made to work, but there were some minor modifications to do on some of them.

Trac comment by acudmore on 2015-05-18 15:56:38:
I agree with Steve in the comment above. We need to determine the impacts.
I do like the idea of binary compatible apps, and it is a good idea to not define telemetry based on processor specific defines.
We may end up having to split osconfig.h into mission defines for path, file name lengths, and such. The sizes of the OS data structures (such as how many tasks, queues ) could go in a processor config file. We would still have to be careful with the mission wide file system defines, because there still could be a case for different maximum filename lengths on two different processors.

Trac comment by jwilmot on 2015-05-19 10:44:10:
Although I aggree with the rationale, I'm not sure this meets the "ROI" test. The change potentially impact quite a few files and the memory savings is likely small. Maybe add notes in the app developers guide to deprecate app use of cfe_platform_cfg.h?

Trac comment by jphickey on 2015-05-21 15:35:19:
Reworking this change to address some of the issues and feedback

Trac comment by jphickey on 2015-05-29 09:49:22:
This is ready for re-review, as commit [changeset:beea9d3]
The new branch name is "trac-12-separate-api-platform-definitions"
Per feedback - I have pulled out the changes regarding inclusion of {{{cfe_platform_cfg.h}}}.  This can be deferred to a later date, but I would still like to get in the main focus of this trac which is to separate the size definitions within API/Message structures from the platform config.
The new commit focuses specifically on this aspect of separating the message/API binary formats from the platform configuration, but leaves the inclusion paths as-is.  This is an important prerequisite of EDS support but it is relevant/important even if EDS is not used.
DEPENDENCY NOTE: because strings in messages may be a different size than what the local platform/OS defines, this //requires// the fix for #86 to be included as well in order to guarantee things continue to work as expected.  The commit ID listed above is a descendant of the trac #86 fix for this reason.

Trac comment by jphickey on 2015-05-29 09:55:37:
Replying to [comment:7 jwilmot]:

Although I aggree with the rationale, I'm not sure this meets the "ROI" test. The change potentially impact quite a few files and the memory savings is likely small. Maybe add notes in the app developers guide to deprecate app use of cfe_platform_cfg.h?

Additional note - the new commit I just pushed will not affect the ability to include the platform config and therefore does not affect compatibility with existing applications like the previous commit would have.  The new commit accomplishes the main goal of what I needed to do here for EDS support.
I still want to deprecate usage of "cfe_platform_cfg.h" from applications, but this can be deferred to a later build.

Trac comment by jphickey on 2015-07-15 13:54:30:
== REBASED COMMIT ==
This has been rebased to the {{{development}}} branch approved at the 2015-07-14 CCB.
Rebased commit ID: [changeset:b8f8385]
Note that this still depends on #86 -- as of this writing #86 is not yet included in a development merge.

Trac comment by glimes on 2015-07-27 15:00:00:
Approve.

Trac comment by jphickey on 2015-07-27 15:21:35:
Note to reviewers:
Although this does not directly prevent apps from including cfe_platform_cfg.h, this does change the name of certain definitions within that file and as such it does affect compatibility with existing applications.
The name changes are intentional - to give an example, application code might be referencing CFE_ES_MAX_APPLICATIONS.
Depending on the context:

It may be using this macro to interact with the local CFE ES instance.  In general this code should be rewritten to use the public function call API only and not rely on such macros at all.  However in the meantime this could be changed to  CFE_ES_PLATFORM_APPLICATIONS to preserve existing behavior.
It may be using this macro to interpret software bus packets to/from CFE ES. In this case the correct value should be CFE_ES_MSG_MAX_APPLICATIONS

This means that neither definition is "valid" for all use cases.  By //not// preserving the existing name, code that references this value will trigger an error and force some examination to see what context this is being used in so the correct modification can be done.
I have written a corresponding ticket and fix for any issues for all existing cFS applications and those are in the [cfs_apps:] repository.

Trac comment by jphickey on 2015-08-11 13:55:44:
Latest commit: [changeset:11cbd8c]

Trac comment by sstrege on 2015-08-21 18:06:23:
Please identify the ticket numbers in the cfs_apps repository.

Trac comment by sstrege on 2015-08-24 18:06:39:
How is the EDS work affected if this change set is NOT applied?

Trac comment by sstrege on 2015-08-24 18:08:56:
From Joe's email:
It was discussed during the last CCB that the applications would all need some sort of update in order to work with the changes introduced by CFE ticket #43.  Below is a list of tickets that allow all the apps to build using the platform configurations modified as part of CFE ticket #43.
Note - these also fix some other compiler warnings in addition to adapting to the platform config changes.
Also note - not proposing that we necessarily review these in detail at the upcoming CCB, as we probably do not have enough time.  I would rather go through the rest of the tickets on the previous list, possibly deferring #43 again until the 9/8 CCB if necessary until these changes can be reviewed.  The main objective here is to give an idea of the type of fixes that were required to apps in order to correctly build with the modified platform configuration.
#56: Fix MD using CFE_TBL definitions
Branch trac-25-md-sendevent-fix / commit 72d41b7
#57:  Fix HS build errors with strict settings Branch trac-26-fix-hs-build-errors / commit 402591f
#58: Fix HK build with strict settings
Branch trac-27-fix-hk-build-errors / commit 6a940b9
#60: Fix DS verification build error
Branch trac-29-fix-ds-build-error / commit 70e309a
#61: Fix CS build error
Branch trac-30-fix-cs-build-error / commit 4a10d1f
#65: Fix CF build errors
Branch trac-34-fix-cf-build-errors / commit 94f3d50
(#65 contains additional fixes beyond just the platform config related items - may split this up into multiple tickets if necessary)

Trac comment by jphickey on 2015-08-31 11:43:18:
== UPDATED ==
This was discussed at the 2015-08-25 CCB meeting and it was agreed to produce a "reduced" version of this change set that did not change any of the names within cfe_platform_cfg.h.
This is available as commit [changeset:b153c13], branch name trac-12-platform-msg-limits-take2
This cuts the number of affected files from 60 (original commit) to 18.
The remaining changes focus on the following areas:

the cfe_mission_cfg.h now contains mission-scope size definitions telemetry/command objects.
message payload definitions within in the .h files are updated to use the mission-scope definitions.
In places where the messages are sent or received, the code is also adjusted accordingly.  When possible, the sizeof() operator is preferred for this operation so the code does not assume a certain size for the I/O structures.  Additionally, the code is updated to allow different size limits (padding out the I/O structure if it is larger in size than the local platform limit).

Trac comment by glimes on 2015-09-08 10:16:18:
Approve.
I'll need to make sure to get all of the right headers in place in the sample_defs
area in the cfs_test tree when this goes live. This is all worked out correctly now
in the ic-ccb-review branch.

Trac comment by jphickey on 2015-09-08 10:04:48:
Related: Added ticket #142 regarding the naming convention for mission scope vs. platform scope macros.

Trac comment by jphickey on 2015-09-08 12:46:23:
Replying to [comment:21 cdknight]:

A simple example:
cfe_platform_cfg.h:
{{{
...
extern const uint32 CFE_SB_DEFAULT_MSG_LIMIT;
extern const uint32 CFE_SB_BUF_MEMORY_BYTES;
...
extern const char * const CFE_SB_DEFAULT_ROUTING_FILENAME;
...
}}}

Actually this is my preferred method storing tunable configuration items and there is already an existing means to do (essentially) this approach.  To minimize impact on the symbol table, a structure is used (rather than an array) so each element does not need to be the same type.  This is currently instantiated by target_config.c in the CMake build.
The nice thing about this is that it defers resolution of the value to link time (rather than preprocessor) so code is more modular.  It is particularly useful for values that are used by a different module than what defined them, e.g. defined by CFE and used by CFS apps, or defined by PSP and used by CFE, etc.
The biggest issue with this is that it is not possible to declare derived types from them. e.g.
{{{
uint8 MyBuffer[CFE_SB_BUF_MEMORY_BYTES];
}}}
will break.

Trac comment by cdknight on 2015-09-08 12:15:48:
Replying to [comment:1 jphickey]:

...{{{cfe_platform_cfg.h}}} should not be available for inclusion by applications....

The value of the parameter can be acquired at run time rather than compile time

I'd like to retain as much visibility of compile/runtime configuration as possible and require as little re-writing of app code as possible. Global symbols could be used to give everyone access, but will increase the heap size which may be a problem for low-memory environments. Also, adds a memory read to every access. An array could be used to reduce the symbol table impact.
A simple example:
cfe_platform_cfg.h:
{{{
...
extern const uint32 CFE_SB_DEFAULT_MSG_LIMIT;
extern const uint32 CFE_SB_BUF_MEMORY_BYTES;
...
extern const char * const CFE_SB_DEFAULT_ROUTING_FILENAME;
...
}}}
cfe_platform_cfg.c:
{{{
...
const uint32 CFE_SB_DEFAULT_MSG_LIMIT = 4;
const uint32 CFE_SB_BUF_MEMORY_BYTES = 524288;
...
const char * const CFE_SB_DEFAULT_ROUTING_FILENAME = "/ram/cfe_sb_route.dat";
...
}}}

Trac comment by glimes on 2016-11-08 14:17:08:
Current crop of cfe-next are all going into CFE 6.6

Trac comment by jphickey on 2015-10-06 12:33:09:
== UPDATED ==
This ticket was last discussed during the 2015-09-08 CCB meeting, and at that time it was requested that the message-handling changes be further separated from the macro name changes.
Ticket #144 was created to address the message-handling changes, namely removing the explicit references to size macros e.g. OS_MAX_API_NAME where data is copied to/from message buffers and replacing this with sizeof().
The above ticket should be considered a prerequisite to this one, as it allows the message payload to be defined in any way, as long as the string is an array (a requirement for SB payloads), and the runtime code will still work.
Branch trac-12-platform-msg-limits-take2 has been rebased on top of #144 to reflect this.  Commit [changeset:25f11c8] reflects the current proposed update under this ticket, which now consists solely of the macro name changes.

Trac comment by jphickey on 2017-04-27 13:57:46:
== Resurrecting this changeset for CFE 6.6... ==
Fixing this remaining issue will be required before any EDS changes can be brought in.  In addition this causes problems when attempting to build binaries that are not CPU-specific, since commands and telemetry definitions may vary between CPUs
I have pushed a new branch up to babelfish, called trac-12-platform-msg-limits-take3, which is based on today's development branch (2017-04-27).
On this branch there are actually two commits:
[changeset:81c64e0] : rebases the previous 2015-era changeset to the latest development.
[changeset:5099bc5] : fixes up the remaining implicit inclusion of cfe_msgids.h
I kept these as separate commits as they are probably worthy of separate review, and not necessarily tied to one another.

Trac comment by jphickey on 2017-05-16 14:45:04:
Commit [changeset:4dd9d3be] addresses the topics discussed in the 2017-05-16 CCB meeting.

removal of OSAL config includes from message definitions cfe_sb_msg.h.  Also removed osapi.h from cfe_evs_msg.h for the same reason.
removal of CFE_PLATFORM_ES_PERF_MAX_IDS configuration macro and keeping only the mission scope version, to be clear that perf IDS are mission-wide allocations.

The second bullet item required touching several additional files to change references from CFE_PLATFORM_ES_PERF_MAX_IDS to CFE_MISSION_ES_PERF_MAX_IDS

Trac comment by sstrege on 2017-05-16 12:42:52:
Recommend removing the CFE_PLATFORM_ES_PERF_MAX_IDS configuration macro.  Performance IDs should be a mission wide assignment.  Providing a platform configuration for setting the max is misleading.
Other than that I recommend/approve the changesets.

Trac comment by jhageman on 2019-03-05 14:58:28:
Milestone renamed


text:
Unsafe macro in cfe_version.h

Is your feature request related to a problem? Please describe.
Unsafe macro (violates coding standard)
https://github.com/nasa/cFE/blob/06c08268f2d7a7fe72aceec8c33201ce6ccba2f4/fsw/cfe-core/src/inc/cfe_version.h#L48
Describe the solution you'd like
Add parentheses
Describe alternatives you've considered
None
Additional context
None
Requester Info
Jacob Hageman - NASA/GSFC

Nevermind.  Read up on it, since it quotes it's safe.

Nevermind. Read up on it, since it quotes it's safe.

Can you add the stuff you read so we can reference it if it comes up again? I was actually discussing this earlier and wondering if we need to have the integer macros at all. If they're all strings then we wouldn't need the helper functions.

My preference is to remove any unused macros!  I just brushed up on the preprocessor macro at https://www.cprogramming.com/reference/preprocessor/stringizing-operator.html, and wrote a quick test program to try and break it and I couldn't (just to confirm it behaved as expected on random strings).

authors: astrogeco skliper


text:
Review pull request template

Template should include these;

Description of the code change (defect or feature enhancement)
Reviewer (in the PR itself)
Storybook documentation update (if needed)
Version change
Changelog update
package.json + package-lock.json update

Need to understand how the version, changelog and package/package-lock gets updated... manually or automatically

Updated in this PR #8

repo: nascentdigital/pm-kit


text:
NPM support

Hi, I notice that pyrometer would parse all the dependencies used by import. And in some projects, the dependencies may comes from npm or other package managers. If there is a need for support for import statements starts with "@", I can try to implement this and send a pull request to this repo.
There is an example
// SPDX-License-Identifier: MIT
pragma solidity 0.8.9;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "../shared/ProtocolConstants.sol";

contract XVader is ProtocolConstants, ERC20Votes, ReentrancyGuard {
    // Address of vader token
    IERC20 public immutable vader;

    /*
     * @dev Initializes contract's state by setting vader's tokens address and
     * setting current token's name and symbol.
     **/
    constructor(IERC20 _vader)
        ERC20Permit("XVader")
        ERC20("XVader", "xVADER")
    {
        require(
            _vader != IERC20(_ZERO_ADDRESS),
            "XVader::constructor: _vader cannot be a zero address"
        );
        vader = _vader;
    }
......

You need to provide a --remappings remappings.txt. A good PR would be documenting this though, as well as updating the panic to suggest adding the remappings flag! (Please make sure you have the latest version and if you still have an issue let me know!)

Thanks a lot! It works!

authors: IzaiahSun brockelmore

repo: nascentxyz/pyrometer


text:
消息提示没有提示消息内容

弹窗提示消息只有你有1条未读消息的提醒，没有消息内容的提示

内容提示，比较麻烦，后续会尝试

这个功能实用，老是要点击一下才能看内容。

authors: nashaofu talenhao zcldzh

repo: nashaofu/dingtalk

license: mit

license_source: bigquery


text:
Milestone 2 refactor

This PR combines milestones 1 and 2. Databases is the new milestone 2.
Foundations now has a mastery directory quizzes
@chortlehoort

Can you provide more details about why you feel the merge is needed? Removing the milestone impacts more than just the structure of the repo, but also changes how we collect feedback from students because the Node and the Python milestones still have the CLI section.
Just to provide some additional context, I've made enhancements to the CLI milestone during the Python course to cover more material which I was intending on migrating over the C#.
The intent for the Foundations milestone was to introduce the students to the language, tools, development concepts and unit tests.

This large of a change requires some discussion with the entire team before it's merged

@chortlehoort
When we spoke about this change some while ago (towards the beginning/middle of milestone 1), where milestone 2 as it stood, made more sense to be rolled into the the first milestone given it's length and that CLI is covered as a result of the exercises in the first milestone.
I'll do better with getting approval before shifting the milestones around,

Here's an thought. Let's try to find a time where you, Scott, Denise, and myself can sit and discuss the first two milestones and see what makes sense. Take a look at what we defined for the 2nd milestone in the Python class (https://github.com/nashville-software-school/python-milestones/tree/master/02-command-line-applications). It's got a lot more meat on its bones.
My thought was that the CLI milestone would prepare them for DB by introducing serialization and relating objects together.
Let me see what I can schedule with everyone.

authors: chortlehoort jcockhren


text:
this requires 1.20.1

ive been asking around and trying to learn fabric just to get the stepup mod in 1.20 and i was so happy to see you did it already but its saying that i need to have 1.20.1 like many other mods so it seems like an issue in the system but ty sooo much for making this, i cant wait to use it, theres so many mods in the same spot and might die. now im waiting on invintory tabs, mod settings, rpg hud and so many more that might not be ported

Hmm, it wasn't my intention for this to be 1.20.1 only. I'll see if I can get that sorted, thanks


text:
Add MAP-KEYS navigator

Like MAP-VALS, it should be optimized further than just doing (def MAP-KEYS (comp-paths ALL FIRST)).

Implemented in master.

repo: nathanmarz/specter


text:
WebGL crash with Meet VideoKit 0.0.10 - MediaDeviceQuery_DiscoverDevices

Hi,
In WebGL build sometimes (very often) when loading scene with NatML Meet Segmentation, there is a crash.
Please take a look in the Profiler screenshot - seems like MLModelData.OnEnable() drops FPS suddenly, and maybe this is a cause of crash? If not - could you suggest some solution for this? Is there a way to improve memory size for WebGL?
Or maybe it is directly connected with MediaDeviceQuery_DiscoverDevices?
This error occurs:
testtest.framework.js:3 Uncaught RuntimeError: memory access out of bounds     at dlfree (testtest.wasm:0x9b73e)     at MemoryManager::LowLevelFree(void*, unsigned long) (testtest.wasm:0x2c6f13)     at UnityDefaultAllocator<LowLevelAllocator>::Deallocate(void*) (testtest.wasm:0x18a6591)     at ThreadsafeLinearAllocator<false>::TryDeallocate(void*) (testtest.wasm:0x699528)     at MemoryManager::Deallocate(void*, MemLabelId, char const*, int) (testtest.wasm:0x4a2737)     at operator delete(void*) (testtest.wasm:0x9125e)     at NDMediaDeviceGetName (testtest.wasm:0xf193bd)     at NatDevice_Name_m7BE4A206300A690F90B92697C3E540277F177766 (testtest.wasm:0x7438fc)     at AudioDevice__ctor_mE8A1C592C648F889936191E95E8E557A845B30E6 (testtest.wasm:0x117f137)     at U3CDiscoverAudioDevicesU3Ed__20_MoveNext_m3947F1662EDDA93971217F8C7E67172E63FDE931 (testtest.wasm:0x1979979)     at InterfaceFuncInvoker0<Toggle_tBF13F3EBA485E06826FD8A38F4B4C1380DF21A1F*>::Invoke(unsigned short, Il2CppClass*, Il2CppObject*) (testtest.wasm:0x918b5)     at dynCall_iiii (testtest.wasm:0x1749226)     at invoke_iiii (testtest.framework.js:3:525248)     at List_1_AddEnumerable_mFD4E2919839A27C7CEACADF62222C63701302D02_gshared (testtest.wasm:0x1e81a36)     at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915_VoidU2A_t104EAEFBD2D237A8C29618913DA9B4D99355E965(void (*)(), MethodInfo const*, void*, void**, void*) (testtest.wasm:0xdf43cc)     at InvokerActionInvoker1<RtcStats_tB82CEAB4F971E9D092B96B90C0C3BFFB035D1BE8>::Invoke(void (*)(), MethodInfo const*, void*, RtcStats_tB82CEAB4F971E9D092B96B90C0C3BFFB035D1BE8) (testtest.wasm:0x9292a)     at List_1_InsertRange_m729639E2C8D1AA7579AC78D259085921E7DC72F2_gshared (testtest.wasm:0xf5b303)     at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915_CancellationToken_t51142D9C6D7C02D314DA34A6A7988C528992FFED_RuntimeObject(void (*)(), MethodInfo const*, void*, void**, void*) (testtest.wasm:0x1c3d9d)     at InvokerActionInvoker2<int, String_t*>::Invoke(void (*)(), MethodInfo const*, void*, int, String_t*) (testtest.wasm:0xa0b5a)     at List_1_AddRange_m44DED39FFEBC8F2ACF6162DB065B649E888B9C57_gshared (testtest.wasm:0xf5ba9a)     at List_1_AddRange_m66D40F60D60CF3FA653432ABEBEBF703840689DB(List_1_t437B6C3879E969156A381BDC3C459CF809D39DDF*, Il2CppObject*, MethodInfo const*) (testtest.wasm:0xa11cd)     at MediaDeviceQuery_DiscoverDevices_m0520738B6315FF77EFB342F12AB3CF55102140C5 (testtest.wasm:0xf450aa)     at MediaDeviceQuery__ctor_mE2C86815B53C8771C6F5BD82319E56505C59FF82 (testtest.wasm:0x2c74bc)     at U252EU252DU252DU252EU252EU252EU252DU252DU252DU252EU252DU252DU252DU252EU252DU252DU252DU252EU252EU252EU252EU252DU252DU252EU252DU252EU252DU252DU252EU252EU252EU252EU252EU252DU252EU252EU252EU252DU252EU252EU252EU252EU252EU252DU252DU252EU252E_U252EU252EU252DU252DU252DU252EU252DU252EU252DU252EU252DU252EU252EU252EU252DU252DU252EU252EU252EU252EU252DU252EU252EU252EU252DU252DU252EU252EU252EU252EU252DU252EU252DU252DU252DU252DU252EU252DU252DU252EU252DU252DU252EU252DU252DU252EU252E_mA165F6D2E8CE5BDA1F792073168AB4F5C78B81EB (testtest.wasm:0x682594)     at NatMlMeetBackgroundRemover_SwitchCameraDeviceToTarget_mF727B58824BDA93FF90F16C8943B75A8A71D35A5 (testtest.wasm:0x186543)     at HallwayViewModel_U252DU252DU252EU252EU252EU252EU252EU252DU252EU252EU252DU252DU252EU252DU252EU252DU252EU252EU252EU252DU252DU252DU252DU252EU252DU252EU252DU252DU252EU252EU252EU252DU252DU252DU252DU252EU252DU252EU252EU252DU252EU252DU252DU252DU252EU252DU252E_mBED46317D9DAB642EACBDF579B8CC8D473313E97 (testtest.wasm:0x783e11)     at HallwayViewModel_U252EU252EU252EU252EU252EU252DU252DU252EU252DU252DU252DU252EU252DU252DU252DU252DU252EU252DU252DU252DU252DU252EU252EU252EU252EU252DU252EU252EU252EU252DU252DU252EU252EU252DU252EU252EU252EU252DU252DU252DU252EU252EU252DU252EU252EU252DU252E_mE7C7F9E1E9446C4ECB510F50DDA0C22E8FE59917 (testtest.wasm:0xfe70f4)     at HallwayViewModel_Start_mD1BD1C85DC59E11053F9FD98C15301F462C6A8B8 (testtest.wasm:0x1f49417)     at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void (*)(), MethodInfo const*, void*, void**, void*) (testtest.wasm:0x1c82f76)     at il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) (testtest.wasm:0x40d8b2)     at dynCall_iiii (testtest.wasm:0x1749226)     at invoke_iiii (testtest.framework.js:3:525248)     at il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) (testtest.wasm:0xf56fe)     at il2cpp_runtime_invoke (testtest.wasm:0xaef264)     at scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) (testtest.wasm:0x3c948a)     at ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) (testtest.wasm:0x1c30a1)     at ScriptingInvocation::Invoke(ScriptingExceptionPtr*) (testtest.wasm:0xf60f9)     at MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethodPtr, ScriptingObjectPtr) (testtest.wasm:0x7473aa)     at MonoBehaviour::Start() (testtest.wasm:0x36b6c3)     at MonoBehaviour::DelayedStartCall(Object*, void*) (testtest.wasm:0x1e2128e)     at DelayedCallManager::Update(int) (testtest.wasm:0x2059dc9)     at InitPlayerLoopCallbacks()::EarlyUpdateScriptRunDelayedStartupFrameRegistrator::Forward() (testtest.wasm:0x1f0da91)     at ExecutePlayerLoop(NativePlayerLoopSystem*) (testtest.wasm:0x103f5a0)     at ExecutePlayerLoop(NativePlayerLoopSystem*) (testtest.wasm:0x103f614)     at MainLoop() (testtest.wasm:0xf50fda)     at dynCall_v (testtest.wasm:0x1748a79)     at browserIterationFunc (testtest.framework.js:3:257137)     at callUserCallback (testtest.framework.js:3:210100)     at Object.runIter (testtest.framework.js:3:211360)     at Browser_mainLoop_runner (testtest.framework.js:3:209635)

I have found a second error, which sometimes shows at the same moment as the one above:
testgoo.framework.js:3 Uncaught TypeError: Cannot read properties of null (reading 'remove')     at methodCaller_void_$$ (eval at new_ (testgoo.framework.js:3:197163), <anonymous>:4:20)     at __emval_call_void_method (testgoo.framework.js:3:196181)     at NatML::Devices::CameraDevice::StopRunning() (testgoo.wasm:0x1e13499)     at NDMediaDeviceStopRunning (testgoo.wasm:0x49cc2b)     at CameraDevice_StopRunning_mD3E4E4E031EDFD4EDCFEF584F12C41C0C3131E82 (testgoo.wasm:0x8009e6)     at VideoKitCameraManager_StopRunning_m3EC6267DD56C025F8E956F7659086DA23D04CBD3 (testgoo.wasm:0x1578f4)     at VideoKitCameraManager_OnDestroy_m6818EA551700A0A76729AE0AD07E8812281A81F5 (testgoo.wasm:0x1846ca7)     at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void (*)(), MethodInfo const*, void*, void**, void*) (testgoo.wasm:0x1c91be2)     at il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) (testgoo.wasm:0x40d902)     at dynCall_iiii (testgoo.wasm:0x1754f21)     at invoke_iiii (testgoo.framework.js:3:525248)     at il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) (testgoo.wasm:0xf6224)     at il2cpp_runtime_invoke (testgoo.wasm:0xaf0dde)     at scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) (testgoo.wasm:0x3c97f1)     at ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) (testgoo.wasm:0x1c79ca)     at ScriptingInvocation::Invoke(ScriptingExceptionPtr*) (testgoo.wasm:0xf6ac5)     at SerializableManagedRef::CallMethod(Object&, ScriptingMethodPtr) (testgoo.wasm:0xdcbc77)     at MonoBehaviour::CallMethodInactive(ScriptingMethodPtr) (testgoo.wasm:0x18a236)     at MonoBehaviour::WillDestroyComponent() (testgoo.wasm:0x1e2a8d2)     at PreDestroyRecursive(GameObject&, unsigned long*) (testgoo.wasm:0xe63c24)     at DestroyObjectHighLevel(Object*, bool) (testgoo.wasm:0x126c34)     at UnloadGameScene() (testgoo.wasm:0xc0a75a)     at LoadSceneOperation::PlayerLoadSceneFromThread() (testgoo.wasm:0xf6061d)     at LoadSceneOperation::IntegrateMainThread() (testgoo.wasm:0x1e879eb)     at PreloadManager::UpdatePreloadingSingleStep(PreloadManager::UpdatePreloadingFlags, int) (testgoo.wasm:0xe62d5b)     at PreloadManager::UpdatePreloading() (testgoo.wasm:0xe62b7c)     at InitPlayerLoopCallbacks()::EarlyUpdateUpdatePreloadingRegistrator::Forward() (testgoo.wasm:0x1f168bc)     at ExecutePlayerLoop(NativePlayerLoopSystem*) (testgoo.wasm:0x1048343)     at ExecutePlayerLoop(NativePlayerLoopSystem*) (testgoo.wasm:0x10483b7)     at MainLoop() (testgoo.wasm:0xf586a6)     at dynCall_v (testgoo.wasm:0x1754774)     at browserIterationFunc (testgoo.framework.js:3:257137)     at callUserCallback (testgoo.framework.js:3:210100)     at Object.runIter (testgoo.framework.js:3:211360)     at Browser_mainLoop_runner (testgoo.framework.js:3:209635)
It points to this part of code in VideoKitCameraManager:
        public void StopRunning () {             cameraDevice?.StopRunning();             output?.Dispose();             output = null;         }
    And in addition I see this warning:

In WebGL build sometimes (very often) when loading scene with NatML Meet Segmentation, there is a crash.

The call stack seems to indicate something about getting the name of the camera device. What browser and Unity versions are you on?

have found a second error, which sometimes shows at the same moment as the one above:

This is related to the first, and happens because the camera preview is being stopped, but due to the first error, the camera is an invalid state.

Hi
Browser version: Chrome Version 110.0.5481.105 (Official Build) (64-bit)
Unity: 2021.3.12f1

Additionally, here are my methods used with MediaDeviceQuery:
`    public static class VideoKitCameraManagerCustom
{
public static CameraDevice GetNextCameraDevice(this VideoKitCameraManager videoKitCameraManager, CameraDevice currentCamera)
{
MediaDeviceQuery.ConfigureAudioSession = false;
var query = new MediaDeviceQuery(MediaDeviceCriteria.CameraDevice);
var devices = query.OrderBy(device => device is CameraDevice camera).ToList();
var currentDeviceIndex = devices.IndexOf(currentCamera);
        if (currentDeviceIndex < devices.Count - 1)
        {
            currentDeviceIndex++;
        }
        else
        {
            currentDeviceIndex = 0;
        }
        var nextDevice = devices[currentDeviceIndex];
        return (CameraDevice)nextDevice;
    }

    public static CameraDevice GetNextTargetCameraDevice(this VideoKitCameraManager videoKitCameraManager, int index)
    {
        MediaDeviceQuery.ConfigureAudioSession = false;
        var query = new MediaDeviceQuery(MediaDeviceCriteria.CameraDevice);
        var devices = query.OrderBy(device => device is CameraDevice camera).ToList();
        var nextDevice = devices[Mathf.Max(0, index)];
        if (nextDevice != null)
        {
            return (CameraDevice)nextDevice;
        }
        else
        {
            return (CameraDevice)devices[0];
        }
    }

    public static int GetCurrentCameraDeviceIndex(this VideoKitCameraManager videoKitCameraManager, CameraDevice currentCamera)
    {
        MediaDeviceQuery.ConfigureAudioSession = false;
        var query = new MediaDeviceQuery(MediaDeviceCriteria.CameraDevice);
        var devices = query.OrderBy(device => device is CameraDevice camera).ToList();
        var currentDeviceIndex = devices.IndexOf(currentCamera);
        return currentDeviceIndex;
    }
}`

Hey @tomaszwozniak123 , can you try VideoKit 0.0.11?

Hey,
I used VideoKit 0.0.11 and get this error instead previous ones (it happens only in browser-Unity Editor works fine). It happens when trying switching scenes:
testgoo.loader.js:1 exception thrown: TypeError: Cannot read properties of null (reading 'remove'),TypeError: Cannot read properties of null (reading 'remove')
    at methodCaller_void_$$ (eval at new_ (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:197163), <anonymous>:4:20)
    at __emval_call_void_method (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:196181)
    at NatML::Devices::CameraDevice::StopRunning() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[116334]:0x25f2b51)
    at CameraDevice_StopRunning_mD3E4E4E031EDFD4EDCFEF584F12C41C0C3131E82 (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[30092]:0xa53001)
    at VideoKitCameraManager_StopRunning_m3EC6267DD56C025F8E956F7659086DA23D04CBD3 (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[5809]:0x1bbebe)
    at VideoKitCameraManager_OnDestroy_m6818EA551700A0A76729AE0AD07E8812281A81F5 (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[79002]:0x1d97e4f)
    at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void (*)(), MethodInfo const*, void*, void**, void*) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[106031]:0x23a4543)
    at il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[16615]:0x52ee7f)
    at dynCall_iiii (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[73323]:0x1c3cf3a)
    at invoke_iiii (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:526839)
    at il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[3695]:0x13f753)
    at il2cpp_runtime_invoke (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[34461]:0xd99a8f)
    at scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[16173]:0x4e91ca)
    at ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[1685]:0xe2e5d)
    at ScriptingInvocation::InvokeChecked(ScriptingExceptionPtr*) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[44139]:0x113695f)
    at SerializableManagedRef::CallMethod(Object&, ScriptingMethodPtr) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[6732]:0x1f760f)
    at MonoBehaviour::WillDestroyComponent() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[116853]:0x260e64e)
    at PreDestroyRecursive(GameObject&, unsigned long*) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[46575]:0x11f2abf)
    at DestroyObjectHighLevel_Internal(Object*, bool) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[29184]:0x9f9a4e)
    at UnloadGameScene() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[38571]:0xefa508)
    at LoadSceneOperation::PlayerLoadSceneFromThread() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[48992]:0x12ed739)
    at LoadSceneOperation::IntegrateMainThread() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[118849]:0x26899d6)
    at PreloadManager::UpdatePreloadingSingleStep(PreloadManager::UpdatePreloadingFlags, int) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[46527]:0x11f0b7d)
    at PreloadManager::UpdatePreloading() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[46526]:0x11f090c)
    at InitPlayerLoopCallbacks()::EarlyUpdateUpdatePreloadingRegistrator::Forward() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[123766]:0x27bce43)
    at ExecutePlayerLoop(NativePlayerLoopSystem*) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[54795]:0x143cde2)
    at ExecutePlayerLoop(NativePlayerLoopSystem*) (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[54795]:0x143ce53)
    at MainLoop() (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[48815]:0x12e476a)
    at dynCall_v (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.wasm:wasm-function[73262]:0x1c3c735)
    at browserIterationFunc (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:257137)
    at callUserCallback (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:210100)
    at Object.runIter (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:211360)
    at Browser_mainLoop_runner (https://v6p9d9t4.ssl.hwcdn.net/html/7446927/Build/testgoo.framework.js:3:209635)

Update for the error above:
When I added these two condition checks to StopRunning() method in the CameraDevice class, it stopped crashing (haven't tested much, so please take it as a hint only):
 public void StopRunning () {
            if (running==false) { return; }
            if (device!=null)
            {
                device.StopRunning().CheckStatus();
            }

            lifecycleHelper?.Dispose();
            lifecycleHelper = default;
            if (previewHandle != default)
                previewHandle.Free();
            previewHandle = default;
        }

Hey @tomaszwozniak123 sorry for the late follow up on this. Your fix is correct, and the fix is landing in 0.0.12.

Fixed in VideoKit 0.0.12.

Hi @olokobayusuf
It seems that this error is back - it happened today (I think it was ok on Friday) - so it is not happening every time.
The platform is WebGL, Firefox browser. It is happening, when I change scenes (on both a camera from VideoKit is needed).
An error occurred running the Unity content on this page. See your browser JavaScript console for more info. The error was:
TypeError: handle is null
methodCaller_void_$$@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.framework.js line 3 > Function:4:14
__emval_call_void_method@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.framework.js:3:277631
NatML::Devices::CameraDevice::StopRunning()@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[115563]:0x25ccc8e
CameraDevice_StopRunning_mD3E4E4E031EDFD4EDCFEF584F12C41C0C3131E82@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[29876]:0xa48690
VideoKitCameraManager_StopRunning_m3EC6267DD56C025F8E956F7659086DA23D04CBD3@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[6678]:0x1f4d41
VideoKitCameraManager_OnDestroy_m6818EA551700A0A76729AE0AD07E8812281A81F5@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[78437]:0x1d8bd5e
RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void (*)(), MethodInfo const*, void*, void**, void*)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[105351]:0x238224b
il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[16546]:0x52f80f
dynCall_iiii@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[72758]:0x1c2c10e
invoke_iiii@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.framework.js:3:608484
il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[3697]:0x1406c0
il2cpp_runtime_invoke@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[34231]:0xd8c770
scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[16104]:0x4ea009
ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[1688]:0xe1211
ScriptingInvocation::InvokeChecked(ScriptingExceptionPtr*)@https://v6p9d9t4.ssl.hwcdn.net/html/7592026/Build/testgoo.wasm:wasm-function[43792]:0x1136b53

Works great, thanks! :)

repo: natmlx/videokit


text:
Extreamly slow when send message to multiple Topics (300) for first time

Hi,
I did a test and result is weird. Please take a look

I created 300 subscription that subscribed  300 Topic.
I Publish 1 message to each Topic.
Wait for all subscriptions receive first message.
(takes over 290,000ms to send 300 messages to 300 Topics (1 message per Topic))
Send 10 messages to each Topic
wait for all subscription receive 10 messages
(take 7ms) (takes over 7ms to send 3000 messages to 300 Topics (10 messages per Topic))

Im using:
NATS: nats-server version 0.9.4
OS: Window 10
CPU: Intel Xeon E3-1240
RAM: 8GB
Client: https://github.com/nats-io/csharp-nats
There is my code
    class Program
    {
        static void Main(string[] args)
        {
            var topics = 300;

            //init connection and subscribers

            var connFac = new ConnectionFactory();
            var subConn = connFac.CreateConnection();
            var pubConn = connFac.CreateConnection();

            var received = 0;
            var subscriptions = new List<IAsyncSubscription>();

            for (var topicId = 0; topicId < topics; topicId++)
            {
                var subscription = subConn.SubscribeAsync(topicId.ToString(),
                    (sender, x) => { Interlocked.Increment(ref received); });

                subscriptions.Add(subscription);
            }

            //1st run: 300 topics, 1 messages per topic

            var messagesPerTopic = 1;
            var noOfMessages = topics * messagesPerTopic;
            Console.WriteLine("Test with {0:n0} topics, {1:n0} messages per topic", topics, messagesPerTopic);

            var sw = Stopwatch.StartNew();
            for (var topicId = 0; topicId < topics; topicId++)
            {
                for (var i = 0; i < messagesPerTopic; i++)
                {
                    pubConn.Publish(topicId.ToString(), Encoding.UTF8.GetBytes("hello"));
                }
            }

            while (received < noOfMessages && sw.Elapsed.TotalMinutes < 5)
            {
                Thread.Sleep(1);
            }
            sw.Stop();

            Console.WriteLine("{0:n0} messages received in {1:n0}ms", received, sw.ElapsedMilliseconds);
            Console.WriteLine("{0:n0} msg/s", received * 1000 / sw.ElapsedMilliseconds);

            //2nd run: 300 topics, 10 messages per topic

            received = 0;
            messagesPerTopic = 10;
            noOfMessages = topics * messagesPerTopic;

            Console.WriteLine("Test with {0:n0} topics, {1:n0} messages per topic", topics, messagesPerTopic);

            sw = Stopwatch.StartNew();
            for (var topicId = 0; topicId < topics; topicId++)
            {
                for (var i = 0; i < messagesPerTopic; i++)
                {
                    pubConn.Publish(topicId.ToString(), Encoding.UTF8.GetBytes("hello"));
                }
            }

            while (received < noOfMessages && sw.Elapsed.TotalMinutes < 5)
            {
                Thread.Sleep(1);
            }
            sw.Stop();

            Console.WriteLine("{0:n0} messages received in {1:n0}ms", received, sw.ElapsedMilliseconds);
            Console.WriteLine("{0:n0} msg/s", received * 1000 / sw.ElapsedMilliseconds);

            foreach (var s in subscriptions)
            {
                s.Dispose();
            }

            pubConn.Dispose();
            subConn.Dispose();

        }
    }

@tamnm , Thank you for using NATS!
I appreciate the sample program and environmental information you provided.
The connection defaults are setup to scale for very high throughput with a smaller number of subscribers.  In order to handle large number of subscribers, I suggest you use the SubscriberDeliveryTaskCount connection option to reduce the number of tasks handling subscriptions.
I was able to get around 390,000 msgs/second (on my slow VM) in your test after setting the subscriber task count to 20.
            var subConn = connFac.CreateConnection();
            subConn.Opts.SubscriberDeliveryTaskCount = 20;

Does this resolve your issue?
Thanks,
Colin

Hopefully this resolved your issue - I'm closing this due to inactivity.

repo: nats-io/csharp-nats


text:
[IMPROVED] Better attempt at delivering messages to queue subscriptions

This PR is based out of #633. It imroves parsing QRSID so that the
TestRouteQueueSemantics test now passes (when dealing with malformed
QRSID).
A test similar to what is reported in #632 was also added. This
test however, uncovers a race condition that will be fixed in a
separate PR.
Resolves #632

Coverage increased (+0.01%) to 92.096% when pulling ee8f001131a492e9621737da09fbbe7ea344b8e2 on fix_632 into dd3dccc55a2368bed195baf1327da412a432d97a on master.

@derekcollison I believe I have addressed the issues regarding comments. We need to think if we want this behavior to be merged or stick with the old one. I believe that this change still honor the at-most and there should not be duplicates. But original behavior was "correct" too (since we don't guarantee at-least-once, but at-most-once).

As long as we can guarantee that we are still at most-once then LGTM. If we can not be sure of that then we need to revisit the changes.

@derekcollison After careful review and to the best of my knowledge, as the code stands in this PR, we still honor at-most-once delivery but do a better job at delivery messages to a queue group. If you approve, please approve the PR (it is currently in Request Changes status).

authors: coveralls derekcollison kozlovic

repo: nats-io/gnatsd


text:
Add stream compression, consumer with multiple subject filters & stream subject transforms

Signed-off-by: Tomasz Pietrek tomasz@nats.io

converting to draft, as I want to find a way to test parsing and handling of fields.

repo: nats-io/nack


text:
Allow building macOS apps targeting 10.14 or 10.15 macOS version

Proposal
gal requires macOS 11 (Big Sur) in order for the gallery saving to work at all. If Xcode project targets lower version (e.g. 10.14 or 10.15), then the project doesn't build. I suggest, if possible, allowing usage of gal on macOS targets lower than 11.0, and instead throw UnsupportedError, if gallery saving is not available. I wonder, whether .swift files will build at all, yet I see #available(iOS 14, macOS 11, *) directives in the source code, which my hope is based on.
Perhaps Gal.isSupported() might be added to know, whether gal is available (may include Linux and Web to that indicator, which are not supported by gal). It might be better, than adding conditions by the developer, as it wouldn't require checking whether the package updates to support the platform.
Use case
The primary reason of allowing lower macOS versions to run is simply the users base. According to market share, 3% to 5% of macOS in the world still are running 10.14 Mojave (perhaps a bit more running 10.15 Catalina). And Flutter supports macOS 10.14+.

Thank you for your contribution 🤝 @SleepySquash
There is a possibility to make macOS 15 the lowest supported version, but before that we need to investigate the API.

I wonder, whether .swift files will build at all

Yes. This is because the main function for saving, PHAssetChangeRequest in photo-kit, is only available on macOS 10.15 or later. See #146.
For that reason, 10.14 and below will not be added to support at all at this time.

macOS targets lower than 11.0, and instead throw UnsupportedError
Perhaps Gal.isSupported() might be added to know, whether gal is available

This does not look good for me. Users should check the supported version of a plugin and expect to be able to use all features within that version. They do not expect to get errors only with older versions.

@natsuk4ze, oh, sorry for not noticing the issue you mentioned, it's my mistake, I apologise for your time taken.
Thank you for the detailed answer! After investigating the macOS Big Sur supported devices, I suppose, it doesn't really make sense to target 10.15 instead of 11.0. Main reason I hoped for version downgrade is Mojave, as it is the last macOS to support 32 bit applications, and some users may stick with it only because of that. And since that doesn't work out, I guess, everything is ok.

They do not expect to get errors only with older versions

Well, I do agree. It is indeed better to know the package works on every OS version the application is built for.
I'm closing the issue. Thank you for your time!

I'm closing the issue. Thank you for your time!

You're welcome. Thanks again for your contribution 😊 @SleepySquash


text:
No LICENSE.md

💕

fix(#1): add LICENSE.md

repo: natthasath/demo-closed-issue


text:
fixed encoding/decoding of Data

fixed Flat encoding for Data.

(btw,  tests will be later with typed-sir)

repo: nau/scalus


text:
🛑 Harmony Bot Website is down

In e6374aa, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 7dc88ac.


text:
🛑 Harmony Bot Website is down

In 9442cc2, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 35ed0b3.


text:
🛑 Harmony Bot Website is down

In 20c0b91, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 33c865d.


text:
🛑 Harmony Bot Website is down

In 67a60ee, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 8ad0066.


text:
🛑 Harmony Backup Bot is down

In f532cba, Harmony Backup Bot ($HARMONY_BACKUP) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Backup Bot is back up in ee2a39c.


text:
🛑 Harmony Bot Website is down

In 12f37ad, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in f6ea9b5.


text:
🛑 Harmony Bot Website is down

In 720cace, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in b429e65.


text:
🛑 Harmony Bot Website is down

In fde7d3d, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in c9bf6a0.


text:
Transparent Terminal Support

Really liking this vim theme, especially the deep variation.
However, one thing keeping me from using it is that I wish to have a transparent background in my supported terminal.
I was hoping you could implement a vim variable to toggle the appropriate colors to make that happen.
An example would be https://github.com/joshdick/onedark.vim#onedarkextend_highlight

I will add a flag to enable or disable
vim.g.onedark_transparent_background = true

Added transparent background support
To enable transparent background
let g:onedark_transparent_background = 1 " By default it is 0
colorscheme onedark

vim.g.onedark_transparent_background = true -- By default it is false
require('onedark').setup()

Hi, just wondering whether it is possible to more finely customise the transparency of the background, e.g. opacity of 0.8.

@axieax Please raise it as new issue. I will add that option

authors: Christian77777 axieax navarasu


text:
Broadcasting되는 Operation에서 timeout 발생 시, exception 메시지 보강.

version, stats 등의 broadcast 되는 operation의 타임아웃 메시지를 보강한다.
타임아웃 메시지 보강과 관련된 PR Link는 아래와 같다, 해당 이슈는 아래의 PR과 별도로 처리하도록 한다.
https://github.com/naver/arcus-java-client/pull/319

PR 반영되어서 close 합니다.

repo: naver/arcus-java-client


text:
Multibyte key test

Added junit test code for key strings in multi-byte languages
(https://github.com/naver/arcus-java-client/issues/35)

Close missed PR


text:
Questions about JakartaValidationPlugin and validation logic for creating fixture objects

Describe your question
My understanding is that the JakartaValidationPlugin reads the settings in the validation annotation and creates a fixture object with values that match the settings.
This is not exact, but the way I understand the above logic to work is as follows.

Create a fixture object
Validate that the field in the fixture object has a value assigned to it that meets the validation annotation conditions
Return the Fixture object if validation succeeds for all fields, otherwise recreate the Fixture object

It seems to be repeating the process of creating an object by first filling the fields with random values and then validating that the object is valid, rather than filling the fields with the validated values from the beginning.
So, I think if we can, it would be better to create the object when all the fields of the object have values that satisfy the conditions.
Of course, since Fixture Monkey uses the logic of the hibernate validator, in some ways I think creating an object and running the validation logic is a natural and much more common implementation.
I'm curious about the design history or opinions of the maintainer on this.

@doljae
Hello, I think the bug causes the misunderstanding.
Fixture Monkey works as follows.

It seems to be repeating the process of creating an object by first filling the fields with random values and then validating that the object is valid, rather than filling the fields with the validated values from the beginning.

Fixture Monkey has two logical flows to satisfy the validation.

Repeat to generate a value within each property that satisfies the condition constraints given by the validation annotation.
2.Repeat to generate an instance until validated by the validator(ex, Hibernate Validator).

For better understanding, you can check the classes below.

JakartaValidationConstraintGenerator,
JqwikJavaArbitraryResolver

Thank you.

Thanks for your detailed explanation.
Which jqwik-related classes actually generate values please?

@doljae

Which jqwik-related classes actually generate values please?

I didn't understand it properly. Can you elaborate on that?

authors: doljae seongahjo

repo: naver/fixture-monkey


text:
[#4326] Enhances handling when an exception occurs in PinpointClientHandler

handle exception when execute channel open operation

Codecov Report

Merging #4328 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #4328      +/-   ##
==========================================
+ Coverage   40.95%   40.97%   +0.01%
==========================================
  Files        2419     2419
  Lines       74791    74794       +3
  Branches    10102    10103       +1
==========================================
+ Hits        30628    30644      +16
+ Misses      41351    41339      -12
+ Partials     2812     2811       -1

Impacted Files
Coverage Δ

...point/rpc/client/DefaultPinpointClientHandler.java
72.61% <100%> (+2.83%)
:arrow_up:

...tor/metric/datasource/DefaultDataSourceMetric.java
75.75% <0%> (-3.04%)
:arrow_down:

...corp/pinpoint/rpc/stream/StreamChannelManager.java
70.68% <0%> (-1.73%)
:arrow_down:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
65% <0%> (-1.43%)
:arrow_down:

...cluster/zookeeper/ZookeeperClusterDataManager.java
64.62% <0%> (-0.69%)
:arrow_down:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
81.11% <0%> (+1.04%)
:arrow_up:

...pinpoint/profiler/monitor/DeadlockMonitorTask.java
19.76% <0%> (+1.16%)
:arrow_up:

...m/navercorp/pinpoint/test/OrderedSpanRecorder.java
74.03% <0%> (+1.92%)
:arrow_up:

...om/navercorp/pinpoint/rpc/codec/PacketDecoder.java
63.82% <0%> (+2.12%)
:arrow_up:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
85.36% <0%> (+2.43%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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

authors: codecov-io koo-taejin

repo: naver/pinpoint


text:
Bygg av 20200227132144-bcef3eb

Kommenter med /promote 20200227132144-bcef3eb cluster, hvor cluster er et gyldig clusternavn

Cluster
dev-sbs
prod-sbs

/promote 20200227132144-bcef3eb dev-sbs

repo: navikt/foreldrepengesoknad


text:
Deploy av 20220912112618-3604abe

3604abe36250417c9e83693685fd3b5df3a94e84

/promote dev-gcp

/promote prod-gcp

authors: espenwaaga grutkowska


text:
Geliştirme Yapmanın Yolları

Bir kişinin bu repository üzerinde geliştirme yapabilmesi için aşağıdaki sorulara cevap bulabilmesi gerekir.

Proje local ortama kurulduktan sonra nasıl çalıştırılacak?
Projenin image, sass ve js kodları nasıl bir işlemden geçirilerek assets klasörüne taşınacak?
Pull Request hangi branch'e atılacak, nasıl birleştirilecek?
Commit yazma kuralları nasıl olacak?

@alperen Selam,
Standart bir WordPress teması olduğumuz için bunları açıklamayı düşünmemiştim. Readme dosyasında güncellemeler yaptım. Eğer senin için yeterli gelmezse yeniden issue açabilirsin.
Geliştirme yapmak istediğin bir konu varsa sana geliştirme ortamı oluşturur bu sayede eksiğim olursa tamamlarım.

authors: alperen hmert


text:
🛑 NBB is down

In dd054c5, NBB (https://stat.nbb.be/restsdmx/sdmx.ashx/GetDataStructure/ALL) was down:

HTTP code: 429
Response time: 788 ms

Resolved: NBB is back up in 404af6e.

repo: nbbrd/sdmx-upptime


text:
🛑 ESTAT is down

In a4d3a11, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in cd4740a after 699 days, 0 hours, 40 minutes.


text:
🛑 ESTAT is down

In f31dfb7, ESTAT (http://ec.europa.eu/eurostat/SDMX/diss-web/rest/dataflow/ESTAT/all/latest/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in de6350b.


text:
🛑 NBB is down

In 07bbbd7, NBB (https://stat.nbb.be/restsdmx/sdmx.ashx/GetDataStructure/ALL) was down:

HTTP code: 429
Response time: 587 ms

Resolved: NBB is back up in dd0807f after 13 minutes.


text:
🛑 NBB is down

In eacc036, NBB (https://stat.nbb.be/restsdmx/sdmx.ashx/GetDataStructure/ALL) was down:

HTTP code: 429
Response time: 590 ms

Resolved: NBB is back up in 92aecb8 after 8 minutes.


text:
🛑 ESTAT is down

In 0e395f8, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 5d2ebfb after 6 minutes.


text:
🛑 ESTAT is down

In e69efad, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 965449c after 8 minutes.


text:
🛑 IMF is down

In b83c590, IMF (http://dataservices.imf.org/REST/SDMX_XML.svc/Dataflow) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IMF is back up in cf7ca01 after 18 minutes.


text:
🛑 ESTAT is down

In 136b2be, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 8578a5e after 14 minutes.


text:
🛑 ESTAT is down

In 1d705a0, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 9df045e after 20 minutes.


text:
🛑 ESTAT is down

In 21769c6, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 565f47a after 13 minutes.


text:
🛑 ISTAT is down

In 51e7e0e, ISTAT (https://esploradati.istat.it/SDMXWS/rest/dataflow/all/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ISTAT is back up in 48cfe40 after 45 minutes.


text:
🛑 NBB is down

In 3d11ea5, NBB (https://stat.nbb.be/restsdmx/sdmx.ashx/GetDataStructure/ALL) was down:

HTTP code: 429
Response time: 501 ms

Resolved: NBB is back up in 7a596dd after 31 minutes.


text:
🛑 NBB is down

In 64b1b65, NBB (https://stat.nbb.be/restsdmx/sdmx.ashx/GetDataStructure/ALL) was down:

HTTP code: 429
Response time: 647 ms

Resolved: NBB is back up in 73ae73f.


text:
🛑 ESTAT is down

In ae9844e, ESTAT (https://ec.europa.eu/eurostat/api/dissemination/sdmx/2.1/dataflow/ESTAT/all/latest) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ESTAT is back up in 6ac156e.


text:
🛑 Lavalink is down

In 3435c84, Lavalink ($SECRET_SITE005) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Lavalink is back up in eb57dfe after 22 minutes.

repo: nboxdev/upptime


text:
Installation Problem

Hi...
Problem with dependencies:
El paquete wine32 no está disponible, pero algún otro paquete hace referencia
a él. Esto puede significar que el paquete falta, está obsoleto o sólo se
encuentra disponible desde alguna otra fuente

Hi,
Could you make sure you have done a git pull?
Thanks

authors: Charliedean lordoracle

repo: nccgroup/Winpayloads


text:
Only Full Screen?

How can i add Player view? and player control (half screen like youtube app)
how can i play video in half screen?
how can i add full screen video button? onclick full screen?
So finally it only work full screen?

@naguchennai use inline html5 video and native javascript controls (e.g. play(), etc.)
issue can be closed

if there's a clear reason for needing this in this plugin i'll reopen but this is easily resolved by using html5 inline video. this is a fullscreen video plugin.

authors: naguchennai shamilovtim


text:
Relative Economic value

We should migrate relative economic value across from Jive https://doi.org/10.1002/qj.49712656313
Consider using the binary contingency table class in this implementation.

Should anyone feel like working on this:
Just a heads up, over time scores has refined what we include in docstrings.
Here are some links to some recently written docstrings, which can serve as guides/templates:
KGE: https://scores.readthedocs.io/en/stable/api.html#scores.continuous.kge
Interval Score: https://scores.readthedocs.io/en/stable/api.html#scores.continuous.interval_score
Also, while you can wait until you have finished your work before opening a pull request, it is also completely fine to open a draft pull request part way through and request feedback part way through.

authors: Steph-Chong nicholasloveday

repo: nci/scores


text:
Python 101

Not smart, we at the back need some hecking help when it comes to figuring this stuff out!
There are some EPIC API foo that want to do, but, like, i dont even know how to do simple string manipulation, much less JSON magic!?
Lets sit down with a expert and get some help!
┆Card is synchronized with this Github issue by Unito

Vihren Petrov commented in Trello:

@ingeman is a Python-fu sensei :sunglasses:

repo: ncsokas/github-actions-training


text:
rc JSON parsing errors when path contains single quote

What is the problem you are having with rclone?
When passing commands to rclone as remote control (rc) and one of the parameters is a path that contains a single quote (e.g. as an apostrophe) there doesn't seem to be a way to escape it when sending the path as JSON. See below for examples
What is your rclone version (output from rclone version)
rclone v1.46

os/arch: linux/amd64
go version: go1.11.5

Which OS you are using and how many bits (eg Windows 7, 64 bit)
Linux 64bit, MacOS 64bit
Which cloud storage system are you using? (eg Google Drive)
not applicable
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone rc operations/list --json '{"fs":"/", "remote":"big-storage/Ben's Test"}'
or
rclone rc operations/list --json '{"fs":"/", "remote":"big-storage/Ben\'s Test"}'
or any other similar command (e.g. sync/sync) which may have a path in it with single quotes. Clearly this is due to the fact BASH is already using single quotes to take in the JSON string so single quotes can't be used inside the string.
Note that using params works:
rclone rc operations/list fs="/" remote="big-storage/Ben's Test"
Produces the expected output:
{         "list": [                 {                         "IsDir": false,                         "MimeType": "application/octet-stream",                         "ModTime": "2019-02-19T18:47:39.738305018-06:00",                         "Name": "testfile",                         "Path": "big-storage/Ben's Test/testfile",                         "Size": 0                 }         ] }
Also, using double quotes to encase the JSON string and then escaping the double quotes inside the string also works:
rclone rc operations/list --json "{\"fs\":\"/\", \"remote\":\"big-storage/Ben's Test\"}"
So maybe the solution is simply to update the documentation for rc to show how to escape JSON for the types of characters that may be encountered in paths. This would likely require further testing of characters that could exist in paths to verify they can all be escaped properly.
A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)
not applicable

This is a bash problem really, rather than an rclone problem...
The --json flag is there for testing - it isn't wildly convenient typing JSON in on the command line!
An alternative might be --jsonfile to read from a file or from stdin.

So maybe the solution is simply to update the documentation for rc to show how to escape JSON for the types of characters that may be encountered in paths. This would likely require further testing of characters that could exist in paths to verify they can all be escaped properly.

Perhaps recommending the single quotes, but stating: if you want to add a single quote ' into the --json parameter while using bash, then use '"'"' instead (that closes the string, adds a single quote in double quotes, then opens the string again).

This looks to be answered so closing out.

authors: animosity22 bfranske ncw

repo: ncw/rclone


text:
Read Google Drive directories concurrently

This PR will read Google drive directories concurrently.
Maximum connection handling is moved to the "pacer", and removed from ACD.
It seems like root drive listing is handled elsewhere, but that performs really well, so I have not done anything to change that.

This fixes #143 if used with "-v".  We could still add a more generic progress display for file listing.

Putting the concurrency control inside the pacer is a great idea.
I did a bit of testing with drive and it speeds my directory listings up by a factor of 3.5!
There is a way of listing everything on drive so we use that for the root directory listing.
Here is a comparison of the root directory listing
$ rclone ls drive: > 0

Transferred:            0 Bytes (   0.00 kByte/s)
Errors:                 0
Checks:                 0
Transferred:            0
Elapsed time:       19.1s

$ rclone --drive-full-list=false ls drive: > 1

Transferred:            0 Bytes (   0.00 kByte/s)
Errors:                 0
Checks:                 0
Transferred:            0
Elapsed time:        7.5s

$ diff <(sort <0) <(sort <1)

Whether it is faster or slower will depend on your drive contents I think...
I've merged that - thanks!

Thinking about this futher, it is short selling the concurrency in the sync phase slightly which is supposed to be config.Transfers and cofig.Checkers....  So the default could be config.Transfers+config.Checkers which over sells the concurrency in the listing phase, but I'd be happy with that.

authors: klauspost ncw


text:
webdav.md: about Macaroons

Added a paragraph about Macaroons; added link to script that obtains a Macaroon, as suggested at https://github.com/ncw/rclone/issues/2360#issuecomment-402519344

That is great - thank you very much :-)

Thank you!

authors: ncw onnozweers


text:
NULL pointer cause crash in iniparser_getboolean.

when input a wired ini file ,there is a crash found.
int main (int argc, char** argv)
{
dictionary * ini ;
char       * ini_name ;
char* filename = argv[1];
char* fuzzstr = {0xff,0x00};
ini = iniparser_load(filename);
if (ini!=NULL) {
int b = iniparser_getboolean(ini, fuzzstr, -1);
char* s = iniparser_getstring(ini, fuzzstr, NULL);
int i = iniparser_getint(ini, fuzzstr, -1);
double d = iniparser_getdouble(ini, fuzzstr, -1.0);
iniparser_dump(ini, stdout);
iniparser_freedict(ini);
}
}
input in .ini file:
"\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x42\x9e\x20\x4a\x09\x96\xe4\x6d\xf8\xb5\x6f\x35\x9b\xca\xc5\xd2\xa0\x39\x11\x21\x52\xd8\xcf\x6c\x52\x61\x7c\x3d\xd0\xad\xf7\x13\x4b\x17\x5d\x54\xad\x42\xc1\xa5\xf7\x30\xda\x92\xfa\xa0\x64\x9a\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\xa3\xf5\xf5\xa4\xa2\xf5\xf5\xa4\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x59\x1e\x33\x07\x0c\xc7\x54\x3f\x7e\xbc\x81\xf4\x61\xa0\xad\x71\x91\x89\x74\x48\x7a\xd9\xab\x79\xc2\xbf\x54\x61\x8a\x89\x3c\xe3\xa8\x6f\xea\xb4\x37\x3e\xf3\xb5\xfa\x74\xa9\x5b\x14\x56\xcd\xa5\xdf\x41\xee\x5a\x1a\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x1f\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d\x0a\x0a\x5b\x5d"
compile:
gcc -fsantize=address test.c ./src/iniparser.c ./src/dictionary.c -o testdemo -I ./src/
run and find a crash:
==2145962==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x556d37d6dce3 bp 0x7ffedb8fc080 sp 0x7ffedb8fc040 T0)
==2145962==The signal is caused by a READ memory access.
==2145962==Hint: address points to the zero page.
#0 0x556d37d6dce3 in iniparser_getboolean ../src/iniparser.c:559
#1 0x556d37d69f57 in main /opt1/software/newtest/iniparser/test.c:19
the vuln is in function "iniparser_getboolean" miss check for function "iniparser_getstring" 's return. when iniparser_getstring return NULL, the code in 559 will cause crash .

also same problem in iniparser_getlongint and iniparser_getdouble which also use iniparser_getstring.

repo: ndevilla/iniparser


text:
Builder Interface for TaskRegister.java

Is your feature request related to a problem? Please describe.
It is cumbersome to continually offer() multiple tasks to the TaskRegister. Instead, it would be cleaner to have a Builder to automatically declare Tasks upon initialization.
Describe the solution you'd like
Builder interface for TaskRegister.java

will have to update unit tests

repo: nealkumar/JBrew


text:
Push Notifications Backend Wrap-up:  Give users the ability to block/unblock receiving push notifications from a specific dApp

Adding a new endpoint to notification server that uses subscription URL for auth, and accepts a acountId/dappId to support blocking/unblocking push notifications for that pair
We will implement this blocking per accountId, e.g. globally across all gateways

hey @ravigautham we've scoped the remaining notifications work down this issue and https://github.com/near/near-discovery/issues/775

Sounds good @charleslavon! Is this going to be paired with UI work to surface these settings? Or will that be done at a later time? And are we still planning to have our contract team tackle the design enhancements captured in the Fast Follow epic?

@ravigautham Instead of the dApp toggles, we'll need a new UI for notifications that is similar to this action menu that appears on posts.

authors: charleslavon ravigautham

repo: near/near-discovery

license: Unlicense


text:
Create a Contribution Path Section on the New Homepage

Problem
Developers currently lack a clear and structured path to engage and contribute to Devhub, making it challenging for newcomers to participate effectively.
User Stories

As a developer, I want to see clear ways of contributing to the ecosystem and respective details of each option.
As a developer, I want to know what all different areas I can contribute to at NEAR and at Devhub.

Acceptance Criteria

[ ] The Devhub page should display a structured contribution pathway that offers clarity on different ways a developer can engage with the ecosystem.
[ ] Each contribution method should be accompanied by a brief description or set of instructions, ensuring that developers understand the requirements and steps involved.
[ ] Navigation to the contribution pathway should be intuitive, ensuring new visitors can easily locate this section.

Assets
Figma - Link
Copy - As outlined in Figma

Can you assign this to me?

Requested merge: https://github.com/near/neardevhub-widgets/pull/325

repo: near/neardevhub-widgets


text:
Container does not start with no stats

Hello, I've deployed docker-logentries but it won't start. It crashes with following error:
$ docker run logentries/docker-logentries -t private-token-hidden --no-stats
/usr/src/app/index.js:64
  if (!stats && !logs) {
                 ^
ReferenceError: logs is not defined
    at start (/usr/src/app/index.js:64:18)
    at cli (/usr/src/app/index.js:142:3)
    at Object.<anonymous> (/usr/src/app/index.js:148:3)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
    at startup (node.js:129:16)
    at node.js:814:3

Looks like this line is the problem, and indeed, variable logs is not defined anywhere.

Fixed and released, just wait for the automated docker build to complete.

authors: mcollina oinopion

repo: nearform/docker-logentries


text:
Update devnet docz

Fixes  https://github.com/nearprotocol/nearcore/issues/581

Seems this broke docs.

repo: nearprotocol/docs


text:
go build的时候报错哦

frontend.go:22:2: cannot find package "github.com/nebula-chat/chatengine/access/frontend/server" in any of:
/usr/lib/golang/src/github.com/nebula-chat/chatengine/access/frontend/server (from $GOROOT)
/root/go/src/github.com/nebula-chat/chatengine/access/frontend/server (from $GOPATH)
frontend.go:23:2: cannot find package "github.com/nebula-chat/chatengine/pkg/util" in any of:
/usr/lib/golang/src/github.com/nebula-chat/chatengine/pkg/util (from $GOROOT)
/root/go/src/github.com/nebula-chat/chatengine/pkg/util (from $GOPATH)

懂了   是go里面把路径写死了    所以说找不到

检查golang环境设置

博主您好！请问这个$GOPATH指的是什么路径呢？
mkdir $GOPATH/src/github.com/nebula-chat/
cd $GOPATH/src/github.com/nebula-chat/
git clone https://github.com/nebula-chat/chatengine.git
如果是go的路径，我的路径是
[root@MiWiFi-R3P-srv frontend]# which go
/usr/bin/go
这样的，后面的go不是目录。
但是go文件里引用了目录
import (
"flag"
"github.com/nebula-chat/chatengine/access/frontend/server"
"github.com/nebula-chat/chatengine/pkg/util"
)
github.com/nebula-chat/chatengine/access/frontend/server像这个目录是指的是什么目录呢？

repo: nebula-chat/chatengine