text:
fix(curriculum): changed challenge test text to use the word should for Responsive Web Design

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

This PR has been on my to-do list for a while.  After we made the change to no longer user the assert message arguments anymore and only use the text to display to the console for failing tests, I noticed several inconsistencies in how the text messages were written.  Most use a should or should not, but others did not and some made it confusing to the camper whether or not they had passed or failed based on descriptions like: "Your code has an h1 element", when it really should have stated "Your code should have an h1 element.
When I queried the existing English challenges I found 763 text strings in 319 challenges that were not using the should or should not verbiage.  Currently, I have only fixed 62 text strings in 27 challenges.  Before I spend any more time on this, I want to first make sure this is a worthy cause.  I personally believe it makes reading through all the challenges more consistent which should allow users to quickly understand what the test expects.
EDIT: This PR only deals with the Responsive Web Design section.  Other PRs will fix the other sections.

Messages like "Your code has an h1 element" are clearly awful, since they imply the opposite of what is actually required.  I'm absolutely in favour of changing those.
Going from "Make sure your CSS rule is properly formatted with both opening and closing curly brackets" to "Your CSS rule should be properly formatted with both opening and closing curly brackets" seems, to me, to be a less critical change.  Both convey what actions need to be taken.  To be clear: I think it's an improvement, but I'd accept both versions.
So, my opinion is that changing the first type is definitely a worthy cause and changing the second type is still worth doing, but of lower priority.

Yea, I like them better how you suggested @RandellDawson - making them consistent throughout all of the challenges and more understandable would speed things up for users I think - I do recall having to read some of the test text a couple times when I was going through some of the lessons to figure it out. And it sounds like it's something you want to do, so I would say go for it.

I agree with what Oliver has to say

@ojeytonwilliams , @moT01, @thecodingaviator This PR is ready for review.  Because there are so many challenge files which will ultimately need to be reviewed, this PR is only for the Responsive Web Design section.  I will create separate PRs for the other sections over the next few days.

@moT01 Thanks for the review.  Sorry about the typos and strange wording I used on some of them.  I have committed all of your suggestions.

@thecodingaviator I committed your suggested change.

@RandellDawson do you want to wait for Kris' and Oliver's reviews too?

@thecodingaviator I think two reviewers is enough.  I tagged the others just to get attention to the PR.

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝

Sorry for being late to this.  I went through it anyway, but couldn't find any problems.  Looks great!

authors: RandellDawson moT01 ojeytonwilliams thecodingaviator


text:
Added cypress for e2e tests

Looking at https://github.com/freeCodeCamp/learn/issues/294, I noticed you already had travis and jest setup, so here is Cypress for e2e/integrations.
I'm happy to add more tests as well.

Hi @TheHollidayInn
Thanks a lot for the PR. We are super interested to get this in. I am linking the direction this is headed. However we are taking all the code from this repo move to the main repo.
Kindly bear with us while we get back to you with the next steps.
Thanks and happy coding.

Sounds good! Thanks for letting me know

source: gharchive/pull-request

authors: TheHollidayInn raisedadead

repo: freeCodeCamp/learn

license_type: permissive

license_source: github-api


text:
request for an API key

Hey, i have posted in freecodecamp gitter group but haven't got a response. I am wondering if i could receive an API which i will use for my exercise in creating a leader camp board with extended functionalities.  My private email is shawn.pan2330@gmail.com. Would appreciate your reply.
Thanks!

Closing as stale.

source: gharchive/issue

authors: ojongerius shawnpanda

repo: freeCodeCamp/open-api


text:
Add ChiselEnum to BundleLiterals

Related issue: #1214

Type of change: other enhancement

Impact: API modification

Development Phase: implementation
Release Notes
This PR enables the use of EnumType in BundleLiterals. For example, the following code should work:
object ENUM extends ChiselEnum {
  val a, b, c = Value
}
class t extends Bundle {
  val a = ENUM()
}
class tIO extends Bundle {
  val a = Output(new t())
}
class TestModule extends Module {
  val io = IO(new tIO())

