Convert Variable Subsystems in Effectors to Configurable Subsystems

We moved to model references on purpose to avoid configurable subsystems at all cost. Could you explain why you are undoing this?

Chris asked me to change this because configurable subsystems seemed easier to use.  Could you explain why configurable subsystems need to be avoided?

Chris asked me to change this because configurable subsystems seemed easier to use.  Could you explain why configurable subsystems need to be avoided?

Sure thing! Configurable subsystems are terrible when you're trying to really work with a model, as illustrated by the following example. They should be avoided as much as possible.
 Place a scope on one of the aileron signals in the model reference of the effectors block. Run the SIL sim. You will see that although the model reference block of the effectors is a pop-out model, you can still check the scope and see what happened in the SIL. This is nice. You have the ability to interact with the model, edit it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL, which is in the controller block. This is the path to the configurable subsystem: SimSIL/Flight Computer/Interrupt Service Routine/Simulink (Controller Type). Try doing anything in here, like adding a scope. You will see that you cannot, because Simulink won't allow you to edit configurable subsystems. This is why configurable subsystems are terrible and why I said they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying to work with or develop on a model. Hence, this is the reason I eliminated all configurable subsystems from the NL and SIL sims, and went instead for model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable subsystem for the controller is because you cannot have an s-function within a model reference block;  that simply doesn't make sense. Thus, we have a configurable subsystem that either picks an s-function or a model reference for a Simulink controller (where the Simulink controller is its own thing and is therefore not limited by the configurable subsystem). Thus, you COULD add a scope to the Simulink controller, even though it is implemented into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation architecture I put in place.

That all makes sense. I like the compactness of the configurable
subsystems, it makes it easier to navigate the model. But changing the
drawings is a real pain. I thought there was a way to allow configurable
subsystems from a library to modify their own content. I feel like there
are no good options for run-time reconfiguration.
The issue we ran into with the variant models is that its pretty convoluted
to set it up to allow multiple instances of a single model using a
different set of parameters. For example, say I need and aircraft with two
IMUs. The parameterization for the IMUs are contained in the structures:
AC.Sensors.IMU1 and AC.Sensors.IMU2. Both instances of the reference model
can only have one set of parameters, its a single model so it can't have
both parameterizations set at the same time. AC.Sensors.IMU1.gyroBias_mps2
and AC.Sensors.IMU2.gyroBias_mps2 can't both be defined for the same model.
So, a means of passing the structure to the parameters to the reference
model is required. Mask workspaces apparently work differently with variant
models than they do with normal subsystems; we couldn't get each instance
of the reference model to work with a simple mask. Maybe there is a way, we
couldn't figure it out. What we ended up doing was pass AC.Sensors.IMU as
an argument to the reference model; the problem is that to do so you need
to provide a prototype of the argument structure for the reference model.
If you pass a structure (its actually setup with a Simulink.Parameter
structure) that has different fields it will error out. If the structure
prototype needs to change there is small series of commands that will
"re-seed" the argument, then the model needs to be re-saved. I thought
about placing those calls in the init callback, but didn't like the idea of
hiding these calls where nobody will see them. I'm hopeful that there will
be a way to make it work.
One other thing about passing arguments; the structure needs to be
homogenous (all doubles for example).
I think this is the reference we were using trying to get this to work:
https://www.mathworks.com/help/simulink/ug/parameterize-referenced-models_f4-141787.html

Chris

On Wed, Jun 14, 2017 at 11:26 PM, Andrei Dorobantu<EMAIL_ADDRESS>
wrote:

Sure thing! Configurable subsystems are terrible when you're trying to
really work with a model, as illustrated by the following example. They
should be avoided as much as possible.
 Place a scope on one of the aileron
signals in the model reference of the effectors block. Run the SIL sim. You
will see that although the model reference block of the effectors is a
pop-out model, you can still check the scope and see what happened in the
SIL. This is nice. You have the ability to interact with the model, edit
it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL, which is in
the controller block. This is the path to the configurable subsystem:
SimSIL/Flight Computer/Interrupt Service Routine/Simulink (Controller
Type). Try doing anything in here, like adding a scope. You will see that
you cannot, because Simulink won't allow you to edit configurable
subsystems. This is why configurable subsystems are terrible and why I said
they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying to
work with or develop on a model. Hence, this is the reason I eliminated all
configurable subsystems from the NL and SIL sims, and went instead for
model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable subsystem for
the controller is because you cannot have an s-function within a model
reference block; that simply doesn't make sense. Thus, we have a
configurable subsystem that either picks an s-function or a model reference
for a Simulink controller (where the Simulink controller is its own thing
and is therefore not limited by the configurable subsystem). Thus, you
COULD add a scope to the Simulink controller, even though it is implemented
into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation
architecture I put in place.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308625207, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALPnbui9c2nNQep1u31WHeMAAdG2h3vNks5sELJ_gaJpZM4N6htc
.

--

Chris Regan

I'm afraid I don't understand.
Why can't you do this:
Have 2 models, each associated with a variant:

Model A has 1 IMU
Model B has 2 IMUs

The IMU block itself is a library item with a mask where you specify the
path to parameters in a structure, so you can differentiate between IMU 1
and IMU 2 implemented in the same model.
The AC structure either has 1 or 2 IMUs defined. When you set up the sim
and choose the aircraft, you configure the variant accordingly.
Why doesn't this work?
On Thu, Jun 15, 2017 at 9:00 AM Chris Regan<EMAIL_ADDRESS>wrote:

That all makes sense. I like the compactness of the configurable
subsystems, it makes it easier to navigate the model. But changing the
drawings is a real pain. I thought there was a way to allow configurable
subsystems from a library to modify their own content. I feel like there
are no good options for run-time reconfiguration.
The issue we ran into with the variant models is that its pretty convoluted
to set it up to allow multiple instances of a single model using a
different set of parameters. For example, say I need and aircraft with two
IMUs. The parameterization for the IMUs are contained in the structures:
AC.Sensors.IMU1 and AC.Sensors.IMU2. Both instances of the reference model
can only have one set of parameters, its a single model so it can't have
both parameterizations set at the same time. AC.Sensors.IMU1.gyroBias_mps2
and AC.Sensors.IMU2.gyroBias_mps2 can't both be defined for the same model.
So, a means of passing the structure to the parameters to the reference
model is required. Mask workspaces apparently work differently with variant
models than they do with normal subsystems; we couldn't get each instance
of the reference model to work with a simple mask. Maybe there is a way, we
couldn't figure it out. What we ended up doing was pass AC.Sensors.IMU as
an argument to the reference model; the problem is that to do so you need
to provide a prototype of the argument structure for the reference model.
If you pass a structure (its actually setup with a Simulink.Parameter
structure) that has different fields it will error out. If the structure
prototype needs to change there is small series of commands that will
"re-seed" the argument, then the model needs to be re-saved. I thought
about placing those calls in the init callback, but didn't like the idea of
hiding these calls where nobody will see them. I'm hopeful that there will
be a way to make it work.
One other thing about passing arguments; the structure needs to be
homogenous (all doubles for example).
I think this is the reference we were using trying to get this to work:
https://www.mathworks.com/help/simulink/ug/parameterize-referenced-models_f4-141787.html

Chris

On Wed, Jun 14, 2017 at 11:26 PM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

Sure thing! Configurable subsystems are terrible when you're trying to
really work with a model, as illustrated by the following example. They
should be avoided as much as possible.
 Place a scope on one of the aileron
signals in the model reference of the effectors block. Run the SIL sim.
You
will see that although the model reference block of the effectors is a
pop-out model, you can still check the scope and see what happened in the
SIL. This is nice. You have the ability to interact with the model, edit
it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL, which is
in
the controller block. This is the path to the configurable subsystem:
SimSIL/Flight Computer/Interrupt Service Routine/Simulink (Controller
Type). Try doing anything in here, like adding a scope. You will see that
you cannot, because Simulink won't allow you to edit configurable
subsystems. This is why configurable subsystems are terrible and why I
said
they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying to
work with or develop on a model. Hence, this is the reason I eliminated
all
configurable subsystems from the NL and SIL sims, and went instead for
model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable subsystem for
the controller is because you cannot have an s-function within a model
reference block; that simply doesn't make sense. Thus, we have a
configurable subsystem that either picks an s-function or a model
reference
for a Simulink controller (where the Simulink controller is its own thing
and is therefore not limited by the configurable subsystem). Thus, you
COULD add a scope to the Simulink controller, even though it is
implemented
into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation
architecture I put in place.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308625207,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/ALPnbui9c2nNQep1u31WHeMAAdG2h3vNks5sELJ_gaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308751635, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APvtCGgQoEqJsaaWN9YaCwR7mfHoJtZFks5sEUB4gaJpZM4N6htc
.

The IMU block has variants. There are several ways to model an IMU at
differing levels of fidelity. At the lowest level we just pass through the
states. At the highest level we perform the transformations of the
measurands (orientation and location), model the transducer (typically a
transfer function and time delay), and superimpose an error model (scale,
bias, noise).
On Thu, Jun 15, 2017 at 11:13 AM, Andrei Dorobantu<EMAIL_ADDRESS>
wrote:

I'm afraid I don't understand.
Why can't you do this:
Have 2 models, each associated with a variant:

Model A has 1 IMU
Model B has 2 IMUs

The IMU block itself is a library item with a mask where you specify the
path to parameters in a structure, so you can differentiate between IMU 1
and IMU 2 implemented in the same model.
The AC structure either has 1 or 2 IMUs defined. When you set up the sim
and choose the aircraft, you configure the variant accordingly.
Why doesn't this work?
On Thu, Jun 15, 2017 at 9:00 AM Chris Regan<EMAIL_ADDRESS>wrote:

