Capacity and Payload Capacity be made Qualities, not Functions.

I suggest that a generic term Capacity be introduced as a subclass of Quality and Payload Capacity be moved accordingly.
A function is the reason that something exists. I am not sure that capacity is the reason for a vehicle to exist. Payload capacity seems to be a 'by-product' of the function of storing or carrying something. The only time a payload capacity might become a function is if someone intentionally builds a vehicle to break some sort of storage record, but even then, the storage or carrying function is really what's being created in the manufacturing of the vehicle, and the capacity is a way of speaking about the physical limit of that function.
Furthermore, what process would capacity be realized in? The payload capacity for a vehicle is the same whether it's empty or full.
I think 'range' also fits this account of capacity (mentioned in Issue 210). I don't think 'range' is the reason for a vehicle or its parts to exist. Certainly, an extended or improved transportation function might inhere in a vehicle and/or its parts, but range is a quality of those artifacts.
There is more to think about with regard to capacities under ideal v. real conditions, like range--the range of an electric car in a cold climate is significantly reduced.
Here is my first attempt at a definition:
Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.
The design pattern would be something like this: storage functions bear a storage capacity, payload functions would bear a payload capacity, distance functions would bear a range capacity, and so on. I do not think that this would unnecessarily duplicate the hierarchy, as the difference between the function and its limiting capacity would be used to model very different things. I also do not think we would have nearly as many capacities as we do functions; there seems to be a limited number of common canonical capacities. Storage would cover quite a lot, and be in the same ballpark as occupancy limits for rooms and facilities, a paradigmatic example I want to cover.
There are two objections that I have anticipated.
First, that what I'm modeling is really a disposition and not a quality. In some cases, this may certainly be true, but I'm still not sure what process would realize such a thing as 'payload capacity' since the capacity is the same whether a vehicle or facility is empty or full. While it is true that I'm talking about some material aspect of an entity, I think I'm capturing something distinct from dispositions and functions.
Second, that it's not a good idea to model a negative, which is what storage and payload limits are. I don't think I'm modeling a negative so much as I'm modeling the bound, the limit of a positive. I'm not modeling the 'ability to not carry 100 people in this vehicle' but rather the fact that 'the ability to carry people in this vehicle' has a kind of limit to its full realization. Though I do admit that there is something negative in what I'm doing, I'm trying to capture it in terms of the positive disposition and function.

"... Quality that inheres in an Independent Continuant or Specifically Dependent Continuant ...". Can a SDC inhere in an SDC? The range of "inheres in" is Independent Continuant. Or have I missed something.

You're right, I used 'or' because I am not sure whether I want to say that the function is what has the capacity or the material entity that has the function has the capacity... I think the latter.

Alternatively, to capture what I'm suggesting, we raise Capacity above Quality and allow it to specifically depend on an IC or SDC.

Could capacity be the quantification/degree of a function/quality rather than a distinct/separate SDC?

A function is the reason that something exists. I am not sure that capacity is the reason for a vehicle to exist.

This just means that it is not a function. It does not follow that it is not a disposition.

Furthermore, what process would capacity be realized in?

Depends on the capacity. Carrying a payload of such-and-such weight and volume is one way realize a payload capacity. I think the issue is that we use terms like 'capacity' and 'capability' differently, whether we are talking about a disposition vs the disposition as to its upper bound realization. It's a subtle nuance.

The payload capacity for a vehicle is the same whether it's empty or full.

By this logic, my ability to play drums is a quality, because whether I play a fast as I can or not at all, I still have the ability.

There is more to think about with regard to capacities under ideal v. real conditions, like range--the range of an electric car in a cold climate is significantly reduced.

Paradigmatic of a realizable entity. Under certain conditions, the entity is realized in a process, but in other conditions the entity is not realized or less likely to be realized.

Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.

Abilities are not qualities. Best fit is a disposition. Give some independent reason why any "can"/"is able to"/ability is not a realizable entity?
An ability to realize just is the realizable entity.
Specifically dependent Continuants are not realized. Processes are.

The payload capacity for a vehicle is the same whether it's empty or full.

By this logic, my ability to play drums is a quality, because whether I play a fast as I can or not at all, I still have the ability.
That's exactly what I intend to capture. You can play the drums, but a minivan cannot.

Capacity = def. A Quality that inheres in an Independent Continuant or Specifically Dependent Continuant in virtue of its ability to realize a Specifically Dependent Continuant.

Abilities are not qualities. Best fit is a disposition. Give some independent reason why any "can"/"is able to"/ability is not a realizable entity?
I want to capture the 'quality' of how a function or disposition may be realized, not those abilities themselves. I want to capture something about the storage function, or about the material entity that bears that storage function, not just the function itself. So no, I do not want to capture abilities, I want to talk about a portion of those abilities. Using the word 'about' here makes me think that the easy way out of this is to relegate capabilities to information-land, but I would rather not do this.

Specifically dependent Continuants are not realized. Processes are.
Realizable entities are realized, what do you mean here?

This sounds like the temperature that affects electric vehicles' distance
function (and gas ones) could be represented as process profiles. I
don't think capacity can be above a quality because that would entail for
every quality of a function, of which there can be many, to be broadened to
capacity, which can dull its definition.
For example,  "The heart has the capacity to pump." comes from its
properties/ qualities. These qualities separate the heart from other major
arteries that also have the same function capacity but not the same payload
capacity.
Using adjectives to describe processes are natural language process
profiles. "The Teslas distance range got shorter as the temperature got
colder," are two process profiles that correlate.
I'm not very well versed on capacity stuff but this is how it reads to me,
if there's anything to correct please let me know, thanks.
On Thu, Apr 4, 2024 at 10:09 AM Cameron More @.***>
wrote:

The payload capacity for a vehicle is the same whether it's empty or full.
By this logic, my ability to play drums is a quality, because whether I
play a fast as I can or not at all, I still have the ability.
That's exactly what I intend to capture. You can play the drums, but a
minivan cannot.
Capacity = def. A Quality that inheres in an Independent Continuant or
Specifically Dependent Continuant in virtue of its ability to realize a
Specifically Dependent Continuant.
Abilities are not qualities. Best fit is a disposition. Give some
independent reason why any "can"/"is able to"/ability is not a realizable
entity?
I want to capture the 'quality' of how a function or disposition may be
realized, not those abilities themselves. I want to capture something about
the storage function, or about the material entity that bears that storage
function, not just the function itself. So no, I do not want to capture
abilities, I want to talk about a portion of those abilities. Using the
word 'about' here makes me think that the easy way out of this is to
relegate capabilities to information-land, but I would rather not do this.
Specifically dependent Continuants are not realized. Processes are.
Realizable entities are realized, what do you mean here?
—
Reply to this email directly, view it on GitHub
https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/229#issuecomment-2037318665,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5355457K46HFO6AC3725S3Y3VNH3AVCNFSM6AAAAABFXHVFX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGMYTQNRWGU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***
com>

I don't think capacity can be above a quality because that would entail for every quality of a function, of which there can be many, to be broadened to capacity, which can dull its definition.

Capacity could be a sibling of quality, that's what I meant, and this does not affect the disposition or function.

For example, "The heart has the capacity to pump." comes from its properties/ qualities. These qualities separate the heart from other major arteries that also have the same function capacity but not the same payload capacity.

