Revert to the original default behavior of dtype in Loss and Metric

There is a regression after #19937 where, when users set a global dtype policy such as "mixed_float16" or "mixed_bfloat16", the dtype is wrongly set in Loss and Metric.
It should follow keras.config.floatx() as the docstrings state.

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

Project coverage is 57.47%. Comparing base (dfc4f78) to head (d772339).

:exclamation:  There is a different number of reports uploaded between BASE (dfc4f78) and HEAD (d772339). Click for more details.
HEAD has 6 uploads less than BASE

Flag
BASE (dfc4f78)
HEAD (d772339)

keras
4
1

keras-torch
1
0

keras-tensorflow
1
0

keras-jax
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #20014       +/-   ##
===========================================
- Coverage   79.25%   57.47%   -21.78%
===========================================
  Files         500      500
  Lines       46884    46884
  Branches     8651     8651
===========================================
- Hits        37156    26947    -10209
- Misses       7977    18258    +10281
+ Partials     1751     1679       -72

Flag
Coverage Δ

keras
57.47% <100.00%> (-21.63%)
:arrow_down:

keras-jax
?

keras-numpy
57.47% <100.00%> (ø)

keras-tensorflow
?

keras-torch
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Don't fire timer in the middle of another event and take one timer at a time

While debugging issues in aquarium, I changed these behaviors of behn.  With these changes, I think it's now true that we fire no more than one timer in an event, and only if this is a %wake event straight from unix.  This should make it much easier to reason about behn's behavior.
There was never any good reason to fire a timer while setting another timer, right?  I think I was running into a situation where I'd have one thing set a timer for now to try to wait for the next event, and then another would do the same thing in the same event, which would fire the first in the same event.
It's super weird, btw, that we (flop moves) in several places rather than once in a ++abet-style function.  I think the flops are right, but I really can't tell.

you could have a "bonus priority moves" variable, that you flop in
parallel with the normal moves, but then weld onto their head
On Sat, Feb 9, 2019 at 1:39 PM Ted Blackman<EMAIL_ADDRESS>wrote:

@belisarius222 approved this pull request.
LGTM.
We can't flop all the moves because we must emit the %doze out to Unix
before moves that notify other vanes about timer expirations. When the
other vane receives a notification that its timer has expired, it might
send a request to Behn to set a new timer, which in turn could cause Behn
to adjust its wakeup timer by emitting a second %doze move out to Unix.
It's crucial that Vere receive the %doze moves in the correct order. If
we flop all the moves after running +set-wake, the second %doze move can
get emitted first.
It might be clearer to modify +notify-clients to flop its moves in a =-
at the top of the arm ... but actually, aren't we now limited to emitting a
single notification per Arvo event? No point in flopping a single move --
although that deserves a comment explaining the behavior.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/1064#pullrequestreview-201879357, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhkOV0sdtHJfpO_tDuEqiZJKgZIYvks5vL0AngaJpZM4ayWpp
.

Seems like the way to handle that would have been to just swap the two =. lines in ++wait.  Isn't that semantically exactly what we wanted to do?
It's my opinion that it's virtually always clearer to reframe (quip moves _this) as _this with a moves state entry.  Then you just make sure to just add stuff on to the front in the order you want it executed, and flop it all at once at the end.
For example, see moves, ++abet-pe, ++abet-aqua, and ++apex-aqua here and how they make things like ++turn-plow much cleaner than it would be if it had to juggle these moves explicitly (like it did in an earlier version).
https://github.com/urbit/arvo/blob/1a87a5c9fad7c96a45ee051eed4f962aa895d4af/app/aqua.hoon#L53

