WIP: Select by bounding box

Building on top of https://github.com/developmentseed/lonboard/pull/412 with help from @batpad
Change list

Draw bbox in deck instead of separate layer

Notes

Create mode for when picking bbox should be active
Send data back to Python
Make multiple draw calls, one per set of layer ids, then set on layer state
Maybe delegate to sub models directly. Add a pick callback directly onto the models, and then iterate over each model, calling pick which picks and then assigns directly onto that model's state?
~In testing, we seemed to get only 35k rows back when we got 143k rows checking the same bbox in geopandas with the input gdf. This is possibly related to x,y,width, height passed in to pickObjects?~ Fixed with latest commit
Note about crossing international dateline
Ensure we're not creating more than 256 layers.

@kylebarron I added a "selectionMode" and some ugly UI for a user to start selection mode and clear selection. As a bonus, when the user has a selection, it also displays the number of objects selected.
There's a few things I feel a bit unsure about the logic, and also how the code is structured. We can look tomorrow - but I think this does roughly what we'd want.

It probably makes sense to keep the bounding box state on the widget model so that Python has access to the same bounding box. So e.g. connecting to Mosaic you could pass the bounding box for them to do the same query in duckdb

There would still a few things to be done here to finish, here's what it looks like so far:
https://github.com/developmentseed/lonboard/assets/72280/c7e85f75-e9eb-4bdc-be74-21cc40059b91
@kylebarron - Although, I'm wondering if this can be restructured to not be so tightly coupled to the main rendering code in index.tsx - it would be almost nice to be able to build something like this as a separate widget, not inside the core lonboard code-base. I think that's probably doable - it might be nice to talk through next week.
cc @hanbyul-here

@kylebarron for now, this just sets map.selected_bounds after the user selects the bbox on the python side.
As an approach, I think I prefer this than trying to send indexes for all the objects down from JS - can we not implement this as a method in python and just use the bbox sent by the frontend? So a map.get_selected_objects() or so that would read the bounds from selected_bounds but then just do that query in Python to get the selected objects?
I feel like this is almost ready for review -- not sure what else we should do here.
@hanbyul-here would you be able to give this a look and point out anything obvious that you feel should be changed?
There's possibly a few things that could maybe be done nicer?

The selection "mode" stuff seems a bit janky: https://github.com/developmentseed/lonboard/pull/417/files#diff-0b5adbfe7b36e4ae2f479291e20152e33e940f7f265162d77f40f6bdb5da7405R287
The CSS to position the select control just seems terrible: https://github.com/developmentseed/lonboard/pull/417/files#diff-0b5adbfe7b36e4ae2f479291e20152e33e940f7f265162d77f40f6bdb5da7405R277

Also this was my first time really writing TypeScript so if there's anything there that seems like it's not proper..
One thing to note:

Right now, "setting" map.selected_bounds in python will not do anything on the JS side - if we want a way for a user to programmatically set the selection in Python, I would rather do this by an explicit method on map like "set_selected_bounds", and treat it similar to how the flyTo operation is being handled currently.

As an approach, I think I prefer this than trying to send indexes for all the objects down from JS - can we not implement this as a method in python and just use the bbox sent by the frontend? So a map.get_selected_objects() or so that would read the bounds from selected_bounds but then just do that query in Python to get the selected objects?

I think there are pros and cons to each manner of implementation, but I think that there are some cases where maintaining the indexes on the model itself is valuable. It might also enable more client side use cases where you're syncing the data and the selection with another external widget through JS, avoiding the Python kernel.
And not needing to do another search query on the Python side might be nice for performance as well. And if we're sending up to like 100k uint32s encoded in Parquet to the server, that's a pretty small file. Probably smaller than 50kb?

Note that a user's selection on the screen is in pixels, and does not always align with an axis-aligned bounding box. E.g. if the map is tilted, the pixel bounding box will accurately choose items within that view because deck.gl uses the actual scene rendering for picking. But that won't be able to be picked from Python because you'd have to serialized the entire view and camera state and implement 3d picking from scratch.

@kylebarron based on our conversation, I've made it now so that each layer has a selected_bounds property and when a user selects a bbox, it will set that property on each layer on the map.

cc @LanesGood

@batpad in response to your request for a design review of the bbox selection instructions/icon:

is it possible to use the ipyleaflet draw controls? https://ipyleaflet.readthedocs.io/en/latest/controls/draw_control.html
If not and this is more of a need to implement custom icons, I'd suggest going with something very recognizable, like the geojson.io controls (which are also used in ipyleaflet):

We could implement this as a button simply in the selection div you've added, and I would propose adding a separate "x points selected" text interface element.

Hey folks, in #567 we fixed the bbox select drawing issues. Items moving forward:

Merge main into this branch
Add a toolbar: I believe we need two icons to implement this workflow, one to start a rectangle selection and another to clear an existing selection. This toolbar could also host other features like, exporting image still or animations cc @LanesGood
Add a panel to display the number of features selected
Disable map drag when drawing the rectangle
Update the cursor type when drawing
Discuss what is the best approach to select the features; quoting my own comment for the other PR:

Deck.gl's pickObjects doesn't seem to pick all objects in the bbox. It might be because it doesn't pick occluded features. The function pickMultipleObjects seems to be the only method that picks occluded features, but the selection area must be a circle. If we find a way to get the feature IDs, we can implement the approach suggested by @kylebarron, but at the moment, the only approach seems to be passing the bbox to the Python code so it can query the features.

Status Update:

Implemented XState for state management, replacing the reducer approach. This should simplify handling of side effects and reduce overall complexity
Enhanced bounding box visuals:

Updated style during drawing phase
Changed cursor to pointer when drawing

Integrated dotenv for environment variable management during frontend build. This was necessary for toggling the XState inspector

To Do:

Add styles to toolbar button to initiate bounding box selection
Verify correct transmission of bounds to Python core

@kylebarron @batpad following our recent discussion, bounds are being passed to the Python core in this section. But I'm unsure how to confirm this in the Jupyter notebook environment.

But I'm unsure how to confirm this in the Jupyter notebook environment.

You can add an attribute on the BaseArrowLayer that's
class BaseArrowLayer:
    selected_bounds = traitlets.Any().tag(sync=True)

Then after a making a selection on the map, you should be able to check layer.selected_bounds

@kylebarron @batpad this is ready for a review. I added a toolbar to handle the different steps of adding a bounding box and connected to the layer attributes selected_bounds property. Colors and icons are not super great, but I want to improve them in a separated ticket. Here is a screen capture of the current workflow:

@kylebarron @batpad thanks for the review, I'll merge this now. Sanjay and I had a quick chat about the XState implementation and we agreed some documentation about it would be helpful. I'll open a ticket to track it.


Meteor pre-install

Change $HOME and give mop user owner perms

Closes #8

👍

👍

@harlanj This approach still suffers from re-installing and using the version of Meteor in the applications .meteor/release file, right?
If so, do we want to check and error out before attempting --server-only?

:shipit:


Remove curve library.

Description
Remove curve related code.

Remove file public/externalLibs/graphics/webGLcurve.js  (curve renders & code related to generating curve)
Remove file public/externalLibs/graphics/webGLhi_graph_ce.js  (curve transformations + code from repeat module)
Remove relevant code from src/commons/application/types/ExternalTypes.ts (curve library & functions exposed in curve library, Intentionally left CURVES = 'CURVES', intact (line 14) to prevent errors in other files)
Remove curve related code from public/externalLibs/graphics/webGLgraphics.js
cadet-frontend/public/externalLibs/index.js no longer loads webGlhi_graph_ce and webGlcurve when loading all libs

Type of change

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

How to test
Any existing code which tries to load curve library will fail because it does not exist anymore. I have left the ExternalLibraryName.CURVES as it is to prevent any errors in those files affected (e.g. AssessmentMocks.ts, WorkspaceSaga.ts)
Rune library should however work as before. (https://source-academy.github.io/source/RUNES/)
i.e. these functions should work
    anaglyph
    beside
    beside_frac
    black
    blank
    blue
    brown
    circle
    color
    corner
    flip_horiz
    flip_vert
    green
    heart
    hollusion
    indigo
    make_cross
    nova
    orange
    overlay
    overlay_frac
    pentagram
    pink
    purple
    quarter_turn_left
    quarter_turn_right
    random_color
    rcross
    red
    repeat_pattern
    ribbon
    rotate
    sail
    scale
    scale_independent
    show
    square
    stack
    stack_frac
    stackn
    translate
    turn_upside_down
    white
    yellow

These are the runes I used for testing. Other libraries are able to load, including all libraries, but I did not extensively test other libraries other than runes as they are unlikely to be affected.
anaglyph(heart);
show(beside(heart, heart));
show(beside_frac(0.2,heart, heart));
show(black(red(heart)));
show(blank);
show(blue(heart));
show(brown(heart));
show(red(circle));
show(corner);
show(flip_horiz(corner));
show(flip_vert(corner));
show(green(heart));
hollusion(heart);
hollusion(indigo(heart));
hollusion(indigo(make_cross(heart)));
show(nova);
show(orange(nova));
show(overlay(corner, nova));
show(overlay_frac(0.3, corner, nova));
show(red(pentagram));
show(pink(pentagram));
show(purple(pentagram));
show(quarter_turn_left(purple(heart)));
show(quarter_turn_right(purple(heart)));
show(quarter_turn_right(random_color(heart)));
show(rcross);
show(red(rcross));
show(repeat_pattern(2, x => beside(x, circle), heart));
show(ribbon);
show(rotate(math_PI/3 ,heart));
show(sail);
show(scale(0.25, sail));
show(scale_independent(0.25, 1, sail));
show(square);
show(stack(heart, red(square)));
show(stackn(5, heart));
show(translate(0.2,0.3,heart));
show(turn_upside_down(heart));
show(white(heart));
show(yellow(heart));

Documentation has been ported to modules repository together with the relevant code.
Checklist

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

Pull Request Test Coverage Report for Build 714088156

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.007%) to 28.265%

Totals

Change from base Build 711322711:
-0.007%

Covered Lines:
2248

Relevant Lines:
7283

💛  - Coveralls

converting to Draft because we need to adapt the teaching material. When the missions are converted to the new curves module, we can merge this PR.

This PR should not be merged earlier than 28/7 (the date of the final assessment of the SICP summer course)

Pull Request Test Coverage Report for Build 982289385

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.005%) to 30.026%

Totals

Change from base Build 977492937:
-0.005%

Covered Lines:
3198

Relevant Lines:
9805

💛  - Coveralls


Provide instructions to containerize the native app

A sample Dockerfile for containerizing the native app should be included

This has been done in https://cloud.google.com/java/docs/compile-native-images


Test code.

This is a very interesting code. Is there a time point when the test code will be released?

@Admgan Thanks to your attention! The time should probably around the end of May, which is after another major conference deadline.