The function of a vein is different from the function of the heart. What I intend to capture is the capacity of amount of blood to flow through a vein or a heart because of its physical size or how 'well' it is performing its function.

I want to capture the 'quality' of how a function or disposition may be realized,

that sounds like a process attribute, eg- profile or characteristic

The discussion seems to be diverging from the original post into threads that use different senses of "capacity". And there are lots of dictionary definitions. Per the Oxford Languages dictionary:
The maximum amount that something can contain.

An amount is a quality. Definition 6 in the OED:
The power, ability, or faculty for anything in particular.

That's a realizable entity. Other definitions mention measurements.
I think @cameronmore's original post, when he discussed storage functions and their relationships to storage capacities, should still guide us, even if the property descriptions weren't quite right. How about this: A storage function doesn't bear a storage capacity. It specifically depends on a storage capacity. Some material entity bears both a storage function and that function's storage capacity. This pattern both lets you know the material entity's function and provides a measurement of the degree to which the entity supports the function.
A possible objection: you can store supplies in a cave, but storage is not the cave's function. The pattern applies only to artifacts designed for storage.

@mark-jensen I could be convinced that a capacity is a process profile, but I don't think that any process needs to occur for a room to have an occupancy limit of 100. The rate of people entering or leaving that room, or the rate of storage, would certainly be a process profile of the performance of the storage function of a room, but capacity stays the same. So, even if it's a process profile, it doesn't fit the intended spirit of a process profile. However, if we want to talk about realized capacities, then maybe such a profile approach would make sense.
@swartik agree, and I think I want to include dispositions in my account so we can handle the cave example. The cave has a disposition that allows us to store things in it, just as facilities have occupancy limits even if they have other 'primary' intended functions, hence what I was trying to get at in my comment about capacities being 'by-products' of other dispositions and functions.
There's another question about the 'bearer' of a capacity: it seems like I want to say that the same portions of material that endow a cave with its storage disposition are the same portions that also have  relation to this capacity, which is what leads me to think that the actual storage disposition might 'bear' the capacity, but that wouldn't be quite right (but that's just my train of thought).

A possible objection: you can store supplies in a cave, but storage is not the cave's function. The pattern applies only to artifacts designed for storage.

Bingo. There's a larger literature on capability (similar semantics to capacity). I believe the recommendation is that a capability is a disposition whose realizations are a benefit to some reference class. Or something like that. The notion then would be that a function is a capability. So, bfo:function should have a parent class that is below bfo:disposition. I am entirely sympathetic to adding capability and putting function underneath it. Right now, that's in CCO.
I don't think it has been nailed down: I take capability and capacity to be synonyms in common parlance. Does anyone take issue with this? Translating "storage capacity" to "capability to store" in appropriate? Same for "payload capacity" is equivalent to a "capability to transport material object"? In CCO, there's not many hits for "capacity". Payload capacity is the only one with the term 'capacity' in the label. Many more include 'capacity' in its definition.
@cameronmore made the point as well that we don't want to get confused between the capacity and the measurement of it. That's right. So, if someone said "this Aklaline battery has 1200 mAh capacity", we are talking about a value of a measurement, and that the value of the capacity is at its upper-bound.
So, Cameron, your point is that you want to say "what is the upper-bound, that is being measured? Is this upper-bound not just a quality?"

I want to capture the 'quality' of how a function or disposition may be realized, not those abilities themselves. I want to capture something about the storage function, or about the material entity that bears that storage function, not just the function itself. So no, I do not want to capture abilities, I want to talk about a portion of those abilities. Using the word 'about' here makes me think that the easy way out of this is to relegate capabilities to information-land, but I would rather not do this.

There is something here about qualities that is right, but it isn't a parent-class or sub-class of quality. The explanatory basis for any disposition existing in a continuant is the quality that the continuant bears. A change in disposition is grounded in (or at least explained by) a change in the bearer's quality. When I couldn't play drums, I still had dispositions, but my ability to play drums was acquired in virtue of changes in qualities. There isn't some clear differentiae of those qualities that ground my disposition vs those that do not.
Is this what you have in mind? Is this helpful?

@jonathanvajda Yes, now we're seeing the same thing. I have become highly sympathetic to adding capability, and it is highly related to a capability/disposition/function. I would say, to be more precise, that a capacity is 'about' the upper bound of any disposition (and subclasses thereof), hence why the measurement value of the capacity is what of primary interest to those using ontologies.
A design pattern I have would be something like this:
Artifact bears Function.
Function realized in Process.
Capacity specifically depends on Artifact
Function has capacity Capacity
The same portions of a cave that give it a storage disposition are the same that yield a capacity to perform that disposition, but the capacity is not the function, but s-depends on the same things that the function does.
Now, there's a whole other can of worms when it comes to producing measurements of those capacities and the fact that they can change over time, but I think this is how it works broadly. My revised draft definition now looks like:
A Capacity is a Specifically Dependent Continuant that specifically depends on some independent continuant and is the magnitude of a disposition to be realized.

There are all sorts of axioms we can create around this link of a realizable entity to a capacity. Now along with 'gain of function' and 'loss of function' we could talk about 'increase of capacity' and 'decrease of capacity' and tie them back to the functions and dispositions...

@cameronmore, in your revised definition, have you thought about how you would express "is the magnitude of a disposition"? Is it as simple as one SDC specifically depending on another, or does it need to be expressed using a process and participants? To put it another way: can the characteristics of an independent continuant's disposition change, or does the independent continuant have a new and distinct disposition? For instance, what happens to storage capacity when a cave-in reduces the volume of a cave?

@swartik I'm thinking that the function already has realizable conditions encoded in the definition/axioms/queries, so linking it to that function is sufficient, we don't need to go all the way to a process in most cases.
Regarding the changing of the capacity, that is some new semantics that have to be worked out, but I think the design is straight forward. A process needs to occur to change the capacity of an entity--a facility is expanded, or a computer network has more servers added, and so on. The use-cases I have in mind for applications revolve around comparing the capacity to the current performance of a function--this room has a limit of 15 people and I'm using a recurring sparql query to check if the room is at capacity and alert on a count that approaches that limit.
I think capacities are always linked to existing (positive) dispositions and functions, capacity is an enhancement to the way we understand the realization of those dispositions and functions.
Perhaps this is because of ambiguity in natural language, but I can say that 'the cave has a storage capacity', and 'the storage function has a capacity', so I'm not settled on what the capacity s-depends on, though I'm leaning on the former and asserting a new relation between the capacity and function.

I've done a lot of thinking and it seems to me that capacities are SDCs which are the maximal realization of dispositions.
Dispositions are realized when some triggering stimulus reaches a material disposition which bears the disposition, and the disposition causes a change in some state of affairs (the process that dispositions are realized in).
Capacities describe the maximal realization of a disposition when given maximal stimulus, and thus produce maximal resulting change. For example, the disposition of a glass to hold a certain volume of water is realized when water fills the glass, and the realization of the disposition is such that water is now located inside the glass. Only when a maximal amount of water is present does a glass reach its capacity (and perhaps overflow if the stimulus is too great). There may be lots of things, like metaphysical masks, that change the context and may decrease the ability for a stimulus to reach a disposition, but there is a capacity regardless. See this paper on blindness for a similar account.
I think this interpretation is generalizable to the sorts of dispositions I want to cover with this term capacity. I'm not certain whether it is (1) a 'part' or (2) it itself 'specifically depends on' or (3) 'is boundary of' dispositions. To say that a capacity is a part of a disposition implies that it itself is a realizable, and this might make sense if we understand capacity as that maximal portion of the disposition. But, if we separate the realizable from its realization, then the parthood relation doesn't make sense. I would rather create a new 'boundary' kind of relation for the realization such that a capacity is a boundary for the realization of a disposition.

capacities are SDCs which are the maximal realization of dispositions.

All maximal realizations are occurrents. No SDCs are occurrents. Thus, no SDCs are maximal realizations.
But it definitely has to do with the modality at which point realizations are dysfunctional, less likely, or otherwise no longer occur. For example, pouring a half-liter of water into a receptacle is easy when the receptacle is empty, harder when it's 1/4 full, a lot harder when it is 7/16ths full, etc. There's an asymptote-like approach toward the "cannot hold another half-liter" based on how much of the capacity has already been realized. Mutatis mutandis when you are just adding a droplet of water, or a stream of droplets across a longer period of time.

Capacities describe the maximal realization of a disposition when given maximal stimulus

This is a little off. Capacities are not ICEs. So, no capacities describe.
The stimulus talk is helpful for framing this more ways we need to be able to capture. But it seems odd in some cases. It is helpful when we are talking about some disposition to react, such as when you poke a bear it growls, or when you move in front of a motion sensor it triggers a flood light to turn on. A water receptacle doesn't change when water is put in its internal material boundary. The water seems like a better candidate for "doing" anything (it is being poured). What is the stimulus? Water? What is the reaction to the stimulous? Not doing something? Worth thinking through.

See this paper on blindness for a similar account.

Lacks or privations are I think critical here, especially for artifacts and what capacities are realized (or not) and under what conditions.

I'm not certain whether it is (1) a 'part' or (2) it itself 'specifically depends on' or (3) 'is boundary of' dispositions. To say that a capacity is a part of a disposition implies that it itself is a realizable, and this might make sense if we understand capacity as that maximal portion of the disposition. But, if we separate the realizable from its realization, then the parthood relation doesn't make sense. I would rather create a new 'boundary' kind of relation for the realization such that a capacity is a boundary for the realization of a disposition.

What might be helpful here is just to describe qualities that ground the disposition, and some qualities are stronger or more exemplified than others.  I play drums better than you, and this is grounded in the differences in qualities. When I play at my upper-bound, that limit is explained by the qualities I have; when you play at your upper-bound, that limit is explained by the qualities you have. The differences in limits between us, then, gets explained by differences in qualities that inhere in our respective bicep muscle groups.
What is the relation between the quality of muscle aggregate and the process-that-would-occur-if-at-upper-bound? That still sounds a little elusive. But think we're on the right track of talking about what SDCs are relevant, and whether they are actualized SDCs or realizable SDCs.

I have in mind two use-cases that exemplify the range of capacities I want to talk about. First, the water. The glass has a disposition 'to hold water'. A manifestation of this disposition would be a state of affairs in which water is being held. So, when the 1 liter glass holds 1 liter of water, it is no longer able to instantiate new manifestations, namely, more water being held in the glass. The glass does not break or anything like that.
But I like the idea of 'how easy is it to manifest such and such with this stimulus'. It's easy for a bodybuilder to pick up 5 pounds, but it's hard when they're already holding 250...
The second use case I have in mind is an aircraft hull's disposition to pressurize (ignoring for a moment that this is a complex disposition, with lots of other artifacts helping, just think about the skin, hull, fuselage). What happens when it reaches its asymptotic capacity? The hull cracks and the disposition is lost. Another thing to worry about down the line is gradations of failure, at what point would we say a disposition is lost, but that's often a granularity issue.
So, this is helping us along, thinking about the things that ground the disposition being important for the disposition's capacity. @APCox has thought a lot about this, and perhaps capacity is itself a realizable.
That direction got me thinking about internally grounded finks and masks (rather than external ones). But again, what 'grounds' these internal ones?
My initial thoughts about grounding go in the direction of 'dispositions inhere in material entities, and since all material entities are finite, all dispositions are finite, and further if realization occurs when stimuli trigger dispositions (and both of which are material), then baked in to the notion of realization is an idea that realization is determined by the finitude of the material entities involved.'... need to think about it more, but just sharing some thoughts.

This is an analysis by analogy to our understanding of temperature.
Some entities have a total order on their subtypes, by which I mean there is some ordering (an example would be "greater than" or "hotter than") between instances and perhaps between types. In the case of temperature, the value of temperature represents its type (see Figure 3, [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3718480/](Classifying Processes: An Essay In Applied Ontology)). In that paper such classes are called determinable. I think the determinable thing has some complications so just think about temperature and it's ordering. A greater-than relation hold between instances of temperature by virtue of the fact that the space of types can be totally ordered. FWIW I think that it is the types that have a greater-than relationship.
Consider a cup that can be filled with liquid. Volume of a portion of liquid is like temperature in that it has an intrinsic lower bound of 0 and no upper bound (other than to the extent that there is a finite amount of material in the universe). The volume of a portion of water than can occupy a specific cup, however, does have an upper bound. Going by analogy to temperature, call that type Vt. Consider the class of volume types which include all volume qualities whose instances are which are not greater-than Vt. The cup has the capacity to hold volumes of water that are of this type.
In the case of temperatures, numeric values of temperature are information entities that are effectively names for the different temperature types. By analogy that maximum volume is also named by some information entity. So, a cup's capacity to hold liquid is a type Vt, and a name for it is an information entity like the volume measured in cubic centimeters.
We might represent this as a relation to a type (has-capacity cup Vt). [This might be time-indexed]. A first pass representation of the capacity of a cup that can carry 1 litre is, where cup is understood to have a site that's part.
cup has-capacity Vt
Vt is-a volume quality (i.e. a type, not a particular)
(every) Vt inheres in some liquid that located-in cup site
ic instance-of value specification
ic has-value 1
ic has-unit litre
ic describes Vt
We could write, approximately, and ignoring time for the moment.
(iff (has-capacity cup Vt)
   (forall (l v)
      (implies
        (and
             (instance-of l liquid)
             (located-in l cup-site)
             (inheres-in v l)
             (instance-of v volume))
          (instance-of v Vt))))

cup, cup-site, v, l are particulars
liquid, volume, Vt are classes, with Vt identified with "the capacity"
But working with types like this is unnatural for OWL and because is about is promiscuous, something about a volume of liquid in a cup is about a cup as well, in which case we might just have a capacity specification that describes the cup, with the above explanation providing a path to define that kind of value specification.

I think this representation gets at the problem nicely. Would we have a generic top class 'capacity' which would have Vt under it along with the others? Or is there a 'volume capacity' defined class? (Volume in CCO is an alt label for Three Dimensional Extent, which is a Size Quality, which is a Quality).

Capacity in the sense I wrote isn't a class, it's more like a category whose members are classes, at the same level as the term universal. The set of volume capacities is a set of subclasses of volumes that inhere in things that have volume qualities. A specific capacity is a class (like Vt). So at least the way I've laid it out the ultimate representation would not to be to have a capacity class (Vt) but rather a capacity value specification, an information content entity. It might be said to be about some volume that inheres in a cup, though "cup" in that sentence might be a class of cups, or a particular cups, in which case punning would be used in OWL. A subclass of capacity value specification could be volume capacity specification, which we could just say is about some volume.
I started to do an analysis of the car range example, but I think that introduces some other issues as we're dealing with dispositions and realizations. I'll try to write something up about it in time.

@alanruttenberg Can you clarify something? In:
   (instance-of l liquid)
   (located-in l cup-site)

does this say anything about the volume of l? The located-in property assertion doesn't imply l completely occupies cup-site. If l is a drop of liquid, ic describes Vt should not hold. Do you need a more specific subproperty? Or should v also be described by a value specification?
On a side note, (inheres-in v l) makes liquids independent continuants. Hydrogen is an independent continuant, but its state (solid, liquid, gas) depends on its energy. If fuel cells ever become practical and we have to start worrying about hydrogen storage, state will have to be treated as a specifically dependent continuant.

@swartik hopefully implicit in the 'has-capacity' relation still is what I mentioned earlier about the maximal realization of a disposition, so that's doing the work, but the implied statements are not the exhaustive definition of what 'has-capacity' means, but they seem to be necessary parts of the phenomenon of capacity. Am I getting that right @alanruttenberg ?
Re capacity not being a class, that makes sense, but I would worry about having 'capacity' classes all over the hierarchy instead of all the capacities in one place.

@alanruttenberg Can you clarify something? In:
   (instance-of l liquid)
   (located-in l cup-site)

@swartik located-in is a lower bound. So if you x is located in y then x is not located in a proper part of y. But if y is part of z, x is also located in z.

does this say anything about the volume of l? The located-in property assertion doesn't imply l completely occupies cup-site.

No, it doesn't say anything about the volume of the liquid, which is why we have v, the volume quality that inheres in the liquid. We could separately have another volume quantity that inheres in the cup site. I didn't identify capacity with that as a) The cup site has a vague boundary and b) there could be a hole in the side of the cup.
If l is a drop of liquid, ic describes Vt should not hold. Do you need a more specific subproperty? Or should v also be described by a value specification?
v could also be specified by a value specification. ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities that liquid held in the cup can have.