  io.a := (new t).Lit(_.a -> ENUM.b)
}

Can one of the admins verify this patch?

ok to test

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

@ducky64 should this be backported to 1.2.x?

@jackkoenig I don't see why not.

@ducky64 sorry for blocking, I have signed the CLA, please proceed, thanks

authors: claassistantio ducky64 jackkoenig ucb-bar-jenkins ucbjrl zhuanhao-wu


text:
Adds a link to the Chris Celio style guide

Type of change: documentation

Impact: no functional change
Release Notes

* What other style suggestions do people have?

I think a lot of the variable naming comes down to "programmers" vs "hardware designers", i.e., do you name things like people would in Scala or as it is common in Verilog/VHDL?
Afaik Scala code normally does not use snake_case for example.

This is just a question of whether to link to Chris's document
His document is top search result on google.
There are really not any good alternatives
Chris is willing to accept PR's that improve it, or we could fork his and maintain our own
People are asking for style guide on SO and elsewhere.
I think this is worth merging now while noting that more work should be done

I'd prefer not to advocate a style guide that doesn't yet have consensus across the community, just so we can tick a box saying "we have this". I think releasing (and more importantly, expecting people to follow) a style guide that is going to see significant flux right after is not a great idea, since the whole point of a style guide is stability and consistency.
Like, this is a starting point to discuss on, and we can prioritize that discussion, but I think this is something that needs to be done as right as we can.
Also, wrt this being the top result on Google: the chisel2 cheatsheet also used to be the top result on Google, well into the chisel3 era. If this document truly reflects the currently dominant style (if one even exists) and best practices, then sure, but I'm not sure if that's the case.

* What other style suggestions do people have?

I think a lot of the variable naming comes down to "programmers" vs "hardware designers", i.e., do you name things like people would in Scala or as it is common in Verilog/VHDL?
Afaik Scala code normally does not use snake_case for example.

Chisel is for describing hardware designs; although the host language style guide can provide some guidance, users shouldn't be afraid to write code in a manner that improves understandability.
As such, though perhaps it betrays my C/C++ and Verilog origins, I have found camelCase does a poor job of providing visual distinctions between prefixes and suffixes which are commonly required for describing hardware.
In particular, this shows up in hardware's need to describe temporal behaviors within the code: across pipeline stages, the differing update semantics of Reg vs Wire, multi-cycle interface contracts of some I/Os, and more.
If you are lucky, you can write your RTL in a functional manner that lines up closely with Scala style. But for other modules, a more structural style with explicit pipelining lends itself closer to more C/Verilog-like naming conventions. Skimming through rocket-chip, I've found it changes style as needed depending upon how best to describe the Module in question.

I've gone back and forth on snake vs camel throughout my Chisel career and see merits to both. To add to @ccelio's snake_case pros, having snake_case for hardware values and camelCase for software values/functions can aid in differentiating between the two. OTOH, one relatively big pro for camelCase is that it is much easier to correlate emitted bundle hierarchies with their source scala if you can reliably use _ as a hierarchy delimiter (e.g. someReally_longNamed_bundleWith_lotsOf_hierarchy vs some_really_long_named_bundle_with_lots_of_hierarchy).

Dev meeting conclusion: we'd prefer to just point to the Scala style guide. If anyone feels differently we can re-open.

authors: ccelio chick ducky64 ekiwi jwright6323 seldridge


text:
(RESTCONF+YANG) PUT Request with invalid JSON modifies state

When making CRUD request (PUT) to RESTCONF with invalid JSON (missing bracket for ex), request is rejected with proper error message but state is also changed. I found core of a problem, but don't have proper solution.
IMO problem lays between these 3 functions:
https://github.com/freeconf/yang/blob/fe20e073cbc56867505f15dce50379d88296b8f3/nodeutil/json_rdr.go#L21
func ReadJSONIO(rdr io.Reader) node.Node {
	jrdr := &JSONRdr{In: rdr}
	return jrdr.Node()
}