Adjust access level of inaccessible protocol members in diagnostics.

Otherwise we hit one of the "%error" cases in the diagnostic text,
which results in an assert.
Fixes rdar://problem/40111079.
(cherry picked from commit dc8650c11ad2966db2215d45aece7f9309eb9c94)

@swift-ci Please test OS X platform


Wildcard import shadows usual scala globals

The docs (README.md) recommend import org.backuity.clist._, which is concise, certainly, but there exists org.backuity.clist.Console, which breaks my existing calls to scala.Console such as Console.err.println("Exiting due to Ctrl-C"), etc.
I'm not a big fan of leading with wildcard imports, particularly in introductory documentation, but I know that everybody does it. But I think if you're going to recommend that approach, you might want to avoid shadowing anything in Scala's default imports?
Otherwise, import org.backuity.clist.{Cli, Command, opt} seems to be working just great!

I've updated the README and released 3.0.0.


show day detail

we should allow users to click on a day and show that days weather detail

still pending!


Refactor/node list

You got lint issues in the build

Will solve tomorrow
Le 3 octobre 2019 22:42:22 GMT+02:00, Gautier Lefebvre<EMAIL_ADDRESS>a écrit :

You got lint issues in the build
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/developer-vault/developer-vault/pull/62#issuecomment-538119930


Added git gud debug as a hidden command

This isn't for any issue, but it might be nice to have this command in case things break, and we want to probe around.
We could test the most recently released version that's distributed by PyPI without having to search for the executable to import and test.
This might also be useful for the 1.0 release if we want the user to probe around for errors by themselves, in case there's an error that they have that we can't reproduce.
I omitted the help argument so that the output doesn't appear in git gud -h.
Note: import readline is necessary to support history in the console.

Could you provide more information on when this would be useful? Is there a specific scenario that inspired you to make this?

@sahansk2 Closing until further information is provided

When this would be useful:

We could test the most recently released version that's distributed by PyPI without having to search for the executable to import and test.
This might also be useful for the 1.0 release if we want the user to probe around for errors by themselves, in case there's an error that they have that we can't reproduce.

As for what inspired me to make this? It was the development of #241 so that I could reinitialize and modify the progress.json file without having to open a text editor to modify the values.


Add looker key that lookers expect

OK this is weird since I did this a year ago https://github.com/looker/actions/pull/173 – clearly we are missing a test around this.

Almost exactly a year ago, actually.


Rewrite the Introduction chapter

Leaving this as a draft because I haven't answered the "Why Should I use Rust on ESP?" question yet, and because I would like to get some feedback on the work that I have done.
This is heavily inspired by The Embedded Rust Book.
Also got rid of some pages that we decided aren't required. The content will be covered elsewhere in the future.
Rendered view: https://github.com/jessebraham/book/blob/59c3b9470bc9791e1fabe031e2d4f493ad508eeb/src/introduction.md
@SergioGasquez @MabezDev @bjoernQ @JurajSadel @georgik if any of you have any input on this I would love to hear it! Are we missing anything? Anything we could explain better?

Not sure if we really need to answer "Why Should I use Rust on ESP?" here, since the user who got here is probably already interested in doing that?

I think it would be beneficial to have some kind of "what advantages does this approach have?" section,  maybe with a pointer to https://www.rust-lang.org/what/embedded and a few details should be sufficient

Gonna just merge this for now, if we decide to go through with adding a section about the benefits then that can be handled in a separate PR.


Add CI to build the project

Enabling TravisCI to build the project.

Instead, we use github action workflow for building maestro.


eldruin/bmi160-rs/issues/5 Add accel, gyro range and types

Hi
I started a bit of work on #5 because I need to be able to set ranges explicitly. I have tested this on my own hardware but if there is any further testing work I am happy to do it, hardware willing.

 I want to implement the scaling as discussed in https://github.com/eldruin/bmi160-rs/issues/2 so the changes in this PR as useful to have.


Resource size displayed in file browser differs from aggregate size in upper left header

Today we noticed that resource landing page displays resource size off
https://github.com/hydroshare/hydroshare/blob/master/theme/templates/resource-landing-page/resource-header.html#L107
Example resource:
https://beta.hydroshare.org/resource/95171602fdd94a3f9c26a65cb7a3552c/

HS 2.10.2

we've noticed that in some cases the size displayed on resource landing page differs vastly from that in iRods
Example:

https://www.hydroshare.org/resource/62dfabfc99c64878883e58383182dd92/
iRods AVU shows: ~325.94 GB in the datazone
Django FileField sizes calculate the size of the resource at 135.6GB

$ ils ../wwwHydroProxy/62dfabfc99c64878883e58383182dd92
/hydroshareZone/home/wwwHydroProxy/62dfabfc99c64878883e58383182dd92:
  C- /hydroshareZone/home/wwwHydroProxy/62dfabfc99c64878883e58383182dd92/data
$ # quotaUserName AVU on the collection
$  imeta ls -C ../wwwHydroProxy/62dfabfc99c64878883e58383182dd92 quotaUserName
AVUs defined for collection /hydroshareZone/home/wwwHydroProxy/62dfabfc99c64878883e58383182dd92:
attribute: quotaUserName
value: REDACTED
units:
$ # quota usage for the quotaUserName (AVU named is quotaUserName-usage)
$ imeta ls -C ../wwwHydroProxy/bags REDACTED-usage
AVUs defined for collection /hydroshareZone/home/wwwHydroProxy/bags:
attribute: REDACTED-usage
value:<PHONE_NUMBER>38

? # actual aggregate size on disk of the collection minus the FAIR data objects
? # but INCLUDING the overhead of all the subdirectory book-keeping on disk (approx 4K per subdir)
? du -b --max-depth=0 /projects/hydroshare/vaults/wwwProxy/home/wwwHydroProxy/62dfabfc99c64878883e58383182dd92/data/contents
349971928486	/projects/hydroshare/vaults/wwwProxy/home/wwwHydroProxy/62dfabfc99c64878883e58383182dd92/data/contents

Perhaps related to https://github.com/hydroshare/hydroshare/issues/5182

UPDATE: after repairing the resource and ingesting all irods files, then running command to refresh size metadata, I see:
>>> from hs_core.models import BaseResource
>>> res = BaseResource.objects.get(short_id="62dfabfc99c64878883e58383182dd92")
>>> res.size
315937358286
>>> from hs_core.hydroshare.utils import convert_file_size_to_unit
>>> convert_file_size_to_unit(res.size, 'gb')
294.2395939361304
>>> from hs_tools_resource.utils import convert_size
>>> convert_size(res.size)
'294.24 GB'
>>> from django.template.defaultfilters import filesizeformat
>>> filesizeformat(res.size)
'294.2\xa0GB'

We might see quite a bit of variation depending on how we convert size
For the resource landing page, we use the built-in: https://docs.djangoproject.com/en/3.2/ref/templates/builtins/#filesizeformat
https://github.com/django/django/blob/3.2.11/django/template/defaultfilters.py#L838-L877

discovered I was conflating two separate issues.
This one #5262 of the file browser showing different size from the resource aggregate (in top left header) vs quota size mismatch. I had thought they might be related but we found that the quota mismatch is due to mircoservices not tracking ibun/zip processes. So Im moving #5262 down in priority for now

perhaps regression of https://github.com/hydroshare/hydroshare/issues/4197

https://github.com/hydroshare/hydroshare/pull/5196/files#diff-42ba409ab49f71821e3fde2cdcb18cddec43cbc17b1eeea1ee2cde95b04c1c16R440
https://github.com/hydroshare/hydroshare/pull/5196#issuecomment-1714269404


Added a isUrl function to lib/utils.ts

This is a PR i discussed about in #1615

👍 ... Could you maybe include refactoring to use this in the entire codebase in the PR? Otherwise there'd have to be a followup PR or someone else would have to refactor. It's probably easier with Search-Replace right off the bat. Thanks!


Replace assertions in Puctuated with more helpful panic messages

Debugging proc macros is very difficult as we can't easily get
backtraces into the proc macro code. Improved error messages will
hopefully give some hint to the user on what the problem is.

Can use https://doc.rust-lang.org/std/macro.assert.html like assert!(some, format_args). I think it's more correct than panic!.

Huh.. I didn't even know assert! can take multiple arguments. I updated the PR.


Fix error reporting

This looks good, thanks for fixing.  Would you bump in ZP as well as HI?
Alex

@zp-alfred accept

Accepted by AlexEvanczuk!

Thanks!


fix future result incompatibility

Coverage remained the same at 81.36% when pulling 62f06d4ac4b92bdffe6a56675cc0fde727fd53c2 on sadam21:poll_result_uri into 4021383cce07724113ffe1485b2e6d0411fce88a on martiner:master.


Flutter cannot build against ARM simulators only in xcode

I'm building an app with dev and prod flavors. Android works fine but ios is facing a bit of trouble.
What I did as follows:

created two dev and prod schemes and two targets respectively.
add debug and release config files for different flavors
add plugin 'flutter_pdfview' in flutter and run pub get.

Things work fine when run through terminals
flutter run --flavor prod or flutter run --flavor prod
But when I build it through xcode, I'm getting this error
Ld /Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Intermediates.noindex/Pods.build/Debug-dev-iphonesimulator/flutter_pdfview.build/Objects-normal/arm64/Binary/flutter_pdfview normal arm64 (in target 'flutter_pdfview' from project 'Pods')
    cd /Users/pengfeihuang/Developer/Flutter/projects/flavors/ios/Pods
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-ios9.0-simulator -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.0.sdk -L/Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Products/Debug-dev-iphonesimulator/flutter_pdfview -F/Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Products/Debug-dev-iphonesimulator/flutter_pdfview -F/Users/pengfeihuang/Developer/Flutter/projects/flavors/ios/Pods/../Flutter -filelist /Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Intermediates.noindex/Pods.build/Debug-dev-iphonesimulator/flutter_pdfview.build/Objects-normal/arm64/flutter_pdfview.LinkFileList -install_name @rpath/flutter_pdfview.framework/flutter_pdfview -Xlinker -rpath -Xlinker @executable_path/Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Intermediates.noindex/Pods.build/Debug-dev-iphonesimulator/flutter_pdfview.build/Objects-normal/arm64/flutter_pdfview_lto.o -Xlinker -objc_abi_version -Xlinker 2 -fobjc-arc -fobjc-link-runtime -framework Flutter -framework Foundation -compatibility_version 1 -current_version 1 -Xlinker -dependency_info -Xlinker /Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Intermediates.noindex/Pods.build/Debug-dev-iphonesimulator/flutter_pdfview.build/Objects-normal/arm64/flutter_pdfview_dependency_info.dat -o /Users/pengfeihuang/Library/Developer/Xcode/DerivedData/Runner-ducgzqqypwgexiekvbigdedzqhbw/Build/Intermediates.noindex/Pods.build/Debug-dev-iphonesimulator/flutter_pdfview.build/Objects-normal/arm64/Binary/flutter_pdfview

ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/pengfeihuang/Developer/Flutter/projects/flavors/ios/Flutter/Flutter.framework/Flutter' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I saw similar issue here, but I don't quite understand why it works with command line but not on xcode.
I have created a sample app here.