I'm guessing that doesn't work because ++notify-clients conflates "pop next timer if any" and "actually notify its subscribers", which want to happen before and after set-wake respectively?
(also I'm probably missing something, but is there a reason it only grabs 1 timer?)

@philipcmonk That's a good idea in theory, but the way it's written right now, we don't know when the %doze should be set to until we've popped the first timer off the queue. We could rewrite that to calculate both things during one function if we want to maintain a stack discipline for the moves. I suspect that would make the logic harder to follow, though, since it would need to blend +set-wake and +notify-client into one more complex function.
Come to think of it, Behn should be even dumber:

+notify-clients should be renamed to +notify-client, and it should error out if our timer queue is empty, or if its first element is in the future compared to now. It should unconditionally produce a single %wake move to a client.
+born should just emit the %doze and exit. That way the timer firing will happen in a new event, which is important for transaction isolation. This also means +notify-client only needs to be called from +wake, so maybe it should be inlined.

+set-wake is very similar to +abet, so maybe it should be called with a =<  set-wake at the beginning of relevant arms to make that clearer. Again, we don't actually need to flop moves anymore because of the new one-timer-notification-per-Arvo-event semantics.

@ohAitch We want each timer firing to happen in its own Arvo event so that downstream processing can fail separately. It's a way to isolate transactions from each other.

Okay, yeah, then "time to set the new timer" seems like another piece of global state that would get updated throughout the call, and then the ++abet would make the actual %doze at the right end of the list.  Similar to unix-effects in aquarium.
In this case, though, I agree with "Behn should be even dumber".  Every call to Behn should produce either nothing, one %doze, or one %wake and one %doze.

Ah, that makes sense yeah
The unix semantics issue mostly suggests a return to ++doze - at least, in some limited sense, where behn sends an idempotent [%doze ~] which signals "at the end of this event, scry behn to figure out when the next timer actually is". I guess we might want a more general pattern that addresses identical issues coming up in userspace for subscription delivery?

::  /sys/vane/behn
|_  [tym=(list [p=@da q=duct]) hen now etc]
++  wait
  |=  wen=@da
  =<  :_(tym [unix %doze ?~(tym ~ `p.i.tym)]~)
  |-  ^+  tym
  ?~  tym  [wen hen]~
  ?:  (lte wen p.i.tym)  [[wen hen] tym]~
  [i.tym $(tym t.tym)]
::
++  rest
  |=  wen=@da
  =<  :_(tym [unix %doze ?~(tym ~ `p.i.tym)]~)
  tym=(skip tym |=(a=[@da duct] =(a [wen hen])))
::
++  wake
  |=  ~
  =^  wak  tym
    |-  ^-  [wak=(list duct) tym=_tym]
    ?~  tym  [~ ~]
    ?:  (gth p.i.tym now) [~ tym]
    [[i wak] tym]:[i=q.i.tym $(tym t.tym)]
  ::
  :-  :-  [unix %doze ?~(tym ~ `p.i.tym)]
      (turn wak |=(a=duct [a %wake ~]))
  tym
--

kind of thing?
"scry-doze" variant that addresses the issue at hand
::  /sys/vane/behn
|_  [tym=(list [p=@da q=duct]) hen now etc]
++  scry-doze  ?~(tym ~ `p.i.tym)
++  wait
  |=  wen=@da
  :-  [unix %doze /bx/doze]~
  |-  ^+  tym
  ?~  tym  [wen hen]~
  ?:  (lte wen p.i.tym)  [[wen hen] tym]~
  [i.tym $(tym t.tym)]
::
++  rest
  |=  wen=@da
  :-  [unix %doze /bx/doze]~
  (skip tym |=(a=[@da duct] =(a [wen hen])))
::
++  wake
  |=  ~
  =^  wak  tym
    |-  ^-  [wak=(list duct) tym=_tym]
    ?~  tym  [~ ~]
    ?:  (gth p.i.tym now) [~ tym]
    [[i wak] tym]:[i=q.i.tym $(tym t.tym)]
  ::
  :-  :-  [unix %doze /bx/doze]
      (turn wak |=(a=duct [a %wake ~]))
  tym
--

…wait okay is there anything the current 240-line implementation is doing that this isn't? Documentation presumably, I guess "space" "grade" coding conventions have really hit the codebase that hard DX

I stand corrected, the behn is only 1/3 comments by weight! Like I guess you need to elaborate the above to the actual arvo interfaces, that's not like, more than a couple lines per arm though 🤔
(also %wegh and diagnostic scry and stuff, still doesn't super add up)

As an exercise in readability reduction:
::
::::  /sys/vane/behn
  ::
  ::  %timer vane
::
|_  [current-timers=(list [set-to=@da for=duct]) unix=duct event=duct now=time]
++  wait
  |=  until=@da  ^-  [(list move) _current-timers]
  =<  :_  current-timers
      ::  fire next timer
      ::
      [unix %doze set-to:(snag 0 current-timers)]~
  |-  ^+  current-timers
  ::  base case: there are no further timers
  ::
  ?~  current-timers
    ::  insert at end of list
    ::
    [until event]~
  ::  terminal case: all other timers are further in the future
  ::
  ?:  (lte until set-to.i.current-timers)
    ::  insert at current position
    ::
    [[until event] current-timers]~
  ::  recursion case: advance past timer earlier than the one being inserted
  ::
  [i.current-timers $(current-timers t.current-timers)]
::
++  rest
  |=  which=@da  ^-  [(list move) _current-timers]
  =<  :_  current-timers
      ::  fire next timer, or clear if none are left
      ::
      [unix %doze ?~(current-timers ~ `set-to.i.current-timers)]~
  ^=  current-timers=_current-timers
  ::  remove the timer whose removal is being requested
  ::
  %+  skip  current-timers
  |=(timer=[@da duct] =(timer [which event]))
::
++  wake
  |=  ~
  =^  wake-subscribers  current-timers
    ::  separate out subscribers in past from timers that remain in the future
    ::
    |-  ^-  [wake-subscribers=(list duct) current-timers=_current-timers]
    ::  base case: no timers to wake
    ::
    ?~  current-timers
      [wake-subscribers=~ current-timers=~]
    ::  terminal case: hit first future timer
    ::
    ?:  (gth set-to.i.current-timers now)
      [wake-subscribers=~ current-timers=current-timers]
    ::  recursion case: get remaining past timers, and add current to that list
    =/  [wake-subscribers=(list duct) rest-timers=_current-timers]
      $(current-timers t.current-timers)]
    :-  wake-subscribers=:_(wake-subscribers for.i.current-timers)
    rest-timers
  ::  set remaining timer, and wake desired wakes
  ::
  :-  :-  ::  fire next timer, or clear if none are left
          ::
          [unix %doze ?~(current-timers ~ `set-to.i.current-timers)]
      ::  notify subscribers
      ::
      (turn wake-subscribers |=(a=duct [a %wake ~]))
  ::  update timer list
  ::
  current-timers
--

(I guess I probably should also have used skim and skip in ++wake)

(oh sorry missed the
::  $current-timers: (list [@da duct]), list of current timer ducts and when they should fire
::  $unix: duct, duct for sending timers to unix
::  $event: duct, duct for the current event
::  $now: time, time right now
::  $until: time, how long should this timer +wait
::  $which: time, which timer for this duct should be laid to +rest
::  $wake-subscribers: (list duct), which subscribers we are deciding to +wake

)

Hell needs to watch out for snowballs!
Sent from my iPhone

On Feb 9, 2019, at 3:36 PM, Anton Dyudin<EMAIL_ADDRESS>wrote:
(oh sorry missed the
::  $current-timers: (list [@da duct]), list of current timer ducts and when they should fire
::  $unix: duct, duct for sending timers to unix
::  $event: duct, duct for the current event
::  $now: time, time right now
::  $until: time, how long should this timer +wait
::  $which: time, which timer for this duct should be laid to +rest
::  $wake-subscribers: (list duct), which subscribers we are deciding to +wake
)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


b5-rosecurrency-client-commands

Baker ID, account address, transaction ID of the transaction used to register as a baker, blockhash of at least one block you produced, transaction ID of the transaction that changes the reward account transaction ID of the transaction that updated baker's keys and observations are at ea28501
Screenshot for client registration command is at 5b2582e

confirmed:B5
address:3myvqokyzc8EkehYrK2FcopkC5L3omGU15F5DQUD6m3EGDHaAK

confirmed:B5
address:3myvqokyzc8EkehYrK2FcopkC5L3omGU15F5DQUD6m3EGDHaAK


Updated elgohr/Publish-Docker-Github-Action to a supported version (v5)

elgohr/Publish-Docker-Github-Action@master is not supported anymore

Hello @elgohr , please point your PR to ytti/oxidized. This is just my personal fork :)


Vanilla Armour Stand is bugged while running mod.

1.12.2
Forge <IP_ADDRESS>54
Latest release of VS mods.
 'Vibrates' when placed facing North.
No other mods running.

newer forge seems to have more problems than this, did you try it on lower versions forge? the forge version for vs is <IP_ADDRESS>47


[WIP] recordMarketShareTokens does not return bool

WIP until I get the ABI updated. Taking longer than I expected because I need to install a newer solc.

No ABI change. I assume because it's a private function.


Help page

This requires https://github.com/Code4SA/wazimap/pull/75.
I would value some input on the general layout, copy and the icon in the header.
@longhotsummer

@longhotsummer
I've moved the styles to wazimap_za.css, as we need them across all instances.

LGTM.


fixed typo: CONTINOUS

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
57
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1377
trunk passed

+1
compile
1324
trunk passed

+1
checkstyle
54
trunk passed

+1
mvnsite
93
trunk passed

+1
shadedclient
942
branch has no errors when building and testing our client artifacts.

+1
javadoc
86
trunk passed

0
spotbugs
155
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
153
trunk passed

_ Patch Compile Tests _

+1
mvninstall
58
the patch passed

+1
compile
1299
the patch passed

+1
javac
1298
the patch passed

+1
checkstyle
53
the patch passed

+1
mvnsite
95
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
871
patch has no errors when building and testing our client artifacts.

+1
javadoc
78
the patch passed

+1
findbugs
146
the patch passed

_ Other Tests _

+1
unit
605
hadoop-common in the patch passed.

+1
asflicense
55
The patch does not generate ASF License warnings.

7424

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1380/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1380

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux deeaa1947a0a 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 915cbc9

Default Java
1.8.0_222

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1380/1/testReport/

Max. process+thread count
1379 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1380/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 32s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
23m 36s
trunk passed

+1 :green_heart:
compile
24m 26s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
18m  0s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
checkstyle
0m 48s
trunk passed

+1 :green_heart:
mvnsite
1m 24s
trunk passed

+1 :green_heart:
shadedclient
16m 14s
branch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 38s
hadoop-common in trunk failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

+1 :green_heart:
javadoc
0m 57s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+0 :ok:
spotbugs
2m 20s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 18s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 52s
the patch passed

+1 :green_heart:
compile
20m 59s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
20m 59s
the patch passed

+1 :green_heart:
compile
17m 50s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
javac
17m 50s
the patch passed

+1 :green_heart:
checkstyle
0m 47s
the patch passed

+1 :green_heart:
mvnsite
1m 24s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
14m 13s
patch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 38s
hadoop-common in the patch failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

+1 :green_heart:
javadoc
0m 58s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
findbugs
2m 24s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
9m 41s
hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 49s
The patch does not generate ASF License warnings.

161m 28s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1380

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 08f0eb147a83 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e756fe35909

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/3/artifact/out/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/3/artifact/out/patch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/3/testReport/

Max. process+thread count
1427 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/3/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 46s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1 :x:
mvninstall
32m  7s
/branch-mvninstall-root.txt
root in trunk failed.

-1 :x:
compile
14m 16s
/branch-compile-root-jdkUbuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.txt
root in trunk failed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.

-1 :x:
compile
12m 29s
/branch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in trunk failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

+1 :green_heart:
checkstyle
0m 54s

trunk passed

+1 :green_heart:
mvnsite
1m 26s

trunk passed

+1 :green_heart:
javadoc
1m  1s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 31s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
2m 15s

trunk passed

+1 :green_heart:
shadedclient
21m 19s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 59s

the patch passed

-1 :x:
compile
14m 10s
/patch-compile-root-jdkUbuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.txt
root in the patch failed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.

-1 :x:
javac
14m 10s
/patch-compile-root-jdkUbuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.txt
root in the patch failed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04.

-1 :x:
compile
12m 25s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

-1 :x:
javac
12m 25s
/patch-compile-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root in the patch failed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 50s

the patch passed

+1 :green_heart:
mvnsite
1m 24s

the patch passed

+1 :green_heart:
javadoc
0m 55s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 29s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
2m 24s

the patch passed

+1 :green_heart:
shadedclient
21m 29s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m  8s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 37s

The patch does not generate ASF License warnings.

161m  8s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1380

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 3a4348c361fd 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 96b9d69c12e9a90294e4cad088ad2f19665e54c1

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/1/testReport/

Max. process+thread count
1728 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1380/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.


Restyle login and register

Login and register page restyled.
Has been made compatible for mobile and large screen.
Dynamic layout.
Issue reference: #164

[This comment can be ignored. It is to test GitHub/Discord Webhook functionality]

Footer Bug is fixed.


Enhance Ui of the contact us page.

Hey @Anupkjha2601  , I would like to change the UI of the contact us section by adding cool effects.
So,please assign this issue to me under gssoc'23.

Please assign it to me under gssoc'23. I want to work on it

@Anupkjha2601 , please assign me this issue.


Cannot access my nuget.org account since i've closed my linked microsoft account

i got the following email from<EMAIL_ADDRESS>
We received a Microsoft account close notification for the account linked with your NuGet account : https://www.nuget.org/profiles/shayhatsor. Your NuGet account https://www.nuget.org/profiles/shayhatsor will be deleted in the next 72 hours. Please consider transferring your owned packages to a different NuGet account using Manage package owners flow. Otherwise the packages owned by the account https://www.nuget.org/profiles/shayhatsor will remain available without a listed owner.

i have tried to login to my nuget.org account, but was unsuccessful. also tried to recover the password which didn't work either. also recreated the closed account, thinking it might give me access to the nuget.org account, but that didn't work either.
please help me move my owned packages to a new account. or remove the link to the microsoft account so i can register a microsoft account again, in order to get access. i wasn't expecting that my nuget.org account will be affected by removing a linked account.
thanks.

I've sent @shayhatsor instructions on how to proceed. We will delete your old account after the packages have been transferred to your new account.

thanks @loic-sharma for the quick resolution of my issue !

Hey @shayhatsor, we're doing an internal investigation on this. You mentioned this:

tried to recover the password which didn't work either.

The recover password flow should work. Could you explain what happened when you tried to recover the password?

yes, when i tried to recover the password for the nuget.org account
'shayhatsor'
i got the following email sent to<EMAIL_ADDRESS>http://gmail.com *which is the email i used originally to register:

Hi there,
We heard you were looking for Microsoft logins associated with your
account on NuGet Gallery.
Our records indicate the associated Microsoft login(s): Shay Hatsor
<EMAIL_ADDRESS>Thanks,
The NuGet Gallery Team

which basically says that there's no way for me to get a new password other
than using the linked<EMAIL_ADDRESS>Microsoft account, which
was closed.
if you have any other questions, please let me know.
shay.
On Fri, Nov 9, 2018 at 9:29 PM Loïc Sharma<EMAIL_ADDRESS>wrote:

Hey @shayhatsor https://github.com/shayhatsor, we're doing an internal
investigation on this. You mentioned this:
tried to recover the password which didn't work either.
The recover password flow should work. Could you explain what happened
when you tried to recover the password?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/NuGetGallery/issues/6633#issuecomment-437469237,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALhlmAYe-lOlsWNMGStN0OVH5hInA_8Bks5utdeIgaJpZM4YR2fq
.

yes, when i tried to recover the password for the nuget.org account
shayhatsor
i got the following email sent to<EMAIL_ADDRESS>which is the email i used originally to register:

Hi there,
We heard you were looking for Microsoft logins associated with your
account on NuGet Gallery.
Our records indicate the associated Microsoft login(s): Shay Hatsor
<EMAIL_ADDRESS>Thanks,
The NuGet Gallery Team

which basically says that there's no way for me to get a new password other
than using the linked<EMAIL_ADDRESS>Microsoft account, which
was closed.


Docker PHP Settings

I cannot find any documentation to edit the settings for the php running in the docker container for the development environment. Can anyone point me in the right direction? I would like to edit the php.ini. I need to increase some memory and times.
Any help is appreciated!

Hi @holmesadrianh sorry this is out of the scope of CDE. Could you please google e.g. "docker wordpress edit php.ini"?

Hi @holmesadrianh sorry this is out of the scope of CDE. Could you please google e.g. "docker wordpress edit php.ini"?

Thanks for the feedback. Will have a look.

Thanks for the feedback. Will have a look.


[BUG] Lava Bucket in Stirling Generator, bucket disappear)

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
If you put a Lava Bucket in a Stirling Generator, then the bucket disappear too. Seems to be the same problem like #260
Expected Behavior
Bucket should not disappear
Steps To Reproduce

Place a Stirling Generator with an Capacitor in it.
Place a Lava Bucket in the GUI
the bucket disappeared

Environment
- OS:Windows 11
- Java version: 17
- Minecraft version: 1.20.1
- Version: 6.0.3-alpha

Anything else?
No response

Duplicate of: https://github.com/SleepyTrousers/EnderIO-Rewrite/issues/260


[SPARK-20408][SQL] Get the glob path in parallel to reduce resolve relation time

What changes were proposed in this pull request?
This PR change the work of getting glob path in parallel, which can make complex wildcard path more quickly, the mainly changes in details:
1.Add config named spark.sql.globPathInParallel , default false
2.Add new function getGlobbedPaths in DataSource, return all paths represented by the wildcard, in parallel or not control by the config
3.Add new function expandGlobPath  in SparkHadoopUtil, to expand the first dir represented by the wildcard
How was this patch tested?
Existing UT.

Test build #75984 has started for PR 17702 at commit b27ef4f.

Test build #75984 has finished for PR 17702 at commit b27ef4f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/75984/
Test PASSed.

@marmbrus Can you take a look of this? Thanks :)

