Add Android ARMEABI_V7A_HARD for Hardfp support

Add Android HardFP support. Expose the "armeabi-v7a-hard with NEON"
ANDROID_ABI.
TEST= Add -DANDROID_NATIVE_API_LEVEL=21
-DANDROID_ABI="armeabi-v7a-hard with NEON -DENABLE_PRECOMPILED_HEADERS=OFF"
to compile with hardfp. Checked the output of make verbose to
confirm -lm_hard is being linked. Softfp also works.
Update: tested functionality after compiling with hardfp and opencv works well.

How did you test the functionality? I tried to run C++ tests (core) on phone, but some of them have failed.

BTW, these changes should go to https://github.com/taka-no-me/android-cmake

Yes, the corresonding PR has been created already: taka-no-me/android-cmake#59

I used readlf -A to verify the output libraries had "Tag_ABI_VFP_args: VFP registers". The only library that didn't have hardfp was libopencv_java3.so because it was hardcoding the flags where it was being built.
Also on running the OpenCV I did notice some functions failed and I am working through those failures. Expect those to PRs to come as I go through them. This is so that it enables us to start testing.

The only library that didn't have hardfp was libopencv_java3.so because it was hardcoding the flags where it was being built.

Maybe dynamic libraries can not be checked this way?
$ cat jni/Application.mk
APP_STL := gnustl_static
APP_ABI := armeabi-v7a-hard

$ ndk-build
[armeabi-v7a-hard] Compile++ thumb: hello-jni <= test.cpp
[armeabi-v7a-hard] SharedLibrary  : libhello-jni.so
[armeabi-v7a-hard] Install        : libhello-jni.so => libs/armeabi-v7a/libhello-jni.so

$ readelf -A libs/armeabi-v7a/libhello-jni.so
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM v7"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_optimization_goals: Aggressive Speed
  Tag_CPU_unaligned_access: v6

Actually that may be true. I did have to change libopencv_java3.so somewhere since it didn't respect BUILD_SHARED_LIBS=OFF. I found it hard coded to SHARED somewhere and changed it to static and then I could run readelf -A on it.

The buildbot seemed to have failed cloning from github. Could we please retrigger the build ?

buildbot says build passed but here it says the checks have failed. Please suggest what the next steps are.

@powderluv, everything is OK, I'm waiting for the last build
:+1:

:+1:

@mshabunin, I'm not sure that we should merge this MR. My opinion is that this toolchain file should be developed in the original repo and OpenCV has just a copy.
By merging this MR you introduce a divergence between these 2 copy and create 2 paths of development - OpenCV and original one. In future, when the original toolchain file will be upgraded, it will be difficult to merge them.
I suggest waiting until MR to original repo is merged and then update script.

@ilya-lavrenov I agree with you but I see very low activity in the upstream repository. Would be wonderful if @Kitware will take care of finally integrating https://github.com/taka-no-me/android-cmake in official releases

I have PR for upstream with the exact same changes.
https://github.com/taka-no-me/android-cmake/pull/59

@ilya-lavrenov our team can start moving to hardfp with this change and more people can start fixing the resultant issues on Android. We noticed rodrigues function etc seem to misbehave with hardfp and want to fix them on master instead of on our branch.

