Fresh Angular 17 cannot be configured with "@angular-devkit/build-angular:browser"

Which @angular/* package(s) are the source of the bug?
Don't known / other
Is this a regression?
Yes
Description
Following the issue https://github.com/angular/angular-cli/issues/26323 I am trying to put back the browser builder mode so that I still can get it working the application with the RESPONSE / REQUEST functionality
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
1.- Do ng new and create a new application
2.- In the Angular.json, change "@angular-devkit/build-angular:application" to "@angular-devkit/build-angular:browser" and browser": "src/main.ts", to "main": "src/main.ts"
3.- Do ng build

The application does not build and I could not find any guidance to follow to make it work

Please provide the environment you discovered this bug in (run ng version)
_                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/

Angular CLI: 17.1.3
Node: 18.13.0
Package Manager: npm 8.19.3
OS: win32 x64

Angular: 17.1.3
... animations, cli, common, compiler, compiler-cli, core
... elements, forms, language-service, platform-browser
... platform-browser-dynamic, platform-server, router, ssr

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1701.3
@angular-devkit/build-angular   17.1.3
@angular-devkit/core            17.1.3
@angular-devkit/schematics      17.1.3
@schematics/angular             17.1.3
rxjs                            7.8.1
typescript                      5.3.3
zone.js                         0.14.3

Anything else?
It would be nice to have the option of specifying the builder to be use at least while the inject issues are being resolved and the overall server is fully stable

The steps mentioned above are insufficient. Th The application builder setup replaces multiple builders. Offering an option to use webpack-based builders does not align with our roadmap, particularly since most new features will only be available with the application builder.
NB: Whilst indeed the Response / Requests token are not available during ng serve, these are available when running the server directly after using ng build.

Ok @alan-agius4 , that's fair enough then. The problem I am facing is a 504 when trying to access the request.res property on the server causing the App to crash. Maybe is related to https://github.com/angular/angular-cli/issues/27075

request.res should not cause that if the Response / Requests tokens have been configured correctly in the server.ts.

I am going to try to put down some logs when hitting the problematic URLs so that I can see what is going on and if that is the case I will let you know
The only problems I have seen, so far have been that one when I need to return a 301 on the server and a misterious "out of memory" problem with node causing it to restart the Angular APP on the hosted Docker container. I am talking here just migrating - no code changes and nothing like OOM seen before.

@CarlosTorrecillas, I am not aware of anything that change that would cause that.

You are right, it looks like the response is filled as it should because I can see it. There is something else going on which is causing the application to hang / restart. I can see that message of Angular is running in development mode. from time to time during the request process.
My use case is that I navigate to a component A which makes a Http request to get the data. The data itself may contain the redirect URL where the resource is because it may have changed so I navigate to the exact same component A with the redirectUrl that I get back from the Http request and that's where I get the problem. Is not like I get an error, no. The application hangs and during that process I can also see the message of "Angular is running in development mode".
The code itself is quite simple because I do:
if (isPlatformServer(this.platformId)) {
                        if (this.request.res) {
                            this.request.res.status(301);
                            this.request.res.setHeader('Location', redirectUri);
                        }
                    } else {
                        this.router.navigateByUrl(redirectUri);
                    }

and that's it. Im just subscribed to activatedRoute to check the value change of the URI and I would make a successful Http request with the resource information later on. That was fully working on Angular 16 and I still don't know what is happening here. Trouble also is that I cannot do "ng serve" to debug locally. I can reproduce it but I cannot debug it because of the issue we have with the request/response.
I also added the uncaughtException handler but that isn't hit either. Any ideas?

I'm uncertain about the situation here, but it's odd that you're encountering the message "Angular is running in development mode" when the application is intended for production. This suggests a potential issue with your build configuration.
Moreover, remember that you can still debug the application even when it's not running within ng serve, this is after all a standalone Node.js application.

Sorry, I was running the dev build on my local machine to reproduce it, that's why you see that. In any case, seems to me a bootstrap message but it shouldnt?

It the application is running in dev-mode, the message is expected as the application gets bootstrapped for every request.

I cannot reproduce the scenario on a brand new App. I was doing extra tests locally and because I couldn't manage just yet to attach to the component I want I am not able to debug the code through node (not sure why I cannot view the component is being displayed to be honest).
That aside it seems to me that the redirect is indeed performed correctly however there is something going on with the second call (with the redirected URI) which finished quite quickly on the API:

But in Angular it shows as pending and does not finish:

Not sure what can it be but I don't know how to replicate to submit the issue to you guys. I will try to do it so we can discover what is going on...

Hi @alan-agius4 , I think I have found the root cause (the element at least that is causing that). If I take out the withFetch() from the provideHttpClient() the application works as expected and no hanging at all. I commented all the code out except the HTTP call and somehow hitting directly certain URLs were causing the application to hang.
That however didn't seem to happen when the application was loading the home page -> navigating directly to "/". Not sure if that could ring any bell or you know anything that could be causing it but in my project that is happening like that.

Hi @alan-agius4 , I am adding a bit more to that. I was looking at the https://angular.io/guide/versions section for Angular 17 and I installed v20.9.0. With that version I am not able to replicate the issue using withFetch() BUT if I switch back to v18.13.0 I have the problem back


Porch PackageVariant configuration injection feature

Implement config injection feature either in Porch or locally (then upstream in Porch)

If this is done in Porch there may be a need to sign Google CLA

Did you get a chance to take a look, @SimonTheLeg ?

Not yet, I am stuck with this one https://github.com/nephio-project/nephio/issues/117#issuecomment-1532620295


Support PEP 519 in I/O functions

As per PEP 519, Python 3.6 includes a protocol to specify that an object is "path-like", and builtin/standard library code has been updated to handle anything with a __fspath__ attribute (including pathlib.Path objects and the DirEntry objects returned by os.scandir). Most notably, the __builtins__.open function can now be given anything path-like.
Many projects like SciPy, NumPy, Pandas, etc., have convenience I/O functions which accept filenames in addition to open file-like objects, and in most cases one can get "free" support for the changes in PEP 519 by simply passing whatever the user provides to open instead of checking membership in a small set of allowed types. This may be a slight behavior change in which exception is raised from where, if letting open throw a TypeError for an unsupported type, instead of a specific I/O function raising its own exception for something apparently unsupported.
If feasible, it would be great to modify the I/O functions in SciPy to simply pass any unknown types to open instead of rejecting them -- one doesn't have to worry about which version of Python is being used, or whether hasattr(os, 'fspath') or anything like that. open will handle what it can, and throw a TypeError if appropriate, according to the capabilities of whatever version of Python someone is using.
Any opinions about this?

fixed in gh-6855


(WIP) Move from sneakers to sidekiq

This is a test of how good sidekiq and redis might be compared to sneakers and rabbitmq.
TODO:

[x] Move to sidekiq, test in dev
[ ] Env vars for redis url and retry settings.
[ ] Test in staging
[ ] Logging/alerting...
[ ] Change healthcheck to check redis

I see you @dan-palmer ;-)
Has @filipposc5 managed to make the sneakers config reliable?

:dancers: :wave: hey @mattmb how are things?

Good thanks buddy :smile: how 'bout you? I'm glad to see that you're still fixing allthethings at the MOJ


Hide coverage report lines for fully-covered files

🚀 Feature Proposal
In the end-of-test coverage report, it would be beneficial to not show files that are fully covered (100% stmts, branch, funcs, and lines; uncovered line #s s empty).
Motivation
In my project, we have 100% test coverage. This application spans hundreds of files. The end-of-test coverage report is extremely long. When a file lacks coverage (the only thing really relevant to the engineer), we have to scroll through these hundreds of lines to look for which file is the culprit.
The files with coverage are not relevant to the engineer. The point of the coverage report is solely to determine which files don't have coverage, not to see which ones have complete coverage already. The ones that don't have coverage are the ones failing the build.
Example
--coverageHideCovered
Changes:
File                                                                                | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------------------------------------------------------------------------|---------|----------|---------|---------|-------------------
All files                                                                              |   99.91 |      100 |   99.71 |    99.9 |
 src/components/app                                                                    |     100 |      100 |     100 |     100 |
  app.hook.ts                                                                          |     100 |      100 |     100 |     100 |
  app.lazy.ts                                                                          |     100 |      100 |     100 |     100 |
  app.view.tsx                                                                         |     100 |      100 |     100 |     100 |
  index.ts                                                                             |     100 |      100 |     100 |     100 |
 src/components/app-fallback                                                           |     100 |      100 |     100 |     100 |
  app-fallback.view.tsx                                                                |     100 |      100 |     100 |     100 |
  index.ts                                                                             |     100 |      100 |     100 |     100 |
 src/components/test                                                                   |   94.52 |      100 |      80 |   93.55 |
  test.hook.ts                                                                         |   92.16 |      100 |      75 |   90.24 | 126-134

Into:
File                                                                                | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------------------------------------------------------------------------|---------|----------|---------|---------|-------------------
All files                                                                              |   99.91 |      100 |   99.71 |    99.9 |
 src/components/test                                                                   |   94.52 |      100 |      80 |   93.55 |
  test.hook.ts                                                                         |   92.16 |      100 |      75 |   90.24 | 126-134

I happened to run across this issue while looking for an unrelated bug. It's quite easy to do this today by passing extra options to istanbul in your Jest config. Just set a custom coverageReporters option like so:
module.exports = {
...
  coverageReporters: [['text', {skipFull: true}], 'html', 'lcov', ...],
...
};

Of course, you can pass whatever other reporters you want, but the key here is replacing 'text' with ['text', {skipFull: true}].


Support for dynamic switchover of autobridging code:

Changes made to support autobridging and improve the offer-crossing logic result in transaction-breaking changes which cause incompatibilities between 0.27 and 0.28 builds of RippleD.
This patch simplifies deployment of 0.28 on the Ripple network by allowing it to emulate the 0.27 offer crossing semantics until the network advances to a specific ledger, at which point the new 0.28 semantics with autobridging become active.
The code is currently hard-coded to switch semantics on ledger 1,000,000,000 which won't come for quite some time. The value will be changed when the ledger on which semantics switch is decided.
Reviews: @vinniefalco, @rec, @JoelKatz

Not sure if the Travis failure is legit - the same specific error occurred with both builds - so kicking travis...

:+1:

The failure is both right and wrong: the tests try to run the autobridge suite (because it's enabled) but the new code effectively disables it until ledger 1,000,000,000 hence unexpected results which translate to a failure. I'll add a workaround.

As I said in a previous comment: "This is the code, exactly as it exists in the 0.27.x branch.I didn't want to modify it anymore than I absolutely had to."
Sorry if I wasn't more explicit in the pull request description. This really doesn't need the in-depth and thorough review you provided. Still thank you because it highlighted some things for future cleanups.

(Adding hold until we can decide on the cutover ledger)

@rec: Unless you have any particularly strong objections, I'd like to mark this as "passed" since it reintroduces the 0.27.x offer-crossing code with a time-based cut-off.

So wait.  I haven't really reviewed this at all.  I started to review it, and then I realized I had no idea what was new code and what wasn't...

@JoelKatz: the offer->ACCOUNT->offer fix has been tied to the "switchover" code. Please review this changeset and sign-off.

I need to know how to identify the new code in this change to properly review it!

@rec: the only new code is in OfferCreate.cpp in src/ripple/app/transactors/ which attempts to call the legacy OfferCreate transactor first in src/ripple/legacy/0.27/OfferCreate.cpp. The other bit of code is src/ripple/legacy/0.27/Emulate027.cpp which determines if we should emulate 0.27.
The rest of the OfferCreate transactors themselves (and their associated Taker infrastructure) are basically verbatim from the existing 0.27 and 0.28 branches.
So really, all you're reviewing is: "will this code cause the old legacy transactor to be called for days prior to March 30, 2015 at 1PM and then cause the new transactor to be called after that cutoff?"

Great!  I can :+1: then in all good conscience...


MemoryArtifactStore for unit testing and ArtifactStore SPI Validation

Provides an in-memory ArtifactStore implementation which can be used for unit testing and ArtifactStore SPI contract validation as proposed in #3387
Description
This PR introduces a MemoryArtifactStore which stores the artifacts in an in-memory map and supports all operations as expected from an ArtifactStore.
Test Suite
The PR also includes a test suite ArtifactStoreBehavior to validate the ArtifactStore SPI contract. This is broken down in following parts

ArtifactStoreCRUDBehaviors - Checks normal CRUD operations
ArtifactStoreQueryBehaviors - Check the query contract around skipping, limiting, sorting etc
ArtifactStoreSubjectQueryBehaviors - Check views specific to WhiskAuth specially around the join support for limits

subjects/identities
namespaceThrottlings/blockedNamespaces

For now these tests are run for 2 stores and passes for them

MemoryArtifactStoreTests
CouchDBArtifactStoreTests

Design for Non CouchDB Stores
CouchDB performs queries based on computed views. Most other databases provide a query interface with backing indexes. Currently OpenWhisk logic provides the view name as part of query invocation and thus has an implicit dependency on CouchDB view support. This has following impact on any non CouchDB store implementation
Mapping views to queries
For database which support SQL like constructs we need to map the query as expressed in CouchDB view to SQL. For e.g. if we need to map whisks.v2.1.0/actions view to some query
function (doc) {
  var PATHSEP = "/";
  var isAction = function (doc) { return (doc.exec !== undefined) };
  if (isAction(doc)) try {
    var ns = doc.namespace.split(PATHSEP);
    var root = ns[0];
    var value = {
      namespace: doc.namespace,
      name: doc.name,
      version: doc.version,
      publish: doc.publish,
      annotations: doc.annotations,
      limits: doc.limits,
      exec: { binary: doc.exec.binary || false},
      updated: doc.updated
    };
    emit([doc.namespace, doc.updated], value);
    if (root !== doc.namespace) {
      emit([root, doc.updated], value);
    }
  } catch (e) {}
}

Then it would be expressed as following pseudo query
SELECT namespace,
       name,
       version,
       publish,
       annotations,
       limits,
       updated,
       EXEC
FROM   whisks
WHERE  entitytype = 'action'
       AND ( namespace = $namespace
              OR rootns = $namespace )
       AND ( updated >= since
             AND updated <= $upto )
ORDER  BY updated

Here

rootns - Is a computed field created at time of creation (see below)
exec - Would be a computed field created at runtime during query result post processing
select criteria - Fields specified in select part are function of view used (see projected fields below)

Sometimes its not possible to completely map the view condition to query. For e.g. in subject queries. In such cases query partially applies the condition and then in DocumentHandler full conditions are applied thus result returned from query may be a super set of actual result set and actual result is thus obtained via "filtering"
Interpreting the keys
Query parameters startKey and endKey are closely tied to view implementation. Thus any other store would need to interpret the values in keys as per the view name. To support that this PR introduces a DocumentHandler trait which defines the db neutral operations
trait DocumentHandler {

  /**
   * Returns a JsObject having computed fields. This is a substitution for fields
   * computed in CouchDB views
   */
  def computedFields(js: JsObject): JsObject = JsObject.empty

  def fieldsRequiredForView(ddoc: String, view: String): Set[String] = Set()

  def transformViewResult(
    ddoc: String,
    view: String,
    startKey: List[Any],
    endKey: List[Any],
    includeDocs: Boolean,
    js: JsObject,
    provider: DocumentProvider)(implicit transid: TransactionId, ec: ExecutionContext): Future[JsObject]

  def shouldAlwaysIncludeDocs(ddoc: String, view: String): Boolean = false
}