On a side note, (inheres-in v l) makes liquids independent continuants. Hydrogen is an independent continuant, but its state (solid, liquid, gas) depends on its energy. If fuel cells ever become practical and we have to start worrying about hydrogen storage, state will have to be treated as a specifically dependent continuant.

Liquids, hydrogen, solids, liquids, and gases are all independent continuants. They are all material entities. The changing states of matter is a known problem of identity. Namely if you have a portion of ice in a cup and it melts yielding a portion of water in a cup is the portion of water the same particular as the portion of ice? I don't think there is an objective answer to this question and it is a matter of ontological commitment.  There are some times when identity makes sense to be tracked across states and some times when it doesn't.
Regarding state, that's relevant if the choice is that the ice and water are the same particular, since then we would have to have something that changes. The state of matter would be a quality I expect.

@swartik hopefully implicit in the 'has-capacity' relation still is what I mentioned earlier about the maximal realization of a disposition, so that's doing the work, but the implied statements are not the exhaustive definition of what 'has-capacity' means, but they seem to be necessary parts of the phenomenon of capacity. Am I getting that right @alanruttenberg ?

That's what has-capacity means. What we call the capacity I am identifying with the superclass of all classes of volume of things located in the cup-site.

Re capacity not being a class, that makes sense, but I would worry about having 'capacity' classes all over the hierarchy instead of all the capacities in one place.