That all makes sense. I like the compactness of the configurable
subsystems, it makes it easier to navigate the model. But changing the
drawings is a real pain. I thought there was a way to allow configurable
subsystems from a library to modify their own content. I feel like there
are no good options for run-time reconfiguration.
The issue we ran into with the variant models is that its pretty
convoluted
to set it up to allow multiple instances of a single model using a
different set of parameters. For example, say I need and aircraft with
two
IMUs. The parameterization for the IMUs are contained in the structures:
AC.Sensors.IMU1 and AC.Sensors.IMU2. Both instances of the reference
model
can only have one set of parameters, its a single model so it can't have
both parameterizations set at the same time.
AC.Sensors.IMU1.gyroBias_mps2
and AC.Sensors.IMU2.gyroBias_mps2 can't both be defined for the same
model.
So, a means of passing the structure to the parameters to the reference
model is required. Mask workspaces apparently work differently with
variant
models than they do with normal subsystems; we couldn't get each instance
of the reference model to work with a simple mask. Maybe there is a way,
we
couldn't figure it out. What we ended up doing was pass AC.Sensors.IMU as
an argument to the reference model; the problem is that to do so you need
to provide a prototype of the argument structure for the reference model.
If you pass a structure (its actually setup with a Simulink.Parameter
structure) that has different fields it will error out. If the structure
prototype needs to change there is small series of commands that will
"re-seed" the argument, then the model needs to be re-saved. I thought
about placing those calls in the init callback, but didn't like the idea
of
hiding these calls where nobody will see them. I'm hopeful that there
will
be a way to make it work.
One other thing about passing arguments; the structure needs to be
homogenous (all doubles for example).
I think this is the reference we were using trying to get this to work:
https://www.mathworks.com/help/simulink/ug/parameterize-
referenced-models_f4-141787.html

Chris

On Wed, Jun 14, 2017 at 11:26 PM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

Sure thing! Configurable subsystems are terrible when you're trying to
really work with a model, as illustrated by the following example. They
should be avoided as much as possible.
 Place a scope on one of the
aileron
signals in the model reference of the effectors block. Run the SIL sim.
You
will see that although the model reference block of the effectors is a
pop-out model, you can still check the scope and see what happened in
the
SIL. This is nice. You have the ability to interact with the model,
edit
it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL, which is
in
the controller block. This is the path to the configurable subsystem:
SimSIL/Flight Computer/Interrupt Service Routine/Simulink (Controller
Type). Try doing anything in here, like adding a scope. You will see
that
you cannot, because Simulink won't allow you to edit configurable
subsystems. This is why configurable subsystems are terrible and why I
said
they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying to
work with or develop on a model. Hence, this is the reason I eliminated
all
configurable subsystems from the NL and SIL sims, and went instead for
model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable subsystem
for
the controller is because you cannot have an s-function within a model
reference block; that simply doesn't make sense. Thus, we have a
configurable subsystem that either picks an s-function or a model
reference
for a Simulink controller (where the Simulink controller is its own
thing
and is therefore not limited by the configurable subsystem). Thus, you
COULD add a scope to the Simulink controller, even though it is
implemented
into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation
architecture I put in place.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308625207,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
ALPnbui9c2nNQep1u31WHeMAAdG2h3vNks5sELJ_gaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308751635,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
APvtCGgQoEqJsaaWN9YaCwR7mfHoJtZFks5sEUB4gaJpZM4N6htc>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308790433, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALPnbqR7OdPMMpltatMSNs2vzxaHso1Eks5sEVgPgaJpZM4N6htc
.

--

Chris Regan

I see.
What if the IMU block itself were a configurable subsystem, and you left
the overall sensor model block as a model reference? This way you could
easily swap in and out, let's call it, a sensor architecture... and then in
the nitty gritty details do you capture the IMU model specifically?
I guess what I'd like to see is a model reference at the top level so you
can easily play with and edit the model. If we lock things down one level
down at the IMU model, that would not have as far-reaching effects as
making the whole sensor model a configurable subsystem.
On Mon, Jun 19, 2017 at 7:22 AM Chris Regan<EMAIL_ADDRESS>wrote:

The IMU block has variants. There are several ways to model an IMU at
differing levels of fidelity. At the lowest level we just pass through the
states. At the highest level we perform the transformations of the
measurands (orientation and location), model the transducer (typically a
transfer function and time delay), and superimpose an error model (scale,
bias, noise).
On Thu, Jun 15, 2017 at 11:13 AM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

I'm afraid I don't understand.
Why can't you do this:
Have 2 models, each associated with a variant:

Model A has 1 IMU
Model B has 2 IMUs

The IMU block itself is a library item with a mask where you specify the
path to parameters in a structure, so you can differentiate between IMU 1
and IMU 2 implemented in the same model.
The AC structure either has 1 or 2 IMUs defined. When you set up the sim
and choose the aircraft, you configure the variant accordingly.
Why doesn't this work?
On Thu, Jun 15, 2017 at 9:00 AM Chris Regan<EMAIL_ADDRESS>wrote:

That all makes sense. I like the compactness of the configurable
subsystems, it makes it easier to navigate the model. But changing the
drawings is a real pain. I thought there was a way to allow
configurable
subsystems from a library to modify their own content. I feel like
there
are no good options for run-time reconfiguration.
The issue we ran into with the variant models is that its pretty
convoluted
to set it up to allow multiple instances of a single model using a
different set of parameters. For example, say I need and aircraft with
two
IMUs. The parameterization for the IMUs are contained in the
structures:
AC.Sensors.IMU1 and AC.Sensors.IMU2. Both instances of the reference
model
can only have one set of parameters, its a single model so it can't
have
both parameterizations set at the same time.
AC.Sensors.IMU1.gyroBias_mps2
and AC.Sensors.IMU2.gyroBias_mps2 can't both be defined for the same
model.
So, a means of passing the structure to the parameters to the reference
model is required. Mask workspaces apparently work differently with
variant
models than they do with normal subsystems; we couldn't get each
instance
of the reference model to work with a simple mask. Maybe there is a
way,
we
couldn't figure it out. What we ended up doing was pass AC.Sensors.IMU
as
an argument to the reference model; the problem is that to do so you
need
to provide a prototype of the argument structure for the reference
model.
If you pass a structure (its actually setup with a Simulink.Parameter
structure) that has different fields it will error out. If the
structure
prototype needs to change there is small series of commands that will
"re-seed" the argument, then the model needs to be re-saved. I thought
about placing those calls in the init callback, but didn't like the
idea
of
hiding these calls where nobody will see them. I'm hopeful that there
will
be a way to make it work.
One other thing about passing arguments; the structure needs to be
homogenous (all doubles for example).
I think this is the reference we were using trying to get this to work:
https://www.mathworks.com/help/simulink/ug/parameterize-
referenced-models_f4-141787.html

Chris

On Wed, Jun 14, 2017 at 11:26 PM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

Sure thing! Configurable subsystems are terrible when you're trying
to
really work with a model, as illustrated by the following example.
They
should be avoided as much as possible.
 Place a scope on one of the
aileron
signals in the model reference of the effectors block. Run the SIL
sim.
You
will see that although the model reference block of the effectors is
a
pop-out model, you can still check the scope and see what happened in
the
SIL. This is nice. You have the ability to interact with the model,
edit
it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL, which
is
in
the controller block. This is the path to the configurable subsystem:
SimSIL/Flight Computer/Interrupt Service Routine/Simulink (Controller
Type). Try doing anything in here, like adding a scope. You will see
that
you cannot, because Simulink won't allow you to edit configurable
subsystems. This is why configurable subsystems are terrible and why
I
said
they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying
to
work with or develop on a model. Hence, this is the reason I
eliminated
all
configurable subsystems from the NL and SIL sims, and went instead
for
model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable subsystem
for
the controller is because you cannot have an s-function within a
model
reference block; that simply doesn't make sense. Thus, we have a
configurable subsystem that either picks an s-function or a model
reference
for a Simulink controller (where the Simulink controller is its own
thing
and is therefore not limited by the configurable subsystem). Thus,
you
COULD add a scope to the Simulink controller, even though it is
implemented
into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation
architecture I put in place.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308625207
,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
ALPnbui9c2nNQep1u31WHeMAAdG2h3vNks5sELJ_gaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308751635,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
APvtCGgQoEqJsaaWN9YaCwR7mfHoJtZFks5sEUB4gaJpZM4N6htc>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308790433,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/ALPnbqR7OdPMMpltatMSNs2vzxaHso1Eks5sEVgPgaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-309455078, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APvtCJqqRVfJc70Kwqx3tukpUXIz_6NPks5sFoQ8gaJpZM4N6htc
.

That's actually what it's looking like now. I also thought about putting
switches at the lower levels (to say bypass the time delay) so that a
single IMU model could be used. That might be the backup plan.

Chris

On Mon, Jun 19, 2017 at 9:28 AM, Andrei Dorobantu<EMAIL_ADDRESS>wrote:

I see.
What if the IMU block itself were a configurable subsystem, and you left
the overall sensor model block as a model reference? This way you could
easily swap in and out, let's call it, a sensor architecture... and then in
the nitty gritty details do you capture the IMU model specifically?
I guess what I'd like to see is a model reference at the top level so you
can easily play with and edit the model. If we lock things down one level
down at the IMU model, that would not have as far-reaching effects as
making the whole sensor model a configurable subsystem.
On Mon, Jun 19, 2017 at 7:22 AM Chris Regan<EMAIL_ADDRESS>wrote:

