Value Range for Lab Spike % Recovery

This is a minor and rare situation, and there are ways to work around it, but the package is not currently handling the value range for lab spikes correctly.  Would this be easy to handle?
For the result unit of measure, we have one special exception:  Lab Spikes may be entered with a percent unit of measure "%" or "% recovery" instead of the base unit of measure.  If the value ranges are defined so that values around 100 have a different DQO, then the wrong DQO might be used by the package.  In the attached files, both lab spikes for Nitrite should be misses, but only one is flagged.  I think the logic should be that if lab spikes are entered with the "%" or "% recovery" unit of measure, then the lab spike should be evaluated against the upper value range, and if the upper value range is not a % DQO, then tabMWRacc() should return an error.
Sample_DQOAccuracy_testing.xlsx
Sample_Results_testspikes.xlsx
Sample_DQOFreqComp_testingspikes.xlsx

I'm very surprised to hear that % recovery was not evaluated as an absolute value because that is a fundamental piece of the % recovery logic.  I'm certain I would have tested that, but you are right that the current production version of MassWateR does not flag negative % recovery exceedances.  Is it possible that this changed somewhere along the way?
The fixes look good mostly, but I did find one issue.  It is also related to the absolute value concept:
In the files I provided, if you change the Nitrite lab spike result value from 460 to 340, tabMWRacc() does not flag it as a miss.  It should because the absolute value of the difference is 60, which is greater than 50.
So, it turns out that spike/check accuracy was not evaluating absolute value for anything (% or normal units of measure).  I am 100% certain that I tested this before, so something must have changed.

@ben-wetherill I fixed the issue for the lab spike results not evaluating the absolute value.  I agree it's odd that we didn't catch that during initial testing.

I think this looks good now.  Thank you.


libinput synaptics like configuration support

Already started here:
https://github.com/eskimor/nixpkgs/tree/libinput-master
It works for me, but not all options are supported yet. I hope to find time polishing it and make a proper pull request soon. In the meantime, you can use what I have, if you need it.

This is great. I've added this and by touchpad now works as expected. An option for inverting scrolling would be neat (or is that handled at a different layer?).

Implemented: Option - NaturalScrolling - completely untested unfortunately, but you might want to try it out.

I believe we should strive to abstract away whether you're using synaptics or libinput and whether you're using X or something else. For example, we have services.xserver.synaptics.accelFactor and now you add services.xserver.libinput.accelSpeed. I'd imagine that instead we should have, for example, hardware.touchpad.accelSomething that would be shared, and hardware.touchpad.driver = "libinput";.

How would that work? Each Wayland compositor is responsible for configuring libinput, and they each have their own internal configuration formats.

I expect we need special setup code in nixos for each (wayland) compositor anyway.

Not for sway or orbment.

@vcunat : Well this would make the switch for users easier between synaptics and libinput, but I believe it is not worth the trouble:

The capabilities of libinput and synaptics are not the same
At the moment the options to be set in nix match the options described in the libinput man page - which is kind of nice.

As libinput is both for X and wayland, changing the name to something like hardware.touchpad indeed makes sense.

Also keep in mind libinput isnt supported by some wms like xmonad based on
my testing. I could control applications fine but keybinds were broken
On Thu, Jan 7, 2016 at 1:52 AM Robert Klotzner<EMAIL_ADDRESS>wrote:

@vcunat https://github.com/vcunat : Well this would make the switch for
users easier between synaptics and libinput, but I believe it is not worth
the trouble:

The capabilities of libinput and synaptics are not the same
At the moment the options to be set in nix match the options described
in the libinput man page - which is kind of nice.

As libinput is both for X and wayland, changing the name to something like
hardware.touchpad indeed makes sense.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/9920#issuecomment-169613185.

Could you elaborate on this - I am using xmonad with libinput - no issues so far.

What would be the easiest way to try this out? Is there anything else besides building configuration from a github checkout with @eskimor's additions?

@datakurre that is at least the most straight forward approach right now. As there seems to be some interest I will try to find some time to make a pull request out of it.

@eskimor Thanks. Libinput made my touchpad usable. And works with xmonad for me.

@eskimor I have a commit you might want to take too. It adds scroll method and two finger right click support: https://github.com/colemickens/nixpkgs/commit/397139d8ed6e76703460882956d4071ff0c4b04e

@colemickens Thanks - integrated.

Could we have a PR for that work?
@vcunat I appreciate the goal, but making such an abstraction without having it leak seems difficult. Also, consider that the drivers work for overlapping sets of hardware, so if the choice of driver is intentional rather than transparent, maybe there is less need to have the configurations be reusable. Finally, if we get in this now, and somehow mark it unstable/tentative, it should be an excellent foundation for such unified configurations in the future.

It was just and idea. You (the implementers) should know better than me whether it's feasible (or worth their time).

if we get in this now, and somehow mark it unstable/tentative

Yeah, well, I don't know how to do that, and I think it would be useful in general to have a means to mark some parts of our "interfaces" as unstable/tentative, meaning they can change without providing backward compatibility. IIRC we were discussing these problems on the case of NixUP after NixCon, as without people using the "interfaces" it's harder to improve them.

@Ericson2314 Yeah - I will do some polishing this Friday. Expect a PR by Saturday.

Sweet!


AdditionalDataPayloadParser/Generator are completely untested

Problem
There are no tests for this code, and it has basic bugs in it like using not-big-enough buffers (some of which might get fixed as part of other changes).
Proposed Solution
Add tests.
@hnnajh

src/setup_payload/tests/TestAdditionalDataPayload.cpp seems to exist now.


Fix sorting issue

Fixes https://github.com/infobip/infobip-spring-data-querydsl/issues/38
First I created a test that replicates the issue, and added a possible fix in a separate commit.
Do I need to add the same tests for the other packages (JPA/R2DBC)?

It took me a while to figure out what's going on.
It seems that the sorting currently does not take the mapping into account. However, with the PascalNamingStrategy this bug is hard to spot because otherField and OtherField are considered the same column if your DBMS is case-insensitive (which seems the case in the tests).
However, with custom column names, it breaks.
In the fix I use the RelationalPathBase which contains all the column mapping and convert the Sort to a QSort using the column mapping.

You don't have to add tests for JPA as there's no custom logic for it in this project.
Please do add tests for R2DBC.

Will do!

Done!


SharePoint Online Client Extensibility Web Application Principal has incorrect AppIdUri causing AadHttpClient to fail in MS Teams Desktop Client

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[X] other (enter in the "Additional environment details" area below)

Additional environment details

MS Teams desktop client

Describe the bug / error
We noticed after the MSAL v2 update, calling AadHttpClient and MSGraphClient from within MS Teams Desktop client fails.
An error is returned by the call to Microsoft.SharePoint.Internal.ClientSideComponent.Token.AcquireOBOToken, causing the application to never receive an access token (a week ago, this error message was limited to Resource not found, now a more descriptive message seems to be sent).
{
  "odata.error": {
    "code": "10009",
    "message": {
      "lang": "en-US",
      "value": "AADSTS500011: The resource principal named https://microsoft.spfx3rdparty.com was not found in the tenant named [...]. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.\r\nTrace ID: a7f600a9-f4eb-4497-ad5f-53c1fcb62e00\r\nCorrelation ID: 7c86fd9f-f0d8-3000-648e-d75761838433\r\nTimestamp: 2021-10-28 09:28:45Z"
    }
  }
}

We investigated the behavior on different tenants (some working, some not), and came to the conclusion that on the non-working tenants, the Application ID URI was different from working tenants.

Working: https://microsoft.spfx3rdparty.com
Non-working: api://<tenant_id>/microsoft.spfx3rdparty.com

We tried navigating to the API Access page, even deleting the app and having it recreated, but without success.
What did work was changing the App ID URI to a wrong one (e.g. "microsoft.spfx3rdparty.com"), and then navigating to the API Access page. The App ID URI was then changed to https://microsoft.spfx3rdparty.com.
Calls to AcquireOBOToken (and AadHttpClient) then work as expected.
Expected behavior
Either AcquireOBOToken to accept api://<tenant_id>/microsoft.spfx3rdparty.com as being correct, or the SharePoint Online Client Extensibility Web Application Principal to being setup with the correct App ID URI.

@NickSevens - could you reach out to me at GrahaMc at microsoft.com.  I'd like to discuss something going on with your tenant that we're not seeing and see if I can get you in a better state.

Hi @NickSevens - This was a regression that was rolled out and since been reverted. The issue is exactly as you said, that the endpoint URI changed and had a resolution error on the call to AcquireOboToken. If you visit the web api access page again in tenant admin the endpoint URI will revert back to the previous value and things will continue to work. We are deploying a fix for the new URI which will roll out in about 2 weeks. This issue affected the subset of customers who had to change rolled out to them and had visited the web api access page while the change was rolled out (and that regression was shut off on Oct 27th).

Thanks this solved our issue as well


replace import * as t from 'funtypes' with import * as funtypes from 'funtypes'

I'm fine with the change, but this is one of the very few situations where I'm OK with a shorthand. This entire file uses funtypes on almost every line, so while normally I would argue that verbosity is valuable, I think in this case the verbosity is a net loss and jargon is favorable due to the sheer volume of references.

I mostly want to do this change as other files use some amount of funtypes, and I don't like the import to be different here. But I also think calling the lib "funtypes" is also more clear than "t"


Allow repo members to /restest via repokitteh

description
atm, you need to be an "approver" to trigger a retest via repokitteh
it would be helpful if the circle was widened, so regular contributors can also trigger this
not being able to trigger it means doing "empty" or "amend" commits which triggers full re-runs,  and a lot of unnecessarily wasted CI cycles

Ultimately we would like to have anyone in https://github.com/orgs/envoyproxy/teams/assignable be able to do it I think?

i reckon i can do this

after a bit of further investigation it seems that it is possible to use /retest - its /azp run which throws a permissions error
i think we still need to clarify and perhaps document more clearly who can re/run ci with the bot etc

seems like anyone can trigger /retest - ie any github member


[QUESTION] Can SkiaSharp draw to an OpenGL buffer?

Can SkiaSharp draw to an OpenGL buffer created from .NET? It seems that it can, if the surface is constructed using the correct SKSurface.Create method. However, there are many overloads, and this process is not very straightforward. It would be useful to clarify which API to use. Additionally, a sample project in the samples directory using an easy library such OpenTK would be helpful to demonstrate the capability.

I agree. Here's a sample project that uses OpenTK: https://github.com/NogginBops/ImGui.NET_OpenTK_Sample