From an engineering point of view this is an issue. There is choice as to whether those classes are represented or not, or whether just the information content entity is, which is where I lean. But there's also a matter of language. Suppose we have a type of aircraft (say 747) and we had a class "747 capacity". That name could be misleading because not all instances are the maximum capacity. Instances are of type any volume (subclass) less than or equal to what we would call the capacity. I.e. an instance of 1/2 of the 747's volume capacity would also be an instance of 747 capacity, since if i an instance of c and c subclass d then i an instance of d - that's the logical definition of subclass.

I think the 747 would have a variety of capacities linked to specific, distinguishable dispositions, like its carrying capacity, its pressurization capacity, and so on. Each of these could have labels like '747 Carrying Capacity' and '747 Pressurization Capacity'.

Instances are of type any volume (subclass) less than or equal to what we would call the capacity. I.e. an instance of 1/2 of the 747's volume capacity would also be an instance of 747 capacity

I'm not following what you mean here in the example

I'm thinking that there could be a few top-level capacity classes like Force Capacity and Volumetric Capacity. The former is the Capacity of a material entity to generate, absorb, or displace a certain amount of force and the later is a capacity linked to the disposition to contain or enclose other material. Heat capacity is another good candidate for a top level capacity.
I've also thought of Complex Capacities (or Aggregate Capacities) which are composed of other capacities which are not as fuzzy, like how the manufacturing capacity of a factory is a combination that is calculated from the power of all the machines, the amount of people on staff, and so on. Range capacity might be a complex capacity since it has a lot to do with other elements of vehicles and not just the engine output (like aerodynamics)

Perhaps something like this using the artifact model approach:
Cup has-capacity Vt
Vt prescribed-by CupCapacitySpecification
CupCapacitySpecification rdf:type ArtifactModel
CupCapacitySpecification has-value 1 Liter

And then
Cup participates-in WaterHolding
Liquid participates-in WaterHolding
WaterHolding rdf:type Process
Cup has-continuant-part CupSite
Liquid located-in CupSite
LiquidVolume inheres-in Liquid
LiquidVolume rdf:type Quality
LiquidVolume measured-by RatioMeasurementICE
RatioMeasurementICE has-value 1/2 Liter

(Besides the ICE-IBE links and nodes, which are not the key point here)

Alternatively, if we make capacity a class and let the 'limits' relation relate the capacity to the corresponding disposition, then we might get something like this which is similar enough in OWL
Capacity limits some Disposition
VolumetricCapacity subclass-of Capacity
Vt1 rdf:type VolumetricCapacity
Vt1 limits HoldingDisposition
Cup bearer-of HoldingDisposition
HoldingDisposition realized-in WaterHolding
...

And the graph continues from there as outlines above

As I understand @alanruttenberg's approach, the first two lines would be:
Cup has-capacity some (Vt and (has-value value CupCapacitySpecification))

to accommodate Vt being a class.

ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities
that liquid held in the cup can have.

I know you said working with OWL is unnatural, but it's the only language I have. So I need to understand how you
would translate your formulation to OWL. If Vt is a class, you can't assert ic describes Vt (unless you pun, which I assume
is not your intention).

I would have to pun to write that, which is part of the reason I don't think I would bother representing Vt explicitly as a class. But FWIW I have recently had other reasons to consider punning.

In short, I am asking for agreement on how to express the following two statements in CCO:
1. Cup c is capable of holding a maximum of 1 liter of liquid.
2. Cup c holds 1/2 liter of water.