There is a separate handle implementation provided for each entity i.e. ActivationHandler, WhisksHandler and SubjectHandler
Sections below would provide more details on the various methods
Computed Keys - computedFields
Some of the views in use make use of computed fields in the view logic. For e.g. view for rules computes a root namespace when namespace is a multi segment path
function (doc) {
  var PATHSEP = "/";
  var isRule = function (doc) {  return (doc.trigger !== undefined) };
  if (isRule(doc)) try {
    var ns = doc.namespace.split(PATHSEP);
    var root = ns[0];
    emit([doc.namespace, doc.updated], 1);
    if (root !== doc.namespace) {
      emit([root, doc.updated], 1);
    }
  } catch (e) {}
}

For supporting such cases in non CouchDB store DocumentHandler#computedFields can be used. This would compute the required field at time of put which the ArtifactStore implementation can then persist along with the main document. For e.g. for Mongo case such a computed json object can be stored under a separate _computed field internally.
These computed fields can then be used for defining declarative indexes. For now following computed fields are generated

WhiskEntity

rootns - Root name space.

Activations

nspath - Namespace with Entity path. The nspath is computed based on logic in whisks-filters.v2.1.0/activations
deleteLogs - This field is computed based on logic in logCleanup/byDateWithLogs i.e. flag would enabled for all such activations which are not sequence

See Mongo ArtifactStore for more details and examples
Projected Fields - fieldsRequiredForView
CouchDB views determine which all fields are included in returned document as part of query result. For non CouchDB cases this field list is defined by fieldsRequiredForView. ArtifactStore implementation can use it for projecting which all fields should be included
Join Support - transformViewResult
CouchDB supports joins which is used for subject queries to fetch the limits. Most other no sql db does not support such joins. So for such cases transformViewResult can be used which would be responsible for performing the join. For it to work the ArtifactStore need to provide an implementation of DocumentProvider which returns the raw json for provided id
trait DocumentProvider {
  protected[database] def get(id: DocId)(implicit transid: TransactionId): Future[Option[JsObject]]
}

MemoryViewMapper
This is an ArtifactStore implementation specific abstraction which converts the query keys passed to query to underlying storage query syntax. Each store implementation needs to have similar logic implementated which cover all possible scenarios from all the active views
Here the test suite plays an important role by validating that all query cases are covered.
TestSuite and future view changes
This test suite would need to be kept in sync with any change in view logic or addition of new views. Then only it can be ensured that other ArtifactStore implementation cover all the usecases as supported by default CouchDB. So going forward MemoryArtifactStore would become a cononical implementation of ArtifactStore contract!
Pending Work

[x] Support for namespaceThrottlings/blockedNamespaces view
[x] More coverage of entity tests

Related issue and scope