Thanks, in the meantime I found another example which demonstrates the capability. Closing the issue.


Add google scope to initializer

Recently I wanted to change scope in google and I spent some time on it so maybe if we put it in initializer somebody else won't have this problem :)

@arnvald could you guys have a look at it? thanks :)

@DMips thanks!
I actually notice and check all the PRs, no need to ping me - it's just that I'm only one person with full-time job and a few side projects, so it sometimes takes me a few days to respond.

@arnvald thank you and sorry about ping :)


Create neural net for calculation of P and v

Create neural net for calculation of P and v

If it works I'm expecting to see more and more simulations being kept from previous node


autogen absolute symlinks; fix configure.sh missing step

See discussion at #592

Since #602 builds on this PR and seems to be getting close to merging, let's close this as a separate PR.


MDBGA: Finish refactoring MongoDB queries to use boolean expressions

Use lower-level query syntax to improve composability.

PR: https://github.com/prisma/prisma-engines/pull/2767


Update public suffix list with pull requests

Motivation:
update-psl fails to push changes to the master branch because the branch is protected after Merge Queue is enabled.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error:
To https://github.com/line/armeria
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'https://github.com/line/armeria'
Error: Invalid status code: 1

Modifications:

Automatically create a pull request for new changes in public_suffixes.txt
The created PR is also automatically merged by Mergify.

Result:
New public suffixes are correctly updated to public_suffixes.txt.

https://github.com/ikhoon/armeria/pull/23 is a sample PR on how public suffix list PR is updated.

I don't have permission to install Mergify to line/armeria repository.
@syleeeee Could you install the app when you are available?

Mergify GitHub App has been installed. Let me merge this PR. 🙇♂

Thanks!


DNS Entries

staging and prod

I've requested CNAMEs for staging, prod, and for the open fisca instance

Heroku is configured. We'll need ssl certs

GOOD NEWS - Heroku has built-in letsentrypt. so once we have the dns entries, we should be good.

done!


feat: i have added  a new video in electronics part. #key 5.

Title

provide a brief description. Use "(feat):" for enhancement requests. Use "(bug):" for bugs/defects/issues.

Related Issue(s)

list any related issue(s) via issue title and number that this pull address is addressing.

Additional Info

provide any additional information relevant to the pull request

Summary by CodeRabbit

New Feature: Expanded educational content in the Data component.

Added a new video tutorial titled "All about reverse bias" to the videos section. This tutorial provides a comprehensive explanation of the backward diode.
Enhanced the info section with additional information about reverse bias in semiconductors, accompanied by a helpful YouTube video for further understanding.

These updates enrich our educational resources, offering users a more in-depth understanding of semiconductor concepts.

LGTM!
Great Work @rayAritra !


[Improvement][SPI] Remove duplicate PropertyUtils

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description

Currently we have two PropertyUtils in both common and spi modules.
It is hard to maintain duplicate util classes.
Furthermore, PropertyUtils in spi module gives some kind of initialization error when we try to mock it using Mockito.mockStatic(). Instead of spending time finding tricky ways to  mock it, I suggest we remove PropertyUtils in spi module.

Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