Something like:
(2)
ic1 type value specification (I have asked this to be added to CCO)
ic1 has specified value .5 (ditto)
ic1 uses_measurement_unit
ic1 describes q1 (could use is_a_measurement_of since it probably is)
q1 type volume
q1 inheres_in c
(optionally) ic1 describes c
(1)
ic2 type volume capacity specification
ic2 has specified value 1
ic2 uses_measurement_unit
ic2 describes c
With volume capacity specification defined in text.
Or to have some axioms to defined volume capacity specification:
volume capacity specification subclass of capacity specification
volume capacity specification describes volume (the class, so punning)
or
volume capacity specification subclass of describes some volume (might be a lie, maybe white)
I model the temporal aspect using a time value specification and a relation 'has timestamp' e.g
t1 a time value specification
t1 has specified value
where  could be an xsd:dateTimeStamp, or in my case TAI time in nanoseconds, in which case I'd also have
t1 uses_measurement_unit
Finally, associating the value specification with a time
ic1 has timestamp t1
Sorry this isn't all CCO - the value specification pattern is from OBO and I've asked for it and associated relations to be in CCO.

I think the 747 would have a variety of capacities linked to specific, distinguishable dispositions, like its carrying capacity, its pressurization capacity, and so on. Each of these could have labels like '747 Carrying Capacity' and '747 Pressurization Capacity'.

Yes. I was writing shorthand.

Instances are of type any volume (subclass) less than or equal to what we would call the capacity. I.e. an instance of 1/2 of the 747's volume capacity would also be an instance of 747 capacity

I'm not following what you mean here in the example

Ok. We've identified the 747 volume capacity as a subclass of volume of things that fit in a 747 and superclass of all volume qualities that inhere in the things inside the 747. When I say "identified" I mean that when we talk about capacity what we are actually referring to is that class (call it 747C). So suppose I have a particular - the volume quality of something that fills half the capacity of the 747. That's an instance of 747C. So what should we call 747C? If we called it 747 volume capacity, one might have the impression that any instance of it is the maximum volume the 747 could have. But as I've explained, it not that, it's the volume of anything that fits.
When we say "Universal" that isn't a class. It's a category whose members are classes (loosely speaking). Similarly "Capacity" isn't a class. It's a subcategory of universal.
Now I understand that what feels natural is that the capacity of something is a particular, an instance of capacity the class. My analysis says that the natural thing is a manner of speaking.
We could go beyond BFO and try to reify capacity - make capacity a special class whose instances are standins for classes. That's pushing downward a category to a class, and pushing down a class to an instance. RDF-wise this would be acceptable, with semantics going beyond OWL-DL. Maybe there's even a modified OWL to FOL translation that could handle that properly. But since we have value specifications already and they seem up to the task, I chose that rather than the extension.

https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/229#issuecomment-2113527170 was written too quickly, not distinguishing the liquid from the cup. I will rewrite.

[Edit: mistakes: See https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/229#issuecomment-2113570963]

ic describes Vt because Vt has nothing to do with the liquid. It is the class of all volume qualities
that liquid held in the cup can have.

I know you said working with OWL is unnatural, but it's the only language I have. So I need to understand how you
would translate your formulation to OWL. If Vt is a class, you can't assert ic describes Vt (unless you pun, which I assume
is not your intention).

I would have to pun to write that, which is part of the reason I don't think I would bother representing Vt explicitly as a class. But FWIW I have recently had other reasons to consider punning.

In short, I am asking for agreement on how to express the following two statements in CCO:
1. Cup c is capable of holding a maximum of 1 liter of liquid.
2. Cup c holds 1/2 liter of water.

The 1/2 litre of water we will call l
Something like:
(2)
ic1 type value specification (I have asked this to be added to CCO)
ic1 has specified value .5 (ditto)
ic1 uses_measurement_unit
ic1 describes q1 (could use is_a_measurement_of since it probably is)
q1 type volume
q1 inheres_in l
l located in c
(1)
ic2 type volume capacity specification
ic2 has specified value 1
ic2 uses_measurement_unit
ic2 describes c
With volume capacity specification defined in text.
Or to have some axioms to defined volume capacity specification:
volume capacity specification subclass of capacity specification
volume capacity specification describes volume (the class, so punning)
or
volume capacity specification subclass of describes some volume (might be a lie, maybe white)
I model the temporal aspect using a time value specification and a relation 'has timestamp' e.g
t1 a time value specification
t1 has specified value
where  could be an xsd:dateTimeStamp, or in my case TAI time in nanoseconds, in which case I'd also have
t1 uses_measurement_unit
Finally, associating the value specification with a time
ic1 has timestamp t1
Sorry this isn't all CCO - the value specification pattern is from OBO and I've asked for it and associated relations to be in CCO.

@cameronmore  re: Limits relation. The thing is, what kind of thing is the subject of limits? Specifically, under what BFO class does the subject of the limits relation fall under?
A dispositional view on volume capacity would be something like: Disposition realized in trying to fill past capacity and failing, though there's a question of what the bearer is.
Back to temperature. What's 0 degrees kelvin, the minimum possible temperature? A subclass of temperature. With the BFO view of types as values, maximums and minimums are going to be types too. It's a decent philosophical stance, but a PITA to deal with, forcing an escape to information entities.

@alanruttenberg I've been thinking about the answer to that for a few weeks and am not sure. I thought it might be a kind of specifically dependent continuant that limits the realization, like an internally grounded disruption. If the maximum is ultimately a type of temperature, then the capacity is a thing that creates that maximum and not the maximum itself, but this starts to get complicated because we would have to introduce capacity as well as all the corresponding maximums that the capacity creates and then take measurements of those, but not the maximum.
This is why I was motivated to say that capacity just was the maximum and hadn't thought about the 'limits' relation.

A few comments before I dig into the meat of the discussion:

@alanruttenberg's use of puns changes my conception of how capacities would be modeled. You can ignore some of my comments yesterday.
But I still want to know how to express my example in OWL.
I agree that values are better associated with information content entities than information bearing entities. Has the request to add Value Specification been presented as a github issue?
The domain of uses_measurement_unit is Information Bearing Entity. Just wanted to check whether the Value Specification request covers measurements too.

@swartik @alanruttenberg Thinking about it, I think has-capacity makes sense as an object property where:
A is capacity of B = (approximately)
Function A inheres in Artifact B such when A is realized, there is no Function which is of a greater grade than Function A.
This builds the semantics of gradation into the property, which, to be fair, is already built into other classes and properties like ‘disrupts’ and ‘inhibits’ and the increase/decrease of realizable entity classes.
Is this in the right direction?

Quick response: I think it is the functioning rather than the function that is graded. Also, definition as given looks almost circular. Maybe
A is capacity of B = (approximately)
Function Ax inheres in Artifact B such that the realization of A is a process of grade x or lower.
I think there needs to be some better wording/thinking about grading, so this is just to illustrate the form.
If function A is in general say, manufacturing of widgets at some rate then Function Ax is an instance of a subclass of function A. However it would be reasonable to create an instance of Function A and then have an ICE that gives the numeric rate, since an instance of Ax would also be an instance of A.

Yeah, there's a sense of realization (functioning) I'm building into this definition, and hence almost modal. I like the definition you gave.