Is it possible to add support like armeabi-v7a-hard with vfpv3-d16 besides armeabi-v7a-hard with NEON? I tried to modify the cmake file to remove NEON and vfpv3-d32 flags, but got the following error. It seems that there is some assembler uses NEON. Thank you.
[  3%] Built target libtiff
[  7%] Built target libjpeg
[  7%] Building C object 3rdparty/libwebp/CMakeFiles/libwebp.dir/dsp/dec_neon.c.o
/tmp/ccfRT8yn.s: Assembler messages:
/tmp/ccfRT8yn.s:37: Error: selected processor does not support Thumb mode `vabd.u8 q15,q2,q3'
/tmp/ccfRT8yn.s:38: Error: selected processor does not support Thumb mode `vabd.u8 q14,q1,q4'
/tmp/ccfRT8yn.s:39: Error: selected processor does not support Thumb mode `vqadd.u8 q15,q15,q15'
/tmp/ccfRT8yn.s:40: Error: selected processor does not support Thumb mode `vshr.u8 q14,q14,#1'
/tmp/ccfRT8yn.s:41: Error: selected processor does not support Thumb mode `vqadd.u8 q15,q15,q14'
/tmp/ccfRT8yn.s:42: Error: selected processor does not support Thumb mode `vdup.8 q14,r2'
/tmp/ccfRT8yn.s:43: Error: selected processor does not support Thumb mode `vcge.u8 q9,q14,q15'
/tmp/ccfRT8yn.s:44: Error: selected FPU does not support instruction -- `vmov.i8 q10,#0x80'
/tmp/ccfRT8yn.s:45: Error: selected processor does not support Thumb mode `veor q1,q1,q10'
/tmp/ccfRT8yn.s:46: Error: selected processor does not support Thumb mode `veor q2,q2,q10'
/tmp/ccfRT8yn.s:47: Error: selected processor does not support Thumb mode `veor q3,q3,q10'
/tmp/ccfRT8yn.s:48: Error: selected processor does not support Thumb mode `veor q4,q4,q10'
/tmp/ccfRT8yn.s:49: Error: selected processor does not support Thumb mode `vqsub.s8 q15,q3,q2'
/tmp/ccfRT8yn.s:50: Error: selected processor does not support Thumb mode `vqsub.s8 q11,q1,q4'
/tmp/ccfRT8yn.s:51: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:52: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:53: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:54: Error: selected processor does not support Thumb mode `vand q9,q9,q11'
/tmp/ccfRT8yn.s:55: Error: selected FPU does not support instruction -- `vmov.i8 q15,#0x03'
/tmp/ccfRT8yn.s:56: Error: selected processor does not support Thumb mode `vqadd.s8 q15,q15,q9'
/tmp/ccfRT8yn.s:57: Error: selected processor does not support Thumb mode `vshr.s8 q15,q15,#3'
/tmp/ccfRT8yn.s:58: Error: selected processor does not support Thumb mode `vqadd.s8 q2,q2,q15'
/tmp/ccfRT8yn.s:59: Error: selected FPU does not support instruction -- `vmov.i8 q15,#0x04'
/tmp/ccfRT8yn.s:60: Error: selected processor does not support Thumb mode `vqadd.s8 q15,q15,q9'
/tmp/ccfRT8yn.s:61: Error: selected processor does not support Thumb mode `vshr.s8 q15,q15,#3'
/tmp/ccfRT8yn.s:62: Error: selected processor does not support Thumb mode `vqsub.s8 q3,q3,q15'
/tmp/ccfRT8yn.s:63: Error: selected processor does not support Thumb mode `veor q2,q2,q10'
/tmp/ccfRT8yn.s:64: Error: selected processor does not support Thumb mode `veor q3,q3,q10'
/tmp/ccfRT8yn.s:111: Error: selected processor does not support Thumb mode `vswp d3,d6'
/tmp/ccfRT8yn.s:112: Error: selected processor does not support Thumb mode `vswp d5,d8'
/tmp/ccfRT8yn.s:113: Error: selected processor does not support Thumb mode `vswp q2,q3'
/tmp/ccfRT8yn.s:114: Error: selected processor does not support Thumb mode `vabd.u8 q15,q2,q3'
/tmp/ccfRT8yn.s:115: Error: selected processor does not support Thumb mode `vabd.u8 q14,q1,q4'
/tmp/ccfRT8yn.s:116: Error: selected processor does not support Thumb mode `vqadd.u8 q15,q15,q15'
/tmp/ccfRT8yn.s:117: Error: selected processor does not support Thumb mode `vshr.u8 q14,q14,#1'
/tmp/ccfRT8yn.s:118: Error: selected processor does not support Thumb mode `vqadd.u8 q15,q15,q14'
/tmp/ccfRT8yn.s:119: Error: selected processor does not support Thumb mode `vdup.8 q14,r2'
/tmp/ccfRT8yn.s:120: Error: selected processor does not support Thumb mode `vcge.u8 q9,q14,q15'
/tmp/ccfRT8yn.s:121: Error: selected FPU does not support instruction -- `vmov.i8 q10,#0x80'
/tmp/ccfRT8yn.s:122: Error: selected processor does not support Thumb mode `veor q1,q1,q10'
/tmp/ccfRT8yn.s:123: Error: selected processor does not support Thumb mode `veor q2,q2,q10'
/tmp/ccfRT8yn.s:124: Error: selected processor does not support Thumb mode `veor q3,q3,q10'
/tmp/ccfRT8yn.s:125: Error: selected processor does not support Thumb mode `veor q4,q4,q10'
/tmp/ccfRT8yn.s:126: Error: selected processor does not support Thumb mode `vqsub.s8 q15,q3,q2'
/tmp/ccfRT8yn.s:127: Error: selected processor does not support Thumb mode `vqsub.s8 q11,q1,q4'
/tmp/ccfRT8yn.s:128: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:129: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:130: Error: selected processor does not support Thumb mode `vqadd.s8 q11,q11,q15'
/tmp/ccfRT8yn.s:131: Error: selected processor does not support Thumb mode `vand q9,q9,q11'
/tmp/ccfRT8yn.s:132: Error: selected FPU does not support instruction -- `vmov.i8 q15,#0x03'
/tmp/ccfRT8yn.s:133: Error: selected processor does not support Thumb mode `vqadd.s8 q15,q15,q9'
/tmp/ccfRT8yn.s:134: Error: selected processor does not support Thumb mode `vshr.s8 q15,q15,#3'
/tmp/ccfRT8yn.s:135: Error: selected processor does not support Thumb mode `vqadd.s8 q2,q2,q15'
/tmp/ccfRT8yn.s:136: Error: selected FPU does not support instruction -- `vmov.i8 q15,#0x04'
/tmp/ccfRT8yn.s:137: Error: selected processor does not support Thumb mode `vqadd.s8 q15,q15,q9'
/tmp/ccfRT8yn.s:138: Error: selected processor does not support Thumb mode `vshr.s8 q15,q15,#3'
/tmp/ccfRT8yn.s:139: Error: selected processor does not support Thumb mode `vqsub.s8 q3,q3,q15'
/tmp/ccfRT8yn.s:140: Error: selected processor does not support Thumb mode `veor q2,q2,q10'
/tmp/ccfRT8yn.s:141: Error: selected processor does not support Thumb mode `veor q3,q3,q10'
/tmp/ccfRT8yn.s:143: Error: selected processor does not support Thumb mode `vswp d5,d6'
/tmp/ccfRT8yn.s:254: Error: selected processor does not support Thumb mode `vswp d3,d4'
/tmp/ccfRT8yn.s:255: Error: selected processor does not support Thumb mode `vqdmulh.s16 q8,q2,d0[0]'
/tmp/ccfRT8yn.s:256: Error: selected processor does not support Thumb mode `vqdmulh.s16 q9,q2,d0[1]'
/tmp/ccfRT8yn.s:257: Error: selected processor does not support Thumb mode `vqadd.s16 d22,d2,d3'
/tmp/ccfRT8yn.s:258: Error: selected processor does not support Thumb mode `vqsub.s16 d23,d2,d3'
/tmp/ccfRT8yn.s:259: Error: selected processor does not support Thumb mode `vshr.s16 q8,q8,#1'
/tmp/ccfRT8yn.s:260: Error: selected processor does not support Thumb mode `vqadd.s16 q8,q2,q8'
/tmp/ccfRT8yn.s:261: Error: selected processor does not support Thumb mode `vqsub.s16 d20,d18,d17'
/tmp/ccfRT8yn.s:262: Error: selected processor does not support Thumb mode `vqadd.s16 d21,d19,d16'
/tmp/ccfRT8yn.s:263: Error: selected processor does not support Thumb mode `vqadd.s16 d2,d22,d21'
/tmp/ccfRT8yn.s:264: Error: selected processor does not support Thumb mode `vqadd.s16 d3,d23,d20'
/tmp/ccfRT8yn.s:265: Error: selected processor does not support Thumb mode `vqsub.s16 d4,d23,d20'
/tmp/ccfRT8yn.s:266: Error: selected processor does not support Thumb mode `vqsub.s16 d5,d22,d21'
/tmp/ccfRT8yn.s:267: Error: selected processor does not support Thumb mode `vzip.16 q1,q2'
/tmp/ccfRT8yn.s:268: Error: selected processor does not support Thumb mode `vzip.16 q1,q2'
/tmp/ccfRT8yn.s:269: Error: selected processor does not support Thumb mode `vswp d3,d4'
/tmp/ccfRT8yn.s:270: Error: selected processor does not support Thumb mode `vqdmulh.s16 q8,q2,d0[0]'
/tmp/ccfRT8yn.s:271: Error: selected processor does not support Thumb mode `vqdmulh.s16 q9,q2,d0[1]'
/tmp/ccfRT8yn.s:272: Error: selected processor does not support Thumb mode `vqadd.s16 d22,d2,d3'
/tmp/ccfRT8yn.s:273: Error: selected processor does not support Thumb mode `vqsub.s16 d23,d2,d3'
/tmp/ccfRT8yn.s:274: Error: selected processor does not support Thumb mode `vshr.s16 q8,q8,#1'
/tmp/ccfRT8yn.s:275: Error: selected processor does not support Thumb mode `vqadd.s16 q8,q2,q8'
/tmp/ccfRT8yn.s:276: Error: selected processor does not support Thumb mode `vqsub.s16 d20,d18,d17'
/tmp/ccfRT8yn.s:277: Error: selected processor does not support Thumb mode `vqadd.s16 d21,d19,d16'
/tmp/ccfRT8yn.s:278: Error: selected processor does not support Thumb mode `vqadd.s16 d2,d22,d21'
/tmp/ccfRT8yn.s:279: Error: selected processor does not support Thumb mode `vqadd.s16 d3,d23,d20'
/tmp/ccfRT8yn.s:280: Error: selected processor does not support Thumb mode `vqsub.s16 d4,d23,d20'
/tmp/ccfRT8yn.s:281: Error: selected processor does not support Thumb mode `vqsub.s16 d5,d22,d21'
/tmp/ccfRT8yn.s:287: Error: selected processor does not support Thumb mode `vrshr.s16 d2,d2,#3'
/tmp/ccfRT8yn.s:288: Error: selected processor does not support Thumb mode `vrshr.s16 d3,d3,#3'
/tmp/ccfRT8yn.s:289: Error: selected processor does not support Thumb mode `vrshr.s16 d4,d4,#3'
/tmp/ccfRT8yn.s:290: Error: selected processor does not support Thumb mode `vrshr.s16 d5,d5,#3'
/tmp/ccfRT8yn.s:291: Error: selected processor does not support Thumb mode `vzip.16 q1,q2'
/tmp/ccfRT8yn.s:292: Error: selected processor does not support Thumb mode `vzip.16 q1,q2'
/tmp/ccfRT8yn.s:293: Error: selected processor does not support Thumb mode `vmovl.u8 q8,d6'
/tmp/ccfRT8yn.s:294: Error: selected processor does not support Thumb mode `vmovl.u8 q9,d7'
/tmp/ccfRT8yn.s:295: Error: selected processor does not support Thumb mode `vqadd.s16 q1,q1,q8'
/tmp/ccfRT8yn.s:296: Error: selected processor does not support Thumb mode `vqadd.s16 q2,q2,q9'
/tmp/ccfRT8yn.s:297: Error: selected processor does not support Thumb mode `vqmovun.s16 d0,q1'
/tmp/ccfRT8yn.s:298: Error: selected processor does not support Thumb mode `vqmovun.s16 d1,q2'
/tmp/ccfRT8yn.s:333: Error: selected processor does not support Thumb mode `vaddl.s16 q2,d0,d3'
/tmp/ccfRT8yn.s:334: Error: selected processor does not support Thumb mode `vaddl.s16 q3,d1,d2'
/tmp/ccfRT8yn.s:335: Error: selected processor does not support Thumb mode `vsubl.s16 q4,d1,d2'
/tmp/ccfRT8yn.s:336: Error: selected processor does not support Thumb mode `vsubl.s16 q5,d0,d3'
/tmp/ccfRT8yn.s:337: Error: selected FPU does not support instruction -- `vadd.s32 q0,q2,q3'
/tmp/ccfRT8yn.s:338: Error: selected FPU does not support instruction -- `vsub.s32 q2,q2,q3'
/tmp/ccfRT8yn.s:339: Error: selected FPU does not support instruction -- `vadd.s32 q1,q5,q4'
/tmp/ccfRT8yn.s:340: Error: selected FPU does not support instruction -- `vsub.s32 q3,q5,q4'
/tmp/ccfRT8yn.s:341: Error: selected processor does not support Thumb mode `vswp d1,d4'
/tmp/ccfRT8yn.s:342: Error: selected processor does not support Thumb mode `vswp d3,d6'
/tmp/ccfRT8yn.s:343: Error: selected processor does not support Thumb mode `vtrn.32 q0,q1'
/tmp/ccfRT8yn.s:344: Error: selected processor does not support Thumb mode `vtrn.32 q2,q3'
/tmp/ccfRT8yn.s:345: Error: selected FPU does not support instruction -- `vmov.s32 q4,#3'
/tmp/ccfRT8yn.s:346: Error: selected FPU does not support instruction -- `vadd.s32 q0,q0,q4'
/tmp/ccfRT8yn.s:347: Error: selected FPU does not support instruction -- `vadd.s32 q6,q0,q3'
/tmp/ccfRT8yn.s:348: Error: selected FPU does not support instruction -- `vadd.s32 q7,q1,q2'
/tmp/ccfRT8yn.s:349: Error: selected FPU does not support instruction -- `vsub.s32 q8,q1,q2'
/tmp/ccfRT8yn.s:350: Error: selected FPU does not support instruction -- `vsub.s32 q9,q0,q3'
/tmp/ccfRT8yn.s:351: Error: selected FPU does not support instruction -- `vadd.s32 q0,q6,q7'
/tmp/ccfRT8yn.s:352: Error: selected processor does not support Thumb mode `vshrn.s32 d0,q0,#3'
/tmp/ccfRT8yn.s:353: Error: selected FPU does not support instruction -- `vadd.s32 q1,q9,q8'
/tmp/ccfRT8yn.s:354: Error: selected processor does not support Thumb mode `vshrn.s32 d1,q1,#3'
/tmp/ccfRT8yn.s:355: Error: selected FPU does not support instruction -- `vsub.s32 q2,q6,q7'
/tmp/ccfRT8yn.s:356: Error: selected processor does not support Thumb mode `vshrn.s32 d2,q2,#3'
/tmp/ccfRT8yn.s:357: Error: selected FPU does not support instruction -- `vsub.s32 q3,q9,q8'
/tmp/ccfRT8yn.s:358: Error: selected processor does not support Thumb mode `vshrn.s32 d3,q3,#3'
make[2]: *** [3rdparty/libwebp/CMakeFiles/libwebp.dir/dsp/dec_neon.c.o] Error 1
make[1]: *** [3rdparty/libwebp/CMakeFiles/libwebp.dir/all] Error 2
make: *** [all] Error 2


Plottable#plot freezes

Sometimes it works. Now it stopped working for the same dataset.
It freezes here https://github.com/dilcom/gnuplotrb/blob/master/lib%2Fgnuplotrb%2Fplot.rb#L87

@Zhomart couldn't you please provide me with the dataset and the code you're using? Probably it's an issue in options handling and I need more details to dig into it.

@dilcom Here is the dataset
ds_ary = [
  [ [[0, 0, 700, 700, 1250], [0, 800, 0, 800, 0]], {:with=>"points", :title=>"Border", :linestyle=>{:pointtype=>1, :ps=>2}} ],
]

GnuplotRB::Plot.new(*ds_ary).to_png("a.png")

This code worked several days ago, I don't know what did I change, now it doesn't work.
Other info
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]

gem 'gnuplotrb', github: 'SciRuby/gnuplotrb'

Wait, it started working. This line was incorrect :linestyle=>{:pointtype=>1, :ps=>2}.
Initially I put it because gnuplotrb didn't work, and I wanted to play with other gem gnuplot.
Now it works!
Thank you! I'll re-open this issue if it stops working again.


Ignoring assigned Build and Testsettings during Testplan migration

If a build was assigned in source testplan then migration fails with error message because original build does not exist in new target testplan.
This PR is fixing this issue by ignoring the not supported artifcat Build and test settings.
Error message:
"Unhandled Exception: Microsoft.TeamFoundation.TestManagement.Client.TestObjectNotFoundException: Build vstfs:///Build/Build/13735 cannot be found. ---> System.Web.Services.Protocols.SoapException: Build vstfs:///Build/Build/13735 cannot be found."

Hello Martin, I close this pull request, because the changes have already been applied by the other pull request.


Remove dockerversion from registry package

dockerversion requires autogen to run before build, otherwise the version is wrong.
The registry package needs to be used by both client and daemon, but if the client is built externally, it shouldn't need to run the docker/docker autogen first.
This removes the dockerversion import from the registry package, and has it passed in by the caller instead.
I'll squash my commits after review.

LGTM, though I think it's unfortunate to add a new parameter to several functions. I wonder if the user-agent header could be folded into metaHeaders, and the functions that don't already take metaHeaders could use that instead for consistency.

Hmm, I read some comments that claimed metaHeaders is modified to add a X-Meta prefix to the headers, so I didn't want to put the user agent into the same map, but I'm not sure if that's still true. I'll look again.

I think those comments are now a lie, so I should be able to put the user agent into metaHeaders

@aaronlehmann I remember now why I didn't just merge them into metaHeaders. This function used to guarantee that a proper user agent was set. By keeping it a separate parameter, there is less of a guarantee that the user agent is "correct", but at least it makes it clear that a user agent is required.

ping @dmcgowan , feedback would be appreciated. This is the last blocker I have for the client package, I'd like to try and get it merged this week.

Small nit but otherwise LGTM, I agree with Aaron but not something that needs to be solved with this PR.

ping @tiborvass @calavera  I believe I have signoff from the distribution team.
I'd like to get this merge so I can proceed with my client work.

ping @calavera @tiborvass ^^

Needs a rebase.
but LGTM 🐮

Rebased and squashed

The test failure is unrelated I think DockerSuite.TestSearchOnCentralRegistry seems to be failing on other branches as well.

@dnephin yep, docker search busybox (or any image) doesn't work on master >_<.

Possibly a temporary issue with Docker Hub, seeing that it also was reported here; https://github.com/docker/hub-feedback/issues/540

Yup, looks to be fixed now (just the windows build failing).

ping, I'd like to get this merged to unblock my client work.

LGTM


Require a module located in static folder

In my application, I am trying to require a module named test that is located inside the /static folder, through the __static variable:
const test = require(`${__static}/test`);

This works well in development, but after packaging I have the following error:
Uncaught Error: Cannot find module '/Users/jroy/Workspace/test/build/Test.app/Contents/Resources/app.asar/dist/electron/static/test'
    at e (renderer.js:1)
    at Module.<anonymous> (renderer.js:1)
    at d (renderer.js:1)
    at renderer.js:1
    at renderer.js:1

If I check what is inside the app.asar:
$ asar list app.asar | grep "static/test"
/dist/electron/static/test
/dist/electron/static/test/index.js
/dist/electron/static/test/package.json
/static/test
/static/test/index.js
/static/test/package.json

How can I fix this?

Are these helpful? Using CSS Frameworks & Using Static Assets. You can have a try.
I haven't packaged an electron app yet. So it may not be particularly useful, apologize for that.😄


Update manifest.json w/ more info & icons

Update manifest.json

browser specific settings are important, let them stay

browser specific settings are important, let them stay

Done!


Syntax highlighting does not work in 1.9rc2

Gitea version (or commit ref): 1.9.0+rc2-1-ga29e667ef built with GNU Make 4.1, go1.12.7 : bindata,
sqlite, sqlite_unlock_notify
Git version: 2.17.1
Operating system: Ubuntu Bionic x86_64
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Description
In this release the code highlighting does not activate when viewing files, even though index.js seems to call it. The <code> element ends up with an empty class string and no highlighting occurs.
Downgrading to 1.8.3 fixes the problem.

I can see this on try.gitea.io here. I suspect it might be related to the recent jQuery update on the 1.9 branch.

Seems like some kind of race condition with the highlight. If I do a no-cache reload in Firefox (CTRL-Shift-R), it highlights correctly.

Thanks for checking that. try.gitea.io was too slow / broken for me to find any actual files yesterday to confirm :(

i put  these to solve this problem for now ...
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.8/styles/github.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.8/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

Hi there,
I'm now on 1.9.3 and this issue is still present, highlighting only activates maybe ~ 50% of the time on page loads :(

Could you try to clean the cache of browser?


Error handling when instantiating experimenter actions

I'm not sure this is only on kytos/of_core or if it also propagates through kytos/flow_manager. Anyway, when using kytos/noviflow napp and submitting a request for SetBFD Experimenter Action, the of_core raised an exception and stopped working. The switches then disconnected.
The request I've sent was:
curl http://<IP_ADDRESS>:8181/api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:0c -H Content-type: application/json -d {"flows": [{"priority": 100, "match": {"in_port": 23, "dl_src": "11:22:33:44:55:66"}, "actions": [{"action_type": "set_bfd", "port_no": 1, "my_disc": 1, "interval": 5, "multiplier": 3, "keep_alive_timeout": 15}]}]}

The request was inspired by the kytos/noviflow unit test: https://github.com/kytos-ng/noviflow/blob/master/tests/unit/test_main.py#L62-L74
Error from Kytos log:
Oct 26 20:53:51 8ba74f12c575 kytos.napps.kytos/of_core:ERROR main:319:  UBInt16(775) is not a valid GenericFailedCode

Maybe we should enhance the error handling on of_core to avoid cases like this breaking the Napp

Looking deeper into this issue, I couldnt find the actual exception raised from kytos/of_core. The message above was actually just a log.error, it shouldn't impact the overall controller execution. In fact, right after this message the switch lost connection. More investigation is being conducted now.

Please disregard this issue report. I found out it was a problem with the OpenFlow channel at the switch.

This seems to be more related to handling OFP_Errors, which could be enhanced from kytos-ng/noviflow (to be investigated)


[release-0.23] Upgrade to latest dependencies

webhook fixes -dprotaso
/cc knative-sandbox/source-wg-leads
/assign knative-sandbox/source-wg-leads
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/pkg 4564797...8d4b5e0:
  > 8d4b5e0 [release-0.23] allow unknown metadata fields (# 2256)
  > a0d1c92 Drop redundant pointers and decoders (# 2261)
bumping knative.dev/hack 93ad912...509255f:
  > 509255f Do not print debug info when running release.sh (# 71)
bumping knative.dev/eventing 200e54c...4e6cde3:
  > 4e6cde3 [release-0.23] [PingSource] disable @every (# 5591)
  > a5a8f89 Fix subtest client scope (# 5532)
  > ecc1c20 Update Knative dependency for release-0.23 (# 5470)
  > aa5d54e Fix cloudevent adapter panic (# 5425)
  > e3ad363 Add podAntiAffinity labels to remaining HA control plane pods (# 5413)

/lgtm
/approve


send_reliable_submission() throwing unexpected keyword argument 'transaction_type'

Using safe_sign_transaction() to sign offline
Returns the following kwarg as part of my_tx_payment_signed
transaction_type=<TransactionType.PAYMENT: 'Payment'>
Attempting to submit my_tx_payment_signed using send_reliable_submission()
returns the following error
TypeError: init() got an unexpected keyword argument 'transaction_type'
Everything else works pretty great!
Any advise greatly appreciated.
SBAL in Seattle

Would it be possible for you to share the exact code that you called (excluding keys/accounts)?
(Or maybe the stacktrace?)
I'm not quite sure what init is, or where it's being called from, so I'm not sure why there's a type error. (Normally if there's a runtime error in send_reliable_submission it raises an XRPLReliableSubmissionException

Thanks for the quick reply Jackson!
Here are the two py's I'm using which I essentially lifted from the
main page of the xrpl-py repo, minor mods made for my specific use
case which is simply 1) Sign tx offline and then 2) Submit tx online

# From https://github.com/XRPLF/xrpl-py

Adding modifying for use case
create a network client
from xrpl.clients import JsonRpcClient
JSON_RPC_URL = "https://xrplcluster.com"
client = JsonRpcClient(JSON_RPC_URL)
Configure existing wallet for transaction using seed / secret
Also get wallet sequence while connected using get_account_info.py
Look for JSON key --> "Sequence": 59996405, etc.
import os
os.system('clear')
using secret = shSxC2CM9eiDcrtEuUugE4mKGwB3N for testing
secret = input(f"\nEnter exisiting source wallet seed / secret : ")
wallet_sequence = int(input(f"\nEnter wallet sequence from
get_account_info.py : "))
from xrpl.wallet import Wallet
wallet = Wallet(seed=secret, sequence=wallet_sequence)
from xrpl.models.transactions import Payment
from xrpl.transaction import safe_sign_transaction
latest_validated_ledger_sequence = int(input(f"""
Enter latest validated ledger sequence
from get_trx_fee_lvls.py online : """))
prepare the transaction
the amount is expressed in drops, not XRP
see https://xrpl.org/basic-data-types.html#specifying-currency-amounts
from xrpl.utils import xrp_to_drops
Note : adding 200 to ledger sequence allows roughly 10 minutes to
submit tx
my_tx_payment = Payment(
account=wallet.classic_address,
fee="10",
sequence=wallet_sequence,
last_ledger_sequence=latest_validated_ledger_sequence + 200,
amount=xrp_to_drops(22),
destination="rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe"
)
print(my_tx_payment)
sign the transaction
my_tx_payment_signed = safe_sign_transaction(my_tx_payment, wallet)
os.system('clear')
print(f"""\nSigned Transaction :
{my_tx_payment_signed}\n""")

from xrpl.clients import JsonRpcClient
JSON_RPC_URL = "https://s2.ripple.com:51234/"
JSON_RPC_URL = "https://xrplcluster.com"
client = JsonRpcClient(JSON_RPC_URL)
from xrpl.models.transactions import Payment
my_tx_payment_signed = Payment(
Enter output from sign_trx.py here
remove transaction_type=<TransactionType.PAYMENT: 'Payment'>
and it seems to run through to final ledger error as expected
)
from xrpl.transaction import send_reliable_submission
try:
submit the transaction
tx_response = send_reliable_submission(my_tx_payment_signed, client)
print(f"\ntx_response")
except Exception as e:
print(f"\nError : {e}\n")
Here's the output

File
"/home/xxxxxxx/.local/lib/python3.8/site-packages/xrpl/models/utils.py", line
60, in new_init
    original_init(self, **kwargs)
TypeError: init() got an unexpected keyword argument 'transaction_type'

I'm a relatively new Pythoner and not a software expert by any means
but do have some pretty good working code for command line trading and
hopefully soon enough might have a bot up and running :)
Thanks again for looking at this!
Quoting Jackson Mills @.***>:

Would it be possible for you to share the exact code that you
called (excluding keys/accounts)?
(Or maybe the stacktrace?)
I'm not quite sure what init is, or where it's being called from,
so I'm not sure why there's a type error. (Normally if there's a
runtime error in send_reliable_submission it raises an
XRPLReliableSubmissionException
—
Reply to this email directly, view it on GitHub[1], or unsubscribe[2].
You are receiving this because you authored the thread.Message ID:
@.***>

Links:
[1] https://github.com/XRPLF/xrpl-py/issues/414#issuecomment-1175592282
[2]
https://github.com/notifications/unsubscribe-auth/AXLE4HL7633RJWYIMIM6J3DVSS63FANCNFSM52UKGRBA

Copying the code into a code block:
# From https://github.com/XRPLF/xrpl-py

   # Adding modifying for use case
   # create a network client
   from xrpl.clients import JsonRpcClient
   JSON_RPC_URL = "https://xrplcluster.com/"
   client = JsonRpcClient(JSON_RPC_URL)

   # Configure existing wallet for transaction using seed / secret
   # Also get wallet sequence while connected using get_account_info.py
   # Look for JSON key --> "Sequence": 59996405, etc.

   import os
   os.system('clear')

   # using secret = shSxC2CM9eiDcrtEuUugE4mKGwB3N for testing

   secret = input(f"\nEnter exisiting source wallet seed / secret : ")
   wallet_sequence = int(input(f"\nEnter wallet sequence from get_account_info.py : "))

   from xrpl.wallet import Wallet
   wallet = Wallet(seed=secret, sequence=wallet_sequence)

   from xrpl.models.transactions import Payment
   from xrpl.transaction import safe_sign_transaction

   latest_validated_ledger_sequence = int(input(f"""
   Enter latest validated ledger sequence
   from get_trx_fee_lvls.py online : """))

   # prepare the transaction
   # the amount is expressed in drops, not XRP
   # see https://xrpl.org/basic-data-types.html#specifying-currency-amounts

   from xrpl.utils import xrp_to_drops

   # Note : adding 200 to ledger sequence allows roughly 10 minutes to
submit tx

   my_tx_payment = Payment(

   account=wallet.classic_address,
   fee="10",
   sequence=wallet_sequence,
   last_ledger_sequence=latest_validated_ledger_sequence + 200,
   amount=xrp_to_drops(22),
   destination="rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe"
   )

   print(my_tx_payment)

   # sign the transaction
   my_tx_payment_signed = safe_sign_transaction(my_tx_payment, wallet)

   os.system('clear')

   print(f"""\nSigned Transaction :

   {my_tx_payment_signed}\n""")
---------------------------------

    from xrpl.clients import JsonRpcClient

   # JSON_RPC_URL = "https://s2.ripple.com:51234/"
   JSON_RPC_URL = "https://xrplcluster.com/"
   client = JsonRpcClient(JSON_RPC_URL)

   from xrpl.models.transactions import Payment

   my_tx_payment_signed = Payment(

   # Enter output from sign_trx.py here
   # remove transaction_type=<TransactionType.PAYMENT: 'Payment'>
   # and it seems to run through to final ledger error as expected
   )

   from xrpl.transaction import send_reliable_submission

   try:
   # submit the transaction
   tx_response = send_reliable_submission(my_tx_payment_signed, client)
   print(f"\ntx_response")

   except Exception as e:
   print(f"\nError : {e}\n")

You actually shouldn't be passing in a transaction_type param at all - that's done under the hood for you in the payment object.

Ok so I tried your edit Jackson and still got unexpected keyword argument 'TransactionType'.
Per mvadari I can remove the transaction_type from the output of safe_sign_transaction() and this does seem to clear the input parameters hurdle for submission step but my question is simply this . . if the safe_sign_transaction() gives me an output with this parameter then I would need to scrub it before passing in my_tx_payment_signed to send_reliable_submission() and hope that the Ledger validates the transaction as payment type? Should we get an update to the return() of safe_sign?
Screenshots added for clarity. Ignore output of send_reliable_submission, it's not a valid transaction obvi.

If you print out the payment before it's signed, it will also show that it has the element transaction_type. What happens under the hood is that the payment __init__ adds in the transaction_type param for you automatically, since it's inferred from the class type. So you don't need to strip it from anything, you just don't need to add it as a parameter when you create the object.


php version error on Ch2 docker-compose.yml

running the install.sh for Ch2 (p35) gives error
pimcore/pimcore[v11.0.4, ..., v11.0.6] require php ~8.1.0 || ~8.2.0 -> your php version (8.0.10) does not satisfy that requirement.
appears current pimcore docker image requires 8.2 but Ch2 docker-compose.yml specifies pimcore/pimcore:PHP8.0-apache
doesn't look like there is a pimcore/pimcore 8.2 apache
docker-compose.yml requires update to correct apache image; failed with change to library/php:8.2-apache
will do a basic pimcore docker install from std gh repo for now
enjoying the book - thx - John

hello @jzedwards
this is because, in the last few days, pimcore changed the main (default) version of pimcore, due to the release of Pimcore 11. So, now, if you do not specify anything the new installation using COMPOSER_MEMORY_LIMIT=-1 composer create-project pimcore/skeleton tmp downloads the latest version, that's not compatible with the container specified in the docker composer.
The solution that works on my local is to simply specify the proper version into the composer command, for example adding 10.2 suffix:
COMPOSER_MEMORY_LIMIT=-1 composer create-project pimcore/skeleton:10.2 tmp
This has to be done in all install.sh scripts of each chapter before installation.

thanks for update; back to learning today


ci: Only create table in ci when pushing to main

Fix for  #471 and https://github.com/embeddings-benchmark/mteb/commit/22ca0e4e941b14d62d543d866fb4daecacdd2805.
issue

For users without MTEB push access, the check-points CI step will face this error in the PR:

Error: Input required and not supplied: token

Even when new points files were added, the ci workflow did not register changes at the git diff step, so it always exits.

Fix is to

split check points into 2 jobs: a) check points, b) create table
only run che when pushing to the main branch.
run git add after git diff

Though I'm not sure I've found why the CI run when pushing to main did not update the table. e.g. https://github.com/embeddings-benchmark/mteb/actions/runs/8770780417/job/24067725233
The push table step shows Everything up-to-date

Hmm but we want to run the score check on the PR.
A solution might be to split it in two:
# runs all all PRs
  check-points:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: "3.8"
          cache: "pip"
      - name: Install dependencies
        run: |
          make install
      - name: Validate jsonl points files
        run: python docs/mmteb/validate_points.py
      - name: Create table
        run: python docs/mmteb/create_points_table.py

# seperate file that only runs on main
  create_table:
    steps:
      - uses: actions/checkout@v3
        with:
          token: ${{ secrets.RELEASE }}
      - uses: actions/setup-python@v4
        with:
          python-version: "3.8"
          cache: "pip"
      - name: Install dependencies
        run: |
          make install
          pip install tabulate # for the table creation
      - name: Push table
        # only run on push to main
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
         run: |
           ...

Oh yes, I got it mixed up. Let's do this:

validate points in every PR
only create table for pushing to main

What do you think?

Yep, let so go for that

Hmm seems like it didn't @isaac-chung

Investigating. I thought I had a solution with git diff-index --quiet HEAD but I wanted to test it out on my fork first.


training batch size

Hi, here the config uses batch size 4 for training, so in total 32 for 8-gpu machine, but batch size in solov2 paper is 16, I'm wondering if bs=16 has lower performance, or similar with bs=32 and you just want to training faster? Thanks !

Just want to training faster.

so may be bs=16 could have better performance

You can try and test.

thanks


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 16:24:29 on 2023.04.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 16967
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=16967

Problem has been resolved in 3m 0s at 16:27:29 on 2023.04.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 16967


Update icons and screenshots from the excel file

[X] I have read the contributing guidelines, and I agree with the Code of Conduct.
[X] Have you checked that there aren't other open pull requests for the same changes?
[X] Have you tested that the committed code can be executed without errors?
[X] This PR is not composed of garbage changes used to farm GitHub activity to enter potential Crypto AirDrops.
Any user suspected of farming GitHub activity with crypto purposes will get banned. Submitting broken code wastes the contributors' time, who have to spend their free time reviewing, fixing, and testing code that does not even compile breaks other features, or does not introduce any useful changes. Thank you for your understanding.

https://github.com/marticliment/UniGetUI/pull/2353/commits/979244590bba9642508be83522339d8f39a7bea5

but this changes nothing?

Why?

Why?

Since it is the same.

I don't want to confuse git too much as I have already had bad experiences with merging nonchanged PRs


Can't enumerate on winxp

The minimum os requirements state winxp sp3, however in my retro build using winxp sp3 the router provides no enumeration through Alcaps viewer nor does it route to soft_oal or any creative  openal dll after a rename.  Openal soft works on it's own.
Does this actually work on xp?

https://github.com/kcat/dsoal/issues/22

Not sure how this answers my question, as the eaxefx router is stated to work on xpsp3, and doesn't rely on dsoal.  Unless I'm misunderstanding how this router works.  Soft_oal is one of the driver names the router works with, and soft_oal works on winxp.

The only problem I encounter is crash of ALCapsViewer32.exe and EnumerateWin32.exe from OpenAL tools.
Here is result of fix:

Thank you. I also experienced a crash in quake 4 using this router, so hopefully this resolved that as well (on winxp).


Convert whole folder of code

Hello,
It's very greate if zzzprojects can perform user to upload a zip file and then convert all relating code files in the zip.
Thanks a lot.
Cho

Hello @tayduivn ,
Thank you for your suggestion.
While output as a zip could eventually happen, I don't think uploading a zip file will ever happen for security reasons.
Best Regards,
Jon


Add support for PC Engines APU2

Add the signature.
Fix allocator issues. coreboot reports page 0 as reserved and this breaks
the address space map allocator. Coreboot also reports memory starting at
0xc0000 as usable, and the asm code would toss that -- in the process, tossing
all of memory.
asm has turned out to be a bit fragile. It can't function without having memory
start at 0. But the code is a bit subtle, so be careful if you decide to adjust it.
Add a comment to mmuinit to explain an error message that is seen all too often.

please test on real hardware


Issue 1168: Replacing ResourceCloser with try-with-resources statements

Fixes #1168 .
Replaced ResourceCloser in the concerned classes and deleted it afterwards.
All four acceptance tests pass.
Side note: In the diff an additional class (TestCaseWithNugetPackageGeneration) appears as changed.
I did not modify it at all, only open it once.

Thanks for your help, @ogryniuk! :)


bug: Issue with selectbox in Ionic 2

Type: bug
Ionic Version: 2.x
Platform: desktop browser

Selected item not working when binding to an array of objects. Also I noticed that in nightly, the text labels for each option are hidden, whereas in 2 beta 10 the text labels do show up.
http://plnkr.co/edit/q04871weGL6dXnfLJeza?p=preview

Hello @tones411 , is this still an issue with beta.11? Thanks for using Ionic!

Hello all! As it seems it has been a while since there was any activity on this issue i will be closing it for now. Feel free to comment if you are still running into this issue. Thanks for using Ionic!


:bug: Fix: getFilterLog issue

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

#1337  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @roninjin10 and the rest of your teammates on  Graphite