[✓] Flutter (Channel stable, 1.22.5, on Mac OS X 10.15.7 19H2 darwin-x64, locale en-NZ)
    • Flutter version 1.22.5 at /Users/pengfeihuang/fvm/versions/stable
    • Framework revision<PHONE_NUMBER> (4 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/pengfeihuang/Library/Android/sdk
    • Platform android-30, build-tools 29.0.2
    • ANDROID_HOME = /Users/pengfeihuang/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.0, Build version 12A7209
    • CocoaPods version 1.10.0

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin installed
    • Dart plugin version 201.9317
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.18.0

[✓] Connected device (1 available)
    • iPhone SE (2nd generation) (mobile) • 01768AA3-066A-483C-BAED-91EDC3E50665 • ios • com.apple.CoreSimulator.SimRuntime.iOS-14-0 (simulator)

• No issues found!

Hi @PandaGeek1024
Although this is a bit different, the underlying cause is still probably https://github.com/flutter/flutter/issues/64502. If it works from command line you can just temporarily only use that (you can use the new flutter build ipa command for building a release).
However this information could be useful on https://github.com/flutter/flutter/issues/64502 so it would be great if you could comment it there
Closing this as a duplicate of https://github.com/flutter/flutter/issues/64502.
Thank you

Hi @PandaGeek1024
Although this is a bit different, the underlying cause is still probably https://github.com/flutter/flutter/issues/64502. If it works from command line you can just temporarily only use that (you can use the new flutter build ipa command for building a release).
However this information could be useful on https://github.com/flutter/flutter/issues/64502 so it would be great if you could comment it there
Closing this as a duplicate of https://github.com/flutter/flutter/issues/64502.
Thank you

This was misduped, reopening.


[fix] Revise Maybe for array, etc #28

Codecov Report

Merging #29 into master will increase coverage by 0.11%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #29      +/-   ##
==========================================
+ Coverage   73.22%   73.33%   +0.11%
==========================================
  Files          33       33
  Lines        1378     1380       +2
==========================================
+ Hits         1009     1012       +3
+ Misses        369      368       -1

Impacted Files
Coverage Δ

src/dprolog/util/Maybe.d
88.46% <100%> (+2.46%)
:arrow_up:

Continue to review full report at Codecov.

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


Document Dev Environment without Pro FontAwesome Subscription

Manuel, thanks for this awesome tool :)
I cloned the repo to start making some contributions but was stumped for a bit about how to get it running without a FontAwesome subscription. I played around a bit and got something working, which I have pushed to a branch on my fork (link). Ideally this would be documented/stored in a better way - do you have thoughts on how to share these changes in a more discoverable way that won't get out of date?

Hmm, it would of course be nice if the build process could be modified to “automagically” fall back to FontAwesome free if NPM_FONTAWESOME_TOKEN is not set. But failing that, perhaps we could simply add a note to README.md?


Implement GCEAgent installer executable.

The change should be checked-in after all windows update functionality complete.Withdraw this pull request.


fix(CI): Testing CI

:tada: This PR is included in version 1.0.2 :tada:
Your semantic-release bot :package::rocket:


Support other Copilot LLMs than OpenAI

Our Copilot provider is fairly tied to it using OpenAI as LLM, but since recently, Copilot can use other LLMs as well. We should support that.

Anthropic mostly works with copilot, except some issues around retrieving malicious packages in natural language chat.
The current hypothesis is that with anthropic in copilot, the system messages actually use role: user for whatever reason.

I'll do this together with #415 because the free copilot also supports anthropic.

PR #428 helps to extract package names and ecosystems with Copilot and Anthropic. There will be a follow up to match them in weaviate - we are discussing how to approach that with Pankaj. Once those are fixed, Anthropic will be supported with Copilot!

I co-assigned @ptelang because during testing we saw issues with extracting package names from natural language prompts also with GPT and this needs an LLM expert :-)


object is possibly undefined even though check is done

TypeScript Version:  3.6.3
Search Terms: object is possibly undefined
Code
const foo = (bar: { baz?: { name: string } }) => {
    const isBarBazDefined = !!bar.baz;
    if(isBarBazDefined) console.log(bar.baz.name);
}

Expected behavior:
Typescript should not give an 'object is possibly undefined' error.
Actual behavior:
Typescript does give an 'object is possibly undefined' error.
Playground Link:
http://www.typescriptlang.org/play/?ssl=4&ssc=2&pln=1&pc=1#code/MYewdgzgLgBAZiEMC8MAUAjAhgJwFwwDeM2AXgPwHFhYC2ApgdDgJZgDmMAvtwJQoA+IgCgYYmKEiwWEAEK55pACL04begBMUMAIQ7sOAHRkA3KPEs4aGfJyKVasJv6SIIADb1D7kO0y5jLFJDGgZeMy4gA
Related Issues:
Couldn't find any.
I realise this is very simple case, but I haven't been able to find an existing issue or FAQ entry on the subject...

This is a duplicate of #12184 - narrowing results cannot be assigned to an identifier and reused.

Thanks. Is there any recommended workaround, besides again doing the check ?

@barroudjo The quick and easy way is a ! assertion:
const foo = (bar: { baz?: { name: string } }) => {
    const isBarBazDefined = !!bar.baz;
    if(isBarBazDefined) console.log(bar.baz!.name);
}


Order ticket displaying wrong closing Values

Wehn I have an existing long position and I go to sell out my long position and more, the order ticket closing position displays wrong amount of shares and the profit is incorrect as well
Steps to reproduce:
Go to Yes/No market with no current position
Trade 1) buy 5 shares at .31 (new position I am long 5 shares at .31)
Order book has .25 bid for 5.02 and .19 bid for 30.03
Trade 2) enter selling 10 shares at .19
Closing position in the order book should say Selling out 5 shares (mine shows 9.98) and new position should show selling out 5 shares (mine shows .02)
Also my profit on the closing position shows positive number should be negative (bought .31s selling out .25s)

@Chwy5 -- Is this still an issue?
If it works now can you close it.


Error: spawn docker ENOENT

⚠ Please verify that this bug has NOT been reported before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

Description
Starting dockge I have a lot of errors
👟 Reproduction steps
Starting dockge
👀 Expected behavior
No errors log messages
😓 Actual Behavior
ERROR: Error: spawn docker ENOENT
Dockge Version
Version: 1.4.2 Frontend Version: 1.4.2
💻 Operating System and Arch
Windows 11
🌐 Browser
Versione 121.0.6167.161 (Build ufficiale) (a 64 bit)
🐋 Docker Version
Docker version 25.0.2, build 29cf629
🟩 NodeJS Version
v20.7.0
📝 Relevant log output
2024-02-11T11:15:42Z [GETSERVICESTATUSLIST] ERROR: Error: spawn docker ENOENT
2024-02-11 12:15:42     at __node_internal_captureLargerStackTrace (node:internal/errors:496:5)
2024-02-11 12:15:42     at __node_internal_errnoException (node:internal/errors:623:12)
2024-02-11 12:15:42     at ChildProcess._handle.onexit (node:internal/child_process:283:19)
2024-02-11 12:15:42     at onErrorNT (node:internal/child_process:476:16)
2024-02-11 12:15:42     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
2024-02-11 12:15:42   errno: -2,
2024-02-11 12:15:42   code: 'ENOENT',
2024-02-11 12:15:42   syscall: 'spawn docker',
2024-02-11 12:15:42   path: 'docker',
2024-02-11 12:15:42   spawnargs: [ 'compose', 'ps', '--format', 'json' ]

It seems like this is the same issue as #361. I'm actually running into the same issue myself; poked around a bunch w/ permissions, etc. but couldn't really get it to work. exec'd into the dockge container and was able to run docker and docker compose commands just fine, so I'm not quite sure why the spawn docker command is throwing an exception here.

I ran into the same problem. Before using dockge, there were other stacks on my host. Is this error caused by dockge not being able to manage existing stacks?

I get the same error if I change to the beta repo. Changing back to :1 doesn't fix it.
06/03/2024 11:58:40 2024-03-06T11:58:40+01:00 [GETSERVICESTATUSLIST] ERROR: Error: spawn docker ENOENT 06/03/2024 11:58:40     at __node_internal_captureLargerStackTrace (node:internal/errors:496:5) 06/03/2024 11:58:40     at __node_internal_errnoException (node:internal/errors:623:12) 06/03/2024 11:58:40     at ChildProcess._handle.onexit (node:internal/child_process:283:19) 06/03/2024 11:58:40     at onErrorNT (node:internal/child_process:476:16) 06/03/2024 11:58:40     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { 06/03/2024 11:58:40   errno: -2, 06/03/2024 11:58:40   code: 'ENOENT', 06/03/2024 11:58:40   syscall: 'spawn docker', 06/03/2024 11:58:40   path: 'docker', 06/03/2024 11:58:40   spawnargs: [ 'compose', 'ps', '--format', 'json' ] 06/03/2024 11:58:40 } 06/03/2024 11:58:45 2024-03-06T11:58:45+01:00 [GETSERVICESTATUSLIST] ERROR: Error: spawn docker ENOENT 06/03/2024 11:58:45     at __node_internal_captureLargerStackTrace (node:internal/errors:496:5) 06/03/2024 11:58:45     at __node_internal_errnoException (node:internal/errors:623:12) 06/03/2024 11:58:45     at ChildProcess._handle.onexit (node:internal/child_process:283:19) 06/03/2024 11:58:45     at onErrorNT (node:internal/child_process:476:16) 06/03/2024 11:58:45     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { 06/03/2024 11:58:45   errno: -2, 06/03/2024 11:58:45   code: 'ENOENT', 06/03/2024 11:58:45   syscall: 'spawn docker', 06/03/2024 11:58:45   path: 'docker', 06/03/2024 11:58:45   spawnargs: [ 'compose', 'ps', '--format', 'json' ] 06/03/2024 11:58:45 }

I'm getting the same error as pvalfar as well.

version: "3.8"
services:
dockge:
image: louislam/dockge:1
restart: unless-stopped
user: "root:986"
ports:
# Host Port : Container Port
- 5001:5001
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./data:/app/data
  # If you want to use private registries, you need to share the auth file with Dockge:
  - /root/.docker/:/root/.docker

  # Stacks Directory
  # ⚠ READ IT CAREFULLY. If you did it wrong, your data could end up writing into a WRONG PATH.
  # ⚠ 1. FULL path only. No relative path (MUST)
  # ⚠ 2. Left Stacks Path === Right Stacks Path (MUST)
  - /data/docker-service:/opt/stacks