The IMU block has variants. There are several ways to model an IMU at
differing levels of fidelity. At the lowest level we just pass through
the
states. At the highest level we perform the transformations of the
measurands (orientation and location), model the transducer (typically a
transfer function and time delay), and superimpose an error model (scale,
bias, noise).
On Thu, Jun 15, 2017 at 11:13 AM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

I'm afraid I don't understand.
Why can't you do this:
Have 2 models, each associated with a variant:

Model A has 1 IMU
Model B has 2 IMUs

The IMU block itself is a library item with a mask where you specify
the
path to parameters in a structure, so you can differentiate between
IMU 1
and IMU 2 implemented in the same model.
The AC structure either has 1 or 2 IMUs defined. When you set up the
sim
and choose the aircraft, you configure the variant accordingly.
Why doesn't this work?
On Thu, Jun 15, 2017 at 9:00 AM Chris Regan<EMAIL_ADDRESS>wrote:

That all makes sense. I like the compactness of the configurable
subsystems, it makes it easier to navigate the model. But changing
the
drawings is a real pain. I thought there was a way to allow
configurable
subsystems from a library to modify their own content. I feel like
there
are no good options for run-time reconfiguration.
The issue we ran into with the variant models is that its pretty
convoluted
to set it up to allow multiple instances of a single model using a
different set of parameters. For example, say I need and aircraft
with
two
IMUs. The parameterization for the IMUs are contained in the
structures:
AC.Sensors.IMU1 and AC.Sensors.IMU2. Both instances of the reference
model
can only have one set of parameters, its a single model so it can't
have
both parameterizations set at the same time.
AC.Sensors.IMU1.gyroBias_mps2
and AC.Sensors.IMU2.gyroBias_mps2 can't both be defined for the same
model.
So, a means of passing the structure to the parameters to the
reference
model is required. Mask workspaces apparently work differently with
variant
models than they do with normal subsystems; we couldn't get each
instance
of the reference model to work with a simple mask. Maybe there is a
way,
we
couldn't figure it out. What we ended up doing was pass
AC.Sensors.IMU
as
an argument to the reference model; the problem is that to do so you
need
to provide a prototype of the argument structure for the reference
model.
If you pass a structure (its actually setup with a Simulink.Parameter
structure) that has different fields it will error out. If the
structure
prototype needs to change there is small series of commands that will
"re-seed" the argument, then the model needs to be re-saved. I
thought
about placing those calls in the init callback, but didn't like the
idea
of
hiding these calls where nobody will see them. I'm hopeful that there
will
be a way to make it work.
One other thing about passing arguments; the structure needs to be
homogenous (all doubles for example).
I think this is the reference we were using trying to get this to
work:
https://www.mathworks.com/help/simulink/ug/parameterize-
referenced-models_f4-141787.html

Chris

On Wed, Jun 14, 2017 at 11:26 PM, Andrei Dorobantu <
<EMAIL_ADDRESS>
wrote:

Sure thing! Configurable subsystems are terrible when you're trying
to
really work with a model, as illustrated by the following example.
They
should be avoided as much as possible.
 Place a scope on one of the
aileron
signals in the model reference of the effectors block. Run the SIL
sim.
You
will see that although the model reference block of the effectors
is
a
pop-out model, you can still check the scope and see what happened
in
the
SIL. This is nice. You have the ability to interact with the model,
edit
it, see what happened, etc.
By contrast, go to the only configurable subsystem in the SIL,
which
is
in
the controller block. This is the path to the configurable
subsystem:
SimSIL/Flight Computer/Interrupt Service Routine/Simulink
(Controller
Type). Try doing anything in here, like adding a scope. You will
see
that
you cannot, because Simulink won't allow you to edit configurable
subsystems. This is why configurable subsystems are terrible and
why
I
said
they should be avoided.
Configurable subsystem behavior is MADDENING for researchers trying
to
work with or develop on a model. Hence, this is the reason I
eliminated
all
configurable subsystems from the NL and SIL sims, and went instead
for
model reference. I would be strongly opposed to going back to them.
For context, the reason why we have to have a configurable
subsystem
for
the controller is because you cannot have an s-function within a
model
reference block; that simply doesn't make sense. Thus, we have a
configurable subsystem that either picks an s-function or a model
reference
for a Simulink controller (where the Simulink controller is its own
thing
and is therefore not limited by the configurable subsystem). Thus,
you
COULD add a scope to the Simulink controller, even though it is
implemented
into the SIL via a configurable subsystem.
I hope this is sufficient clarification to justify the simulation
architecture I put in place.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/UASLab/OpenFlight/pull/17#
issuecomment-308625207
,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
ALPnbui9c2nNQep1u31WHeMAAdG2h3vNks5sELJ_gaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308751635
,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
APvtCGgQoEqJsaaWN9YaCwR7mfHoJtZFks5sEUB4gaJpZM4N6htc>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-308790433,
or mute
the thread
<
https://github.com/notifications/unsubscribe-auth/
ALPnbqR7OdPMMpltatMSNs2vzxaHso1Eks5sEVgPgaJpZM4N6htc
.

--

Chris Regan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-309455078,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
APvtCJqqRVfJc70Kwqx3tukpUXIz_6NPks5sFoQ8gaJpZM4N6htc>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UASLab/OpenFlight/pull/17#issuecomment-309456773, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALPnbrK-MUvte0BPhUeJptlOHMwfpJFqks5sFoWOgaJpZM4N6htc
.

--

Chris Regan


Drag and drop node inside other that ist collapsed

Now, its not possible to drag a node and drop it into another that is collapsed
To be more graphic I will put an ascii example
Lets say we have this structure
|-- Node 1
|    |--- Node 1.1
|    |--- Node 1.2
|
|-- Node 2
|-- Node 3
|    |--- Node 3.1
|    |--- Node 3.2
|    |--- Node 3.3
|
|-- Node 4

Let's say I want to drag "Node 2" and drop inside of "Node 3". Well, if "Node 3" is collapsed I can do it before open it. Is this behavior ok or I am missing some configuration?
If this behavior is like that, how can I force this? One think I thought is to on the hover on a node when we are dragging it, expand the node father of the ones inside that we are hover.
Am I being clear?
Appreciate any response..
Regards,
Luciano

+100

I assume this won't be in the near future so, is there any way to apply the expand() function on the events like dragMove?

I soved using this trick:
In the accept function, you should use the expand() function.
Something like this;
accept: function (sourceNodeScope, destNodesScope, destIndex) {
    destNodesScope.expand();
}

@marsanla.... I've try your idea.
Anyway, got an error...
app.js:790 Uncaught TypeError: destNodesScope.expand is not a function

Looks like destNodesScope is not the scope of the node or something like that and I can't call the function expand
This is what my destNodesScope has....
$$ChildScope: ChildScope()
$$childHead: ChildScope
$$childTail: ChildScope
$$listenerCount: Object
$$listeners: Object
$$nextSibling: null
$$prevSibling: null
$$watchers: Array[4]
$$watchersCount: 0
$element: JQLite[1]
$id: 8
$modelValue: Array[4]
$nodeScope: null
$nodesMap: Object
$parent: ChildScope
$treeScope: ChildScope
$type: "uiTreeNodes"
accept: (sourceNode, destIndex)
beforeDrag: (sourceNode)
childNodes: ()
cloneEnabled: false
depth: ()
destroySubNode: (subNode)
hasChild: ()
initSubNode: (subNode)
insertNode: (index, nodeData)
isParent: (node)
maxDepth: 0
nodropEnabled: false
outOfDepth: (sourceNode)
removeNode: (node)
safeApply: (fn)

Do you have any idea of what could I be doing wrong or if this is a BUG?
Regards,
Luciano

