Set Preprocessor Macros

Hi,
is there currently a way to set C Preprocessor macros or to entirely ignore them?
The motivation is, that I want to analyze larger projects and some use macros i.e.:
#ifdef FEATURE_XY_ENABLED
 [... stuff ...]
#end if

The result is of course an empty AST :(
Thanks in advance

Yes, using the symbols parameter of https://github.com/Fraunhofer-AISEC/cpg/blob/ba1ecaa8397e993e44aa75f26486870b1a68cdbe/cpg-library/src/main/java/de/fraunhofer/aisec/cpg/TranslationConfiguration.java#L115


iphone 5

how to change iOS

changing iOS

Hi @vinny12343. I can see how you got confused as the project starts with 'ios' in iosched. This is an Android app and as far as I'm aware, you can't run an Android app on iOS.
There is, however an iOS app which you can download is here: https://itunes.apple.com/us/app/google-i-o/id1109898820?mt=8 and the source code is here: https://github.com/google/iosched-ios. Hope this helps.

Sorry but @vinny12343 dont even know his own email, I'm not related with
his problem and this is not his email.
Thanks and I hope you will find him.
On Mon, 18 Jun 2018, 12:02 Timothy Kist<EMAIL_ADDRESS>wrote:

Hi @vinny12343 https://github.com/vinny12343. I can see how you got
confused as the project starts with 'ios' in iosched. This is an
Android app and as far as I'm aware, you can't run an Android app on iOS.
There is, however an iOS app which you can download is here:
https://itunes.apple.com/us/app/google-i-o/id1109898820?mt=8 and the
source code is here: https://github.com/google/iosched-ios. Hope this
helps.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/iosched/issues/263#issuecomment-398004651, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALns2p5e3KZr8hNnALU137aUHlcLsXLaks5t93rQgaJpZM4Ul76F
.

@AlbertJQarK just got back from support. It's not that the OP has your email, not at all. You're watching this repository so you get all the issues and pull requests etc.
If you don't want all this, then please change your preferences or contact<EMAIL_ADDRESS>for more help. Hope this helps!


Increase Security to reduce sign on attempts.

Hi - with regard to this one are these general wordpress notifications? Ok for me to assign myself using an email to keep watch? I will get these through Sucuri also but its best to have both.

These notifications are coming from the Limit Login Attempts Plugin.

HI ok it is best we move this over to Wordfence to monitor as this will also throttle the requests from spam - if ok I will change this around
Kelly   Lloyd
DUCK SOUP DIGITAL
Web Management | Development | Marketing | Managed Hosting
@.***
DUCKSOUPDIGITAL.CO.UK
From: Heldy @.>
Reply: ASRG/asrg.io @.>
Date: 24 November 2021 at 13:24:26
To: ASRG/asrg.io @.>
Cc: KellyDSD @.>, Assign @.***>
Subject:  Re: [ASRG/asrg.io] Increase Security to reduce sign on attempts. (Issue #384)
These notifications are coming from the Limit Login Attempts Plugin.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

@KellyDSD Please go ahead with the changes.  Actually, are there any charges?

Hi - do you mean to change over to Wordfence? No the free version for now should cover? Or do you mean implantation time?
Kelly   Lloyd
DUCK SOUP DIGITAL
Web Management | Development | Marketing | Managed Hosting
@.***
DUCKSOUPDIGITAL.CO.UK
From: Heldy @.>
Reply: ASRG/asrg.io @.>
Date: 24 November 2021 at 15:22:00
To: ASRG/asrg.io @.>
Cc: KellyDSD @.>, Mention @.***>
Subject:  Re: [ASRG/asrg.io] Increase Security to reduce sign on attempts. (Issue #384)
@KellyDSD Please go ahead with the changes. Actually, are there any charges?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

I meant software license costs.  If we can work with the free version, please go ahead and integrate.


Access request for Willsparker, various machines

Access level:

[x] root/Administrative

System for which access is needed:
build-linaro-centos76-armv8-2
test-macstadium-macos11-arm64-1
test-macstadium-macos11-arm64-2

Please explain why you need this access including whether it is a temporary or permanent request:
To run the Nagios_* ansible roles, to enable Nagios monitoring, see https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/1716#issuecomment-762209817 . Ping @gdams for the macOS machines. Permanent request :-)

There are a couple of linaro machiens available but I haven't decided how to fully set them up yet or what they'll be used for as I'm doing initial tests on it so I'd leave them out of Nagois until they're ready if possible.

There are a couple of linaro machiens available but I haven't decided how to fully set them up yet or what they'll be used for as I'm doing initial tests on it so I'd leave them out of Nagois until they're ready if possible.

test-macstadium-macos11-arm64-1 is currently offline
I can grant you access to -2 for now though, but be careful with it as it's not a production-quality machines being macos/aarch64

test-macstadium-macos11-arm64-1 is currently offline
I can grant you access to -2 for now though, but be careful with it as it's not a production-quality machines being macos/aarch64

Hmm .. Okay, I'll update that info into my Nagios issue. Thanks

Hmm .. Okay, I'll update that info into my Nagios issue. Thanks

I don't think I have access to test-macstadium-macos11-arm64-2 , unless the IP address isn't what it says in the Inventory.yml
will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

I don't think I have access to test-macstadium-macos11-arm64-2 , unless the IP address isn't what it says in the Inventory.yml
will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

will@will-XPS-13-9360:~$ ssh<EMAIL_ADDRESS>Password:

Fixed - bastillion wasn't set up properly for that machine so my change got overriden

Fixed - bastillion wasn't set up properly for that machine so my change got overriden


chore: release 0.3.1

:robot: I have created a release *beep* *boop*
0.3.1 (2021-06-03)
Bug Fixes

don't display version alert when unable to retrieve version from bee node (#138) (5ace762)
typeerror in the postage stamps form (#137) (465df17)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ethersphere/bee-dashboard/releases/tag/v0.3.1 :sunflower:


debugbar logging requests using microtime

Feature request from the forum: https://forum.codeigniter.com/thread-81113.html
Each pull request should address a single issue and have a meaningful title.
Description
Explain what you have changed, and why.
Checklist:

[x] Securely signed commits
[x] Component(s) with PHPDoc blocks, only if necessary or adds value
[x] Unit testing, with >80% coverage
[x] User guide updated
[x] Conforms to style guide

@maniaba Thank you for sending the PR.
You forgot GPG signing.
See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/signing.md
It ssems there are coding style violations and Static Analysis error.
See

https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#php-style
https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#static-analysis-on-php-code

@maniaba Thank you for sending the PR. You forgot GPG signing. See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/signing.md
It ssems there are coding style violations and Static Analysis error. See

https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#php-style
https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#static-analysis-on-php-code

I just made changes.

Your sign is unverified.

The email in this signature doesn’t match the committer email.

@maniaba Please add to the user guide changelog (1) debug toolbar is now using microtime instead of time, and (2) there is a possible BC break for those users extending the History Collector and they should probably update setFiles() method

This is not (int):
https://github.com/codeigniter4/CodeIgniter4/blob/4ca2159818ca96d26bb9713b00941461509ad0b1/system/Debug/Toolbar.php#L485-L488

@maniaba
Rector check was failed. Can you fix?
See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#static-analysis-on-php-code
And when you sync your repository, can you use git rebase?
See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/workflow.md#pushing-your-branch

@maniaba
It seems you used git merge. Is it difficult to use git rebase?
See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/workflow.md#pushing-your-branch

Your changes to the SCSS files did not match the expected CSS output.
diff --git a/system/Debug/Toolbar/Views/toolbar.css b/system/Debug/Toolbar/Views/toolbar.css
index 680ef52..11a3301 100644
--- a/system/Debug/Toolbar/Views/toolbar.css
+++ b/system/Debug/Toolbar/Views/toolbar.css
@@ -774,7 +774,8 @@
 }

 .debug-bar-width190p {
-  width: 190px;}
+  width: 190px;
+}

 .debug-bar-width20e {
   width: 20em;

https://github.com/codeigniter4/CodeIgniter4/runs/5314886769?check_suite_focus=true

There was 1 failure:

1) CodeIgniter\Debug\Toolbar\Collectors\HistoryTest::testSetFiles
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'1645684473.268600'
+'1645684473.2686'

/home/runner/work/CodeIgniter4/CodeIgniter4/tests/system/Debug/Toolbar/Collectors/HistoryTest.php:75
phpvfscomposer:///home/runner/work/CodeIgniter4/CodeIgniter4/vendor/phpunit/phpunit/phpunit:97

@maniaba
Fixing the failed tests seems to complete this PR.
Can you?

Closed via #5958


Adds contentsTitle to all/title search scopes

Adds matching against contentsTitle.folded field when searching all
(default) or title scopes. All fixtures are regenerated as a consequence
of the baseline query body changing. Although some fixture data has
drifted, no existing tests were broken.
Includes trivial, unrelated fixes, including:

one test was expecting data in contributorLiteral data that now exists in creatorLiteral
improved documentation about updating fixtures

https://jira.nypl.org/browse/SCC-469

PR 💯 !


How to use confirmDismiss property of Dismissible? Please, give example.

Will send in a PR. Thanks for letting know.

I think this issue can be closed now?

I think this issue can be closed now?


[DATAHELP-2984] Log more on deepcopy failure

This one is similar to https://github.com/lyft/incubator-airflow/pull/174/files but the request I got enters into the other condition, hence adding it as well.
https://jira.lyft.net/browse/DATAHELP-2984

@jinhyukchang @astahlman @feng-tao


Problems with ggplot: Histograms don't stack, density plots don't fill

As reported by @edvinli in #7 :

I don't get the histogram to stack, as in the example in the readme. I get that the histogram when plotting my top 10 are added behind and in front of each other instead of stacking. Any idea as to why?

The density plot does not fill, I haven't figured out why that is.

I guess there are breaking changes in ggplot between versions 0.6.8 and 0.11.5 (dependency updated in 3c78a5369b23f2954a3166a9f7d7651882e60402).

Downgraded to ggplot 0.6.8 in 60b50b6088af18149d45533f0c4d3f6854244c19 to fix.


Access nested cells with the same owner

My usecase is in a programming language, for type-inferring. I have type variables in Rc<TCell<>>, such that multiple places can share their inferred type automatically. The problem is that a type can contain another type variable (that might not be known yet), so I have some situations where I would effectively need to get the innermost value (mutably) out of a Rc<TCell<Rc<TCell<_>>>>. I have some workarounds for this, but they are all limiting in some way.
I think the nested access pattern should be possible for all the cells, since the owner is borrowed mutably and so no other accesses can happen simultaneously. Is my reasoning wrong? If not, it would be great if we could get a function like
fn TCellOwner::rw_nested<T, U>(cell: &TCell<T>, get_nested: impl FnOnce(&mut T) -> &TCell<U>) -> &mut U;

On a related note, we could also introduce a lower-level, UnsafeCell-like unsafe API to get pointers without having the owner.
This would allow one to implement the above function oneself, by using the fact that the owner is borrowed mutably to fulfill the safety conditions of, say,
/// Subject to similar conditions to UnsafeCell::get
fn TCell::ptr(&self) -> *mut T;

(This should then also exist for all the cells)

This could be unsound as there is nothing to stop you borrowing the same cell twice mutably.
It IS sound to do multiple mutable borrows using the same owner, but that requires cross-checking that no two of them refer to the same memory. This is convenient to check if the caller presents all of them at the same time which is what rw2() and rw3() methods do. To do something more dynamic like what you're proposing would mean building up a list of memory addresses already borrowed and checking new borrows against that. Is this going to be any more efficient than your workarounds?
Alternatively perhaps once you know you're looking at two TCells, you could drop the borrow on the first and then use rw2 to get borrows on both of them at the same time.

Okay, I think I can see what you're saying now. Since rw_nested knows the address of both cells, it can do the cross-check. It seems like quite a specific case, but valid. I wonder whether it can be generalized in some way. I will think about it.

I have an idea. It would go something like: let (borrow1, chain) = owner.rw_chain(&tcell); let borrow2 = chain.rw(&borrow1.tcell);. I think I can let people chain borrows indefinitely, although it has to do an O(N) scan down the chain each time a new borrow is added. But it may panic if two TCells turn out to be the same one. So I think I also need try_rw and try_rw_chain so that those cases can be handled in the caller. I will have a go later on.


Fix/action

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Rotating blog CTA to April 19th's staging event

Description & motivation
The next Staging is coming up on April 19th - let's let people know in the dev blog CTA section.
Asana ticket here.
Pre-release docs
Is this change related to an unreleased version of dbt?

[ ] Yes: please

update the base branch to next
add Changelog components: <Changelog>[New/Changed] in v0.x.0</Changelog>
add links to the "New and changed documentation" section of the latest Migration Guide

[ x ] No: please ensure the base branch is current
[ ] Unsure: we'll let you know!

Could you merge plz @jasnonaz?!  Boarding a flight to an offsite.

On Apr 4, 2022, at 12:32 PM, Jason Ganz @.***> wrote:

@jasnonaz approved this pull request.
good to go!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.

@krevitt merged!


feature/mx-1615 setup authentication

PR Context
This PR adds basic authentication against a local user config, as a stop-gap for a centralized IAM.
Added

add login component and form
add user menu in navbar with logout button
setup authentication against locally configured users

Changes

re-organize state classes into individual modules

Removed

remove unused mex.editor.transform.to_primitive

I couldn't log in with the new credentials. Only the old credentials, which I still had in my .env worked.

not sure what you mean with the new credentials, but this is desired behaviour, it should validate against the ones that are found in your local .env file

It would be great to have the command on how to shut down the running editor

yeah good point. instead of the readme, I added a log message to the startup procedure though; see 0ee3326


Crooked display of object in debugger

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.94.2
OS Version: windows 11 23H2

Steps to Reproduce:

Sort object: Record<string, number>
Launch the debugger
View the results

Why did I specifically sort the object, but vs code decided to display it as he wanted

Please share the code. I don't think that any particular order of object keys can be guaranteed in the debugger though.

That's exactly what it is not guaranteed to be. And if I specifically sort the object?
export const sortObj = (obj: Record<string, number>) =>
	Object.entries(obj)
		.sort(([, a], [, b]) => b - a)
		.reduce(
			(r, [k, v]) => {
				r[k] = v;

				return r;
			},
			{} as Record<string, number>,
		);

const glossary:  {
  l: 0.231,
  o: 0.154,
  H: 0.077,
  e: 0.077,
  ' ': 0.077,
  w: 0.077,
  r: 0.077,
  d: 0.077,
  '!': 0.077,
  '\n': 0.077
}

console.log(sortObj(glossary))

Please share the code. I don't think that any particular order of object keys can be guaranteed in the debugger though.

That's exactly what it is not guaranteed to be. And if I specifically sort the object?
export const sortObj = (obj: Record<string, number>) =>
	Object.entries(obj)
		.sort(([, a], [, b]) => b - a)
		.reduce(
			(r, [k, v]) => {
				r[k] = v;

				return r;
			},
			{} as Record<string, number>,
		);

const glossary:  {
  l: 0.231,
  o: 0.154,
  H: 0.077,
  e: 0.077,
  ' ': 0.077,
  w: 0.077,
  r: 0.077,
  d: 0.077,
  '!': 0.077,
  '\n': 0.077
}

console.log(sortObj(glossary))


Widgets should be sortable

Describe the feature you'd like to have in Pock
Widget order should be changeable in the widget list. The pock.app web page seems to suggest that widget order is variable because the order on the example widget is different than my own.
Describe alternatives you've considered
Perhaps one can just remove widgets, and then reinstall them in a well-defined order, but as a stopgap or alternative, that is highly kludgy, undesirable, and unacceptable IMO. Also it probably causes widget config reset, which makes it a nonstarter/nonfunctional as a replacement.

:(


[Fix #13050] Add new Style/BitwisePredicate cop

Closes #13050.
This PR adds new Style/BitwisePredicates cop, which checks for usage of & operator in bitwise operations involving comparisons.
# bad - checks any set bits
(variable & flags).positive?

# good
variable.anybits?(flags)

# bad - checks all set bits
(variable & flags) == flags

# good
variable.allbits?(flags)

# bad - checks no set bits
(variable & flags).zero?
(variable & flags) == 0

# good
variable.nobits?(flags)

I've opened a proposal in the style guide at https://github.com/rubocop/ruby-style-guide/pull/944.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thank you for feedback. I updated this PR.

@koic @bbatsov Is there a chance of merging this? I have a codebase that begs for this cop dearly :grin:

@zverok Sure!


Ensure StartAsync on transports waits for the transport to initialize and yields any errors

Right now, the Server-Sent Events and Long Polling transports don't actually block StartAsync until they are initialized, they start up loops to handle polling and sending and then just immediately return. This means any failure in initialization won't trigger Transport Fallback (#1455).
For example, see Server-Sent Events (Long Polling is similar):
https://github.com/aspnet/SignalR/blob/1c44e8febfd57a1038715d6c74f030cebdcd14f2/src/Microsoft.AspNetCore.Sockets.Client.Http/ServerSentEventsTransport.cs#L47-L72
The Task.CompletedTask on line 71 will be returned regardless of if the transport successfully initialized. Instead, we need to create a TaskCompletionSource, pass it in to the "OpenConnection" method and return the Task from that in StartAsync. Then, when the connection is properly established, we trigger the TCS, or if any error occurs, we fault the TCS.

For Server-Sent Events, we want to trigger the TCS after the SendAsync here completes, and fault it if an exception occurs anywhere up to that point:

https://github.com/aspnet/SignalR/blob/1c44e8febfd57a1038715d6c74f030cebdcd14f2/src/Microsoft.AspNetCore.Sockets.Client.Http/ServerSentEventsTransport.cs#L76-L81

For Long Polling, things are slightly trickier. We want to trigger the TCS as soon as the first poll flushes headers. On the client, that simply means triggering it after the SendAsync for each poll (https://github.com/aspnet/SignalR/blob/1c44e8febfd57a1038715d6c74f030cebdcd14f2/src/Microsoft.AspNetCore.Sockets.Client.Http/LongPollingTransport.cs#L102) since only the first time you trigger it matters. Similarly we need to fault it if there's an exception with a poll. However, the server is trickier (see below)

We do have one tricky thing to deal with. Today, the Long Polling transport on the server does not flush the body until a message arrives, which means the headers won't be sent, and the SendAsync call on the client won't complete until a message arrives. We'll need to change our logic to flush the body immediately (to signal that the poll was received). That also means we can't set the Content Length and will have to use Chunking (the server will do this for us automatically) because we won't have a message at the time we're writing the headers.
@davidfowl Does this all sound reasonable to you? In particular, the Long Polling server-side change is a bit of a change in protocol.

We're also going to need this in the TS client.

Yup, gonna add it with https://github.com/aspnet/SignalR/issues/1558

Done: b5c46f35b3550936655c94c9ae8925d1fd4256be


[question] Is interacting with dynamically added elements supported?

I wonder if its possible to for example click on an element that is added to dom by an ajax call? I could not managed to that and I wonder if it's an issue with webdriver its self, i don't create a full issue of it.
I was assuming it's possible to do any think a real user can do by webdriver. however according to http://mink.behat.org/en/latest/guides/drivers.html#driver-feature-support there are somethings that are not possible to do.

Hi @salarmehr , yes, this is possible.
You must first use explicit wait, to make sure the item is already present in DOM. Then its no problem interacting with those elements.
BTW Behat uses different Selenium driver than php-webdriver, so its documentation may not be relevant for php-webdriver behavior.

OMG, I was using Laravel Dusk waitFor method assuming it uses php-webdriver explicit waits. However it does not!
Frustrated of using Dusk and wasting time more! :(


add config options to enforce passwords on public links

Added a new config option to enforce passwords on public links with "Uploader, Editor, Contributor" roles.

:boom: Acceptance test localApiTests-apiSpaces-ocis failed. Further test are cancelled...

The open points have been clarified with @C0rby.
No changes needed, all issues identified will be fix in a independent PR.


add max length for help command

There is now a max length of 256 so the default help command can't work if you have a lot of commands

Thanks for letting me know, I'll rework the command to work with the new message system.

Fixed in https://github.com/xMistt/rebootpy/commit/9714b2dd4cd48dbab92ef6d7b70097ab0767b112, I tested & had no issues, but if you have any, please let me know here by reopening this issue. These changes will be in the next pypi release which will either be today or tomorrow but if you need it before then, you can download directly from GitHub.


Fix mpris support in Linux (tested with GNOME on GNU/Debian-sid).

Fixes #3618.

Can you explain why this fixes the mpris support? This just reverts recent changes that were made to bring mpris up to date.

It reverts indeed a change that broke the MPRIS support. So reverting a broken patch looks like a fix to me? Just test it, it works. Note that only part of the patch is reverted.
I'm using this patch for my own build since some days on GNOME without issue.

The original change may have broken mpris support, but the current version  should also be compatible. I'd rather come to a solution with the new version vs reverting.

But then the original author should look at this. I have mostly bisected the issue to the wrong commit and I have reverted the minimal part that broke completely the MSIS support. I'm no expert on this issue, I'm also contributing to too many Open Source projects and cannot invest more time on this. I wanted this to work as I depend on this issue and it was broken for far too long, so I decided to fix it. Feel free to close this PR if you don't think it can be integrated, that's fine with me.

I'm going to close this as it doesn't solve the issue without reverting way back before the dbus/mpris upgrade. If we can come up with a specific fix for the issue at hand otherwise I'd review it.


Enhancement: Add a drop_all function

Summary
There should be a way to drop all current tables in your database including the alembic_versioning table.  This is really useful for rapid prototyping.
Basic Example
No response
Drawbacks and Impact
No response
Unresolved questions
No response

Funding

If you would like to see an issue prioritized, make a pledge towards it!
We receive the pledge once the issue is completed & verified

This feature would be very useful


Test that walproposer recovery is handled correctly

See #859
For example, at the moment I'm not sure how exactly walproposer knows whether it's received enough WAL from a specific Safekeeper.

@arssher should we do anything here?

yes, we should add a small check that all WAL was indeed received


Update Companion Pet Plugin- Update for compatibility with WorldView.

Update Companion Pet Plugin- Update for compatibility with WorldView.
(Very small change, Plugin currently not working without fix)

Can you please scale down your nav_icon image, it's very large due to being blown up to it's max size when Java loads it into memory (width * height * 4)


Swift 3.0 handle?

Hi, is it possible to handle swift 3.0 by updating dependancy of
'SwiftyJSON'
'SwiftWebSocket'

Hello, @arnaudWasappli
will update it on a weekend

@arnaudWasappli, it appears it requires a bit more time to upgrade than I thought, will update it as soon as I have time
or PRs are always welcomed;)

+1


Fetch full PR branch

Closes #756

I accidentally broke the link to this branch, closing -- will try to reopen.


Blog updates

Clarification on blog posting on README
Update to blog categories
Update first blog post to reflect new category ID

Deploy preview here: https://5f9b21f0af3e6300072fadd4--magma-website.netlify.app/


Level: Basics 1 - "First Commit"

1) First Commit - Show that you can add/commit - Commits contain files (adapt from basics-committing)

Just add a file and commit that file.
Status shows your progress in a way somewhat like this.
 Created: Yes
 Added: No
 Committed: No

The level demonstrates the process and shows how files must be added before they are considered part of a commit

@benthayer Woop


System throws a technical error message on clicking 'Message' link

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Sign in with account A (default contact method)
Add account B as a secondary login of account A
Sign in with account C on a new tab
Open a chat with account A
Mention secondary login account B
Send message
Switch tab to where account A is signed in
Open the message sent from account C
Click on the mentioned secondary login message
Verify a details sidebar displaying details of the secondary login account is displayed
Click on Message link
Observe that system has thrown a technical error message (Auth OpenReport returned an error)
Click on the browser's refresh button
Observe that user is signed out

Expected Result:
System shouldn't throw a technical error, and shouldn't sign out user
Actual Result:
System throws a technical error message, and signs out user
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.13
Reproducible in staging?: y
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/88bf7811-b133-43ff-b84d-26ecf8c11501
https://github.com/Expensify/App/assets/43996225/57033f8f-2a97-417c-9742-71790e43e3ee
Expensify/Expensify Issue URL:
Issue reported by: @natnael-guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1683807771824459
View all open jobs on GitHub

Since the secondary login account is not treated as a separate account, I believe 'Message' link shouldn't be available on the details sidebar when clicking on the secondary login mention. Rather, the details sidebar for secondary login should have the same elements as the details sidebar for the default contact method.

Proposal
Please re-state the problem that we are trying to solve in this issue.
System throws a technical error message on clicking 'Message' link
What is the root cause of that problem?
Currently we don't allow sending message to the same account (including all the accounts of contact methods), so when we try to message an account from our contact methods, server will return the errors.
What changes do you think we should make in order to solve the problem?
I agree with @Natnael-Guchima that we shouldn't show the Message button when we open the detail page.
In order to do that, we should update the condition to show or hide Message button inside DetailsPage.
Currently we only hide it when the mail equals the main contact method.
https://github.com/Expensify/App/blob/293f23b57be2bca3f3eb0af903d5e0c2894cb36a/src/pages/DetailsPage.js#L190-L197
So the condition to show the Message button will look like this:
 const isCurrentUser = _.keys(this.props.loginList).includes(details.login);

                                {!isCurrentUser && (
                                    <MenuItem
                                        title={`${this.props.translate('common.message')}${details.displayName}`}
                                        icon={Expensicons.ChatBubble}
                                        onPress={() => Report.navigateToAndOpenReport([details.login])}
                                        wrapperStyle={styles.breakAll}
                                        shouldShowRightIcon
                                    />
                                )}

What alternative solutions did you explore? (Optional)
None.

This is going to take a while to test, will get to soon

Took me a minute but I was able to reproduce and get 🔴 Auth OpenReport returned an error
It sounds like we have, at least, a couple options.

@Natnael-Guchima 's "Since the secondary login account is not treated as a separate account, I believe 'Message' link shouldn't be available on the details sidebar when clicking on the secondary login mention.
Change the wording of the error message to something like Hey numbskull, you can't message yourself! (jk)

I like #1 better as you shouldn't be able to complete the action of opening the message pane if you can't send a message.
@tgolen It might not be a valuable use of your time to try to reproduce, I wasn't sure if this was internal or external so added Engineering for 👀

I also agree that this is probably worth a UI change since it's already blocked on the server and we should just remove the message link.

Sending this to external to get some proposals

I got to this issue through Upwork. I am still setting up the development environment. With limited context I think there is one more way to solve this problem.
Context:
There is a primary account<EMAIL_ADDRESS> This user has added<EMAIL_ADDRESS>as alternate contact.
Keep view consistent

Clicking<EMAIL_ADDRESS>and<EMAIL_ADDRESS>should open same detail tab.
Detail tab will also have 'Alternate Contacts' section. It will list all contacts associated with this account, in this case<EMAIL_ADDRESS>will be listed there.
Message button will not be there

Note
It will be good if this behavior is consistent when any other user clicks on<EMAIL_ADDRESS>or<EMAIL_ADDRESS>

@hungvu193 Thanks for the proposal. Your RCA is correct and the fix is on point :+1:.
:ribbon: :eyes: :ribbon: C+ reviewed
cc @tgolen

🟢  to hire @hungvu193 for this @mallenexpensify
@hungvu193 You can go ahead and create a PR when you are ready.

🟢 to hire @hungvu193 for this @mallenexpensify
@hungvu193 You can go ahead and create a PR when you are ready.

Sure. I'll create a PR soon

https://github.com/Expensify/App/pull/19431 is now ready for review @tgolen @s77rt

@Natnael-Guchima (for reporting), @hungvu193 and @s77rt have all been hired, please accept
https://www.upwork.com/jobs/~01b88f02a102ef7dee

@Natnael-Guchima (for reporting), @hungvu193 and @s77rt have all been hired, please accept
https://www.upwork.com/jobs/~01b88f02a102ef7dee

I've accepted. Thank you

Accepted. Thanks @mallenexpensify .

@mallenexpensify Accepted!

Apologies for the delay in hiring @hungvu193 , all good now!

The PR that introduced the bug has been identified: https://github.com/Expensify/App/pull/7135
The offending PR has been commented on: https://github.com/Expensify/App/pull/7135#discussion_r1207120510
A discussion in #expensify-bugs has been started: https://expensify.slack.com/archives/C049HHMV9SM/p1685123516043239
Determine if we should create a regression test for this bug: No

All paid, inc. 50% timliness bonus!


spec: embedding a type alias is confusing

When you embed a type alias within a struct, the resulting struct type has a field of the alias's apparent name, but its run-time type descriptor uses the alias's original name.  For example:
package main

import "fmt"
import "bytes"

type buffer => bytes.Buffer

type S struct {
        buffer
}

func main() {
        var s S
        _ = s.buffer
        // _ = s.Buffer // compile error: s has no field Buffer
        fmt.Printf("%#v\n", s) // "main.S{Buffer:bytes.Buffer{...}}"
}

This is potentially confusing to the reader, and I suspect it will break a number of analysis tools that assume the name in the syntax of the embedded field declaration is the same as the name of the field.
Something to think about.

It's worse. If the package that exports S is imported again, in that package the anonymous field is named as the type: Buffer rather than buffer. That is, the same field is named differently in different packages.
package t1

import "go/build"

type T struct {
	context
}

type context => build.Context

var t T
var _ = t.context // lower-case context

package t2

import "./t1"

var t t1.T
var _ = t.Context // upper-case context

After clarification in spec, the compiler needs to be fixed.

Since this affects type aliases, this issue would persist even if we restricted aliases to a types only.

It should be fairly simple to fix in the compiler: Currently, when we export anonymous fields, we deduce the field name from the type. We simply have to export the actual field name as well (perhaps only when it's different from the type name).

By fix, do you mean treat struct { buffer } as if it had been written struct { bytes.Buffer }?

No, treat struct { buffer } as it's written; i.e. the field name is buffer in this case.

It looks like the public APIs for reflect.StructField and go/types.Var already independently report name and anonymity/embeddedness, so that's good.
However, reflect internally represents anonymous fields as an empty field name, which at runtime it replaces with the field type's name.  We'll need to change that to allow named embedded fields.
(Unless we do decide instead that struct { buffer } is equivalent to struct { bytes.Buffer }.)

Using the field name as written seems much clearer.  It does mean that some types differing only by alias names are non-identical, such as these three:
struct { bytes.Buffer }
struct { buffer }
struct { buffer2 } // another alias of bytes.Buffer

I believe the behavior that Alan describes in the initial report is the right one. As I said on the CL, think of alias like a #define. Whether you name the alias or the actual definition of the alias, the resulting program should have identical behavior 100% of the time. Because "buffer" is an alias for "bytes.Buffer", embedding "buffer" behaves exactly like "bytes.Buffer".
Analysis tools should probably be working on the "original" type all the time. As long as they "dereference" the alias aggressively, they should have no problem with this. People may have a slight problem, but tooling will help and of course convention will too.
I agree that the embedded buffer being named Buffer is a little bit of a surprise, but the definition of alias is crystal clear about the effect:
The effect of referring to a constant, type, variable, or function by an alias
is indistinguishable from referring to it by its original name.

I think it would be a serious mistake to make exceptions to that rule. Doing so would bar (or at least complicate) automated fixes that try to update code to use non-deprecated names in place of deprecated aliases.
That said, the legacy aliases byte/uint8 and int32/rune do not behave this way: they take the name used in the struct. That implies to me that we should not refer to them as aliases, now that alias has a precise and different meaning. I filed #17766 for a reflect bug involving those.
/cc @robpike @ianlancetaylor

I appreciate that the spec change in https://go-review.googlesource.com/30601 breaks the "crystal clear" invariant you quoted, and makes structs nonidentical if their fields differ only by an alias name, but I think using the name as it appears for the field name leads to much more readable code.
Also, the change you propose would break an equally important invariant: identifier case determines exportedness.
You would be surprised to read this declaration
type S struct { foo }

or perhaps see this documentation in godoc:
type S struct { /* unexported fields suppressed */ }

and discover that struct type S has a field called Foo (or perhaps even Bar).
As for the "automated fixes", the lesson is: when you use aliases as forwarding pointers during a refactoring, be sure to give the alias the same name as the original.

type b => bytes.Buffer
var B1 b
var B2 struct { b }
var B3 struct {
    struct { b }
    struct { bytes.Buffer }
}

I gather that in this example the idea is that B2.b does not work because there is really no field named b, likewise B3.b does not work, and B3.Buffer does not work because there is a name collision.
But what about exports?  In this example, does the package have an exported type Buffer?  Or given type B => bytes.Buffer does the package have an exported type B or an exported type Buffer?
What is the key difference between those cases?  In one case, the aliased name matters, and in the other case the alias name matters?

But what about exports? In this example, does the package have an exported type Buffer?

The type alias b is not exported because it starts with a lowercase letter.  The exported type of B2 is a struct containing a single field named "b" of type bytes.Buffer.

and B3.Buffer does not work because there is a name collision.

No, you can't compile even the declaration of B3 because an anonymous field must a named type or a pointer to one, not an unnamed struct type.

given type B => bytes.Buffer does the package have an exported type B or an exported type Buffer?

The package would have an exported type alias B whose original is named bytes.Buffer and has the declaration struct {...etc...}.

In the discussion on the alias proposal there was an alternative suggestion (by me, but that that's not important). It differs in that it does not bind any new (local) names. The observation I'd like to point out is that then some, if not all of the problems being discussed above are automatically solved - they cannot happen.

@cznic You are correct - if we don't allow renames, the problem disappears.

@rsc I disagree. I believe there's a difference between the behavior of the name (which aliases is all about: different names) and the behavior of the respective entity (type in our case). But I like to step back for a moment and contemplate a completely different approach.
Currently we have an inconsistency. There are many ways to resolve this. I am enumerating some here to pique imagination a bit:

Do not allow aliases to rename the original (aliases) entity. I believe we should seriously consider making this change. See elaboration below.

Disallow the use of aliases as anonymous struct fields.

Make a difference between the alias name used as a "handle" to refer to an anonymous field, and the actual field itself. This is what Alan and I have been proposing.

Always use the original (aliased) type's name to refer to the anonymous field, no matter if an alias is used or not. This is (I believe) what @rsc is suggesting.

Allow both: the alias or the original type name to refer to a field ("anything goes").

Don't introduce aliases.

Arguments in favor of solution 1:

If we don't allow aliases to rename, this issue falls away.

If the alias and the original have the same name, there's is much less confusion about what an alias refers to. This (potential for confusion) is a major concern brought up by the community.

If alias and original must have the same name, it's impossible by design to declare more than one alias per package for a given original. This is another potential concern brought up by several people.

If alias and original must have the same name, we can simplify the alias syntax (see suggestion below). If we can simply the alias syntax, we don't need another token "=>", and yet another pain point of the proposal falls away.

Finally, this would still address the primary use cases we see for aliases.
Suggestion for simplified alias declaration syntax:
AliasSpec = QualifiedIdent .

Examples:
const math.Pi
type bytes.Buffer
var build.Default
func math.Sin

Intuitively, each such declaration simply states that the qualified identifier is declared under the base name in this package. It is automatically re-exported. Or another way of looking at these declaration is to see them as "extern" or "forward" declarations of entities declared elsewhere.

I haven't thought long and hard about it but @griesemer's suggestion (option 1) appeals to me.

It's certainly simpler, and the syntax is clever, but if we are to add this restriction I wonder if sticking to the existing syntax might not be better, for three reasons. The first is that we can extend it later should the need arise.  The second is that this feature of the language will, we hope, be little used and therefore slightly obscure to many users. The existing syntax suggests its meaning clearly, and is less likely to cause surprise or be used by accident.  In contrast, the concise syntax proposed here could trigger confusing compiler errors.  The third reason is that it looks like just a use of a name, not a declaration, when in fact it's both.

A restriction for Go 1.8 may make sense, but I think we should reserve flexibility for later. The "simplified syntax" seems too simple - it looks almost like a typo - and it does not have obvious flexibility for later.
I am concerned that option 1 is too restrictive. The motivating use case for alias is when moving a declaration from package P1 to P2. It may be that P1.Name was a good name but that P2.Name is not a good name, because P1 and P2 convey different information. The restriction in option 1 limits the refactoring in potentially unhelpful ways. For example, when we moved io.ByteBuffer out of io, it became bytes.Buffer, not bytes.ByteBuffer. It would be sad if aliases effectively disallowed using the best name for the new location.
I am also concerned that option 2 is too restrictive. For example the golang.org/x/net/context package's tests define
type otherContext struct {
	Context
}

As of Go 1.8, the definition of Context in that package is
type Context => context.Context

to redirect to the standard library definition. But the tests are worth keeping to make sure the definitions in the golang.org/x/net/context package do work. That test would no longer compile if we adopted option 2.
I think 3 and 5 are non-starters, and I understand that others think 4 is a non-starter. Let's strike those. I think 6 would be terribly unfortunate, since we do have a problem to solve.
A counter-proposal, intersecting options 1 and 2, so let's call it option 1.5:
1.5) If an alias is used as an anonymous struct field, its name must match its target's name.
This avoids all the confusion we've identified without causing the more general problems in the specific examples I mentioned above.

@alandonovan Parsing the existing syntax and the simplified syntax are almost identical. The lead is a an identifier followed by either "=>" or "." (depending on which approach we choose). Any confusion that can arise with "=>" can arise with "." .

Isn't option 1.5 "too restrictive" for the same reasons you outlined for option 1?  To continue your example, defining bytes.Buffer as an alias for io.BytesBuffer would have disallowed clients from embedding bytes.Buffer.
Perhaps what makes option 4 unsettling is that it reveals that "anonymous" fields are not anonymous. All fields have names, but only an "anonymous" field declaration triggers embedding behavior.  In fact it would be quite possible to decouple the issues of naming and embedding altogether.

I certainly do understand the objections to 4. What's nice about 1, 1.5, and 2 is that any of them side-steps having to decide between 3, 4, 5. What's nice about 1.5 in particular is that it breaks fewer uses than either 1 or 2: it breaks only the uses that both 1 and 2 would break.
That is, suppose you have these cases:
A) Alias io.ByteBuffer => bytes.Buffer, with no embedded uses of the original.
B) Alias io.ByteBuffer -> bytes.Buffer, with embedded uses of the original.
C) Alias x.Context => context.Context, with no embedded uses of the original.
D) Alias x.Context => context.Context with embedded uses of the original.
(1) breaks A and B.
(2) breaks B and D.
(1.5) breaks B only.
That seems like a win. The problem is caused by the unexpected interactions of renaming and embedding. Instead of disallowing one or the other always, disallow doing both at the same time.

I'm not sure it's a good idea but I want to mention the possibility of (1.75) any aliased type may be embedded in a struct, but you may only refer to it directly if the name of the alias is the same as the name of the aliasee.  That is, in the case of different names, you can embed to inherit methods, but direct references to the field are not permitted, as though there were a name collision.  The type reflection information would have the qualified name of the aliasee--a name that can be printed but can not be referenced in Go code.

@rsc The simplified notation is trivial to extend to allow "=>" should that need arise. Though this might really be a situation where perhaps we should give up flexibility of naming for simplicity and clarity of feature, even when we can't always get the best name at a new location. After all, we still believe we should use aliases sparingly.
Regarding the "syntax almost looks like a typo": We will get used to it. Func declarations w/o a function body also look a bit odd, and it's a similar situation. Also, in the (likely) common case where the name doesn't change, we don't have stutter (type Context => context.Context vs type context.Context).
Regarding the other options I suggested: I agree that 2), 5) and 6) are not good solutions.
In defense of 3) which is Alan's and my original suggestion for this issue: The spec arguably already supports this approach. This:
The effect of referring to a constant, type, variable, or function by an alias
is indistinguishable from referring to it by its original name.