[x] I opened an issue to propose and discuss this change (#3387)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[x] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[x] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[x] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

This PR is now ready for review.
In a separate branch travis run was done with default ArtifactStoreProvider switched MemoryArtifactStoreProvider and all test (except few1) have passed.
ArtifactStoreBehavior test suite consist of ~30 tests which try to cover all possible access patterns for ArtifactStore and provides a coverage of ~86%
1 2 test needed to be ignored for run involving MemoryArtifactStore. See commit notes for details

@dubee @csantanapr @markusthoemmes 🙏 a pg to be safe although I expect Travis to be sufficient.

@rabbah  Currently there is a ignored test count with skip in ArtifactStoreQueryBehaviors as it fails for CouchDB. Looks like a count call with skip does not work as intended so that flow does not work
$ curl -H 'Host: localhost:5984' -H 'Authorization: Basic d2hpc2tfYWRtaW46c29tZV9wYXNzdzByZA==' -H 'Accept: application/json' -H 'User-Agent: akka-http/10.0.10' 'http://localhost:5984/whisk_local_activations/_design/whisks-filters.v2.1.0/_view/activations?startkey=%5B%22artifactTCK_aAAS_ns_zKXPz/testact%22,0%5D&endkey=%5B%22artifactTCK_aAAS_ns_zKXPz/testact%22,%22%EF%BF%B0%22,%22%EF%BF%B0%22%5D&skip=4&reduce=true'
{"rows":[

]}

In above curl for same setup if I remove skip=4 I get following response
{"rows":[
{"key":null,"value":10}
]}

Should I create separate issue to track this?

PG2 3021 🔵

@markusthoemmes If the PG test has passed can this PR be approved and merged?

Currently there is a ignored test count with skip in ArtifactStoreQueryBehaviors as it fails for CouchDB

Opened #3560 to track this


Alpha 1.0.4 - "more device info" not populating in text box

During the initial device information gathering process, "getting more device info" step doesn't populate into the text box.
"Get Info" button no longer populates extra information in the text box either.

This was a bug caused by me clearing the text field when stopping loading. Fixed, but I'll wait for the commit to close it.


key stories static map. I know this is hacked

for #147 can you help @lindsaycarr ?
I forgot how to get a static image from a non-target dir into the viz the right way. I was looking back at the example viz, and didn't see use of this (might be helpful to add that later?).

We did this in how-to-gdp for gifs but the need for export: true is unclear.
https://github.com/USGS-VIZLAB/how-to-gdp/blob/master/viz.yaml#L366-L377

Ok, I see what you did there. I assume I need to do something like this: https://github.com/USGS-VIZLAB/how-to-gdp/blob/master/layout/templates/gdp-figure.mustache in the template for key stories. Is there a standard format or snippet I should use for that?

Looks like this now:


Store dead links in database and expose an API endpoint that the catalog can pull from

Problem

Currently we store dead links only in Redis as a cache and periodically re-check the links based on a cache expiration. This means the work to find dead links on the API doesn't get reported back to the catalog for re-checking. We could have a DAG, for example, that pulls dead links from the API and then iterates through them to check the provider's API response for that item and determine whether any of the following are true:

The item is truly gone from the provider
The item's url has changed

Description

To enable this, we'd need to make it possible for the catalog to pull dead links from the API database. The easiest way to do this (I think) would be to store the dead links in the database and expose an endpoint for the catalog to ingest them and process them from. This endpoint could (probably should) be restricted to a specific OAuth scope so that it's not publicly available. It also seems likely that we'd want the catalog to be able to update the dead links list in the API. Either this would need to happen during ingestion or somehow we'd need to open a write endpoint on the API that the catalog can hit to fix the dead link in real-time somehow without having to wait for re-ingestion. That might not be necessary though :thinking: We would want to invalidate the cached dead link status from Redis upon the next data refresh of those items though which suggests either the catalog should write to Redis or somehow Redis needs to be updated during data refresh.
Alternatives

Could the catalog pull directly from Redis? That seems like a hack though.
Additional context

cc @stacimc and @AetherUnbound for expertise from the catalog side to know whether this is really possible or if there is another more sensible approach.
Implementation

[ ] 🙋 I would be interested in implementing this feature.

We have other issues to solve this using better, less complex approaches. Closing this in favour of #428  #1571 etc.


Perl - 5.26 - Update to latest version

Well I will not update Perl in near months because it need rebuild a lot of packages and I dont have much time. Lets do it when I can.

Rebase changes

This is just not working and attempts to work with the branch to make things worse.  I will close this.


Shared board fixes

Coverage decreased (-0.01%) to 47.338% when pulling f4be4db10ab4c5f79aa925a083e3a02addc57b39 on shared_board_fixes into 98f50481d156f9c6931b2a2c559c0e3628aaa100 on master.


feat: adds small-check-icon

Overview
PR Checklist

[x] Related to designs: specific design for weekly target needed a small version of the check mark and scaling the current checkmark did not work visually so adding a customized smallCheckIcon.
[x] Related to JIRA ticket: https://codecademy.atlassian.net/browse/EGG-256?atlOrigin=eyJpIjoiOGU3YTYwNDBmZDI2NDc1NmFlODY4NjFjMDdhNjA5NDkiLCJwIjoiaiJ9
[x] I have run this code to verify it works
[ ] This PR includes unit tests for the code change

Description

📬Published Alpha Packages:@codecademy/gamut-icons@3.8.3-alpha.5cae52.0@codecademy/gamut-labs@4.2.11-alpha.5cae52.0@codecademy/gamut@16.1.6-alpha.5cae52.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f871cf368d5b11ebc8c05f1--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@3.8.3-alpha.946722.0@codecademy/gamut-labs@4.3.1-alpha.946722.0@codecademy/gamut@16.2.1-alpha.946722.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f874ccb77884757435de3e2--gamut-preview.netlify.appDeploy Logs


Loss of backward compatibility when upgrading to version 2.0.3 (I think)

TypeScript Version:  2.0.3
Expected behavior:
I expected that the upgrade from version 2.0.2 to version 2.0.3 should not cause problems as backward compatibility should be maintained. I expected that my code that compiles without errors in version 2.0.2 will be as error-free kompilirovatsya to version 2.0.3.
Actual behavior:
In version 2.0.2 the compilation succeeds. With version 2.0.3 get three errors:
ERROR in ../components/dialogs-page/Dialog.class.ts
(7,14): error TS2420: Class 'Dialog' incorrectly implements interface 'IDialog'.
  Types of property 'type' are incompatible.
    Type 'DialogType' is not assignable to type 'DialogType'.

ERROR in ./Background/BgClass.ts
(84,7): error TS2365: Operator '===' cannot be applied to types 'AudioOptionStatus' and 'AudioOptionStatus'.

ERROR in ./Background/BgClass.ts
(86,7): error TS2365: Operator '===' cannot be applied to types 'AudioOptionStatus' and 'AudioOptionStatus'.

Newer versions contain bug fixes as well as new checks. You can find all the breaking changes in https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-20
As for your question, I can not help you further without looking at the definitions and use sites that triggered these errors. Please provide self contained code samples that we can look at.

// /source/components/dialogs-page/Dialog.class.ts
export enum DialogType {
	User,
	Chat,
	Group,
}

export class Dialog implements IDialog {
	peer_id: number;
	in_read: number;
	out_read: number;
	unread: number = 0;
/*7*/type: DialogType;
	title: string;
	url: string;
	photo_50: string;
	profiles: number[] = [];
	// ...
}

// /source/entrys/Background/BgClass.ts
export class BgClass {
	stg = <IStorageData>{};
	badge: number = 0;
	// ...
	playSound(newBadge: number) : this {
/*84*/	if (this.stg.options.audio === AudioOptionStatus.Never || newBadge <= this.badge) return this;
		const audio = <HTMLAudioElement>document.getElementById('audio');
/*86*/	if (this.stg.options.audio === AudioOptionStatus.Always) {
			audio.play();
			return this;
		}
		chrome.tabs.query({url: '*://*.vk.com/*'}, (tabs) => {
			if (!tabs.length) audio.play();
		});
		return this;
	}
	// ...
}

// /source/components/StorageApp/storage.d.ts
declare enum DialogType {
	User,
	Chat,
	Group,
}

interface IDialog {
	peer_id: number;
	unread?: number;
	title?: string;
	in_read: number;
	out_read: number;
	type: DialogType;
	profiles: number[];
	message?: IMessage[];
	photo_50?: string;
	isMore?: boolean;
}

declare enum AudioOptionStatus {
	Never,
	SomeConditions,
	Always,
}

interface IOptions {
	friends: boolean;
	photos: boolean;
	videos: boolean;
	messages: boolean;
	groups: boolean;
	app_requests: boolean;
	wall: boolean,
	mentions: boolean,
	comments: boolean,
	likes: boolean,
	reposts: boolean,
	followers: boolean,
	audio: AudioOptionStatus;
}

interface IStorageData {
	// ...
	options: IOptions;
	dialogs: IDialog[];
	// ...
	[key: string]: any;
}

I have the same issue. I had to change all references to my enum values to be ..valueOf().

here is a simpler repro for this issue:
namespace Ambient {
    export declare enum E {
        A,
        B
    }
}
namespace Concrete {
    export enum E {
        A,
        B
    }
}

var a: Ambient.E;
var c: Concrete.E;

a = c; // Concrete.E is not assignable to Ambient.E

The reason this error is shown is that the compiler could not guarantee the correctness of this assignment:

The compiler will generate code for Concrete.E, and since all members do not have any initializers, it will auto-number them. so Concrete.E is actually: { A = 0, B = 1 }.
As for Ambien.E it does not have any intalizaters, so the values for Ambient.E.A can be anything at runtime.

So to get rid of the warning, make sure your ambient enum has initalizers that matches your implementation enum. in the above example, adding initalizers to Ambient.E makes the two enums assignable again.
namespace Ambient {
    export declare enum E {
        A = 0,
        B = 1
    }
}

The other solution is to use const enums instead of the two enum declarations. const enums do not exist at runtime, so you can just declare them in the .d.t file and use them in the .ts file without having to redefine them. The compiler inlines all references to the const enum in the .ts file with its value, see this example for more details.

I'm confused, because the original issue didn't have anything to do with assignment. The real problem was about comparing two values from the same enum definition:
`this.stg.options.audio === AudioOptionStatus.Never
declare enum AudioOptionStatus {
Never,
SomeConditions,
Always,
}`

@daschult i do not know what the issue you are running into. you have not shared any information.
based on the sample @cawa-93 shared, he has two declarations for the same enum. this is what i explained above. the two enums have the same name, this is why you get this error message  Type 'DialogType' is not assignable to type 'DialogType'.

//cc: @sandersn

Ah, I see. I was mostly interested in the 2nd and 3rd error messages.
`ERROR in ./Background/BgClass.ts
(84,7): error TS2365: Operator '===' cannot be applied to types 'AudioOptionStatus' and 'AudioOptionStatus'.
ERROR in ./Background/BgClass.ts
(86,7): error TS2365: Operator '===' cannot be applied to types 'AudioOptionStatus' and 'AudioOptionStatus'`

From @cawa-93 sample, i see a similar pattern for AudioOptionStatus. but i am working with snippets here, so i could be wrong :)