[Wait for #1376] [dataset] split train / val / test databuffer

[Pending commit: #1376]

[dataset] split train / val / test databuffer

This patch splits train / val / test dataset.

It is also possible to set dataset separately from the model.

**Major Changes**
1. `auto dataset = createDataset(train_cb, val_cb, test_cb)` -> `auto
dataset_train = createDataset(train_cb)`
1. `NN.setDataset(dataset);` -> `NN.setDataset(DATA_TRAIN,
dataset_train)`

**Self evaluation:**
1. Build test: [X]Passed [ ]Failed [ ]Skipped
2. Run test: [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Jihoon Lee<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1379. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.

:octocat: cibot: @zhoonit, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nntrainer/ci/repo-workers/pr-checker/1379-202107091141290.86986708641052-b305b6132297cd1564e1514603804b09a1299523/.

Let's remove DatasetType type while creating the dataset from the C++ API ( current signature std::unique_ptr createDataset(DatasetType type, const char *file);), and rather pass it while setting this dataset to the model? I do understand that this is needed for the C-API, so ml_train_dataset_h can store the dataset type inside its structure and pass it while setting the dataset appropriately.

There is just one downside, the C++ API and C API will differ at this stage. To avoid this, make create a new DatasetType for C++ ANY where the type of dataset is not yet known (which will be default value) and will be set when setting the dataset to the model. Now, the C++ API is a superset of C-API.

Can't agree more. I will remove type on the upcoming PR's. Currently type is a member of databuffer and need some broader changes to directly apply here.

Let's remove DatasetType type while creating the dataset from the C++ API ( current signature std::unique_ptr createDataset(DatasetType type, const char *file);), and rather pass it while setting this dataset to the model? I do understand that this is needed for the C-API, so ml_train_dataset_h can store the dataset type inside its structure and pass it while setting the dataset appropriately.

There is just one downside, the C++ API and C API will differ at this stage. To avoid this, make create a new DatasetType for C++ ANY where the type of dataset is not yet known (which will be default value) and will be set when setting the dataset to the model. Now, the C++ API is a superset of C-API.

Can't agree more. I will remove type on the upcoming PR's. Currently type is a member of databuffer and need some broader changes to directly apply here.

Then please a corresponding TODO / add to issue to keep track for it :).

Then please a corresponding TODO / add to issue to keep track for it :).

Wait, we will need types.

There are some other types of databuffer added in the upcoming PR that rely on the current semantics (eg) random_categorical)
for ini need to parse the same way
setting property after setting to the model won't be allowed.
we will need two set of set property in cc, capi.

I'll make a templated factory instead.
typename <typename Args...>
std::unique_ptr<Dataset>
createDataset(DatasetType type,
              const std::vector<std::string> &properties = {}, Args &&args...);

Then please a corresponding TODO / add to issue to keep track for it :).

Wait, we will need types.

There are some other types of databuffer added in the upcoming PR that rely on the current semantics (eg) random_categorical)
for ini need to parse the same way
setting property after setting to the model won't be allowed.
we will need two set of set property in cc, capi.

I'll make a templated factory instead.
typename <typename Args...>
std::unique_ptr<Dataset>
createDataset(DatasetType type,
              const std::vector<std::string> &properties = {}, Args &&args...);

Should these be other types of dataset or be a property of the existing datasets. Can you list out the types of dataset you are planning (maybe in an issue and we can continue the discussion there).
Also, lets try to not attach type to dataset in internal code. It can done at the capi implementation side. For the ini also, it can be handled at the ini reading side.

Also, lets try to not attach type to dataset in internal code. It can done at the capi implementation side. For the ini also, it can be handled at the ini reading side.

I think attaching datatype is needed.
There are list of different dataset types which would likely to have same

Mock dataset which generates a random one-hot label (already implemented)
ImageFolder dataset (which will also receive a const char*)
Specified Format of dataset (perhaps in format of hdf5, receiving const char*)
Some custom datasets (just like pytorch support it)

Those use cases can be a property and we put switch cases like current loss layer or activation layer, but I think it's not very extensible. IMO, those would better be a polymorphic object like layer does.

Also, lets try to not attach type to dataset in internal code. It can done at the capi implementation side. For the ini also, it can be handled at the ini reading side.

I think attaching datatype is needed.
There are list of different dataset types which would likely to have same

Mock dataset which generates a random one-hot label (already implemented)
ImageFolder dataset (which will also receive a const char*)
Specified Format of dataset (perhaps in format of hdf5, receiving const char*)
Some custom datasets (just like pytorch support it)

Those use cases can be a property and we put switch cases like current loss layer or activation layer, but I think it's not very extensible. IMO, those would better be a polymorphic object like layer does.
There soon will be a factory refactor PR, I think we can continue discussion there.

Dataset types like these are fine. Basically, the base dataset is databuffer using callback. All of these are just callbacks implemented for different file/format types. Thats what I meant by property. Depending on the property, this kind of dataset callback would be attached.
DatasetType is confusing keyword as of now, so this type will have to attach but I meant train/test and certain other types based on properties like shuffle etc.

DatasetType is confusing keyword as of now, so this type will have to attach but I meant train/test and certain other types based on properties like shuffle etc. When you have the base class ready for dataset, which all other types would extend, please share the PR explicitly for review.

I understood what you mean. I'll make a simple diagram in #303.

DatasetType is confusing keyword as of now, so this type will have to attach but I meant train/test and certain other types based on properties like shuffle etc. When you have the base class ready for dataset, which all other types would extend, please share the PR explicitly for review.

I understood what you mean. I'll make a simple diagram in #303.

I want to put another thought to remove file type support. I think we don't need to. Saving order or format of data is quite differ as well. and the data type is differ too. It could be really hard to support. And file format also can support with callback so.. we could deprecate the file support for dataset. then it could make some issues easier.


Add missing permission constants (UseActivities, ManageEvents, UseExternalStickers)

Adds a couple of permission constants that were missing, specifically:

Use Activities / 0x8000000000
Manage Events / 0x200000000
Use External Stickers / 0x2000000000

Thanks for your contribution!


Initialize event update

Codecov Report

Merging #37 (062f3cb) into master (b19a29f) will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #37      +/-   ##
==========================================
+ Coverage   96.64%   96.76%   +0.12%
==========================================
  Files          12       12
  Lines         537      557      +20
  Branches       63       63
==========================================
+ Hits          519      539      +20
  Misses          9        9
  Partials        9        9

Impacted Files
Coverage Δ

...omponents/svg-container/svg-container.component.ts
100.00% <100.00%> (ø)

src/app/modules/directives/svg-circle.directive.ts
96.00% <100.00%> (+0.16%)
:arrow_up:

...rc/app/modules/directives/svg-ellipse.directive.ts
96.00% <100.00%> (+0.16%)
:arrow_up:

src/app/modules/directives/svg-image.directive.ts
96.49% <100.00%> (+0.12%)
:arrow_up:

src/app/modules/directives/svg-line.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

src/app/modules/directives/svg-path.directive.ts
96.36% <100.00%> (+0.13%)
:arrow_up:

...rc/app/modules/directives/svg-polygon.directive.ts
95.91% <100.00%> (+0.17%)
:arrow_up:

...c/app/modules/directives/svg-polyline.directive.ts
95.91% <100.00%> (+0.17%)
:arrow_up:

src/app/modules/directives/svg-rect.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

src/app/modules/directives/svg-text.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #37 (062f3cb) into master (b19a29f) will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #37      +/-   ##
==========================================
+ Coverage   96.64%   96.76%   +0.12%
==========================================
  Files          12       12
  Lines         537      557      +20
  Branches       63       63
==========================================
+ Hits          519      539      +20
  Misses          9        9
  Partials        9        9

Impacted Files
Coverage Δ

...omponents/svg-container/svg-container.component.ts
100.00% <100.00%> (ø)

src/app/modules/directives/svg-circle.directive.ts
96.00% <100.00%> (+0.16%)
:arrow_up:

...rc/app/modules/directives/svg-ellipse.directive.ts
96.00% <100.00%> (+0.16%)
:arrow_up:

src/app/modules/directives/svg-image.directive.ts
96.49% <100.00%> (+0.12%)
:arrow_up:

src/app/modules/directives/svg-line.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

src/app/modules/directives/svg-path.directive.ts
96.36% <100.00%> (+0.13%)
:arrow_up:

...rc/app/modules/directives/svg-polygon.directive.ts
95.91% <100.00%> (+0.17%)
:arrow_up:

...c/app/modules/directives/svg-polyline.directive.ts
95.91% <100.00%> (+0.17%)
:arrow_up:

src/app/modules/directives/svg-rect.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

src/app/modules/directives/svg-text.directive.ts
96.15% <100.00%> (+0.15%)
:arrow_up:

Continue to review full report at Codecov.

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


chore: updates arquillian cube dependencies.

@hemanik Thanks for the PR!
Do you have these changes working for you locally?
I am asking because our CI seems to be failing with this PR

This should be postponed post-Summit.

@hemanik Thanks!
We will recheck and merge the changes in a week or so, when summit is all done.

@geoand What is the status about this PR ?

This (as well as the other relevant PRs to the other boosters) are very old and should probably be closed


Can you add the new environment variable for the MixRamp option?

Can you add the new environment variable for the MixRamp option?
To analyze songs on-the-fly, the mixramp_analyzer option can be enabled in mpd.conf:
mixramp_analyzer "yes"
More info: https://mpd.readthedocs.io/en/latest/user.html#mixramp
Originally posted by @skierro in https://github.com/GioF71/mpd-alsa-docker/discussions/379

Hello, I might be wrong but the version tagged as 'v0.23.15' does not contain the needed changes.
The next commit instead includes those changes. But I am building against the tag v0.23.15.
Have a look at this commit page:
https://github.com/MusicPlayerDaemon/MPD/commits/master/?after=c71e586c530e1d066efde7c2ca40c363f74100c7+139
The relevant commits:
Merge tag 'v0.23.15' <--- this is the first commit AFTER the tag 'v0.23.15' and does not have any tag
https://github.com/MusicPlayerDaemon/MPD/tree/5f54a8e94edb95b4652af000da168ce238b2a96d
tag v0.23.15 <--- I am building this!
https://github.com/MusicPlayerDaemon/MPD/tree/b8bfc986181a6824b7ee9c4f2c475369ca8ac931
If you check the differences, you will see that the changes needed to support mixramp_analyzer are not included in 'v0.23.15'.
Unless I am missing something.
Can you confirm?

Hello, I am sorry, but the feature is not part of a release yet. From what I understand, it will not even be included in 0.23.x.
The changes you request are in a separate branch, of course there is an error now if you try to enable the feature, so I believe it's pointless to merge it.
We need to wait for a release that includes the feature.

No problem. Let's wait for the official introduction of the feature in the next mpd release.


Harden MRTK inspectors / Move MRTK addition to scene to utility class

Overview
This PR combines #4467 & #4435 and addresses comments from both.

/azp run mrtk_pr

/azp run mrtk_docs

/azp run mrtk_docs

/azp run mrtk_pr

/azp run mrtk_docs

/azp run mrtk_pr

This PR combines #4467 & #4435 and addresses comments from both.

@railboy should those PRs be closed now, then?

@keveleigh Yup they can be closed.


less restrictive checking for xfs quota stats

It seems that the xfs quota stats provided in /proc/fs/xfs/stats can
provide more than 8 values, so instead of erroring, just ignore the
extra fields.

Test coverage? Otherwise there's no guarantee this won't break.


[TEST] Network simulator and some initial tests

Abstract
The aim of this PR is improving the unit test coverage by adding a mock to the network class.
How to use it in unit tests:

Mock the file vi.mock('../../../scripts/network.js')
Create a bunch of wallets with the functions setUpLegacyMainnetWallet(). Those wallets have a non-zero balance and are synced.
After creating txs with any wallet call getNetwork().sendTransaction(txHex)
Once enough txs are added mint a new block with getNetwork().mintBlock()
Trigger download of the block for all wallets in the test by calling the global.js function refreshChainData();

Notice that calling refreshChainData()  will emit a signal that is received by wallets as
 getEventEmitter().on('new-block', async (block) => {
            if (this.#isSynced) {
                await this.getLatestBlocks(block);
                getEventEmitter().emit('new-tx');
            }
        });

which makes tests reliable, in the sense that the normal sync flow is followed, with the only difference that instead of blockbook, blocks are provided by the mock class.
I have also added a couple of tests:

Create a bunch of txs between a HD and a Legacy wallets and verify that txs are received and balance is updated as expected
Verify that HD wallets are aware of at least MAX_ACCOUNT_GAP addresses after the last used

Testing
Tests working as expected

new tests will fail until #363 is merged (which will solve the sync bug)

These looks good, my only nit is that these are no longer unit tests, so just move them in a different folder

done


Feature Request: Add linting to template/contracts/

Describe the solution you'd like
Took a look at linters for solidity:
solhint
solhint is a linter with rules. Similar control mechanisms to eslint, supporting disabling rules via comments and allow you to create new rules.
solhint provides additional styling rules that augments forge fmt or prettier-solidity-plugin. Pretty neat.
ethlint
Project appears to be inactive

ethlint is out as it is inactive.
For solhint, we need to add two files: .solhint.json and .solhintignore.
In .solhint.json, we need to decide which rules sets to follow. solhint:recommended option looks good but would like to hear from more experienced solidity developers on which rule sets to enable / how their experience with solhint has been.
In .solhintignore, lib should be added as we don't want to lint third party imports.
Been using solhint for a couple days and it's been decent so far.
Describe alternatives you've considered.
No response

Yeah besides forge fmt, solhint is the only other linter I've seen used before. forge fmt does have its own section in the config file that we could also set to get more use out of it. Regarding which rules to use for solhint, the recommended Best Practices and Style Guide Rules sections look good. However, the Security Rules look pretty out of date / not of high fidelity to be worth enabling.