Hi,
This is not really a bug. Atually there is a pulrequest for something like this : #539
As @marsanla say, you can use accept or dragMove. But you need to be sure that  destNodesScope.$nodeScope exist (indeed  destNodesScope has no expand function).
But be careful, callbacks functions does not support promises (#507) !

Closing this issue due to inactivity. See #815 for more information.
Please create a new issue is this still occurs with the current version of the component.


⚠ Fetchers has degraded performance

In 03cd2e1, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 269 ms

Resolved: Fetchers performance has improved in 15df1c2.


One extra word that throws off the flow of reading

The readme in the dev branch is not the same so I apologize for making you aware against master. Unusual wording, 'anything' corrected from 'a anything'.
Correction, it is present in the dev branch. Retargetting dev with this.

Better idea, I'v told you. It would be much better for someone here to ninja it in with the next edit to the readme instead of making such a small contribution.

Hey. Thanks for the PR. I've credited you with the change in my PR towards the dev branch here: https://github.com/includeos/IncludeOS/pull/2152
We are close to a merge of dev->master and a release.


Show help on missing args for kurma create

Minor bug fix for kurma create
@krobertson @jpoler

LGTM on green.

There's nothing built into cobra for arg validation?

I don't know cobra all that well... but the create function had multiple modes of operation. Would like to simplify it some. Need to revive the "kurma cli design document", perhaps for tomorrow's meeting.

LGTM2.

re: cobra args len handling seems to be still delegated to the user, e.g. by using a switch for example: https://github.com/spf13/cobra/blob/9a8186dbb51a58b06720d2189657fa8adc12f1a1/cobra/cmd/init.go#L48


Environment created only in collection scope - any way to define Global Environments

Hi,
Environment created only in collection scope - any way to define Global Environments.
anyway to create Global env or at least have option to duplicate Environments between collections?
Is there also way to define Global variables ?

I agree this is needed.  I'm trying to help my team migrate from Postman to Bruno and this functionality would be helpful to avoid needing to duplicate values across collections.  Similarly this should be considered for .env files as well.

Would it be possible to combine your collections into folders inside a single collection instead? I think global variables goes against the current manifesto.

Would it be possible to combine your collections into folders inside a single collection instead? I think global variables goes against the current manifesto.

will give it a try - can be good solution for this requirement

See also #115. I'd really appreciate having a global environments option as well.

Issue closed as duplicate. This feature has already been tracked here: https://github.com/usebruno/bruno/issues/115


Jump to bottom button

There should be a "Go to the bottom" button (e.g. in the down right corner).
🍻

Hi, this issue is still open and i would like to work on this issue.
Is there anything i have to pay attention for, before i start to work on this issue?
How is the best way to start with this issue?


Add getter for webhook url in SlackWebhookHandler class

Add getter so that the subclass can easy to inherit SlackWebhookHandler class

Thanks

Thanks


Prevent the spawning of Graves on the first few days to allow players to prepare for Zombies

Suggestion's in the title. It's a little annoying to immediately start a world with Graves spawning when you don't even have wooden tools created yet, let alone a home, considering Zombies seem to have defense and cannot be simply whacked away with your fists (hitting with Fists shows no health loss particles). Preferrably, it should be:

3-4 days on Easy
2-3 days on Normal
1-2 days on Hard
No grace period on Hardcore

If not making it mandatory, at least make it an option in the config for those who wish to enable it. Optionally make a sound play when Grave spawning is enabled after the grace period ends. Also optionally, you can limit what plant types spawn during the grace period (or just planting them in general, which would remove Sun generation without Solar Winds or random Peashooters), to prevent farming powerful plants easily due to the threat of Zombies missing for the first few days.

Also as a side suggestion, please give the option to change grave spawn rates, I can't kill these zombies faster than the graves spawn...

The current grace period is 5 minutes, but I could add options to extend it
And if you go to the configs in the latest update, you will see that you can change their spawn rates, you just have to lower the value in the grave's weight so that they spawn less often

And if you go to the configs in the latest update, you will see that you can change their spawn rates, you just have to lower the value in the grave's weight so that they spawn less often

Alright, thank you for pointing that out. How often do they spawn in the default "10" weight?

I just checked the configs for Grave spawning and it seems that configs in the modmenu don't accept decimals. Not really sure if it's just a Mod Menu thing or if it's exclusive to this mod but I thought I'd go ahead and say that here.


fix loader

You can create a pull request for this. Fixing the size of the loader.

Can you assign this to me as hactoberfest tag


Ticket type not found

when clicking the donate button, the following error appears:

This is only happening to this event: https://events.handsupfoundation.org/pvt/cinema-for-syria/cinema-for-syria-at-earls-court-film-festival-2020/
Please urgent if you can fix this.

This is only happening to this event: https://events.handsupfoundation.org/pvt/cinema-for-syria/cinema-for-syria-at-earls-court-film-festival-2020/

I've investigated and found that this is caused by the event having an external ticket url.
When I remove the external ticket url, the donation button works properly.
It seems like the system expects the external url be used to donate if there is one - I don't know why this needs to be the case though.

I removed the external link; you are completely right no need for it to be there. Thank you


Update quickstart-python.md

Fixes the typo in the bash command to set FLASK_APP env var

@DexterPOSH : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Change button style after minmal time

From outline to normal to indicate success.

rejected. This is adding to much attention to the timing


Update the title to 'Voice' for the consistency

Updating the title for the consistency.
Interaction design - Gaze
Interaction design - Gesture
Interaction design - Voice

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/voice-design.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@cre8ivepark This is another one that is intentional. There are "core" articles and "design" articles for each input. The "core" article titles right now are "Gaze," "Gestures," and "Voice input" while the "design" articles are "Gaze targeting," "Gestures" (uses the same core article for some reason), and "Voice design." Changing the name of the voice design article to Voice wouldn't be the right solution for consistency here, it would be renaming the "core" version to just "Voice" but also would need to understand why the design articles have inconsistent naming/sometimes share the core article, but other times don't. Wanna set up some time to chat through these and rationalize the titles with Randy?


Generate libcrypto.a using OpenSSL 1.0.2g, using Tag OpenSSL_1_0_2g

In response to facebook/conceal#129
Builds libcrypto.a using OpenSSL 1.0.2g. Added some bootstrap for easier upgrades in the future.
All standard conceal tests passed and has been tested on a working Android app by copying over the generated libconceal.jar, conceal_android.jar and all libconceal.so for all archs
To check that the generated apk has been built using latest OpenSSL run
unzip -p myapp.apk | strings | grep "OpenSSL"
You should see OpenSSL 1.0.2g  1 Mar 2016
I am interested in knowing how the maven artifact com.facebook.conceal:conceal:1.0.1@aar is generated as I would prefer to use that instead of copying over generated objects over to Android projects.

@flopex the make script is great!
I can merge the request right away if you do two small changes to it:

add a no-asm option in the Configure call for the 64 bits cases
remove the compiled libraries from the commit

About how to get the compiled conceal library offered in maven: we use the gradle scripts (setting the repository access variables in gradle.properties). You can run gradle assemble to generate the .aar file locally.

Failed because travis build couldn't find any of the libcrypto.a files, @helios175 your call on whether you would like to add those yourself of add a build process to travis to make those.

I will upload the libraries now.
We preferred not to merge compiled libraries.
But the commit was great I must say!


[Flaky Test] Topology tagger took longer than 0

https://circleci.com/gh/weaveworks/scope/3879

https://circleci.com/gh/weaveworks/scope/3907

https://circleci.com/gh/weaveworks/scope/3976


feat: manual resolver and example

Description

Option to create a manual resolver
Added validations and flags
Example
Tests

Release required?

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

@vburckhardt FYI
when I try to spin up "delegated" service - it says only system and manual are allowed. See the message below:
│         "errors": [
│             {
│                 "code": "validation_failed_oneof",
│                 "message": "Expected only one oneOf fields to be set: got 0",
│                 "target": {
│                     "name": "VpcdnsResolverPrototype",
│                     "type": "field"
│                 }
│             },
│             {
│                 "code": "validation_failed_enum",
│                 "message": "VpcdnsResolverTypeManualPrototype is invalid: Validation Failure: Expected [\"manual\"]",
│                 "target": {
│                     "name": "VpcdnsResolverTypeManualPrototype.VpcdnsResolverTypeManualPrototypeType",
│                     "type": "field",
│                     "value": "\"delegated\""
│                 }
│             },
│             {
│                 "code": "validation_failed_enum",
│                 "message": "VpcdnsResolverTypeSystemPrototype is invalid: Validation Failure: Expected [\"system\"]",
│                 "target": {
│                     "name": "VpcdnsResolverTypeSystemPrototype.VpcdnsResolverTypeSystemPrototypeType",
│                     "type": "field",
│                     "value": "\"delegated\""
│                 }
│             }
│         ],
│         "trace": "ee4a6b58-4f91-4274-a3cf-1c23baa37a11"
│     }
│ }
│
│
│   with module.spoke_vpc.ibm_is_vpc.vpc,
│   on ../../main.tf line 29, in resource "ibm_is_vpc" "vpc":
│   29: resource "ibm_is_vpc" "vpc" {
│
╵

It also says that "dns" is invitation-only service. Not sure if that might be the reason behind not supporting "delegated" service (docs: https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_vpc#dns)

/run pipeline

/run pipeline

Ran both pr_tests and other_tests locally and they passed successfully.

/run pipeline

/run pipeline

:tada: This PR is included in version 7.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


quilt: Simplify QUILT_PATH

Introduces quilt get, which allows the user to download specs from other repositories, e.g. quilt get github.com/secant/specs
Changes quilt spec to quilt run spec
Makes QUILT_PATH only one directory, that lays its own structure out like GOPATH
Modifies all current specs' import statements

I skimmed this over.  At a high level, it looks really good.  much much cleaner than I expected.
Couple of comments:
In the second patch, their shouldn't be a period in the first line of the commit message.
Also, it looks to me a bit like the second patch implements some functionality, but breaks some things in the code base, that you fix up in the subsequent patches.  Is that the case?  If so, those later patches should be folded into the first one.  No patch in the history should break anything (knowingly), even if later, it's fixed up in the same commit.
Anyways, this wasn't a formal review, just skimmed it.  Someone else (will do it).

Also, what's the "in progress" bit?  Just the unit tests?

Oh, the documentation too I suppose

Btw, this doesn't matter at all, but it's common if you're posting a patch that you don't think should be merged yet, to prepend the title with [RFC] as in "Request For Comment".   I added the WIP because I got way too excited to make a PR, and forgot I had to write tests 😝

Coverage increased (+0.1%) to 35.408% when pulling d231983ab91e67d8cb81b35bcf7529600ca8f086 on secant:change-quilt-path into 5bf463e654af1265713a1dc3ff9854520d93c77a on NetSys:master.

Your coverage could be even better I think:
https://coveralls.io/builds/6791437/source?filename=util%2Fget.go#L29

Coverage increased (+0.2%) to 35.579% when pulling a955c36bae275e278dc447628869b6d833d999c2 on secant:change-quilt-path into 2c1c1d640786105ec3b375c38c73c475e4311e43 on NetSys:master.

This case is probably worth testing: https://coveralls.io/builds/6823738/source?filename=util%2Fget.go#L29

That case is covered locally :(
image

Sigh, coveralls is crappier than I'd hoped . . .

Ready for more review!

Changes have been made!

Also, note, looks like the build failed.  Line too long.

Changes made, should be ready now. @ejj

Coverage increased (+0.3%) to 35.463% when pulling b8dd46d53db2c676a7055471c9877c90aa1bebed on secant:change-quilt-path into fc56afefa397149692582e1d9d88ab230d2fee50 on NetSys:master.

Merged


Jupyterlab >= 3.5.2 is incompatible with CentOS 7

Install aborts on CentOS 7 since we forced the version of jupyterlab to be >= 3.5.2 to fix #25

Seems related to the fact that CentOS 7 uses python2 by default and pip2 by default. Pbroblem is not seen on Ubuntu where python3 is used.


Unable to resolve "./TabViewAnimated" from "node_modules/react-native-tab-view/src/index.js"

Current behaviour
After upgrading from react-nativation 2 to 3 and following migration instructions, when I start the app (build with Expo sdk31), I have this error :
Unable to resolve "./TabViewAnimated" from "node_modules/react-native-tab-view/src/index.js"

Expected behaviour
Detailled error in simulator :
Unable to resolve module `./TabViewAnimated` from `/Users/laurent/Work/****/node_modules/react-native-tab-view/src/index.js`: The module `./TabViewAnimated` could not be found from `/Users/laurent/Work/****/node_modules/react-native-tab-view/src/index.js`. Indeed, none of these files exist:
  * `/Users/laurent/Work/****/node_modules/react-native-tab-view/src/TabViewAnimated(.native||.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)`
  * `/Users/laurent/Work/****/node_modules/react-native-tab-view/src/TabViewAnimated/index(.native||.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)`

ABI31_0_0RCTFatal
__37-[ABI31_0_0RCTCxxBridge handleError:]_block_invoke
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_main_queue_callback_4CF
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
__CFRunLoopRun
CFRunLoopRunSpecific
GSEventRunModal
UIApplicationMain
main
start

Code sample
I didn't change anything to my code except changes needed by 3.0.9 upgrade
I'm using createMaterialTopTabNavigator
export default createMaterialTopTabNavigator(
  {
    aStack,
    bStack,
    cStack
  },
  {
    initialRouteName: "a",
    activeTintColor: "#03dac4"
  }
);

What have you tried
I've seen that TabViewAnimated is not available as such and just seems to be defined in flow typed ...
https://github.com/react-navigation/react-navigation-tabs/blob/7a21afd3b6e18a4bbdae176f1e5760dc137284c1/flow-typed/npm/react-native-tab-view_vx.x.x.js
Your Environment

software
version

expo
sdk31

react-native
sdk31 : 0.57.1

react-navigation-tabs
1.0.2

node
v8.9.4

yarn
1.13.0

Expo CLI 2.6.14 environment info:
    System:
      OS: macOS High Sierra 10.13.6
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 8.9.4 - /usr/local/bin/node
      Yarn: 1.13.0 - ~/.yarn/bin/yarn
      npm: 6.4.1 - /usr/local/bin/npm
      Watchman: 4.7.0 - /usr/local/bin/watchman
    IDEs:
      Android Studio: 3.1 AI-173.4907809
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      expo: 31.0.2 => 31.0.2
      react: 16.3.1 => 16.3.1
      react-native: https://github.com/expo/react-native/archive/sdk-31.0.0.tar.gz => 0.57.1
      react-navigation: 3.0.9 => 3.0.9
    npmGlobalPackages:
      expo-cli: 2.6.14

Something is wrong with your local node_modules, try the following:

If you're using npm, switch to yarn
Delete node_modules and run yarn
Reset metro cache: for vanilla react-native, run yarn start --reset-cache, for expo, press Shift+R in the terminal when expo start is running
Delete watchman watches: watchman watch-del-all

Closing this issue since it's not an issue in the library.


Mac OS 11.4 (Big Sur) support

Rasterview currently does not show anything when opening a PWG file on Big Sur. Is this a known issue?

Yes, it is a problem with the GUI toolkit I'm using that was recently fixed. Hope to put out a new binary release with a fix for this soon.


Pass arguments in CLI

Hi,
Is there a way to pass variable values in the CLI ? For example, I have a simple C# script that's saved as myscript.csx
var path = "C:\\Folder";

var properties = ExportProperties(Model.AllColumns);

SaveFile(path+"\\columnproperties.tsv", properties);

I can run the command in CLI:
start /wait TabularEditor.exe Model.bim -S myscript.csx
Can I pass the value to the path variable instead of hardcoding it in the script. One way would be to launch a dialog box but I was wondering if there is a way to pass it as an argument in the CLI command. Sorry I barely know C#.
Thanks!

One way to do this, is by using environment variables. I.e. set a variable in the command line, before executing the Tabular Editor CLI:
set te_path=c:\Folder

Then, in your C# script, read the value of that environment variable:
var path = Environment.GetEnvironmentVariable("te_path");

Perfect, thanks


[FEA] Update Python bindings for ingress/egress creation to take a pybind11 object typeid

Is your feature request related to a problem? Please describe.
This is an optimization; we want to be able to create ingress/egress nodes from Python that can be directly connected to their c++ equivalent data type without first converting to a PyHolder / py::object.
Describe the solution you'd like
Update ingress/egress bindings to take either a list (current implementation) with names that result in XXPort<PyHolder>, or a list of tuples of (name, typeid) format, so we can dynamically connected edges at run time without the c++->python->c++ overhead

Closed in PR #153


Added support for Symfony 3.* components

There seem to be a few problems with Travis/Style CI. Can you check?

This is because of Symfony\Component\Console\Command\Command::setCode(), which changed from
public function setCode($code)

to (
public function setCode(callable $code)

in this commit: https://github.com/symfony/symfony/commit/4e0c6e1b554ac74fee526868b86d028a7c38c10e
This is an example where the SF3 support and PHP 5.3 support don't go together (the callable type hint was introduced in PHP 5.4)

Ok. Let's define the class conditionally then:
// CommandAdapter.php

abstract class AbstractCommandAdapter extends Command
{
    // current code except setCode()
}

if (method_exists('Symfony\Component\Console\Command', 'asText')) {

    // Symfony 3.0 compatible definition
    class CommandAdapter extends AbstractCommandAdapter
    {
        public function setCode(callable $code) { ... }
    }

} else {

    // Symfony 2.0 compatible definition
    class CommandAdapter extends AbstractCommandAdapter
    {
        public function setCode($code) { ... }
    }

}

Done, all tests pass. Only Scrutinizer has something going on that seems having to do with their infrastructure. Does not seem like a problem here.

Perfect, thanks! :)


nixos/wireguard: Remove .path systemd unit for privkey

TODO

[ ] Based on PR #121331, merge that first.

Thus only the top commit needs to be reviewed.

Motivation for this change
Fixes #123203.
As per man systemd.path:

When a service unit triggered by a path unit terminates
(regardless whether it exited successfully or failed),
monitored paths are checked immediately again,
and the service accordingly restarted instantly.

Thus the existence of the path unit made it impossible to stop the
wireguard service using e.g.
systemctl stop wireguard-wg0.service

Systemd path units are not intended for program inputs such
as private key files.
This commit simply removes this usage; the private key is still
generated by the generateKeyServiceUnit.
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Also fixes #123293

cc wireguard users @nrdxp @manveru

oh, this should be backported


Move data to a new Jabbr-Core.Data project

fixes #57

@ashanhol re chat the other day this should be a class library, seems this is a full web app. I'd create a new class library merge only the class files in/fix paths, we can talk more about that tomorrow.

:shipit:


updated POST routes for New Game

POST routes for user_responses and scores tables to create blank rows (with default points and scores as 0) when new game is created

@sjsamphex @devstah @Rdgh1583 - simple updates to routes per our convo. Please review + let me know if OK to merge. Thanks!


[Question] Enantiomeric/Stereoisomeric compounds

Are the encoding protocols sensitive to enantiomeric and stereoisomeric compounds?
It matters because two isomers have different binding affinities. If they are going to have exactly the same encoding, it may cause problem in training.

Hi, it depends on the encoding schemes. For SMILES strings encoding, it should be sensitive as long as the SMILES string is sensitive and the training/testing set both have the same encoding scheme. But for molecular graph (MPNN), it is not. It is actually one of an active research directions to put chirality into the graph neural network: https://arxiv.org/abs/2012.00094


GraphBrowser "Expand" function doesn't load all possible edges

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 2.8
[ ] 3.0
[x] 3.1
[ ] 3.2 pre-releases: ___
[ ] self-compiled devel branch

On this operating system:

[ ] DCOS on

[ ] AWS
[ ] Azure
[ ] own infrastructure

[ ] Linux

[ ] Debian .deb
[x] Ubuntu .deb
[ ] SUSE   .rpm
[ ] RedHat .rpm
[ ] Fedora .rpm
[ ] Gentoo
[ ] docker - official docker library
[ ] other:

[x] Windows, version: 7
[ ] MacOS, version:

this is a web interface-related issue:
I'm using the web interface with this browser:     Firefox / Chrome (latest) running on this OS: Win7
These are the steps to reproduce:

Load a known graph
Browse around and select a vertex
Use the "expand" function from the menu

The following problem occurs:

The GraphBrowser loads only some of the related edges.
Edges to already loaded vertices are not loaded / ignored.
-> This is irritating as it doesn't represent the correct data.

You can proof that the missing edges / connections are definetly made if you
set the suspected vertex as new "start node".

Thanks for the report. It is fixed in devel and 3.1.

3.1.19 is available for download - closing. Feel free to comment if the issue persists.


Javascript intellisence lost

I installed this extension for vs 2015 today, and now there is no intellisense for javascript. Even the colorful highlighting of javascript keywords like 'function' is now lost and every is black

looks like #4238.
This is probably caused by "Tools and Windows SDK 10.0.10240"; follow the instructions in https://github.com/Microsoft/TypeScript/issues/4238#issuecomment-129060370 to restore JS support.


Standardize Side Effects

Currently the call element has limited support for side effects -- it would be good to put this support into all elements that have expressions

Realized that eval should return an object with the result values, and the current (possibly affected) values of the variables.
Shouldn't be too hard to implement, and then will provide support for side effects across the board, regardless of where the variable is inside the expression.

Updated eval, instead of returning an object with result values the code inside eval checks if the current state is not running, and then reaches into the stack and updates the values with newer ones


please use tensorflow

could you realize it with tensorlfow?

Thanks for your interest, the codebase is implemented in TensorFlow.

Thank you for your reply! That's great and wonderful.


Rustdoc-JSON: Replace - with _ for binary package target

Hi! First of all, thanks for this very useful crate :)
Whenever I want to build JSON documentation for a binary with - in it, I get a PathBuf that does not point to the generated file.
This PR is fixing that and adding a new test that ensures correctness.
I am opening this as a draft because perhaps a similar solution should also be applied to other package target kinds.

Just curious: What is your use case? In what scenario do you want to list the public API for a bin?

I am only using the rustdoc-JSON and writing a library that would provide a compile-time reflection based on the JSON output.

@frondeus There is no urgency of course; just wanted to check if you intend to bring this PR to the finish line?

Yes I do, as soon as I return from my holiday leave :)

I'd like to make a release this weekend, so I've helped you take this to the finish line. I hope you didn't mind!

Absolutely! Thanks for your work :)