environment:
  # Tell Dockge where is your stacks directory
  - DOCKGE_STACKS_DIR=/opt/stacks

After adding the above user configuration, I did not report any errors, but I am not sure if this is the cause

For me this was a permissions problem.  Made sure my docker compose assigns proper user:group and ensured stacks directory had appropriate write permissions for this user, as well as access to docker socket.

Hi everyone,
I found that might be caused by a mismatch between the name field in your docker-compose.yml and your folder name. To resolve this, make sure that the folder name and the name field are the same. You can do this by either editing the name field or changing the folder name to match.


Make sriov-network-config-daemon crash when configmap cannot be obtained

This PR adds a line to crash sriov-network-config-daemon if it can't access the configmap with NIC interfaces.
Fixes #390

Makes sense to me. I'm not aware of any scenario in which the config-daemon can work without InitNicIDs successfully initialized.
@SchSeba I think this should not clash with #365 , as the service implementation would use another function to obtain the map. Right?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.05%) to 25.223%

Files with Coverage Reduction
New Missed Lines
%

controllers/sriovibnetwork_controller.go
2
65.35%

controllers/sriovnetwork_controller.go
2
69.0%

api/v1/helper.go
6
40.6%

Totals

Change from base Build<PHONE_NUMBER>:
-0.05%

Covered Lines:
1894

Relevant Lines:
7509

💛  - Coveralls

/lgtm


Metropolis-Hastings (+ readme files)

I've implemented versions of basic logistic regression, both Metropolis-Hastings and Langevin-adjusted, as agreed. Calculations are here as usual.
I'm running it as a standalone file (see the notebook for the command) because I would not need to compile the whole library, and they are temporary files anyway.
The problem is that I get really weird acceptance ratios in both cases. In particular, this is caused by what I call "ratio2", that is the second term of the ratio involving product over data points. The first and last term seem fine, but ratio2 always seems to be either >1 for all data, or <1 for all data. This leads to either gigantic or infinitely small acceptance ratios.
I don't think MH is meant to work with what are basically 0-or-1 probabilities. But I don't understand where the error is.
The estimated coefficients don't come close to the true ones either, and to me this is further proof that there is an error somewhere. But computations seem fine, too. I'm kinda drawing a blank right now.
(I also pushed CONTRIBUTORS.md and correlated changes as promised.)

I'm sorry I don't have time to go bug hunting at the moment... I wrote this code very quickly but it seems to work to me
#include <gtest/gtest.h>
#include <Eigen/Dense>
#include <stan/math/prim.hpp>
#include "src/utils/rng.h"

double sigmoid(double x) { return 1.0 / (1.0 + std::exp(-x)); }

double log_like(Eigen::VectorXd y, Eigen::MatrixXd x, Eigen::VectorXd alpha) {
  double out = 0.0;
  for (int i = 0; i < y.size(); i++) {
    double tmp = sigmoid(x.row(i) * alpha);
    out += y(i) * std::log(sigmoid(tmp)) +
           (1 - y(i)) * std::log(1 - sigmoid(tmp));
  }
  return out;
}

Eigen::VectorXd mh_step(Eigen::VectorXd y, Eigen::MatrixXd x,
                        Eigen::VectorXd curr_alpha, double var) {
  int dim = curr_alpha.size();
  Eigen::VectorXd out;
  // Hardcoding prior
  Eigen::VectorXd prior_mean = Eigen::VectorXd::Zero(dim);
  Eigen::MatrixXd prior_var = Eigen::MatrixXd::Identity(dim, dim) * 5;

  // propose new state
  Eigen::MatrixXd prop_covar = Eigen::MatrixXd::Identity(dim, dim) * var;
  Eigen::VectorXd prop_alpha = stan::math::multi_normal_rng(
      curr_alpha, prop_covar, bayesmix::Rng::Instance().get());

  double lik_rate = log_like(y, x, prop_alpha) - log_like(y, x, curr_alpha);
  double prior_rate =
      stan::math::multi_normal_lpdf(prop_alpha, prior_mean, prior_var) -
      stan::math::multi_normal_lpdf(curr_alpha, prior_mean, prior_var);

  double acc_rate = lik_rate + prior_rate;

  double unif = stan::math::uniform_rng(0, 1, bayesmix::Rng::Instance().get());
  if (unif < std::exp(acc_rate)) {
    std::cout << "accepted!, acc_rate: " << std::exp(acc_rate)
              << ", lik_rate: " << lik_rate << ", prior_rate: " << prior_rate
              << std::endl;
    std::cout << "prop_alpha: " << prop_alpha.transpose() << std::endl;
    out = prop_alpha;
  } else {
    out = curr_alpha;
  }
  return out;
}

TEST(mh, 1) {
  int ndata = 500;
  Eigen::MatrixXd X = Eigen::MatrixXd::Random(ndata, 2);
  Eigen::VectorXd alpha_true(2);
  alpha_true << -10, 10;

  Eigen::VectorXd y(ndata);
  for (int i = 0; i < ndata; i++) {
    double prob = sigmoid(X.row(i) * alpha_true);
    y(i) = stan::math::bernoulli_rng(prob, bayesmix::Rng::Instance().get());
  }
  std::cout << "y: " << y.transpose() << std::endl;
  std::cout << "log_like: " << log_like(y, X, alpha_true) << std::endl;

  Eigen::VectorXd alpha(2);
  alpha << 0, 0;
  for (int j = 0; j < 1000; j++) {
    alpha = mh_step(y, X, alpha, 0.5);
  }
  std::cout << "alpha = " << alpha.transpose() << std::endl;
  std::cout << "log_like: " << log_like(y, X, alpha) << std::endl;
}

Don't you worry, I figured, you had told me. I'll try and merge with your code, then if everything else fails I'll switch to the thesis for a bit.

I also tried MALA and seems to work fine:
Eigen::VectorXd grad(Eigen::VectorXd y, Eigen::MatrixXd x,
                     Eigen::VectorXd alpha, Eigen::MatrixXd Lambda) {
  Eigen::VectorXd out = -Lambda * alpha;
  for (int i = 0; i < y.size(); i++) {
    out += (y(i) - sigmoid(x.row(i) * alpha)) * x.row(i).transpose();
  }

  return out;
}

Eigen::VectorXd mala_step(Eigen::VectorXd y, Eigen::MatrixXd x,
                          Eigen::VectorXd curr_alpha, double stepsize) {
  int dim = curr_alpha.size();
  Eigen::VectorXd out;
  // Hardcoding prior
  Eigen::VectorXd prior_mean = Eigen::VectorXd::Zero(dim);
  Eigen::MatrixXd prior_var = Eigen::MatrixXd::Identity(dim, dim) * 5;
  Eigen::MatrixXd prior_prec = prior_var.inverse();

  // propose new state
  Eigen::VectorXd prop_mean =
      curr_alpha + stepsize * grad(y, x, curr_alpha, prior_prec);
  Eigen::MatrixXd prop_covar =
      Eigen::MatrixXd::Identity(dim, dim).array() * std::sqrt(2 * stepsize);
  Eigen::VectorXd prop_alpha = stan::math::multi_normal_rng(
      prop_mean, prop_covar, bayesmix::Rng::Instance().get());

  double lik_rate = log_like(y, x, prop_alpha) - log_like(y, x, curr_alpha);
  double prior_rate =
      stan::math::multi_normal_lpdf(prop_alpha, prior_mean, prior_var) -
      stan::math::multi_normal_lpdf(curr_alpha, prior_mean, prior_var);

  Eigen::VectorXd reverse_prop_mean =
      prop_alpha + stepsize * grad(y, x, prop_alpha, prior_prec);
  double prop_rate =
      stan::math::multi_normal_lpdf(prop_alpha, prop_mean, prop_covar) -
      stan::math::multi_normal_lpdf(curr_alpha, reverse_prop_mean, prop_covar);

  double acc_rate = lik_rate + prior_rate - prop_rate;

  double unif = stan::math::uniform_rng(0, 1, bayesmix::Rng::Instance().get());
  std::cout << "acc_rate: " << std::exp(acc_rate) << ", lik_rate: " << lik_rate
            << ", prior_rate: " << prior_rate << ", prop_rate: " << prop_rate
            << std::endl;
  std::cout << "prop_alpha: " << prop_alpha.transpose() << std::endl;
  if (unif < std::exp(acc_rate)) {
    out = prop_alpha;
  } else {
    out = curr_alpha;
  }
  return out;
}

TEST(mh, 2) {
  int ndata = 500;
  Eigen::MatrixXd X = Eigen::MatrixXd::Random(ndata, 2);
  Eigen::VectorXd alpha_true(2);
  alpha_true << -10, 10;

  Eigen::VectorXd y(ndata);
  for (int i = 0; i < ndata; i++) {
    double prob = sigmoid(X.row(i) * alpha_true);
    y(i) = stan::math::bernoulli_rng(prob, bayesmix::Rng::Instance().get());
  }
  std::cout << "y: " << y.transpose() << std::endl;
  std::cout << "log_like: " << log_like(y, X, alpha_true) << std::endl;

  Eigen::VectorXd alpha(2);
  alpha << 0, 0;
  for (int j = 0; j < 1000; j++) {
    alpha = mala_step(y, X, alpha, 0.05);
  }
  std::cout << "alpha = " << alpha.transpose() << std::endl;
  std::cout << "log_like: " << log_like(y, X, alpha) << std::endl;
}

Now it works, both with my original gaussian covariates and your uniform ones. I had implemented the evaluation of the acceptance ratio by using the final results of my computations by hand, but after seeing you directly using log-likelihoods and such, I switched to that much simpler approach. I guess there must have been some computation errors, or some important constants I forgot about. I was also not using log-values, so that could be another source of errors.
So, which one performs the best? The Langevin method is truly wondrous. It has reached almost accurate state values by the 10th (!) iteration, while regular Metropolis-Hastings takes about 80. Not a surprise, I guess.
M.A.L.A. it is, then!

As for the structure of the logit class, or at least the part involving updates of alpha, I was thinking about something similar to what I wrote in these draft files. In short, I used separate methods for all kinds of lpdf's as well as draw_proposal() and utility functions.
Also, since the Durante-Rigon algorithm leverages regular Bayesian regression, I think we should be able to use LinRegUniHierarchy for representing the (beta, tau) pair. As mentioned in the paper, their pseudo-code uses conditionally conjugate, separate priors for the sake of concise notation, but one may also use a normal-gamma joint prior. Therefore, we should be able to merge both beta and tau update steps into good old ~sample_given_data()~ sample_full_cond() using LinRegUniHierarchy objects.
If you agree, I shall start writing the proper class.