if you do not have the same pattern, but seeing errors that you do not expect, please file a new issue and provide self contained repro for the issue.

@mhegazy thanks. You'r example resolve my problem.
declare enum AudioOptionStatus {
	Never = 0,
	SomeConditions = 1,
	Always = 2,
}

declare enum DialogType {
	User = 0,
	Chat = 1,
	Group = 2,
}


ci(pr-preview): add support to vercel pr preview

Deploy URL (WebApp):

Deploy URL (WebApp):

:tada: This PR is included in version 1.10.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Add django-instant to requirements.txt

This fixes the "No module named 'instant' " when the project is ran.

Thanks @Smyja


Use for := range idiom when looping on bin content

It's more idiomatic Go
it does not require computing the count, db.divx * db.divy as it's correspond to the slice length, and thus, is contained in the slice underlying data structure

Coverage remained the same at 100.0% when pulling 0b4512e2e11618eab302145f1e419a4c666559b0 on use-for-range-idiom into 7a47d940709227fd1b19e504d27ba651fbba2b8b on master.


README_clarification

Adding some clarification to the instructions in the README.md based on my experience using letsencrypt-webfaction.

I had seen the comment (and that the staging was the default setting in the config), but I think I missed the implications of the corner case I opened the issue about here, where I got "stuck" with the staging certificate.


Fix NPE occurring when swiping fast between chapters

If you swipe between chapters back and forth very fast - the app will crash. Variable context becomes null at some point. I fixed this by using context from mWebview.
How to reproduce this crash: https://youtu.be/Af8_L9MdgMk

Great!


How to install global commands

The extension docs state that you should define script commands in the workspace settings.json. But I have some commands I want to be available always (i.e., in every workspace, and even when I open a standalone file with no workspace. How do I do that? Also script files seem to be located relative to the workspace - so where would I put script files for global commands (I'd rather not hard code paths, as I'd prefer my settings to be portable).

It looks like adding the exact same settings to define commands in the workspace-specific settings.json also works in the global settings.json.


Fixed positioning of the clear button when using a filter

@epwinchell

Old:

New:

@martinpovolny @h-kataria Looks good

@chessbyte @fryguy can you restart vmdb test

@chessbyte @fryguy pls restart travis

looks good.


fix typings for core

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-core


[Ruby] Ruby 2.6 is now minimum support (dropping Ruby 2.5)

Motivation and Context
Ruby 2.5 has been end-of-lifed 1 year and 2 months ago on March 31st, 2021.
Some of our dependencies are bumping to a minimum of Ruby 2.6 which causes some rough installations.
Description

Bumped fastlane.gemspec to minimum Ruby 2.6
Bumped .rubocop.yml to target of Ruby 2.6
Ran rubocop which changed a bunch of stuff

Restarting


Watch the config map for change

We need to watch the config map for changes, such that we update the same on managed clusters that are subscribed to the config via a DRPolicy, as part of the watch we would possibly remove reading the config from the mounted config map in the deployment


Can't login to datacamp

Hi,
Whatever I do I can't login. Keeps giving an error that username and password are incorrect. I even changed my password to test it again.

This is the response

WARNING: Couldn't run login with inputs

This happens to me sometimes due to Cloudflare's protection. Use set-token to login, it should work.

Thank you, it worked. But now I don't see the courses listed.

You can only download your completed courses/tracks


main file index.js not found, you may need to build the project

NVIM v.0.8.0

Nope, is just a json.


Fix unit test workflow

Fixes for unit test workflow, not running currently appropriately.

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

Project coverage is 96.77%. Comparing base (d06cf77) to head (fb4f256).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #22   +/-   ##
=======================================
  Coverage   96.77%   96.77%
=======================================
  Files          21       21
  Lines        1085     1085
=======================================
  Hits         1050     1050
  Misses         35       35

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


Created missing profile endpoints

Delete order endpoint
Update order endpoint
Order sold endpoint (Decrease quantity by 1)

Forgot to mention in the description, i have removed all the misc endpoints as they were returning 404 for me

@Sh4dow8080 Misc endpoints is on dev build and will be deployed in the next update.
Please return them =)

Api docs was extracted into separate public repo after i added all these endpoint a while ago

Anymore changes you would like me to make before merging?

i'll finish my current tasks, will check and merge it, thanks !

I will commit the changes you requested some time this weel :relaxed:

since the author hasn't resolve the conversations and being inactive for so long, I'm marking this PR as stale for now


Update ping requests

Update all ping requests to match the output found in cogs.info.help-ping()

Corrected with 1.1.2


Newlines don't work in translation tags

The following gets picked up in translation capturing and included in the translations.json but at runtime will not get translated.
    <translate tag='p'>
      Forgot your password? Enter your username, click "Continue"
      and we'll send a password reset link to you.
    </translate>

vue-gettext 2.0.8
Mac Os Sierra 10.12.3
gettext <IP_ADDRESS>
easygettext 1.2.2

Still have such issue with v-translate

    Install Serverwide

Install Serverwide

   <translate>
        Install Serverwide
   </translate>

trimming msgid before comparison did the trick for me:
// Sometimes msgid may not have the same number of spaces than its key. This could happen e.g. when using
// new lines. See comments in the `created` hook of `component.js` and issue #15 for more information.
            if (!translated && /\s{2,}/g.test(msgid)) {
                Object.keys(translations).some((key) => {
                    if (key.replace(/\s{2,}/g, ' ') === msgid.trim().replace(/\s{2,}/g, ' ')) {
                        translated = translations[key];
                        return translated;
                    }
                });
            }

Thanx @tabun-matadorov a new release is available with your fix :)


Added twig loader extension for references

Mentioned as a more scalable way to include references to other twig templates.

@davidcmoulton ah right, late addition of stringifyRequest broke it, fix that now 👍

Was hoping this would fix the Twig reload problem, but doesn't...

@thewilkybarkid What the details of the Twig loading problem?

@stephenwf Make a change to a template, it doesn't update and there's an error in the console.


improve GROUP BY time() examples, including offsets

URL for relevant page?
https://docs.influxdata.com/influxdb/v0.13/query_language/data_exploration/#group-by-time-intervals
Use a slightly clearer example with more round numbers. It's tough to parse the day offset, especially with odd dates rather than even dates.
Also, let's show what happens if there are points with fields that don't always have a value. E.g. show the buckets with no values, then use FILL() and show buckets with the filled values.

Try 1h


Add link to deployed project

In the Live demo section of the README file, the link to the deployed project has been added.

Thank you @PinkMoon25


Merge pull request #133 from ordinals-wallet/pixel-pepe

Planetary Ordinals

Merge

{
  "name": "Planetary Ordinals",
  "inscription_icon": "98da33abe2045ec1421fcf1bc376dea5beb17ded15aa70ca5da490f50d95a6d9i0",
  "supply": "69",
  "slug": "planetary-ordinals",
  "description": "",
  "twitter_link": "https://twitter.com/ordinalswallet",
  "discord_link": "https://discord.com/invite/ordinalswallet",
  "website_link": ""
}


Orientation issue exif related

Photos taken by iPhones in Portrait mode show up as landscape. This could be an Exif related issue. Photos taken in landscape mode seem fine. I will provide more details as I work with this tool more to characterize what's really wrong.

Remark: This ignoring of Exif may be ok depending on context. I just tried the tool out, label a few boxes. In my jupyter notebook, I used this to open them as an numpy array
x = np.array(PIL.Image.open('my image.jpg'))
Since we are using x as raw data, and doesn't care about the intended display orientation, all are consistent and fine. I think the trouble come if you use some other tools, maybe imageio, that respects EXIF, then you may get an apparent mismatch in coordinates those captured by this tool in some circumstance.
I don't think this is a bug with this tool, it is appropriately a data processing tool (part of a pipeline) and not concern with display and presentation.