Fixed in https://crates.io/crates/rustdoc-json/0.8.6


[21129] Migrate fastrtps namespace

Description

This PR migrate fastrtps namespace to fastdds. It also rename one of the member of DiscoveryProtocol from NONE to MANUAL.

Contributor Checklist

[x] Commit messages follow the project guidelines.
[x] Code snippets related to the added documentation have been provided.
[x] Documentation tests pass locally.
[x] Applicable backports have been included in the description.

Reviewer Checklist

[x] The PR has a milestone assigned.
[x] The title and description correctly express the PR's purpose.
[x] Check contributor checklist is correct.
[ ] CI passes without warnings or errors.

@richiprosima please test_3 docs


Floating / always visible buttons

As some forms can be really long when filling them on mobile / tablet and users might need to save the form continuously, it would be very nice to have floating / always visible buttons (those that are standardly displayed only in the bottom of the page: Cancel / Update & Continue editing, Update). Would it be possible to add something like that?

Would it be possible to add something like that?

PR's are welcome.


package.json should contain keywords to improve npm search

The file package.json doesn't contain keywords.
As a result when searching for similar packages on npm by keywords like multipart upload, this package doesn't appear.
Example of keywords (taken from issue 36):  [ 'multipart', 'form', 'upload', 'file' ]