So, which one performs the best? The Langevin method is truly wondrous. It has reached almost accurate state values by the 10th (!) iteration, while regular Metropolis-Hastings takes about 80. Not a surprise, I guess.
M.A.L.A. it is, then!

That's usually my take as well, also gradient evaluation should not be that intensive, so let's go with MALA

As for the structure of the logit class, or at least the part involving updates of alpha, I was thinking about something similar to what I wrote in these draft files. In short, I used separate methods for all kinds of lpdf's as well as draw_proposal() and utility functions.

Yes we should start as simple as possible. Just have a LogitStickBreakMixing class that handles things by itself. We can later think of generalizing MALA/MH classes if needed by other parts of the code

Also, since the Durante-Rigon algorithm leverages regular Bayesian regression, I think we should be able to use LinRegUniHierarchy for representing the (beta, tau) pair. As mentioned in the paper, their pseudo-code uses conditionally conjugate, separate priors for the sake of concise notation, but one may also use a normal-gamma joint prior. Therefore, we should be able to merge both beta and tau update steps into good old ~sample_given_data()~ sample_full_cond() using LinRegUniHierarchy objects.

That's fine for me. I don't really remember what they were doing with the Hierarchy part, what I was most interested in is the Mixing part. Then we can plug-in any hierarchy that we want, also non-dependent ones

I obviously need to create a new ConditionalAlgorithm derived object for this. What should I name it? I mean, will we be able to reuse it for other algorithms? If so, LogitSBAlgorithm is not a good name.

I think the right name to it should be BlockedGibbsAlgorithm, since it consists of the same steps of Ishwaran's and James Blocked Gibbs (http://people.ee.duke.edu/~lcarin/Yuting3.3.06.pdf)

Thanks Bruno for your effort! I guess that before implementing the BlockedGibbs algorithm, some preliminary tests can be performed on the LSB prior (either formal tests or qualitative), similarly to the main file you had for the MetropolisHastings class.
Once that's settled, BlockedGibbs all the way + simple simulation study :)

Thank you. I like your plan. I'll start implementing tests as soon as I finish addressing your remarks.

So the mixing works as intended as far as reading/writing/updating goes, as evidenced by the first tests. But I don't know how I can perform a statistical test without an actual algorithm. The old metropolis example files had no need of real allocation values unlike this class. For now I'm just passing fixed arbitrary/random stuff, but I'm sure that doesn't mean anything. Should we proceed directly to building BlockedGibbs?

So the mixing works as intended as far as reading/writing/updating goes, as evidenced by the first tests. But I don't know how I can perform a statistical test without an actual algorithm. The old metropolis example files had no need of real allocation values unlike this class. For now I'm just passing fixed arbitrary/random stuff, but I'm sure that doesn't mean anything. Should we proceed directly to building BlockedGibbs?

As you wish. If it was me, I would just simulate a dataset of allocations and run the MCMC update for the LSB by passing the allocations, but if you want to go straight for the BlockedGibbs go ahead, it might be more difficult to debug...
For the test I have in mind, there are several possibilities. Two that are fairly easy are:

For observations i=1, ..., n generate the cluster label c_i ~ Uniform({1, 2, 3}), if c_i = 1, generate x_i ~ N([-5, -5], I), if c_i= 2, generate x_i ~ N([5, -5], I), if c_i = 2, generate x_i ~ N([0, 5], I) or whatever distribution you prefer as long as they are separated. Then pass to the LSB update_state method the allocations and an empty list of hiearchies, since I don't think they will be used...
Let alpha_1 = [0, -5], alpha_2 = [0, 5], alpha_3 = [5, 0]. For observations i=1, ... n generate x_i ~ N([0, 0], 5* I) and generate c_i with weights given by the LSB mechanism with the given alphas.

For both approaches you can also generate a test set using the same mechanism and check the predictive probability assigned to p(c* = c_true | x*) is sufficiently high
For the second approach you can also check the posterior distributions of the alphas.

It turns out that my question was quite dumb. Everything you said for option 1 is already there, I just need to generate covariates from different distributions instead of just using Eigen Random for the whole thing. Be right back soon...

I've done some debugging and there's definitely something weird going on with the computation of the gradient (lines 49-62 of the LogitSB class), but I can't quite point out what it is. I've checked my calculations (see last paragraph) over and over, and they look correct to me. Basically the gradient gets disproportionately small or large with each added point, and drags the proposal mean with it. Because of these large values, the sigmoids computed in log_like() are either almost 0 or almost 1, resulting in nan when computing the logarithms.
Maybe the parameters I set are just wrong? I have no clue.

Ok I will look into this, what about using a simple MH? Does the algorithm work in that case?

Thank you. That would be (since using step=0 is impossible due to the variance) replacing step with 0 in prop_mean = state_c + step * grad(...)? Unfortunately, it does not seem to be the case. State values are kinda fluctuating around zero, which incidentally is the prior mean. True values are (2,2), (4,4), (8,8). At least we don't get nans...

This should be ready. Shall I merge?

This should be ready. Shall I merge?

Sure go ahead


Renaming the module map file in the source directory

Renaming the module map file in the source directory to a non-default name for Xcode 8.3 (LLVM) compatibility, as recommended by the workaround in the release notes of Xcode 8.3.

Known Issues
When building a framework that has module maps in both the source and the install directories that define the same module, the compiler will show a redefinition message. (28638816)
Workaround: Rename the module map file in the source directory to a non-default name (the default name is module.modulemap or module.map), and set the Module Map File build setting to the renamed module map.

thanks for contributing!

Thanks for merging so quickly!


Filter: Add PROXY Protocol Header Generation Upstream Filter

Description: Adds a new upstream network filter that injects the PROXY protocol header. This filter only works with TCP proxy, as TCP proxy has been modified to add downstream connection information to the upstream filter state. This is how the new filter gets downstream address information for generating the header.
Risk Level: Medium
Testing: Unit, Integration, local manual testing
Docs Changes: A new documentation page has been added for the new filter. Its sits under the upstream section and not with the other filters since they are all under the listener section.
Release Notes: A note has been added for the new filter
Fixes #1031
A couple other things:

Put Matt's name in CODEOWNERS for now just to pass fix format
I haven't been able to get ./tools/proto_format/proto_sync.py to work. I get

  File "./tools/proto_format/proto_sync.py", line 307, in <module>
    Sync(args.api_root, args.mode, args.labels, False)
  File "./tools/proto_format/proto_sync.py", line 272, in Sync
    copy_dst_dir.mkdir(exist_ok=True)
  File "/usr/lib/python3.7/pathlib.py", line 1258, in mkdir
    self._accessor.mkdir(self, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmp6nqm40u1/b/envoy/annotations'

as a failure when running. The proto BUILD files were manually generated for now.

Thanks for the initial feedback @alyssawilk! I will pick it up / respond tomorrow.

Q: What should PROXY PROTOCOL looks like when it is using TLS? Will be the header encrypted or not? For downstream the listener filter works before TLS termination, but with upstream filter the header will be encrypted.

Q: What should PROXY PROTOCOL looks like when it is using TLS? Will be the header encrypted or not? For downstream the listener filter works before TLS termination, but with upstream filter the header will be encrypted.

Good catch. Yeah I think this is not going to work. I'm pretty sure the expectation is that the header is plaintext prior to any TLS data, etc. I wonder if we actually need to do some type of transport socket which wraps another transport socket, kind of like the tap one?

Ah, yup, definitely a problem. The header should be sent unencrypted.

@wez470 yeah sorry I think we need to step back and try to figure out the best way of doing this. I can take a look next week if you don't want to propose something sooner. In the meantime, I would recommend finalizing the header encoding code w/ tests as we will need that no matter what?

@mattklein123 Sounds good. I may not have a ton of time to investigate other potential solutions within the next week, but can work on some more tests.

I wonder if we actually need to do some type of transport socket which wraps another transport socket, kind of like the tap one?

Yeah I think that works.

I've investigated this a bit and I do think that the right solution here going to be to either add a wrapper transport socket, or just to add direct proxy proto support to both the transport sockets we have now either as a common base class or some type of helper.
In the TCP proxy case, here is where grab a specific TCP connection pool before getting a host:
https://github.com/envoyproxy/envoy/blob/3fb6c41a2d2b28e772e1dadf84727d90078cd81a/source/common/upstream/cluster_manager_impl.cc#L1309-L1315
My suggestion would be to (optionally) explicitly add proxy proto info to the upstream transport socket options, thus both hashing the pools correctly as well as as passing the needed info through to the transport socket so it can use it on new connections by emitting the needed header on new connections. This should work for all TCP derivative protocols and I think could make work fairly simply for HTTP as well if desired with proper connection pool segmentation.
Sorry for the prior bad info this, saved by a great catch from @lizan. We should definitely have an integration test for this feature though. I think it should be relatively simple at least for the plaintext case as part of a TCP proxy integration case.
@lizan @zuercher @ggreenway @alyssawilk  WDYT?

Yikes, I hadn't thought at all about TLS and how proxy-proto would play with that. Sorry!
I agree that setting it in the TransportSocketOptions seems like the right way to pass it in.
It feels unfortunate that on ingress, it can be handled by a listener_filter (which is completely optional) but on egress it is added to the TransportSocket implementations. From that thinking, I like the idea of writing a thing that wraps another TransportSocket, but that's really breaking a bunch of abstractions. The Tap transportsocket works because it doesn't care about the underlying transport; it just wants to see the bytes going through. If we made a proxy-protocol wrapping-transport-socket, it needs to write to the underlying transport without the thing it wraps being aware, so it would need to know if it is a file-descriptor, or something else, etc.
So from that line of thinking, I agree it makes most sense to just add it directly to raw_buffer and tls transport sockets. It's only a few lines of code in each.

From that thinking, I like the idea of writing a thing that wraps another TransportSocket, but that's really breaking a bunch of abstractions. The Tap transportsocket works because it doesn't care about the underlying transport; it just wants to see the bytes going through. If we made a proxy-protocol wrapping-transport-socket, it needs to write to the underlying transport without the thing it wraps being aware, so it would need to know if it is a file-descriptor, or something else, etc.

I don't think wrapping transport socket really breaks abstractions, whether it is a file-descriptor or something else is being abstracted by other way in platform, i.e. the os_fd_t. Though I'm fine either way.

From that thinking, I like the idea of writing a thing that wraps another TransportSocket, but that's really breaking a bunch of abstractions. The Tap transportsocket works because it doesn't care about the underlying transport; it just wants to see the bytes going through. If we made a proxy-protocol wrapping-transport-socket, it needs to write to the underlying transport without the thing it wraps being aware, so it would need to know if it is a file-descriptor, or something else, etc.

I don't think wrapping transport socket really breaks abstractions, whether it is a file-descriptor or something else is being abstracted by other way in platform, i.e. the os_fd_t. Though I'm fine either way.

I was thinking of some of the other transport sockets that have been discussed, such as VPP, or anything else that isn't an OS socket, but I see that there is an IoHandle that abstracts that. So making a wrapping transport socket would be fine with me.
In case we change our mind about where to implement this later, should we add a config option on the cluster for do-upstream-proxy-protocol, instead of directly specifying transport socket options?

Yeah, I kind of hate adding it to both classes, but if we have a shared
library it's really not all that bad.
@Matt Klein<EMAIL_ADDRESS>have any thoughts about the HTTP/2
over TCP case? We need to write the proxy proto header as stream data
payload, so that when we demux it's part of the TCP stream, and we're going
to have the same problem where we may want to include information about the
upstream connection, but we don't have the upstream connection yet.
Given that upstream filters won't work for the TLS case, I wonder if we
want to use upstream filters for the HTTP/2 case (where the filters would
apply before TLS but that's what we want here), or if we want some
mechanism where the normal L7 filter chain can send headers but delay
sending data (including the proxy proto header) until we've selected a
route and established a connection.
On Wed, Mar 4, 2020 at 12:30 AM Lizan Zhou<EMAIL_ADDRESS>wrote:

From that thinking, I like the idea of writing a thing that wraps another
TransportSocket, but that's really breaking a bunch of abstractions. The
Tap transportsocket works because it doesn't care about the underlying
transport; it just wants to see the bytes going through. If we made a
proxy-protocol wrapping-transport-socket, it needs to write to the
underlying transport without the thing it wraps being aware, so it would
need to know if it is a file-descriptor, or something else, etc.
I don't think wrapping transport socket really breaks abstractions,
whether it is a file-descriptor or something else is being abstracted by
other way in platform, i.e. the os_fd_t. Though I'm fine either way.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/pull/10177?email_source=notifications&email_token=AELALPNSUY5XIIOHWCBTTALRFXRO5A5CNFSM4K4MDBHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENWNNMQ#issuecomment-594335410,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELALPPYTEXOM3UXBEUMVJ3RFXRO5ANCNFSM4K4MDBHA
.

Okay, so I had some time to look into this today.
I like new wrapper transport socket option the best. Feels the cleanest from a software engineering perspective to me. I played around with the current tap transport socket and got a bit of a  POC working. Doesn't seem too bad with that ioHandle abstraction Greg mentioned. I'll pursue this way unless anyone has other objections.
Since the changes needed are a quite large, should we close this PR and I can open a new one with the new architecture when ready?

have any thoughts about the HTTP/2 over TCP case?

@alyssawilk TBH I'm having a hard time wrapping my head around the TCP over HTTP/2 case, so let's chat about it next week in a more high-bandwidth setting?

I'll pursue this way unless anyone has other objections.

SGTM. If there is any possibility to split this into multiple PRs that would be appreciated. For example, you could split header encoding into 1 PR, and then see if anything else can be split, etc. Thank you for working on this! I will close this for now.

Hey @wez470, would you be up for landing the utility parts of this PR?  I'm working on TCP-over-HTTP2 and CONNECT logic which I think could both use the capability of writing out the proxy proto header.

Sure. I'm close to a PR of the transport socket right now. The code to generate the v1, and v2 headers are methods on the transport socket class right now. Are you wanting to move those to a common place that you can use for your TCP-over-HTTP2 stuff?

Yeah, if it's not a hassle to split it out, I'd be happy to have it land this week - I have a WIP pr that could benefit from it and I could imagine the transport socket PR taking some time in review

Yeah, I should be able to do that

@wez470  any update on your PR for transport socket option to add Proxy protocol support for upstream connections .. I am looking for similar functionality in my deployment. Thx.

One piece merged https://github.com/envoyproxy/envoy/pull/10548. Another in progress piece getting feedback right now: https://github.com/envoyproxy/envoy/pull/10682


Testing performance when doing a single test is super slow

Suppose that I want to run just one test. Let us leave IDEs and their configuration aside, I just want to use the canonical gradle way...
$ time ./gradlew :roaringbitmap:test --tests *testIndexIterator4
Starting a Gradle Daemon, 1 busy Daemon could not be reused, use --status for details
<============-> 92% EXECUTING [2m 42s]
> :RoaringBitmap:test > 1 test completed
> IDLE
> IDLE
> IDLE
> :RoaringBitmap:test > Executing test org.roaringbitmap.RoaringBitmapSubsetTest
> IDLE
> :RoaringBitmap:test > Executing test org.roaringbitmap.buffer.MutableRoaringBitmapSubsetTest
> IDLE
> IDLE

It is basically burning cycles like there is no tomorrow... this is like bitcoin mining but you do not get any bitcoin.

This completes in second if we avoid expensive parametrized classes in our tests.
See https://github.com/RoaringBitmap/RoaringBitmap/pull/383

$ time ./gradlew :roaringbitmap:test --tests *testIndexIterator4
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :RoaringBitmap:compileTestJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

BUILD SUCCESSFUL in 21s
7 actionable tasks: 2 executed, 5 up-to-date

real	0m21.967s
user	0m1.118s
sys	0m0.147s

Tested in https://github.com/RoaringBitmap/RoaringBitmap/pull/384

The resolution is just that we cannot, using gradle, use pattern matching with a starting asterisk (--tests *blabla). It breaks gradle.
cc @marshallpierce


⚠ Secret Website 3 has degraded performance

In a367bf0, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 2734 ms

Resolved: Secret Website 3 performance has improved in a6274f4.


Start upgrading to ml_program

Background: We are lobbying to introduce a new ml_program dialect upstream (initial RFC discussion). This effort aims to get sufficient operations upstream such that we don't need iree_input for most "normal" ML programs from TFLite, JAX, PyTorch. The initial scope includes container ops (CFG based func and Graph-based subgraph) and global/extern-constant infrastructure.
I would like IREE to be the first adopter of what we produce here because it will allow us to sever the dependency of the frontends on IREE dialects, at least for a wide range of cases. This will let us propose that our importers be directly included in the various frontend projects without taking a dependency on IREE (unless if something advanced is warranted). Given that we will also be building out facilities upstream for externalized constants (in sidecar files outside of the IR), once even the initial scope is done, it should also yield a pretty nice usability improvement in addition to the layering improvements.
Rough work to be done (dependent on upstream consensus/landing):
IREE:

[ ] Extend the iree-import-public pass to rewrite ml_program.func -> func.func (at a future point, we may just want to either use ml_program.func more deeply or have IREE have its own func).
[ ] Teach IREE how to handle externalized constant files if provided (this should extend the APIs to accept constant files and implement core support for using them in IREE's globals).

[ ] Thread constant files through more pervasively, supporting generating them in global simplification/numeric optimization and potentially preserving them through to vmfb generation (there is a lot that can be done here, and fully working out is likely a project in itself -- as part of this effort, we will take some naive steps to make it work at all).

[ ] Add iree-import-public conversions for globals to util dialect globals.

TFLite:

[ ] Rework the upstream TF code to produce ml_program.func (or add a stop-gap conversion pass to make things line up for now).
[ ] Hoist large inline constants and globals to ml_program.global and support externalizing the actual values.
[ ] Update stateful op lowerings to use ml_program.global_* ops.
[ ] Contribute the TFLite importer to TensorFlow so that anyone can build the binary and get ml_program + TOSA IR.
[ ] Delete the TFLite importer from IREE.

TF:

[x] #8832

iree-jax:

[ ] Update the iree-jax Python code to produce ml_program.func functions for traced wrappers (potentially producing ml_program.subgraph for HLO-only kernels).
[ ] Emit ml_program.global_* ops instead of iree_input.global_* ops.
[ ] Emit externalized values for globals and hoist large inline constants to externs.
[ ] Raise an RFC to the JAX team to either incorporate iree-jax or rewrite it to their wishes.
[ ] Delete iree-jax.

torch-mlir

[ ] Teach torch-mlir to produce ml_program.func ops instead of func.func.
[ ] Rework value importing in torch-mlir to emit globals and allow generation of externalized data for large tensor values.
[ ] Map mutable module state to globals.

Once completed, we should no longer have:

integrations/tensorflow/iree-dialects shadow copy.
Any code in integrations/tensorflow (we may still have a WORKSPACE that points to the TensorFlow commit we like so that we can build binaries).
A standalone iree-jax project.

We will likely continue to build the TFLite importer (hopefully from pristine upstream sources) and distribute it in our wheels for usability. However, depending on how ambitious we are, it may be possible to simply expose a TF Python API to do such conversions.

@sjarus FYI - Torch-MLIR will probably start producing ml_program.func

Extend the iree-import-public pass to rewrite ml_program.func -> func.func (at a future point, we may just want to either use ml_program.func more deeply or have IREE have its own func).

Can this just be an upstream pass? Seems like "everybody" is going to need this.

Btw working with Jeff and Mehdi on externalized constants. It's just an attribute so any op that uses ElementsAttr (e.g., constant) would be able to reference extern constant in a self-contained/repro producing manner. Adding additional metadata for origin files etc can be added

@sjarus FYI - Torch-MLIR will probably start producing ml_program.func

Extend the iree-import-public pass to rewrite ml_program.func -> func.func (at a future point, we may just want to either use ml_program.func more deeply or have IREE have its own func).

Can this just be an upstream pass? Seems like "everybody" is going to need this, at least at the beginning.

I'd just sent @stellaraccident some notes yesterday on TOSA and its intersection with this construct. Sounds like the timing was pretty good. Happy to keep working in this direction.

Btw working with Jeff and Mehdi on externalized constants. It's just an attribute so any op that uses ElementsAttr (e.g., constant) would be able to reference extern constant in a self-contained/repro producing manner. Adding additional metadata for origin files etc can be added

What happened to having it just be linked to the sym_name of the global? I thought that's what we were going for.

Btw working with Jeff and Mehdi on externalized constants. It's just an attribute so any op that uses ElementsAttr (e.g., constant) would be able to reference extern constant in a self-contained/repro producing manner. Adding additional metadata for origin files etc can be added

What happened to having it just be linked to the sym_name of the global? I thought that's what we were going for.

Sym_name doesn't avoid uniqueing in context unless you make the IR non-self contained (which works for cases where you just want constant opaque, or where you aren't running passes as part of another system but as standalone tool).

Btw working with Jeff and Mehdi on externalized constants. It's just an attribute so any op that uses ElementsAttr (e.g., constant) would be able to reference extern constant in a self-contained/repro producing manner. Adding additional metadata for origin files etc can be added

What happened to having it just be linked to the sym_name of the global? I thought that's what we were going for.

Sym_name doesn't avoid uniqueing in context unless you make the IR non-self contained (which works for cases where you just want constant opaque, or where you aren't running passes as part of another system but as standalone tool).

Let's sync up offline.

Sym_name doesn't avoid uniqueing in context unless you make the IR non-self contained (which works for cases where you just want constant opaque, or where you aren't running passes as part of another system but as standalone tool).