@HyukjinKwon Can you help me to find a appropriate reviewer about this?

Not sure. Probably, @cloud-fan or @gatorsmile ?

ping @cloud-fan and @gatorsmile ,  could you have a look about this ? Thanks :)

Can you show us the performance difference?

yea I'm also wondering how useful it is

Thanks for your review. @gatorsmile @cloud-fan
Can you show us the performance difference?
No problem, I reproduce our online case offline like below
Without parallel resolve:

With parallel resolve:

Test env:

item
detail

Spark version
current master 2.2.0-SNAPSHOT

Hadoop version
2.7.2

HDFS
8 servers(128G, 20 core + 20 hyper threading)

Test case
spark.read.text("/app/dc/test_for_ls/*/*/*/*").count() first level below test_for_ls contains 96 directory, each directory has 1000 directory in next level, the third and forth only have 1 directory and file each.

Discussion:

More complex scenario and deeper directory level will have more optimization, in this local test it can bring us 100% faster.
spark.sql.globPathInParallel config will only parallel the process of resolve glob path.
If driver and cluster in different geographical region, this improvement can produce at least 5* boosting in our scenario because of the resolving work becoming a parallel job on the cluster.

Test build #76378 has started for PR 17702 at commit 2dcf96f.

Test build #76378 has finished for PR 17702 at commit 2dcf96f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/76378/
Test PASSed.

@gatorsmile @cloud-fan, do we need other performance test?

ping @cloud-fan

Test build #77634 has started for PR 17702 at commit 897d316.

Test build #77634 has finished for PR 17702 at commit 897d316.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77634/
Test PASSed.

The logic looks very similar to InMemoryFileIndex.bulkListLeafFiles, is it possible to consolidate them?

@cloud-fan Thanks for your reply!
It's possible to consolidate them but may be not so necessary? I can consolidate them by replace the logic in getGlobbedPaths list below to InMemoryFileIndex.bulkListLeafFiles
+      val expanded = sparkSession.sparkContext
+        .parallelize(paths, paths.length)
+        .map { pathString =>
+          SparkHadoopUtil.get.globPathIfNecessary(new Path(pathString)).map(_.toString)
+        }.collect()
+      expanded.flatMap(paths => paths.map(new Path(_))).toSeq

, and also change the interface of bulkListLeafFiles by adding a default param to parse the function globPathIfNecessary, because of the glob path can be nested in many levels.
Maybe current logic to add a new parallelize job is better than consolidate, what do you think?

retest this please

Test build #78137 has started for PR 17702 at commit 897d316.

Test build #78137 has finished for PR 17702 at commit 897d316.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/78137/
Test PASSed.

Test build #78156 has started for PR 17702 at commit a3a3509.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/78156/
Test FAILed.

Test failed may because of the env? process was terminated by signal 9 in jenkins log.
retest it please

retest this please

Test build #78171 has started for PR 17702 at commit a3a3509.

Test build #78171 has finished for PR 17702 at commit a3a3509.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/78171/
Test PASSed.

Test build #82351 has started for PR 17702 at commit 0ee6943.

Test build #82351 has finished for PR 17702 at commit 0ee6943.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82351/
Test FAILed.

retest this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82360/
Test FAILed.

retest this please

Test build #82378 has started for PR 17702 at commit d019656.

Test build #82378 has finished for PR 17702 at commit d019656.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82378/
Test PASSed.

cc @zsxwing

Test build #83783 has started for PR 17702 at commit 660b95a.

Test build #83783 has finished for PR 17702 at commit 660b95a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83783/
Test FAILed.

Test build #83819 has started for PR 17702 at commit ec9c1c1.

Test build #83819 has finished for PR 17702 at commit ec9c1c1.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83819/
Test FAILed.

retest this please

Test build #83822 has started for PR 17702 at commit ec9c1c1.

Test build #83822 has finished for PR 17702 at commit ec9c1c1.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83822/
Test FAILed.

retest this please

Test build #83837 has started for PR 17702 at commit ec9c1c1.

Test build #83837 has finished for PR 17702 at commit ec9c1c1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83837/
Test PASSed.

@zsxwing Thanks for your comments, ready for review.

gental ping @zsxwing

This approach only works if the first level glob pattern matches a lot of directories, e.g. /my_path/*/*. Otherwise, we can't apply it, e.g. /my_path/{ab, cd}/*.
My proposal: think about how glob works

split path into parts, e.g. /a/*/* -> a, *, *
for each path part, expand it if it's glob pattern, then flatMap the expanded results and expand the next path part, repeat until the last path part.

