Use of defaults in code

Due to the fact that the defaults in elvis_rulesets.erl and elvis_style.erl aren't always the same, the following might happen.
My elvis.config file has {elvis_style, line_length, #{}}. If I look at the Wiki, I might (wrongly assume the default is 100). The default being applied, in this case, isn't coming from the rulesets but from the style, since the option map is present but the key isn't, which means maps:get(limit, RuleConfig, 80) evaluates to 80, not 100 (as expected).
Do you think it's best to:

leave this matter alone (it's fine as it is),
the defaults should be removed from the rulesets and only exist in the style (the rulesets would just include the rules themselves, not the options),
the defaults should be e.g. exposed in rulesets and then imported in style as, for example,

% rulesets.erl
...
-export([default_line_length_limit/0]).
-define(DEFAULT_LINE_LENGTH_LIMIT, 100).
...
default_line_length_limit() -> ?DEFAULT_LINE_LENGTH_LIMIT.
...

% style.erl
...
line_length(_Config, Target, RuleConfig) ->
    Limit = maps:get(limit, RuleConfig, elvis_rulesets:default_line_length_limit()),
    ...

?

Your concern is very valid.
I would personally strongly prefer your option #2, but I would be fine with #3, as long as you don't use macros and instead return the default value directly in the functions… Even more, I would do it this way:
-spec default(module(), atom()) -> term().
default(line_length, limit) -> 100;
default(line_length, skip_comments) -> false;
…

Thanks, @elbrujohalcon. I think I'll go with a mix of both. A function that allows for an easier to maintain elvis_rulesets and a function with the defaults, so that elvis_rule can be easily maintained to. Both will read from the same source.

Something like
-spec default(module(), function(), Option :: atom()) -> DefaultValue :: term().
default(elvis_style, line_length, limit) -> 100;
default(elvis_style, line_length, skip_comments) -> false.

-spec default(module(), function()) -> DefaultOption :: term().
default(elvis_style = M, line_length = F) -> #{limit => default(M, F, limit),
                                               skip_comments => default(M, F, limit)}.

, perhaps?

maps:get(skip_comments, RuleConfig, false)

would become a more generic
get_option(M, F, Option, RuleConfig) ->
    maps:get(Option, RuleConfig, default(M, F, Option)).

or is this too abstract?

The way I'm looking at this now, which thus implied changes to two test cases, is that:

if a rule map is #{} it doesn't mean "apply no options", since for that we can use disabled,
thus, it actually means "I have no defined options, use the defaults".

I don't really like having 2 default functions… Someday someone will add a literal value to a map default/1 without using default/3 and we'll then have a mix of places to put the defaults.
I would personally choose to only have default/1 which returns both the maps with the default list of options and the defaults for those options… all written down in just one place.

The way I'm looking at this now, which thus implied changes to two test cases, is that:

if a rule map is #{} it doesn't mean "apply no options", since for that we can use disabled,
thus, it actually means "I have no defined options, use the defaults".

I like this but it has to be properly documented.

The way I'm looking at this now, which thus implied changes to two test cases, is that:

if a rule map is #{} it doesn't mean "apply no options", since for that we can use disabled,
thus, it actually means "I have no defined options, use the defaults".

I like this but it has to be properly documented.

Where should it be documented?

I don't really like having 2 default functions… Someday someone will add a literal value to a map default/1 without using default/3 and we'll then have a mix of places to put the defaults.
I would personally choose to only have default/1 which returns both the maps with the default list of options and the defaults for those options… all written down in just one place.

Sure, will do. It's an extra maps:get I think, but it should be performance-degrading in a significant way.

Sure, will do. It's an extra maps:get I think, but it should be performance-degrading in a significant way.

It shouldn't be performance degrading.

Where should it be documented?

Probably here.

Should this be enough:

Note: using #{}, as an option map, will mean that defaults apply, i.e. it's not the same as disable
?

Yeah!

Yeah!

Done!


[TACHYON-1079]  Order Journal entry types

Jenkins, test this please.

Can one of the admins verify this patch?

Jenkins, test this please.

Jenkins, okay to test.

Jenkins, test this please.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/5590/
Test PASSed.

LGTM.

Thanks!


Add autoNotify API for internal use by bugsnag-unity

Goal
Alters bugsnag-cocoa so that it is capable of supporting Unity's AutoNotify API, which allows automatic error detection to be enabled/disabled after Bugsnag has initialized. This is not exposed as part of the Cocoa interface and is intended for internal use by Unity only.
Changeset

Added autoNotify as a private property of BugsnagClient
When autoNotify is updated bsg_kscrash_setHandlingCrashTypes is invoked with the appropriate error types to capture automatically

Testing
Added E2E tests to verify that autoNotify is respected for NSException/Signals, and that error capture behaviour is unaltered if the flag is toggled off then on.

Added scenarios to macOS test fixture and addressed review comments.


feat: upgrade sdk to v0.47.x

Closes: #XXX
What is the purpose of the change
Updating the node to v0.47.5
This is still WIP.
Currently upgrading protobufs to the latest.
To start working on this clone https://github.com/cosmos/cosmos-proto locally
and change the replace directive in three go.mods from:
github.com/cosmos/cosmos-proto => /home/ghost/git/cosmos/cosmos-proto to point at your local installation

go.mod
ibc-hooks/go.mod
osmoutils/go.mod

Then run:
go mod tidy in each
Then run:
make install
The error for proto generation should be:
/home/ghost/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.5/runtime/services/reflection.go:60:28: type func(x *descriptorpb.FileDescriptorProto, y *descriptorpb.FileDescriptorProto) bool of func(x, y *descriptorpb.FileDescriptorProto) bool {…} does not match inferred type func(a *descriptorpb.FileDescriptorProto, b *descriptorpb.FileDescriptorProto) int for func(a E, b E) int

devbot help


Support for MSSQL version above 4.1.0

Well, have we had any news for that?
https://github.com/knex/knex/blob/232fe9f1517dba927f6a3a1fb1b8842d7c0a4007/src/dialects/mssql/index.js#L52-L70

check a bit more recent version of source codes... https://github.com/knex/knex/blob/master/lib/dialects/mssql/index.js#L65


Zoom out function is not working in Capidle Map

Description
The zoom-out button in Map in Capidle is not working. It can be zoomed out with other methods.
Steps to reproduce

Open Capidle
Click on Zoom out ( Minus button)
No response

Expected behaviour
The map zooms out once we press the button.
Potential cause
I don't have any idea, it might be has something to do with the map function inside Capitle\script\render.js But it is out of my ability and I am not very certain about it.

Approved! This might be critical for mobile users

Might be good to do a little more preliminary analysis to find a cause before we approve this for development.


Working for NENAH003 (run 2)

@finnlennartsson from discussion today: consider %t=time tag from dcm2niix

@finnlennartsson from discussion today: consider %t=time tag from dcm2niix

Now that NENAH003-run1 and NENAH003-run2 are placed under the new folder NENAH003, this and the other cases need to be re-runned.

Viewing derivatives/preprocessing_logs/sub-NENAH003/sub-NENAH003_DcmSourcedata_to_NiftiRawdata.log:
INFO: Running heudiconv version 0.9.0 latest 0.9.0
INFO: Need to process 1 study sessions
INFO: PROCESSING STARTS: {'subject': 'NENAH003', 'outdir': '/dataOut/', 'session': None}
INFO: Processing 3935 dicoms
INFO: Analyzing 3935 dicoms
Traceback (most recent call last):
  File "/opt/miniconda-latest/bin/heudiconv", line 33, in <module>
    sys.exit(load_entry_point('heudiconv', 'console_scripts', 'heudiconv')())
  File "/src/heudiconv/heudiconv/cli/run.py", line 24, in main
    workflow(**kwargs)
  File "/src/heudiconv/heudiconv/main.py", line 351, in workflow
    grouping=grouping,)
  File "/src/heudiconv/heudiconv/convert.py", line 176, in prep_conversion
    custom_grouping=getattr(heuristic, 'grouping', None))
  File "/src/heudiconv/heudiconv/dicoms.py", line 215, in group_dicoms_into_seqinfos
    .format(studyUID, file_studyUID)
AssertionError: Conflicting study identifiers found [<IP_ADDRESS>.1<IP_ADDRESS>.145028.30000020071109585511800009105, <IP_ADDRESS>.1<IP_ADDRESS>.145028.30000020102410181784900012690].


Added a menu item

Added a Caesar Salad menu item into the mix

Please add more to your menu!

LGTM!


feature/interactive: add insert mode