Ah yeah... Always forgetting about that.


Migration Document

v0.7 -> v0.8
It would be appreciated if the migration documentation was more explicit about what is supposed to happen.
kind: Certificate
   acme:
     config:
     - http01:
         ingress: www-ingress
       domains:
      - example.com

How does that meant to be moved to the ingress?  Drop it in as is?  It appears to be different so a concrete example would be appreciated.

Hey there,
I'm not too sure what your question here is. Do you mean this migration document? https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html
This walks through a concrete example of someone switching over to the new format from previously having two different solving configurations, HTTP01 and DNS01.
Could you rephrase your question/clarify so we can help? 😄

You can also see examples here: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/index.html

Well it would be nice to have something that specifically says Certificate.acme.config.domains now goes here and Certificate.acme.config.http01.ingress goes here and has these additional options.  Or something along these lines.
Also, I am confused by
https://docs.cert-manager.io/en/latest/tasks/issuers/setup-acme/http01/index.html
which seems to state that ingressName and ingressClass are fields, but the example migration shows
ingress:
  class:

I guess I just don't understand that ingressClass is actually written as two lines here or am I misreading something?
Another tangential thing that bothers me is that, as far as I am aware, there is no way to test that the certificate update will work on a production system other than to wait for the scheduled update to succeed or fail.  If I knew I could play around with the configs and easily test that they work or do not work, I would be less dependent on the migration doc clarity.

We are in the process of overhauling our documentation. I am going to close this issue but will keep a reference in the main documentation issue that we are using to consolidate these so it wont get lost.
/close


Llama2-7b Jailbreak Robustness models on Hugging Face

Would it be possible to make the Llama2-7b-chat models available from the Jailbreak Robustness experiment? We're especially interested in RT-EAT-LAT. Thanks a lot!

We are also very interested in these models. It would be appreciated if you could release the weights on huggingface (Currently only llama3 jailbreak models are on them). Thanks!


Convert map to old map

Old map is here: http://<IP_ADDRESS>/map
Make current map like this (toggle between individual and group)

@sebgrebe do we still need this?

@michaltrzesimiech no


⚠ Samsung has degraded performance

In 2a18400, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2543 ms

Resolved: Samsung performance has improved in fbc3f2d.


Provide a windows binary release

We should provide a windows standalone binary (like we do for POSIX)

An issue with that might be that staticx only supports Linux for now.

@bartoszbanachewicz-dynatrace we don't have to provide an actually static binary for Windows -> we can rely on certain libraries just being there ;) I've read somewhere about decent results running pyinstaller under wine

Preferred solution would be to rewrite the project in Rust, if the project itself makes sense going forward


python3Packages.pytraccar: init at 0.10.0

Motivation for this change
Python library to handle device information from Traccar
https://github.com/ludeeus/pytraccar
This is a Home Assistant dependency.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145467 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.pytraccar
python39Packages.pytraccar


astroid 3 breaks builds:  AttributeError: 'Module' object has no attribute 'doc'

I am not sure if this an astroid or autodoc2 issue, but the astroid 3 release broke builds.
Example error:

Running Sphinx v7.2.6
making output directory... done
[Autodoc2] Analysing package...[  5%] itkwasm.pixel_types
Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/sphinx/events.py", line 97, in emit
    results.append(listener.handler(self.app, *args))
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/autodoc2/sphinx/extension.py", line 76, in run_autodoc
    mod_path = run_autodoc_package(app, config, i)
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/autodoc2/sphinx/extension.py", line 164, in run_autodoc_package
    for data in analyse_module(mod_path, mod_name):
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/autodoc2/analysis.py", line 41, in analyse_module
    yield from walk_node(
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/autodoc2/analysis.py", line 105, in walk_node
    yield from func(node, state)
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/autodoc2/analysis.py", line 116, in yield_module
    "doc": fix_docstring_indent(node.doc),
AttributeError: 'Module' object has no attribute 'doc'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/sphinx/cmd/build.py", line 293, in build_main
    app = Sphinx(args.sourcedir, args.confdir, args.outputdir,
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/sphinx/application.py", line 272, in __init__
    self._init_builder()
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/sphinx/application.py", line 343, in _init_builder
    self.events.emit('builder-inited')
  File "/home/docs/checkouts/readthedocs.org/user_builds/itkwasm/envs/latest/lib/python3.10/site-packages/sphinx/events.py", line 108, in emit
    raise ExtensionError(__("Handler %r for event %r threw an exception") %
sphinx.errors.ExtensionError: Handler <function run_autodoc at 0x7f69dd1211b0> for event 'builder-inited' threw an exception (exception: 'Module' object has no attribute 'doc')

Not sure what astroid is, I got the same error for my test class!
─╯
Running Sphinx v7.2.6
loading pickled environment... done
[Autodoc2] Analysing package...[ 33%] testbench.init
Extension error (autodoc2.sphinx.extension):
Handler <function run_autodoc at 0x7fea39dde200> for event 'builder-inited' threw an exception (exception: 'Module' object has no attribute 'doc')
make: *** [Makefile:20: html] Error 2


missing links from help page

https://docs.adobe.com/content/help/en/target/using/reports/conversion-rate.html#concept_0D0002A1EBDF420E9C50E2A46F36629B
missing links are:
To calculate these calculated metrics, download the Target's Complete Confidence Calculator Excel file to input the activity's value, or review the statistical calculations used by Target.
please see bold references above i.e. Target's Complete Confidence Calculator & statistical calculations used by Target.
These linked before to : https://marketing.adobe.com/resources/help/en_US/target/target/complete_confidence_calculator.xlsx  but this link is now broken.

Updated links to new domain. Thanks for the catch.


Shapes not resizing properly

When resizing the horizontal editor I find that the first shape properly resizes but the second one lacks proper resizing.

We definitely fixed this at some point, Scene Editor's not being consistent is now our problem


Enable mnist sharding with layout overrides

Mnist sharding works with a few caveats:

All op layouts are overriden.
Only works if all dims are pre tiled. Waiting for support for memref TileType to be propagated properly from TTIR to the backed. Related: #822
Workaround for ttnn failing to chose 1d matmul program config. https://github.com/tenstorrent/tt-metal/issues/13204

Generated ToLayout ops now have a suffix for location names in order to keep the names unique and be able to override op inputs as needed.

@AleksKnezevic Can i get a review from runtime codeowners please?

@tapspatel Can you take a look at the PR please? Your approval is needed before merge.

runtime changes look good!


Issue 137 and 154

Supposedly fixed #137 (per service lock and lock-free service map modification) and #154


fix Issue 16383 - 'Algebraic visit does not match const'

Change looks like a step in the right direction. The new condition, is(Params[0] == T), is obviously ok. It's not so clear for the existing one, is(Unqual!(Params[0]) == T).
There are some related cases that should probably be made to work:
{
    /* since the same works with Algebraic!Object */
    alias T = Algebraic!(immutable Object);
    T.init.visit!(
        (const Object x) => 0,
        () => 0,
    );
}
{
    /* similarly */
    alias T = Algebraic!(Object, immutable Object);
    T.init.visit!(
        (const Object x) => 0,
        () => 0,
    );
}
{
    /* This one should obviously work, but fails because of Unqual. */
    alias T = Algebraic!(Object, immutable Object);
    T.init.visit!(
        (Object x) => 0,
        (immutable Object x) => 0,
        () => 0,
    );
}
{
    /* Not sure about this one. */
    alias T = Algebraic!(Object, const Object);
    T.init.visit!(
        (Object x) => 0,
        (const Object x) => 0,
        () => 0,
    );
}

If you'd like to tackle these too, @Cauterite, that would be great. But they fail already, they wouldn't be introduced by this PR. So we can just file them and leave them for later.
Please add a unittest for the fixed issue.

Could you please add a unittest that your code makes work?

Current coverage is 88.75% (diff: 100%)

Merging #4727 into master will increase coverage by <.01%

@@             master      #4727   diff @@
==========================================
  Files           121        121
  Lines         74070      74070
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          65737      65738     +1
+ Misses         8333       8332     -1
  Partials          0          0

Powered by Codecov. Last update 41df329...90e7fd0

I'll consider revisiting this to deal with those other cases, but for now I don't consider it a priority.

This should be all green by the way; the build failures don't appear to have anything to do with this patch.

@Cauterite the auto tester looks like it had some recent issues with space. But that seems to have cleared up, and the test in question has been deprecated anyhow.
@aG0aep6G yeah, I think the way this should work is that if any items are callable with the stored type, then it should work. If two or more items match, and one is a better match (defined by D overload rules), then the better match should work.
Probably needs a good design examination, I don't think it's a quick fix.
LGTM. I assume that the other comments are approvals sans unit test that is now added?

Auto-merge toggled on


run_untagged option shouldn't be deprecated

Describe the bug
run_untagged option shouldn't be deprecated , regarding  the documentation it was depreciated  with runner_gitlab_registration_config
Expected behavior
It would be good to have  a way to set this with terraform.

This option won't be deprecated. Instead you have to register the Runner manually on the GitLab UI and use that token for the module. The GitLab guys removed the API to register a new Runner. So we can't use this feature any longer (GitLab 17+).
Pass the token of the manually created Runner to var.runner_gitlab.preregistered_runner_token_ssm_parameter_name.


Enhancement - Position of notification

Hello,
First of all: thank you for developing this nifty tool, I really like it :)
Just one thing: I can't seem to change the position where the notification appears. When working in Chrome on a Mac, the pop-up appears in the upper right corner, exactly on the spot where I click to open a new tab (yes, I always have tons of tabs open in Chrome).
It would be a great addition if we could choose where the notification appears (right top, right bottom, left top, left bottom, top center...)

This is a macOS problem not a Spotify Notifications problem


home-assistant-cli: 0.9.5 -> 0.9.6

Description of changes
https://github.com/home-assistant-ecosystem/home-assistant-cli/releases/tag/0.9.6

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 197627 run on x86_64-linux 1

1 package built:

home-assistant-cli


Port forwarding adds wrong subnet mask for virtual IPv6 addresses

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[ x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Virtual IPv6 addresses are set up as /32 rule and not as single host respectively /128
To Reproduce
Steps to reproduce the behavior:

Setup a IPv6 CARP address (/64)
At "Firewall: NAT: Port Forward" create a new entry
Select the created CARP address in the Virtual IPs section as the destination.
TCP/IP Version: IPv6
fill in the remaining data
click save
Check the destination address in the overview (should wrongly be /32)

Expected behavior
it should be /128 respectively a single host
Additional context
CLI check:
grep 2001:xxxx:xxxx:xxxx::100 /tmp/rules.debug
rdr on ix1_vlan1010 inet6 proto tcp from {any} to {2a02:xxxx:xxxx:xxxx::190/32} port {443} -> 2001:xxxx:xxxx:xxxx::100 port 8443 # To Webserver 01

Environment
OPNsense 23.1.9-amd64 (Openssl)
Intel® Xeon™ CPU (bare metal)

b779ab46d1cb might do the trick... this was pretty wild

@fichtner on my end it still stores the /32, I was thinking to keep the original construct, but hide and disable the mask field. The mask isn't really needed, but since we offer it for the "special nets" we are posting it for processing too. Yesterday I couldn't find the time to check which part should be changed here, but you're certainly right, these legacy pages are the worst.

if it was stored it won't be cleared. Initial assignment is ok as far as I can tell. It's not possible to decide afterwards if this was manual input or not... and VIPs seem to be stored without /xx attached which is consistent with the patch.

either way is fine really, not attached to a particular fix

@fichtner I was thinking about https://github.com/opnsense/core/commit/0c76a9134d5aa9226aeeebd05ad5d81ba40716fc. (in which case we can revert the other commit). The page still has warnings and deprecation notices, but I didn't want to fix those now to avoid cluttering the view. (I can take a look later at that)

No need to revert. It was a separate branch.

modifying pconfig_to_address() likely requires fixing all caller page's JS

"fixing" may be a harsh word but here it just means "to make things consistent" across all callers

@fichtner this https://github.com/opnsense/core/commit/fc93cdb0b060b8434defb0b6f2bd47a5df11eeb4 should be the last bit then to make things consistent (firewall_nat_npt_edit.php doesn't use the select/related fields)

Thanks! Will test and close next week :)

Ok, misread, will test anyway 😊

Looks ok to me, into 23.1.10 it goes. 👍


leap: update benchmark for fair weighting of years

For https://github.com/exercism/xgo/issues/197

Seems reasonable. Merging it.


cds core form alignment broken in clr-modal popup

Describe the bug
Using cds form elements inside a  clr-modal seems to break the alignment for a vertical form layout. Letters are cropped.

How to reproduce
https://stackblitz.com/edit/clarity-light-theme-v5-nzwlxs?file=src/app/app.component.html
Steps to reproduce the behavior:

Click on 'show modal'

Expected behavior
Letters and error label (including upper case ÅÄÖ) should not be cropped.
Versions
Clarity project:

[x] Clarity Core
[x] Clarity Angular/UI

Clarity version:

[ ] v3.x
[ ] v4.x
[x] v5.x

Framework:

[x] Angular
[ ] React
[ ] Vue
[ ] Other:

Framework version:
Angular 11
Device:

Type: [PC]
OS: [Windows 10]
Browser [Chrome]
Version [90]

@wokis
I can't get your stackblitz to run. Any chance you could get it fixed so I can see the issue?


Upgrade layout-bin-packer

In the process of trying to remove the ember-cli-babel@5 deprecations, I ran into layout-bin-packer surfacing it. 1.4.0 was just published that removes the deprecation warning, so this bumps to that version to resolve the problem for people with the latest version of ember-collection.

Relates to #169 (but does not completely solve it)

CI seems unhappy with this:
not ok 151 Firefox 59.0 - scrollTop: scroll but within content length
    ---
        actual: >
            60
        expected: >
            50
        stack: >
            @http://localhost:7357/assets/tests.js:2915:5
            runTest@http://localhost:7357/assets/test-support.js:4164:16
            run@http://localhost:7357/assets/test-support.js:4150:6
            runTest/<@http://localhost:7357/assets/test-support.js:4362:7
            advanceTaskQueue@http://localhost:7357/assets/test-support.js:3763:6
            advance@http://localhost:7357/assets/test-support.js:3744:4
            begin@http://localhost:7357/assets/test-support.js:5760:4
            internalStart/config.timeout<@http://localhost:7357/assets/test-support.js:4749:6

        message: >
            Scrolled one row.
        Log: |

Once green, I can release.

Gotcha, I just upgraded it and push 🤷♂ I'll see if I can solve the failure and update the PR tomorrow.

Weird, the tests don't fail in Chrome, Safari or Firefox locally....

Interesting, the CI failures in #170 are from the same test.

Can we re-run the CI suite against master and make sure that this failure isn't happening there, too? The tests were last run against master 3 months ago.

@mattmcmanus and I tracked down the failing test and PR'd a fix here: https://github.com/emberjs/ember-collection/pull/174

Verified that this passes when rebased on master with #174 merged. Merging.... thanks @alexlafroscia! 🎉

Released as 1.0.0-alpha.9


Proxy Service Crashes

Greetings,
We're using this service running in a docker container (running scrapinghub/crawlera-headless-proxy:latest). It works properly for some period of time and then will fail with:
time="2019-02-01T07:58:55Z" level=debug msg="Layer trace" execute-duration=35.96716655s on-request-durations="[60.778µs 5.812005ms 6.894µs 20.544µs 25.788µs]" on-request-error="<nil>" on-response-durations="[45.852µs 345ns 0s 396ns 2.394µs]" request-id=987636319649793
panic: Length of args %!= 2

goroutine 261844 [running]:
github.com/scrapinghub/crawlera-headless-proxy/proxy.(*Logger).getFields(0xded598, 0xc008849c80, 0x3, 0x3, 0xc004653e88)
	/app/proxy/logger.go:38 +0x18d
github.com/scrapinghub/crawlera-headless-proxy/proxy.(*Logger).Warn(0xded598, 0x9ab433, 0x2a, 0xc008849c80, 0x3, 0x3)
	/app/proxy/logger.go:22 +0x6c
github.com/9seconds/httransform.(*Server).makeHijackHandler.func1(0xa2d6a0, 0xc00254c180)
	/go/pkg/mod/github.com/9seconds/httransform@v0.0.0-20190111135017-ebcb54ac3762/server.go:104 +0x510
github.com/valyala/fasthttp.hijackConnHandler(0xa24a40, 0xc0035ac540, 0xa2d880, 0xc0025240c0, 0xc000240680, 0xc00302a780)
	/go/pkg/mod/github.com/valyala/fasthttp@v1.1.0/server.go:2086 +0x7b
created by github.com/valyala/fasthttp.(*Server).serveConn
	/go/pkg/mod/github.com/valyala/fasthttp@v1.1.0/server.go:2005 +0xb95

When this happens, the service hangs at this message and will not handle any new requests.
Restarting the service will result in it immediately handling requests as expected.
We have not as yet found any specific trigger to reproduce the error. Average request rate should not be exceeding ~1 request per second with occasional bursts up to ~16/s (though will verify that). This seems to be happening inside ~60 minutes or so after sustained use.
We will continue to debug in terms of whether we can find a reproducible scenario, any help is greatly appreciated.
Thanks!

Thanks for the report! I'll fix as soon as possible

Should be fixed now, thanks!


chore: Add workflow to validate PR titles

Pull Request Description
Description:
Add Semantic PR Title checks
Related Issue:
Checklist

[x] I have added the appropriate prefix  to the pull request title
[x] The CI tests are passing for this pull request.
[x] The pre-commit run -a hooks are passing for this pull request.

This PR is included in version 0.5.0 :tada:


What is the correct WETH-USDC Pool address on Ropsten?

I have tried both of these for pools:
//address WETHUSDCPool = 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640;
from https://etherscan.io/address/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640#readContract -- this looks like the right pool from searching

  address WETHUSDCPool = 0x8ad599c3A0ff1De082011EFDDc58f1908eb6e6D8; //?? linked from uniswap
from https://info.uniswap.org/#/pools/0x8ad599c3a0ff1de082011efddc58f1908eb6e6d -- this one I get from UNISWAP

I always get an error consulting the Uniswap V3 Oracle Library with these pools, it reverts which it can do if there are no reserves.
What is the correct WETH-USDC Pool? Thank you!!

The info I was getting from uniswap was a mainnet pool despite being connected to Ropsten in my metamask. Hm. How do I find the pool for WETH-USDC on Ropsten?

I found https://ropsten.etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984#code
and using  values
0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC Ropsten)
0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 (WETH Ropsten)
and 3000 for the pool rate
I got "0x8ad599c3A0ff1De082011EFDDc58f1908eb6e6D8"
this still always reverts when I do the Uniswap Oracle Library consult on it.

I am currently looking for it...my accounts have been severely compromised and I have to do a security check

No


Socket.emit error alwasy crash the caller

I found that this line:
setImmediate(() => sock.emit('error', errnoException(err, 'connect')));
always crashes the client, even if it is wrapped inside a try-catch block.
I found that putting another name, e.g.
setImmediate(() => sock.emit('my error', errnoException(err, 'connect')));
everything is fine, i.e. I can catch the error.

What do you mean? Can you show a trace? Note that the error is fatal, so you can't just catch it and move on.
You can listen to the error event on the socket and act on it.

The problem is related to this
https://github.com/socketio/socket.io/issues/2285

If the server the socket is trying to connect to is not responding how shall I catch the error? The following error is never fired.
client.on('error', function(err) {
                    logger.error("AVRO","Error ",err);
});

I'm not sure the connect fails when there is no server, TBH.


PHP 8.0 support

Package does not support php 8.0

@Djenkaa it looks like Travis has not released PHP8 support too: https://travis-ci.org/github/cybercog/laravel-ban/jobs/746159651


Mark bimap as trustworthy and/or safe?

Bimap 0.3.3 was automatically marked as safe by GHC, but that was lost with bimap 0.4 due to the import of GHC.Exts which is itself not safe.
Perhaps it could make sense to mark this module as trustworthy for newer GHC versions (where the import of GHC.Exts is used), and Safe otherwise (or perhaps GHC can figure that out for older versions).
At present this is limiting the use of bimap 0.4.0 in copilot-theorem because we have a module marked as Safe there.

Would it be possible to check if we are compiling in safe mode, and if so skip the import of GHC.Exts and the definition of the IsList instance?

The IsList instance could be moved into a separate module (e.g. Data.Bimap.UnsafeInstances). That would mean Data.Bimap could be Safe and IsList could only be used if the caller is willing to accept Trustworthy.
This would make IsList an orphan, which generates a warning.
@intricate You added the IsList instance, do you have any thoughts about this?

You'd probably want to define the module Data.BimapExt only for some GHC versions. So I correct myself: that would not be the complete patch, but it would be fairly close. The other-modules field in the cabal file would need to be guarded by an condition on the compiler version.

Would a patch along the lines of the above, with the changes I've mentioned below, be accepted? If so, any changes you think should be necessary (e.g., using a different module name)?

Thanks again.
I've prepared a PR. Please take a look. Let me know if anything needs to be changed.
There are GHC flags (i.e., trust) that could also be used to trust specific packages, but it would mean trusting everything, which may be overreaching. This commit adds a bit more code to maintain, but seems also more justifiable than trusting all of base or even all of GHC.Exts (if such a thing was possible).

The patch outlined in https://github.com/joelwilliamson/bimap/issues/14#issuecomment-1119491773 seems reasonable to me.

Yes. If you send me a patch t along those lines hat makes the whole library
usable in Trustworthy, and everything except IsList usable in Safe, I'll
add it and release a new version.
On Sat., May 7, 2022, 07:51 Ivan Perez, PhD, @.***>
wrote:

Would a patch along the lines of the above, with the changes I've
mentioned below, be accepted? If so, any changes you think should be
necessary (e.g., using a different module name)?
—
Reply to this email directly, view it on GitHub
https://github.com/joelwilliamson/bimap/issues/14#issuecomment-1120196084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANG27BTPF22AAVM3K4ZJV3VIZKKLANCNFSM5VG424EQ
.
You are receiving this because you commented.Message ID:
@.***>


Config object should dynamically set directory module name

Should be based on the label in the main config.
Given this example:
directory:
  connectors:
    ldap: C:\Users\adorton\projects\user-sync.py\config\connector-ldap.yml

The directory module name user_sync.connector.directory_ldap would be set in the config object.

This is done.


Day59

Resolves #129.

Pull Request Test Coverage Report for Build 649

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 645:
0.0%

Covered Lines:
5

Relevant Lines:
5

💛  - Coveralls


Beta2 rollout

This is the base-branch for the new back-end rollout

[x] Spacer integration. Issue #264
[ ] More vision backend tests. [@StephenChan ]
[ ] Purge python 2.7 compatibility code. [@StephenChan ]
[ ] Support for different extractors. Issue #235  [@StephenChan ]
[ ] More vision backend tests [@beijbom ]
[ ] More vision backend PEP8 and SWE [@beijbom ]
[ ] Make reg-tests robust for all settings. Add comparison for classifier performance. [@beijbom]

@StephenChan : I merged the first PR. Do you want to take a stab next? You can address any combination of your 3 items in the PR description. Doesn't seem the order matter that much.

Do you want to take a stab next and address any combination of your 3 items in the PR description. Doesn't seem like the order matter that much. Once done I'll take one more pass on the vision_backend app.

Sure. I can do 1) more vision backend tests and 3) support for different extractors. The second item, 'Purge python 2.7 compatibility code', doesn't necessarily have to happen before the rollout. Though I'll make sure to use Py3-only code for this branch.