RectLabel is an offline image annotation tool for object detection and segmentation.
Although this is not an open source program, with RectLabel you can remove the EXIF orientation flags from images and convert images to the front orientation. If necessary, you can rotate the image right/left by 90 degrees.
https://rectlabel.com/help#remove_exif_orientation_flags


More possibilities with Modbus-Exceptions

This got a little bigger than I initially expected. I hope you're ok with my changes.
What I've done so far

Made some types of frame module public
Converted FunctionCode to an enum and replaced it in a lot of places in codec module. I've done this because I needed the function code in the service handlers to send the Correct ExceptionResponse object.
Added the GetFunctionCode trait and implemented it on Request and Response. This is also necessary to generate the correct ExceptionResponse in the handlers.
Added the ExtractExceptionResponse trait. This is for an easy way to downcast the std::io::Error in the clients to ExceptionResponse
Added a new example that combines the following things:

async tcp-server
async rtu-server
An example of a Service that really uses async and not futures::ready
Specifying ExceptionResponses in the Service Layer
extracting ExceptionResponse from the client response

I started this because I didn't find ways to specify Modbus-Exception and didn't find a way to extract those in the clients.
I Think this PR should fix #169 and #98.
What could be better here?
I think It would be better to be able to Just return a Result<Response, Exception> from the Service and figure the correct function_code out after the service handler and automatically convert the Exception into ExceptionResult.
But I didn't want to make an even bigger change without speaking to to you in the first place.

Thanks for contributing!
IMHO this PR contains too many unrelated changes. The FunctionCode newtype should be introduced by a separate PR.

any chance this is getting merged soon?

Please give this PR a concise title that later becomes the Git commit message.
We also need a changelog entry that summarizes the changes and consequences for users of this crate. Ideally a single sentence for every notable API change. As short as possible.
Everyone is invited to do a review. We are managing this crate in our spare time without any monetary compensation. Please understand that paid projects might be prioritized. Thank you.

I will close this PR after seeing no progress lately and because merge conflicts are pending.
Please open a new PR whenever you have something ready. Thank you.


[Backport] [v0.7] RHUI client certificate expired for RHEL 7-RAW images

Please backport #2318 to v0.7.

✔ epicli apply: Azure/AWS x RHEL. Successfully deployed clusters in Azure RHEL (using RHEL 7-RAW image) and AWS RHEL environments.


🐞 Extractor Vite does not watch fixed extraction sources

Description
// vite.config.ts

import { defineConfig } from 'vite'
import { CSSExtractorPlugin } from<EMAIL_ADDRESS>
export default defineConfig({
    plugins: [
        CSSExtractorPlugin({ sources: ['foo.txt'] })
    ]
})

npm run dev

It does not have HMR when modifying foo.txt
Reproduction
No response
System Informations
No response

🎉 Released in https://github.com/master-co/css/releases/tag/v2.0.0-beta.160


Client fetch_token throwing NoMethodError

I am currently using this library to fetch tokens from a centralized identifier service.
The problem occurs when the identifier service is unreachable and we are passing the :raise_errors option set to false.
The fetch_token method throws NoMethodError while trying to perform the following code: response.parsed.merge(access_token_opts), because the response.parsed is nil.

Great analysis.  Do you think you could work up a failing spec in a PR?

Already did, #460

Already closed for sometime


Fix image CVE issue

update the image tag to v2.4
update doc
update image Dockerfile to fix the CVE issue

/hold will rebuild all images with new tag v2.4

all images have pushed to the repo with v2.4 tag

/lgtm

argocd image passed:

alertmanager-to-github image passed:

app-prom-config image passed:

/unhold


Auto detect chain-prefix from chain binary

Closes #97

[ ] Add tests

only the prefix is detected, but not denom; this is confusing. The user will have to provide some aspects about the blockchain, but not others. Half automation in this case is actually worse than no automation at all.

Denom can be configured in genesis file generation step. It is not exactly hardcoded as chain HRP prefixes.

it is unclear how auto-detections works, and should work in general when the prefix can be provided in the chain.toml config file.

We can still keep prefix key in chain.toml and update it when binary is updated (via atomkraft chain binary junod)

the feature relies on the particular way a binary is expected to react to keys parse 00 --output json. I don't feel this is the standard behavior we should expect of all chains.

I agree with the fact that we should not use a feature that is not supported by cosmos-SDK by default. I opened a PR at cosmos-sdk. But I don't expect it to be present in any other chains soon.

the feature is undocumented. E.g. the transfer tutorial is not adjusted.

I wait for an initial code review to add tests and update tutorials. Because it doesn't make sense if a PR is rejected.


Feedback on Milestone 2

@Jamienie and @makka3, great job on Milestone 2! All I can add is the following:

[ ] Table 1 in the report appears as a code snippet rather than a rendered table.
[ ] I see that you have addressed almost all feedback noted for Milestone 1, so do not forget to close the issue on Github :)

Suggestions:

Go through http://swcarpentry.github.io/make-novice/reference. This would help you make your Make code more practical. For example, you can use automatic variables and avoid some repetition.

Thank you Ozum for your constructive feedback throughout the project. We made the following changes to address your suggestions and fulfill the requirements of the final project:

Rendered the table in the final report and made formatting edits
Making and documenting the Docker file
Added a Code of Conduct
Edited the Readme to account for Docker file instructions
Closing all the issues

We looked into making our code more practical using the link above, but ultimately made little to no changes in the project for the purposes of time. We will definitely be considering this when implementing future projects.
Hope you enjoy/enjoyed reading our project, and thank you once again for all of your suggestions.
-Makk and Fan


Unable to create replication with a label filter

Describe the bug
Attempting to add a label filter on a harbor_replication resource fails with error:
{"errors":[{"code":"BAD_REQUEST","message":"filters the type of label filter value isn't string slice \n"}]}
To Reproduce
The following example fails with the stated error
resource "harbor_registry" "main" {
  provider_name = "docker-hub"
  name          = "test_docker_harbor"
  endpoint_url  = "https://hub.docker.com"
}

resource "harbor_replication" "push" {
  name        = "test_push"
  action      = "push"
  registry_id = harbor_registry.main.registry_id
  filters {
    label = "qa"
  }
}

Expected behavior
Expect a filter on label to be applied to the replication
Screenshots

Desktop (please complete the following information):

OS: MacOS
Browser: N/A
Version: 3.1.8 (of terraform-provider-harbor)

Additional context
Honestly I'd almost consider this a harbor bug.. as API docs do not seem to align with actual api
See below where api shows an array/slice rather than raw string:
GET /api/v2.0/replication/policies
[{
    "id": 1,
    "name": "test-replication",
    "description": "",
    "creator": "",
    "src_registry": {
        ... redacted ...
    },
    "dest_registry": {
        ... redacted ...
    },
    "dest_namespace": "",
    "filters": [{
        "type": "label",
        "value": ["qa"]
    }],
    "trigger": {
        "type": "manual",
        "trigger_settings": {
            "cron": ""
        }
    },
    "deletion": false,
    "override": true,
    "enabled": true,
    "creation_time": "0001-01-01T00:00:00Z",
    "update_time": "2020-10-09T15:11:22.876218Z"
}]

Digging in a bit more on the harbor side, this stuff is not clean looking :\
https://github.com/goharbor/harbor/blob/master/src/controller/replication/model/model.go#L233
Seems like it would be appropriate to change the replications.ReplicationFilters#Value to interface{} and mimic harbor's casting based on type checking


Error: IndexError for sutils.load_profiles in unix based OS like mac, linux

I am getting the below error while running spot_connect.sutils.load_profiles() in the mac os.
python3 ec2_spot.py
lib:  profiles.txt profiles /
pull:  /Users/xyz/Desktop/MyComputer/Development/env_aws/lib/python3.8/site-packages/spot_connect
Traceback (most recent call last):
  File "ec2_spot.py", line 18, in <module>
    print(sutils.load_profiles())
  File "/Users/xyz/Desktop/MyComputer/Development/env_aws/lib/python3.8/site-packages/spot_connect/sutils.py", line 60, in load_profiles
    profile = [f for f in list(absoluteFilePaths(pull_root()+'/data/')) if f.split('\\')[-1]=='profiles.txt'][0]
IndexError: list index out of range

Found issue during the
f.split('\\')[-1]=='profiles.txt'

Possible solution to this is using pathlib package.
import pathlib
path=pathlib.Path('/Users/xyz/Desktop/MyComputer/Developmentenv_aws/lib/python3.8/site-packages/spot_connect/data/profiles.txt')
print(path.name)

Output:
profiles.txt

I replaced the '\\' with os.path.sep. It happens in a few places. This is arguably a quick and dirty fix, pathlib might be better.


Add sanity check for primitive inplace copy operator

🚀 Feature
Add a sanity check to ensure the copy_to argument of prims.copy_ is not used as input for any of its subsequent operators
Motivation
Nvfuser's fd.add_output(output, input) API has the rule "do not use the input after it has been updated". We need the same sanity check for prims.copy_(copy_from, copy_to).
cc: @IvanYashchuk @jjsjann123

wondering if this is part of #145 , or just a simple patch to catch the obvious issues?

wondering if this is part of #145 , or just a simple patch to catch the obvious issues?