This adds a cursor movement and inserting a character in arbitrary place.
Truly saying I got confused implementing that in order of complexity.
Might it would be better to split responsibilities of rendering the general list of suggestions from the custom line.
In this case there would be no need in rendering the whole suggestion list one more time.
And the complexity would be reduced just because each part of interface is responsible for one thing. (I see that it's what should have been done but ... :)).
yep. I consider the code this PR providing is slightly compound :(
PS: These thoughts I have in order to not thinking that my code just bad :smiley:

Could you git fetch -a && gut rebase upstream/master where upstream refers to this repo (not your fork) so the merge conflicts get resolved which causes ci to not trigger

I left the control over rebasing it :smile: .
Might it's worth to squash everything and force push here?

No worries :)


STEPS FOR CREATING A DEEP LEARNING MODEL

THE BASIC STEPS FOR CREATING A DEEP LEARNING MODEL.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding. ✈


Implement Photon-Beetle-AEAD{32, 128} Schemes

[x] Implement Photon-Beetle-AEAD[32] encrypt/ decrypt routines
[x] Implement Photon-Beetle-AEAD[128] encrypt/ decrypt routines
[x] Test functional correctness of AEAD implementation
[ ] Benchmark AEAD routines on CPU based system

To learn more about AEAD, see https://de.wikipedia.org/wiki/Authenticated_Encryption

Test by issuing
make

Benchmark on CPU systems, using
make benchmark


$connection property not working in Migration.

Laravel Version: 8.75
PHP Version: 8.1
Database Driver & Version: mariadb

Description:
After declaring protected $connection = 'mysql_external';  Schema facade still using default connection, but should declared in $connection property.
So, fix the framework or change documentation... https://laravel.com/docs/8.x/migrations#setting-the-migration-connection
I see the problem exist form laravel 5, and still arent fixed, but issue closed? https://github.com/laravel/framework/issues/31060
Resulting problems:
-php artisan mirgrate:fresh not droping external db tables
Steps To Reproduce:

Mar 2021 comment from Taylor about the state of things: https://github.com/laravel/framework/issues/36596#issuecomment-799784094
$connection alone can't be used to configure a secondary database. Schema::connection() is required too:
protected $connection = 'mysql_external';

function down()
{
    Schema::connection('mysql_external')->drop('user_settings');
}

or:
function down()
{
    Schema::drop('user_settings');
}

php artisan migrate:rollback --database=mysql_external

This docs section was added last year: https://github.com/laravel/docs/commit/f3f5a24aa228290d69404f4f4fbdb41a4b0b7d1b

I'm unsure if the framework behaved this way after looking at branches 7.x, 6.x, 5.8, 5.7, then back to 5.4. I can't find anytime Illuminate\Database\Migrations\Migration@getConnection() was explicitly switched into per migration before methods up() or down() are called. That $connection is only used by DB::transaction() and DB::pretend() but the queries would still run using the default connection (or the --database command override.)
A bug fix PR was attempted last year (https://github.com/laravel/framework/pull/35841 https://github.com/laravel/framework/pull/35840) but it lacked important additional tests on a critical feature (:rotating_light:) so it was closed.
I just a crack at it https://github.com/laravel/framework/compare/8.x...derekmd:fix-migrations-connection-property?expand=1 but some code duplication with Migrator::withConnection() isn't great. If $connection is used, I assume the migrations table row should still be using the default connection (or --database) so the Migrator::respository instance shouldn't be modified per migration.
Either a bug fix PR like mine can be merged to 8.x or the docs snippet needs expanding with Schema::connection().

Thanks @derekmd. I feel like your PR can be attempted. If Taylor rejects it we can maybe look into a docs update.

I am also affected by this issue. Will this problem be addressed in the near future or should I look for a solution myself?

@ImChriz see the convo above


Kafka consumer partition offset off by 2?

Hi,
I have a kafka topic with a single partition. I would like to create a consumer with the single purpose of returning me the last message that was produced on the channel (and that's it).
The use case is that this is run by the producer at the beginning of each run. The producer listens to some other data source and relays any new entries into the kafka topic. In the case of producer downtime or failures, it needs to recover from where it last left off.
Please let me know if any of the below are not the correct ways to do this. This is basically what I have:
def getKafkaTopic(topic):
    client = KafkaClient(zookeeper_hosts=getZookeeperHosts())
    return client.topics[topic]

and then
topic = getKafkaTopic('some.topic.name')
consumer = topic.get_simple_consumer(consumer_group="some_consumer_group")
partitions = [p for p in consumer.partitions.itervalues()]
offset_pairs = [(p, p.latest_available_offset() - 2) for p in partitions]
consumer.reset_offsets(partition_offsets=offset_pairs)

This works. However, I'm baffled at the requirement for p.latest_available_offset() - 2.
Given that an offset value in kafka points to the "next message to be consumed", I would expect a consumer at p.latest_available_offset() to block until the next message is produced, so that would be as expected. However, p.latest_available_offset() - 1 will also block until the next message is produced, whereas p.latest_available_offset() - 2 will get me the last message produced.
Is this an off by one error somewhere in pykafka? Or am I just not understanding kafka?
Thanks,
Jack
PyKafka version: 2.2.0
Kafka version: 0.8.2

Hi @zhaojack, thanks for filing this. The behavior you're seeing is a consequence of pykafka's handling of the "funky" Offset API. The Offset API accepts timestamps, not offset values. To allow users to reset to specific offsets, pykafka attempts to treat them as timestamps and assumes they're offset values as a fallback.
Effectively, the offset value you give in reset_offsets is treated as the offset most recently consumed by the consumer. If you pass latest_available_offset - 1, the consumer understands this to mean that latest_available_offset - 1 was the last offset consumed, and that latest_available_offset - 1 + 1 should be the next message consumed. Since latest_available_offset doesn't exist on the topic yet (due to the way that the Offset API works), the consumer hangs until it becomes available. If you pass latest_available_offset - 2 to reset_offsets, the consumer sets its "next message" to latest_available_offset - 2 + 1, which is the actual latest message appended to the topic.
The documentation of the Offset API indicates that

The response contains ... the "log end offset" i.e. the offset of the next message that would be appended to the given partition. We agree that this API is slightly funky.

For this reason, I realize that latest_available_offset is a misleading name. The function should probably return an offset one less what it currently returns.
See the logic you're hitting in this example for more detail.


Repeated calls to uniform() produce non-uniform output

Repeated calls to :uniform(0, 1) produce non-uniform output.  This only happens with CudaTensors and only across many calls to uniform, filling a large tensor with a single call seems okay.
-- this produces uniform output
-- local block = 10000

-- this does not
local block = 1

local r = torch.zeros(block):cuda()
for j = 1, 10000/block do
    r:uniform(0, 1)
    -- this is also broken
    -- r:rand(r:size())

    for i = 1, r:size(1) do
        print(r[i])
    end
end

Yes, you're right. The output seems to be "less uniform" when not generating a whole batch. It seems to get better the more numbers you generate but it's still not great.
I'm guessing that CUDA's random number generator isn't really designed for generating single numbers. To be efficient, you want to generate lots of them at a time. This is opposed to the Torch RNG where it doesn't make a difference whether you generate a single number N times, or N numbers in a batch (both in terms of performance and the result).
I don't think this is a problem in practice. If you only want to generate single numbers at a time, you can just use torch.uniform().

We did some more digging into this:
It turns out that the numbers generated by our RNG are only properly distributed when generating at least a few thousand numbers at a time (we used the dieharder tests to verify that). This is only since we changed from using cuRAND's host API to its device API. The host API always generates good numbers.
Some profiling suggests that the host API is always generating 16384 (64*256) random numbers at a time and then copies numbers from that pool into the output buffer. I can think of two ways we could do something similar:

Generate a pool of random bits and transform them into the right distributions on-demand (this is what the host API is doing afaict).
Have different pools for different distributions (eg. uniform and normal) and transform those numbers to the right distribution on-demand.

While the second option may obviously use more memory than the first, it would probably be easier to implement because we don't have to think about how to transform random bits into uniformly (or normally) distributed floats, for example.

this was documented in NVIDIA's CUDA docs, or I remember reading so.
Second option might end up using significantly more memory. If the overhead is less than say 10-25MB and it would save you tons of time, go for option 2. If the overhead of going for option (2) will hurt people with 2GB or 4GB cards (for example), then it is not great, and option (1) might be the way.

Storing 16384 floats takes up 64KB, so if we keep a set of uniform, normal and log-normal numbers around (the distributions that we currently rely on), we'll only use 192KB of extra memory. And we could allocate that lazily.
I think it makes sense to take advantage of cuRAND's capabilities to give us numbers from these distributions directly, rather than doing it ourselves.

okay, then (2) sounds good. I agree with you that we take advantage of cuRAND directly to give us these numbers.

A log-normal Y can be obtained from normal X by: Y = exp(X).
So we can avoid storing log-normal numbers.

I'm worried of storing separate pools: it opens up the door to introducing correlations depending on the order in which you call the pools, in an application that uses different distributions.
All the (little) theoretical guarantees that I'm aware of rely on having a good source of independent uniform numbers, then transform it them to get a stream of independent numbers regardless of the distribution of each number.
I'm not saying the two pools is a bad idea, but I'm saying it is a very nonstandard one for which we have no guarantees whatsoever -- something which I'm always worried about when it comes to fundamental tools like this.
It is likely that behind-the-scene cuRAND's generation of normal numbers actually calls the uniform generator and transforms them on-demand. I do not know for sure, but that is the way I have seen it done in all RNG toolboxes I've encountered so far. We should be able to port the transformations from these classic generators (e.g. randomkit) without too much difficulty.
I would suggest option (1). The not-too-big extra work it requires is worth the maintained guarantees. Also, we shouldn't forget to add enough information to the state variable that we can reproduce the pool exactly, for example:

storing the pool in addition to the current uniform RNG state: that makes for a bit larger state, but is the simpler to store/restore.
storing the state as it was before the last pool-filling,  the number of variates sampled from there, and the number of variates, left in the pool, so as to rebuild the pool at restore time. That makes the smallest information, but also the heavier state restoration.


pandas: loc indexer not return the correct type of object

Hi, developer. I meet  a problem when using 'loc' to select some columns, it seems 'loc' doesn't return the a DataFrame for me

any advise would be appreciated, thanks

update:
I checked the stub files

I think my code should be refered as a DataFrame not a Seires accroding to the code in stub file

@RuixiangLiu01, could you please add a code snippet for this so that we could repro?

@RuixiangLiu01, could you please add a code snippet for this so that we could repro?

Thanks for reply. Here is a simple example:
df = pd.DataFrame({'A': [1, 2, 3, 4], 'B': [2, 3, 4, 5]}) df1 = df.loc[:,'A']

I am not sure is it helpful for u

In that example you gave, Pylance infers that df is a DataFrame and df1 is a Series, and that is correct. Can you give an example where waht Pylance shows you is not correct?

This is a non-trivial fix; right now things only work as well as they do because of a bug :-( There's a bunch of complexity around this kind of indexing that I need to think through.

This issue has been fixed in version 2021.5.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202150-5-may-2021


Error: Building package boost-compatibility:x86-windows failed with: BUILD_FAILED

On Windows 10  of 10.0.18363
To Reproduce
Steps to reproduce the behavior:
`./vcpkg install pcl
Starting package 3/103: boost-compatibility:x86-windows
Building package boost-compatibility[core]:x86-windows...
Could not locate cached archive: C:\Users\Erixar\AppData\Local\vcpkg/archives\34\34231cecbadde1397f5d99437d20f1c9044172c1.zip
-- Downloading https://github.com/boostorg/compatibility/archive/boost-1.73.0.tar.gz...
-- Extracting source C:/dev/vcpkg-master/vcpkg-master/downloads/boostorg-compatibility-boost-1.73.0.tar.gz
-- Using source at C:/dev/vcpkg-master/vcpkg-master/buildtrees/boost-compatibility/src/ost-1.73.0-44642da97c.clean
-- Packaging headers
-- Packaging headers done
-- Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.73.0/LICENSE_1_0.txt...
-- Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.73.0/LICENSE_1_0.txt... Failed. Status: 6;"Couldn't resolve host name"
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:181 (message):
  Failed to download file.
  If you use a proxy, please set the HTTPS_PROXY and HTTP_PROXY environment
  variables to "https://user:password@your-proxy-ip-address:port/".
  Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
installed/x86-windows/share/boost-vcpkg-helpers/boost-modular-headers.cmake:17 (vcpkg_download_distfile)
ports/boost-compatibility/portfile.cmake:12 (boost_modular_headers)
scripts/ports.cmake:79 (include)
Error: Building package boost-compatibility:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: boost-compatibility:x86-windows
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.
Additional context
This problem appears when I'm trying to install pcl on my new computer,and before that vcpkg failed to connected with nuget to get 7-zip. I have to download it manually. Is there some mirror sources can be used in China?

Duplicated to https://github.com/microsoft/vcpkg/issues/13348.


remove code related to feature-flag api

Resolves

#605

Things removed related to featureFlag api -
Routes
Controllers
Models
Integration tests
Unit tests
Validators
/feature-flag route from routes/index.js

Looks good to me.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

AWS CodeBuild CI Report

CodeBuild project: DDKIntegrationTestsD8472609-5SCHWjldmWcf
Commit ID: 9e46d8c4082ba63a42adbc0a60c9caa972c1c2d0
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Virtual kubelet: enable skipping single object reflection

Description
This PR introduces the possibility to skip the reflection of an arbitrary object living in an offloaded namespace through the addition of an appropriate annotation.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ] Automated testing (existing + new)
[ ] Manual testing

/build

/build

/test

/test

/rebase test=true

/merge


Update container addons references for a new release

Why is this PR needed?
Required for renewal of addon containers for CaaSP 4.5.4 release
What does this PR do?
bump addon image references

Merging since I just realized our workers in the CI got updated with wrong terraform packages. Fixing it requires changing the repo set and redeploying them. I am not going to do that now for this simple change on addons image versions.


Add ability to export weighted normals

The exporter currently averages smooth normals on export. However, advanced users may want the ability to export custom weighted normals, something the FBX-JMS pipeline supports. This can be used to achieve nice results in hard surface modeling with less geometry.
I propose that this be a new ASS/JMS export option grouped with the existing edge split options, but off by default because beginners will definitely shoot themself in the foot with poor normals otherwise.

Latest patch now uses loop normals instead of vertex normals so this should no longer be a problem.


WEDO and lists

WEDO has no support for lists. That is ok.
But in the start block you can set the type in a variable declaration to 'list of numbers', e.g.. Then the front end crashes.
BTW: blockly throws an error message 'no list support for wedo', but this exception is ignored.
Solution: the type drop down should not contain list types

solved


v 0.32.0  Cannot localize all text, only partial text can be localized

Reproducible in vscode.dev or in VS Code Desktop?

[X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
import { setLocaleData } from 'monaco-editor-nls'
import zh_CN from 'monaco-editor-nls/locale/zh-hans'
setLocaleData(zh_CN)
// import * as monaco from 'monaco-editor'
const monaco = require('monaco-editor/esm/vs/editor/editor.api')

Actual Behavior
Only part of the text has been localized, and most of the text is still the original text

Expected Behavior
When I return to version 0.30, I can localize it all

Additional Context
monaco-editor version : 0.32.0
monaco-editor-nls version: 2.0.0
monaco-editor-esm-webpack-plugin version: 2.0.2
monaco-editor-webpack-plugin version: 7.0.0

to add to this, this happens with some suggestion text also, eg


Suggestion: Make serde an optional dependency

One suggestion to prevent bringing in more dependencies than a user needs would be to make serde an optional dependency and adjust the Serialize and Deserialize derives be like #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]. This would be a breaking change so would need a minor version update.

This sounds like a good idea, thanks for pointing this out! We're currently contributing a lot of changes for a 0.2 version, so the minor version update is not a problem IMO.

we can't move the serde dependency behind a feature flag for linfa-linear and linfa-logistic because of argmin

I just merged a PR in argmin which adds a feature that allows users to remove the serde dependency. This isn't released yet though and unfortunately  I can't make any promises yet as to when there will be a new release.

Update: We just need to bump argmin in linfa-logistic and linfa-ftrl to 0.7, the same way it was done in linfa-linear.


Simple Intro Skip with Jump

I  decided to reverse your method entirely and create my own method based on your initial research

I could not get your method to compile.
transplanting your method to my internal debug resulted in a crash for me.

CHANGES

Removed Extra Window
Removed Detour

The sig scan now points to (currently) eldenring.exe+0AB01EE
The patch is now a simple jump from (currently) eldenring.exe+0AB01EE to eldenring.exe+0AB020F
It takes roughly 14seconds from launch to title screen

Thank you for the PR, I always appreciate people contributing.
A couple questions:

Is this also supposed to skip the initial white screen? (Not part of the intro logos).
What kind of errors were you getting when trying to compile? I assume it was related to MASM.

Thank you for the PR, I always appreciate people contributing or commenting on the code.
A couple questions:
* Is this also supposed to skip the initial white screen? (Not part of the intro logos).

* What kind of errors were you getting when trying to compile? I assume it was related to MASM.

I helped him on this as well, I was there when we were trying to figure it out. By the "initial white screen" I assume you mean the one that immediately follows after booting the game before the FMV's being player (I.e the swapchain initialization screen) this cannot be skipped as the game requires DX12 to run the swapchain any DX application will be white initially before successful init.

Thank you for the PR, I always appreciate people contributing or commenting on the code.
A couple questions:

Is this also supposed to skip the initial white screen? (Not part of the intro logos).
What kind of errors were you getting when trying to compile? I assume it was related to MASM.

 I did not understand that is another thing your window was doing until after I made my pull request. I imagine including the window to cover the initial "FlashBang" as you call it could still be accomplished with this jump?
Thinking about it further ... It seems you have done this code cave jump so that you could include a flag at the end. Upon being flipped TRUE the created window is queued for destruction.
In regards to compiling errors:
MSB3073

The command "COPY "X:.CODING.GIT_CLONES\EldenRingMods\x64\Release\SkipTheIntro.dll" "G:\SteamLibrary\steamapps\common\ELDEN RING\Game\mods" :VCEnd" exited with code 1.
SkipTheIntro C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets	155

https://user-images.githubusercontent.com/80198020/163671001-9b75c2da-cd6a-4c5b-9551-f3cb5e7fb657.mp4

Yeah the mod actually skips the intros entirely by overwriting a jump and then in addition creates the window to hide the initial white screen.
The build error you are getting is because I have post-build events set up that copy the DLLs to my game directory, I don't know if there's a better way for me to distribute the VS solution without having to manually remove the build event before pushing to Git...
Thank you for your interest and time, however for now I don't see a reason to merge this change.
As for the D3D swapchain stuff, it would be nice if we could remove the white screen in a more direct way, however one thing to keep in mind is that this modification is very time sensitive, a good solution must apply almost immediately as the game is launched. Sigscanning for D3D functions or variables, or even looking through the VMT might take too long. If the modification takes more than ~0,2 seconds then you will still get flashbanged.
It's also possible that the white background color is related to the initialization of the window itself, and not the D3D initialization. I tried messing with the game window using some Winapi functions, but I don't believe doing it that way will work.


Re-evaluate MacOS support...?

https://www.youtube.com/watch?v=Yt3DbfIVXDQ
Dawid (not a typo) makes some great points in this video about the current state of gaming on the Mac. It's atrocious; and, quote: "I don't want Apple anywhere near the game industry."

I mean, sure? But really the ultimate point here is that mac gaming is where it is because developers don't bother porting their software properly.
Granted it can be a real hassle to put together an App Bundle for mac without knowing what you're doing. I've been banging my head on a desk for awhile to get an OutpostHD mac bundle ready for distribution and it's been a headache and a half.
The same could be said for Visual Studio though it's not quite as rough.

Yeah, this isn't something I can take seriously. We're not going to strip Mac support just because someone doesn't like Mac.
Besides, Mac builds are done with the makefile, largely the same as Linux. There isn't really that much difference in the actual build between Linux and Mac. Mostly it's just a slightly different environment in terms of dependency install, and a different version of Clang.
I don't know much about Mac bundling. That's something we've never supported.

The builds for mac are basically the same, but distribution is a little less simple for developers. There are two possible ways to do it -- I can either develop and xcode project that builds a Swift based app that then calls an embedded C++ CLI tool... or I can write a package installer app which will install the needed dependencies and binaries where they need to go and set up an Alias for the application either in the Applications folder or on the Desktop (not sure what's best practices for macOS yet).
I'm finding it really difficult to figure out the xcode bundling so I'm considering just using an installer script that handles it for us though it's not really the 'mac way' of doing things... but eh, whatever, this isn't a commercial product :D

Could just leave it to Mac people to figure out for now. I mean, the code compiles on a Mac, so they're not totally unsupported. As it stands now, we don't really have any expertise in bundling software for Mac, and we maybe need to be careful what we spend limited time and energy on.
I'm sure we'll get there eventually, but if we're busy with other stuff meanwhile, and someone more knowledgeable happens to come along and do Mac bundling for us, then hey, that would be nice. I certainly wouldn't object to such help.

It compiles without change on an Intel based mac. M1/M2 mac's have different settings for Homebrew which was annoying to figure out -- basically we'll need to add a "Building from source on macOS" and have an addendum for Apple silicon.
Homebrew basically builds to /opt/Homebrew/include and /opt/Homebrew/lib instead of wherever it goes on Intel macs. Not sure why the change but for me the easiest solution was to add these to the correct $PATH environment variables. Can add this as an aside to a "Building on Mac" document.
Separate issue from this but thought I'd mention it since it took a bit to figure out for me.


feat: Add support for formatted json

What kind of change does this PR introduce?
Feature
What is the current behavior?
Currently does not support output in formatted json.
What is the new behavior?
Ouput is also available in formatted json.
Additional context
None

Just trying to understand the use case here. Why do you need this feature?

For debugging purposes, it is easy to look at.

@devsdocs Are you using the yet_another_json_isolate as a standalone package or through some supabase packages?

Closing because of no response. Just comment if you still believe this should be added, and I'm open to reopen this pr.


Implement godot-entry-generator

TODO: split in different subtasks
Has to be done after: #68, #69, #70, #71, #72 !
Implement the entry generator. It should be called by the godot-annotation-processor and receive the lists described here: #71 . With those lists, the entry file should be generated and all the gdns files should be generated. If the gradle plugin sets the automated removal of the generated gdns file to true, it should also remove all obsolete gdns files from the filesystem.
For more information: write @chippmann on Discord.

@RegisterProperty
var int = 100

@RegisterProperty
var ints = variantArrayOf(100, 200) //only VariantArray is allowed!

@RegisterProperty
var int = PoolIntArray(100, 200) //treated as primitive

@RegisterProperty
var float = 1.0f

@RegisterProperty
var double = 2.0

@RegisterProperty
var str = "hello"

@RegisterProperty
var bool = true

@RegisterProperty
lateinit var resource: Resource //if not lateinit -> fail, customResources: just have to derive from Resource but are exported as Resource and not as custom type

@RegisterProperty
var nodePath: NodePath = NodePath("")

@RegisterProperty
var nodePaths = variantArrayOf(NodePath("A"), NodePath("B")) //only VariantArray is allowed!

@RegisterProperty
@EnumFlag(MyFlag.ONE, MyFlag.TWO)
lateinit var flags: Set<MyFlag> //fail if not lateinit as default values are passed in annotation

closing in favor of individual issues


Adding a column (if quantitative trait) or two (if binary trait) to the table ”Gene prioritisation using colocalisation analysis” on the Gene prioritisation page to infer directionality of effect

These additional columns will help users to infer whether an increase or decrease in the expression of a given gene/ abundance of a given protein in a given tissue/cell type is likely to cause an increase in the trait/increase of disease risk.

The column headers could be “Direction of effect” for the quantitative trait phenotypes and “Direction of effect” and “Therapeutic mode of action based on GWAS/QTL” for the binary traits. We need to discuss this before implementation.

There are 8 scenarios.

For Quantitative traits

Here, I'm referring to β1 as the β from the association summary (left study) and β2 as the QTL beta displayed in the “Gene prioritisation using colocalisation analysis” (right study) under the table tab.

Scenario 1: β1 is positive and β2 is positive: ↑ expression ↑ trait

Scenario 2: β1 is negative and β2 is negative: ↓ expression ↓ trait

Scenario 3: β1 is positive and β2 is negative: ↓ expression ↑ trait

Scenario 4: β1 is negative and β2 is positive: ↑ expression ↓ trait

Writing this down makes me realise that we cannot infer therapeutic directionality for quantitative traits. Some proteins’ increased levels is protective while others increased level increases risk (i.e. HDL cholesterol and LDL cholesterol).

For Binary traits

We could potentially have two columns added: “Direction of effect” and “Therapeutic mode of action based on GWAS/QTL”. However we need to be cautious about inferring therapeutic directionality from GWAS/QTLs. Also QTL directionality can vary sometimes between tissues.

Scenario 5: OR>1 and β2 is positive: ↑ expression ↑ disease risk -> Inhibition is therapeutic

Scenario 6: OR<1 and β2 is negative:  ↓expression ↓ disease risk -> Inhibition is therapeutic

Scenario 7: OR>1 and β2 is negative: ↓ expression ↑ disease risk -> Stimulation is therapeutic

Scenario 8: OR<1 and β2 is positive: ↑ expression ↓ disease risk -> Stimulation is therapeutic

IMO, we should remain in the "direction of effect" concept and avoid the "therapeutic directionality" assessment.
Among other things, some traits like menopause or homosexuality might be problematic.

Q: Is the type of trait somehow encoded in EFO or would it be an inference based on the beta/OR values?

@MayaGhoussaini we should explore what's the uncertainty of the assessment. A few questions that would be good to investigate:

Do we believe all h4/h3 values for this assessment?
Do we want to include all effect sizes that marginally deviate from 1?
Should there be an intermediate case in which there is enough uncertainty on the data not to make the call?

I feel we could get these answers by comparing the assessments with other potentially cleaner sources of the direction of effect (e.g. drug data for binary traits or burden tests for quantitative traits)
@ireneisdoomed

Q: Is the type of trait somehow encoded in EFO or would it be an inference based on the beta/OR values?

To do it on the data, we need to start with the coloc dataset and join the left variant - left study beta.
> root
 |-- coloc_n_vars: integer (nullable = true)
 |-- coloc_h0: double (nullable = true)
 |-- coloc_h1: double (nullable = true)
 |-- coloc_h2: double (nullable = true)
 |-- coloc_h3: double (nullable = true)
 |-- coloc_h4: double (nullable = true)
 |-- left_type: string (nullable = true)
 |-- left_study: string (nullable = true)
 |-- left_chrom: string (nullable = true)
 |-- left_pos: integer (nullable = true)
 |-- left_ref: string (nullable = true)
 |-- left_alt: string (nullable = true)
 |-- right_type: string (nullable = true)
 |-- right_study: string (nullable = true)
 |-- right_bio_feature: string (nullable = true)
 |-- right_phenotype: string (nullable = true)
 |-- right_chrom: string (nullable = true)
 |-- right_pos: integer (nullable = true)
 |-- right_ref: string (nullable = true)
 |-- right_alt: string (nullable = true)
 |-- coloc_h4_h3: double (nullable = true)
 |-- coloc_log2_h4_h3: double (nullable = true)
 |-- is_flipped: boolean (nullable = true)
 |-- right_gene_id: string (nullable = true)
 |-- left_var_right_study_beta: double (nullable = true)
 |-- left_var_right_study_se: double (nullable = true)
 |-- left_var_right_study_pval: double (nullable = true)
 |-- left_var_right_isCC: boolean (nullable = true)

There is an alternative, do it in the front-end, but it might be a bit messy.

That is a good point David.  Yes agree. We should stick to the first column for everything. I was anyway not very comfortable with the second column. Below are answers to your questions:
Do we believe all h4/h3 values for this assessment?
I think these are separate things. We are not inferring directionality from the coloc and it is testing a different hypothesis (i.e. whether the trait and the QTL are likely to share the same causal variant. I think as long as we have a GWAS-significant hit and a significant QTL p-value then we can infer this column. We should add a tool tip to say that this is inferred from QTL beta and trait beta/OR.
Do we want to include all effect sizes that marginally deviate from 1? We could include any hit that is GWAS significant and use the OR> or <1 to infer allele/risk direction.
Should there be an intermediate case in which there is enough uncertainty on the data not to make the call? well I guess if the eQTL is not significant then you cannot infer a direction. I think we display in the portal only significant eQTL/pQTL, isn't it?

This has been now implemented in the genetics portal evidence that features in Platform #2831 #2840. It will be available on 23.02


do we should provide logback.xml file into "main" folder for this artifact

https://github.com/rhiot/rhiot/blob/master/cloudplatform/paas/adapters/src/main/resources/logback.xml
@hekonsek  for testing/ test folder only isn't it ?

It should be here, as this is fat jar project. It is supposed to be run as an executable. So we need logger config for it included in a final artifact.


Allow to set distinct text_color per screen

Seeing show_time as new parameter for add_screen service starting from 2023.4.0, has reminded of an issue/limitation that might be solved in a similar way.
Allowing a text_color to be set differently for each screen, rather than using the last set text_color for each active screen. The text_color as of today could be used as a global screen default, optionally changeable per screen and valid for that screen only.
Right now if I have an active screen with a color and I start a new simultaneous screen with a different color, text for both screens will be displayed using the new color.
Would this be something possibly/easily implementable?
Thanks in advance for all the great work you've been doing in this custom component.

Hi it's not well tested but in the 2023.4.0 there is a set_screen_color("iconname",rig,b) service but yet no action. I will work on it at weekend

Hi it's not well tested but in the 2023.4.0 there is a set_screen_color("iconname",rig,b) service but yet no action. I will work on it at weekend

OK, that would allow me to call the new set_screen_color rather than the existing set_text_color. Good luck and once again thanks for the great work.

the  optional set_screen_color is only for the actual screen for the specified icon. the set_text_color sets the default color!

the optional set_screen_color is only for the actual screen for the specified icon. the set_text_color sets the default color!

Just installed brand new 2023.4.0 and new service set_screen_color doesn't seem to have an effect on the screen text color.
I called the service with the following data:
  data:
    icon_name: ha_logo
    r: 107
    g: 174
    b: 93

and I saw the following in esphome debug log:
[00:24:58][D][EHMTX:135]: icon: ha_logo found id: 0
[00:24:58][D][EHMTX:041]: set screen color: icon 0 r: 107 g: 174 b: 93
[00:24:58][D][EHMTX:135]: icon: ha_logo found id: 0
[00:24:58][D][EHMTX:016]: findfreeslot for icon: 0
[00:24:58][D][EHMTX:136]: display length text: Hello!!! pixels 29 calculated: 10 show_time: 10 default: 10
[00:24:58][D][EHMTX:401]: add_screen icon: 0 iconname: ha_logo text: Hello!!! lifetime: 1 screen_time: 10 alarm: 0
[00:25:04][D][EHMTX:289]: next action: show screen "ha_logo" for 10 sec

but the text color shown on the matrix is all white...
Any ideas?
Thanks in advance.

So it's best to set the screen color in your automation after every add_screen.

I was setting the color before adding the screen, so it was always picking up the default color (as the screen was not yet in the queue). All working perfectly after changing the order of the service calls in my HA script.
Don't know what you think, but maybe it's worth mentioning this detail in the documentation.


How do you keep yourself from getting frustrated? Also, how do professionals like yourself keep calm in scenarios like these?

I do get frustrated. And I do lose calm. It happens less when you're working at the right place. Also meditation and Yoga helps.


How to limit children count to a fixed Integer (5 for ex:)?

The only way that can be done is to use fixed keys for the children, and only allow those keys.
key() >='0' && key() <= '4'


Module3 wording edits

This change is

Review status: 0 of 1 files reviewed at latest revision, 4 unresolved discussions.

3-1.html, line 223 [r1] (raw file):

Information about how to run each container, such as the container image version or specific ports to use

A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your NodeJS app as well as a different container that feeds the data to be published by the NodeJS webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

WDYT of replacing "different" with "supporting"?

3-1.html, line 225 [r1] (raw file):

A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your NodeJS app as well as a different container that feeds the data to be published by the NodeJS webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

Pods are the atomic deployment unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is deployed, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are deployed on other available Nodes in the cluster.

nit: Is it confusing to use the word "deployment" here since it has a different meaning than "Deployment".  Same for "where it is deployed" => "where it is scheduled"?

3-1.html, line 262 [r1] (raw file):

Nodes

Node

3-1.html, line 267 [r1] (raw file):

Kubelet, a process responsible for communication between the Kubernetes Master and the Nodes; it manages the Pods and the containers running on a machine.

A container runtime (like Docker, rkt) responsible for pulling all of your containers from a registry.

FYI the container runtime also runs the containers in addition to pulling the images.  We should also probably be clear on the difference between the container image (binary packaging of files) and the running container (the unpacked files + running processes and machine resources).

Comments from Reviewable

3-1.html, line 223 [r1] (raw file):
Previously, pwittrock (Phillip Wittrock) wrote…
> WDYT of replacing "different" with "supporting"?

I see what you're getting at, but "supporting" is a little ambiguous (and the statement "that are relatively tightly coupled" expresses that idea. The point I was getting is that it isn't entirely clear that all the containers in a Pod aren't just copies of the same container; they're different containers with reason to be logically grouped.

Comments from Reviewable

3-1.html, line 225 [r1] (raw file):
Previously, pwittrock (Phillip Wittrock) wrote…
> nit: Is it confusing to use the word "deployment" here since it has a different meaning than "Deployment".  Same for "where it is deployed" => "where it is scheduled"?

Done.

Comments from Reviewable

3-1.html, line 262 [r1] (raw file):
Previously, pwittrock (Phillip Wittrock) wrote…
> > Nodes
>
> Node

Done.

Comments from Reviewable

3-1.html, line 267 [r1] (raw file):
Previously, pwittrock (Phillip Wittrock) wrote…
> FYI the container runtime also runs the containers in addition to pulling the images.  We should also probably be clear on the difference between the container image (binary packaging of files) and the running container (the unpacked files + running processes and machine resources).

Done.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Fix for #204

This fixes #204.
The culprit turned out to be the IL generated by Roslyn for comparing references to null. In the old compiler, o => o != null results in
    ldarg.0
    ldnull
    ceq
    ldc.i4.0
    ceq
    ret

which literally translates to (o == null) == 0.
In Roslyn, the same code results in
    ldarg.1
    ldnull
    cgt.un
    ret

which literally translates to o > null. While this is a clever trick and produces shorter IL, it doesn't match implicit non-null assumptions generated by the static checker and thus results in unproven assertions.
The fix is to recognize the cases when cgt.un is used to compare to null and make them look like o != null to the static checker.

:question: What does o => null != o generate?

:question: What does o => null != o generate?

It still produces cgt.un, with or without optimization.

It still produces  cgt.un, with or without optimization.

And the null is still on the right?

And the null is still on the right?

Yes. It is the same exact sequence:
    ldarg.1
    ldnull
    cgt.un
    ret

Yes. It is the same exact sequence:

I checked the specification and it calls out cgt.un specifically as a cne-equivalent for null checking. Based on this it doesn't look like you need any other special cases in code.

The following comes to mind.

Since there is no cne instruction, ECMA-335 §III.1.5 makes a note that cgt.un may be used instead for the specific case where the right-hand-side is null. For all integer inputs to the cgt.un instruction, if the right side is null or zero, we treat the instruction as a "not equal" instruction for improved results from the static checker.

This is a stronger statement than what's implemented. The code only deals with nulls on the right hand side, but not with integer zero. So, how about this:

Since there is no cne instruction, ECMA-335 §III.1.5 makes a note that cgt.un may be used instead for the specific case where the right-hand-side is null. If the right side is null, we treat the instruction as a "not equal" instruction for improved results from the static checker.

:+1:

Oh, that explains some of the more subtle behaviours I saw when trying to compile the bug report. Nice work!

Awesome job, guys! Merged.


Look into use unpkg for CDN use of web-sdk

We should probably add a CDN option at some point. For example, you can probably already use the SDK via unpkg. Just confirm this and add it to the web-sdk readme.

unpkg seems to be a CDN just for npm packages. Isn't the npm registry behind a CDN anyways?


Illegal instruction (core dumped) when trying to start

Describe the Bug
When running docker-compose up the container fails and exits with code 132. The last message in the logs being Illegal instruction (core dumped). My system's memory is a bit low, but still above what seems to be expected for Update 8 and I'm watching memory usage with htop and it never gets over even 1G.
Your Runtime Command or Docker Compose File
version: '3'
services:
    satisfactory-server:
        container_name: 'satisfactory-server'
        hostname: 'satisfactory-server'
        image: 'wolveix/satisfactory-server:latest'
        ports:
            - '7777:7777/udp'
            - '15000:15000/udp'
            - '15777:15777/udp'
        volumes:
            - '/home/jason/docker/satisfactory/config:/config'
        environment:
            - MAXPLAYERS=8
            - PGID=1000
            - PUID=1000
            - STEAMBETA=false
        restart: no
        deploy:
          resources:
            limits:
              memory: 6G
            reservations:
              memory: 4G

System Specs (please complete the following information):
===== START ISSUE REPORT =====
OS:  Linux jason-ubuntu-server 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
CPU: AMD Phenom(tm) II X4 965 Processor
RAM: 7GB/7GB
HDD: 14GB/456GB (4% used)
===== END ISSUE REPORT =====

Additional Context
It's an old system that I only recently put back together with a fresh install of Ubuntu Server, so there shouldn't be anything else interfering, but the hardware is pretty dated. Still, I think it should all meet the minimum system requirements as of Update 8.
Thanks for any assistance!

Oh! I meant to share my container's logs:
startup.log

Hey @jdbecker. I'm not sure specifically what's triggering the error (seemingly resource/spec/OS-related), but I can tell you for a fact that your CPU will not be sufficient to run the server. Satisfactory is very demanding, and requires very good single core performance. This is why in the wiki they recommend a minimum of a Ryzen 3600, which has 10x the overall CPU passmark compared to yours

Ah shoot, I missed that. That's a big bummer. Well, thanks for the help!


How to create training datasets

Hi, Yufeng, I am wondering how to create my own datasets through cameras: 1) the image size is 512x512, 2) what is the camera speed or fps? 3) is there any special requirement like the face should be in the middle of images? or the background must be a single color? How about the lightness?
Best,
Mike

Okay, these are very helpful. Thank you!


Have to reconnect after a while

Plugin is working fine on my main desktop but on my main laptop, it keeps disconnecting.

Keeps losing connection for me too.

Happens all the time. After 30 min - 1 hour, I have to manually reconnect and give my consent regarding permision on the Galaxy 2.0 popup.

Just a quick reminder that this is still hapening. If any log is needed, I can provide it.

The latest version has a fix for storing cookies. Please check if it resolves the problem.
https://github.com/FriendsOfGalaxy/galaxy-integration-battlenet/releases/tag/v0.37

Same here, and after several attempts to reconnect plugin goes completely offline (0.37 too). From the log:
2019-08-26 23:23:54,493 - root - INFO - Handling request: id=16, method=pass_login_credentials, params={'cookies': '****', 'credentials': '****', 'step': ''} 2019-08-26 23:23:56,362 - root - DEBUG - Sending data: {"jsonrpc": "2.0", "id": "16", "error": {"code": 101, "message": "Network error"}}
Blizzard's app authenticates just fine on same PC at the same time. And in browser too. So it all looks like a shadow ban on BNet server side. May be, by User Agent, or something.

Haven't tried on my laptop but on the desktop it works quite fine. The "install" has been replaced by "launch" for Overwatch even.

@PastorGL  looks like we think your are offline ("Network error"). It is translated from requests ConnectionError which is raised in few cases in this line and few next: https://github.com/psf/requests/blob/67a7b2e8336951d527e223429672354989384197/requests/adapters.py#L453
It is probably too broad for our needs, as Galaxy switches to offline mode. And it may be potentially raised on ClosedPoolError: https://github.com/urllib3/urllib3/issues/951
More investigation is needed.
In case if it repeats please, make another issue.
@BuryTomorrow12 I know most probable source of problem, but please send us your logs after it happens, just to be sure. Thanks!

Can you check against latest v0.38?

Checked 0.38. Auth seems working and plugin doesn't go offline anymore 👍

Seems to be working fine with 0.38 👍


not fully Crockford's Base32 compatible.

From the Crockford's Base32 spec:

When decoding, upper and lower case letters are accepted, and i and l will be treated as 1 and o will be treated as 0.
(...)
Hyphens (-) can be inserted into symbol strings. This can partition a string into manageable pieces, improving reabability by helping to prevent confusion. Hyphens are ignored during decoding. An application may look for hyphens to assure symbol string correctness.

I can send a PR to fix it.
Another thing:
Not sure how the Check Symble works and if it could affect ulidx. Any idea?

Hi @bluet - While ULIDs make use of Crockford's Base32 spec, it adheres to the ULID spec first and foremost. In the interest of keeping my fork in like with:

The spec here
Other forks in other languages

I don't think I can support changes that would change how the validity of a ULID is determined. It's not correct imo to validate ULIDs by their Base32 likeness.. they're still ULIDs first.
I appreciate the work you put into this, and I'm sorry that I wasn't able to move this forward. Thanks.

Hi @perry-mitchell , thanks for the reply.
As the spec indicates it's Crockford's Base32, the missing part in the original javascript implementation of the compatibility with UILD and Crockford's Base32 has been well discussed.
As ulidx was originally forked to extend it's life, keep everything up-to-date and complete it, I thought it's about time to fill the missing part.
But you're the boss and I respect whatever your choice is. Hahaha
Despite that, adding additional standalone functions for users if they want to fix the ID string from user input (ex, me), doesn't hurt the compatibility with other languages implementations, isn't it?  As long as we don't make it the default behavior.
Just my two cents.

@bluet I've had a think about this and I've changed my mind - I do agree with you. I completely missed that this was all intended as a complimentary set of functions.
I'd accept this PR if you'd be willing to make a couple of changes:

Combine all the functionality into a single method. I don't see the value in having them separately as fixUlid does as it says - fixes a ULID in terms of this base32 correctness.
Rename said function to something like fixULIDBase32 so it's clear that it's not just base ULID functionality.

Would you be interested in doing this?

So nice to hear that ☺ you win my respect again. I'll work on that soon.

@perry-mitchell Thanks for the merge. Any chance to see 0.5.0 release on npm soon? :D

I will be doing so today 😊

Released under 0.5.0. Thanks @bluet for the work on this, as well as the clear explanations.

Thanks! Glad I can help! 😸


Remove or relax Rust toolchain constraints

From this discussion

Although honestly we can just remove the rust-toolchain.toml file from this repo instead. That's the crux of the issue here as it's defaulting for rustup to install/use 1.70 but that's not needed in most cases.

As an immediate work-around; the rust-toolchain.toml file is pretty close to the bottom of the pecking order of version considerations, so you can get a working version even on AArch64 with cargo +1.72.0 build or the like, or make it persistent by running rustup override set 1.72.0 in the repo root, etc.
But yeah, it's not an ideal situation with aHash being in the situation it is right now.

It makes sense to me that we should have the MSRV verified programmatically, right? And also human readable. Is there a way to do this other than rust-toolchain ?
Also, I'll repeat what I wrote here https://github.com/Qiskit/openqasm3_parser/pull/26#issuecomment-1890364683 . It may be that dropping the required version of hashbrown in openqasm3_parser is enough to obviate this problem. I  didn't try it because I don't have the aarch64 platform.

On Qiskit we hard-pin aHash to 0.8.6 (in the lockfile) to prevent the problematic 0.8.7 version from coming in, but on Qiskit we're not building a reusable Rust library, so it's not really a problem that we have exactly pinned dependencies.  It's not so great here, because we'd have to specify it as a core pin in the Cargo.toml rather than in the lockfile, but it's potentially passable.
I agree it's a good idea to have the MSRV verified in CI, but that doesn't necessarily need to be done with a rust-toolchain.toml file—we can use one of the other override methods in the CI test job—and we don't necessarily need to have the same MSRV for all different platforms, though it's pretty annoyingly that aHash bumped up so high even though it's only for AArch64.
We have a rust-toolchain.toml file on Qiskit mostly as a convenience to non-Rust developers; it forces their rustup to push them up to the MSRV, so as long as they've got that installed, they don't need to know anything about Rust at all.  The same argument applies a little less here, where it's a pure Rust library, perhaps.

I just read this about rust-toolchain. I had misunderstood it as a sort of specification of a MSRV. But no, it's meant to pin the version of rust.
I agree that pinning the compiler version does not make sense in a library like this. Someone building the library should be able to use a higher version of rustc to work around a problem with dependencies. This kind of problem is very common in compiled libraries.
I support the idea of removing rust-toolchain.


Migration to androidx libs

Hi, this is the change for the new androidx libs that replace the old Support libs.
Artifacts within the androidx namespace comprise the Android Jetpack libraries. Like the Support Library, libraries in theandroidx namespace ship separately from the Android platform and provide backward compatibility across Android releases.
AndroidX is a major improvement to the original Android Support Library, which is no longer maintained. androidx packages fully replace the Support Library by providing feature parity and new libraries.
Check info: https://developer.android.com/jetpack/androidx

I think we're actually going to take the approach for dropping support for API 19 and therefore just removing the RequiresApi statement altogether. I've created a draft PR for this when cordova-android 9 is released. https://github.com/ionic-team/cordova-plugin-ionic-webview/pull/540


Allow users to share with other users privately

As an alternative to full group support, another useful path to improved access control would be to allow a user to share with another user privately.
The lightweight version of this would allow user1 to give user2 read-only access.
This would be valuable for collective projects (like SD2) because it would allow tight control of who can write to a particular collection (giving authority to originators and limiting potential damage from accidents), but still allow sharing within a group of users.

closing this as sharing already has its own issue


Batch add for Experience Replay (#682)

Description
The patch adds an extend function to ReplayBuffer and PrioritizedReplayBuffer that imitates      the behavior of list.extend, i.e. it enables adding batches of experiences (State, Action, Reward, State, Done).
Motivation and Context

[x] I have raised an issue to propose this change (required for new features and bug fixes)

Implements #682
The goal was to reduce clutter code when using Batch Environments. The current behavior results in the following code when using batchenvs:
env = BatchEnv()
obs = env.reset()
done = False
buffer = ReplayBuffer(128)
while not done:
    action = agent(obs)
    newobs, r, d, _ = env.step(action)
    for i in range(num_envs):
        buffer.add(obs[i], action[i], reward[i], newobs[i], done[i])
    obs = newobs

With the patch:
env = BatchEnv()
obs = env.reset()
done = False
buffer = ReplayBuffer(128)
while not done:
    action = agent(obs)
    newobs, r, d, _ = env.step(action)
    buffer.extend(obs, action, reward, newobs, done)
    obs = newobs

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (update in the documentation)

Checklist:

[x] I've read the CONTRIBUTION guide (required)
[x] I have updated the changelog accordingly (required).
[ ] My change requires a change to the documentation.
[x] I have updated the tests accordingly (required for a bug fix or a new feature).
[ ] I have updated the documentation accordingly.
[x] I have ensured pytest and pytype both pass (by running  make pytest and make type).

Note:
These two failed on my macbook.
tests/test_0deterministic.py::test_deterministic_training_common[SAC] FAILED
tests/test_0deterministic.py::test_deterministic_training_common[TD3] FAILED
and make type gives:
pytype
make: pytype: No such file or directory
make: *** [type] Error 1

Overall looks good, just few minor nitpicks. Thanks for the nice work! 👍
I'll allow code quality review as those private variables are read for testing purposes.

Thank you for reviewing the changes!


Add govuk_editor permission to all Publisher users

This adds a task which when run adds the govuk_editor permission to all users who currently have access to the Publisher application. This is a necessary step towards adding a new permission later which will only give permission to edit Welsh content in Publisher.
Publisher will be updated to recognise the govuk_editor permission as granting the ability to perform every action on an edition. The upcoming welsh_editor permission will only grant access to editing Welsh language editions.
Once run the task can be deleted.
Trello Card

It does strike me as odd that we create these throwaway rake tasks, rather than say a Rails ActiveRecord migration which would preserve the code as well as mitigate the need to raise a second PR to remove the code afterwards. But I remember reading somewhere our preference for only using migrations if there is a structural change, and not for 'data changes'. Can't find that doc at the moment though 🤔 if there is any other reason we write these as rake tasks, let me know!

I generally follow https://thoughtbot.com/blog/data-migrations-in-rails as guidance on whether to use migrations or Rake tasks. I think you're right that in GOV.UK we try to avoid using migrations for this sort of thing, and I'm sure I've read that somewhere too, but I can't think where that would be...

I generally follow https://thoughtbot.com/blog/data-migrations-in-rails as guidance on whether to use migrations or Rake tasks. I think you're right that in GOV.UK we try to avoid using migrations for this sort of thing, and I'm sure I've read that somewhere too, but I can't think where that would be...

That article explains it - thanks! Agreed rake tasks are the right approach for this 👍


remove install instructions; get rid of cmake warning

The current install instruction doesn't quite work (includes not installed).
It is also problematic when used as part of pelikan- we want make install to just install the server binaries, but currently it will try to install the library as well.
So we are removing the install instructions for now and investigate later.
Also setting a variable for RPATH on OSX to rid warning.

Created https://github.com/twitter/ccommon/issues/125 to follow up on install configuration.

🚢


Update Readme with correct usage & Basic Typescript

I had trouble understanding the readme, and additionailly I noticed some of the examples are different from src/examples/App.vue, so I updated the example.
I also got it working with typescript, so I added brief instructions for how to do that.

我知道了，是 vue3 proxy 的问题，不要用 vue 变量作为编辑器实例就可以了


ESM

Update project to TypeScript
Added build scripts to target ESNext

Oof, the require syntax only appears to be working in my-react-crasher because of some sort of translation that's happening under the hood.

Most stuff seems to be working now, only sucky part left as far as I know is in my-ts-react-crasher you have to use `import { BugSplat } from 'bugsplat/esm';

Fixed!


fix: String of only whitespaces considered as name

Impacted Files

packages/smooth_app/lib/pages/product_list_user_dialog_helper.dart

What

The input form for adding a new list was allowing names with only whitespaces.
Input string will remove leading and trailing spaces in the list item name and then adds to the list if it's validated
Event though if there is leading or trailing spaces will be there  it will be removed before adding to the list !

Screenshot

whitespaceTrim.webm
Fixes bug(s)

Fixes: #3574

Part of

#525

Thanks @M123-dev <3


Multi loss

WIP, providing two additional loss functions. Custom is a WIP but there is a built in cross entropy one in pytorch

consolidated into this PR


Allow persistent right prompt

I like having say a clock (to see how long commands execute for) and exit status in my right prompt.
Also, would it be possibly to implement a way for the rprompt to be updated before a command is executed?

Reasonable. Perhaps controlling this behavior through a boolean variable $le:persistent-rprompt will make sense?

Yeah, that sounds like a good idea.


[DM-30904] Update TAP application for 0.2.0 chart

Depend on 0.2.0 and remove the now-unnecessary override of the
address of the TAP schema database.

The first CI run will fail because the chart isn't published yet. Will retry.


dry-run: UPDATER_OPTIONS

This accepts a comma separated list representing the keys in the options hash passed to FileUpdaters.
It's good enough while that's a bitmap, but won't play nicely if options accept values.
We can use this to toggle all the cool features masked behind options in the updater, without needing to turn each into a command line flag.
Maybe we should still accept the list via option instead of yanking it from environment?
Related

Continues https://github.com/dependabot/dependabot-core/pull/2597
Formalized hack from testing https://github.com/dependabot/dependabot-core/pull/2596 + https://github.com/dependabot/dependabot-core/pull/2551

Looks promising, @thepwagner! Can you share a quick example usage and/or describe what steps we can take to verify that this is working as expected? :bow:

@jasonrudolph  thanks! I'm not set on this implementation at all, but I wanted to breadcrumb this as it was handy for testing.
As implemented, usage is: UPDATER_OPTIONS=go_mod_tidy,go_mod_vendor bin/dry-run.rb go_modules thepwagner/my-awesome-repo --clone
The alternative I considered as I was writing the PR description was using the existing OptionParser for something like:
bin/dry-run.rb go_modules thepwagner/my-awesome-repo --updater-opts=go_mod_tidy,go_mod_vendor --clone.
Semantics but it looks like the pattern is to only use ENV for secrets?
Toggling the go_mod_tidy against go_modules is probably the best way to verify: does go.sum contain the previous version? If not, you're tidying.

@jasonrudolph I talked myself into the options path since it provides better opportunity for discovery.
 bin/dry-run.rb go_modules thepwagner/my-awesome-repo --clone --updater-options=go_mod_tidy

I'm still hesitant to bake the available options into this script, but the help text hopefully leaves a breadcrumb that the ecosystem's file updater is what defines them.
We could add something like FileUpdater::Base.available_options = [] to do it, doable but a fair bit of creep.


HH_ManageHHAccount page does not pass url params to standard account page

Use Case
I am sending my user to edit a non-Household account and passing some extra URL parameters. (I am sending saveURL, specifically, but I can imagine sending any number of URL params.)
I would like NPSP to get out of my way since this has nothing to do with NPSP.  However, the account edit override (HH_ManageHHAccount.page) only passes retURL and RecordType to the nooverride edit page.
Instead, HH_ManageHHAccount.page should blindly pass all URL parameters sent by the user.
Steps to reproduce

Run the below Apex from a VF page (see below) or simply go to a URL like /001xxxxxxxxxxxx/e?retURL=%2F500xxxxxxxxxxxx&saveURL=%2F300xxxxxxxxxxxx%2Fe
On the first edit page press Save

Expected behavior
You are redirected to the saveURL (/300xxxxxxxxxxxx/e)
Actual behavior
Since saveURL is not passed to the "nooverride" account edit page, you are redirected to the retURL (/500xxxxxxxxxxxx).
Example Apex controller (not tested):
public class TestController {
  public TestController(ApexPages.StandardController stdController) {}

  public PageReference goToAccount() {
    Account acct = [SELECT Id FROM Account WHERE npe01__SYSTEM_AccountType__c != 'Household Account' LIMIT 1];
    Contact cnt = [SELECT Id FROM Contact LIMIT 1];
    String editUrl = new ApexPages.StandardController(acct).edit().getUrl();
    String saveUrl = new ApexPages.StandardController(cnt).edit().getUrl();
    String combined = editUrl + '?saveURL=' + EncodingUtil.urlEncode(saveUrl, 'UTF-8');
    return new PageReference(combined);
}

Example VF page (not tested):
<apex:page standardController="Case" extensions="TestController">
  <apex:outputLink value="{!goToAccount}">Go</apex:outputLink>
</apex:page>

Hi @ckoppelman - the Account Edit override you're talking about was long changed a separate 'Manage Household' button and we no longer recommend using any Account override. As such, I'll close this issue but of course, you are welcome to implement your own solution to meet your needs and use that instead of the code that is still provided for backwards compatibility.

oh wow!  that's good news.  thank you!  Can you send me to the documentation on how to make the upgrade?


There is no formatter for 'helm'-files installed.

This plugin can't format helm template files. Please defer to yaml formatter when it has extension yaml or yml, after rendering the final phase, and then you can put back the bracketed parts ;)

Thanks for raising this.  Could you clarify what you mean by the second sentence?  Is it a suggestion for how we could implement a fix, or is it expanding on the problem?  Sorry for not understanding!

This plugin is taking responsibility for formatting, since it's registered itself as the handler for helm template files. Now, since this plugin has no implementation for formatting of the resulting output, I suggest to defer formatting to the default formatters already installed by the user (*.yaml|json|etc). If they don't have formatters installed for the generated files, then your plugin should throw an error imo.

This is actually an issue with the Helm Chart Specification more-so than the plugin itself. A chart's templates has no defined for a given template file. The file extension doesn't actually signify that the file is written in YAML/JSON/what-have-you. In reality, the file extension of the templates SHOULD be of type .tpl, but the keyword there is SHOULD. The chart specification just defines that the content of the templates are undefined. Many users choose to use the extension to signify what the expected output of helm template should result in, but this is after the chart and all its values have been rendered. As a result, they cannot be formatted. :)
I don't think this is something the VSCode could (or should) try and solve. As mentioned before, the file's contents is undefined and the file extension doesn't really mean anything. Attempting to format a file with undefined structure would end in much pain and sorrow for the maintainer(s) attempting to write a formatter.

I think more to the point, until someone sits down and writes a yaml reader/writer that handles go templating inside.... well, until that point, we'll take a PR that does this! :-)

Fixed this by adding
    "files.associations": {
        "*.yaml*": "yaml"
    }

to the bottom of my vscode settings.json:
File > Preferences > Settings >> Text Editor > Files > Files: Associations

Fixed this by adding
    "files.associations": {
        "*.yaml": "yaml"
    }

to the bottom of my vscode settings.json: File > Preferences > Settings >> Text Editor > Files > Files: Associations

This didn't work for me :(

Fixed this by adding
    "files.associations": {
        "*.yaml": "yaml"
    }

to the bottom of my vscode settings.json: File > Preferences > Settings >> Text Editor > Files > Files: Associations

This solves the problem, but then you lose the benefits of this extension.


EAS cannot create builds with Firebase and RN 0.69.5

Build/Submit details page URL
https://expo.dev/accounts/yolpsoftware/projects/eas-firebase-test/builds/8729ce37-5e55-472c-8d11-8a20a6b9a143
Summary
Since Expo SDK 46, my Firebase project cannot be built anymore by EAS. Both on cloud and local (eas build --local) I get a CocoaPods error. Since this is a Managed project, I cannot change anything in the Podfile.
Managed or bare?
managed
Environment
expo-env-info 1.0.5 environment info:
System:
OS: macOS 12.6
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 8.19.1 - ~/.nvm/versions/node/v16.17.0/bin/npm
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 16.0, macOS 12.3, tvOS 16.0, watchOS 9.0
IDEs:
Xcode: 14.0/14A309 - /usr/bin/xcodebuild
npmPackages:
expo: ~46.0.9 => 46.0.10
react: 18.0.0 => 18.0.0
react-dom: 18.0.0 => 18.0.0
react-native: 0.69.5 => 0.69.5
react-native-web: ~0.18.7 => 0.18.9
npmGlobalPackages:
eas-cli: 2.1.0
Expo Workflow: managed
expo doctor
🎉 Didn't find any issues with the project!
Error output
[INSTALL_PODS] The Swift pod FirebaseCoreInternal depends upon GoogleUtilities, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set use_modular_headers! globally in your Podfile, or specify :modular_headers => true for particular dependencies.
[INSTALL_PODS]
Error: pod exited with non-zero code: 1
at ChildProcess.completionListener (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/spawn-async/build/spawnAsync.js:41:23)
at Object.onceWrapper (node:events:628:26)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1093:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)
...
at spawnAsync (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/spawn-async/build/spawnAsync.js:7:23)
at spawn (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/turtle-spawn/dist/index.js:17:47)
at installPods (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/build-tools/dist/ios/pod.js:12:38)
at /Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/build-tools/dist/builders/ios.js:69:41
at BuildContext.runBuildPhase (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/build-tools/dist/context.js:50:34)
at buildAsync (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/build-tools/dist/builders/ios.js:68:19)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Object.iosBuilder (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/@expo/build-tools/dist/builders/ios.js:24:33)
at async buildIosAsync (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/eas-cli-local-build-plugin/dist/ios.js:54:12)
at async buildAsync (/Users/jo/.npm/_npx/b6b81adc32d91f4e/node_modules/eas-cli-local-build-plugin/dist/build.js:42:32)
Reproducible demo or steps to reproduce from a blank project
https://github.com/yolpsoftware/eas-firebase-test
Check out the project, then run
eas build --platform ios --local

react-native-firebase is not a library maintained by expo and neither it's included in a managed workflow. With problems like that you should post on the library repo.
With that said, it looks like they updated their documentation (for regular rn projects and for expo)
https://github.com/invertase/react-native-firebase/blob/main/docs/index.md#altering-cocoapods-to-use-frameworks

I'm having the same issue after upgrading to Expo 46 (from 45), and I'm not using react-native-firebase in my project.
npm ls react-native-firebase
project/path
└── (empty)

I do use firebase and expo-firebase-analytics though.

@almirfilho Did you follow this part of instructions https://docs.expo.dev/versions/v46.0.0/sdk/firebase-analytics/#additional-configuration-for-ios ?

@almirfilho Same here. Did you find a solution?

Okey, this solves the problem: https://docs.expo.dev/versions/v46.0.0/sdk/firebase-analytics/#additional-configuration-for-ios


Importing package bundled by webpack as library with split chunks does not import chunks

Bug report

Importing package bundled by webpack as library with split chunks does not import chunks.
What is the current behavior?
Just before exaplaining the bug, I need to clarify the setup a bit:
(Description of the demo, which is based on my actual issue in a more complex setup.)
I have two packages a and b in a npm workspace.
a is a package that contains a small web application. b is a library, consumed by a.
b has two files, just an index.js file and a translation.json file. There is only a getTranslation function that is exported by the library. This function asynchrounously load translation.json file and return it.
When compiling b, two files are generated, main.mjs, and translation_json.mjs.
Now the current behavior:
In a, the b package can be successfully imported, both synchronously and asynchronously. However, when calling b.getTranslation, the translation_json.mjs is not found by the dev server. A build of a also does not output b's translation_json.mjs contents in any of its files.
If the current behavior is a bug, please provide the steps to reproduce.
Clone the following repo:
https://github.com/pedro00dk/webpack-library-split-chunks
Then:
$ # inside repo root directory
$ npm install
...

$ cd ./a/
$ npm run start # it will build 'b' automatically

Now go to http://localhost:5000 and click the button with text: click to load "b" translation file

What is the expected behavior?

When building a, the translation_json.mjs fromb should be included in the bundle somehow, and accessible when running the dev server.
Other relevant information:
webpack version:  5.88.0 (cli: 5.1.4)
Node.js version: 20.2.0
Operating System: Ubuntu 23.04
Additional tools: None

Just adding some more details I found out. I'm using experimental modules and library type "module". I still have the same issue when usingoutput.library.type = "commonjs". But I think I found another bug, with commonjs I get ReferenceError: exports is not defined. I have to add a window.exports = {} and get the exported values from it instead of the import(...) return. (This also happens with commonjs2, I have to initialize window.module = {exports:{}} to get imports working)
Same demo, go to commonjs branch.
https://github.com/pedro00dk/webpack-library-split-chunks


Docker issue

related PR #46
related issue #42 #29

i'll make a account related api patch real quick


gpm: fix static build

Patch I developed to add support for static build into upstream build system do
not apply cleanly on 1.20.7 release, so instead of backporting it, I decided to
switch to git snapshot instead.  It allowed to get rid of three other patches
in nix expression, since they are applied upstream.
=> https://github.com/telmich/gpm/pull/42
I requested proper release, but chance seems to be slim.
=> https://github.com/telmich/gpm/issues/33

Motivation for this change
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

I am okay with addition of withNcurses parameter, but wouldn't it be better to have it in separate pr?

@SuperSandro2000 ?


Adding {CssBaseline.flush()} in _document.js makes styles dissapear

Describe the bug
This is my _document.js.
import React from "react";
import Document, { Html, Head, Main, NextScript } from "next/document";
import { CssBaseline } from "@nextui-org/react";

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx);
    return {
      ...initialProps,
      styles: React.Children.toArray([initialProps.styles]),
    };
  }

  render() {
    return (
      <Html lang="en">
        <Head>{CssBaseline.flush()}</Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

export default MyDocument;

It seems that it removes all the styling from all NextUI components. Removing the {CssBaseline.flush()} in the <Head/> tag solves it but im not sure what are the consequences.
How should I go about this ?
Thanks!
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
1 .follow the getting started docs
2. render any NextUI component
Expected behavior
In the official 'Getting started' it is stated to add this function. Adding it removes all the CSS. I expect that not to happen.
Screenshots or Videos
No response
Operating System Version
Windows 10
Browser
Chrome
EDIT: it seems like there are conflicts with tailwind css.

Ye I just installed nextui I wanted to use it in t3 stack, but the styles are not working, the button that i tried to showcase in the browser is there, but without any styles expect for the ripple-like effect after clicking, so i will have to wait untill it wont be fixed cause i have the same problem ;p

@getlaurekt  Seems like there's a clash with @tailwind base. Just add
corePlugins: {     preflight: false,  }
to your tailwind config.

corePlugins: { preflight: false, }
to your tailwind config.

Where exactly?
After @tailwind base; or inside
@layer base {
  corePlugins: { preflight: false, }
}

@elhe26 here , in your tailwind.config.js module.exports = {   content: [   ....   ],   theme: {     extend: {       ...     },   },   plugins: [],   corePlugins: { preflight: false, } }


Recognize wikilinks

It would be great if this plugin could render the contents of the csv in a way so that Obsidian could recognize (and allow clicking) the wikilinks in it. Having a wikilink in a row anywhere but the last column will not render that row at all. Having it in the last column will show it as plain text.

This is a duplicate of #2


feat: add hero live

✍ Description
(required) Please include any relevant details about this Pull Request, with a focus on:

What does it fix.
Why did you do things this way.
How does it fix the issue at hand.

Please don't be shy and add as much context as you think necessary.
✅ Fixes
(optional)

Closes #(issue)
Fixes #(issue)

✅ QA
Before requesting a review, please make sure that:

[ ] Preview is working on Netlify, Heroku or similar.
[ ] Manually check that it's working.
[ ] Add documentation and tests if needed.

📸 Screenshots
(optional) Please post any relevant screenshots that might help understanding the scope of this functionality.
🔗 Relevant URLs
(optional)

https://example.com/feature/1
https://example.com/feature/2

📕Extra Documentation
(optional)
Please include links to any external documentation such as requirements, manuals, etc.

@glebapps
I just checked in mobile, maybe is just a WIP and you already noticed.
But I left some notes here


Adding BrowserAnimationsModule and NoopAnimationsModule causes webpack HMR to duplicate the app element on update

Using exactly the same code as in the angular-animations-example branch, any changes to the app that invokes the webpack hot module replacement results in the previous app element being left behind underneath the newlay added app element. A browser refresh is necessary to get rid of it and test as normal.
This seems to be provoked merely by importing the two AnimationsModules into the browser and server app modules.
Here's my demo of the problem.
https://github.com/JimLynn/AngularCoreWithAnimation/commit/356be71025fff5329265c3aff58c377ec1c9bc89

Thanks for reporting this.
Closing as duplicate of https://github.com/aspnet/JavaScriptServices/issues/1231, as I am certain that fixing that issue will also resolve this one.


FLCN-138

Updated styling to match bc gov

Just a drive-by here, we should be using padding/margin etc for bootstrap classes instead of hardcoding those values in to custom classes.

Closed because most of this has been addressed in other PRs since this was opened. Also some styling choices made here have been moved away from.


Import Adobe Commerce Code into a Cloud project > Import Adobe Commerce database link is 404

Issue in ./help/how-to/general/sync-data-and-files-from-production-to-staging-or-staging-to-integration.md
https://experienceleague.adobe.com/de/docs/commerce-cloud-service/user-guide/develop/deploy/staging-production lands on 404

Hi @denysbabenkodivae!
We'll take a look what's happening with the German translation of that page.
Meanwhile, if you understand English, or use a translator on the page, the English version of that page is up and accessible here:
https://experienceleague.adobe.com/en/docs/commerce-cloud-service/user-guide/develop/deploy/staging-production

Hi @denysbabenkodivae!
This article on the link you provided now loads.
Thanks for reaching out!