Here function returns node.Node (which can be node.ErrorNode in case of read errors) without separate error value.
This cause code in restconf:
https://github.com/freeconf/restconf/blob/72cc856c177bf129d9c55bb2978367379209b4c6/browser_handler.go#L179-L184
		case "PUT":
			// CRUD - Remove and replace
			var input node.Node
			input, err = requestNode(r)
			if err != nil {
				handleErr(compliance, err, r, w)
				return
			}
			err = target.ReplaceFrom(input)

to not to check error and pass erroneous node.Noderight to yanglibrary.
Here, ReplaceFrom first deletes previous version of element before trying to apply new version which is an just error.
https://github.com/freeconf/yang/blob/fe20e073cbc56867505f15dce50379d88296b8f3/node/selection.go#L470
func (sel *Selection) ReplaceFrom(fromNode Node) error {
	parent := sel.parent
	if err := sel.Delete(); err != nil {
		return err
	}
	return parent.InsertFrom(fromNode)
}

The error is returned but it's too late, data is already gone.
Like I said, I've done investigation :) but I don't know how to properly fix this issue to keep code consistency.
Main question is: what is better, to return error from ReadJSONIO() or to check for node.ErrorNode in browser_handler.go?

Main root of a problem is solved in #101 PR, but IMO, ReplaceFrom function should also be refactored because data still can be lost of fromNode will be correct JSON but with different structure than expected.

Sorry, I have to reopen this issue.
I'd like to fix the problem I mentioned in https://github.com/freeconf/yang/issues/100#issuecomment-1900640027

data still can be lost if fromNode will be correct JSON but with different structure than expected.

I have time to do this but I need an advice how.
Core of a problem is in this function:
https://github.com/freeconf/yang/blob/fe20e073cbc56867505f15dce50379d88296b8f3/node/selection.go#L470
It modifies tree in 2 steps: sel.Delete() and parent.InsertFrom(), each is a separate action wrapped in BeginEdit-EndEdit, so it is even harder to detect issue with payload from application code.
I thought that we can copy selection before delete operation so we can restore previous state from it in case of insert errors, but such approach can be expensive due to copying. If you have any proposals about how to refactor this function, please, share them and I can try to prepare PR.
Many thanks.

As it exists today FreeCONF's operations happen on the live objects.  I think to achieve what you are looking for freeconf should support "data stores" that act as sandbox to validate requests and only after no errors are found, then reapply the request to the live objects.
But yeah, this validation can be expensive depending on how bug the request scope is but in your case, you delete everything first, so not really a "copy" of the original but rather a start w/empty and apply input twice, once to sandbox once to live objects.

authors: dhubler sibuk-harabudjasim

repo: freeconf/yang


text:
improvement: adding the disabled text color, fixing inverted text colors

What:
This PR adds the disabled state to the Text component, in alignment with the design for wave. It also fixes colors when inverted (for weak and disabled texts) also in alignment with the design.

Why:
This is in regard to SUP-11112

How:

Add a new disabled property to the Text component
Fix the colors for inverted state
Add examples to the documentation

Media:

I don't have any concerns with the implementation, nonetheless, I feel a bit lost with the need and if this should be something that designers actually do. Feels odd to talk about "disabled text". Besides, I will encourage you to bring these topics to further discussion with designers and the dev community at Github.
From the link, you refer to I just see you as a reporter outlining a need, but is indeed this valid? (sorry for the doubts I just want to make sure designers and dev are align) @rafael-sepeda @agonzalezUX can you folks help here to answer the following question:
Do designer have the concept of "disabled" text?

Hi @rafael-sepeda, with the color codes you mentioned, this is how it looks. Does this look correct? If so I can update the PR with these new ones

@duranmla , @lloydaf
for the new setup in Figma we created this tokens:
"text": {
    "primary": "$colors.brand.authenticBlue.900",
    "primary-inverted": "$colors.brand.white",
    "secondary": "$colors.brand.authenticBlue.550",
    "secondary-inverted": "$colors.brand.authenticBlue.50",
    "disabled": "$colors.brand.authenticBlue.350",
    "disabled-inverted": "$colors.brand.authenticBlue.200",
    "link": "$colors.brand.actionBlue.900",
    "link-inverted": "$colors.brand.white",
    "danger": "$colors.brand.negativeOrange.900",
    "success": "$colors.brand.positiveGreen.900",
    "warning": "$colors.brand.attentionYellow.900"
},