I think that's a simple patch and could be removed when the full inplace analysis is ready


Font Awesome 5 support

Can you please merge this @toopay ? thanks a bunch

Please also create a new release

@royduin sorry but I can't bump npm version. @toopay has to do it


Format changelog

This adds @metamask/auto-changelog, and updates the changelog to match the expected formatting. I've also renamed the file to CHANGELOG.md (from Changelog.md) for consistency.

@SocketSecurity ignore<EMAIL_ADDRESS>New author seems ok.


Generate simple context model without SDK deps, supporting calling CRM from Azure Functions

Is your feature request related to a problem? Please describe.
XrmContext generates API models that depend on the OrganizationService and Entity base-classes.
This is fine for Plugins / Workflows.
However, MS has not released a .NET Core compatible library for the OrganizationService, locking Azure Functions on version ~1 and .NET Framework.
Describe the solution you'd like
Use the context generator to create a "dependency-free" version of the context, and helper functions, allowing us to call the WebAPI directly.

For the time being, I would suggest looking in to this article if you have this need https://github.com/delegateas/XrmContext/wiki/Using-XrmContext-in-a-.net-core-project.


no api key

the website no longer gives api keys, Is there's some way to get this module working?

Thanks for the hint. I am currently looking for an alternative for the API and already have one in prospect. But I still expect the consent for the use (without API key).


[WIP] Thought experiment on avoiding java reflection APIs

Not for landing

@swankjesse Yep, dead end.  I was trying to confirm that, but also wondering about avoiding all the messy reflection code.


About the Shape_formation_block

Hi !Thanks for sharing your great work ! I have no idea about the code in the function called 'Shape_formation_block',
		face_shape = face_shape - tf.reshape(tf.reduce_mean(tf.reshape(facemodel.meanshape,[-1,3]),0),[1,1,3]) I have read your annotation，it is used to re-center the face shape with mean shape.But I still couldn't understand ,Could you please give me more explanations?

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

Thanks a lot!!!

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.
Hi ! Sorry for bothering you again. I also have question about the meaning of the point_buf in the BFM model.
		self.point_buf = tf.constant(model['point_buf']) # face indices for each vertex that lies in. starts from 1. [N,8]
Does it mean the adjacent face index for each vertex?

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

Hi ! Sorry for bothering you again. I also have question about the meaning of the point_buf in the BFM model.
self.point_buf = tf.constant(model['point_buf']) # face indices for each vertex that lies in. starts from 1. [N,8]
Does it mean the adjacent face index for each vertex?

Yes it is.

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

Hi ! Sorry for bothering you again. I also have question about the meaning of the point_buf in the BFM model.
self.point_buf = tf.constant(model['point_buf']) # face indices for each vertex that lies in. starts from 1. [N,8]
Does it mean the adjacent face index for each vertex?

Yes it is.

Thank you so much. I appreciate your help.

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

Hi ! Sorry for bothering you again. I also have question about the meaning of the point_buf in the BFM model.
self.point_buf = tf.constant(model['point_buf']) # face indices for each vertex that lies in. starts from 1. [N,8]
Does it mean the adjacent face index for each vertex?

Yes it is.

Hi! Sorry for bothering you again, I have no idea about the perspective projection of the 3D face. I have searched many information on the internet and found that the projection matrix is a 44 matrix like this.But I found that the p_matrix in your work is a 33 matrix.

Could you kindly give me some information about the prospective projection in your work ?
Thanks again

Hi, the 3x3 projection matrix we use and the 4x4 matrix are doing the same thing but in different mathematical forms. You may check https://en.wikipedia.org/wiki/Pinhole_camera_model to get a rough understanding about pinhole camera model.

Thanks for your help and your patience!!^_^

We re-center face shapes so that for a shape with arbitrary rotation angles, when projected onto the image plane, will have similar size to a frontal face and lies in the middle area of the image.
In our method, we use a cropped region of BFM which only contains face region. Therefore, the original center of BFM model is a little bit behind. If use the original center (without re-centering), faces with non-zero rotation angles will not fall in the center of the image.

Hi ! Sorry for bothering you again. I also have question about the meaning of the point_buf in the BFM model.
self.point_buf = tf.constant(model['point_buf']) # face indices for each vertex that lies in. starts from 1. [N,8]
Does it mean the adjacent face index for each vertex?

Yes it is.

Hi! Sorry for bothering you again. I could not understanding the the meaning of the number '102' in the pre_processing file. In function resize_n_crop_img(img,lm,t,s,target_size = 224.)
	w = (w0/s*102).astype(np.int32)
And I also couldn't figure out the experssion left = (w/2 - target_size/2 + float((t[0] - w0/2)*102/s)).astype(np.int32) in the same function. I konw the t[0] and t[1] is the translation of the x and y, and s is the sacle factors from 3d-landmark to 2d-landmark. But I dont konw the reason why should add (t[0] - w0/2)*102/s and (h0/2 - t[1])*102/s) while caculating the left and up  and when caculating the right and below doesn't need to add these.
Thanks again.

For the first question, 102 is just a manually set scalar to adjust the face size in the cropped image.
For the second question, we already know the target size of the cropped image, which is 224 in our setting. Therefore, once we get left and top in the original image, we directly know the right and below, which equal to left + 224 and top + 224 respectively.

For the first question, 102 is just a manually set scalar to adjust the face size in the cropped image.
For the second question, we already know the target size of the cropped image, which is 224 in our setting. Therefore, once we get left and top in the original image, we directly know the right and below, which equal to left + 224 and top + 224 respectively.

Thanks for your reply, I could understand the meanging of '102'.But I don't know why you use (t[0] - w0/2)*102/s when caculating the 'left'.In my points of view, the left is(w/2 -target_size/2)* 102/s - t[0],because from the least square problem we knpw that 'lm3d * R + t = lm2d'. I can not understand why is (w/2 - target_size/2 + float((t[0] - w0/2)*102/s)).
Thanks again.

If we ignore the rotation, the least square problem is solving s*lm3D + t = lm2D(Original image space).
Therefore, in order to put the face in the center of the original image, we should move the image center by t - w0/2 (because the image center of the original image is w0/2 instead of 0). However, for the resized image to be cropped, it is scaled by 102/s. So to move the face to the center in the resized image space, we should multiply t - w0/2 with scale factor 102/s, and that deduces the equation (w/2 - target_size/2 + float((t[0] - w0/2)*102/s)).

If we ignore the rotation, the least square problem is solving s*lm3D + t = lm2D(Original image space).
Therefore, in order to put the 2D face in the center of the original image, we should move the image center by t - w0/2 (because the image center of the original image is w0/2 instead of 0, but the center of lm3D is zero). However, for the resized image to be cropped, it is scaled by 102/s. So to move the face to the center in the resized image space, we should multiply t - w0/2 with scale factor 102/s, and that deduces the equation (w/2 - target_size/2 + float((t[0] - w0/2)*102/s)).

Thanks!!!! With your guidance, I understanded that reason just now.

Hi, the 3x3 projection matrix we use and the 4x4 matrix are doing the same thing but in different mathematical forms. You may check https://en.wikipedia.org/wiki/Pinhole_camera_model to get a rough understanding about pinhole camera model.

Hi ! Sorry for bothering you again. I have some problems about the caculation of landmark loss. According to the caculation in the function Projection_block, we can get a 2d-landmark. But I found that the  result of the Pinhole_camera_model  is a reversed image like the picture below. The onlt idea I can come up with is to transpose the image befor sending to the face-net(and I got the landmark loss 7045.1685 with single image ). Do you have other ideas?
the red landamarks is from the face-net
the blue landmarks is from the projection block

I do transpose for the image befor sending to the face-net. But the nhumber of landmark loss is too large.Do you have any idea？
Thanks again.


Better explanation of how to render math?

Describe the problem/need and solution
Context
I am trying to use this library to create files using markdown that allow me to refer back to equations. I would like to achieve something like this example
Problem / Idea
For some reason, I can't do both reference to equations work and render equations. For example, I would like to be able to show the letter lambda in the example bellow:

I have looked the documentation up and down, but even the examples available in the documentation don't render like LaTeX! I have tried using the interactive part of the documentation (which is a great feature) and I does not render there as well!
I am quite new to javascript, so maybe it is obvious for everyone else? In this case, I apologize. If I understood some of the code, there seems to be some options for the MyST() which do not seem to be documented anywhere. Maybe the solution is in there and this is the real issue?
Thanks!
Guide for implementation
No response
Tasks and updates
No response

Hi @danmrc, sorry for missing this when you posted. You are quite right that math doesn't work out of the box with mystjs at the moment, and requires some post processing.
Are you using mystjs to render directly to HTML? Or is there a bit more context you can give about your setup?

Hello @rowanc1,
I am trying to generate HTML through eleventy to build a static webpage. Here is the line of code that allows me to convert Markdwon files to HTML:
const markdownTech = require("mystjs");

module.exports = function(eleventyConfig) {

   #many things that are from eleventy here!

    const parser = new markdownTech.MyST();

   eleventyConfig.setLibrary("md", parser);

}

This is enough to convert the markdown to a html post, but as I said, I can't get the maths to render;.
Since eleventy generates site, I tried adding the following to the header to get KaTeX to work:

<link rel="stylesheet"<EMAIL_ADDRESS>integrity="sha384-KiWOvVjnN8qwAZbuQyWDIbfCLFhLXNETzBQjA/92pIowpC0d2O3nppDGQVgwd2nB" crossorigin="anonymous">
    <script defer<EMAIL_ADDRESS>integrity="sha384-0fdwu/T/EQMsQlrHCCHoH10pkPLlKA1jL5dFyUOvB3lfeT2540/2g6YgSi2BL14p" crossorigin="anonymous"></script>

And that doesn't do anything

and requires some post processing

I think I understood that, and in #4 you say something in that regard. However, I was not able to get it working from your discussion on that post. I have not used JS a lot, so maybe this is more a beginners doubt than an issue with the documentation.


No TLS support for Redis

Pretty much what it says in the title.
Request is just to add a useTLS flag to the helm chart and pass that through to the client so that we can securely connect to redis.

https://github.com/livekit/livekit/blob/4be096cf740501f95dd2a6ef5f4959dc5bc0a202/pkg/service/wire.go#L143 Sort of how its done here


2<IP_ADDRESS> version, GUI Simulation doesn't always follow path

I'm not sure if this is by design (ie some sort of optimization/path smoothing feature) or it's a bug.  But I've noticed that the center of the robot doesn't follow the path all the time.  It works perfectly for the example path but when you move some of the control points there are times when the robot (ie graphical  representation of the robot) completely leaves the path.  I noticed this when trying to get the robot to go around the sharp corner of the charge station.
BTW: Absolutely love the new version.

Yeah this is how the new path following works. It uses the pure pursuit algorithm and accelerates/decelerates on the fly instead of the whole motion profile being generated ahead of time. So, the paths you create aren't really the exact path that the robot will follow any more, they're sort of a target path you want the robot to try following.
Going to simplify it a bit so I don't explain the whole algorithm, but the lower the robot's acceleration, the further ahead in the path it needs to target in order to start following a curve without completely overshooting. But, because its targeting so far ahead it can start making a curve before actually reaching the curve in the path, causing undershooting.
I've tried to minimize this as much as possible with a few different things but the path following just can't really assume as much as the previous version since it all works based on the robot's actual state, not what the generation pre-determined it should be at a certain point in time. I still think that its a good trade-off to have a bit of overshoot/undershoot in some cases in order to gain the benefit of being resistant to error caused by collision or getting stuck on things, being able to correct odometry while path following without it being super jerky, and the ability to follow paths with discontinuities (such as paths generated with A* or the new autos that can have multiple paths without the guarantee that their start and end points perfectly line up).
You should be able to tune out most overshoot/undershoot by playing around with global constraints and constraint zones at problem areas. But, if you find any really egregious examples of over/undershooting that you can't seem to get rid of at reasonable speeds then feel free to send over the path file so I can see if I can find a way to prevent it from happening.

I'm torn with these new changes. I sort of liked the previous moving setpoint, X, Y and Theta controller model. I can see the benefits in smoothing and pure pursuit, but I also feel that if you have a control point in your path the robot should be doings its hardest to track through these control points and not cutting corners in the name of pure pursuit.  I'll have to play with the constraints to see how it plays out.
I think the path that is drawn on the GUI should be the path that the robot "should" follow if turned correctly.  I know it would take a big re-write, but could you update the GUI to display the pure pursuit path and not the Beizer path.  This would mean that the path would actually change as you change constraints (either global, zonally, or control point constraints).  Or maybe have an option that show a dotted path line that shows the projected pure pursuit path with the given constraints.  All of the code to generate the pure pursuit path is already there for the animation so all you would need to do is plot a center dot as you draw the animation of the robot following the path, and then clear these dots before restarting the animation.
Another option would be to some sort of optional dynamic adjustment of the look ahead distance that changes as you approach and leave a control points.  This would force the robot to track harder to the control points.
Thanks again for making your path planning program publicly available.

Side note.  I thought I'd have a play with the right hand side of the GUI (Autos section) to see how the effect of joining paths with discontinuous headings plays out in regards to the new pursuit stuff.
I can add an Auto by clicking the + symbol, but as soon as I try an edit it, it crashes the program.  When you come back to the program the autos section is empty again.

Fixing that crash in #323
So, there is not any actual intentional smoothing going on. The path you see is the one the robot "should" follow. It just might not be actually capable of doing so perfectly in some situations. This was also the case with the old algorithm as well, difference being that the old controller would violate the path constraints in order to minimize error. It might command the robot to go much faster than the max velocity to catch up to where it should be, or apply a greater than max acceleration in curves in order to stay on track. New algorithm actually enforces these constraints at all times (except for final deceleration to make sure it actually stops at the right spot).
Showing the simulated path would also be a bit misleading, since this is just a perfect world simulation. Robot may perform differently if its not actually capable of following with the constraints given, if the modules are not tuned properly, etc.

Or maybe have an option that show a dotted path line that shows the projected pure pursuit path with the given constraints

OR an option that leaves every plot of the animated robot rectangle drawn on the screen.  This would effectively leave behind a big fat path that "should" show where the outer edges of the robot "should" have travelled while using pure pursuit.
Only ideas.

It depends. The simulation is really only valid if you are starting to follow the path from a stop and at exactly the start point, which isn't necessarily the case when you actually follow the path. You can follow any path starting from any position with any velocity and it will work. The auto simulation is much more useful than the path simulation because of this. Still not a guarantee it will actually do what it shows, as with the old path preview system. But, I can see how the whole path of the simulation would be useful over just the robot outline at a given point in time. Will look into a way of doing that.

OK, that makes a lot more sense now.  I was only thinking from an autos perspective (ie starting at the start of the path).   I didn't realize that you now have the ability to approach a path from anywhere on the field at anytime in the match and effectively merge onto it using pure pursuit.  That's going to be a pretty cool feature.
How does that even work? Does it find the closest perpendicular point on the path and head for that and then depending on how far from the path you are, the look ahead target starts to move along the path when you get inside the lookahead distance?
You are really going to need the ability to customize the look ahead distance for tight spaces to force the robot to hug the path (like past the edges of the charge station for the season just gone).  And I suppose that it what the customizable zonally velocity and acceleration constraints are all about.
Can't wait to see this in action.  Hey another nice feature could be virtual walls.  IE: If a look ahead projection is sending you on a collision course with a wall, field element or penalty zone, have the pure pursuit following algorithm steer you around it.  And I suppose that is what  A* is all about.
Looking forward to seeing the 3015 robot in action in 2024.  This is going to be sick.

It basically chooses a point on the path X distance away from the robot. If there is no point within the lookahead distance, it will target the start of the path. This distance is determined based on how fast the robot is going, as well as its max acceleration. It needs to be further away for lower accelerations or it will massively undershoot. Trade-off being you get some undershoot to avoid a lot of overshoot.
Decreasing the lookahead distance doesn't necessarily make the robot follow the curve closer. If it is too low the robot won't start accelerating in the direction of the curve until it is too late, which causes the overshoot. Basically, the robot tries to drive towards the lookahead point. So, you can imagine that if this point is really close to the robot, when it starts to follow a curve the needed heading change for the robot would be far more than it could actually handle with limited acceleration, causing the overshoot.

#327 lets you show the center path of the simulation so you can compare it to the original bezier curve (new editor settings dropdown in the path/auto tree). Also made a tweak to the lookahead distance calculation that should make it track a bit closer. Still though, there are situations where it won't be perfect, so some manual tuning for your specific robot will be needed if you want it perfect. This will be possible before any beta release.


AWS005: clarrification / documentation

Hi! Rule AWS005 seems strange for me. One of the reasons to have a LB is to expose application without exposing the actual instances. If the application is internet facing, them the LB needs to be exposed. Is there any documents on AWS on what is the best practice?
Also, not only for this rule, but for all of them, it would be great if we can have more information within the rule itself so it is easier to understand why the rule triggered (maybe display a URL to the docs in the actual error like eslint).

Found this: https://www.cloudconformity.com/knowledge-base/aws/ELB/internet-facing-load-balancers.html

This is there primarily for awareness of public exposure rather than highlighting a definite issue. It's definitely a good idea to add a bit more information to each rule. I'll try and get to this soon.

The AWS005 rule now has a link to the wiki which includes the link you gave above - thank you!


Runtime execution over missing fields when field is optional

The current JavaScript backend code generation expects JSON with a field containing null for optional fields in the CTO model.
So for a concept:
concept C{
  o Integer a optional
}

The expected serialization is currently:
{ "$class" : "C", "a" : null }

This is inconsistent with the way Concerto validates optional fields, instead assuming the default serialization is:
{ "$class" : "C" }

It would be useful to support both serialization in Ergo.
Note that it might be less confusing to Ergo user is the default Concerto serialization use the null form, since in Ergo, you always have to write:
C{ a: none }

@dselman @mttrbrts Would love to have your thoughts on this issue. I would love to sneak this change into Concerto 1.0.
Concretely the change would be, for the Concerto model:
concept C{
  o Integer a optional
  o String b
}

Current behaviour:
validate { "$class" : "C", "b" : "Foo " } -> { "$class" : "C", "b" : "Foo " }
validate { "$class" : "C", "a" : null, "b" : "Foo " } -> { "$class" : "C", "b" : "Foo " }

