update subscription tracking images

Description of the change: Updated subscription tracking images
Reason for the change: Images outdated
Link to original source: https://github.com/sendgrid/docs/issues/3917

Closes #

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hello @productdana,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX

Hello @productdana,Thanks again for the PR!                                         We noticed that you have earned 3 out of the 5 points needed to receive glorious SendGrid Hacktoberfest swag.                                         Please take a moment to checkout this link to find more issues to get you past the required threshold.                                         Also, please be sure that you have officially registered here.                                         Thank you and Happy Hacktobering!                                         Team SendGrid DX


Your email is not working

Your smartcontractsolutions.com email is not relaying emails.

Free btc now

Thanks for reporting this. We are now using an openzeppelin.org email.


post_recipient not implemented

First off, great job on this module - thank you very much.
SendGrid.post_recipient(params: params) gives undefined method `post_recipient' for #SendGrid4r::Client:0x007fee833b2878
To get around this I've implemented post_recipients with just a single recipient. The documentation should either be updated or the code added to support the method.
Thanks again for a great module. Huge time saver.

Thanks for reporting.
I will take a look shortly.

The post_recipient() has been removed from ver 1.2.0.
https://github.com/awwa/sendgrid4r/commit/baa8b9d844d8f453ca1a99dfa68fe9e54ec1ac35
Because SendGrid has removed the single post endpoint.
Could you please use the post_recipients() with single item array argument?
I have removed the post_recipient() from the documentation.

Hi,
It appears post_recipient() is still in the documentation.
#post_recipient_to_list
Add a Single Recipient to a List.
recipient = {}
recipient['email'] = @email1
recipient['last_name'] = @last_name1
recipient['custom_field_name'] = 'pet'
recipient = @client.post_recipient(recipient)
client.post_recipient_to_list(list_id: list.id, recipient_id: recipient.id)

Also, because this, and RoR in general, is still relatively new to me, can you explain why client is an instance variable in:
recipient = @client.post_recipient(recipient)

but not so in:
client.post_recipient_to_list(list_id: list.id, recipient_id: recipient.id)

I'm assuming code above this would include:
require 'sendgrid4r'
client = SendGrid4r::Client.new(api_key: 'api_key')

Thanks!

Thanks. The documentation was not updated. I have updated them.

Thanks!


Tests (where relevant) don't actually make sure that an exception was thrown.

Tests like these:
https://github.com/Mojang/brigadier/blob/cf754c4ef654160dca946889c11941634c5db3d5/src/test/java/com/mojang/brigadier/StringReaderTest.java#L239-L247
will actually pass if no exception is thrown.

According to this random article I found, JUnit 5 has an assertThrows that returns the exception if a matching one is found (and fails otherwise), which is probably the ideal thing for this kind of test.  JUnit 4 has the ExpectedException rule, but I don't think that it would be usable for this purpose.
The easiest approach, and one that already seems to be used by some of the existing tests, is to call fail() after the code that should throw the exception.  That's easy enough that I'll look into making a PR for it.

JUnit 4 also has an assertThrows method since version 4.13, see https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method
Also Brigadier uses the old Maven artifact coordinates for JUnit: junit:junit-dep:4.11
It should switch (and update) to junit:junit:4.13.2


Column display label different from column name

I'm submitting a ...  (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here

Current behavior

No way to provide different column name and display label. Templates can work as a workaround but not convenient.
Expected behavior

We should be able to provide a display label different from column name. Because backed services send data which is closer to an identifier e.g. exchangeRate but in UI you would display it as 'Exchange Rate'.
Column name should be used to look up value for cell whereas displayLabel should be used for header.
Reproduction of the problem

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Table version: 0.7.x

Angular version: 2.0.x

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]

Can't you use 'prop' to specify the property name.  I think what you want is already supported.

Yes I think it is already supported. Just that I was not aware of it.

Can someone please explain prop with an example ?

And how to use that prop?
I'm really surprised there is no such property of ngx-datatable-column as "Label" or "Caption".
It's common scenario when you bind column to some object property and want to display other column title.

@andrew-kuzovov
You can define an arraywith N object (1 x every row) and pass it to the columns. If you generate a custom datatable-column you can generate your column header with any value.
Object to columns property:
 gridColumns = [
        { id: "qa", label: "Codi", size: 1},
        { id: "rulename", label: "Nom Regla", size: 1 },
        { id: "path", label: "Camps on s'aplica", size: 2 },
        { id: "params", label: "Paràmetres de regla", size: 3 },
        { id: "criticality", label: "Criticitat", size: 1 }
   ];

In the [name] you pass the id and in the {{ col.label }} your custom and visible name for the column.
Component Template:
<ngx-datatable-column *ngFor="let col of gridColumns " [flexGrow]="col.size || 1" [name]="col.id" [sortable]="true" [canAutoResize]="true" [draggable]="true" [resizeable]="true">
            <ng-template ngx-datatable-header-template let-sort="sortFn" *ngIf="col.label">
                <span (click)="sort()">{{ col.label }}</span>
            </ng-template>
</ngx-datatable-column>

prop usage appropriately:

{{ value.clientCode }}  - {{ value.clientName }}

       <ngx-datatable-column name="My Custom Column Header" prop="client">
        <ng-template let-value="value" ngx-datatable-cell-template>
          <strong>{{ value.clientCode }} </strong> - {{ value.clientName }}
        </ng-template>
      </ngx-datatable-column>

the above code is just to show how to use label/column-title and prop properly


Spanish translations needs to be updated and other languages as well

What happened?
I changed the language from English to Espanol but not all the words changed to Espanol. Same in other languages.
Please reproduce in steps

Go to change the language selection
Change language

Expected Behavior
Other words should also be translated
What browsers are you seeing the problem on?
Chrome
At which address did you encounter bug?
beta.kodadot.xyz
Are you logged in?
Yes
Which wallet you are using?
PolkadotJS
At which chain did you encounter bug?
Basilisk
Screenshots

Relevant log output
No response
Payment link for reward
https://kodadot.xyz/transfer/?target=<FRd1rG6vs8qCW43BVK3KgCdWLyF7HqgT5HxdhN9nWmfq7Em
https://github.com/kodadot/nft-gallery/blob/main/CONTRIBUTING.md#creating-your-ksm-address>
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi , feel free to add your language content here, you can find more information on the Kodadot documentation

Hey there, since I took it upon me to provide the german translation some questions popped up.
I made the fork and started to edit and also checked on some other translations how they went through it, I noticed that it's not making sense to translate every line e.g. gallery/Gallery. Since I want to do it right i would appreciate some guidance :)
Thank you 💯

Hey there, since I took it upon me to provide the german translation some questions popped up.
I made the fork and started to edit and also checked on some other translations how they went through it, I noticed that it's not making sense to translate every line e.g. gallery/Gallery, since there is basically only a noun. What also puzzled me was that the first line consist of 'translation' and 'english', from my understanding i would fill in the translations under translation and not under english.

Since I want to do it right i would appreciate some guidance :)

Thank you 💯

closed in #4001, continue in #3935


Epsilon values can disappear with FP16

With this change, the default behavior of has_value changed.
Previously the float tolerance was 1e-12
This value now calculated from std::numeric_limits<dtype>::epsilon()
This means the float value will be 1.19209e-07 and the half value will be 9.76562e-04.
This can cause problems with normalizations (by default it is 1e-05 in ONNX spec.), where the eps value can be smaller (e.g. keras uses 1e-07).
For example, during most norm parsing it will be clipped to 1e-07 for half. (This should be lowered to 1e-05 probably.)
Also, not every model has it as a layer, rather just raw ops. With those, it could be any arbitrary small number. And multiple tests use smaller eps as well.
The problem is that currently the default 1e-5 will still be optimized out for half during find_unit_ops. And with the current function args, the tolerance can't be lowered.
This can fail matchers which depend on adding eps. And without it, normalizations can produce inf numbers during runtime.
To reproduce the issue, you can use this script
Calling python3 -c "import gen_llamanorm; gen_llamanorm.llamanorm_test()"
Compiling e.g. to ref fp16 to ignore fusing:
MIGRAPHX_TRACE_PROPAGATE_CONSTANT=1 MIGRAPHX_TRACE_ONNX_PARSER=1 MIGRAPHX_TRACE_MATCHES=1 MIGRAPHX_TRACE_FINALIZE=1 MIGRAPHX_TRACE_COMPILE=1 MIGRAPHX_TRACE_PASSES=1 migraphx-driver compile llamanorm_test.onnx --fp16 --ref
Which will call propagate_constant (because of quantize_fp16), and convert 1e-05 (float) to 9.95398e-06 (half).
Later Matched by migraphx::find_unit_ops, where 9.95398e-06 < 0.000976562 will eliminate this literal with add.
But 1e-05 < 0.000976562 would also be optimized out.
A verbose log (including has_value params) is attached: comp_llamanorm_fp16_ref.log

We can probably update the tolerance on the find_unit_ops matcher to be more strict.

The tolerance for find_unit_ops searching for a zero value would have to be 0 for absolute then. Which would only match an exact zero value, since the relative tolerance would also be multiplied by zero. I presume this is the intended behavior because I do not see a way of determining between an intentional epsilon value and a something that's supposed to be zero.

Fixed with https://github.com/ROCm/AMDMIGraphX/pull/2696


Naming of arrays / sequences

Context and Problem Statement
The current use of the terms array and sequence is inconsistent:
Specification: type T is array of E
Python: Array, ArrayType, ArrayValue
SPARK: Message_Sequence, Scalar_Sequence
The mainly used term array might not be the most suitable.
Considered Options
O1: Consistently use array
Specification: type T is array of E
Python: Array, ArrayType, ArrayValue
SPARK: Message_Array, Scalar_Array
+ Specification syntax is similar to Ada, although not identical
– Specification uses same term as Ada, although semantics differ: no specification of index type, no direct access to array elements possible
– array often refers to collection of fixed-size elements, which is not necessarily the case in our specification
O2: Consistently use sequence
Specification: type T is sequence of E
Python: Sequence, SequenceType, SequenceValue
SPARK: Message_Sequence, Scalar_Sequence
+ Makes divergent syntax and semantics to Ada arrays clear
+ Similar use in ASN.1
O3: Consistently use list
Specification: type T is list of E
Python: List, ListType, ListValue
SPARK: Message_List, Scalar_List
+ Makes divergent syntax and semantics to Ada arrays clear
– list usually refers to collection of heterogeneous elements, which is not the case here
– Name conflict with Python´s typing.List
O4: Use array and sequence interchangeably
Specification: type T is array of E
Python: Array, ArrayType, ArrayValue
SPARK: Message_Sequence, Scalar_Sequence
+ No changes needed
– Inconsistent
Decision Outcome
TBD

O2 seems to me to be the best option.

I agree that O2 is the cleanest solution.


Add .editorconfig

In #508, my commits included whitespace errors (text files with no \n on the last line).
This adds an .editorconfig file to automatically configure text editors to insert that final newline, and to configure indentation.

I have added a PR that checks Markdown linting https://github.com/grafana-operator/grafana-operator/pull/527
it should partly solve this PR.
The thing that it misses is the yaml checks.
But as I wrote earlier it would need a job to ignore a number of files. It's possible using the https://github.com/github/super-linter that I use in my PR but it's something that would need to get done.
Do you think that would be an option @silverlyra and something that you would be willing to look in to?


fix: SearchView data persists on rotation

Fixes #862
Changes:
Added MutableLiveData in SearchViewModel and setting the value to that through onQueryChange listener. A logic is added to check whether the MutableLiveData is set or not.
Screenshots for the change:

@nikit19 @iamareebjamal Do review and suggest changes if any.

Squash your commits


Add Sublime Ctrl+P-like filename search

Any news?

This is a high-priority feature and will be implemented when I or someone else has time. PRs welcome!

The code is mostly there, in lib/ui/BaseFindForm.js.
If you want to make it fancy and show a list of results, rather than just showing the closest match to the query, it is a bit more complicated but also relatively simple -- you'll want to expand the FileFindForm few rows taller to make room for the result list.

Fuzzy matching library from Atom: https://github.com/atom/fuzzaldrin


Auto-generate TypeScript client with types from Cadet's documented Swagger API

Description
Using https://github.com/acacode/swagger-typescript-api, a TypeScript-based client with types is generated from the cadet backend's swagger.json.
TODO:

[ ] Add documentation

Basic instructions

Copy swagger.json to src/commons/api/
Run yarn run update-cadet-api

[ ] Avoid typecasting
[ ] Ensure generated types are accurate
[ ] Switch from fetch to the new API globally

Type of change

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

How to test
Run the test suite.
Checklist

[ ] I have tested this code
[ ] I have updated the documentation

Yes, yes, so much yes. This is probably the best thing that's happened in the frontend code-quality wise ever since it was written. Looking forward to seeing this merged :)

Hmm, anyone looking after this PR? @bnjmnt4n ? There is enthusiastic support from @angelsl . But still in draft and currently with merge conflict...

Sorry for the delays. I was planning to come back to it, and will take a look at it hopefully this weekend.

Reviewing our open PRs and this one comes up again.  @bnjmnt4n do you have time these days? There is/was enthusiastic support from @angelsl . But still in draft and currently with merge conflict...

This will need quite a bit of time to properly convert all the places in the frontend that make requests to the backend. And we need to make sure the backend Swagger definitions are accurate as well (unfortunately Elixir is dynamically typed so it's not possible to generate Swagger definitions from type information...)
It'll be tedious but worth it.


CordovaOauth only detected basic permission in Instagram

I am using cordovaOauth https://github.com/nraboy/ng-cordova-oauth to authorizate the user with instagram .
My problem is that when the user authorizate with api only accepts the basic permissions not view others . as you can see I 'm having permits [ " basic" , " relationships " , " public_content " , " follower_list " ] but when the user enters data and accepts only warranted against the basic . What am I doing wrong ? Sorry for my English . Thank you . a greeting. My code :
var igscope = ["basic","relationships","public_content","follower_list"];
            var CLIENT_ID = "XXXXXXXXXXXXXXXXXXXXXXXX";

    $cordovaOauth.instagram(CLIENT_ID,igscope).then(function(result) {

        $scope.usuario.token = result.access_token;
        userFactory.setUser($scope.usuario);

        $timeout( function() {
            $state.go('app.browse');
        }, 200 );
});

Do you get an access token in your response?

Yes i get the token generate in the response correct . But this token is generate with only basic permissions .

If you're getting an access token, then this plugin is working correctly.  I don't offer free support for this plugin anymore because the demand is too high.  You can purchase support from myself or @matheusrocha89 or you can take it to Stack Overflow and the Instagram documentation.
Best,


create-paketo-buildpacks guide with packit v2

Problem

I created a buildpack using packit as described here. While looking at the source code for the cpython buildpack I noticed that it is using using packit/v2 (here) which is different than what is described in the guide I followed. Should v2 be using going forward and should the guide be updated to reflect this change?
Affected page(s)

Anyone following the guide on how to create a buildpack using the packit library.

Checklist

[ ] I have included links to page(s) that need to be changed

https://github.com/paketo-buildpacks/paketo-website/edit/main/content/docs/howto/create-paketo-buildpack.md
There is a small error here that should be fixed if/when this page is updated.
https://github.com/paketo-buildpacks/paketo-website/blob/main/content/docs/howto/create-paketo-buildpack.md?plain=1#L329
This holds section holds buildpack specific metadata
should be:
This section holds buildpack specific metadata

Thanks for calling this out, @jpena-r7. That guide should definitely be updated to use packit v2!


SSL not working

I just got the latest mup working on my project, but I'm still having trouble when enabling SSL.  Has anyone seen this behavior before?  When my Meteor project is running on the target, I experience:

Port 80 properly sends a redirect to https (using Meteor package force-ssl)

Port 443 accepts connections from localhost, but then immediately disconnects.

Port 443 rejects connections from all outside, even when telnetting to the hostname from the same host.

Yet netstat -tulpn lists ports 80 and 443 as listening properly (I think -- not really an expert on IPv6 addresses):
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 <IP_ADDRESS>:27017         <IP_ADDRESS>:*               LISTEN      1790/docker-proxy
tcp6       0      0 :::80                   :::*                    LISTEN      4940/docker-proxy
tcp6       0      0 :::22                   :::*                    LISTEN      1186/sshd
tcp6       0      0 :::443                  :::*                    LISTEN      5023/docker-proxy

As far as I can tell (from iptables and my OpenStack configurator), it's not an issue with my own firewall. I also haven't changed anything since old-mup was working and was properly serving https over port 443.
Here is the relevant part of my mup.js (sanitized to remove hostnames):
module.exports = {
  meteor: {
    ...
    dockerImage: 'abernix/meteord:base',
    buildOptions: {
      serverOnly: true,
      buildLocation: '/scratch/build'
    },
    env: {
      ROOT_URL: 'https://hostname.domainname',
      PORT: 80,
      MONGO_URL: 'mongodb://localhost/meteor'
    },
    ssl: {
      // pem: '../host.ssl/host.pem'
      crt: '../host.ssl/host.crt',
      key: '../host.ssl/host.key',
      port: 443
    },
    deployCheckWaitTime: 150
  }
  mongo: {
    oplog: true,
    port: 27017,
    servers: {one: {}}
  }
}

Maybe there's some issue with my SSL crt/key pair?  (With old mup, I used the .pem file.  I also tried setting crt and key to the pem file.)  Are there logs somewhere I can investigate to see what's wrong with the SSL proxy?
mup deploy is working fine, and mup logs shows nothing of interest.

I have the same trouble, and inside the syslog I found this:
No such image: meteorhacks/mup-frontend-server:latest
this is for sure the problem with SSL.
If I comment out the SSL part my app deploy correctly.

Any updates/ideas on this?  I tried updating to the new Meteor, but still can't deploy my server, which is pretty annoying.  No error messages (as Meteor is running, and is correctly redirecting http to https), but telnetting to localhost port 443 leads to immediate disconnect, while telnetting to the host at port 443 gives "connection refused".
Here is the bottom of my syslog, which doesn't seem to reveal much (but I'm not very familiar with docker). Does docker have its own firewall?...
Nov 22 18:33:14 hostname kernel: [1126112.223654] docker0: port 2(veth0502b1c) entered disabled state
Nov 22 18:33:14 hostname kernel: [1126112.270872] docker0: port 2(veth0502b1c) entered disabled state
Nov 22 18:33:14 hostname kernel: [1126112.271316] device veth0502b1c left promiscuous mode
Nov 22 18:33:14 hostname kernel: [1126112.271323] docker0: port 2(veth0502b1c) entered disabled state
Nov 22 18:33:15 hostname kernel: [1126112.568493] docker0: port 3(veth17beb2f) entered disabled state
Nov 22 18:33:15 hostname kernel: [1126112.568851] device veth17beb2f left promiscuous mode
Nov 22 18:33:15 hostname kernel: [1126112.568858] docker0: port 3(veth17beb2f) entered disabled state
Nov 22 18:33:16 hostname ntpd[2439]: Deleting interface #17 veth0502b1c, fe80::84b8:61ff:fe8d:adec#123, interface stats: received=0, sent=0, dropped=0, active_time=1112619 secs
Nov 22 18:33:16 hostname ntpd[2439]: Deleting interface #16 veth17beb2f, fe80::cd2:4ff:fe8a:8f82#123, interface stats: received=0, sent=0, dropped=0, active_time=1112619 secs
Nov 22 18:33:16 hostname ntpd[2439]: peers refreshed
Nov 22 18:33:49 hostname kernel: [1126146.758827] device veth52af827 entered promiscuous mode
Nov 22 18:33:49 hostname kernel: [1126146.759117] IPv6: ADDRCONF(NETDEV_UP): veth52af827: link is not ready
Nov 22 18:33:49 hostname kernel: [1126146.935929] IPv6: ADDRCONF(NETDEV_CHANGE): veth52af827: link becomes ready
Nov 22 18:33:49 hostname kernel: [1126146.935963] docker0: port 2(veth52af827) entered forwarding state
Nov 22 18:33:49 hostname kernel: [1126146.935966] docker0: port 2(veth52af827) entered forwarding state
Nov 22 18:33:50 hostname kernel: [1126147.457174] device veth3e550ff entered promiscuous mode
Nov 22 18:33:50 hostname kernel: [1126147.457322] IPv6: ADDRCONF(NETDEV_UP): veth3e550ff: link is not ready
Nov 22 18:33:50 hostname kernel: [1126147.457326] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:33:50 hostname kernel: [1126147.457331] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:33:50 hostname kernel: [1126147.683912] IPv6: ADDRCONF(NETDEV_CHANGE): veth3e550ff: link becomes ready
Nov 22 18:33:54 hostname kernel: [1126152.034066] docker0: port 3(veth3e550ff) entered disabled state
Nov 22 18:33:54 hostname kernel: [1126152.040855] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:33:54 hostname kernel: [1126152.040863] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:33:55 hostname ntpd[2439]: Listen normally on 18 veth3e550ff fe80::dc9a:49ff:feaa:5c1d UDP 123
Nov 22 18:33:55 hostname ntpd[2439]: Listen normally on 19 veth52af827 fe80::6ce7:14ff:fe2b:3532 UDP 123
Nov 22 18:33:55 hostname ntpd[2439]: peers refreshed
Nov 22 18:33:55 hostname ntpd[2439]: new interface(s) found: waking up resolver
Nov 22 18:33:58 hostname kernel: [1126155.862066] docker0: port 3(veth3e550ff) entered disabled state
Nov 22 18:33:58 hostname kernel: [1126155.869040] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:33:58 hostname kernel: [1126155.869047] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:34:04 hostname kernel: [1126161.952015] docker0: port 2(veth52af827) entered forwarding state
Nov 22 18:34:11 hostname kernel: [1126168.852165] docker0: port 3(veth3e550ff) entered disabled state
Nov 22 18:34:11 hostname kernel: [1126168.853351] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:34:11 hostname kernel: [1126168.853359] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:34:26 hostname kernel: [1126183.904096] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:34:53 hostname kernel: [1126210.813757] docker0: port 3(veth3e550ff) entered disabled state
Nov 22 18:34:53 hostname kernel: [1126210.815290] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:34:53 hostname kernel: [1126210.815298] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:35:08 hostname kernel: [1126225.824038] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:37:27 hostname kernel: [1126364.972239] docker0: port 3(veth3e550ff) entered disabled state
Nov 22 18:37:27 hostname kernel: [1126364.973589] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:37:27 hostname kernel: [1126364.973600] docker0: port 3(veth3e550ff) entered forwarding state
Nov 22 18:37:42 hostname kernel: [1126380.000047] docker0: port 3(veth3e550ff) entered forwarding state

I found the issue.  Three problems:

I didn't run mup setup after adding the SSL configuration.  Obvious, in hindsight.  Would have been helpful to have an error message, but this is definitely on the side of user error.

For some reason, there were existing bundle.crt and private.key directories which prevented the copy from working.  (I got good error messages saying the copy failed.)  I'm guessing these were leftovers from the old mup or from some previous poor configurations.

$ ssh host ls -l /opt/projectname/config/
total 16
drwxr-xr-x 2 ubuntu root   4096 Nov  9 17:36 bundle.crt
-rw-r--r-- 1 ubuntu ubuntu  549 Nov 22 18:33 env.list
drwxr-xr-x 2 ubuntu root   4096 Nov  9 17:36 private.key
-rw-r--r-- 1 ubuntu ubuntu 1167 Nov 22 18:33 start.sh

I needed to specify my .pem file instead of my .crt file as my crt.  Otherwise I got the following message:

nginx: [emerg] PEM_read_bio_X509_AUX("/bundle.crt") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE)
        nginx: configuration file /opt/nginx/conf/nginx.conf test failed

Anyway, now everything is working!


[KOGITO-2688] Removing listType=map from non-required objects

Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>See:
https://issues.redhat.com/browse/KOGITO-2688
This needs to be on 0.12.0, otherwise users will fail to install all the CRDs in Kubernetes 1.18, like the newer minikube.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

I always have one question in mind, Why we are commiting auto-generated file in Github? Generally we don't do so

Those files are needed for the whole project to work since they implement necessary functions for our inner types to work with Kubernetes. In Golang this is pretty common to generate boilerplate functions to extend some functionality.

I always have one question in mind, Why we are commiting auto-generated file in Github? Generally we don't do so

Those files are needed for the whole project to work since they implement necessary functions for our inner types to work with Kubernetes. In Golang this is pretty common to generate boilerplate functions to extend some functionality.

Sorry If I am not clear with my last statement, I am not asking to remove these files from project. I just checking that because these are auto-generated files and ideally developer should not suppose to make any change in these files directly so there is no need to checkin these files in GitHub repo. These will be auto generates when Jenkins perform its build.
With this approach we prevent lots of issue where developer miss to compile/commit these files. Or Develeloper have different version of Operator-sdk on his system which cause him to generate wrong files

We need those files in the repository, otherwise our types won't work and will fail in case of anyone uses the package. It's not a matter of generating those files for runtime only.


Potential regression with Whitebox testing of JPMS-based Java module

Expected Behavior

Without a module-info.java file in test/java, Gradle should generate a test command relying on java's --class-path argument (cf https://docs.gradle.org/current/userguide/java_testing.html#whitebox_unit_test_execution_on_the_classpath).
Current Behavior

Gradle generates a test command relying on JPMS-related arguments (--module-path, --patch-module, ...).
Context

I'm using Gradle 7.4.2. Trying to test (build and run works, at least the Gradle part) project https://gitlab.com/sosl/sosl/-/tree/Modularization
Steps to Reproduce

Clone project https://gitlab.com/sosl/sosl; checkout branch Modularization; run "./gradlew --info build"
git clone --branch Modularization https://gitlab.com/sosl/sosl.git
git checkout e80315b2f7838c854d50646b6059ebe156772cd9
./gradlew --info clean test

Your Environment

Build scan URL: https://gradle.com/s/uepka7o37c4sm (old one https://gradle.com/s/ykpxd3dgukk2y)

The problem with the command currently generated by Gradle (.../java ... --module-path ...build/classes/java/main:...build/classes/scala/main:... ... --patch-module sosl=...) is probably linked to the fact that ...build/classes/scala/main does not contain a module-info.class file.
Either:

I have a problem with my build setup, and Gradle should generate a command based on --class-path instead of --module-path ;
module-info.java should be in both directories build/classes/java/main et build/classes/scala/main, but I doubt Java would like it ;
the argument "--patch-module sosl=..." should include the '.../build/classes/scala/main' which it does not currently.

Not a regression, behaves the same way with all recent Gradle versions. Re-classifying it as a bug.

There is probably a problem with the build of the above-mentioned project (I'll investigate that point next).
I however did an MCVE (git clone --branch JPMS https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms.git) and there are 1 nonobvious constraint and 2 points "incorrectly" handled by Gradle natively when using Gradle with JPMS and sources in Java and Scala.

Java and Scala sources must not share packages (a Java class and a Scala class declared to be in the same package). As Java classes and Scala classes end up in 2 different directories, there is no way to combine them at "runtime". If using JPMS, java seems to expect classes in the same package to be in the same directory (potentially linked to the fact that the content of packages can not be declared in different modules).
Natively, Gradle assumes Scala sources depend on Java sources. Inverting this dependency is not "natural".
When compiling the java sources (which contain the file module-info.java), scala classes must be added to the classpath and the compiled module must be declared to "read" the unnamed module.

The 2 last points are potentially linked to the fact that I was unable to "properly" invert the dependency between Scala and Java sources.

It seems it was not a bug or regression after all. However, with the default conventions, projects mixing Scala, Java, and JPMS do not work out of the box. I was able to 'fix' an MCVE (https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms/-/tree/JPMS) with the help of Vampire on the Slack community.
The bottom line (in addition to having to set the dependencies between scala and java if not using the ones from the convention) seems to be that Java compilation tasks rely on the classes directory to find modules. It does not work if the sources of a single module are built by different tasks (as is sometimes the case in a project mixing Scala and Java). A 'better' approach may be to rely on already built Jar libraries. It however requires interlacing compilation tasks with jar tasks (jar libraries must be built after contained class files have been produced and before the compilation of sources relying on those libraries).


Additional user profile properties

The user should be able to enter additional, personal information in her/his user profile. Therefore, the "user profile" view should be extended to provide additional input fields:

Academic degree (optional, simple text input, e.g. "Diplom-Wirtschaftsinformatiker")
Position profile (optional, simple text input, e.g. "Software Architect")
Summary (optional, multi-line text area)
Industry sectors (optional, chips input allowing to enter multiple simple texts, e.g. ["Automotive", "Telecommunication"])
Specializations (optional, chips input allowing to enter multiple simple texts, e.g. ["IT Consulting", "Software Integration"])
Certificates (optional, chips input allowing to enter multiple simple texts, e.g. ["Java Certified Programmer"])
Languages (optional, chips input allowing to enter multiple simple texts, e.g. ["Deutsch"])

Extension of the user profile view:

When accessing the "user profile" page the additional input fields must be prefilled with the values received with the API response from the server, i.e. response of GET /users/{userId}.
When the user clicks the save button on the "user profile" page the additional information must be transmitted to the server within the API request, i.e. PUT /users/{userId}.

I removed the description part saying that "Languages" must contain at least one item. This was somehow inconsistent with the optional behavior of this input field. 😉


Bugs: AccessDeniedException: Resource is not in the state functionActive

Version: v1.0.9
When I deployed, I got the following error in CloudFormation Event message.
(This deployment has no changes in Lambda, IAM Role and IAM Policy, only Custom Resource has changes for update.)
ECSConstruct/EcrConstruct/ImageScannerWithDockle/Default/Default (ECSConstructEcrConstructImageScannerWithDockle0DCA0262) Received response status [FAILED] from custom resource. Message returned: AccessDeniedException: Resource is not in the state functionActive
    at Object.extractError (/var/runtime/node_modules/aws-sdk/lib/protocol/json.js:61:27)
    at Request.extractError (/var/runtime/node_modules/aws-sdk/lib/protocol/rest_json.js:61:8)
    at Request.callListeners (/var/runtime/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
    at Request.emit (/var/runtime/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
    at Request.emit (/var/runtime/node_modules/aws-sdk/lib/request.js:686:14)
    at Request.transition (/var/runtime/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/var/runtime/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /var/runtime/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/var/runtime/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/var/runtime/node_modules/aws-sdk/lib/request.js:688:12) (RequestId: xxxxxxxxxxxxxxxxx)

Custom Resource Provider Role Policy missing?
https://stackoverflow.com/questions/76819690/accessdeniedexception-resource-is-not-in-the-state-functionactivev2-at-object-e

However, when I retried, I succeeded...

I'll close it this time for now.

Tried it multiple times with different stacks, but they say it will be the first.
And in all, retries are successful.

Provider has next policies.
AWSLambdaBasicExecutionRole
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "lambda:InvokeFunction",
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:dev-main-BastionTunnel-CustomImageScannerWithDockl-hzy008aOF787",
                "arn:aws:lambda:ap-northeast-1:123456789012:function:dev-main-BastionTunnel-CustomImageScannerWithDockl-hzy008aOF787:*"
            ],
            "Effect": "Allow"
        }
    ]
}

Retry succeeds, so I'll close it this time for now...

What policy you have added to your role?  I am also getting the same AccessDenied error.

Users of this library do not need to specify explicit policies.
Apparently this is a bug on the aws-cdk side.
https://github.com/aws/aws-cdk/issues/26838


Pre-build scenarios for less powerful systems

Hi,
So I am looking to use this library on an ARM6 system with very low specs.
I already have the latest version of nodeJS and npm installed, aswell as maria db.
My problem is when installing this module with no precompiled binary available on AWS, it trys to compile itself but the system has such low processing power and with it being headless over a SSH session, during the process (hour or 2 in) the SSH connection closes and the build process subsequently stops.
Just wondering if there is a way to pre-compile the binaries on a seperate more powerful system (arm7), and make the install on the ARM6 system used the pre-compiled binary from a custom location.
Would really like to use this on IOT devices.

@Truemedia
Possible solutions

cross-compilation from a more powerful system
using a tool like tmux to keep apps running over SSH in a detached mode
compiling in a VM from a more powerful system

ARMv6 is not a very popular platform, I do not see it getting prebuilt binaries for it soon.

Will look into those options thanks

See https://github.com/mapbox/node-sqlite3/issues/418#issuecomment-484224355 for a way to cross build with Docker.


A hard time to implement a RESTful API in a middleware

This is the extend of our discussion on Twitter in relation to https://github.com/SchumacherFM/mailout/commit/d31087daef8179639cdf5153ab3225fe87e00dc8
I'm having a hard time to implement a RESTful API design for the new caddy middleware https://github.com/SchumacherFM/mailout
Especially this line https://github.com/mholt/caddy/blob/master/server%2Fserver.go#L322
		// Fallback error response in case error handling wasn't chained in
		if status >= 400 && w.Header().Get("Content-Length") == "" {
			DefaultErrorFunc(w, r, status)
		}

breaks everything when I use HTTP status >= 400 codes in the middleware return argument as suggested like here.
My fix is now to always return a 200 Status Code to Caddy and call WriteHeader(anyCode) before returning. That was never in the mind of the inventor.
I'm not that into the internal API design of Caddy and I hope we can find a solution ... or leave it as it is because my hack works now ;-)

Suggestion -- I know this may feel a little hacky, but it's actually correct, I think.
Write the >=400 status code to the response (WriteHeader()), but return 0 for the status code (the first return value). You should still be able to return an error if you want it logged, for example, and it shouldn't affect the response.
That should preserve your API design. (Right now you're returning 200 instead of 0. I think that's fine, but it might be slightly misleading, semantically.)

Perfect! The mailout ServeHTTP handler returns now zero or a real error to Caddy, all other status gets written directly to the client.!
Thank you!

FWIW I brainstormed ways to improve the design last night, and I think I have an idea, although it needs a little more work. Will probably post an issue for it soon.

Cool!
Maybe please refer me in the issue that I can get a notification :-)

So, thinking now that the signature won't change much because it actually is effective, I think, even for REST APIs. After re-reading my godoc, I realize I could make it clearer in the documentation. I want your feedback.
How about this revised godoc for middleware.Handler:

Handler is like http.Handler except ServeHTTP may return a status
code and/or error.

If ServeHTTP writes to the response body, it should return a status
code of 0. This signals to other handlers above it that the response
body is already written, and that they should not write to it also.

If ServeHTTP encounters an error, it should return the error value
so it can be logged by designated error-handling middleware.

If writing a response after calling another ServeHTTP method, the
returned status code SHOULD be used when writing the response.

If handling errors after calling another ServeHTTP method, the
returned error value SHOULD be logged or handled accordingly.

Otherwise, return values should be propagated down the middleware
chain by returning them unchanged.

Does this make sense? Is it clear?

I do feel better and my ServerHTTP function already uses this behaviour. 😀
Thank you!

Cool, thanks. I've updated the wiki too, with a better description of the return values.


Builds still failing - '../Fabric/Fabric+FABKits.h' file not found

So I am in the process of trying to switch off of phonegap build to a local cordova setup in hopes of getting deep links working in iOS.  Unfortunately, I still can't get the app to build with the latest version of the branch cordova plugin.  The error on the latest checked out from master (I have pretty much given up on using npm at this point) is still throwing an error: "'../Fabric/Fabric+FABKits.h' file not found".  Any idea what's going on here?  I thought this was fixed.  Before this, I had the plugin locked into version 2.0.9 on npm and that still worked, I just wasn't sure if it had everything to get the universal links working.  They didn't seem to be with my tests so I figured I'd get the latest off git and see if I had any more luck that way.

I guess what version started supporting the new link formats with the xxxx.app.link?  I'll just set it to that version and see if I can get the deep links working.

I had resolved that issue on NPM with the latest version: 2.1.7. The problem was that NPM was collapsing all of the source files to 1 directly, making ./Fabric/Fabric+FABKits.h an invalid directory reference.
Which version were you trying that caused it to break?

So I'm installing it via npm.  I used to have to fixed at 2.0.9 which was working, but I  was afraid it didn't support the new link convetions with the xxxx.app.link schemes.  So I tried to completely remove the project and re-build it adding the plugin like so: cordova plugin add branch-cordova-sdk --variable BRANCH_KEY=branchKey --variable URI_SCHEME=uriScheme.  After I updated to latest, I'm still seeing that Fabric.h error.  So I guess the npm fix didn't get rolled out or something?

The same error occurs when I install the plugin directly from git, so it doesn't look like a npm issue, cutting the uncertainty of installing from npm out of the equation like so: cordova plugin add https://github.com/BranchMetrics/cordova-ionic-phonegap-branch-deep-linking.git --variable BRANCH_KEY=branchKey --variable URI_SCHEME=uriScheme

Sorry, disregard that previous comment.  I hadn't updated the code on my build machine to use the git repo.  Now I did and the iOS builds are passing.  That said, I'll leave this ticket open to address the npm issue which still stands.  I'll just continue building off git.

Well the good news, after switching to using the master out of git, everything builds perfectly and I was FINALLY able to get universal links working in iOS.

cool, good to hear that this issue is now resolved.
Will close the issue now. Thanks @gabaum10

Well, the npm issue is not resolved, which is why I left this open.  You guys probably want to try and fix that for future npm use.  Building out of git works fine though.


Fix bonus not received

Description
gdstore was bound to the state the effect was defined, so isLoggedInCitizen was always false
separate the bonus check interval into a new effect bound to gdstore
since we also call bonus check on init, if gdstore is false then check wallet.isCitizen
About #1060

@AnastasiiaOdnoshevna do we have bonus test in automation?


Add docker compose script

Add docker compose script to handle restarting the noip service after reboot

Thank you for creating this. It is a simple addition that some people have asked for, so we see no reason not to add a Docker Compose template and snippet to the Readme.


Add boolean return value for inspect API calls

See comment: https://github.com/svaarala/duktape/pull/1128#issuecomment-265661105.

I'm a bit on the fence if this change actually makes sense. The calls map 1:1 to Duktape.info() and Duktape.act() and the return value from those Ecmascript functions is exactly the value pushed on the value stack. So in essence the C API calls would then have two return values: one on the value stack, and another as a direct boolean return value. These are also called very rarely so they don't need to be very convenient; and adding footprint for making these rare calls more convenient seems like footprint better used elsewhere.
But I'll add the return values to the pull and see what the result would be.

For x64 defsize the footprint impact is +48 bytes. Seems tiny but also the change (and improvement in API usefulness) is tiny; this would be one third of the object coercion changes footprint impact. Hmm...

I 'm assuming the extra footprint is the cost of (at least) one extra instruction to load a 0 or 1 for each return.  Hm.

There are multiple exit paths and multiple loads, and generally functions returning a value will cause register allocation changes in the call site.
But I guess that's ultimately secondary to API consistency. On that front, e.g. duk_get_finalizer() will just push the current finalizer to the value stack exactly like Duktape.fin(), and doesn't provide a return value to indicate if a finalizer existed or not. While there are examples to the contrary (like the property functions you commented on earlier), these "rare" API calls like finalizer access, prototype access, etc are generally as minimal as possible.
So, don't know :)

I'll live if you choose not to merge the change, I have maybe four call sites total for these so it's pretty rare in practice as you say.

Thinking about duk_get_prop_xxx() a bit, I guess the difference there is that a property get might either succeed and push undefined (because that's the value of the property), or fail and push undefined (because the property doesn't exist).  So the only way to distinguish the two cases is by the return value.  duk_inspect_xxx() will only push undefined in the failure case, so there's no ambiguity.

That's true. Btw, even for duk_get_prop_xxx() and foo.prop there is a difference in handling non-existent properties. Ecmascript code generally doesn't care about the difference of the property not existing or existing with the value undefined. The end result is the same unless you explicitly check for the existence. So if C code mirrors Ecmascript code, it "shouldn't" use the return value but rather act on the pushed value.
So... If the return value is thought of as a shorthand for "read back undefined", it should actually be false when the pushed value is undefined (regardless of property existence) and true otherwise.
I'm not suggesting that change though, but it's an interesting question how closely the C API should mirror typical Ecmascript code behavior.

Ecmascript does have the in operator though so it's essentially shorthand for "prop" in foo followed by a property read--which is quite convenient and something that I often do in JS as well as C.

Sure, but my point was about the common idiom. How often do you see something like:
x = foo.prop;
if (x !== undefined) {
    // ...
}

or:
x = foo.prop;
if (x != null) {
    // ...
}

compared to:
if ('prop' in foo) {
    x = foo.prop
    // ...
}

Very rarely will application code actually bother to check for existence in my experience.
(And to be really technical, doing an "in" check and then reading the property is not 100% same as duk_get_prop_xxx() because there are no guarantees for the property not to disappear in the middle, e.g. with a Proxy target.)

I don't know about other real world code, but I know that I personally do existence checks a lot because if I forget to initialize a variable somewhere I don't want it to just silently be coerced to a default value later - I would prefer it to fail noisily.  Thus  I make a distinction between "property not present" vs. "present but set to undefined".

I'm not saying that's good or bad, but code bases I've worked with almost never do that. Maybe some other code bases do, shrug :)

Also based on previous discussions re: null and undefined, why not just:
x = foo.prop;
if (x !== void 0) {
} else {
    // aiee, property is missing
}

If "null" is used exclusively for a present-but-not-specified value (and "undefined" for a missing value, as I understood you prefer), "undefined" is actually never intentionally used for a property that's present but doesn't have a value?

For public-facing APIs I can't guarantee someone didn't implicitly pass me an undefined due to an accidentally uninitialized variable, for instance.  The main thing I try to do is avoid confusing "accidental" with "deliberate".  If I get a null that indicates intent, versus undefined which might be intended or not.  Since JS has two null types, only one of which is implicit, might as well take advantage of it :)
API design is really my passion, even though most of my Duktape work has been with internals.  So I guess I tend to think about these things differently than most.  I rarely view code as being a closed system, for example.

By the way, in Lua the equivalent of undefined/null is a single nil type which is more like "undefined" than "null". In particular, you delete properties by saying:
x.foo = nil

which would be roughly the same as:
delete x.foo;

If Ecmascript treated "undefined" as a missing property, it would actually make sense to delete properties by saying:
x.foo = undefined;

That would actually make the role of "undefined" a bit more useful. Now there are essentially three null-like values: null-and-present, undefined-and-present, undefined-and-not-present.

If I get a null that indicates intent, versus undefined which might be intended or not. Since JS has two null types, only one of which is implicit, might as well take advantage of it :)

But doesn't that then mean that you would want to provide that warning log entry for both a missing property and an "undefined" property -- because "undefined" wouldn't necessarily signal intent?

True, and now that I think about it, probably.  In that regard Lua's behavior makes more sense - nil properties aren't actually stored so there's no need for a separate existence check.

FWIW I'm not really sure what idioms are best, I'm just commenting on what I typically see. For example, one often sees:
var timeout = timeout || 60;  // default to 60

which is error prone because a 0 would be treated as false and be converted to the default value. What I usually use for that is:
var = (typeof timeout !== 'undefined') ? timeout : 60;

This doesn't (and cannot) differentiate between an actual "undefined" and a missing argument. One could make that distinction via the "arguments" object, but it's way too verbose for my taste. And I don't usually care about missing vs. undefined in this context.
Similarly for properties I typically use typeof foo.prop !== 'undefined'. I guess "prop" in foo would be be better, but I'm used to typeof because it also matches how I check arguments.
But again, I don't know if these are common or good idioms.

Wait, I know what I was referring to now.
Suppose I have a function that takes an object with options.  If any options aren't present, the function uses defaults for them.  If they ARE present but set to undefined, then I warn: this was likely caused by an uninitialized variable.  I can't make that distinction with only a value comparison.

If one wants to treat a missing property and "undefined" the same way, it would actually be simpler if duk_get_prop_xxx() return value would be exactly the same as !duk_is_undefined(ctx, -1) after the property read. This allows:
if (duk_get_prop_string(ctx, -3, "prop")) {
    /* obj.prop is present and not undefined */
} else {
    printf("aiee: obj.prop is missing or undefined\n");
}

Right now, if one wants to treat missing and undefined the same way, one must check for duk_is_undefined() explicitly.
It would also be possible to take the DUK_TYPE_NONE into actual use to signify a missing value for property reads. IOW, duk_get_prop_xxx() would push a "none" if the property doesn't exist. The downside of that is that DUK_TYPE_NONE is then a concrete value that can exist on the value stack and needs to be handled everywhere (probably defaulting to whatever behavior "undefined" has), and also that the C API return type won't match an Ecmascript property read type.

If they ARE present but set to undefined, then I warn: this was likely caused by an uninitialized variable. I can't make that distinction with only a value comparison.

That will then warn for this idiom:
var timeout;
if (something) {
    timeout = 60;
}
doSomething({ timeout: timeout, ... });

The variable is intentionally uninitialized, and only set if there's a reason to do so. The fix would be to set var timeout = null but I wouldn't naturally do so because "undefined" is a valid value :-) But I do get your point though.
For comparison, in Lua that timeout: timeout would be a missing property if timeout was nil. That works out in these cases well too. The problem with Lua is actually the opposite: there's no way to signal an intentional null because a nil is exactly the same as absence. That's sometimes very awkward because there's no way to e.g. set a value to null and prevent inheritance of a non-null value.

Right, I would personally initialize timeout to null in that case as a clear signal to readers that it may be accessed without being assigned.  So the warning is desirable to me in that case :)

So with that sidetrack I can maybe reword my point a bit more clearly: I'm not sure what the best idiom (or even the most common one) for Ecmascript code is. So I'm also not really sure what the best C API idiom - it should ideally dovetail with the best/preferable Ecmascript convention.
In general one approach that may not be ideal but is at least conceptually simple is for C APIs to mirror their Ecmascript counterparts. For property reads that would mean that only the final returned value would be considered, without divulging whether the property was present or not.
That presence information is, by the way, not really always even available. For example, proxies return undefined for both missing properties and properties with an undefined value. You can't determine the presence based on the property read alone. You can of course do an "in" check but that's different from a side effect perspective -- and it would be really surprising if the C API property reads triggered a "has" trap for proxies because the Ecmascript property reads don't.

So as a concrete example:
duk> target = {}; P = new Proxy(target, { get: function () { return void 0; } });
= {}
duk> typeof P.foo
= "undefined"

If I gave "P" as an argument to a Duktape/C function, every duk_get_prop_xxx() read would return 1 (i.e. "property present"). So with proxies the distinction between not present and undefined already breaks down.

Huh.  That's interesting but I guess it makes sense from the perspective of Ecmascript semantics.
Ultimately I guess it's because as a C coder first, because undefined is the implicit value for anything that hasn't been assigned yet, it's natural for me to treat it as garbage.

Right, but that's really my main point: is it useful for the C API to provide information about the presence or non-presence of the property if (a) that's not generally used by script code (up to debate of course) and (b) that information is not always available or reliable?
In other words, shouldn't non-present and "undefined" just be treated the same way?

And that question is actually quite opposite to the question for the inspect API calls. For the inspect calls the "non-presence" is very well defined: for inspecting a value, an invalid index is "not present", for inspecting a callstack entry, and "out of bounds" index is also clearly "not present".

Hmm, going outside of my own little bubble for a bit, I guess that seems like the most reasonable default given typical idioms.  I would be a bit annoyed having to change the call sites in minisphere but I'm just one single user after all ;)

Sorry, this sidetrack is a bit long already, but that Proxy example actually brings up a related point: the current duk_get_prop_xxx() return value was originally added before Proxies were supported (or even fully specified). The return value makes sense for a concrete property lookup.
However, with proxies that return value is essentially bogus. And because Proxies should be relatively transparent compared to a plain object, this actually works quite badly for C code now. Suppose I called a C function like this:
myNativeFunction(new Proxy({
    host: 'foo.bar', port: 8080, timeout: 30
}, { /* ... traps ... */ }));

If that C function now checked for presence of options in the call argument, all options would read back as "present with value X" or "present with value undefined". So the C call could never determine that a parameter was missing, unless it used duk_has_prop_xxx() explicitly.
So... the best practice for dealing with objects in C code would in fact be to generally ignore the duk_get_prop_xxx() return value, or risk unintended behavior with Proxy arguments. Given that, it might make more sense to remove the return value or change its semantics (= true if not undefined, false if undefined, regardless of presence).

Added #1170 to mention the Proxy behavior in documentation. There's no similar problem for any of the other property operations or Proxy traps; the return values map cleanly 1:1 otherwise.

Sorry, I always managed to sidetrack Duktape pulls with tangential stuff :)

Well, the conclusion for duk_get_prop_xxx() is actually useful at least for documentation.

I'll close this as unmerged; these are very rarely called and the added convenience doesn't seem worth it. Also the Ecmascript variants of these bindings don't provide a "present or not" indication; that's apparent from the return value.


Version Management

Feature Proposal

Spec Version 0.2.0

Context
Problem
Currently, users can’t track changes made to diagrams and feedback is not linked to a speciﬁc version, which makes it more diﬃcult to collaborate and engage in a feedback loop. There is no way to revert to previous versions or restore them.
Motivation
Considering that UML modeling is a collaborative activity and plays an important role in the software evolution of model-driven development, version management of diagrams is crucial for projects that utilize Apollon for creating and maintaining UML models.
Requirements Engineering
Existing (Problematic) Solution / System
If a developer wants to create another version of the diagram, the only way would be to import the diagram into a new ﬁle. In order to see an older version, it has to be stored and imported into the editor.
Proposed System
In the standalone version of Apollon, users will be able to toggle the visibility of a sidebar which displays a list of versions of a diagram. The user can see a preview of each version, delete, restore or edit them. Each version in the list has its title and description. The sidebar will also have a “Publish Version” button so that the user can create a new version of the diagram given the current state of the diagram.
Requirements
Functional requirements:

FR1: Add new versions: Developers will be able to create new versions of a diagram
FR2: See list of versions: Developers will be able to see a list of versions of a diagram
FR3: Preview version: Developers will be able to view each version of a diagram
FR4: Edit version info: Developers will be able to edit version info of a diagram (title and description)
FR5: Restore version: Developers will be able to restore a version of a diagram

Nonfunctional requirements:

NFR1: Reliability: Saved versions will persist
NFR2: Availability: Versions can be previewed and modified at all times
NFR3: Usability: Users will have an intuitive sidebar for version management

Analysis
Analysis Object Model

System Architecture
Subsystem Decomposition
Currently, diagrams are stored as:
id: string;
title: string;
model: UMLModel;
lastUpdate: Moment;

In order to support the described functional requirements, I intend to change the model: UMLModel field to models: UMLModel[]. The chronological order of versions would be deduced from indexes in a ascending manner. I would also add title and description fields to the UMLModel DTO, to enable FR2 and FR4.
I intend to add a new POST endpoint /diagrams/:token/publish. The request body will contain the new diagram to replace the existing one saved under a token. The models array in the request body will not contain the last element from the models array in local storage, as it represents the "Current Unpublished Version".
However, I am unsure about how to handle this migration. Should I make sure that both formats are supported at once?
Other Design Decisions
Currently, when clicking any button in the share modal (Edit, Give/See Feedback, Collaborate, Embed), a new token is generated. For version management, this means that if someone embedded a diagram, as described in #92, and then shares it to get feedback for example, the embedding would become stale. My solution idea is, if a diagram had previously been shared, and the user clicks on a button in the share modal, then another modal pops up. This modal would explain that the user can either discontinue the version history of the previously shared diagram or not, and let the user choose.
UI/UX Design

First draft of the sidebar is already implemented on the branch linked to the issue.

Generally looks good already.
Here are some questions / remarks that I have in mind:

Does UMLModel contain a timestamp?
Does this change require a migration? We have to keep apollon-ios in mind, is there a way to not make it a breaking change? Maybe by having a prevVersionId or so
What happens to feedback? I think the flow would be: work on diagram v1 -> publish version & share with others to get feedback -> receive feedback on v1 -> implement feedback in v2 -> publish version -> ...

This feedback loop is IMO a core part of even having a version history
I'd guess the feedback for a version is only visible for the currently viewed version  (this deviates from Figma since there you always see all feedback regardless of the version)
A feedback indicator in the version history would be nice (this deviates a bit from Figma)

Are you doing autosave versions? Or is it always triggered by a user?
I think a duplicate action like in Figma would be good so you can "fork" that version
The actions do not have to be buttons IMO, you can do it like Figma with the "..." and have a dropdown selection
How will this work in the context of collaboration?

Please highlight the open discussion points that are important to talk about with Stephan and me where decisions are necessary, such as migrations. On those points you can also offer multiple alternatives that you have considered.

Does UMLModel contain a timestamp? Does this change require a migration? We have to keep apollon-ios in mind, is there a way to not make it a breaking change? Maybe by having a prevVersionId or so.

That's a good idea, with the prevVersionId I can avoid breaking changes. Also, UMLModel doesn't contain a timestamp, but it won't be needed since the Diagram does.

What happens to feedback? I think the flow would be: work on diagram v1 -> publish version & share with others to get feedback -> receive feedback on v1 -> implement feedback in v2 -> publish version -> ...

Feedback (assessment) is part of the UMLModel datatype, and will therefore be linked to a single version. This means that the flow would be just as you have specified. However, the feedback system of Apollon is currently specifically designed for instructors to grade diagrams. As Eugene pointed out in his evaluation here, standalone Apollon lacks commenting for free-form discussions. Such discussions can be carried out in a PR/issue, and perhaps commenting as part of standalone Apollon is a feature that could be implemented in the future.

Are you doing autosave versions? Or is it always triggered by a user?

The "Currently Unpublished Version" is the autosaved version that hasn't been published yet, whereas published versions were created by clicking on the + button, like on Figma.

I think a duplicate action like in Figma would be good so you can "fork" that version

There is currently a "Restore Version" button that is available once a preview of the diagram is opened. That is what you mean by "forking", right?

The actions do not have to be buttons IMO, you can do it like Figma with the "..." and have a dropdown selection

I thought it would look better this way. If you think it is better with a dropdown I can implement it that way too.

How will this work in the context of collaboration?

My idea is that version management is also available within collaboration mode and that all collaborators have access to it.

There is currently a "Restore Version" button that is available once a preview of the diagram is opened. That is what you mean by "forking", right?

I meant this pencil button that looks like an edit button. I think if you'd click that one it would create a duplicate of the diagram for editing. I think restore version would be a separate functionality that we also want.


TILA-1635: Allow reservations without opening hours if flag is enabled

The PR adds a new boolean flag to ReservationUnit. If the flag is set true, reservations can be done without opening hours.

@nicobav I updated the commit message. Now it describes how serializer is updated 👍


Difference between displayErrorDetails and printing to error log

Hi! I was configuring error reporting for an application and started to wonder about the displayErrorDetails setting: why is displaying errors to the client coupled to not showing them on the log? There are use cases during development where I might want to display the errors to the client but also have them at the log (e.g. if the client may be a mobile app or another application which might not give me a chance to look at the full response body).
Overall, it seems to me that switching displaying of error details and printing to the log are separate concepts and should be independent settings. Does this make sense to implement? Of course Slim is not a logging framework and the implementation for this should be kept simple. I would be happy to contribute a PR for this!

Hi @edudobay. I'm not sure if I get your question right. Have you tried to implement a custom slim error handler?
There you have the possibility to decide which (and when) error details are displayed to the client and can log all errors in detail using a logger (e. g. Monolog).

Hi! Yes, I had no problem implementing a custom error handler, but to keep things simple I wanted to reuse the logging behavior that Slim already provides out of the box. The problem is that I can't reuse just the logging part because it's coupled to the rendering part. If I turn on error rendering, logging gets turned off and that’s what I’d like to change.
My current solution is an ugly subclass that “fakes” the displayErrorDetails setting when delegating to the log writer. Of course this is coupled to the Slim implementation; the proposal for Slim 4.x at #2222 (AbstractErrorHandler) would break this, for example.
class ErrorHandlerWithLogging extends \Slim\Handlers\Error
{

    protected function writeToErrorLog($throwable)
    {
        $oldValue = $this->displayErrorDetails;
        $this->displayErrorDetails = false;
        parent::writeToErrorLog($throwable);
        $this->displayErrorDetails = $oldValue;
    }
}

The most obvious “pretty” solution for me would be for the constructor to take two flags, say displayErrorDetails and writeToErrorLog - and the latter could default to the opposite of the former when not provided, to guarantee backwards-compatible behavior. Something like this:
class Error extends AbstractError
{
    public function __construct($displayErrorDetails = false, $writeToErrorLog = null)
    {
        if ($writeToErrorLog === null) {
            $this->writeToErrorLog = !$displayErrorDetails;
        } else {
            $this->writeToErrorLog = (bool) $writeToErrorLog;
        }

        // ...
    }
}

Am I going too far suggesting this? Or is it possible that Slim could have this separate setting, at least configurable from the constructor of the Error handler class?

The problem is, that in Slim 4 the method writeToErrorLog is getting only called if displayErrorDetails is true. See here. That means overwriting the writeToErrorLog method in a extended class will not work in Slim 4.
Have you tried to implement a custom ExceptionMiddleware?
Example:
// Exception middleware
$app->add(function (Request $request, Response $response, $next) {
    try {
        return $next($request, $response);
    } catch (Exception $ex) {
        // logging etc...
    }
});

@odan despite not being a viable solution in Slim 4, someone will be able to simply extend the AbstractErrorHandler and stub the constructor and do whatever they want.
#2222 has been closed. The concepts of that PR have now been implemented in #2398.
If you have any suggestions, feel free to comment on that PR!
Thanks

closing as resolved with #2398


Fixed #29619 -- Raised FieldError's should include the field that caused the error

branch management shenanigans led me to accidentally close this PR/delete the branch. Restored and reopening.

Looks like the database tests failed due to losing connection during testing. Is there a way for a PR creator to have the tests rerun aside from making a new commit to the branch?

@timgraham I believe this to be passing all checks, is there a way for me to rerun the checks so that it can be flagged as passing for potential reviewers?

See the patch review checklist. You need to add a link to the PR on the ticket and check "Has patch" on the ticket, don't worry about non-deterministic failures although you can amend and force push to re-run the checks. As for the patch itself, it looks like at least tests are lacking (many places changed but only a couple messages tested). I'm not sure if that ordering message is an actual improvement, it still seems somewhat obscure as far as giving help to track down the issue.

I'll review the checklist and can add additional testing. Would it be sufficient or preferable to simply 6 indicate the field, as requested in the ticket?

Whatever you think makes sense. The ticket doesn't describe a particular use case that caused confusion.


velocity freezes when server integration test server crashes due to error: "Meteor code must always run within a Fiber"

The integration test server crashes:
[velocity] Starting mirror on port 51024
=> Meteor server restarted
[velocity] Established connection with Velocity.

/private/var/folders/m9/gq0f4c795n13rst82cpnqxl40000gn/T/meteor-test-run1qvddiy/.meteor/local/build/programs/server/packages/meteor.js:942
    throw new Error("Meteor code must always run within a Fiber. "

Tracked with https://github.com/meteor-velocity/html-reporter/issues/74

I've added a status next to each framework now that shows mirror state (starting / ready)


Increase DNS autosacaler memory and add memory limit

Problem
When in large clusters memory allocation can be a challenge if memory limit != memory requests. Because of that we've some internal requirements for the platform and we're committing to be more aggressive and taking this very seriously in our platform.
We've some tooling around this in prometheus and as part of our memory allocation cleanup process we've found kube-dns-autoscaler consuming 250% times the requested memory. As we've this alert in our side, this component will trigger an alert:
(
  avg(
    container_memory_usage_bytes{
      container!="POD",
      image!="",
    }
  ) by (container, namespace)
  * 100
) / max(
  kube_pod_container_resource_requests_memory_bytes{
    job="kube-state-metrics",
    }
) by (container, namespace) > 90

Solution
I've increased the memory request up to 50Mi and added a proper memory limit.
Note
This cloud be improved by just adding parameters in the cluster.yaml but I didn't take the time as I think not so much people will face this issue

This is very serious, and we've started taking similar steps for applications deployed on our clusters. Could we patch this into the v0.16.x branch as well?

@dominicgunn sure, I'll cherry-pick


Lpc chapter

Here is our PR as part of our submission for the APS class' mini-project !
I added a new chapter with 2 subparts (theory and implementation), and I wrote more precise information about the implementation so that the future students do not get lost.
I also corrected the numerotation of the Granular Synthesis.
Work by Lkham Nyambuu, Alexis Mermet and Cyril Cadoux

@CyrilCadoux: I made quite a bit of changes here, most notably changing the implementation so that it doesn't rely on numpy/scipy array operations. This way, porting to C will be more straightforward. With the Digital Design Chapter now up, users should know how to perform the filtering with the LPC coefficients without using lfilter.


Call to undefined method Image::applyFilter()

It seems there is an issue using the latest integration branch of JIT, I guess it is due to the latests updates of JIT.
Call to undefined method Image::applyFilter()
/extensions/image_upload/fields/field.image_upload.php around line 60

the latest integration branch of JIT,

You mean version 2.0.0 ?

Yes, using JIT 2.0.2. I tryied to change applyFilter() to applyFilterToImage() (if i remember well), also tryied to require_once other classes than Image but I didn't find the solution.

Which RewriteRule are you using ?


Update azure-stack-sql-resource-provider-deploy.md

missing a . before $tempDir in last line script

@RedBa : Thanks for your contribution to the Azure documentation! The author, @JeffGoldner, has been notified to review your proposed change.

@RedBa : Thanks for your contribution to the Azure documentation! The author, @JeffGoldner, has been notified to review your proposed change.

#sign-off


External Event Handlers - Rotate with buttons?

Trying to decipher your code to make this rotate with button events calls. I havent got it working yet - was hoping for some insight?

I would like a similar interaction, is this currently possible?  I would need access to next and previous event handlers. @clandestine8 did you figure this out?

I think you can do that very easily. If you see the code (in develop branch) you just have to put the code in touchmove in a function and call it (the parameters need to be adjusted).
Reply back if you want a similar code. I think I did this for someone long ago.


[5.6] Move saveMany test

I believe this test doesn't need to exist because the essence of this test seens to be that a collection can be looped over using each, and relationships can be saved using the model, which doesn't have anything to do with the factory that the test class is concerned with. Since these tests exist elsewhere in the test suite, I suggest removing this test.
Well, actually, I assumed these tests already exist elsewhere in the test suite, but I discovered that this test in EloquentFactoryBuilderTest is the only test covering HasOneOrMany::saveMany, so I added a test for saveMany where I found a better home for it.

@taylorotwell The explanation is simple. The test doesn't belong in EloquentFactoryBuilderTest.php because it doesn't test EloquentFactoryBuilder, and so I moved the essence of the assertion from one class to another. Doesn't it make sense to organize the test suite and try and strive to make it as pretty as the framework? When you open up a test file you shouldn't have to be distracted by tests that don't actually test the thing that name of the test class would suggest it's testing.


Embroider readiness

prepare Ember for embroider (the new build system)
this may be related to #546
this would allow true code splitting
this would move the project into a more modern build system that is on par with the broader JS community
this might allow us to use alternative build tools e.g. vite

Closed by https://github.com/eclipse-pass/pass-ui/pull/1283


Using "Restore last config" doesn't update the displayed state of the custom header properly

https://cdn.discordapp.com/attachments/942484835631521812/1094249902835499038/2023-04-08_15-17-44.mp4

https://github.com/ori-community/rando-ui/blob/32735b09c8af47dd2f461b87cce2ee52f29d9bf9/components/WotwSeedgen/WorldSettings.vue#L156
that handler doesn't trigger when loading last config. Although it does if you load the last config again/twice

Fixed