Great. Let’s test explicitly for duplicate row/col values. I didn’t handle
that explicitly, so I’m curious if it works out anyways.
On Thu, Jun 18, 2020 at 19:54 StephenChan<EMAIL_ADDRESS>wrote:

Do you want to take a stab next and address any combination of your 3
items in the PR description. Doesn't seem like the order matter that much.
Once done I'll take one more pass on the vision_backend app.
Sure. I can do 1) more vision backend tests and 3) support for different
extractors. The second item, 'Purge python 2.7 compatibility code', doesn't
necessarily have to happen before the rollout. Though I'll make sure to use
Py3-only code for this branch.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/beijbom/coralnet/pull/323#issuecomment-646406327, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAITTF6QCGU4JZSNPLJ7VWLRXLHOVANCNFSM4NJVQRGQ
.

Great. Let’s test explicitly for duplicate row/col values. I didn’t handle that explicitly, so I’m curious if it works out anyways.

Agreed, there should be tests for that.
Also, a follow-up on the string-attribute related migrations from PR #324:

Just in case, I'll set up a Python 3 environment on our staging server and see if that encounters any issues with the new migrations.

I set up Python 3 on the staging server. The migration unit test fails, just like on Travis. However, the migration itself seems okay. I ran the images 0024 migration, and started the staging server. Didn't see any issues with existing metadata. Rolled it back to 0023, still no issues seen. So it's likely the unit test's issue.

Very nice! Nope; this should be good to go!

Yeah.
I'll have the Blog post for the feature extractor/classifier fully drafted
tonight.
But that's not really an announcement of the full release.
On Wed, Dec 23, 2020 at 4:05 PM Oscar Beijbom<EMAIL_ADDRESS>wrote:

Very nice! Nope; this should be good to go!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/pull/323*issuecomment-750607448__;Iw!!Mih3wA!S2fC73VRQTCZmF4VI7s_Vrrj_I5496JIx8_45VtdnUVQvAHQdKQST9DgyFoOuVhv$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5ALWTR7VU33HTZVTLADSWKAVDANCNFSM4NJVQRGQ__;!!Mih3wA!S2fC73VRQTCZmF4VI7s_Vrrj_I5496JIx8_45VtdnUVQvAHQdKQST9DgyPeO1Fpf$
.