New behaviour:
validate { "$class" : "C", "b" : "Foo " } -> { "$class" : "C", "a": null, "b" : "Foo " }
validate { "$class" : "C", "a" : null, "b" : "Foo " } -> { "$class" : "C", "a": null, "b" : "Foo " }

Some belief:

For the purpose of validation etc. I don't think this changes anything.
For Ergo it doesn't change anything, but the serialization is more consistent with the user code (e.g., users write C{ a: none, b: "Foo" })
For JavaScript, truthy tests as if (validated.a) { ... } still keep semantics, but some other tests, e.g., if (validated.a === null) { ... }` may change
For code generation (e.g., in Java) I think this is also more consistent (to be checked)

If I’ve understood the proposal, you’d like all optionals to be serialised as ‘null’ when absent in the JSON?
Some questions:

will impact size of the documents (many AP models have many optionals)
with the serialiser going away post v1 where would we do this? Using the Concerto API we validate the user JS object as-is. It seems awkward to have to specify null for potentially dozens of optionals.
this seems stricter in terms of model evolution, in that removing an optional now breaks all instances. Not sure that is bad, but it is interesting.

If I’ve understood the proposal, you’d like all optionals to be serialised as ‘null’ when absent in the JSON?
Some questions:

will impact size of the documents (many AP models have many optionals)
with the serialiser going away post v1 where would we do this? Using the Concerto API we validate the user JS object as-is. It seems awkward to have to specify null for potentially dozens of optionals.
this seems stricter in terms of model evolution, in that removing an optional now breaks all instances. Not sure that is bad, but it is interesting.

Hm.. interesting questions.

Size of the JSON data -- I think this is in the noise, maybe I'm wrong? Do we really care about this level of optimisation?
very very good question. I think this is the biggest one. Can we really get away without having some changes to the JSON post validation? (e.g., default values from the model?) If yes, then we might want to consider this quite carefully (or maybe it just becomes a moot point -- note we will still need a JSON -validate+convert-> path for Ergo (and different representations e.g., WASM). but that could go somewhere else.
symmetrically, currently changing an optional to a non optional would break? I think this shifts what kind of evolution would be transparent or not... I hadn't thought of that.

This makes me think we could revisit this / leaves this open until we have a better idea of the "functional validation" change.


Wrong include path order causes build error: modules/xobjdetect/src/waldboost.hpp:53:7: error: redefinition of ‘class cv::xobjdetect::WaldBoost’

Please state the information for your system

OpenCV version: 3.1.0
Host OS: Linux (Gentoo)
Compiler & CMake: GCC 5.3.0 & CMake 3.5.2

In which part of the OpenCV library you got the issue?
Build system
Expected behaviour
xobjdetect compiles fine. In particular: source include paths are ordered before system include paths.
Actual behaviour
The include path order is broken and /usr/include appears before modules/xobjdetect/include, causing following build error:
In file included from /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp:77:0:
/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/src/waldboost.hpp:53:7: error: redefinition of ‘class cv::xobjdetect::WaldBoost’
 class WaldBoost {
       ^
In file included from /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp:48:0:
/usr/include/opencv2/xobjdetect.hpp:136:18: error: previous definition of ‘class cv::xobjdetect::WaldBoost’
 class CV_EXPORTS WaldBoost : public Algorithm
                  ^
In file included from /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp:78:0:
/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/src/wbdetector.hpp:56:42: error: expected class-name before ‘{’ token
 class WBDetectorImpl : public WBDetector {
                                          ^
/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/src/wbdetector.hpp:71:15: error: cannot declare field ‘cv::xobjdetect::WBDetectorImpl::boost_’ to be of abstract type ‘cv::xobjdetect::WaldBoost’
     WaldBoost boost_;
               ^
In file included from /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp:48:0:
/usr/include/opencv2/xobjdetect.hpp:136:18: note:   because the following virtual functions are pure within ‘cv::xobjdetect::WaldBoost’:
 class CV_EXPORTS WaldBoost : public Algorithm
                  ^
/usr/include/opencv2/xobjdetect.hpp:146:30: note:       virtual std::vector<int> cv::xobjdetect::WaldBoost::train(cv::Mat&, const cv::Mat&, bool)
     virtual std::vector<int> train(Mat& data,
                              ^
/usr/include/opencv2/xobjdetect.hpp:154:19: note:       virtual float cv::xobjdetect::WaldBoost::predict(const cv::Ptr<cv::xobjdetect::FeatureEvaluator>&) const
     virtual float predict(
                   ^
make[2]: Leaving directory '/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build'

Additional description
The system header /usr/include/opencv2/xobjdetect.hpp is being included instead of the header in the source tree at opencv_contrib-3.1.0/modules/xobjdetect/include/opencv2/xobjdetect.hpp.
The reason for that is a wrong order of include directories in the call to GCC:
cd /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC "-D__OPENCV_BUILD=1" "-DCVAPI_EXPORTS" -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build" -isystem"/usr/include" -isystem"/usr/include/eigen3" -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build" -isystem"/usr/include" -isystem"/usr/include/eigen3" -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/include" -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/src" -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/core/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/imgproc/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/ml/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/imgcodecs/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/videoio/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/highgui/include" -I"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0/modules/objdetect/include" -pipe -O2 -march=bdver3 -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -mno-avx -msse3 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -ffunction-sections -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -DCVAPI_EXPORTS -x c++-header -o /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp.gch/opencv_xobjdetect_Gentoo.gch /var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv-3.1.0_build/modules/xobjdetect/precomp.hpp
Here, -isystem"/usr/include" appears (several times) before -isystem"/var/tmp/portage/media-libs/opencv-3.1.0-r2/work/opencv_contrib-3.1.0/modules/xobjdetect/include".
All the module's local directories are being added via target_include_directories(), called in ocv_target_include_directories(), when ocv_define_module() is being called. However, when actually building, -isystem".../opencv-3.1.0_build" -isystem"/usr/include" -isystem"/usr/include/eigen3" -isystem".../work/opencv-3.1.0_build" -isystem"/usr/include" -isystem"/usr/include/eigen3" suddenly appears out of thin air before them on the command line. I am unable to figure out how that command line is actually being composed.
You can find all the details in https://bugs.gentoo.org/show_bug.cgi?id=575690

Fixed in master branch: https://github.com/Itseez/opencv/pull/6410

Fixed in master branch: Itseez/opencv#6410

Sadly the issue still exists after applying the patch: build.log.zip

Could you try to disable PCH: cmake -DENABLE_PRECOMPILED_HEADERS=OFF ...?
Also please attach CMakeVars.txt file from build directory.

Also please attach CMakeVars.txt file from build directory.

There is no such file, but I can give you CMakeCache.txt, which hopefully contains the information you need: CMakeCache.txt.zip (from the build run which included 9393a0c5bb942215f15ccb0c940c23b284f19b15 but was still broken)

And again for the run with PRECOMPILED_HEADERS disabled: build.log.and.CMakeCache.txt.zip

I checked your paths, which contain dots ., but there is still no problem for CMake MATCHES condition and patched checks work as expected.
Looks like build is succeed with disabled PCH support.

Looks like build is succeed with disabled PCH support.

Yes, it did. Sorry, forgot to mention that.


Fix problems with range query

https://github.com/Dynamoid/Dynamoid/issues/41
Now it works with query like
class SomeModel
  include Dynamoid::Document

  table :name => :some_table, key: :some_hash_id

  range :some_range_id, :string

...

SomeModel.where(some_hash_id: 100,
'some_range_id.gt': 'abcd', 'some_range_id.lt': 'abxy').all

Please review :bow:
(@ananthakumaran : You may be the best one)

Thanks! It looks good. Can you squash your commits?

Thanks! It looks good. Can you squash your commits?

I did it.

I found that API will regard multiple {gt, lt}, conditions as 'OR' query.
AdapterPlugin::AwsSdkV2
supports range_between option on query method but it's not set within criteria chain at all.
I'll let it supports 'range_between' options by next commit.

Is CI working properly? Maybe some problems with DynamoDBLocal or something...

Thanks!

It helps me a lot 👍


Dev-->Master User Types blog

https://dev-blog-nrrd.app.cloud.gov/

Shannon's changes

@cthomasONRR @lpgoldstein I've incorporated Shannon's edits, please review. Thanks


Stories question

How would I get a list of recipients that have viewed a story posted by me?
Is this possible?

not as far as I am aware at this moment.

It's possible because the application does it, it should be in
/loq/all_updates output, somewhere.
On 10/02/2015 17:22, Snowlav wrote:

not as far as I am aware at this moment.
—
Reply to this email directly or view it on GitHub
https://github.com/JorgenPhi/php-snapchat/issues/91#issuecomment-73729777.

I'll do some sniffing later tonight and update you with what I can find

There is a json array, inside the story container which is called story_notes. It contains the username, timestamp and if the user screenshotted the story.


Add a Gitter chat badge to README.md

intrepion/json-api-request-library-php now has a Chat Room on Gitter
@intrepion has just created a chat room. You can visit it here: https://gitter.im/intrepion/json-api-request-library-php.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Current coverage is 100.00%

Merging #1 into master will not affect coverage as of c126103

@@            master      #1   diff @@
======================================
  Files            1       1
  Stmts            7       7
  Branches         0       0
  Methods          2       2
======================================
  Hit              7       7
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of c126103

Powered by Codecov. Updated on successful CI builds.

Oops, already added this badge manually