We where using before the weak but now renamed it to secondary

@rafael-sepeda Are we using the authenticBlue.50 for secondary-inverted now? It used to be the 200, right? I'm not really sure if the contrast between primary and secondary in the inverted colors will match the default colors in this new setup. Is there a reason why we changed it?

@agonzalezUX Could you check the colors?

Hi guys, the color codes @rafael-sepeda shared with you are correct
Regarding Vini's comment, he is right, the secondary-inverted should not be authenticBlue.50, there is a mistake and it should be authenticBlue.550
Regarding the suggestion @viniciusleitao is raising regarding the usage of authenticBlue.200 for the secondary inverted, I have to say that in wave we never differentiated between secondary default and inverted as both font color used the same value. However I am open to have this discussion between product designers.
So, in conclusion we should use:
"text": {
    "primary": "$colors.brand.authenticBlue.900",
    "primary-inverted": "$colors.brand.white",
    "secondary": "$colors.brand.authenticBlue.550",
    "secondary-inverted": "$colors.brand.authenticBlue.550",
    "disabled": "$colors.brand.authenticBlue.350",
    "disabled-inverted": "$colors.brand.authenticBlue.200",
    "link": "$colors.brand.actionBlue.900",
    "link-inverted": "$colors.brand.white",
    "danger": "$colors.brand.negativeOrange.900",
    "success": "$colors.brand.positiveGreen.900",
    "warning": "$colors.brand.attentionYellow.900"
},

This is how it looks, @agonzalezUX, updating the PR with these values

For me "secondary-inverted" and "disabled-inverted" colors are inverted. With the current implementation, Disabled looks brighter than Weak and it should be the other way around.

Sorry guys I think @viniciusleitao is right. Default should go from darker to lighter and inverted form lighter to darker. Sorry for the confusion 🙏🏼
please @viniciusleitao and @rafael-sepeda double check those are the correct values:
"text": {
    "primary": "$colors.brand.authenticBlue.900",
    "primary-inverted": "$colors.brand.white",
    "secondary": "$colors.brand.authenticBlue.550",
    "secondary-inverted": "$colors.brand.authenticBlue.350",
    "disabled": "$colors.brand.authenticBlue.350",
    "disabled-inverted": "$colors.brand.authenticBlue.550",
    "link": "$colors.brand.actionBlue.900",
    "link-inverted": "$colors.brand.white",
    "danger": "$colors.brand.negativeOrange.900",
    "success": "$colors.brand.positiveGreen.900",
    "warning": "$colors.brand.attentionYellow.900"
},

As we have ended up with the initial values in the PR, I am removing all the commits in between to make our lives easier :)

@rafael-sepeda @viniciusleitao @agonzalezUX I recommend adding some guidance on when to use this type of text. It definitely fails to pass any a11y contrast checks. This is one of the key elements to make the page perceivable by everybody.
I think it is important to put to the document the following info:

WCAG-2.1 recommendation is to keep enough color contrast for all the elements except components in the inactive/disabled state and pure decoration texts.
Official contrast checker and recommendation to use at least AA level of contrast
Figma users can install Constrast plugin or A11y - Color Contrast Checker

It definitely fails to pass any a11y contrast checks

@nlopin just to clarify, the only color combination that does not pass the contrast check is the disabled one. Checking other design systems I realized this is some kind of pattern on disabled states.

Material
Atalassian
Carbon

@viniciusleitao yes, there are no contrast requirements for the disabled states

@lloydaf , @nlopin , @agonzalezUX , @viniciusleitao
Thanks for pushing this. I hope that soon we will be able to automate the color sync between Figma and wave. We discussed already that we can start with semantic colors and see how we can consume the color tokens definition in JSON  in code and extract it so we can import it back to Figma.