Let's sync up offline.

Let's chat more about this. The approach described in the RFC was actually (imo) a really nice simplification from Chris that will play really well with the tools. That doesn't need to be the only way to do it, but extern binding by name matches most other programming models, has strong priors, etc.

Sym_name doesn't avoid uniqueing in context unless you make the IR non-self contained (which works for cases where you just want constant opaque, or where you aren't running passes as part of another system but as standalone tool).

Let's sync up offline.

Let's chat more about this. The approach described in the RFC was actually (imo) a really nice simplification from Chris that will play really well with the tools. That doesn't need to be the only way to do it, but extern binding by name matches most other programming models, has strong priors, etc.

Sounds good, note that it is orthogonal to binding by name or using global ops.
I'll start roping some folks in for TFlite and JAX work. For Torch I'm assuming Sean is on it (but correct me if wrong :-)).

Hoist large inline constants and globals to ml_program.global and support externalizing the actual values.

Tflite export does externalization at the moment when going to flatbuffer, what externalization options will the other backends be using? (I'm trying to think if we should use TOSA's flatbuffer or not and so have the result be a relatively pure TOSA export).

Either delete the TF importer or upgrade it in a similar fashion to the above. #8832

This may be a good question for bridge team too: seems much of the functionality here is bridge related and could build on APIs they provide/most parts moved there.
Would the minimal here be to produce ml_program.func (unless HLO only) instead of func.func? (Seems with that and if we only care about MHLO section, we could reuse parts for Jax in terms of hoisting and this be reasonably small in scope).

Tflite export does externalization at the moment when going to flatbuffer, what externalization options will the other backends be using? (I'm trying to think if we should use TOSA's flatbuffer or not and so have the result be a relatively pure TOSA export).

The TOSA serialization format has certain design choices that have evolved over time, e.g. the choice of embedding weight content vs reference to a .npy file containing weights. If you're interested in using the format, we'd be happy to get you connected to conversations internally so you're up to date on our thinking and can offer your own feedback.

IREE specific changes have landed to support ml_program so we can start shifting front-ends over.
JAX changes for this are lined up in
https://github.com/rsuderman/jax/commit/3c3c96cb905ab3f41106cb6dc0b148e778e7d665
Logged a separate issue for switching tflite over to ml_program
https://github.com/iree-org/iree/issues/9654

TF changes in https://github.com/iree-org/iree/pull/9804 (restriction, conceptually, from before but not in practice we believe).

Landed the final migration into iree-jax. We are fully on the ml_program train.
https://github.com/iree-org/iree-jax/pull/23


Doubt regarding ViT from timm

Hi @jacobgil. This is such an amazing piece of work. Thanks to you and all the contributors behind it.
I am currently, using vit_base_patch16_224 from timm and I am trying to visualize the Grad-CAM maps. I have followed the guidelines you have laid out in the README for ViTs but I am still getting a weird error:
RuntimeError: shape '[1, 16, 16, 768]' is invalid for input of size 150528.
Here's minimal code:
def reshape_transform(tensor, height=14, width=14):
    result = tensor[:, 1 :  , :].reshape(tensor.size(0),
        height, width, tensor.size(2))

    # Bring the channels to the first dimension,
    # like in CNNs.
    result = result.transpose(2, 3).transpose(1, 2)
    return result

vit_model = timm.create_model("vit_base_patch16_224", pretrained=True)

rgb_img = cv2.imread("grace_hopper.jpg", 1)[:, :, ::-1]
rgb_img = cv2.resize(rgb_img, (224, 224))
rgb_img = np.float32(rgb_img) / 255
input_tensor = preprocess_image(rgb_img, mean=[0.485, 0.456, 0.406],
                                            std=[0.229, 0.224, 0.225])

cam = GradCAM(model=vit_model, target_layer=vit_model.blocks[-1].norm1,
              use_cuda=True, reshape_transform=reshape_transform)
grayscale_cam = cam(input_tensor=input_tensor, target_category=652)
visualization = show_cam_on_image(rgb_img, grayscale_cam)

Here's the Colab Notebook for reproducing the issue.

Hi!
I'm going to look into this and get back to you very soon.

Hi,
I actually tried running this locally with some image and it worked.
I couldn't run the colab since grace_hopper.jpg was missing, but when I created a random image there of size 224,224,3 it also worked.
Can you provide that image, and maybe re-run and make sure it doesn't work?

I just reran and it also worked. Not sure where I made the mistake. However, the visualization seems to be spurious:

Here's the full Colab Notebook (working). Am I passing the wrong target_layer? Here's how vit_model.blocks[-1] looks like:
Block(
  (norm1): LayerNorm((768,), eps=1e-06, elementwise_affine=True)
  (attn): Attention(
    (qkv): Linear(in_features=768, out_features=2304, bias=True)
    (attn_drop): Dropout(p=0.0, inplace=False)
    (proj): Linear(in_features=768, out_features=768, bias=True)
    (proj_drop): Dropout(p=0.0, inplace=False)
  )
  (drop_path): Identity()
  (norm2): LayerNorm((768,), eps=1e-06, elementwise_affine=True)
  (mlp): Mlp(
    (fc1): Linear(in_features=768, out_features=3072, bias=True)
    (act): GELU()
    (fc2): Linear(in_features=3072, out_features=768, bias=True)
    (drop): Dropout(p=0.0, inplace=False)
  )
)

Can you please try
vit_model.blocks[-1].norm1?

The reason is that anything after the last attention, will have a gradient of 0 with respect to the class token.
I tried communicating that in the readme.
I will also try now on this image :-)

Can you please try
vit_model.blocks[-1].norm1?

If you see the Colab Notebook you will see I have done that only. I provided the full output for better visibility.

The reason is that anything after the last attention, will have a gradient of 0 with respect to the class token.
I tried communicating that in the readme.

Oh yes, I noticed that when I was reading the documentation. Thanks for being extra careful with that. The explanation is just spot on there.

Just ran it now on the examples\both.png image.
Re the grace hopper image - I think there is no person category in imagenet, so it might be tricky to interpret it.

Also, FWIW, 652 (military uniform) is the class category of the image I am trying.

Cool.
This is how it looks for gradcam:

It's a bit weird, so looking into it.

I fixed the normalization stats. For ViT (Google), it should be [0.5, 0.5, 0.5] for both mean and std. With this, I got something similar:

With a ResNet50, I got:

For tabby cat (with ViT), I got something expected (on a different image):

For the uniform image,
target_layer = model.blocks[-2]
seems to work slightly better:

(Maybe it memorized the stars in the flag)
But looks like it learned very different patterns than resnet.

Yes exactly. Very interesting to see.


Production build is taking more than 25 mins earlier it was taking 6 mins

Describe the bug
Production build react-scripts build is now taking more than 25 mins earlier it was taking 6 mins
Using react-scripts 4.0.0
trying to rollback to script 3.4.3 and will see the build prformance
Did you try recovering your dependencies?

(Write your answer here.)
Which terms did you search for in User Guide?

(Write your answer here if relevant.)
Environment

(paste the output of the command here.)
Steps to reproduce

(Write your steps here:)

Expected behavior

Build should take 6-7 mins
Actual behavior

Build is taking more than 25 mins.
Reproducible demo

(Paste the link to an example project and exact instructions to reproduce the issue.)

Duplicate of #9966.

Here's a workaround: https://github.com/facebook/create-react-app/issues/9930#issuecomment-719037994

@mareksuscak there is no improvement in production build performance. Still take 25 mins before this change build was taking 6 mins. It did help in local development now hot reloading is happening fast. There could be some other issue while creating production build.
react-scripts build command

Yeah I feel like eslint is the culprit here and should not be run as part of the build. We can always run eslint outside of the build context.

Agree, I have eslint for my src folder files and it takes 30 sec to check all files. as we don't get log we have not idea whats going on in backend. This is really frustrating.

I see one of new bug created today #9997 says react-scripts ignores .eslintignore files. This could be another reason build take so much time. as it might be scanning node_modules files too.

Hi React-scripts team,
How long do you guys need to identify this issue and to fix ?
Its been already 4 working days.

They should really split the 4.0.1 release and fix the performance issues first.

@pascalstr
I've been following this repository for many months now because of multitude of bugs. The previous release was in March. It took over half a year for a new release despite countless bugs and library updates in that time. There seems to be a commit every couple of days or weeks.
I read in one of the issues or PRs that the maintainers are not FB employees (does FB even use react anymore?) which somewhat explains why things are moving at snail's pace.

team, when are you planning to fix this build performance issue. This is really painful to see build to run for 30 mins. Please priorities this issue.

There is a great non-intrusive workaround mentioned by @mareksuscak: https://github.com/facebook/create-react-app/issues/9975#issuecomment-720368060

@HugoGiraudel - I have replied that fix did not help in prod build, it only help in hot reloading.

@pascalstr
I've been following this repository for many months now because of multitude of bugs. The previous release was in March. It took over half a year for a new release despite countless bugs and library updates in that time. There seems to be a commit every couple of days or weeks.
I read in one of the issues or PRs that the maintainers are not FB employees (does FB even use react anymore?) which somewhat explains why things are moving at snail's pace.

Yeah it is looking pretty stale and so many projects / tutorials are depending on it. Just no response after a broken major release, it will reflect bad on React. It was a great tool once but looking at the current state it seems like abandoning this is a safe choice instead of relying on this dead project.

See also excluding IgnorePlugin if you are not using moment.js. In our case it took 2 minutes (7 minutes total).
Excluding Eslint and Ignore plugins led us from 7minutes to 2 minutes.


Workspace-Feature summary-data not in consistent order

This is quite annoying.  Everytime I am looking in the summary information to the right of the green bar, it is in a different order.  So I have to look really hard to find the peg id.  It is giving me eye strain!!!  Some examples of the revolving information can be seen below

This is simply because the default/fall through viewer of this information shows the data in the order it comes back from solr.  We can either make a specific viewer for each type or do something like alphabetize the output so it is consistently ordered.
On Aug 6, 2015, at 12:14 PM, ARWattam wrote:

This is quite annoying. Everytime I am looking in the summary information to the right of the green bar, it is in a different order. So I have to look really hard to find the peg id. It is giving me eye strain!!! Some examples of the revolving information can be seen below
�
Reply to this email directly or view it on GitHub.

I think alphabetical would be fine.  It really is annoying to try and sift through all the lines of data

I agree with Rebecca.

I've changed the default to list these properties in alphabetical order. Not pushed to production yet.


chore: upgrade jenkins-x/jx3-versions to version 0.3.2

from: https://github.com/jenkins-x-terraform/terraform-jx-azure.git

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign ccojocar
You can assign the PR to them by writing /assign @ccojocar in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Flutter 2: Cannot configure in the builder parameters of MaterialApp

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: SmartDialogPage(),
      builder: (BuildContext context, Widget child) {
        return FlutterSmartDialog(child: child);
      },
    );
  }
}