Looks like we will have a cyclic reference if adding common dependency into task-plugin module:
[ERROR] [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT'}' and 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT'}' introduces to cycle in the graph org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT @
[ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT'}' and 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT'}' introduces to cycle in the graph org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT -> [Help 1]

@kezhenxu94 @ruanwenjun @caishunfeng @SbloodyS May I ask whether there are any grace solutions to this? Thanks

Looks like we will have a cyclic reference if adding common dependency into task-plugin module:
[ERROR] [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT'}' and 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT'}' introduces to cycle in the graph org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT @
[ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT'}' and 'Vertex{label='org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT'}' introduces to cycle in the graph org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-common:dev-SNAPSHOT --> org.apache.dolphinscheduler:dolphinscheduler-task-api:dev-SNAPSHOT -> [Help 1]

@kezhenxu94 @ruanwenjun @caishunfeng @SbloodyS May I ask whether there are any graceful solutions to this? Thanks

No, it's a really bad idea to work around this even if there is a solution. There is no reason the common module should depend on the task module, anything inside common module that uses task module should be moved to task-api module.

How about make task-api relying on the common module?

How about make task-api rely on the common module?

FYI, here are the files of task-api which common depends on:
dolphinscheduler.plugin.task.api.enums.TaskExecutionStatus;
dolphinscheduler.plugin.task.api.enums.TaskTimeoutStrategy;
dolphinscheduler.plugin.task.api.parameters.TaskTimeoutParameter;
dolphinscheduler.plugin.task.api.enums.DataType;
dolphinscheduler.plugin.task.api.enums.Direct;
dolphinscheduler.plugin.task.api.model.Property;
dolphinscheduler.plugin.task.api.TaskConstants;
dolphinscheduler.plugin.task.api.parser.PlaceholderUtils;
dolphinscheduler.plugin.task.api.parser.TimePlaceholderUtils;

I need more time to look into them to see whether to move those constant and utility stuff into common module or move the code depend on them into task-api module.


topk_indices = topk_indices // num_classes Killed

When I do the testing with dataset scannet200, the procedure would be killed. Can anyone help me with it? Thanks in advance!!!
The command I used is like this:
python main_instance_segmentation.py general.experiment_name="scannet200_val_query_${CURR_QUERY}topk${CURR_TOPK}dbscan${CURR_DBSCAN}" general.project_name="scannet200_val" general.checkpoint="saved/scannet200/last.ckpt" data/datasets=scannet200 general.num_targets=201 data.num_labels=200 general.eval_on_segments=true general.train_on_segments=true general.train_mode=false model.num_queries=${CURR_QUERY} general.topk_per_image=${CURR_TOPK} general.use_dbscan=true general.dbscan_eps=${CURR_DBSCAN}
And at the 104/312, the procedure was killed.
Testing DataLoader 0:  33%|█████████████▌                           | 103/312 [10:52<22:04,  6.34s/it]/home/pub-7/Documents/Mask3D/trainer/trainer.py:599: UserWarning: floordiv is deprecated, and its behavior will change in a future version of pytorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values. To keep the current behavior, use torch.div(a, b, rounding_mode='trunc'), or for actual floor division, use torch.div(a, b, rounding_mode='floor').
topk_indices = topk_indices // num_classes
Testing DataLoader 0:  33%|█████████████▋                           | 104/312 [11:10<22:21,  6.45s/it]/home/pub-7/Documents/Mask3D/trainer/trainer.py:599: UserWarning: floordiv is deprecated, and its behavior will change in a future version of pytorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values. To keep the current behavior, use torch.div(a, b, rounding_mode='trunc'), or for actual floor division, use torch.div(a, b, rounding_mode='floor').
topk_indices = topk_indices // num_classes
Killed

@JonasSchult

Similar issue occured to me.

Hi!
The warning regarding topk_indices is just a warning and should not result in a killed process.
I occured similar issues if the memory (RAM) was not sufficient. Can you monitor the memory consumption during evaluation and report if it uses up all memory?
Best,
Jonas

If not use dbscan postprocessing, there is no error using leaner version of testing like 'python main_instance_segmentation.py
general.experiment_name="leaner_version_scannet200_val"
general.project_name="scannet200_eval"
general.checkpoint="checkpoints/scannet200/scannet200_val.ckpt"
data/datasets=scannet200
general.num_targets=201
data.num_labels=200
general.eval_on_segments=true
general.train_on_segments=true
general.train_mode=false'
Is it OK to test it using leaner version? And what is the diference between these two methods?

Running DBSCAN postprocessing results in better performance but introduces additional runtime/memory cost.
It is basically a trade-off.
Best,
Jonas


test: Break down huge monolith mock header to improve test compilation performance

Commit Message: breakdown test/mocks/server/mocks.h into different mock classes
Additional Description:  test/mocks/server/mocks.h is a wide-used mock header included by various test files. However it's very huge and most test files only used a small portion of it. Splitting it up into different mock classes will be helpful to reduce compilation time.
Risk Level: low
Testing: existing tests
Docs Changes: N/A
Release Notes: no
Related Issues: #10917

@ahedberg

cc @asd

Please fix formatting. ./ci/run_envoy_docker.sh './ci/do_ci.sh fix_format' should do it.

Now it should be fixed. Actually the empty namespace block in mocks.h from previous commits  was used to make the formatter happy. now I found I can use no lint instead


[Issue]: Occasional Incomplete Configuration of Git Proxy

This intermittent issue results in incomplete configuration of Git proxies, where either the HTTP or HTTPS proxy is occasionally left unconfigured. It is noteworthy that this does not occur consistently.
Recommendation: To mitigate this issue, it is advised to meticulously click on the desired proxy card twice, ensuring a brief time gap of approximately 5 seconds between clicks. This deliberate approach aims to enhance the reliability of proxy configuration and minimize the occurrence of incomplete settings. Your attention to this matter is appreciated for a smoother and more consistent Git experience.

/label add Notice, bug

completed


page getting started styling

Fix #101
Test URLs:

Before: https://main--bevespi--hlxsites.hlx.page/copd-management-resources/getting-started-on-bevespi
After: https://101-page-gs--bevespi--hlxsites.hlx.page/copd-management-resources/getting-started-on-bevespi

down arrow from the header is missing

changes look good, only thing is that on some display widths, the down arrow is not displayed, but I think this issue is more related to the hero, than to the styling of the getting started page

ah, forgot one thing, on some sections there is a background image, like on columns, from the homepage

ignore the comment above, this will be fixed in the issue #137


io.dropwizard.metrics:metrics-core package lost support for the JPMS between version 4.1.10 and 4.1.11

In io.dropwizard.metrics:metrics-core version 4.1.11 JPMS support was broken.
Specifically, this line is now missing from META-INF/MANIFEST.MF:
Automatic-Module-Name: com.codahale.metrics

@myurchen Thanks for reporting this!
It looks like this was introduced with #1617 and maven-bundle-plugin:5.1.1 removes this manifest attribute.

The change of module name breaks any dependants that used the old module name. If this package follows SEMVER, this change in module name would necessitate a full major version bump as it is not backwards compatible.

@njdoyle You're right. I'll publish a patch release to fix that.


MAr21

Linting
On Mon, Mar 21, 2022, 08:52 Vadali Sai Krishna @.***>
wrote:

Merged #24
https://github.com/saikrishnavadali05/Artifact_Detection/pull/24 into
master.
—
Reply to this email directly, view it on GitHub
https://github.com/saikrishnavadali05/Artifact_Detection/pull/24#event-6272492422,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANZG7FPY2ETBZPIZ5JDWT3DVA7TQ7ANCNFSM5RGOU4XA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
<saikrishnavadali05/Artifact_Detection/pull/24/issue_event/6272492422@
github.com>


postgres/create_buses_database.sql is hardcoded

https://github.com/venice-framework/venice/issues/3

Fixed with https://github.com/venice-framework/venice/pull/20


feat: custom package.json location

:pencil: Description

Added an input for setting a custom location for the package.json to validate

:link: Related Issues

I wasn't sure how to add a unit test for this, since the package.json content seems to be passed as strings in the tests?

@esbakker Thanks for contributing! I think you'll need to run bun run package in order to get the dist/ code to match what the CI generates.

@esbakker It's still not matching. I think you might be able to add github-actions[bot] as a collaborator to your fork, and the CI will push the commit to your branch.

@danadajian The rights for workflows seem to be correct. I ran the build workflow from my own repo and there it succeeded. I cherry picked the changes, so hopefully it will succeed now

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


let g:syntastic_js_checkers not working

Syntastic is ignoring the option let g:syntastic_js_checkers = ['jscs'] and running jshint instead:
Output of SyntasticInfo
Syntastic version: 3.6.0-92 (Vim 704, Darwin)
Info for filetype: javascript
Global mode: active
Filetype javascript is active
The current file will be checked automatically
Available checkers: jscs jshint
Currently enabled checker: jshint

.vimrc configuration
" Configure syntastic
set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*

let g:syntastic_js_checkers = ['jscs']
let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1
let g:syntastic_check_on_open = 1
let g:syntastic_check_on_wq = 1
let g:syntastic_error_symbol = "✗"
let g:syntastic_warning_symbol = "⚠"

It looks like the issue is that syntastic is ignoring the setting let g:syntastic_js_checkers = ['jscs'] and is running jshint instead.

This is not supposed to work.  The standard filetype is named javascript, not js.  Try g:syntastic_javascript_checkers instead of g:syntastic_js_checkers.

when I try to see the variable g:syntastic_javascript_checkers, I get
:echo g:syntastic_javascript_checkers
E121: Undefined variable: g:syntastic_javascript_checkers

@juanpabloaj That's because there is no variable g:syntastic_javascript_checkers defined by default.  You are supposed to set it to the list of javascript checkers you want to run if you plan to use syntastic to check JavaScript files.


Building on mac

Cant build it on a Mac !SOLVED
$ cargo build
Compiling hyper-rustls v0.14.0
   Compiling git2 v0.10.2
   Compiling built v0.3.2
   Compiling croaring-sys v0.3.9
   Compiling randomx v0.1.0 (https://gitlab.com/epiccash/randomx-rust.git#21b3792d)
   Compiling epic_wallet v3.0.0-alpha-2 (/Users/devron/Downloads/git/epicwallet)
error: failed to run custom build command for `randomx v0.1.0 (https://gitlab.com/epiccash/randomx-rust.git#21b3792d)`

Caused by:
  process didn't exit successfully: `/Users/devron/Downloads/git/epicwallet/target/debug/build/randomx-a38eff86731ce054/build-script-build` (exit status: 101)
  --- stdout
  Starting randomx build
  running: "cmake" "/Users/devron/.cargo/git/checkouts/randomx-rust-fba834b8b9a2d6f8/21b3792/randomx" "-DCMAKE_INSTALL_PREFIX=/Users/devron/Downloads/git/epicwallet/target/debug/build/randomx-ef3a8f6e946fe925/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Debug"

The problem was with cmake version 3.22
to fix it //

download cmake version 3.20.0 copy it to the application folder
install the cmake command line: sudo "/Applications/CMake.app/Contents/bin/cmake-gui" --install
go back to the building folder and build it again : cargo clean && cargo build --release


fix: return types and laravel helper function

Summary

Changed array_only to Arr::only, since the helper package is not necessarily installed
Fixed return types
Updated link to documentation

Why are these changes necessary?
I couldn't use the package, the return types are part of PHP and therefore a hard error and not possible try/catch.
How were these changes implemented?
See changed files, it's not much :)
Checklist

[x] Documentation (if necessary)
[x] Tests (if necessary) -> there are no tests?
[x] Ready to be merged

➜ ./vendor/bin/phpunit
PHPUnit 9.3.10 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.4.10
Configuration: /.../laravel-1/phpunit.xml.dist
Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

No tests executed!

Thanks for submitting this pull request! A maintainer will review this in the next few days and explicitly select labels so you know what's going on.
If no reviewer appears after a week, a reminder will be sent out.

A contributor has approved this PR. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait.
Thank you for your contribution!

Your pull request has been merged and marked as tier 4. It will earn you $20 USD.


Some apps can't disabled

Such as game center app from oppo or realme phone
I tap disable and nothing happen app still stay active :-(

...yes, some apps cannot be disabled.
Brevent use pm disalbe-user to disable apps. Sometimes, it won't work.


[TEVA-1346] Redirect to domain if request host is different

This PR redirects requests with different host names to DOMAIN.
See tv_engineering slack channel for context
Note: the rspec/capybara/selenium host/domain config saga was more than a pain the backside, hence not running the redirect before_action in tests

We suspect it fails as the paas internal healthcheck may not pass the right HOST header.
Additionnally, we need to make sure the header is set by cloudfront (in dev , staging, prod).


COPY+PASTE error installing via pip on Python 3.6

Command "/home/alumne/anaconda3/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-ti4r7xo3/pycryptodome/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-gn51nvyh-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-ti4r7xo3/pycryptodome/
Thanks, sounds interesting this module, need to extract text from PDF 1.5 and PYPDF2 cannot do it

Hi @manel00,
I'm closing this issue because it is been inactive for a long time and I don't really understand the issue. Feel free to reopen it if this issue is still important to you.


more optimize tips? for azul zulu prime and Transparent HugePage(THP)

first is that possible to have some test results for Azul zulu prime(for me at least on jave8 is huge improvement compare to regular java)
and for largepage section to have THP?

for THP tutorial can fellow this
https://docs.azul.com/prime/Enable-Huge-Pages
should work for zulu prime and regular openjdk(just for prime when system have THP enabled then flag to enable THP is not needed)
is suggested to use 5.4 or newer linux kernel(meself suggest latest LTS(for now is 6.6.y) or latest stable kernel)

THP guide added in https://github.com/Mukul1127/Minecraft-Performance-Flags-Benchmarks/commit/fba8bf4c89bc4dccf4eb36e62a216460b7eea071, for the testing part, I don't really do any testing as said in the repo and I don't plan to. Feel free to test yourself and maybe even post your results.

Also this may be helpful in trying out Azul Platform prime: https://github.com/brucethemoose/Minecraft-Performance-Flags-Benchmarks/issues/49#issuecomment-1716138313


Formatter next steps

The formatter (#344) should now be able to take any valid program and output an equivalent program. However, there are still some things left to do with the output.
Feel free to convert to issue!

[x] #381
[ ] Comment placement.
[x] #383
[ ] EmptyStatement becomes blank lines where they shouldn't. (Mostly as the first statement in a block since we allow { f() }.)
[ ] f() can be written f', usually (but not always).
[ ] #385
[ ] Blank lines separating use-statements, functions etc.
[ ] Short lists inline, longer lists with one element per line. ([1,2,3] doesn't need multiple lines.)
[ ] Implicit returns.
[ ] Actual formatter tests. Maybe we want to write some sylt code and what it should be formatted to?

Are trailing whitespace still a problem?

Are trailing whitespace still a problem?

Yes, but only for EmptyStatement. Technically a subset of "EmptyStatement becomes blank lines where they shouldn't."


Allow choosing which project.clj file to use if there are multiple

Proto REPL (PR) only looks at the root of the project for a project.clj. It should be possible to start a REPL from a different one if there are multiple. I need to figure out the right way to let the user indicate which one to use.

This could be done by adding a new toggle command, proto-repl:start-from-current-project-clj, that would start a REPL using the project.clj that was open in the active text editor. That would be the easiest way to add it.
More advanced ways would be:

Detect there are multiple project.clj and prompt for which one to use
Allow right clicking on a project.clj and selecting "Start REPL"


Convert Gradle to Maven Build

Ready to go for review. Do not merge until the web5-kt PR below is merged and a proper release is cut there, and updated here.
I'll avoid repetition here. Reasoning and layout is same as extensively detailed in:

https://github.com/TBD54566975/web5-kt/pull/261

Deployed a Release Candidate build: https://blockxyz.jfrog.io/artifactory/tbd-oss-releases-maven2/xyz/block/tbdex/1.0.0-maven-rc-1/
This has been validated as working in developer.tbd.website:

https://github.com/TBD54566975/developer.tbd.website/tree/alrubinger/tbdex-upgrade-v1-kt-maven

Accomplishes the principal goal: make it so that consumers of tbdex-kt get versioning aligned with web5-kt without the need to do any manual dependency coordination by appdevs. Proven by the dev site testsuite POM: https://github.com/TBD54566975/developer.tbd.website/blob/alrubinger/tbdex-upgrade-v1-kt-maven/site/testsuites/testsuite-kotlin/pom.xml#L30

Must document in README: Updates to new web5-kt must be done in two places in the parent pom.xml: when defining the <parent>, and when defining <version.xyz.block.tbdex>.

Add to README: note the distribution package.


Type [System.Management.Automation.PSMemberInfoIntegratingCollection`1] returned by .psobject.properties should have a .Count property

Accessing .psobject.properties on any object is a convenient way to reflect on that object's properties.
Sometimes all you want is to count the number of properties.
That is currently complicated by the [System.Management.Automation.PSMemberInfoIntegratingCollection[System.Management.Automation.PSPropertyInfo]] instance returned not implementing a .Count property.
The workaround is to wrap the .psobject.properties access in @(...) before accessing .Count, but that shouldn't be necessary.
Steps to reproduce
$obj = [pscustomobject] @{ one = 1; two = 2 }
$obj.psobject.properties.Count

Expected behavior
2

Actual behavior
1
1

That is, in the absence of a .Count property on the collection, member enumeration was used to look for a .Count property on each element  of the collection, which - due to PSv3+ implementing .Count even on scalars - returned 1 for each property.
Environment data
PowerShell Core 6.2.0-rc.1
Windows PowerShell v5.1

Actually it is not Collection - it is IEnumerable.
internal class PSMemberInfoIntegratingCollection<T> : PSMemberInfoCollection<T>, IEnumerable<T> where T : PSMemberInfo

    public abstract class PSMemberInfoCollection<T> : IEnumerable<T> where T : PSMemberInfo
``

Yes, @iSazonov, but given its purpose - and, not least, its name, PSMemberInfoIntegratingCollection  - it's reasonable to expect a .Count property, whether as a direct property or via an interface.

We could implement tha class based on Collection. I am afraid that it is too expensive to use in PSObject. We need to avoid every extra byte.

Don't most IEnumerables have a Count property anyway? Why is it lacking on here?

@vexx32: IEnumerable is about lazy enumeration, so the count isn't known in advance - that's why the interface has no .Count property (applies to both the generic and the non-generic interface).

Really you could just add
public int Count => System.Linq.Enumerable.Count(this);

To PSMemberInfoCollection<> just to fix this scenario as it's pretty annoying to run into. Not many folks are likely to though.

I'm down.

I believe the property store could be refactored as a whole (for performance).
/cc @powercode

@iSazonov Yes, I've two different branches on separate approaches for that. But it is non-trivial.
@vexx32 The operation of getting all properties for a type is expensive, since it has to look at many different sources - reflection, type adaptors, registered type info, instance members etc. So to expect a property Count is understandable but much harder to realize than it may seem.
Properties should by design guidelines be like fields, and not do excessive computations, so it may not be a good fit for this case.

@powercode You could share the code - somebody could help (Dongbo :-) ).

@iSazonov  Waste of his time so far.


出错了

Traceback (most recent call last):
  File "/usr/local/bin/s", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/site-packages/iSearch/isearch.py", line 569, in main
    search_database(word)
  File "/usr/local/lib/python2.7/site-packages/iSearch/isearch.py", line 234, in search_database
    print(colored(word + ' 不在数据库中，从有道词典查询', 'white', 'on_red'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-28: ordinal not in range(128)

环境是macOS

是否是最新的版本？pip install -U isearch 更新下，Python2 应该没问题啊

pip install -U isearch
Collecting isearch
  Downloading https://files.pythonhosted.org/packages/ba/40/79d3b01e6b5ed88addcece66adc728d581a2987a1228b8d52aa72b14660a/iSearch-1.0.2-py2.py3-none-any.whl
Requirement not upgraded as not directly required: requests in /usr/local/lib/python2.7/site-packages (from isearch) (0.14.2)
Requirement not upgraded as not directly required: bs4 in /usr/local/lib/python2.7/site-packages (from isearch) (0.0.1)
Requirement not upgraded as not directly required: termcolor in /usr/local/lib/python2.7/site-packages (from isearch) (1.1.0)
Requirement not upgraded as not directly required: beautifulsoup4 in /usr/local/lib/python2.7/site-packages (from bs4->isearch) (4.1.3)
stevedore 0.8 requires distribute, which is not installed.
pyinstaller 2.1 requires distribute, which is not installed.
aeneas <IP_ADDRESS> has requirement BeautifulSoup4>=4.5.1, but you'll have beautifulsoup4 4.1.3 which is incompatible.
fabric 1.6.1 has requirement paramiko>=1.10.0, but you'll have paramiko 1.9.0 which is incompatible.
protobuf 3.5.1 has requirement six>=1.9, but you'll have six 1.3.0 which is incompatible.
Installing collected packages: isearch
Successfully installed isearch-1.0.2

好像有几个问题，但升级成功了。
但问题依旧还在，不知道什么原因。Python3也试过，同样的问题。

我在ubuntu 16.04上也遇到这个问题。


Add mammal species

Add mammal species to the list of species. Mammals can be handled similarly to any other species.

[x] Get list from AL
[ ] Add to the system

@aorin AL said all Finnish mammals should be allowed. Could the system allow all using api.laji.fi for resolving names? I don't remember how mammals were supposed to be saved.
Or download mammal taxon file from Laji.fi and include that into deployment. Then if new mammals need to be added, just add a new file from Laji.fi.

@mikkohei13 The allowed species list look like this currently
...
  "PICPIC": {
    "value": "PICPIC"
  },
  "PPIC": {
    "value": "PICPIC"
  },
  "NUCCAR": {
    "value": "NUCCAR"
  },
...

The mammals don't have that kind of codes... If some mammal names have spaces for example then it may break the shorthand. But maybe it wasn't necessary that they work with the shorthand? Should be easier to add the mammal selection to the day page.

Finnish names don't have spaces, but can have ä, ö and -.
But day page is good as well.

Ok then using the Finnish name could work


Upgrade gradle completion to the official one

https://github.com/gradle/gradle-completion

Lots of updates from you today - thanks!


Fix missing hasher parameter for supervisor test

Minor fix. This came up in CI as well as while trying to test out the commands in #790.

[ ] Referenced an issue explaining the need for the change
[ ] Updated all relevant documentation in docs
[ ] Updated all code comments where relevant
[ ] Wrote tests
[ ] Updated CHANGELOG.md

Codecov Report

Merging #793 (419115c) into master (4752a88) will increase coverage by 2.0%.
The diff coverage is 84.8%.

@@           Coverage Diff            @@
##           master    #793     +/-   ##
========================================
+ Coverage    53.6%   55.7%   +2.0%
========================================
  Files         197     198      +1
  Lines       13682   14060    +378
  Branches     3482    3692    +210
========================================
+ Hits         7341    7834    +493
+ Misses       5942    5894     -48
+ Partials      399     332     -67

Impacted Files
Coverage Δ

light-client/src/builder/light_client.rs
0.0% <0.0%> (ø)

light-client/src/errors.rs
9.6% <0.0%> (+1.7%)
:arrow_up:

light-client/src/store.rs
40.6% <0.0%> (ø)

light-client/src/tests.rs
62.0% <ø> (+6.1%)
:arrow_up:

testgen/src/light_chain.rs
86.0% <71.4%> (-7.9%)
:arrow_down:

light-client/tests/backward.rs
79.1% <79.1%> (ø)

light-client/src/light_client.rs
75.0% <88.8%> (+18.3%)
:arrow_up:

light-client/src/supervisor.rs
80.2% <92.2%> (+51.5%)
:arrow_up:

light-client/src/utils/std_ext.rs
62.5% <100.0%> (+31.2%)
:arrow_up:

light-client/tests/light_client.rs
87.0% <100.0%> (+1.3%)
:arrow_up:

... and 75 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #793 (419115c) into master (4752a88) will increase coverage by 2.0%.
The diff coverage is 84.8%.

@@           Coverage Diff            @@
##           master    #793     +/-   ##
========================================
+ Coverage    53.6%   55.7%   +2.0%
========================================
  Files         197     198      +1
  Lines       13682   14060    +378
  Branches     3482    3692    +210
========================================
+ Hits         7341    7834    +493
+ Misses       5942    5894     -48
+ Partials      399     332     -67

Impacted Files
Coverage Δ

light-client/src/builder/light_client.rs
0.0% <0.0%> (ø)

light-client/src/errors.rs
9.6% <0.0%> (+1.7%)
:arrow_up:

light-client/src/store.rs
40.6% <0.0%> (ø)

light-client/src/tests.rs
62.0% <ø> (+6.1%)
:arrow_up:

testgen/src/light_chain.rs
86.0% <71.4%> (-7.9%)
:arrow_down:

light-client/tests/backward.rs
79.1% <79.1%> (ø)

light-client/src/light_client.rs
75.0% <88.8%> (+18.3%)
:arrow_up:

light-client/src/supervisor.rs
80.2% <92.2%> (+51.5%)
:arrow_up:

light-client/src/utils/std_ext.rs
62.5% <100.0%> (+31.2%)
:arrow_up:

light-client/tests/light_client.rs
87.0% <100.0%> (+1.3%)
:arrow_up:

... and 75 more

Continue to review full report at Codecov.

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


LUIS abstractions should provide first class support for spell check

@carlosscastro Spell check can be added by adding the mkt-bing-spell-check-key header to the http requests to LUIS and then LUIS will return the corrected version into AlteredText. The gap is that the SDK does not expose a way to control headers declaratively or a higher level property specific to spell check.

@carlosscastro
A workaround could likely be made by subclassing the recognizer, creating a new declarative type and controlling the headers internally. Not ideal or nice though, but a way out.
Regarding the long term support for spell check, seems like just by adding a property we could support this. We'd need to figure out where this lies in terms of priorities but it would be great to create an issue to track it and triage.

There's been a thread on this where @darrenj an I have weighed in.  We are of 1 mind that we wouldn't do this work.  if you guys feel differently, then lets have a discussion

No plan to implement this.


fix(@embark/core): Fix tests for shim/monorepo

When embark was running as module inside the dapp’s node_modules, the tests were failing due to several issues:

web3 was not being set in the global namespace of vm2. EmbarkJS.Blockchain.setProvider was therefore failing because it relies on global.web3 to be set. I guess somehow this works when the test app was running in a child tree of the executing program. maybe this is a security feature of vm2, but i’m not sure.
embarkjs provider code being injected to the vm twice. This really was the initial point of failure, as this piece of code is requiring embarkjs, so i’m assuming, but again not sure, that maybe it was getting a second instance of EmbarkJS which did not have it’s providers set up correctly (hence the error with ENS provider not set).

Fixes for those issues in this PR:

To circumvent the web3 issue, we are now setting global.web3 for tests only (the global web3 accessible in the tests), and web3 is now explicitly passed in to EmbarkJS.Blockchain.setProvider
To fix the embarkjs code being called twice, we are not re-injecting this code to the VM during test initialisations

@jrainville - ok to remove changes required?


add spring shoes skills

I don't know what that josn file is.  Thats probably an artifact of me just learning how to use git.  How do I fix that?


Sync common files

When working with multiple packages its a pain to keep files in sync. For example you often want the same analysis_options.yaml across packages. It would be great to have a consistent way of doing this.

Other examples of files to keep in sync, .gitignore, LICENSE.

you can have one .gitignore in the root directory
but otherwise I agree

It was my understanding that pub uses the .gitignore to determine what not to push

Right, I remember that discussions

I'd like to see something like this!

@matanlurey so hypothetically how should this be approached?
Maybe a .mono_repo directory that has the files to sync?

Yeah I guess it depends if you want to configuration or convention based.
@kevmoo what say you?

Or just have an entry in mono_repo.yaml (after https://github.com/dart-lang/mono_repo/pull/29) that specifies a source project directory + files that should sync everywhere?


Metrics output files

Created an app that converts MetricsOutput.tsv file into a MetricsOutput.xlsx file with some modifications which are normally done manually in accordance to the Helios Manual https://cuhbioinformatics.atlassian.net/wiki/spaces/O/pages/3059056641/Helios+Manual+v9.1

Hello @Arun-bioinformatics! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file process_metrics_file.py:

Line 30:1: E302 expected 2 blank lines, found 1
Line 32:71: W291 trailing whitespace
Line 67:48: W291 trailing whitespace
Line 70:80: E501 line too long (86 > 79 characters)
Line 79:80: E501 line too long (80 > 79 characters)
Line 81:80: E501 line too long (85 > 79 characters)
Line 83:40: E231 missing whitespace after ','
Line 115:80: E501 line too long (80 > 79 characters)
Line 119:80: E501 line too long (85 > 79 characters)
Line 121:80: E501 line too long (89 > 79 characters)
Line 122:80: E501 line too long (84 > 79 characters)
Line 123:80: E501 line too long (80 > 79 characters)
Line 124:80: E501 line too long (90 > 79 characters)
Line 144:33: E127 continuation line over-indented for visual indent
Line 145:80: E501 line too long (85 > 79 characters)
Line 156:80: E501 line too long (90 > 79 characters)
Line 160:80: E501 line too long (90 > 79 characters)
Line 161:80: E501 line too long (92 > 79 characters)
Line 180:49: E251 unexpected spaces around keyword / parameter equals
Line 180:51: E251 unexpected spaces around keyword / parameter equals
Line 200:80: E501 line too long (81 > 79 characters)
Line 212:1: E305 expected 2 blank lines after class or function definition, found 1


Improve the UI of introduction to open source page and make it responsive

Category

[ ] Documentation
[ ] Resource Addition
[ ] Codebase
[x] User Interface
[ ] Feature Request

Description

I want to improve the UI of introduction to open source page as it is not looking good now and I will also make the page responsive. I will fix all these, please assign me this issue under JWOC '24

You're assigned.


mmenu Conflict with Google DFP

Hi,
We've the below code on our site - http://brokeassstuart.com/
jQuery(document).ready(function($){
if ( $.fn.mmenu ) {
		$(".vw-menu-mobile-wrapper").mmenu({
			classes: "mm-slide",
			offCanvas: {
				position: "right",
			},
			clone:true,
			transitionDuration:200,
			// searchfield: true
		});

		$(".vw-mobile-nav-button").click(function() {
			$(".vw-menu-mobile-wrapper").trigger("open.mm");
		});
	}

});
The issue is, Google DFP ads(top first ad in right sidebar) not loading when this code exists on site and works very well when its removed. Couldn't identify where the conflict is taking place!.. Can you please help..
Thanks,
~VJ

Hi,
Just found that the issue is specifically with offcanvas addon.. Any ideas?..
Thanks,


Quickinfo displays any in TS files within JSDoc comments

🔎 Search Terms
quickinfo jsdoc ts any
🕗 Version & Regression Information

This is the behavior in every version I tried

⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.4.0-dev.20240120#code/PQKhAIAEBcE8AcCm4DeAKAlOAvAPleACYCG0xAXOAM7QBOAlgHYDmA2gLrgC+X4IwAKABmAV0YBjaPQD2jcNEQ1MlFEVIVqdJm068UA8OFqJoI2nP2HDJMpQ4AaA9wDcArgIGgIkY6fNVUVRsNGgYWDm5efmExSRk5BRoAJmUCYMpQ7Qi9J18zCydrdTt2R0MuV3dPMCg4JEDwACNiWgytFmdIvkFxWRp5RWgAZhwCZtbwAHJJ7g8gA
💻 Code
/** @type {() => { data: string[] }} */
function test(): { data: string[] } {
  return {
    data: [],
  };
}

/** @returns {{ data: string[] }} */
function test2(): { data: string[] } {
  return {
    data: [],
  };
}

/** @type {{ bar: string; }} */
const test3 = { bar: '' }

🙁 Actual behavior
When hovering over any of those properties in the JSDoc comments we get a useless quickinfo mentioning any
🙂 Expected behavior
I'd expect those quickinfos to not be displayed at all in TS files
Additional information about the issue
No response

That's super weird since I thought TS just didn't parse JSDoc type info at all in .ts files, but clearly it's done enough work to know data and bar are things that should have types.


NAT reflection for 1:1 (bi)nat not working as expected

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
Describe the bug
I'm working with a Opnsense 20.1.7.
I already checked the box: Firewall->Settings-Advanced->"Reflection for 1:1"
After creating a new 1:1 nat rule several rdr rules are created besides the binat rule. But the rdr rule for the lan interface is missing
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
To Reproduce
Steps to reproduce the behavior:

Go to 'Firewall->NAT->1:1'
Create a new NAT Rule
2.1. on interface: wan
2.2. external network: virtual wan ip/32 (e.g. <IP_ADDRESS>/32)
2.3. type: binat
2.3. source: dmz lan ip/32 (e.g. <IP_ADDRESS>/32)
2.4. Destionation: any
2.5. Nat reflection: use system default

Expected behavior
On every other interface (except dmz lan and wan) there should be a rdr rule that forwards traffic from the lan segment(s) to the dmz lan whe accessing the virtual wan ip. As a result I cannot access the dmz lan ip from the lan segment(s). Access is only possible from the internet.
Additional context
When I create the port forwarding rule manually on the lan interface I can access the dmz lan ip from the lan segment(s).
Environment
OPNsense 20.1.7 (amd64, OpenSSL).
vmWare virtual machine
seven network interfaces
ipsec
manual outbound nat
openvpn
carp ip adresses

Does it has been solved ?

It is working now, but in the mean time we have changed quite a bit and I cannot say for sure what really fixed the issue.
This issue can stay closed.


App-deployment

Deployment:

link= ("  https://ikoote1.github.io/Portfolio-Setup/" )

STATUS: APPROVED ✔ 🍾 🍾 🍾 🥳 🥳 🥳
Hi @ikoote1 ,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Highlights
✅ Deployed page works fine.
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Help me and point at those optional suggestions, I would like to address them, please.
Thankx.
@bobb-Rob


Add slide number to footline.

On a side note: It seems someone is preparing their slides for the SGS-Abteilungsklausur :wink:
Having slide numbers is something that was previously suggested, and it is indeed a valid suggestion. I did a little bit of testing--this pull request works also with abbreviated titles/authors (e.g., \title[foo]{bar}) and for the handout. It shall be merged :smile:
I will add the change to the copy of the Beamer theme in the combined Beamer template in our department's Git.
Thanks for the patch and for contributing!


3.0.6 produces unexpected console.error in ie9

After upgrading to<EMAIL_ADDRESS>I'm seeing a new console.error in ie9.
A quick look suggests this was introduced by #1075
This causes my app to silently fail when no console is open. When I have the f12 console open I get the following error:

You are currently using minified code outside of NODE_ENV === 'production'. This means that you are running a slower development build of Redux. You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) to ensure you have the correct code for your production build.

Running the same code in modern browsers (chrome, firefox...) produces no console.error.

The error message seems that ie9 is somehow mistakenly detecting that redux is being built minified, which I do not believe is the case.
Some more information about the builds in question. I am building with webpack. I have tried following the suggestions for setting NODE_ENV to "development", but the ie9 errors persist.
Some things I have tried with no success:
In my conditional build configuration:
// Webpack build config is conditionally loaded for prod or development:
if (process.env.NODE_ENV === 'production') {
  module.exports = require('./webpack.config.website.prod.js')
} else {

  // adding this line does not help the ie9 errors:
  process.env.NODE_ENV = 'development'

  module.exports = require('./webpack.config.website.dev.js')
}

Adding it to DefinePlugin in webpack.config.website.dev.js as mentioned in the referenced SO answer also does not help ie9:
// ... config ...
new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"development"',
}),

Minimal config
Here is a minimal webpack config which still causes the error to be shown in ie9:
var webpack = require('webpack');
var path = require('path');

module.exports = {

  entry: {
    main: './js/website/main.js',
    'category-je-minforme': './js/website/category-informe.js',
  },

  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'webroot/wp-content/themes/apr_main/js'),
    pathinfo: true,
  },

  plugins: [
    new webpack.ProvidePlugin({
      Promise: 'imports?this=>global!exports?global.Promise!es6-promise',
      fetch: 'imports?this=>global!exports?global.fetch!whatwg-fetch',
    }),
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"development"',
      DEVELOPMENT: true,
      DEBUG: true,
    }),
  ],

  module: {
    loaders: [
      {
        test: /\.js$/,
        include: [
          path.resolve(__dirname, 'js'),
          path.resolve(__dirname, 'node_modules/qs'),
        ],
        loader: 'babel-loader',
        query: { cacheDirectory: './.babelCache' },
      },
    ],
  },
  debug: true,
  devtool: 'source-map',
}

.babelrc
In case it's relevant, here's my .babelrc. Unlikely the problem is here...
{
        "presets": ["es2015", "react"],
        "plugins": [
                "syntax-object-rest-spread",
                "transform-object-rest-spread",
                "transform-object-assign",
        ]
}

Can you walk through the debugger and check why the warning is happening? What is mistaken in our assumptions?

I just referenced a line that is behaving differently in ie9, which may be the cause for mistakenly thinking the code is minified:
run in chrome:
function foo(){}
foo.name === 'foo'
// true

run in ie9:
function foo(){}
foo.name === 'foo'
// false

Should be fixed in 3.1.4.

Thanks for the quick work. Commit  b1bcee2 was likely sufficient to not crash the app when the console isn't open, which is really all I need for ie9 :smile:.

Also, thanks for reporting!

Good evening: Question, I am not using webpack, but I am getting that error in Chrome. Could you please help me?

@richardvaldiviesomacias What do you use to bundle CommonJS modules? You can only get this warning (it’s not technically an error) with CommonJS.

Thanks for your quick answer. I am using Browserify.

Does the part of the warning related to browserify help?

You are currently using minified code outside of NODE_ENV === 'production'. This means that you are running a slower development build of Redux. You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) to ensure you have the correct code for your production build.

I notice that I have that package. Question, I have redux version 3.0.5 is that a problem?

I’m not sure I understand what you are asking. If you see this warning, please make sure you envify Redux in production. Normally putting NODE_ENV=production before your browserify call should be enough for this. As a last resort you can use prebuilt UMD build in redux/dist/redux.min.js. It doesn’t need envification. I hope this helps.

Thanks @gaearon I will try your advice. This is my first big project using React and Redux, so still learning. Definitely became my libraries of choice.

I'm using browserify with loose-envify transform after babel and I'm setting         process.env.NODE_ENV = 'production'; before bundling modules and still get this warrning in all Browsers.
Tried also with envify package and setting NODE_ENV in global scope.
I'm on Redux 3.6.0.

I found this code within node_modules/redux/dist/redux.js:
if (("development") !== 'production' && typeof isCrushed.name === 'string' && isCrushed.name !== 'isCrushed') {
	  (0, _warning2['default'])('You are currently using minified code outside of NODE_ENV === \'production\'. ' + 'This means that you are running a slower development build of Redux. ' + 'You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify ' + 'or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) ' + 'to ensure you have the correct code for your production build.');
	}

obviously, the point is ("development") !== 'production', I don't know why. Anyone can explain it? I think it should be process.env.NODE_ENV !== 'production'.

@mrdulin : that's the output of the build process, after process.env.NODE_ENV has been replaced with another value.  I've got an article here that explains what's going on: http://blog.isquaredsoftware.com/2016/11/posts-on-packtpub-generic-redux-modals-and-building-better-bundles/ .

@markerikson Thanks. So, my webpack config alias maybe:
redux: path.join(nodeModulePath, env === 'development' ? `redux/dist/redux.js` : 'redux/dist/redux.min.js'),

?


Remove the unused glyphNameMap parameter from Type2Compiled

As part of the changes in PR #4259, which landed over ten years ago, the glyphNameMap property on Font-instances was removed.
The reason that this didn't cause any bugs is that we always fallback on getGlyphsUnicode, and when using that data we also rely on StandardEncoding, hence we should just removed the unused parameter from the Type2Compiled constructor.

/botio test

Nice find!


Move rebase-helper code to a subclass

Fixes #560 #567

recheck

...but, we should introduce a test case for #567 to make sure this PR indeed fixes the problem


BUG - Requester Wait Time metrics have mismatches

Are you a current Fivetran customer?
Yes. My name is Alexei, Analytics Engineer working at Colvin.
Describe the bug
The metric Requester Wait Time is having different numbers compared to the Fivetran UI for the same ticket ids.
Steps to reproduce

Go to Zendesk queries editor. Select ticket_id as row, select Requester Wait Time - Business Hours and Requester Wait Time - Calendar hours as metric.
Go to the dbt output table zendesk__ticket_metrics and query for the same metrics and the same ticket_ids.
The numbers for Requester Wait Time don't match.

Expected behavior
The numbers of the table zendesk__ticket_metrics should match with the Zendesk UI numbers.
Project variables configuration

name: 'dbt_customer_experience'
version: '1.0.0'
config-version: 2

profile: 'customer_experience'

source-paths: ["models"]
analysis-paths: ["analysis"]
test-paths: ["tests"]
data-paths: ["data"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target"  # directory which will store compiled SQL files
clean-targets:         # directories to be removed by `dbt clean`
    - "target"
    - "dbt_modules"

vars:
  zendesk:
    using_organization_tags: False
  zendesk_source:
    zendesk_database: thecolvin-data
    zendesk_schema: fivetran_zendesk

models:
  dbt_customer_experience:
    sources:
        materialized: ephemeral
    staging:
        schema: staging

  zendesk:
    +schema: staging
    intermediate:
      +schema: staging
    sla_policy:
      +schema: staging
      materialized: view
    ticket_history:
      +schema: staging
      materialized: view
  zendesk_source:
    +schema: staging
    materialized: view

Package Version

packages:
  - package: fivetran/zendesk
    version: 0.7.0

Warehouse

[x] BigQuery
[ ] Redshift
[ ] Snowflake
[ ] Postgres
[ ] Databricks
[ ] Other (provide details below)

Additional context
See the screenshots
Screenshots

Please indicate the level of urgency
The metrics are not matching with the Zendesk UI. The stakeholders are being affected in analysis and decision making.
Are you interested in contributing to this package?

[ ] Yes, I can do this and open a PR for your review.
[ ] Possibly, but I'm not quite sure how to do this. I'd be happy to do a live coding session with someone to get this fixed.
[x] No, I'd prefer if someone else fixed this.  I don't have the time and/or don't know what the root cause of the problem is.

Hey @alexei-colvin thanks for opening this issue and digging into our Zendesk metrics! 👀
Does it seem to be that almost all _calendar wait times match (if off by a minute or so)? If so, I want to confirm that the _business wait times are being impacted by our transformation logic around the tickets changing schedules. In addition to the comment I created within Issue #53, I will look into this and provide an explanation of our modeling decisions for you.
Once I provide this write-up, we can chat more about logic in further detail and how it relates to the Zendesk UI metrics.

Hello @fivetran-joemarkiewicz Sorry for the delay. Yes, it seems all _calendar wait times are matching. Regarding the _business numbers, they are very different respect to the Zendesk UI numbers. Are you going to do some updates here or not? I would really appreciate it if you could explain to me what's going on below, to understand why you think the package's results are better than Zendesk's.

Hi All,
The latest release of the package should include the fix that closes the discrepancy of the business metrics for reply time. Feel free to open a new issue if the discrepancy still persists.
Thank you!


Bug fixes

Various bug fixes.

Tests in test_parser.py were failing, but that wasn't being detected because of a typo in _assert_segments.
When the escape character appeared at the start of the data element, the tokenizer was not respecting the escape character.
When a composite data element starts with empty components (eg :::abc), the resulting Segment had one too few empty strings in its elements list.
After serializing a Segment whose data elements needing escaping, the strings Segment's elements array was being changed. The strings in the elements array was becoming escaped.

Thanks VERY much for your patches. Great to see that my lib is of somewhat help anywhere and I'm not the only one in need of  such a thing.


fix(dtype): fix TypeError when casting count result to int64

Fixes #1427
Changes Made
Modified files:

narwhals/utils.py

Added string dtype handling in isinstance_or_issubclass function
Added support for both string-based ("int64") and class-based (nw.Int64) dtype specifications
Added comprehensive docstrings and type hints

narwhals/_expression_parsing.py

Restored file with original type ignore comments
Note: The mypy error in this file is expected and handled by type ignore comments, as it was in the original code:narwhals/_expression_parsing.py:229: error: Incompatible types in assignment
(expression has type \"list[PandasLikeSeries | ArrowSeries | Any]\"
variable has type \"list[PandasLikeSeries] | list[ArrowSeries] | list[DaskExpr] | list[PolarsSeries]\")

tests/expr_and_series/count_cast_test.py

Added new test file to verify the fix
Tests both string-based and class-based dtype specifications
Verified compatibility across all backends (pandas, polars, pyarrow, dask)

Type of PR

[x] 🐛 Bug Fix

Related issues

Closes #1427

Checklist

[x] Code follows style guide (ruff)
[x] Tests added
[x] Documented the changes

Additional Context
This fix enables TemporalScope integration by allowing string-based dtype casting in count operations. The mypy error in _expression_parsing.py is expected and handled by type ignore comments, which is consistent with the original codebase's approach to handling complex type system limitations."

thanks @philip-ndikum for your PR!
closing in favour of https://github.com/narwhals-dev/narwhals/pull/1429 then as we don't want to allow cast('int64'), it should be cast(nw.Int64)


Mark std.file.readText as trusted

std.file.readText includes an unsafe cast from void[] to string but we can verify it can be trusted.

Shouldn't the call to validate be in the trusted portion as well? That way, whatever the input to the trusted code, we can verify the output is valid UTF text. That seems to be the original purpose of these trusted subroutines in the first place, otherwise we're just doing it to fight the compiler.

In light of the recent @trusted debacle... so was I right after all? :)

In light of the recent @trusted debacle... so was I right after all? :)

Not exactly. I think the whole thing should be trusted, it's pretty small.


adds changeSelector method

Allows the user to modify the selector before it’s used in the
publication.
This can be helpful for narrowing results to a certain column based on
the search string used or for encrypting the search string before it’s
used in the query.
I’m not sure how useful this is for others but I thought I would submit
the PR just in case you wanted to add it.

Hello,
In  your doc you say :
modifySelector
But in your code it's
changeSelector
I use changeSelector option and it works.
Thanks.

Thanks @pascoual !

Thanks!

Released, and I also changed it to pass in userId as the second arg, in case that's useful in some cases.

Great ! Thanks all.

Awesome. Needed this 3 days ago. Fixed other tasks. Updated the package. Works! Thanks!


offer programmatic api

currently bower-installer.js is a cli,  could you split it to a lib, so we can require it programmatic

+1


SQL file required

Your work looks good. I want to try. SQL file required

SQL file required

@okyayaykut @amitsavla  Thanks for the feedback. Sorry I didn't check my github account in the past couple of years. Now i'm back, will need to find out where the sql file is.


fix(promise): require the standard interface, not the internal one

@gergelyke Great optimization. Suggested change is performing the exact thing under hood as current. Can't figure out why it was implemented that way as it is currently.
@rhys-vdw Sorry that I'm trying to tidy up PRs and issues.

@gergelyke Thanks. I think this has been killing our CI recently!


Several improvements for Mac

Add URL validation for VSTS_URL variable
Update soon-to-be deprecated node attributes from node.set to node.default
Use homebrew for installing openssl on macOS
More detailed and updated testing guide

@americanhanko,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

The build is failing because of missing environment variables. In previous builds (and missing from mine):
$ export encrypted_19acfaae1edd_key=[secure]
$ export encrypted_19acfaae1edd_iv=[secure]
$ export encrypted_92c995406a15_key=[secure]
$ export encrypted_92c995406a15_iv=[secure]

@americanhanko thank you for the PR 🥇 . It was merged to the master. I will release a new version of cookbook today.


⚠ Community has degraded performance

In 35fb858, Community (https://community.wrk.com/health) experienced degraded performance:

HTTP code: 200
Response time: 194 ms

Resolved: Community performance has improved in fc29e8d.


Add Python type annotation for base Compute API

The goal of this pull request is to add type annotations to the base APIs in an incremental manner.
Adding type annotations to an existing project is much harder (and takes much more time) compared to adding it as you develop a new project and that's why I will take an incremental approach.
I plan to start with the base APIs and see how it goes. It's likely that those type annotations will require various issues in the driver code which will be hard and time consuming to fix (and that's also the reason why I plan to start with the base APIs).

It turns out this will be quite a challenging and painful task.
Existing type annotations I added already uncovered some issues with sub-classes not handling parent types correctly, etc.
We don't have much choice here, but to use a type annotation work around in such scenarios (supporting multiple types aka Union), because we can't break the API.
In addition to that, it will also be hard to come up with good type annotations for our dynamic get_driver and other factory methods.

In addition to my comment above - I also decided I will start with an API per pull request to make sure the PRs don't grow too large.
In this PR I will work on the compute API and other common code which is needed to get that to work.
As far as type annotations for our dynamically returned provider drivers go - I still haven't been able to figure this out.
We may just need to go with returning a reference to the base NodeDriver. It's not ideal since it won't know about any provider class specific methods and arguments, but I'm not even sure yet if we can correctly annotate our code which does our dynamic driver class loading (we may need a MyPy plugin or it may even not be possible).

@tonybaloney ^ maybe you have an idea if we can get type annotations to work for our dynamically loaded and returned driver classes.
For now, I have this - f5a201637f517c86128ef049314996e3bc97e195. As mentioned above, it's not ideal since it won't be aware of any provider driver class specific methods and arguments.
I did quite a lot of research and experimentation and I couldn't get it to work (aka annotate get_driver method that it returns a reference to provider driver class which is dependent on the value of provided provider argument constant).
I believe we may only be able to achieve that using a custom MyPy plugin (but I could be wrong).

I finally managed to get all the tests to pass.
Sadly it wasn't that straightforward. One of the main offenders was our custom "enum" type and making sure it works with type annotations and it's also fully backward compatible. For that, I needed to implement a bunch of "glue" code - 9604610fdd3bc9c86a5c7cc5ca9d42bf2d100be8

Codecov Report

Merging #1306 into trunk will decrease coverage by <.01%.
The diff coverage is 92.92%.

@@            Coverage Diff             @@
##            trunk    #1306      +/-   ##
==========================================
- Coverage   86.25%   86.25%   -0.01%
==========================================
  Files         367      367
  Lines       75252    75279      +27
  Branches     6882     6885       +3
==========================================
+ Hits        64911    64932      +21
- Misses       7568     7571       +3
- Partials     2773     2776       +3

Impacted Files
Coverage Δ

libcloud/common/brightbox.py
53.65% <ø> (ø)
:arrow_up:

libcloud/common/hostvirtual.py
59.37% <ø> (ø)
:arrow_up:

libcloud/common/gridscale.py
83.92% <ø> (ø)
:arrow_up:

libcloud/storage/drivers/cloudfiles.py
79.45% <ø> (ø)
:arrow_up:

libcloud/compute/providers.py
85.71% <ø> (ø)
:arrow_up:

libcloud/compute/drivers/ec2.py
75.01% <ø> (ø)
:arrow_up:

libcloud/common/liquidweb.py
96.49% <ø> (-0.07%)
:arrow_down:

libcloud/utils/loggingconnection.py
63.51% <ø> (ø)
:arrow_up:

libcloud/common/base.py
89.91% <100%> (ø)
:arrow_up:

libcloud/common/azure_arm.py
73.01% <100%> (ø)
:arrow_up:

... and 25 more

Continue to review full report at Codecov.

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

@c-w maybe you have an idea on how (if possible) to handle that in mypy^ - https://github.com/apache/libcloud/pull/1306#issuecomment-509980658

@Kami I'm not sure this is currently possible in mypy since we only know the type of the returned driver value at runtime based on the provider argument.
The current approach looks good to me and may even encourage more users to stick to the methods defined in the base API (a win in my mind since it'll make code more easily cross-cloud portable). We do lose mypy coverage for any ex_ methods, but if a user has code that relies on those, they can always work around it like this:
driver: MySpecificDriver = get_driver(...)

Thanks.
And yes, I believe what you said should work (I will test it and document it).
I plan to release release a candidate / beta version with those changes (probably after the next release) to make sure it doesn't break anything. Only thing I'm really worried about is the enum changes I made.

I'll work on a patch release first (2.6.1) and after that's out, merge this into trunk and prepare release candidate / beta releases with those changes for people to test them out.

@c-w That's what I came up with - 428c3b63.
For some reason, mypy doesn't recognize driver classes (e.g. EC2NodeDriver to be a subclass of NodeDriver), so the following doesn't work:
EC2 = get_driver(Provider.EC2)  # type: Type[EC2NodeDriver]
Rackspace = get_driver(Provider.RACKSPACE)  # type: Type[RackspaceNodeDriver]

The approach I used is not ideal, but I confirmed it works.
I'm not sure why it doesn't recognize it (I didn't dig in too much yet), I assume it's something to do with scoping.
Might even need to open mypy issue / question about it, but I assume they will come back to us with that our code already relies on too much "magic" and meta programming :D

It turns out this PR inadvertently introduced dependency on requests when running setup.py install and we didn't have any install tests which would have caught that.
I believe I fixed that in 4e42ea3c5a7c4cc83dae53958cdc72f9b5df2750, 5159babc482eb4cf8c87215d53dfe71f828a3a0c and added a check in 75f07bd2c75ae6b82ccc07090bdefaa07b9938b8.

Just a heads up - the plan is to add py.typed file which declares Python packages includes type annotations once type annotations are included for all the base APIs.

@c-w I just found out today that casting to a driver type doesn't work as expected - https://github.com/python/mypy/issues/3903#issue-254433060 :/
MyPy won't inherit type annotations from the base class if subclass overrides the method (it doesn't matter if it preserves the parent method signature).
Pretty much only option we have at this point is to add type annotations to all the subclassed methods.
This is obviously far from ideal :/


Fixed 'Invalid column longitude' in Android 29 SDK

The error is still reproducing for image location on API 29
I added checking for android API. Set LONGITUDE and LATITUDE for images if API < 29
This is an error screenshot:

Looks good to me

@bartolkaruza anything else is needed to merge this PR?

@slavakoshevoi given that in this PR https://github.com/react-native-community/react-native-cameraroll/pull/114 we're not using latitude and longitude anymore to fetch those information but we use ExifInterface#getLatLong, should we simply remove them from PROJECTION list as opposed to have a conditional with API Level? @syedrahaman92 thoughts?

@dokkis @slavakoshevoi I also think we don't need Images.Media.LONGITUDE and Images.Media.LATITUDE anymore. Below API Level 29, it will also work because ExifInterface#getLatLong is introduced in API Level 5 https://developer.android.com/reference/android/media/ExifInterface#getLatLong(float[])

@syedrahaman92 @dokkis Agree with you guys. I've updated code

LGTM

@bartolkaruza can we merge this fix?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

I still face this issue even after update to lates cameraroll version and update sdktarget 29

I still face this issue even after update to lates cameraroll 4.0.0 and targetSDK 29

me too, still error happens... with cameraroll 4.0.1 amd targetSDK 29


Class 'Faker\Factory' not found

Bagisto: version 1.1.0
In Bagisto v1.0.0 the faker class was a part of the require section in the composer.json file now it has been moved to the require-dev section which in my mind should be the correct setting for production environments but there is a Helper file in the CORE package that uses the Faker class for some reason (packages/Webkul/Core/src/Helpers/Laravel5Helper.php).

Hi @emperorjm
We have reverted this these dependency.
Thanks for notifying us.

@emperorjm
We are closing this issue. Feel free to reopen this bug if not resolved
Thanks.


When logging in, double tapping the emoji causes a black screen in the app.

Repro steps

Go to freeflowpages and trigger a login for an existing account
Enter pin and while selecting the correct emoji, double tap it.

Expected Result
Logged in
Actual Result
Black screen
System Info
ADDITIONAL INFORMATION
Updated
January 15, 2020
Size
4.0M
Installs
500+
Current Version
1.4.3

still happens on
Type: Staging
Git user: Mathias De Weerdt
Git branch: v1.4.4
Git hash: ca37da7
Time: 11:19:49 31.01.2020


Updating amazon linux release cycles

First, I have to say, I really LOVE the way amazon versions their distros! /s
We only had one release cycle for Amazon Linux AMI, but if you look at the CPE names from the distros, the version are actually like 2016.09, 2015.03 etc.

Amazon Linux AMI 2016.09 /etc/os-release
Amazon Linux 2 /etc/os-release

Also added more cpe names (because Amazon Linux 2 and Amazon Linux AMI have different cpe names)
And I updated the EOL dates for Amazon Linux AMI, since it looks like they extended it until 2023 (ref)
I added comments for releases of the blog post where they were announced for you to verify. I can remove these comments before merging.

We only track stable releases, so 2022 so should not be included in our list. We should add this once it goes to GA. Okay with the CPE changes, but I'm unsure about the extra rows.
Do you see an actual benefit for splitting it into extra rows beyond separate release links.

I see two benefits:

it's more factually accurate, and keeps a history of the release dates
it makes it easier for any tooling to actually match amazon linux releases with their EOL dates (something I'm working on right now actually https://github.com/noqcks/xeol/pull/33)

The downsides:

it's probably more unpleasant to read for a human user, since the EOL dates for Amazon Linux AMI is all exactly the same.

If it makes it easier for tools to use, sounds good to me.
The extension to June 2023 was already covered at https://endoflife.date/amazon-linux

The original Amazon Linux AMI is now in a maintenance support phase with a limited set of packages still being supported. The Amazon Linux AMI FAQ has a few more details.

Amazon calls v1 as EOL, so showing it in green as supported might be incorrect.
Maybe we should use the extendedSupport field for "Maintenance Support", and call it out as EOL'd in Dec 2020?
thoughts @marcwrobel @BiNZGi ?

Maybe we should use the extendedSupport field for "Maintenance Support", and call it out as EOL'd in Dec 2020?

I would prefer to use the support and eol like we do with other products:

label for support: Standard Support
label for eol: Maintenance Support

Also add a remark for this:

Update Jan 4, 2021 – The Amazon Linux AMI ended its standard support on December 31, 2020 and has entered a maintenance support phase. A list of supported and unsupported packages along with additional information is now available here.

I am also not happy with the releaseLabel. I contains the product name itself and it is to long, I would change it to:

2
AMI 2018.03
AMI 2017.09
etc

@captn3m0 updated labels for support and eol


Implement string interpolation as a call to String.interpolation

Before this PR, a string interpolation like:
"hello #{world}!"

was roughly expanded to:
String.build do |io|
  io << "hello "
  io << world
  io << "!"
end

In this PR it's expanded to:
String.interpolation("hello ", world, "!")

The benefits of doing this are:

We can change how string interpolation works without modifying the compiler: we just need to modify the definition of String.interpolation
The way string interpolation works is more visible: anyone can go to the source code and see how it's done, in Crystal, instead of looking at the compiler's source code
We can provide optimized overloads. Right now there are a few:

when interpolating a single string value, like "#{value}", we return the same value. This is uncommon, but why not?
similarly, interpolating a single non-string value just calls to_s on it: much more efficient than using String.build
when interpolating multiple strings we can precompute the total bytesize, something that the String.build approach can't do
when interpolating a char at the beginning or end we use + (uncommon, but why not?)

Eliminates discussions like "Instead of doing "foo#{bar}" you should do "foo" + bar". String interpolation will provide the most performant implementation, always (and I plan to further optimize this by inlining constants if possible, but in a separate PR).

A small benchmark:
require "benchmark"

Benchmark.ips do |x|
  x.report("interpolation") do
    var1 = "hello"
    var2 = "world"
    "foo #{var1} bar #{var2} baz"
  end
end

Results:
before: interpolation   8.51M (117.49ns) (± 4.86%)  224B/op  fastest
after:  interpolation  21.81M ( 45.85ns) (± 3.71%)  48.0B/op  fastest

😻 now I need to update my next presentation that mention interpolation internals. just on time.
Any comparison whether it was better the inline approach for creating the string builder? Because after this PR there will many String.interpolation overloads.

I like the syntax of String["hello", world, "!"] to similar to other literals.  But this could be a macro to call the interpolation method?

Technically, making "#{value}" just return value is a breaking change, because previously it returned a new string. This is only relevant when doing unsafe stuff, but still might it be better to dup the string to avoid any inconsistencies?

@bcardiff Good question! I didn't measure how it affects compilation time or memory. On one hand the old approach generated more code to type (multiple calls). The new code just generates a call, which means that if in your program you have string interpolation with same types the compiler will have those instances cached. But then it will need to create a different tuple type for each combination. But compiling the compiler took the same time/memory, same for specs, so maybe it doesn't matter. I was going to mention all of this in this PR but I didn't because I didn't conclude anything about it.

Technically, making "#{value}" just return value is a breaking change, because previously it returned a new string.

Good point. But what's a case where you want to have a String with the same contents but different memory address?

When you do unsafe stuff with it, such as passing it to a C library that modifies the string in place.

When you do unsafe stuff with it, such as passing it to a C library that modifies the string in place.

Let's try this change and see if it breaks something. Using "#{value}" should be pretty rare, more so doing that in a C interaction.

Or maybe we can just duplicate the string. I guess nobody would do "#{value}" if value is already a string... do doing that with a small performance penalty isn't bad.

Technically, making "#{value}" just return value is a breaking change, because previously it returned a new string. This is only relevant when doing unsafe stuff, but still might it be better to dup the string to avoid any inconsistencies?

While it's a breaking change, wouldn't it be better to still have this optimization in the long run?
The value.dup (which looks nicer) is the same as "#{value}", right?
I wonder how really common is the current "#{value}" usage?

Docs says that Strings are immutable (and that is good), so modifying them isn't just unsafe stuff (things that can break a contract but language "believes" a programmer that he don't), but undefined behavior (things that always break a contract). So there is no breaking change.

Am I the only one who finds this implementation of String#dup (as well as clone) very confusing? Or is it just my Ruby background?
https://github.com/crystal-lang/crystal/blob/0e2e1d067af09e7b1e4573a7258c433e3cf8fa17/src/string.cr#L4276-L4278

Strings are immutable so there's no point in dup allocating a new string. The more memory we can save, the better.
I also agree with reverting my last commit. I'm pretty sure it's harmless.

This is great. I'm really looking forward to the constant inlining as well.
But should this maybe be called interpolate instead? String.interpolation reads nicely as "string interpolation", it's the string interpolation. But technically String.interpolate would be more appropriate I think because you call the method of String that interpolates. Similar to how you call the split method of a String instance so that it splits it. It would also be shorter.
And if you actually call the method it looks like this: String.interpolation("hello", "world") and in this case I really think String.interpolate("hello", world, "!") reads better (even though you are normally not supposed to call it) because you basically ask String to interpolate the following things for you.

Yes, the name can be interpolate. I find String.interpolation to be slightly better because:

it matches what it means: it's what a string interpolation is expanded to
it doesn't interpolate anything. Interpolation is doing "foo #{bar}", that is, putting #{bar} inside of a string. So String.interpolate("foo ", bar) isn't exactly right because the interpolation is already done (by this exact expansion). So String.interpolation looks like it's the result of the interpolation.

We could consider String.concat because that's what it does: it concatenates the arguments. But interpolation is fine as well.

concat was the first name I was going to use, so :+1: from me on that

join might be a strong contender on the name front though.

@yxhuvud We can't optimize Enumerable because it doesn't necessarily return the same elements each time, thus would require to cache the elements and defeat the purpose. But Indexable#join is already optimized in a similar way as in this PR. It's just a bit more complex because of separators.

I think we could optimize Tuple#join and then make this PR use that, it's slightly more complex because I have to do the size and type checks all inside a single method. Plus I liked the idea of having a specific method representing the implementation of string interpolation.

Technically, making "#{value}" just return value is a breaking change

It's not a breaking change since you need to use unsafe methods to observe it.

Actually, Hash's new compare_by_identity could also observe this.
In case you were using "#{value}" to get a copy of a string which doesn't share its object id, this would no longer work (with String you can neither use #clone nor #dup to get a different instance).

I think nobody is doing "#{value}" where value is already a String with the use case of duplicating the string. I'm almost sure that if someone is doing that it's just to convert something to a String (because they maybe don't know about to_s?).
So I wouldn't worry about this. If it's a breaking change then it's fine, we just document what's the expected behavior and provide an upgrade path (Changelog: notice that "#{value}" doesn't create a new String instance if value is a String).

Totally agree. It's fine to change it. But that's a breaking change.

I think nobody is doing "#{value}" where value is already a String

It might be a case of some polymorphic function that ends up doing that. Either way, we are fine with the new behaviour: returning the same object. Strings are immutable.

... and I'd like to have at least some benchmarks on the performance impact on compile time and runtime.

I tried this code:
world = "hello"
baz = 1

{% for i in 1..100_000 %}
  "hello #{world} foo bar #{baz}"
{% end %}

Current compiler:
$ time crystal build foo.cr -s
Parse:                             00:00:00.000111332 (   0.25MB)
Semantic (top level):              00:00:00.326971158 ( 140.35MB)
Semantic (new):                    00:00:00.000738606 ( 140.35MB)
Semantic (type declarations):      00:00:00.041685849 ( 140.35MB)
Semantic (abstract def check):     00:00:00.003865196 ( 140.35MB)
Semantic (ivars initializers):     00:00:00.008136129 ( 140.35MB)
Semantic (cvars initializers):     00:00:00.052535028 ( 156.35MB)
Semantic (main):                   00:00:01.233419492 ( 476.78MB)
Semantic (cleanup):                00:00:00.003785580 ( 476.78MB)
Semantic (recursive struct check): 00:00:00.000530665 ( 476.78MB)
Codegen (crystal):                 00:00:01.421233198 ( 588.78MB)
Codegen (bc+obj):                  00:00:10.021156172 ( 588.78MB)
Codegen (linking):                 00:00:00.418528598 ( 588.78MB)
dsymutil:                          00:00:00.060007620 ( 604.78MB)

Codegen (bc+obj):
 - no previous .o files were reused

real	0m13.675s
user	0m14.764s
sys	0m1.351s

This PR:
$ time bin/crystal build foo.cr -s
Using compiled compiler at `.build/crystal'
Parse:                             00:00:00.000118621 (   0.25MB)
Semantic (top level):              00:00:00.335138769 ( 141.16MB)
Semantic (new):                    00:00:00.000748274 ( 141.16MB)
Semantic (type declarations):      00:00:00.042147838 ( 141.16MB)
Semantic (abstract def check):     00:00:00.004128044 ( 141.16MB)
Semantic (ivars initializers):     00:00:00.006740879 ( 141.16MB)
Semantic (cvars initializers):     00:00:00.061190217 ( 157.16MB)
Semantic (main):                   00:00:00.638093375 ( 269.34MB)
Semantic (cleanup):                00:00:00.003363172 ( 269.34MB)
Semantic (recursive struct check): 00:00:00.000472708 ( 269.34MB)
Codegen (crystal):                 00:00:00.736523215 ( 317.59MB)
Codegen (bc+obj):                  00:00:04.330238197 ( 317.59MB)
Codegen (linking):                 00:00:00.240875165 ( 317.59MB)
dsymutil:                          00:00:00.046648033 ( 317.59MB)

Codegen (bc+obj):
 - no previous .o files were reused

real	0m6.508s
user	0m7.554s
sys	0m0.811s

That's probably because String.interpolation(...) for the same types is cached by the compiler and then reused every time.
Another test that could be done is generating many string interpolations with different types and number of arguments. But note that the above program is 100_000 different string interpolations and it doesn't take that much time, so I think this change is safe for performance (and could actually be a performance improvement).

But note that the above program is 100_000 different string interpolations and it doesn't take that much time

With that I also mean that it's very unlikely that a program will have that many different string interpolations, so this benchmark is like the worse case ever.

Also note that there are 4069 different interpolations across this entire repository, so I think we are still safe with this change :-)

I pushed another commit where #{value} with value a String returns just that string, not a copy, as we discussed above.
Let's do that, mark it as a breaking change, and see if it affects anyone. If so, we can revert it to return a copy.

I did some timings of compiling the spec suite and compiler in a spreadsheet.

Interesting. So it's slower? Let me try it too

I just did that experiment too. Compiling the compiler is slightly faster (around 2 seconds). The all_specs is more or less the same (0.2 seconds slower). I think there's enough flux compiling things that there's no way to draw a conclusion here other than maybe "the changes here don't significantly affect compile-time performance".

@asterite did you use a release mode compiler when testing compile times?
My results were 17 sigma for 7% slower on compiling the compiler.
But it's really interesting that it seems the slowdown and speedup is heavily based on the code being compiled...
I'd really like to automate speed-testing over time but no time :)

yes

Looks nice.
I think I might be getting some weird  backtraces after this commit on OS X, but only with --release FWIW:
test file:
$ cat bad4.cr
def go1
  go2
end

def go2
  raise "boom"
end
go1

$ ./bin/crystal run --release bad4.cr
Using compiled compiler at `.build/crystal'
Unhandled exception: boom (Exception)
  from src/string.cr:4539:0 in 'go2' # THIS LINE
  from bad4.cr:2:3 in 'go1'
  from bad4.cr:9:1 in '__crystal_main'
  from src/crystal/main.cr:97:5 in 'main'

:)