thanks @duranmla ❤
What are the next steps ideally? Should I merge after I get enough approvals or do you merge on behalf of me? Both are fine, as long as we merge this before #97. Right now it says

Only those with write access to this repository can merge pull requests.

One of the code owners will merge to main and the new version will be published automatically. I think we want one approval from the design team

@nlopin what documentation page would you want to modify/add and what specific information would you like represented in the docs? I can try and add that if you want.

authors: agonzalezUX duranmla lloydaf nlopin rafael-sepeda viniciusleitao

repo: freenowtech/wave


text:
Can restore it?

If delete the scan code and don't know 16 secret key,I can't login.How to restore it?

You cannot. Contact the admin of the site to disable 2FA for you.

authors: JakeWoki SvetlinZarev

repo: freeotp/freeotp-android

license_source: bigquery


text:
Feil: Feilmelding wrapper under ikon hvis teksten er lang/container er smal

Fra @Slaine2

Feilmeldingen på den andre linjen skal være på linje med den første linjen og ikke starte med ikonet.

Steg for å gjenskape

Gå til https://jokul.fremtind.no/komponenter/textinput/
Klikk på Med feil

Forventet oppførsel
"hvordan du finner riktig areal" alignet med "Du må fylle ut boarealet".

Jeg tror ikke jeg synes dette er bedre @Slaine2 🤷 Before/after video:
https://github.com/fremtind/jokul/assets/1223410/d102c715-5013-41c4-9797-8cdee0f31eb9

repo: fremtind/jokul

license: MIT


text:
Release/2.0

#7 NestJS v4

Coverage remained the same at 95.522% when pulling 0d1fd3183d9dea66554e90abd96215fe0438b9c1 on release/2.0 into 673a708ec3bc48a565fa25c8d5abac218ee717e3 on master.

authors: TobyColeman coveralls

license: mit


text:
Support HTTP request headers for datapackage exporting

@BobHarper1 has wrote:

I get an error whenever I try this with a valid url (that works through my browser), even with the example given on the blog.
urllib2.HTTPError: HTTP Error 404: Not Found
Having had a bit of a search, I would need to set the User-Agent header in the HTTP request urllib2.Request. Any idea if I could do that in datapackage.push_datapackage?
A couple more comments about what's happening (though my ability to test different datapackage urls is limited by not knowing about more).

It doesn't seem to be affected by the url scheme, I've tried http:// or https:// and both have brought about the same error
If I make a basic urllib2 request on the url as tested with datapackage.push_datapackage() I'm able to get the response back no problem

@BobHarper1
In coming months we will update export/import functionality. Considering to add request headers to export function (push_datapackage for now).

Thanks!

MERGED
https://github.com/frictionlessdata/datapackage-py/issues/132
Current push/pull_datapackage API will not be fixed. There will be an updated API to solve this problem. Merging this issue to general re-implementation tracker.

repo: frictionlessdata/datapackage-py


text:
Enhancement: Update friendsofphp/php-cs-fixer

This pull request

[x] updates friendsofphp/php-cs-fixer
[ ] runs make coding-standards

💁♂ For reference, see https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/compare/v3.16.0...v3.40.0.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1967123) 79.83% compared to head (79b2971) 79.83%.

:exclamation: Current head 79b2971 differs from pull request most recent head 5955039. Consider uploading reports for the commit 5955039 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##               main     #306   +/-   ##
=========================================
  Coverage     79.83%   79.83%
  Complexity      749      749
=========================================
  Files            55       55
  Lines          2603     2603
=========================================
  Hits           2078     2078
  Misses          525      525

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter localheinz

repo: friendsoftwig/twigcs


text:
Create condition for an entity