concerns "referring to", that is use of a name. If I declare an anonymous struct field using an alias
type foo => bytes.Buffer
type T1 struct { foo }

I expect the behavior of that anonymous field (which is referred to by it's alias foo) to be the same as bytes.Buffer. I don't expect it to be called Buffer - that's not what's in the source, but I expect it have the same methods, identity, etc. as bytes.Buffer; i.e., I expect it to have the same behavior. After all, anonymous fields really are anonymous for all behavior, the fact that we need a name is simply so we can refer to it.
Finally: Of course we can do suggestion 1.5 for Go 1.8. But it adds one more rule. It also "burns in" the new "=>" token. The suggestion 1) is more minimal and doesn't even require token changes.

For whatever it's worth, if I saw

type S struct {
        buffer
}```

in some code my assumption would be that it behaved exactly like embedding bytes.Buffer except that a user of this package could not refer to the embedded type by name as the alias is unexported. I would also expect

t := S{}
t.Buffer.Reset()

to fail to compile because I embedded buffer not Buffer.

But likewise I'd expect:

```func NewS(b buffer) S {...}```

to accept a bytes.Buffer value since they're type-identical.

But that's also confusing because I'd expect an outside package to not be able to create a value of an unexported type.

I think there's an inherent contradiction between aliases being another name for something and a name determining whether something is exported, which affects how it behaves and can be used.

Maybe we need option 1.1 where you can rename an alias but it has to have export parity; that is, an exported identifier can only be aliased to an exported identifier, and, likewise, an unexported identifier can only be aliased to an unexported identifier.

I appreciate the simplicity of type pkg.Name and how it elegantly avoids the field naming issue and extra syntax, but thinking about it some more, I'm not sure it solves the LSC (large-scale change) issue for renaming types.
If you want to rename a type in a LSC from pkg1.T1 to pkg2.T2, ideally the steps are:

Introduce alias "type T2 => pkg1.T1" in pkg2.
In parallel, independently update all users of pkg1.T1 to use pkg2.T2 instead.
Replace the type alias for pkg2.T2 with a regular named type declaration.
Remove pkg1.T1.

Because you want step 3 to be a local operation that only affects pkg2, it's important that any field embeddings of pkg2.T2 be unaffected.  I think that strongly suggests the implicit field name needs to be T2, not T1.
(The inability to declare type aliases within a package unfortunately complicates renaming from p.T1 to p.T2, but it's possible as a two step operation: p.T1 -> ptmp.T -> p.T2.)

I generally agree with rsc's "crystal clear" invariant being a good thing. I will be very helpful in writing automatic rewriting tools, which will be, I think, critical to have aliases actually disappear (or at least converge towards disappearing)  down the line in the process of a refactoring.
I think the main issue of 4 is more the unexpected exportedness than the naming. Much of the confusion of 4 can be avoided by requiring that an alias is required to have the same exportedness, as @alandonovan calls it, as the object it aliases. This also avoids confusion of whether a in type a => bytes.Buffer is exported or not.
@gri: I think not allowing renames is too strict. Although it is consistent with not allowing aliases to objects within the same package. If you allow renames, you probably should also allow the latter.

FWIW: I would expect embedding with aliases to work as follows....
package t1

import "go/build"

type context => build.Context

type T struct {
    context
}

var t T
var _ = t.context // lower-case context

package t2

import "./t1"

var t t1.T
var _ = t.context // lower-case context

I don't like option 1.5 because
import pkg

type S {
   pkg.T
}

succeeds or fails entirely on whether T happens to be an alias that happens to change a name. Even with a really good error message that is, if nothing else, annoying.

The exact syntax was discussed and refined quite a bit in the proposal process, with significant community input. I strongly believe we should not reconsider that today without very good reason; probably we'd need to go back to the "proposal" phase. Let's please take syntax changes off the table and focus on semantics.
The question before us in this issue to define the semantics of aliases when used as embedded fields. Broadly speaking, there are two kinds of answer to this: either some specific definition or else some restriction that excludes the situation entirely. For Go 1.8, I personally lean toward the latter, because it buys us time to consider the specific definition more carefully later (if ever; maybe the right restriction will be livable, like happened with 3-index slices). From @griesemer and @robpike's replies it sounds like they lean toward the restriction approach too. I don't see any leaning one way or another in the other replies here.
Q: Do we agree that for Go 1.8 we should somehow restrict aliases to avoid this situation instead of trying to define its meaning?
Assuming yes, then there are four choices proposed so far:

Disallow renaming aliases (such as io.ByteBuffer => bytes.Buffer).
Disallow embedding aliases (such as type otherContext { xnet.Context }).
1.5) Disallow embedding of renaming aliases.
1.75) Disallow references to embedding of renaming aliases as ambiguous.

Q: Which restriction should we adopt for Go 1.8?
I think there are good reasons to think (1) and (2) are too broad. (1) breaks a rename we've done before, and (2) breaks a use of alias that exists today (but could obviously be changed). I think (1.5) is a reasonable compromise and that we could reserve (1.75) for when a real situation arose that justified it.
If there are significant objections to (1.5) and the choice is between (1) and (2), I would opt for (1).
Thoughts?

1.5 seems like a safe compromise that leaves the door open for the future.

Embedding is fundamental to the language. Peppering it with footnotes seems wrong. Especially since you'd have to know about how a type from another package that you're attempting to embed is declared to know whether you can.
Option 1 (sans syntax simplification) isn't a terrible restriction, even if it would disallow some useful things temporarily.

I think disallowing alias renaming (1) is the safest.  I'm concerned that 1.5, 1.75, and 2 introduce opportunities where type p.T becomes a (possibly renamed) aliased type, and causes downstream embeddings to stop compiling through no obvious fault of their own.

I still believe option 3) is viable and on the table. I have not seen a convincing argument against it. It would keep everything in place.

@griesemer to clarify, option 3 means that given
package p
import q
type S => q.T
type U struct {
    S
}
var u = U{}

then u.S would be the field name but u.T would not be.
Is that a correct summary or did I get muddled somewhere mid-thread?

@jimmyfrasche That is correct. An anonymous field is referred to by the name used to declare it - not the original name of the type. With respect to behavior (but not naming), the anonymous field behaves as if the original type was used (i.e., it promotes the types' methods, field names, etc.).
That is, option 3) leaves everything as is but fixes the current issue, and I believe it fixes it in accordance with the spec (see https://go-review.googlesource.com/#/c/32633/).

I think of aliases as hard links. That is, it establishes a second name for a type that is interchangeable for the first. This is important because in a refactoring scenario, the "primary" name for the type (eventually) changes.
Given that background, I support (3). The name of the type used in the struct definition should set the name of the embedded field.

Option 3 seems like the least surprising, most consistent interpretation. Embedding is defined in terms of both the embedded type and its name. When a type has multiple names, use the one that was used to do the actual embedding.
If there has to be a restriction for Go 1.8, option 1 seems a reasonable compromise that includes a lot of the other planned restrictions for free.
The options that disallow embedding in circumstances that can be outside your control are a no-go for me.

I agree with @mdempsky that all of 1.5/1.75/2 should be considered unsafe options. With any of [1.5,2], if I wanted to use an alias, I'd first need to deprecate using the aliased type embedded. It effectively doubles the refactoring-effort, because I now first need to find and fix all users of my code that use the type embedded(ly?).
1 seems, in that regard, safe; it may break use-cases, but it breaks them at the source, that is, the place  where an alias is introduced, instead of used. So, not all of the breakages described by @rsc are equal, IMHO. I agree that it would be unfortunate if aliases could not also be used to rename an exported thing, however, 1 would keep the door open to allow that later.
I also find 3 slightly confusing, but to me personally, that confusion does not outweigh the benefits of allowing all known/mentioned use cases. As others have pointed out, it's still logically consistent, it's just a stumbling block for beginners. I'd see it as similar to the nil-pointer in interface thing or that fields to be json-marshalled need to be exported; confusing when you don't know about it, but logically consistent and once it's explained the first time, it's easy to remember and internalize.

I'm in favor of (1):

(1.5) seems safe enough on its face, but it feels like a wart, and with @mdempsky I worry about discovering yet more consequences later. Struct embedding has long been a source of tricky language design and reflection problems.
I believe that (1) is enough to address the most pressing needs for aliases and it will buy us time and data.
The community has resisted aliases so vocally that moving carefully and slowly seems even more warranted than usual.
We are a few days into the freeze and we have just started exploring the impact of aliases on some end-user tooling (cmd/vet, go/doc, and godoc). As far as I know goimports, gorename, eg, and the plethora of third-party tools have not seen much testing. The restriction in (1) should reduce the number of unfound, subtle bugs in those tools.

One question about (1): Are there alias use cases in which it is critical that the package author have the ability to change from exported to unexported? Or an argument that those don't exist?
I personally find the =>-free form an intriguing suggestion, but Russ is probably right that it's not worth re-opening that discussion at this stage.

I think not allowing renaming alias makes aliases much less useful. Think
rsc's example of io.ByteBuffer and bytes.Buffer. Choosing good package
names to simplify exported names is so essential to idiomatic Go style that
I expect non-trivial amount of aliases be renaming.
Let's not forgetting the non-refactor use of aliases too (integration of
multiple internal pacakages into a API only top-level package, renaming
aliases would play a key role there.
Also, because I expect relaxing this restriction later will likely receive
similar resistance like the introducation of aliases received today
(because it makes alias abuses much worse, which is the main argument
against alias), I think if we make this restriction today, we will never be
able to remove it.

I don't understand what the type reflection information looks like for option 3.  Are we going to set Name to the alias, set Type to the imported type, and set Anonymous to true?  Note that that will require a change to the format of the reflection information currently being generated by the compiler, as it currently has no way to both provide a name and indicate that the type is embedded.

@jimmyfrasche, thank you for the observation that (1) constrains people writing alias statements and (2) constrains people using code that happens to use alias statements. That's an important distinction, and I think it's a good argument that (1) is preferable to both (1.5) and (2).

@ianlancetaylor I haven't looked at the reflection information yet. I have a pending CL for the necessary export data change (still missing tests besides my manual tests). It does contain an extra field name if the "name" of the anonymous field doesn't match the base type's name. I suspect something similar will need to be done for reflection info.

Rereading the thread, it looks like we're down to option 1 or option 3. It also seems the arguments for and against each hinge on what a type alias means.
Given a type alias in a package p, type T => q.S, everyone agrees that values of p.T and q.S should be able to be used interchangeably regardless of the name used.
The disagreement seems to be whether the name p.T is a "#define" (@rsc) or a "hard link" (@quentinmit).
In the #define interpretation it is as if instances of p.T are replaced by q.S in the text before compilation. They may be used interchangeably in the source but, in a sense, only the original name, q.S, is ever actually used.
The hard link interpretation is that p.T and q.S are two alternate names of the same named type. They are like two distinct but synonymous words.
Option 1 allows both interpretations to behave the same for embedding.
Option 3 uses the hard links interpretation.
Consider
package r
import "p"
type U struct {
    p.T
}

By the #define interpretation, the field name of the anonymous field is S. (This was option 4).
By the hard links interpretation, the field name of the anonymous field is T.
The #define interpretation has the same effect as options 1.5/1.75/2: it constrains people using code that happens to use the alias statement. They have to remember that even though they embedded p.T the field name is S.
One of the major use-cases for aliases is refactoring. Renaming aliases is an important part of that, as mentioned.
Under the #define interpretation, refactoring is inhibited when embedding is used.
Say the type U, defined above, is written while p.T is an alias of q.S and in the code it's accessed by its field name, S. After refactoring p.T is no longer an alias. Suddenly all code accessing S from U be fail to compile and have to be changed to T.
However, under the hard links interpretation nothing has to be changed: the field name is T regardless.
Even if this decision is delayed for now by going with option 1, I think the outcome will still have to be option 3 in the end.

The restriction that aliases can only reference names in a different package already restricts the renaming operations that can be performed. Under the original proposal you can rename p1.T1 => p2.T2, but not p1.T1 => p1.T2.
Extending this restriction to cross-package renames (option 1) doesn't seem onerous to me. If it is, then perhaps that's an argument against limiting aliases to names in different packages.

@neild You can still rename p.T=>p.U, it just requires extra steps and an extra temporary package during the transition.  For example:

Add package q with q.A=>p.T.
Refactor all uses of p.T to use q.A.
Atomically rename p.T to p.U, and change q.A's alias to q.A=>p.U.
Refactor all uses of q.A to use p.U.
Remove package q.

I'm in favour of option 3. The types are indistinguishable in all but name, but naming is precisely what aliasing is all about. It also fits with the existing embedding semantics of built in types such as byte and rune - to define these exactly as aliases would be a nice bonus (issue #17766 is indicative of the confusion in this area).

@neild

Extending this restriction to cross-package renames (option 1) doesn't seem onerous to me. If it is, then perhaps that's an argument against limiting aliases to names in different packages.

I would argue that it's the latter.
Option 3 seems best from a user perspective: it doesn't break things nearly as badly when moving an existing type out of a package, because you can drop in a forwarding alias and everything still basically works as expected.

FWIW (which isn't much :), I'm strongly in favor of an approach which allows byte and rune to be defined as aliases. It's just simpler.

"An alias can never be lower case" seems to solve the problem and is consistent with the fact that aliasing is about forwarding the exposed object definitions of a package, I think.
Along with the fact that an unexported object should not be aliasable.
Renaming feels quite important in order to avoid naming conflicts and  as a way to create parametrized packages (aliases as a kind of naming indirection allows to switch type definitions quite more easily).
Options 4 still makes the most sense to me (aliases should be almost (*) completely transparent at runtime since it is a compile-time mechanism and aliasing has no incidence on type identity, by definition).
Concerning error messages, I guess that the line numbers will help disentangle any discrepancy between alias vs. original name.
( * ) Ideally, there should be local package information when an object is aliased and part of an error message.

Locking because aliases are no longer proposed.


Filter broken

The background filter at the top of the page is not working. Its spitting out the following error:
Uncaught TypeError: Cannot read property 'value' of undefined     at main.js:formatted:14056
-Vinnie

Fixed


Add default startup and automatic configuration

Right now i run each separate command, would like to have a .sh added to startup with all the following commands:
# 1
discord --start-minimized
# 2
slack -u
# 3
telegram-desktop -startintray
# 4 - couldn't figure it out how to start this one minimized
upwork

Such commands should be automatically configured in ubuntu startup using new_system.sh, and parhaps other .sh file to just store this commands.

Right now I configured using this "startup applications" manually, would like to not be necessary to use this window for such configuration, just plain .sh


"unable to validate against any pod security policy: []" when injecting to the non-default namespace

Hello, I have followed the tutorial and managed to deploy and run an injected pod.
However, when I run the same deployment definition in a different namespace, it is unable to start the pod.
I have labeled the new namespace as instructed.
Are there any additional steps needed in order to inject pods in another namespace?

Sorry for late response.
I have added some troubleshooting steps here: https://github.com/morvencao/kube-mutating-webhook-tutorial#troubleshooting
Please check if that helps.

It's more likely that your issue is caused by permission issue.
Please try the latest code, I have made some updated for docker image to make it run as non-root user.


Support WAM with MSA account

Context:
Azure PowerShell supports signing in by WAM (web account manager) on top of the Azure.Identity library. However, as it does not support enabling the MSAPassthrough option which MSAL (Microsoft authentication library) provides, we can’t sign in MSA accounts. This blocks a lot of users from the integrated experience of signing in with Windows.
See proposed .NET implementation at https://github.com/Azure/azure-sdk-for-net/pull/31227.

Blocked on https://github.com/AzureAD/microsoft-authentication-library-for-go/issues/243

Tagging as Discuss in Office Hours as the design was brought up for discussion during standup Monday

@scottaddie is going to reach out to the PSH team to see if moving this from the public surface area to an environment variable would work for their scenario.


Adding social proof

Awaiting on finalized quotes

https://app.clubhouse.io/featurepeek/story/3581/display-social-proof-on-landing-and-pricing-pages


Need password prompt option to avoid plain text VSphere passwords in config.json

I would like to a way to avoid saving plain text VSphere passwords in the config.json file.
Currently, supplying a password via VSPHERE_PASSWORD at machine creation results in the password being saved as plain text in the config.json file for that machine. Of course, a password is needed for the create operation, and I should be able to supply it via a command line option or an environment variable, but I should have the ability to avoid saving it in config.json. Subsequent operations should be possible even if the password is not in config.json, as long as the command line option or corresponding environment variable is set. Alternatively, the docker-machine command could prompt for the password when needed, if it's not in config.json and not supplied via command line or environment variable.
Plain text passwords saved on disk violate security policies in my organization.
This may be applicable to other drivers as well.

Also, we need a method that avoids putting the password in either environment variables or on the command line, since those are visible to other users on the system.

same with openstack drivers. username and password in plain text along with a copy of server key and certificate.


ENH add metric frame

Closes #278

@BenjaminBossan I feel I should write a test for this, but I'm unsure where it should go. I was thinking of skops/card/tests/test_card.py inside the TestTableSection class. Thoughts? Is there somewhere else it would be better?

@lazarust I see that there are some black issues. If you set up your dev environment with pre-commit hooks as described here, they should be caught before committing.

@BenjaminBossan Thanks for the tip! Sorry, I missed that from the Contribution Guide. I'm currently working on making the tests. I'll ping you whenever it's ready again!

@BenjaminBossan This is ready for you to take a look at!

@BenjaminBossan Thanks for the review! I haven't looked at your code comments yet since the decision of whether to pass in the parameters or a MetricFrame affects a lot of it.

Of course, we could add more parameters to the signature of add_fairlearn_metric_frame, but it only gets bigger and bigger that way, and we have to keep it up to date when fairlearn changes.

I agree! I was thinking of that while writing the method but was unsure if that was something we wanted to do.
I do wonder if we require users to install and import fairlearn on their own if this feature just won't be known/used as much. I could be completely off base on that, but it is a thought I have. We could add an example of using this or just add it to the existing examples.
Beyond that, I don't really see too many disadvantages that would outway the advantages.  What're your thoughts?

I do wonder if we require users to install and import fairlearn on their own if this feature just won't be known/used as much.

We would do that anyway, fairlearn would not be installed by default when installing skops. And even if it were, users don't just discover and try out random packages that were installed :)

We could add an example of using this or just add it to the existing examples.

This + documenting it well are definitely the way to go for users to discover and use the feature.

Beyond that, I don't really see too many disadvantages that would outway the advantages. What're your thoughts?

Great, I think we agree then.

@BenjaminBossan Thanks for explaining this! I think I've addressed/responded to most of your comments.
I still need to handle scalars from the MetricFrame and update the doc string.

Great, thanks, please ping Adrin and me once it's ready for review.

@BenjaminBossan and @adrinjalali This is ready to review again!!

I think the transpose feature could be implemented without pandas, but it's not a big deal, most users will probably have pandas installed anyway.

fairlearn depends on pandas anyway.

fairlearn depends on pandas anyway.

I didn't even think about that, then forget what I said :)

@adrinjalali and @BenjaminBossan Thanks for reviewing this! I've addressed all the comments except for one I needed clarification on.

@BenjaminBossan I've addressed your comment! Sorry, it took me a couple of days to get to this.


request error

blobfile: error message=request failed with exception HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Read timed out. (read timeout=10), request=, status=0, error=None, error_description=None, error_headers=None when executing http request  attempt 1, sleeping for 0.1 seconds before retrying
how to solve it?

blobfile: error message=request failed with exception HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Read timed out. (read timeout=10), request=, status=0, error=None, error_description=None, error_headers=None when executing http request attempt 1, sleeping for 0.1 seconds before retrying
how to solve it?

I encountered the same problem, did you solve it? @floodsung

I've removed the use of blobfile for accessing public files in tiktoken 0.1.2. This should make your error go away.


Add esPass MIME type

same as with https://github.com/k9mail/k-9/pull/1358 - but for esPass

You can't just make up media types. They have to be registered with IANA: http://www.iana.org/assignments/media-types/media-types.xhtml
See also: https://en.wikipedia.org/wiki/Media_type

apple did the same - you have a lot of stuff in the list that is not registred

They are using the vendor tree.

OK - I submitted a request for registration - follow up here: https://github.com/esPass/tasks/issues/1 - but as far as I was reading a registration is not really needed when using vendor-prefix. Would you merge a PR for application/vnd.espass-espass without registration?

espass is now a registered mime-type. In the process it changed to vnd.espass-espass+zip:
http://www.iana.org/assignments/media-types/application/vnd.espass-espass+zip


Get some specific fields of preload, not all

Your Question

I have a 2 tables: user and order, order belong an user.
User {
  ID uint
  Name string
  ...
}

Order {
  ID uint
  UserID uint
  User User
}

How can I get order with only user's name?
I use following code to do this but it get all fields of user
DB.
  Model(&Order{}).
  Preload("User").
  First(&order, "id = ?", orderId).Error

The document you expected this should be explained

I can't find any doc to solve this problem.
Expected answer

a command to get order with some specific fields of preloads.

can someone give example if this is possible I want do the same?


Potential memory leak

Has anyone seen a heap dump similar to the image below? Not yet certain its related to this package, but it seems like our exception logs are causing a large number of other objects to be held in memory.

I'm a bit confused. Aren't you saying that if the GC ran, it would clear all the objects out of memory?  If that's the case wouldn't that imply there isn't a leak and just that you have enough available memory in your system that a GC isn't running automatically and when it would the leak would be gone?

Could you also post your express-winston (and winston if applicable) configuration?
If you're using a "msg" option that is a function that returns a string with mustache interpolations then the app can grow in memory usage extremely quickly as it has to compile the template with every request.
https://github.com/bithavoc/express-winston/blob/master/index.js#L160


Add a retry on some tasks

Really often, we have this issues on our CI/CD process on Github actions:
* What went wrong:
Execution failed for task ':ui-ee:installNode'.
> org.siouan.frontendgradleplugin.domain.installer.RetryableResourceDownloadException: org.apache.hc.core5.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 44566491; received: 9958471)

Is it possible to add a default retry for this exception please?

Hi @tchiotludo,
Thank you for your feedback.
To ease understanding and troubleshooting, there's a template that must be filled to report a bug. This is a mandatory step before considering your issue.
Anyway, starting from release 8.0.0, the plugin provides a configurable retry mechanism (see properties maxDownloadAttempts, retry... here). Let me know if this helps.
If you think there's really a bug, please provide information missing using the provided template. I'll be glad to help. Thank you!
BR

Hey @v1nc3n4,
Thanks for the prompt response, sorry for the lack of template, since it's was a feature request (and not a bug), I don't think about use it. I have updated the issue with the template.
I was not aware of this change of latest version with retry on some http status, I'm not sure this one will work since there is not http status on this exception.
But I discovered this options maxDownloadAttempts that should do the job, I will try.
Thanks a lot for pointing this.

I think the retry mechanism should work in your case, because it deals with connectivity issues (and your seems to be one) as well as some HTTP error response. If you want to be sure that the retry works as expected with this exception, just set maxDownloadAttempt to a number higher than 1, and enable verbose mode (see verboseModeEnabled property). You should see a message for each download attempt in Gradle log.
Let me know the result 😀.

😄 Enabling verbose mode is the only way to see the issue in the log file and one or more retry attempts. Verbosity applies to the plugin only, not to Gradle.
For example, here's what log should look like:
>gradlew installNode

> Task :installNode
[installNode] Removing install directory '<project-directory>\node'
[installNode] Downloading distribution at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip'
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 1 of 3: java.net.UnknownHostException: unknown.domain
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 2 of 3: java.net.UnknownHostException: unknown.domain
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 3 of 3: java.net.UnknownHostException: unknown.domain

> Task :installNode FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':installNode'.
> org.siouan.frontendgradleplugin.domain.installer.RetryableResourceDownloadException: java.net.UnknownHostException: unknown.domain

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 15s
1 actionable task: 1 executed

As it appeared to be a problem of configuration, I close the issue now. Feel free to reopen it you think there's a bug with the plugin's retry feature.

@v1nc3n4 I didn't notice the errors any more, thanks for your help.
Just a suggestion, increase the default value to 3 for example, if I have the issues, I think other people could have.

That was discussed here when the feature was designed, and a value of 1 was chosen for backward compatibility and to minimize risk with existing configurations because implementation appeared significant. That may be changed in the future however. Thank you for your suggestion.


c# basics

link few minimal constructors and method as basics for c#
long term plan is to have the documentation generated automatically from the .dll
Facade architecture would help in getting a clean documentation

Not doing it.
User will need to learn from the examples for the time being


Add a readme for Bunny nose filter

https://github.com/akshitagupta15june/Face-X/tree/master/Snapchat_Filters/Bunny_Nose

hey @akshitagupta15june  Can I work on this Issue , Please let me know

Thank you so much 👍


Reorganize terraform deployment scripts.

Extract common module for API gateway boilerplate (upstream terraform module contains support for API Gateway v2 which doesn't support X-Ray, and not v1 which does...)

Separate sample app module and integration test module

sample app module for reference by end user of public layer and for use in canary tests
integration test module for testing during development and for use in integration tests

Remove provider.tf to allow setting region

Going to go ahead and merge to unblock followup, happy to address anything as followup


add timeout logic in channel synchronize interface

Codecov Report

Merging #49 into dev will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##                dev      #49      +/-   ##
============================================
- Coverage     14.32%   14.32%   -0.01%
  Complexity      592      592
============================================
  Files           387      387
  Lines         11782    11785       +3
  Branches       1417     1417
============================================
  Hits           1688     1688
- Misses         9901     9904       +3
  Partials        193      193

Impacted Files
Coverage Δ
Complexity Δ

.../main/java/org/fisco/bcos/sdk/channel/Channel.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...in/java/org/fisco/bcos/sdk/channel/ChannelImp.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

Continue to review full report at Codecov.

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


Future development version roadmap

v0.3.0 - Add support for the LST correction

In progress in the main branch.  Code references the soil emissivity collection, so this will need to be updated/fixed for openet-core v0.1.1.

v0.4.0 - Clean out old or unused code, especially in the Tcorr options

v0.5.0 - Add full support for global calculations

Add support for using other datasets for the conversion from alfalfa to grass.  Right now this is hardcoded to NLDAS.  Not sure if this should be a separate version or maybe wrapped into the global support.

As of 19-Sep 2023,  phased deprecation items for consideration:

[ ] Removing old scene-based precomputed and dynamic Tcorr calibration functions
[ ] Removing support of Landsat Collection 1 TOA image collections (ended 2022-01-01).
[ ] Removing associated unit tests to above items
[ ] Other depreciated content - TBD

I started a new "v0p4_deprecation" branch.  I'm not sure the best way to flag the various parameters and methods as deprecated, but I went with the warnings module for now unless someone knows the "right" (or better) way to do this.
The DeprecationWarning is suppressed by default for most of our use cases (jupyter notebooks, importing as a module), so I used FutureWarning for now so that the messages would show in jupyter.  I'm not sure if this is good or bad, but just a heads up that is why that is in there.
Should support for the "DYNAMIC" tcorr source be deprecated?  It seems like you are saying that above, but wanted to double check.  I kind of like the idea of keeping it since that was the original approach in so many of the papers, but it would probably require having and maintaining the tcorr climatology image collections.
Should support for computing dT dynamically using the "CIMIS", "GRIDMET", and "DAYMET" keywords be deprecated?  I set the precomputed "DAYMET_MEDIAN_V0", "DAYMET_MEDIAN_V1", and "DAYMET_MEDIAN_V2" keywords as deprecated, so it might make sense to remove all of the keywords based options and only support reading precomputed assets set with a full image collection ID.
Should support for the tmax_source keywords be deprecated?  These include CIMIS, GRIDMET, DAYMET_V3, DAYMET_V4 and a couple of MEDIAN options.  I think we should deprecate them all but want to double check.

The Deprecation/Future Warning seems like a reasonable approach.
Regarding support for tcorr keywords, dT keywords, and tmax keywords - please deprecate all of those as suggested. I reviewed these options with the model PI and he is in agreement that each of those could be historically accessed/recreated using the archived (versioned) code releases.

Initial code cleanup and deprecation is being applied in v0.4.0 (#57) and further discussion of global support will be made in a separate issue (#58).


Update the GainPlugin example parameter throttling

This commit introduces a safer way of broadcasting parameter value updates to the javascript engine.
The way it was previously written, we had the juce::MessageManager::callAsync call in the parameter change callback. Although in practice that's not a huge deal, it is technically non-deterministic, and is running way frequently on the realtime thread when a parameter is actually changing.
The way I had been planning to rewrite this involved the ThrottleMap abstraction, but actually this also isn't a great solution for the realtime thread because of the syscall to collect the current time and the allocation upon inserting into the std::map.
This new way that I'm showing here I think is the safest and most efficient, and width this I'll propose that we remove the ThrottleMap altogether.

Looks totally sane to me Nick. Good to avoid any potential locking here

:+1: awesome, thanks for the look over!


Add templates to MQTT climate

Description:
This replaces #11347. The primary use case I have in mind is still the same as over there:

This targets a (probably pretty common) use case of using the MQTT thermostat with another HA instance on the other side, and using mqtt_statestream for the *_STATE channels. Since #9872 , the values set from the "master" HA instance will be echoed in a quoted form on the state channels by the "slave" HA instance, causing errors. There is currently no easy way of circumventing this.

However, providing the possibility to parse payloads via a template is definitely less hacky. I added the possibility to apply one template to all state topics (via value_template) as well as setting individual templates per state topic.
Related issue (if applicable): fixes parts of #10209
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#4407
Example entry for configuration.yaml (if applicable):
climate:
  - platform: mqtt
    name: Study
    modes:
      - off
      - on
      - auto
    mode_command_topic: "study/ac/mode/set"
    mode_state_topic: "study/ac/mode/state"
    mode_state_template: "{{ value_json }}"

Checklist:

[x] The code change is tested and works locally.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

Can templates be added/applied to temperature_command_topic as well?  Setpoint needs to be multiplied by 100 for my MQTT HVAC.  Then read temperature needs to be divided by 100 which the above template addition should take care of that.
Thanks,
IceStuff


Bump premonition version so that it works also on columns different t…

Bumps admonition version to support them not being on first column

/lgtm
/approve


Thumb jumping when touching/clicking

Hi,
I've noticed an issue with your control.
The thumb image and the value of the slide seem to instantly jump a bit to the left or right, when the thumb is touched. The amount of the jump seems to correlate with the current position of the thumb, i.e. when the thumb is all the way to the left it will jump a bit to the right when touched, when it's on the right side it will jump a bit to the left and in the middle it won't jump at all.
Here is a video demo: https://www.youtube.com/watch?v=RNT5UazGWQA

Thanks for the report. I’m inclined to close this issue because the UISlider in the demo app behaves in exactly the same way so it doesn’t seem to be related to my code. Can you confirm that?

Well that's weird. I never noticed this behavior of UISlider. You're right.


Dataset used in LongLLM_QLORA

Hi:
I wonder what's the base/source dataset used to create the following dataset

bio_book
one_details_book
multi_details_book
multi_details_paper_long
one_detail_paper_long

Thanks!
Best,
Mingyi

Hi,

All books are from books3 subset of the Pile.
All papers are from arxiv subset of the Pile.


one more issue

simple issue

this is another comment

this is another new comment

try some comment

one more comment


Remove snappy

cdm_reader_mapper fails to install using pip - difference in snappy packages between conda and pip.
See #33

@jtsiddons: Many thanks.
Could you now install and run cdm_reader_mapper on your local machine? If so I could merge the PR.

Installs on python 3.12.3. Output of pytest:
~/P/cdm_glamod/ [remove_snappy*] $: pytest tests
========================================================================================================= test session starts =========================================================================================================
platform darwin -- Python 3.12.3, pytest-8.2.0, pluggy-1.5.0
rootdir: /Users/josidd/Projects/cdm_glamod
configfile: pyproject.toml
collected 39 items

tests/test_cdm.py .........................                                                                                [ 64%]
tests/test_glamod_tables.py .                                                                                [ 66%]
tests/test_operations.py .............                                                                                [100%]

========================================================================================================== warnings summary ===========================================================================================================
tests/test_cdm.py: 23 warnings
  /Users/josidd/Projects/cdm_glamod/cdm_reader_mapper/cdm_mapper/mappings.py:222: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
    return datetime.datetime.utcnow()

tests/test_cdm.py: 22 warnings
  /Users/josidd/Projects/cdm_glamod/cdm_reader_mapper/cdm_mapper/mappings.py:364: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
    strf = datetime.datetime.utcnow().strftime("%Y-%m-%d %H:%M:%S")

tests/test_cdm.py::test_read_craid_1260810
  <frozen importlib._bootstrap>:488: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility. Expected 16 from C header, got 96 from PyObject

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
============================================================================================= 39 passed, 46 warnings in 186.51s (0:03:06) =============================================================================================


Allow users to define custom properties that can be brought in by Meltano

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1755
Originally created by @bencodezen on 2020-02-18 14:37:31

User has non-standard properties in Salesforce that they would like to bring into Meltano.
Is the best path forward to write a custom transformation for their instance?
Long term solution may be to provide a UI that allows users to do this on their own.
cc @iroussos

View 2 previous comments from the original issue on GitLab


Does it automatically schedule pickups?

I want to ensure we have control over what pickups are scheduled and when. Does this plugin automatically create the pick-ups with couriers or are they created manually only? I don't see any options for this in the settings.

You control the printing of the label and the pickup scheduling from the order management. You can re-quote and/or choose another carrier from there and set few pickup settings like insurance, signature, reference, etc...

Thank you. I saw in the options it had settings regarding pick ups so I wanted to be sure but was unable to test it on the environment it's installed in. Much appreciated.


Beta1

Updated dependencies and resolved some issues with file watching, browsersync, and publicPath.

#1794, #1790, #1789 should be good now but require documentation


use EKS Go relese version from the release trigger files if not speci…

…fied
Issue #, if available:
Description of changes:
Allow us to specify a specific EKS Go release version when installing EKS Go on the builder base.
If no release version is specified via the second argument to build::go::install, fetch the release number for the given Go version from the release trigger file in the repository.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

talked to Jackson; we're going to take a slightly different approach here, and also wait till https://github.com/aws/eks-distro-build-tooling/pull/555 merges to work ont his.

I think we can close this, we now have the tank file in place to define the go versions


How to set the first load header range: bytes = 0-0

Hello
I have an idea to set the first request header range: bytes = 0-0, not bytes = 0-
I searched for problems, but I didn't find any existing problems!
How can I achieve it? Or whether corresponding properties can be added.

I don't want to load the whole video at the beginning, I want to be the proxy

I tested bytes=0-0, but the next request is still ”bytes=1-“ Loading the whole video stream is too much！
set $range $http_range;
if ($http_range = "bytes=0-") {
set $range "bytes=0-0";
}
proxy_set_header range $range;
How can plyr specify a range for each request？


No way to see comments when video is opened with direct url

First of all sorry for this continous reporting of issues but I have to report another one. After discovering your app (gtk-youtube-viewer) I ditched  opening youtube in browser because this is more efficent and fast.
When I open a youtube video directly using a link such as this https://www.youtube.com/watch?v=uQBmkvY3P3Q I am not able to load or see comments? This is my suggestion to the problem when we load a video directly from a link; this link's details (thumbnail, title,info) should also populate in the list window while playing the video.

@trizen Is there a solution for my above problem? I really want to view comment in the gui. I also want to report this some times youtube playlist wont load in gtk-youtube-viewer https://www.youtube.com/watch?v=ktvTqknDobU&list=PLkgWEYvTsgqHO6vTqQEqWxBlW_6ykRmYz


We lost the LV3 assembly?

LV3 SolidWorks assembly only includes the CubeCradel.

That was intended, There are a couple things missing that are required for the whole assembly that I am working on. As it stands it would be a bunch of loose assemblies right now.


Add Version constant

Codecov Report

Merging #118 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #118   +/-   ##
=======================================
  Coverage   96.22%   96.22%
=======================================
  Files          22       22
  Lines        1431     1431
=======================================
  Hits         1377     1377
  Misses         37       37
  Partials       17       17

Continue to review full report at Codecov.

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


[23.1] jfrPerfTest fails with experimental VM warning

The test fails with:
 Error:  Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,247.701 s <<< FAILURE! - in org.graalvm.tests.integration.JFRTest
Error:  jfrPerfTest{TestInfo}  Time elapsed: 988.065 s  <<< FAILURE!
org.opentest4j.AssertionFailedError:
build-and-run.log log should not contain error or warning lines that are not whitelisted. See /home/runner/work/mandrel/mandrel/mandrel-integration-tests/testsuite/target/archived-logs/org.graalvm.tests.integration.JFRTest/jfrPerfTest/build-and-run.log and check these offending lines:
Warning: The option '-H:+SignalHandlerBasedExecutionSampler' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/io.netty/netty-transport/reflection-config.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue. ==> expected: <true> but was: <false>
	at org.graalvm.tests.integration.JFRTest.jfrPerfTestRun(JFRTest.java:210)
	at org.graalvm.tests.integration.JFRTest.jfrPerfTest(JFRTest.java:176)

The -H:+SignalHandlerBasedExecutionSampler needs to get unlocked. netty issue is https://github.com/netty/netty/pull/13596

Re-opening as we still need to deal with:
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/io.netty/netty-transport/reflection-config.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.

Re-opening as we still need to deal with:
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/io.netty/netty-transport/reflection-config.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.

Dealt with in https://github.com/Karm/mandrel-integration-tests/pull/203