Additional suggestion for tests: Use Branching Tree Technique for Solidity tests, through bulloak (https://github.com/coinbase/build-onchain-apps/issues/523)


Fix comment in YamlCreate

This PR moves the comment to the first line of the script, change ".yaml" to upper case, and remove the redundant "file" word.
Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Microsoft Reviewers: Open in CodeFlow

I'm not very familiar with Diagnostics.CodeAnalysis.SuppressMessageAttribute, so I'm not sure if it's recommended above or below the Get-Help comments. I found some documentation that suggests it should be above the param block, and this move keeps it above the param block here.


Multiple monitor/screen fade out to black (or any color settings)

Description of the new feature / enhancement
To have a way for people who uses more than one screen or even for single screen users, to mute its monitor content by appling a black overlay color on top of the screen (every app, game, etc.).
Scenario when this would be used?
This is a very useful feature for multiple monitor users, lets say you have a TV attached to your system, sometimes you want to watch series in focused mode (happens a lot with me), then with just a simple click of a button you got every screen of your choice blank out (to any color, normally as black).
Another use case is to blank out the screens when you are controlling your system in a remote way, lets say you are going to sleep and don't want to get up to shutdown the computer or the screens for any reason, then you just connect your phone as a remote user to your windows system and on the tray icons blank the screens, this is something i particularly do with "Multiscreen Blank" already.
Supporting information
This feature already exists outside of microsoft original software, but would be nice to see it in windows natively.
The software which does it... that i described is known by its name as: "Multiscreen Blank"
Found at this address: http://multiscreenblank.nookkin.com/download.ndoc

/dup https://github.com/microsoft/PowerToys/issues/13035


Translate the System Design

The system design is documented in docs/system_design.md.
It needs to be translated into German and French.

/pilot write the French version into docs/system_design_fr.md and create a new issue for the German one

/pilot Sum up this ticket


NEID 1.4.1 & asielib - cofhapi:tileentity not found but available as part of cofhcore

NEID 1.4.1 causes asielib issues with cofhapi:tileentity
"[21:38:44] [Client thread/ERROR] [FML/]: The mod asielib (asielib) requires mod versions [CoFHAPI|tileentity@[1.7.10R1.0.0,)] to be available
[21:38:44] [Client thread/DEBUG] [FML/]: Mod sorting data"
cofhapi:tileentity is part of cofhapi which is part of cofhcore.
the latest official cofhcore is CoFHCore-[1.7.10]3.0.3-303.
All newer builds than this one are alpha builds that are not recommended for public use by the cofh team.
This does not happen with NEID 1.4.0

Here is more of the client-latest.log regarding this issue
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in NuclearCraft
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in Magic Resistance Mod
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in emashercore
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in emasherdefense
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in gascraft
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in eng_toolbox
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in SonarCore
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in progressiveautomation
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in EnderTech
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in SolarExpansion
...
[21:38:43] [Client thread/DEBUG] [FML/]: Found API cofh.api.tileentity (owned by CoFHAPI providing CoFHAPI|tileentity) embedded in redgear_core
...
[21:38:43] [Client thread/TRACE] [FML/]: Removing upstream parent CoFHLib from APIContainer{CoFHAPI|tileentity:1.7.2R1.0.0}
[21:38:43] [Client thread/TRACE] [FML/]: Removing upstream parent CoFHCore from APIContainer{CoFHAPI|tileentity:1.7.2R1.0.0}
[21:38:43] [Client thread/DEBUG] [FML/]: Creating API container dummy for API CoFHAPI|tileentity: owner: CoFHAPI, dependents: [hpt, EnderIO, RouterReborn, NuclearCraft, Magic Resistance Mod, emashercore, emasherdefense, gascraft, eng_toolbox, SonarCore, progressiveautomation, EnderTech, SolarExpansion, redgear_core]
...

full log pls...


LBRY update not working in Windows

The Issue
When prompted to upgrade in Windows, the installer does not run after download.
Steps to reproduce

run v11.6 and get prompt for upgrade
Download update
Run update

Expected behaviour
Installation file is executed or directory opens
Actual behaviour
Nothing
Debugging -
Found 2 issues, 1) the LBRY file name for Windows is not consistent with what is downloaded, fixed here:
case 'win32':
return LBRY.${version}.exe;
The original has return LBRY.Setup.${version}.exe;

the upgradeDownloadPath variable points to the upgrade directory, not the file itself (not sure if the goal was to open the download dir, or open the exe). I tried pointing it to the file directly, but still, nothing is kicked off by:
function upgrade(event, installerPath) {
app.on('quit', () => {
console.log('Launching upgrade installer at', installerPath);
// This gets triggered called after all other quit-related events, so
// we'll only get here if we're fully prepared and quitting for real.
openItem(installerPath);
});

I was able to get a console.print in doStartUpgrade()  function (could not get console to print from main - so I'm assumming that the parameter is passed correctly):
debug with path: Launching upgrade installer at C:\Users\thoma\AppData\Local\Temp\CWx1v1
debug with file: C:\Users\thoma\AppData\Local\Temp\CWx1v1\LBRY_0.11.7.exe
Does this help:
shell
The shell api is an electron only api that you can use to shell execute a file at a given path, which will use the OS default application to open the file.
const {shell} = require('electron');
// Open a local file in the default app
shell.openItem('c:\example.txt');
System Configuration

LBRY Daemon version:
LBRY App version: .11.6
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

I'm looking into this. The goal was to run the executable, but I believe openItem should work with both executables and directories (dirs open in Explorer). So it's weird that nothing at all is happening.
Upgrades were working on all three platforms until recently, so I would think this is a Redux issue, but you manually hacked in the full installer path and still nothing happened, so that's interesting. Will keep you posted.

Like I said, I could not get the debug to work on the main.js side, that log was coming from bundle.js. So still not sure it's being passed correctly.  I'm a newbie, still learning :)
Thanks for looking into it!

@tzarebczan FYI, console statements from app/main.js will print to the actual console you use to launch the app.

reporting from slack:
@zentralsonne says

Auto-update does not work
After downloading the update and re-opening the application, the update message appears again and a cycle is obtained.
Win 10.  Autoupdate from 0.11.7 to 0.11.8
I'll try to download manually from git
Manual update to 0.11.8 works normal.

Yup, don't think this was worked on. Separate issue than the one mentioned in the change log.

Fixed in #176. Thanks for the heads up.

I think @ZentralSonne's problem is totally unrelated (and possibly fixed already? That kind of thing can happen if the wrong version is up on lbry.io). If it's still happening, we should make a new issue.

.11.9 is telling me I need to update - but is already current - Windows 10

I'm on same version and Windows too, not seeing an update message. Restarted the app too.

I messed with my install_id - related?

Same caching issue as before? Or try full uninstall / reinstall?

Porblem with manuall update.
Installed https://github.com/lbryio/lbry-app/releases/tag/v0.12.0rc3
this version.
But in Settings -HELP- About shows  old version

@polminer above was just fixed, version reporting was wrong in RCs.
I don't think upgrading is currently broken, so I'm going to close this. Re-open if I'm wrong.


Resolve Validators Conflict

update the requirement.txt to reflect the latest validators version
remove the deprecated attribute require_tld in validators.url() for portal/views/client.py
remove the deprecated test require_tld for test_auth.py

@waynelai1228 can you evaluate the remaining require_tld in portal/views/client.py?
@pbugni There are two separate validators in portal/views/client.py.
The one causing the problems is validators.url (bumped to 0.14.0)
The other validators is from WTForm, which still has require_tld field.


CASMPET-5420: Move nexus3 into container images

Summary and Scope
This adds the nexus3 container image into container-images repo from nexus3 repo. This adds a docker file that was used in the nexus3 repo as well as adds in the kar file needed to run nexus and script. It takes all the parts from nexus3 repo and moves it to container-images repo. This also creates the workflow and directory for nexus3 version 3.38.0 which is the latest from upstream. This still has vulnerabilities in it but it takes a big chunk out from 3.25.0.
Issues and Related PRs

Resolves CASMPET-5420
Resolves CASMPET-5425

Testing
Tested on:

Virtual Shasta

Test description:
I ran the same tests I did checking for 3.38.0 to work in the nexus3 repo including installs and upgrades.
Risks and Mitigations
There are still a few high and critical vulnerabilities in nexus3 3.38.0 that can not be patched because they come from upstream image of nexus3.
Pull Request Checklist

[ ] Version number(s) incremented, if applicable
[ ] Copyrights updated
[ ] License file intact
[ ] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

Looks good, just a couple of questions for my own understanding, license header needs to be fixed.