Story statement
As a Fraud Administrator,
I want to be able to add a new condition for an entity
So that the system is able to block or override a transaction event based on the evaluation of conditions against one of the transaction event attributes AND
So that the system can exert operational control over evaluations based on the outcome of business processes and prior evaluations
Description / Overview
New functionality is being added to the Tazama system to be able to block or allow a transaction event based on the evaluation of conditions against one of the transaction event attributes. The purpose of this user story is to provide a feature to allow a user to create a condition for an entity via an Admin API.
See epic: https://github.com/frmscoe/tazama-project/issues/12
Sequence diagram
sequenceDiagram
  participant clientsystem as Client System
  participant tmsapi as Admin API
  participant cache as Cache
  participant db as Database

  clientsystem->>tmsapi: setCondition()
  tmsapi->>db: setCondition()
  db->>tmsapi: writeOK(recordId)
  tmsapi->>cache: setCondition()
  cache->>tmsapi: writeOK()
  tmsapi->>clientsystem: writeOK(recordId)

Acceptance criteria

Create an administrative API that has access to the Tazama database

recommended /v1/admin/event-flow-control/entity

Create REST (POST) endpoint to allow a client system to add a condition in the Tazama graph database for an entity
If the system is unable to write to the database, retry 5 times, if still unable to write, return error.

Message format
{
    "evtTp": [
        "pacs.008.01.10",
        "pacs.002.01.11"
    ],
    "condTp": "non-overridable-block",
    "prsptv": "both",
    "incptnDtTm": "2024-01-01T24:00:00.999Z",
    "xprtnDtTm": "2024-03-03T24:00:00.999Z",
    "condRsn": "R001",
    "ntty": {
        "id": "+27730975224",
        "schmeNm": {
            "prtry": "MSISDN"
        }
    },
    "forceCret": true,
    "usr": "bob"
}

Functional requirements

The event type evtTp is mandatory and must be an array containing one or more of the current list of values pacs.002.01.11, pacs.008.01.11, pain.001.01.11, pain.013.01.11, OR all. The event type evtTp must be validated in the API via fastify ajv.
The condition type condTp is mandatory and must be one of non-overridable-block or overridable-block or override and must be validated in the API via fastify ajv.
The block perspective prsptv is mandatory and must be one of creditor, debtor or both and must be validated in the API via fastify ajv.
Inception date incptnDtTm is optional for all condition types

If incptnDtTm date is not provided, it must default to NOW
If incptnDtTm date is provided, it must be greater than NOW

Expiration date xprtnDtTm is mandatory for override conditions

xprtnDtTm date must be after incptnDtTm

Expiration date xprtnDtTm is optional for non-overridable-block or overridable-block conditions

If xprtnDtTm is not provided (omitted or null), it must be omitted in the database.
If provided,

xprtnDtTm date must be after incptnDtTm

Reason code condRsn is mandatory.
The entity identifier ntty object and its contents are mandatory. The structure of the entity identifier is based on that of an element of a debtor or creditor entity in an ISO20022 message. Ref https://github.com/frmscoe/tms-service/issues/154.

If the entity node exists, create the condition and edge.
If the entity node does not exist in the database and forceCret is true, create the entity in the database, create condition and edge.
If the entity node does not exist in the database and forceCret is false or omitted, fail and respond with an error.

Create an edge that describes whether the condition is for a debtor or creditor prsptv (or both, if specified) as governed_as_debtor_by or governed_as_creditor_by
User usr is mandatory (for audit purposes): if null, return an error message.
Create date creDtTm must be set to NOW() (javascript function) by the API on receipt and processing of the request.

Complete Success Criteria