The error occurs:
The argument type 'FlutterSmartDialog Function(BuildContext, Widget)' can't be assigned to the parameter type 'Widget Function(BuildContext, Widget?)?'.

Hi，this is my problem， because I forget to update  the use of flutter2.0
This problem has been solved

please update version to 2.0.3

dependencies:
  flutter_smart_dialog: ^2.0.3

about use

void main() {
  runApp(MyApp());
}

///flutter 2.0
class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Container(),
      builder: (BuildContext context, Widget? child) {
        return FlutterSmartDialog(child: child);
      },
    );
  }
}

Fixed! Thank you very much!


Need to add Swagger specification for REST APIs

Blockchain DB backend exposes APIs via REST, it will be handy if for these APIs create Swagger Specification for easier integration and demonstration of the blockchain db functionalities.

Sure. I will move this under doc and tutorial epic.


Laravel Linter

This pull request includes changes and recommendations for crafting your application "The Laravel Way". Feel free to commit any additional changes to the shift-12658 branch.
Before merging, you should:

Checkout the shift-12658 branch
Review all pull request comments for additional changes
Thoroughly test your application

If you want help with your upgrade, check out the Shift Human Services or join the Shifty Coders Slack room to get answers to all your Laravel questions.

:warning: Shift found instances of string based class references. Laravel adopted the ::class static property since it became available in PHP 5.5. You should update your code to use references like App\SomeModel::class instead of strings like 'App\SomeModel'.

:warning: The following controllers contain actions outside of the 7 resource actions (index, create, store, show, edit, update, destroy). For more details, review the docs or watch Cruddy by Design to see if you can rework these into resource controllers.

[ ] app/Http/Controllers/LocaleController.php

:warning: The following files reference Laravel facades through the global namespace. For example, you're referencing \DB or importing use DB. Instead import Illuminate\Support\Facades\DB and reference DB.
While global references are allowed through aliases, you should import the facade explicitly. This can improve clarity not only for developers, but static analysis used by your IDE.

[ ] app/Http/Middleware/AdjustApplicationLocale.php

:warning: Shift found inline validation in the following controllers. Unless you require this level of control, you should use a Form Request to encapsulate this validation logic and keep your controller clean.

[ ] app/Http/Controllers/API/IngredientController.php
[ ] app/Http/Controllers/API/ItemController.php
[ ] app/Http/Controllers/API/MealController.php
[ ] app/Http/Controllers/API/MenuplanController.php
[ ] app/Http/Controllers/API/MenuplanInvitationController.php
[ ] app/Http/Controllers/API/PurchaseController.php
[ ] app/Http/Controllers/Auth/RegisterController.php

:warning: Shift found opportunities to use the built-in Blade directives like @csrf in the following views:

[ ] resources/views/auth/login.blade.php
[ ] resources/views/auth/passwords/email.blade.php
[ ] resources/views/auth/passwords/reset.blade.php
[ ] resources/views/auth/register.blade.php
[ ] resources/views/layouts/app.blade.php

:warning: Shift found the following config files differ from the defaults. While you are welcome to customize your configuration, you should leverage ENV variables rather than hardcode values. If you find you're adding a lot of configuration options, consider creating a domain specific config file, such as core.php. Both will make app upgrades and deployments easier.

[ ] config/app.php
[ ] config/cache.php
[ ] config/session.php

:information_source: Your Laravel application contains 71 classes and 951 lines of code, with an average of 4.03 lines of code per method.
Most of your classes are Controllers. Your Controllers contain the most lines of code (193 loc) and your Middlewares have the highest lines of code per method (8.33 loc).

:information_source: As noted, much of the code detected above can be automatically fixed using the Laravel Fixer. Save yourself time and clean up your codebase quickly with this new Shift.


common - Add pldm cpld update and improve pldm update common code

Summary:

Support cpld pldm fw update
Support vr update for Grand Teton

Test Plan:

Build Code: PASS

Hi @garnermic , This pull request is based on #780 , thanks!

Hi @garnermic , New commit has fix the problem, thanks for remind.

The latest update still shows it is failing Github checks as shown below.
Build and Analyze / run-cppcheck
Build and Analyze / run-clang-format
Build and Analyze / Aggregate-Lint-Output

Hi @garnermic , merge conflict problem has been solved, please have a look, thanks!

Since #800 has been merged, so closed this pull request.


Extended Mode

I found some problems trying to use the extended mode function. Simple mode is fine.

Setting ‘on’ to false has no effect the only action seems to be on (extended mode)

It would be good to add in some more range checking. Brightness values greater than 100 produce a library error?
"Error: Philips Hue: 7, invalid value, 508,, for parameter, bri”

Brightness 0 isn’t off (I think that’s a Hue bridge limitation) but IMHO I think zero should be off also if you use 0 to 100 rather than 0 to 254 then the possible range of brightness levels is reduced?

ct is fine using megakelvin !!! but weird IMHO but what about saturation etc?

I wonder whether the excellent info might be improved a bit to explain whether commands are additive. So if I send ‘on' without colour and follow up with a colour setting without ‘on’ what is the result?

Would it be better to match the parameter names to the Philips ones (even if they are cryptic)?

Hi lespatots!
Thank you for this nice feedback and sorry for my late response!
Setting "on" to "false" should work as expected now with v1.3.1. I also added a brightness setting validation (can't understand why I didn't before…) and lights / groups are now turning off if the setting is "0". You were right, for some reasons Philips' API is not turning off the lights if the brightness setting is 0.
The saturation setting is something that I totally missed from the API docs – but now obviously added with the update ;)!
With the improved input "algorithm" in v1.3.1 all nodes are now working "additive". You also don't have to pass in the "msg.payload.on" parameter anymore and all future commands are simply updating the light / group / sensors. I added this info in the features section in the README file with a simple sentence. You're totally free to contribute if you have some improvements for the README of even the actual code :)!
I decided to use own customized parameters for HueMagic because of three reasons:

You also mentioned it. They are cryptic in some cases and not easy to remember (often).
If they were all identical then users would probably think, that they also work the same. With Philips Hue API for example you have to pass in a value between 0 and 254 to set the brightness level of a light bulb. In HueMagic this setting is a more convenient "percent" parameter which makes things easier for users – I guess (I hope).
With customized parameter names HueMagic is able to keep it's nodes and API "alive" with internal recalculations and without having the user to manually update all the nodes, just because Philips changed / removed / unnamed some parameters in their API.

I am closing this issue for now. Feel free to answer back if you don't agree with my last arguments 👍 !


fail to install libpng

Package: libpng:x86-windows
Vcpkg version: 0.0.83-

Please try the latest version (0.0.84) and post the output of the failure so we can investigate.

@flcker , can this isue be reproduced on your machine now? I can't repro it.  If it occurs on your machine recently, please post the output of the failure.
Thanks.

Please open a new issue if this is still a probem for you.


Update to zola v0.19

Changelog: https://github.com/getzola/zola/blob/master/CHANGELOG.md#0190-2024-06-20

Differences: https://github.com/phil-opp/blog_os_deploy/commit/b435a7e7505d8cd0f7b7f119537ee94a335286b0


Add openSUSE Leap 15.5 PR image

What does this PR change?
Add the openSUSE Leap 15.5 image we use for testing PRs

Against master https://github.com/uyuni-project/sumaform/pull/1368


RS system refuses to craft pistons / crafting tables and other certain items

Issue description:
Somewhere during our playthrough our RS system stopped autocrafting certain items. Most prominent of which are the pistons / crafting tables, but other items seem to be affected in a similar way.
What happens:
When autocrafting pistons / crafting tables the recipy gets prepared by the RS system and can be viewed in the crafting monitor, but will not finish the step in the crafting proces that will produce the actual pistons / crafting tables. The crafting queue can be cancelled, but will reproduce the bahaviour if tried again. Other items will be crafted as per normal.
What you expected to happen:
For the RS system to finish the steps in the crafting queue for pistons / crafting tables.
Steps to reproduce:
I am unsure as to the steps to reproduce this behaviour as it surfaced after many hours played. Possibly interactions with other mods (like Storage Drawers or Storage Reborn) may have contributed to the issue. We are still in the process of dismantling our RS system to the point where we can perform meaningful (isolated) tests.
Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: unsure
Refined Storage: 1.2.18
Modpack: FTB Presents Skyfactory 3 (v3.0.6)

Does this issue occur on a server? [yes/no]
yes, i can arrange for access if it will help debugging.
If a (crash)log is relevant for this issue, link it here:
There is a thread on the Feed The Beast subreddit discussing the issue. it contains a link to an imgur album with screenshots of someone else experiencing the exact same issue:
https://www.reddit.com/r/feedthebeast/comments/5rin9v/problems_autocrafting_in_sf3/

Likely an issue between Storage drawers and ore dict autocrafting. See #885

This seems to be the issue. Thank you for a speedy response!

This seems to be the issue. Thank you for a speedy response!

This was fixed in 1.2.19


Archive Page Repeating H1 / Title

author archive pages and all search results

repeat the archive heading, ala

Fixed in template file. Will deploy as soon as Deploybot and Dreamhost are happy together. Getting permission error in Deploybot when trying to authenticate w/ Dreamhost. Will need to investigate.

Fixed.


Update use-command-line-parameters-to-install-visual-studio.md

Making the docs reflect how to do multiple workloads / components as finer grain control lead me to believe it was semi-colon delimited.

@crutkas : Thanks for your contribution! The author, @TerryGLee, has been notified to review your proposed change.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/install/use-command-line-parameters-to-install-visual-studio.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@crutkas Thanks for your feedback and for updating the page!
#sign-off


How can we change the name of the downloaded file?

i try %(title)s-%(id)s.%(ext)s but not working

Thanks for the feedback, the previous code could not support the change of the output title, with https://github.com/FlorianLeChat/YouTube-Downloader/commit/ba1328f6c40de69602cbc44cc4092c2999f8f364 and the latest commits, this should be fixed. The default title now uses the one you mentioned above which is also the same with YouTubeDL. Let me know if there is still an issue!


Rotating object via property panel eliminates shear

I think the best way to prioritize this is to wait until we have the node-based transform system using the Transform node. Probably isn't worth the expendable effort of a temporary fix when that won't matter after we have nodes.

Upon further thought, maybe this can be fixed without that much effort and it would probably be a quality of life improvement for users who run into this. Do you have any thoughts about this and its prioritization @0HyperCube?

Upon further thought, maybe this can be fixed without that much effort and it would probably be a quality of life improvement for users who run into this. Do you have any thoughts about this and its prioritization @0HyperCube?

This would probably be somewhat ugly because of how skew combines with rotation and scale in the affine2.