Step by step, we first expand /a/*/* to /a/b1/*; /a/b2/*, and then /a/b1/c1; /a/b1/c2; /a/b2/c1; /a/b2/c2. Theoritically, we can add a check in each step, if the current to-be-expanded list is above a treshold, do the next expand in parallel.
Maybe we should just fork the Hadoop Globber and improve it to run in parallel.

This approach only works if the first level glob pattern matches a lot of directories.

Yep, actually in our internal usage, we leave the problem to user and they should use first wild cast to represent most of file.
Maybe we should just fork the Hadoop Globber and improve it to run in parallel.

Thanks for your detailed explain and guidance, I'll reconsider this and open another PR.


Breaking changes to language binding assets associated with dfx generate in 0.12.0-beta.3 result in idlFactory type error.

I currently have some software tooling that generates canister declaration files and then copies them over to another directory.
One of the developers using this tooling on the 0.12.0-beta.3 version just reported the following error when trying to start up their frontend after copying over the declarations from the backend canister directory. (I have a script that runs dfx generate before copying over the declarations from the backend to the frontend directory).
It results in the following error.
TS2305: Module '"../declarations/index/index"' has no exported member 'idlFactory'.

For comparison, no other developers (running <= 0.11.x) have this same issue.
I dug a bit deeper into this and found that it's because in 0.12.x the declarations generate an additional index.d.ts file that is not present in dfx versions <= 0.11.x does not. (See https://github.com/dfinity/sdk/blob/master/src/dfx/assets/language_bindings/index.d.ts.hbs)
Because of this addition, now TypeScript expects for the idlFactory type to be defined in this index.d.ts file and will complain if it is not present there (with the error shown above), instead of just pulling it from `./<canister_name>.did.js.

@nathanosdev is looking into this. Thank you for reporting!


cask-analytics: use new cask path

The script stopped working after repo sharding. I updated it to work with the new path.
I also modified the cask_added_date to follow the git history beyond the sharding commit.

Thank you. Already bumped the formula version.


Bug in modularizing Chapel file

I ran:
pych --compile docs/source/examples/sfiles/chapel/hellolib.exported.chpl
and the output was:
AttributeError: 'bool' object has no attribute 'startswith'
from specializer.py line 58, from specializer.py line 80, from compiler.py line 189

Could be another 2.6.9 compatibility issue

This looks like a real bug (i.e. something expects a string and calls .startswith() on it, but it is instead getting a bool).

For sure.  I just haven't dived into debugging it - that area of the code strikes me as a little hairy, and I think we have other priorities on what to do next.  I did alert Simon to this, though, so we'll see what he thinks.


perl-Filter-Simple: 0.91 -> 0.94

Motivation for this change
Build-time tests were failing.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Rebased into master in 4bf61ab252e13a893a00f775dfc80c8551d07657. Thanks!


Remove /employers with Google Webmaster Tools URL Remover || SEO :bug:

Bug Report :bug:
What is the current behavior?
Google is indexing an old page /employers. The result is displaying the 404 page in search results.
What is the expected behavior?
Google search should not return the 404 page.
Solution:
Remove the URL https://operationcode.org/employers using the Google Webmaster Tools URL Remover.

Done!


Summary predict functions - for issue #9 and issue #6

Created skeleton for summary and predict functions with docstrings

Should we transfer some of the heavy lifting from the fit function to the summary function so that the fit only needs to return the centroids and the labels?

Yes I agree. I will make changes now


remove get leader after pd supports redirect.

Should we try to connect to leader first, or just get the members list and connect to a random one?

I think random is ok.


picocom: 3.1 -> 3.2a

Motivation for this change
Upstream (untagged) release.
Also:

write history to $HOME/.cache instead of $HOME
drop wrapper and patch in location of binaries
add bash completion support
start using shell helpers instead of manually copying in man page

Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 107379 run on x86_64-linux 1

2 packages built:

ino
picocom

Result of nixpkgs-review pr 107379 run on x86_64-darwin 1

1 package built:

picocom


Added UnikoinGold (UKG) Token to Defaults

Name of Token :
UnikoinGold
Symbol of Token:
UKG
Decimals:
18
Token Contract address:
0x24692791bc444c5cd0b81e3cbcaba4b04acd1f3b
https://etherscan.io/token/0x24692791bc444c5cd0b81e3cbcaba4b04acd1f3b
Logo:
https://f.unkrn.com/2017-11-04/a/1509813079_unikoin-icon-gold.svg
Official Contact Email Address:
<EMAIL_ADDRESS>Twitter:
https://twitter.com/unikoingold
Facebook
https://www.facebook.com/unikoingold
Website:
https://unikoingold.com
Blog:
https://news.unikrn.com/topic/UnikoinGold
Bitcointalk:
https://bitcointalk.org/index.php?topic=2206150.40
Github:
https://github.com/unikoingold/UnikoinGold-UKG-Contract
Whitepaper:
https://unikoingold.com/whitepaper
Reddit:
https://www.reddit.com/r/unikoingold/
Discord:
https://community.unikrn.com

Thanks for providing all the info! 🚀

@tayvano https://github.com/kvhnuke/etherwallet/pull/1311 - dont hate me please 🤕


Add TimeSeries RDD lag

For issue #65  I used the implementation of time series lag

@sryza check the last commits

@mbaddar2 it looks like the PR still includes the spurious files like y and y.pub

Thanks for fixing this up.  This is looking good.  I added a few more stylistic comments.  Also, would you mind rebasing it on master so that it can be merged?

Thanks @sryza  however i see that some changes happened in original lags code in the Time Series class (support for generic time series key) , which may cause some conflicts when rebasing , will resolve them , rebase and get back to you

Thanks!


[$1000] Web – 2FA - The copy icon placed in "copy code" button is clicked, the icon remains in a hovered state.

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:

Go to the "Settings" section.
Click on the "Security" option.
Select the "Two-factor authentication" feature.
Notice that when the copy icon placed in "copy code" button is clicked, the icon remains in a hovered position until the cursor is placed over it and then moved away.

Expected Result:
The copy icon should not remain in a hovered position when the "copy code" button is clicked.
Actual Result:
The copy icon should not remain in a hovered position when the "copy code" button is clicked until the cursor is placed over it and then moved away.
Workaround:
Unknown
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.31-2
Reproducible in staging?: y
Reproducible in production?: y
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/93399543/4f0e8cba-2c08-4bb3-ab41-79b29c1f4275
https://github.com/Expensify/App/assets/93399543/80c4d1e7-5574-4c17-b880-30f25c9aea40
Expensify/Expensify Issue URL:
Issue reported by: @usmantariq96
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687498320311389
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01827743d082c5b93a
Upwork Job ID:<PHONE_NUMBER>868873216
Last Price Increase: 2023-07-06

Was able to recreate this as well, so getting eyes on the proposal 👍

@abdulrahuman5196 Any thoughts on the proposal above?

Essentially the pressable component is only wrapping the icon, which means it will only highlight when we hover over the icon specifically

@Ollyws  I agree on this. it weird that while only hovering the icon it goes to hover state, it should be in hover state even if we go over the text. @CortneyOfstad  Kindly correct me if wrong, if the expectation is to show the hover state when only we go over the icon not the icon text.
But regardless, the current issue is that the hover state itself is not updated correctly leading to the copy icon being in hovered state. Could you mention why do you think both are related? Why does the hover provide wrong results when hovered over the icon(which is the root cause actually).

@abdulrahuman5196 I believe you are correct that the hover state should be when we go over all text 👍

Heading OoO for the week (back July 10) so re-assigning this in the meantime 👍

this was assigned to me while i was out of office - reviewing today.

@abdulrahuman5196 - when you have a chance, let me know what you think of @Ollyws comment here - https://github.com/Expensify/App/issues/21673#issuecomment-1614912366

I think the comment makes sense.
Anyways the real issue i am thinking of is that Why isn't the icon highlighted when we hover on its relevant text/button itself?
So I think the right fix would be make the icon come to hover state when the mouse enters the button itself. AFAIK tested it seems to fix the hover state issue this GH was originally created for.
@Ollyws Could you update your original proposal with more information from comments discussed - https://github.com/Expensify/App/issues/21673#issuecomment-1609372663

@Ollyws 's proposal here looks good and works well. We will be change the behaviour of hover style of icon to be activated when button itself is hovered.
🎀👀🎀
C+ Reviewed
cc: @maddylewis

🎀 👀 🎀 C+ reviewed

@abdulrahuman5196 - will you provide an update on this one? are we waiting for the fix to be deployed? https://github.com/Expensify/App/pull/22430#issuecomment-1645730374
once the fix is live, do we need to wait for the 7-day regression period before issuing payment? lmk - thanks!

@maddylewis
will you provide an update on this one? are we waiting for the fix to be deployed?
The fix was merged yesterday. And waiting for prod deployment
once the fix is live, do we need to wait for the 7-day regression period before issuing payment?
Yes

@maddylewis offer accepted with thanks.

moving to daily since payment date is coming up.

The PR that introduced the bug has been identified. Link to the PR:
The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

This is not a regression. The component has been this way with PressableWithDelayToggle.js

Determine if we should create a regression test for this bug.
If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

This is corner case. So regression test wouldn't be benificial here.
@maddylewis

Payments
Outlined here - https://github.com/Expensify/App/issues/21673#issuecomment-1640394003

@maddylewis Done

thanks!

thanks!


Third party library import resource failure

use  'com.android.support:appcompat-v7:24.1.1' ，Can normally generate BUCK file，Can also be normal generationapk，But after the operation return wrong，the error info is org.xmlpull.v1.XmlPullParserException: Binary XML file line #17 tag requires viewportWidth > 0

Use English please, there are several English speaker in maintainers. :)

use 'com.android.support:appcompat-v7:24.1.1' ，Can normally generate BUCK file，Can also be normal generationapk，But after the operation return wrong，the error info is org.xmlpull.v1.XmlPullParserException: Binary XML file line #17 tag requires viewportWidth > 0

Does your gradle build works well?
By the way, change this issue title please.

yes,Using Android Studio can normally run :）

I use Android  Studio create a new Empty Activity ,and modify gradle file，add signingConfigs,the app
gradle is this:
apply plugin: 'com.android.application'

android {
    compileSdkVersion 24
    buildToolsVersion "24.0.1"

    defaultConfig {
        applicationId "com.shine.bucktest"
        minSdkVersion 15
        targetSdkVersion 24
        versionCode 1
        versionName "1.0"
    }

    signingConfigs {
        release {
            storeFile file('../debug.keystore')
            storePassword 'android'
            keyAlias 'androiddebugkey'
            keyPassword 'android'
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.release
        }
        release {
            minifyEnabled false
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:24.1.1'
}

at the root gradle.build is
// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.1.2'
        classpath 'com.github.piasy:okbuck-gradle-plugin:1.0.0-beta9'
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}
apply plugin: 'com.github.piasy.okbuck-gradle-plugin'

okbuck {
    overwrite true
    resPackages = [
            app: 'com.shine.bucktest',
    ]
}

gotcha! You use the wrong plugin, see README closely :)

I have use Java 8 lambda  in my project, so I use okbuck-gradle-plugin:1.0.0-beta9, you think I shoud use 0.4.0? It is newer?

I have update root gradle classpath 'com.github.okbuilds:okbuild-gradle-plugin:0.4.0' android apply plugin: 'com.github.okbuilds.okbuck-gradle-plugin'
okbuck {
    overwrite true
    resPackages = [
            app: 'com.shine.bucktest',
    ]
}

but ./gradlew okbuck -info Error occurred，the error info is
* Where:
Build file '/home/jiangcy/AndroidStudioProjects/BuckTest/build.gradle' line: 28

* What went wrong:
A problem occurred evaluating root project 'BuckTest'.
> Could not find method overwrite() for arguments [true] on root project 'BuckTest'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

Follow the full guide in README, please.

OK，I would try tomorrow,thank you verymach

Latest installation instructions in README
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.github.okbuilds:okbuild-gradle-plugin:0.5.3'
    }
}

apply plugin: 'com.github.okbuilds.okbuck-gradle-plugin'

Please re-open if it is happening in latest version. Closing for now


[Feature] Use java11 as default compiler

Search before asking

[X] I searched in the issues and found nothing similar.

Motivation
Currently the default java compiler is 1.8, we can use java11 as default compiler for paimon-1.0 after paimon-0.9 is released.
Solution
No response
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

What about adding a optional jdk11 build profile first, in this profile we can choose the 3.x.x caffeine version ?

What about adding a optional jdk11 build profile first, in this profile we can choose the 3.x.x caffeine version ?

LGTM, we can do it first


cmd/go: unnecessary stdlib recompilation when passing -m flag

What version of Go are you using (go version)?
tip bc723cf3
Does this issue reproduce with the latest release?
No. The relevant changes were introduced in master recently.
What operating system and processor architecture are you using (go env)?
Darwin/amd64
What did you do?
The exact code doesn't matter as long as there's at least one import.
The default code at https://play.golang.org/ will exhibit the issue.
go run -gcflags='-m=2' main.go
What did you expect to see?
main.go:7:6: cannot inline main: non-leaf function
main.go:8:14: "Hello" escapes to heap
main.go:8:14: 	from ... argument (arg to ...) at main.go:8:13
main.go:8:14: 	from *(... argument) (indirection) at main.go:8:13
main.go:8:14: 	from ... argument (passed to call[argument content escapes]) at main.go:8:13
main.go:8:13: main ... argument does not escape

What did you see instead?
...
# reflect
reflect/swapper.go:38:43: <S> capturing by value: ps (addr=false assign=false width=24)
reflect/swapper.go:42:43: <S> capturing by value: ss (addr=false assign=false width=24)
reflect/swapper.go:48:43: <S> capturing by value: is (addr=false assign=false width=24)
reflect/swapper.go:51:43: <S> capturing by value: is (addr=false assign=false width=24)
reflect/swapper.go:54:43: <S> capturing by value: is (addr=false assign=false width=24)
reflect/swapper.go:57:43: <S> capturing by value: is (addr=false assign=false width=24)
reflect/swapper.go:65:22: <S> capturing by value: s (addr=false assign=false width=8)
reflect/swapper.go:68:30: <S> capturing by value: size (addr=false assign=false width=8)
reflect/swapper.go:70:16: <S> capturing by value: typ (addr=false assign=false width=8)
reflect/swapper.go:70:21: <S> capturing by value: tmp (addr=false assign=false width=8)
reflect/type.go:1387:61: <S> capturing by value: name (addr=false assign=false width=16)
reflect/type.go:2031:40: <S> capturing by value: hash (addr=false assign=false width=4)
reflect/type.go:2440:26: <S> capturing by value: ifield (addr=false assign=false width=8)
reflect/type.go:2440:41: <S> capturing by value: imethod (addr=false assign=false width=8)
reflect/type.go:2448:26: <S> capturing by value: ifield (addr=false assign=false width=8)
reflect/type.go:2448:41: <S> capturing by value: imethod (addr=false assign=false width=8)
reflect/type.go:2457:26: <S> capturing by value: ifield (addr=false assign=false width=8)
reflect/type.go:2457:41: <S> capturing by value: imethod (addr=false assign=false width=8)
reflect/type.go:2465:26: <S> capturing by value: ifield (addr=false assign=false width=8)
reflect/type.go:2465:41: <S> capturing by value: imethod (addr=false assign=false width=8)
reflect/type.go:2654:41: <S> capturing by value: hash (addr=false assign=false width=4)
reflect/type.go:2749:23: <S> capturing by value: typ (addr=false assign=false width=8)
reflect/type.go:2759:23: <S> capturing by value: typ (addr=false assign=false width=8)
reflect/type.go:2974:20: <S> capturing by value: count (addr=false assign=false width=8)
reflect/type.go:2975:25: <S> capturing by value: esize (addr=false assign=false width=8)
reflect/type.go:2977:9: <S> capturing by value: eequal (addr=false assign=false width=8)
reflect/type.go:2989:20: <S> capturing by value: count (addr=false assign=false width=8)
reflect/type.go:2990:9: <S> capturing by value: ehash (addr=false assign=false width=8)
reflect/type.go:2990:31: <S> capturing by value: esize (addr=false assign=false width=8)
reflect/type.go:3121:21: <S> capturing by value: x (addr=false assign=false width=8)
reflect/value.go:1015:6: can inline Value.IsValid as: method(Value) func() bool { return v.flag != 0 }
reflect/type.go:774:6: can inline (*rtype).Kind as: method(*rtype) func() Kind { return Kind(t.kind & kindMask) }
reflect/type.go:644:6: cannot inline resolveTypeOff: no function body
reflect/type.go:683:6: cannot inline (*rtype).typeOff: non-leaf function
reflect/type.go:691:6: cannot inline (*rtype).uncommon: unhandled op DCLTYPE
...
on and on for hundreds of lines
...
fmt/scan.go:369:33: (*readRune).UnreadRune r does not escape
fmt/print.go:128:38: new(pp) escapes to heap
fmt/print.go:128:38: 	from ~r0 (return) at fmt/print.go:128:28
fmt/print.go:128:38: new(pp) escapes to heap
fmt/print.go:128:38: 	from new(pp) (interface-converted) at fmt/print.go:128:38
fmt/print.go:128:38: 	from ~r0 (return) at fmt/print.go:128:28
fmt/scan.go:379:38: new(ss) escapes to heap
fmt/scan.go:379:38: 	from ~r0 (return) at fmt/scan.go:379:28
fmt/scan.go:379:38: new(ss) escapes to heap
fmt/scan.go:379:38: 	from new(ss) (interface-converted) at fmt/scan.go:379:38
fmt/scan.go:379:38: 	from ~r0 (return) at fmt/scan.go:379:28
<autogenerated>:1:0: leaking param: io.p
<autogenerated>:1:0: 	from .this.Write(io.p) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Write(io.p) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: os.(*File).close .this does not escape
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Flag(c) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Precision() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Width() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: b
<autogenerated>:1:0: 	from .this.Write(b) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Write(b) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: io.p
<autogenerated>:1:0: 	from .this.Read(io.p) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Read(io.p) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.ReadRune() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.UnreadRune() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Error() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: buf
<autogenerated>:1:0: 	from .this.Read(buf) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Read(buf) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.ReadRune() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.SkipSpace() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: f
<autogenerated>:1:0: 	from .this.Token(skipSpace, f) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Token(skipSpace, f) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.UnreadRune() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Width() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Align() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.u
<autogenerated>:1:0: 	from .this.AssignableTo(reflect.u) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.AssignableTo(reflect.u) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Bits() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.ChanDir() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Comparable() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.u
<autogenerated>:1:0: 	from .this.ConvertibleTo(reflect.u) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.ConvertibleTo(reflect.u) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Elem() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Field(reflect.i) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.FieldAlign() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.index
<autogenerated>:1:0: 	from .this.FieldByIndex(reflect.index) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.FieldByIndex(reflect.index) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.name
<autogenerated>:1:0: 	from .this.FieldByName(reflect.name) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.FieldByName(reflect.name) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.match
<autogenerated>:1:0: 	from .this.FieldByNameFunc(reflect.match) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.FieldByNameFunc(reflect.match) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: reflect.u
<autogenerated>:1:0: 	from .this.Implements(reflect.u) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Implements(reflect.u) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.In(reflect.i) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.IsVariadic() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Key() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Kind() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Len() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Method(.anon0) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .anon0
<autogenerated>:1:0: 	from .this.MethodByName(.anon0) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.MethodByName(.anon0) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Name() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.NumField() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.NumIn() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.NumMethod() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.NumOut() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Out(reflect.i) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.PkgPath() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Size() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.String() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.common() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.uncommon() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: f
fmt/format.go:168:19: index bounds check elided
fmt/scan.go:349:27: index bounds check elided
<autogenerated>:1:0: 	from .this.Format(f, c) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Format(f, c) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.GoString() (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: state
<autogenerated>:1:0: 	from .this.Scan(state, verb) (parameter to indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.Scan(state, verb) (receiver in indirect call) at <autogenerated>:1:0
<autogenerated>:1:0: leaking param: .this
<autogenerated>:1:0: 	from .this.String() (receiver in indirect call) at <autogenerated>:1:0
# command-line-arguments
main.go:7:6: cannot inline main: non-leaf function
main.go:8:14: "Hello" escapes to heap
main.go:8:14: 	from ... argument (arg to ...) at main.go:8:13
main.go:8:14: 	from *(... argument) (indirection) at main.go:8:13
main.go:8:14: 	from ... argument (passed to call[argument content escapes]) at main.go:8:13
main.go:8:13: main ... argument does not escape

It looks like @rsc 's recent changes to staleness detection cause spurious rebuilds. I would argue that any flag that doesn't change binary output, which includes -m, should not cause the std lib to be rebuilt.
I would personally prefer that even flags that do change binary output (e.g. -l) do not cause the std lib to be rebuilt when only a single go file is passed to go run / go build as it makes it considerably harder to test specific compiler features on specific code in isolation, which can be a problem for a variety of things, including, but not limited to, reduction of issue reproducers.

The old behavior (do something different depending on the state of $GOROOT/pkg) is not coming back. It's a feature, not a bug, that the end result of a command no longer depends on the specific sequence of "go install" commands that have been run in the past. However, I certainly appreciate that there's a problem here.
Today -gcflags means "apply these flags to all packages". It could be that we need some way to express to the go command "apply these flags to some packages". For example maybe
go run -gcflags='main:-m=2' main.go

/cc @aclements @dr2chase

I understand where you're coming from but it seems to me that this is a rather big, and potentially risky, change in behavior.
Consider for instance someone doing a build with -race, -N, or -l=3, or really any other compiler flag. The new behavior means that on upgrade, compilation is suddenly much longer and the performance characteristics of the resulting binary may change dramatically as the option suddenly applies to stdlib and runtime instead of just application code.
If we're thinking about allowing flags to be set per-package, which I think would be great, why not default to only setting flags for the file/package being explicitly compiled?

@huguesb I don't think this is intended for general use, but it would be darn useful when debugging the compiler and runtime.  Quite often I want to put a new feature under a flag and enable it for just one package (usually "main" or "foo") without trying that new feature on other code that is much more difficult to debug.

@dr2chase Yes, that's pretty much my use case too. It was mostly working for me until now because my test cases fit in a single file and stdlib/runtime wouldn't get recompiled. An escape hatch would be enough for me although I'm still a little worried about the impact this behavior change may have on unsuspecting users in the wild.

Notes from discussion with @aclements just now.
Q1. Threshold question is do we want to be able to specify that a build should use different flags for different packages? The answer is apparently yes, or we wouldn't be having this discussion.
Q2. Then the next question is how?
Previously the answer to "how?" was repeated go installs, essentially keeping non-repeatable state in the $GOROOT/pkg directory. This was never a good answer and now it's not even a workable answer. It's very important to scalability and repeatability for the result of one build command not to depend on the exact history of previous build commands (see also #22196).
That leaves some indication on the go command line that certain flags apply only to a subset of the packages being built. One option, which I will mention only to reject it, is to have bracketing like
go build -packagescope=strings -gcflags=-N -endpackagescope mypkg

That would require a whole new flag parser, so we're not going to do that.
That leaves putting the scoping into the individual options, as in:
go build -gcflags=strings=-N mypkg

to rebuild mypkg with optimization disabled while building (only) package strings. The general form here would be -gcflags=<packagepattern>=<flags>, where packagepattern is a pattern the go command can check against each package it is building (see go help packages).
Q3. Next question is what to do about multiple such specs. One option is to introduce more syntax inside a single -gcflags, like semicolon-separated list, but it seems better to make -gcflags repeatable:
go build -gcflags=strings=-N -gcflags=math=-l mypkg

Q4. Next question is what to do about packages matched by multiple patterns. Today, when you repeat -gcflags the last one wins, so we should probably do that here. These commands:
go build -gcflags=strings=-N -gcflags=strings=-l mypkg
go build -gcflags=all=-N -gcflags=strings=-l mypkg
go build -gcflags=s...=-N -gcflags=strings=-l mypkg

build strings with only -l not also -N.
Q5. Next question is what it means when you don't specify a pattern, as in
go build -gcflags=-N mypkg

My initial answer was that it means -N for all packages, because that's what it meant in earlier versions of Go if nothing was up-to-date. But normally dependencies are up-to-date, and in that case the -N would have applied only to mypkg itself. So maybe a more useful, if nuanced, answer is that without a pattern the flags apply only to the packages named on the command line (similar to how go install only applies to the packages named on the command line now). That would make these work as I think most users expect:
go build -gcflags=-m net/http # show optimization decisions in net/http
go build -gcflags=-S strings # show disassembly for package strings
go build -gcflags=-N myprog # build myprog with optimization disabled only for myprog itself (not all its dependencies)
go build -gcflags=net/http=-d=ssa/check/on # build net/http (only) with extra SSA checking

To build a fully unoptimized binary you'd use:
go build -gcflags=all=-N myprog

Q6. Next question is whether -a affects any of this. In particular whether -a should mean "apply -gcflags to all packages instead of just what's on the command line". That would essentially bless the current idiom for building a fully unoptimized binary:
go build -a -gcflags=-N myprog

However, I think we should not do this. Despite popular misunderstandings, -a is and has always been about forcing the build not to reuse any previously built object files. It's a debugging override that has over time become less and less necessary, and as of Go 1.10 it should (in the absence of caching bugs) be completely unnecessary. Conflating that debugging with the meaning of other flags seems like a mistake.
This means that people (or maybe just delve) will need to learn the new idiom
go build -gcflags=all=-N myprog

to build an unoptimized binary. I'm OK with that. The confusion and non-orthogonality of redefining -a seems too destructive.
(I've used -gcflags as the running example but this would apply to all (and only) the tool flags: -asmflags, -gccgoflags, -gcflags, -ldflags.)

The proposal, then, is the following.

The go command flags -asmflags, -gccgoflags, -gcflags, and -ldflags are adjusted to take an optional = prefix that causes the flags to apply only to packages matching that pattern (that is, packages that would show up in go list <pattern>). Using -gcflags below is a stand-in for any of the larger set.

For each package being built, repeated -gcflags are considered in turn: the final match is the one that applies, and earlier matches are replaced (not augmented) by the final match.

In the absence of a pattern, -gcflags applies only to the packages named on the command line (or the implicit "current directory" argument when no package is named on the command line).

None of this is affected by the debugging flag -a, which has the completely orthogonal meaning "do not use previously built object files even if they look useful".

Normally something like this would not be changed this late in the cycle, but I think it's critical to fix along with deploying the new content-based staleness. The old semantics were never really right but that fact is exposed more clearly by content-based staleness.
/cc @aclements @dr2chase @cherryyz @thanm @griesemer @mdempsky @khr @ianlancetaylor @crawshaw @heschik @derekparker

Overall SGTM.
I find
  -gcflags=strings=-N
difficult to read... would it help to add some syntactic sugar like
   -gcflags={strings=-N}
Obviously these both mean the same, but the second is visually clearer (easier to pick out the meaning of each of the two ='s).

Just to note that given this affects -ldflags it would have a serious performance impact on all builds we do here as we use it to set static build information, which is specific to a given package.
I believe this is quite commonly used, here's an example for reference:
go build -ldfags "-X package/directory/utils.rcsVersion=${GIT_REVISION} -X package/directory/utils.buildDate=${BUILD_DATE} -X package/directory/utils.rcsTag=${BUILD_TAG} -X package/directory/utils.buildDirty=${GIT_DIRTY}" package/to/build

I would agree with @rsc that this is critical to fix, as we wouldn't be able to update to 1.10 due to the performance implications without it.
The proposed fix sounds good to me, however I wonder if -X ldflags could be treated as a special case and the effected package calculated automatically as the package information is already present. This would help eliminate what could otherwise be quite a painful upgrade for users of this feature?

-ldflags here looks a bit confusing to me. Presumably, it only affects the invocation of the linker, which typically only runs once for the final binary, and it has nothing to do with compiling packages. So I'm not sure we need a per-package -ldflags (and what it means).

I find -gcflags=strings=-N difficult to read

I agree that it looks a little weird, but there's a fair amount of precedent for this in other places. E.g., GODEBUG=gctrace=1 follows the same pattern.
It can be made easier to read simply using shell syntax, though: -gcflags="strings=-N". This is probably a good habit anyway since it's necessary when passing multiple flags (or you have to escape the space itself :) Of course, the shell isn't forcing you to put the quotes there, but this seems sufficient to me.

@stevenh I think that under @rsc's proposal your command line would not have to change at all.  Since you are not specifying a package, the -ldflags option will apply only to the packages listed on the command line.  And that seems to be what you want.  In particular note that the -X option is indeed applied only at link time; there is no need to recompile the packages mentioned.

@cherrymui A package specific -ldflags option would apply when running something like go install -ldflags=cmd/compile=-w cmd.  I admit I'm having trouble coming up with an example that somebody might actually want to do, but it seems meaningful and consistent.

@ianlancetaylor Yes, it does apply in your example. Thanks.

@rsc Your proposal seems problematic for any option that can itself contain an =.  Scanning the doc files, I see the following such options:

cmd/compile -importmap
cmd/asm -D
cmd/link -X
gccgo quite a few options inherited from GCC

Perhaps we can assume that no package path starts with -, and that therefore the optional package prefix is anything before the first = unless the first character of the option is -.  But note that while the language spec does permit prohibiting some characters from the package path, - is not one of those characters.
Or, we could require that these options must always be written with a leading all= prefix.

@andybons, why did gopherbot just comment twice about this CL? Are there two running when there should only be one?

Only one pod is currently running for GopherBot (including both staging and prod).
/cc @bradfitz

@rsc Tested tip at 48f2a55a. The issue seems to be solved when the input is a package but not when it is a single file.

@huguesb, I'm not sure what you mean. This is my output:
$ cat hello.go
package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello, playground")
}
$ go build -gcflags=-m=2 hello.go
# command-line-arguments
./hello.go:7:6: cannot inline main: non-leaf function
./hello.go:8:14: "Hello, playground" escapes to heap
./hello.go:8:14: 	from ... argument (arg to ...) at ./hello.go:8:13
./hello.go:8:14: 	from *(... argument) (indirection) at ./hello.go:8:13
./hello.go:8:14: 	from ... argument (passed to call[argument content escapes]) at ./hello.go:8:13
./hello.go:8:13: main ... argument does not escape
$

(And note that if you run the same go command again it will print nothing, because of #22587, which will be fixed.)
But it doesn't print anything about runtime like in your original report. Are you seeing something different?

Hmm weird. I can't reproduce this anymore. I might have accidentally toolstash restore'd between two tests or something.


Disabling msaa_writeback breaks multi-camera UI

Bevy version
0.14
Relevant system information
cargo 1.79.0 (ffa9cf99a 2024-06-03)
rustc 1.79.0 (129f3b996 2024-06-10)
Arch Linux (EndeavorOS), KDE, (tested both Wayland and X11)
Firefox 127.0.2 & Chrome 126.0.6478.126
Nvidia 3080 Driver version 555.58.02
AdapterInfo { name: "NVIDIA GeForce GTX 980, or similar", vendor: 4318, device: 0, device_type: Other, driver: "WebGL", driver_info: "2.0", backend: Gl }
What you did
I disabled msaa_writeback on my splitscreen game.
What went wrong

what were you expecting?
I was expecting it to stop writing the effects of msaa over top of other cameras.
what actually happened?
The UI stopped working on all but one camera.

Additional information
You can replicate this easily by adding msaa_writeback: false to the Camera component on the offical split_screen.rs example.

I patching bevy with this draft PR and it completely fixed this issue: https://github.com/bevyengine/bevy/pull/14287

Closing as completed in https://github.com/bevyengine/bevy/pull/14287


Remove knobs for changing the consensus bit for docs in the IETF stream

See RFC8789. Until what's stated there is changed by another RFC, the consensus bit can and should be automatically handled by the datatracker - having UI to change it only introduces confusion and unnecessary work for ADs.

Also remove the info from the agenda card for a document, will save some space.


Support for Option Pattern

Hi everyone,
it would be cool if you could add support for the Options Pattern.
If there is at least one class that uses the attribute, the generated method should be: serviceCollection.AutoRegister(IConfiguration configuration);
An attribute might look like this:
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public class OptionAttribute : Attribute {
    public string? Section {get;}

    public OptionAttribute(string? section = null) {
        Section = section;
    }
}

Possible Usages:
[Option]
public record RootOption {}

[Option("SectionOption")]
public record SectionOption {}

[Option("SectionOption:InnerSection:MoreInnerSection")]
public record InnerSectionOption {}

Thank you

There are a number of considerations over both the surface area and extent to which ARI would be able to register options.
Mutability is quite a concern for a lot of people setting these types of objects up.
ARI would need to be able to new up one of these types, which isn't strictly what everyone wants. Since ARI is opinionated this may be ok.
There may be requirement to validate the options and as such provide more fine options within the attribute.

There are a number of considerations over both the surface area and extent to which ARI would be able to register options.
Mutability is quite a concern for a lot of people setting these types of objects up.
ARI would need to be able to new up one of these types, which isn't strictly what everyone wants. Since ARI is opinionated this may be ok.
There may be requirement to validate the options and as such provide more fine options within the attribute.

It'd be great if you could make it to support the fundamental scenarios around options configuration, at least initially. We could implement a source generator that produces code similar to:
_ = services.AddOptions<TOptions>()
    .BindConfiguration(SectionName) // Support multiple binding approaches
    .ValidateDataAnnotations() // Optional via ARI
    .ValidateOnStart(); // Optional via ARI

This keeps things simple while covering the most common use cases.


Kernel Issue

Description
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Please provide any additional information below
File "D:\Anaconda3\envs\test_env\lib\site-packages\spyder\plugins\ipythonconsole.py", line 1290, in close_client
self.create_new_client()
File "D:\Anaconda3\envs\test_env\lib\site-packages\spyder\plugins\ipythonconsole.py", line 1009, in create_new_client
self.connect_client_to_kernel(client)
File "D:\Anaconda3\envs\test_env\lib\site-packages\spyder\plugins\ipythonconsole.py", line 1035, in connect_client_to_kernel
stderr_file)
File "D:\Anaconda3\envs\test_env\lib\site-packages\spyder\plugins\ipythonconsole.py", line 1440, in create_kernel_manager_and_kernel_client
kernel_manager.start_kernel(stderr=stderr)
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_client\manager.py", line 337, in start_kernel
kernel_cmd, kw = self.pre_start_kernel(**kw)
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_client\manager.py", line 286, in pre_start_kernel
self.write_connection_file()
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_client\connect.py", line 472, in write_connection_file
kernel_name=self.kernel_name
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_client\connect.py", line 136, in write_connection_file
with secure_write(fname) as f:
File "D:\Anaconda3\envs\test_env\lib\contextlib.py", line 81, in enter
return next(self.gen)
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_core\paths.py", line 461, in secure_write
win32_restrict_file_to_user(fname)
File "D:\Anaconda3\envs\test_env\lib\site-packages\jupyter_core\paths.py", line 387, in win32_restrict_file_to_user
import win32api
ImportError: DLL load failed: The specified procedure could not be found.
Version and main components

Spyder Version: 3.2.4
Python Version: 3.6.3
Qt Versions: 5.6.2, PyQt5 5.6 on Windows

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.24.2 (OK)
numpy >=1.7      :  1.19.5 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  0.10.5 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  1.1.1 (OK)
cython >=0.21    :  0.26.1 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  7.16.1 (OK)
pylint >=0.25    :  1.7.4 (OK)

Hi @arbabejazi,
It seems you are having an installation error of pywin32, I can recomment you to update your environment and install the latest version of that package and try again.
As this error is not related with Spyder and we cannot fix it on Spyder's side I'm going to close this issue.
Thanks for reporting!


Remove res.jsonp(status, obj) signature

Fixed the History.md mistake.

Updated due to comments on similar pull request (https://github.com/expressjs/express/pull/2939)

@tunniclm coverage has decreased by a fraction, otherwise looks good to me.

As mentioned in the other similar pull request, the slight reduction in coverage is due to the reduced number of lines in the file.

Merged into the 5.0 branch :)


Android: Crashes when sharing images

Summary
Crashes when sharing images
Environment Information

Device Name: Pixel 7a
OS Version: 14 AP2A.240705.004
Mattermost App Version: 2.17.1
Mattermost Server Version: 9.9.1

Steps to reproduce

Share image from Gallery app, etc. to the Mattermost app
enter text and post

Expected behavior
Image will be posted
Observed behavior (that appears unintentional)
Mattermos app are crashed
Possible fixes
If you can, link to the line of code that might be responsible for the problem

https://mattermost.atlassian.net/browse/MM-52807


Add getGameSorts and getGameList

This adds support for getting the different sorts and the games in them.

That's true, but it's been 4 months and I'm not fixing that now xD. But yeah the Roblox docs is very misleading. They also still use OpenAPI 2.0 instead of 3.0

Author has no plans to bring this to a mergable state, closing. Feel free to pick it up if you need these functions.


Cannot build omnisharp-sublime

I cannot build omnisharp. After cd into omnisharp folder ./build.sh brings a command window and stops. I opened the file and noticed that I don't have xbuild on my system. what do I do?

install mono
On 13 June 2015 at 03:16, joeizang<EMAIL_ADDRESS>wrote:

I cannot build omnisharp. After cd into omnisharp folder ./build.sh brings
a command window and stops. I opened the file and noticed that I don't have
xbuild on my system. what do I do?
—
Reply to this email directly or view it on GitHub
https://github.com/OmniSharp/omnisharp-sublime/issues/182.

install mono?! ok will do that and see how it goes


Can we check if CpuAcc backend supports QuantizedLstmLayer?

Hi,
I am using Arm NN sdk v19.08 + ACL v19.08
In the release notes of v19.08 arm nn, it mentioned:
Added Quantized_LSTM layer support to CpuAcc and GpuAcc backend
I write a test program reference to the function SerializeDeserializeQuantizedLstm @src/armnnSerializer/test/SerializerTests.cpp to verify if CpuAcc backend supports QuantizedLstmLayer.
However, the result seems CpuAcc backend doesn't support QuantizedLstmLayer.
Could you please help check if there is any possible issue?
Thanks.
Alan

Hi Alan,
The release notes are correct in that we support Quanitzed_LSTM on CpuAcc and GpuAcc. The layer is not currently supported on the Reference backend (CpuRef), however.
Can you please supply us with the error message(s) you received, and some more info on how to reproduce.
Thanks,
James

Optimize() takes an optional vector of strings to write error messages to. It would probably be helpful to provide it and see the messages placed into it:
std::vector<std::string> errorMessages;
armnn::IOptimizedNetworkPtr optNet = Optimize(*network, {Compute::CpuAcc, Compute::CpuRef}, run->GetDeviceSpec(), armnn::Optional<std::vector<std::string>&>(errorMessages));

Then print out the content of errorMessages. It should give you an idea why your layer is not supported.

Hi Alan,
I have looked at your code and I see a few issues with how you have setup the quantization parameters. Please see my diagram below for the data types for each tensor (note that in ArmNN uint8 === QuantisedAsymm8 and int16 === QuantisedSymm16):
.
There is also specific scale/offsets you need to specify for this layer, which are defined in the Android NN docs (https://developer.android.com/ndk/reference/group/neural-networks#group___neural_networks_1ggaabbe492c60331b13038e39d4207940e0a42edb5ab6f1c74f4a756eb1ed0183a16)
The scale/offsets are:
float inputOutputScale = 0.0078125f;
int32_t inputOutputOffset = 128;
float cellStateScale = 0.00048828125f;
int32_t cellStateOffset = 0;
float weightsScale = 0.00408021f;
int32_t weightsOffset = 100;
float biasScale = 3.1876640625e-05f;
int32_t biasOffset = 0;
Please see how this is all put together when creating tensors in the tests for this layer here (also ensuring that the shape of each tensor is correct - this is based on the number of batches, input size and output size): https://github.com/ARM-software/armnn/commit/9c3cae8683e4b24932446b88d3ecbc02f9f9fa08
Let me know how you get on!
Cheers,
J

Optimize() takes an optional vector of strings to write error messages to. It would probably be helpful to provide it and see the messages written into it by the optimizer:
using namespace armnn;
// ...
std::vector<std::string> errorMessages;
IOptimizedNetworkPtr optNet = Optimize(*network, { Compute::CpuAcc, Compute::CpuRef }, run->GetDeviceSpec(), Optional<std::vector<std::string>&>(errorMessages));

Then print out the content of errorMessages. It should give you an idea why your layer is not supported.

Hi @arovir01 ,
Thanks for the suggestion.
The dumped errMessages are:
errMessages[3]: WARNING: Layer of type QuantizedLstm is not supported on requested backend CpuAcc for data type Unsigned8 (reason: in validate src/runtime/NEON/functions/NELSTMLayerQuantized.cpp:253: input_to_input_weights->num_dimensions() > 2), falling back to the next backend.
Thanks!
Alan

Hi Alan,
I have looked at your code and I see a few issues with how you have setup the quantization parameters. Please see my diagram below for the data types for each tensor (note that in ArmNN uint8 === QuantisedAsymm8 and int16 === QuantisedSymm16):
.
There is also specific scale/offsets you need to specify for this layer, which are defined in the Android NN docs (https://developer.android.com/ndk/reference/group/neural-networks#group___neural_networks_1ggaabbe492c60331b13038e39d4207940e0a42edb5ab6f1c74f4a756eb1ed0183a16)
The scale/offsets are:
float inputOutputScale = 0.0078125f;
int32_t inputOutputOffset = 128;
float cellStateScale = 0.00048828125f;
int32_t cellStateOffset = 0;
float weightsScale = 0.00408021f;
int32_t weightsOffset = 100;
float biasScale = 3.1876640625e-05f;
int32_t biasOffset = 0;
Please see how this is all put together when creating tensors in the tests for this layer here (also ensuring that the shape of each tensor is correct - this is based on the number of batches, input size and output size): 9c3cae8
Let me know how you get on!
Cheers,
J

Hi James,
Thanks for the info!
After I applied your suggestion, the validation still got failed.
I think the reason is the dimension defined in function SerializeDeserializeQuantizedLstm @src/armnnSerializer/test/SerializerTests.cpp is 4, which is larger than 2 as the following code section in ACL:
validate() function @src/runtime/NEON/functions/NELSTMLayerQuantized.cpp
// Dimensionality checks
ARM_COMPUTE_RETURN_ERROR_ON(input->num_dimensions() > 2);
ARM_COMPUTE_RETURN_ERROR_ON(input_to_input_weights->num_dimensions() > 2);
ARM_COMPUTE_RETURN_ERROR_ON(input_gate_bias->num_dimensions() > 1);
ARM_COMPUTE_RETURN_ERROR_ON(output_state_in->num_dimensions() > 2);
The errorMessages:
armnn::ConstTensor inputToInputWeights(armnn::TensorInfo(
4, inputToInputWeightsDimensions.data(),
armnn::DataType::QuantisedAsymm8, weightsScale, weightsOffset), inputToInputWeightsData);
Is it a bug for the SerializeDeserializeQuantizedLstm test in SerializerTests.cpp?
B.R.
Victor

Hi Alan,
For the SerializeDeserializeQuantizedLstm test, it looks like the tensors are not setup correctly to pass validation in ArmNN/ACL (the test wasn't created for this purpose, however). For all of the tensors, the number of dimensions is 4:
armnn::ConstTensor inputToInputWeights(armnn::TensorInfo(         4, inputToInputWeightsDimensions.data(),         armnn::DataType::QuantisedAsymm8), inputToInputWeightsData);
As per the Android documentation, all tensors should be 2-D, except for the Bias tensors, which are 1-D. You will need to change the shape of the bias tensor to {1, 1, 1, 9}.
You could also use the values used in some of the tests I linked you above to test functionality.

J

{1, 1, 1, 9} (ie. 4D tensor, degenerate in leading three dimensions) will work for a bias.
In very early versions of Arm NN it was required to specify every tensor as 4D (with leading size 1 dimensions in cases like this).
This has been fixed and now {9} (ie. 1D tensor) will also work, and is preferred.

As James mentioned it, the serialization tests only verify if the layer is serialized and deserialized correctly, i.e. they only check whether the layer the deserializer reconstructs has the exact same properties as the one that was serialized. There is no guarantee that the layers used in those tests are actually valid and executable on any particular backend.

Still, unless there's a reason (for test coverage) that this test should use an invalid definition, we could change it. That would avoid the confusion.
@alanhsu5678 feel free to submit a review (on review.mlpatform.org) for this change. I see no reason why this test case can't be changed to use a valid LSTM configuration.
Other than that, I think the original reported issue has been resolved? (ie. CpuAcc backend does support QuantizedLstmLayer, and checking it works in the normal way).

Thanks for pointing out the invalid test definition @alanhsu5678 , I didn't realise you were referring to it in your initial post. As @MatthewARM suggested, this should be fixed to avoid confusion in the future. If you're interested in submitting a patch, see the contributor's guide for ArmNN: https://github.com/ARM-software/armnn/blob/branches/armnn_19_08/ContributorGuide.md
Cheers,
James

Hi all,
Already uploaded my commit as the follows:
https://review.mlplatform.org/c/ml/armnn/+/2168
B.R.
Alan

Many thanks.

Hi Alan,
Thank you for your contribution. Please be aware, however, that it does not compile in its current form.

Hi @arovir01 ,
OK, I'll check on it and upload a new patch set.
B.R.
Alan

It seems the parantheses are in the wrong place, the scale and the offset needs to go inside the TensorInfo constructor.

Thanks @alanhsu5678 !

Close this issue and thanks for the support!
Alan


build: update to JDK 17 and relevant dependencies

This PR updates the connector to use Java 17. Additionally, it updates relevant dependencies to ensure compatibility with Java 17.

 Build with Java 17 & 21 as well

We're not gonna bump the JDK yet, we'll instead make sure JDK 17 works fine with the connector (as part of our build).