The condition is stored in a new conditions collection in the pseudonyms database (as part of the history graph) and available for future retrieval
If successfully written to the DB, the condition is also stored in Valkey (https://valkey.io/) cache for high speed retrieval (i.e. write-aside caching). Also consider gremlin tinkerpop for in memory graph option
The document for the new condition must be structured as follows (sample):{
  "condTp": "non-overridable-block",
  "incptnDtTm": "2024-01-01T24:00:00.999Z",
  "xprtnDtTm": "2024-03-03T24:00:00.999Z",
  "condRsn": "R001",
  "usr": {bob},
  "creDtTm": "2024-01-01T24:00:00.999Z"
}

The condition is assigned a unique identifier condId by the database when the document is created.
The condition type condTp will be either non-overridable-block or overridable-block or override
The condition contains an inception date incptnDtTm
The condition may contain an expiration date xprtnDtTm (if provided). If no xprtnDtTm is provided, this attribute is omitted
The condition contains a condRsn reason code
The condition contains the usr that created it via the API
The create date creDtTm is set to the ISO8601 timestamp with 0 (zero) off-set for the time at which the request was received and processed
The entity to which the condition applies is linked to the condition with one or two edges, depending on the value of the prsptv attribute in the payload:

For prsptv = "both", create both of the following edges, otherwise just create the one indicated.
For prsptv = "debtor", create an edge from the entity to the condition called governed_as_debtor_by.
For prsptv = "creditor", create an edge from the entity to the condition called governed_as_creditor_by.

The document for the new edge(s) must be structured as follows:{
  "evtTp": ["pacs.008.01.10", "pacs.002.01.11"],
  "incptnDtTm": "2024-01-01T24:00:00.999Z",
  "xprtnDtTm": "2024-03-03T24:00:00.999Z"
}

Event types are defined by the evtTp attribute or all event types are defined by evtTp = ["all"]
The edge contains an inception date incptnDtTm
The edge contains an expiration date xprtnDtTm (only if provided)
If the entity node exists, create the condition and edge.
If the entity node does not already exist in the database and forceCret is true, create the entity in entities collection in the pseudonyms DB

If forceCret is false, return an error to indicate the entity required does not exist in the database

If there are active conditions i.e. conditions that have not yet expired (i.e. it has no expiry date or the expiry date is after now), then return a warning conditions already exist for the entity and return all active conditions and edges (Using the retrieve condition function with the active parameter)

Success response
200 OK
Error responses
4xx
5xx

This issue is blocked by the central library PR which is waiting for the documentation merge
central lib PR: https://github.com/frmscoe/frms-coe-lib/pull/152

coe-lib documentation was updated https://github.com/frmscoe/frms-coe-lib/pull/153

condId should be the database _key

authors: Sandy-at-Tazama cshezi

repo: frmscoe/admin-service


text:
Different C compilers for Nim output

As C++ is tested with different compilers, maybe Nim's tuned implementations could be tested with different C compilers too.

Are there more than one complete Nim compiler? C++ is tested on the most popular open C++ compilers. Those are mature and popular on their respective platforms. That is, I don't want to turn this benchmark into an endless list of tons of variations. BTW, you can always just test whatever alternative solutions and configurations and compare them by the relative slowdown to get an idea of how fast your solution or configuration is.

Oh, I just got what you meant! Well, that will only show the difference between C compilers... That is quite orthogonal to Nim itself. I imagine someone interested specifically in Nim would find it informative to see a separate blog post or whatever comparing tons of different GCs and C compilers out there.

authors: frol hlaaftana

repo: frol/completely-unscientific-benchmarks


text:
Improve Haskell version in both readability and performance.

The pattern "type FooCell = Maybe Foo; data Foo = ..." is usually
avoided in Haskell with just using recursive data type. Also strict
tuples and unboxed data is rarely used in practice.
Unfortunately still using Strict language. Could not reach quite the
same performance without it. Requires some actual performance analysis.

@FranklinChen @314eter Could you, please, provide any comments to this PR? I am completely incompetent in Haskell.

@Jaak Thank you for the improvements!
@FranklinChen Thank you for your thorough review!

Thank you for review!
Yes, that's absolutely true that strictness annotations and UNBOX are idiomatic Haskell. I was merely a bit set back and wondered if it is possible to achieve similar levels of performance without those (and unboxed tuples).
Generally in benchmark shootouts all readability is optimized away in favour of performance. I enjoyed the fact that this code tries to be in the spirit of what a programmer would actually write if performance were not of utmost importance.

I have just updated the scoreboards!

authors: Jaak frol


text:
Warning in HTML2React should be fixed

child of https://github.com/wp-pwa/saturn-theme/issues/48

:tada: This issue has been resolved in version 0.7.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: frontibotito orballo

repo: frontity/saturn-theme


text:
Update h2r version

Fixes https://github.com/frontity/frontity/issues/112

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

authors: DAreRodz frontibotito