Deceleration when using runForward/runBackwards fails

I'm using the latest release: 0.23
However, it doesn't seem to occur for every speed from one to another.
e.g. From speed 1 to 0.1 nothing changes.
From 0 or other direction, to 0.1 it does change.
From 5 to 0.1 it changes to something in between.
I set the speed to slower value setSpeedInUs, and call applySpeedAcceleration, but I do not seem to actually decelerate.
The ramp state is set to RAMP_STATE_DECELERATE
Some logs that I am dumping (the stat and evel 1 x are commands sent over the serial, the speed x mm/s is after some gearing etc)
stat
 ExtruderTargetSpeed set to: 0.00mm/s
 Retract speed: 30.00mm/s
 Speed Factor:1.00 Heaters : 0 TEMP : 31.57 Extrudable: 1 Enable?: 1 speeds: INACTIVE_RAMP  Is running? 0 0us Target=0 STOP   IDLE
evel 1 0.1
0.10
191114.06Sent us/step. 191114us/step 0curr us/step
5232.99Sent mHz. 5232mHz 0curr mHz.
3057824Ticks.
updated speed to: 0.10
stat
 ExtruderTargetSpeed set to: 0.10mm/s
 Retract speed: 30.00mm/s
 Speed Factor:1.00 Heaters : 0 TEMP : 31.60 Extrudable: 1 Enable?: 1 speeds: ACTIVE_RAMP  Is running? 1 191114us nonstop RUN   COAST
evel 1 1
1.00
19111.86Sent us/step. 19111us/step 191114curr us/step
52325.41Sent mHz. 52324mHz 5232curr mHz.
305776Ticks.
updated speed to: 1.00
evel 1 0.1
0.10
191114.06Sent us/step. 191114us/step 19111curr us/step
5232.99Sent mHz. 5232mHz 52324curr mHz.
3057824Ticks.
updated speed to: 0.10
stat
 ExtruderTargetSpeed set to: 0.10mm/s
 Retract speed: 30.00mm/s
 Speed Factor:1.00 Heaters : 0 TEMP : 31.65 Extrudable: 1 Enable?: 1 speeds: ACTIVE_RAMP  Is running? 1 19111us nonstop RUN   RED
evel 1 5
5.00
3822.77Sent us/step. 3822us/step 19111curr us/step
261625.04Sent mHz. 261640mHz 52324curr mHz.
61152Ticks.
updated speed to: 5.00
evel 1 1
1.00
19111.86Sent us/step. 19111us/step 4352curr us/step
52325.41Sent mHz. 52324mHz 229776curr mHz.
305776Ticks.
updated speed to: 1.00
stat
 ExtruderTargetSpeed set to: 1.00mm/s
 Retract speed: 30.00mm/s
 Speed Factor:1.00 Heaters : 0 TEMP : 31.62 Extrudable: 1 Enable?: 1 speeds: ACTIVE_RAMP  Is running? 1 9760us nonstop RUN   RED
evel 1 0.1
0.10
191114.06Sent us/step. 191114us/step 9760curr us/step
5232.99Sent mHz. 5232mHz 102456curr mHz.
3057824Ticks.
updated speed to: 0.10
evel 1 2
2.00
9556.18Sent us/step. 9556us/step 9760curr us/step
104650.32Sent mHz. 104644mHz 102456curr mHz.
152896Ticks.
updated speed to: 2.00

I bisected it to commit e938cda . It has the (appears to) have the correct behavior prior to that (up to the tag 0.21.0)

Thanks for the detailed info and bisect-ing down to a commit.
In order to repeat this, the acceleration value is needed.
Can you please provide that value ?

Two more questions:

the curr us/step value uses which lib-call ?
how much time approx. between speed changes ? Or is it just longer than deceleration or acceleration would need ?

don‘t bother. Seems I can repeat the issue

The issue, which I have identified based on your description, is fixed in 0.23.1 (with an appropriate test case). Please check, if this solves your problem, too.
Background:
The calculation uses this formula s = 1/2 * a * t² = v² / 2a for the ramp.
Thus the speed at step s = 1 should be v = sqrt(2*a).
If the acceleration is high enough, then the calculated speed is faster than the setSpeed value.
Thus the deceleration would stay stuck with too high speed.
The fix is to detect this situation and just set the speed to the setSpeed value.

Seems to work! Thanks for the fixes

Thanks for the detailed info and bisect-ing down to a commit.
The acceleration value is needed.
Whoops, 5243 s/s^2


Add automated build process

https://github.com/tanjo3/tww_apworld/pull/1#issuecomment-1984228877

[...] And yeah, I don't have a build script for this; just doing it manually.

https://github.com/tanjo3/tww_apworld/pull/1#issuecomment-1984241428

Would you like me to add a build script for you?

https://github.com/tanjo3/tww_apworld/pull/1#issuecomment-1984249976

Sure, that'd be appreciated. Would this be a GitHub actions workflow? I can commit the sample YAML to the repository.

As previously talked about, what I was thinking is creating a shell script taking care of building the project.
But I was also thinking it might in fact be nice to have a github action in place to do it either on request though the action panel, or based on commits and/or PRs, depending on what you prefer.
And I can make the action yaml file myself unless you want to use a specific template...
Note
dolphin-memory engine can be included using the script included in this comment: https://github.com/tanjo3/tww_apworld/pull/1#issuecomment-1973891777.
Would probably need to simplify it since there's only one dependency so it's kinda overkill.

I've started looking into building the script.
I've noticed, you've been including the base yaml file in your build, but I don't think I saw it in the repo, am I mistaken, is there a reason why it's missing?
I saw you've been including essentially the whole source code in your release, was there a reason for that?
Also, wouldn't it be "simpler" for the user if the tww folder wouldn't be present?
I'd like you to tell me what you think of having the license file of dolphin-memory-engine directly in its folder.
Also I've been taking into consideration the requirement file, when bundling the requirements, so I've been putting those in the a lib folder to mimic the archipelago installation folder. And that way if you decide to add more library they should be processed mostly auto-magically.
By extension I don't know if it would make sense to put the tww.apworld in lib/worlds.
Thoughts?

I've noticed, you've been including the base yaml file in your build, but I don't think I saw it in the repo, am I mistaken, is there a reason why it's missing?

No reason in particular, that's what I meant when I said I can commit the sample YAML to the repository. I'll just do that.

I saw you've been including essentially the whole source code in your release, was there a reason for that? wouldn't it be "simpler" for the user if the tww folder wouldn't be present?

Honestly, I've just kinda followed how the BfBB dev did their apworld releases. I think it's nice to have there just so the user can look at the code if they have concerns, but I suppose they could always just unzip the apworld file. If it'd make the build script easier, then feel free to not include it.

I'd like you to tell me what you think of having the license file of dolphin-memory-engine directly in its folder.

That's probably fine. I'm not familiar with the legalities regarding license files.

Also I've been taking into consideration the requirement file, when bundling the requirements, so I've been putting those in the a lib folder to mimic the archipelago installation folder. And that way if you decide to add more libraries they should be processed mostly auto-magically.
By extension, I don't know if it would make sense to put the tww.apworld in lib/worlds.

So, the user would just have to, say, drag and drop the lib/ folder in the release onto their AP lib/ folder? That's fine, though it will require an update to the setup guide. To some degree, I like having the apworld at the top level, just for "visibility" in that the user can see immediately that they've downloaded the apworld file. But this "ease-of-installation" is probably for the better.

No reason in particular, that's what I meant when I said I can commit the sample YAML to the repository. I'll just do that.

Oh okay, sorry I thought you meant a github action template yaml file. That's my bad.

[...]  I suppose they could always just unzip the apworld file. If it'd make the build script easier, then feel free to not include it.

When it comes to that, the issue I have isn't about the complexity of the the script, it's mostly that i think it might get inexperienced user confused since there's more stuff in the zip. But also it makes the zip heavier (okay, it's just a few files since the repo isn't huge, but still). Lastly, since it's a production build, I just think it's a bit uncommon to have the source code included with the release build (when speaking about software release in general), and users whom are familiar with archipelago in can in fact just unzip the apworld, they also know where the repo is, so they should also be able to just browse the code on github (or clone it).
But. If you rather still have it, then I'll include it. It won't be hard to add that step to the build, it's 1 line.

So, the user would just have to, say, drag and drop the lib/ folder in the release onto their AP lib/ folder? That's fine, though it will require an update to the setup guide. To some degree, I like having the apworld at the top level, just for "visibility" in that the user can see immediately that they've downloaded the apworld file. But this "ease-of-installation" is probably for the better.

never mind. I'll just include the apworld at the root since you prefer it, but also directory merging can be a whole can of worm in itself. Not all OS support directory merging, and if they do, it doesn't mean it will do it the way we expect it.
Though I'll still need to modify the setup steps to say they need to copy the content of the lib folder into archipelago's lib folder.

Alright. Yeah, let's go with removing the source code tww/ folder and keeping the apworld at root, then. Thanks.

I think I'm mostly(tm) done with the initial build script. I am able to generate the archive and it seems to be working from what I've tested.
Here's the folder structure I have atm.
.
├── lib
│   └── dolphin_memory_engine
│       ├── _dolphin_memory_engine.cp311-win_amd64.pyd
│       ├── _dolphin_memory_engine.cpython-311-x86_64-linux-gnu.so
│       ├── __init__.py
│       ├── LICENSE
│       └── version.py
├── LICENSE.md
├── README.md
├── The Wind Waker.yaml
└── tww.apworld

There's still a few things I want to change. But you should be able to start looking into it.
Also I ended up removing the inc folder since it's not needed from what I've tested and it's just a duplicate of the code distributed by the pip package, which we shouldn't have to handle imo.

Also I ended up removing the inc folder since it's not needed from what I've tested and it's just a duplicate of the code distributed by the pip package, which we shouldn't have to handle imo.

I'm not sure this works. I built an apworld with this change and it doesn't seem to be working. Although, it's not raising an errors either, for some reason. Is the apworld working for you?

Okay, if you want to start looking into the build.sh file for review I think you can. I don't think I'll make any more change to it unless the github action stuff gets quirky, but I don't think it will be an issue.

Okay, everything should be good to be reviewed now. The script and the github action are in place.
When it comes to the github action, it should trigger automatically when you create a tag, or when you trigger a manual build from the Action menu.
I didn't think it made much sense to create a build for each commit or pull request since it would just eat you credits needlessly.

Awesome, looked through the code, the script output, and the apworld and it all looks good to me. Very cool stuff! Do you think the installation steps in the setup guide should be modified with the new structure change for the dolphin-memory-engine folder (now that it's in lib/)?

Oh, yeah! I forgot to change that part.
I'll make the change, then if things looks good to you we should be golden!

The change is applied. Just let me know if there's anything else.

Looks good, so I'll merge. From next release onward, I'll use the actions for the builds. Thanks again for this! Great work.
I'd like to add you to the credits of the README. How would you prefer to be named?

It was a pleasure to be able to help!
If you want to add me to the README, you can use "Lunix" as my name.


⚠ ClamAV has degraded performance

In 24a6083, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 448 ms

Resolved: ClamAV performance has improved in 8bfca9b.


Support cross compilation for ARM Linux

有需求的可以在这里提一下。顺便提供一下：

芯片类型和参数
Linux版本
交叉编译器版本
如果支持GPU的话支持提供一下OpenCL的版本和动态库的路径(32/64位)

交叉编译的话，不需要提供芯片类型和参数吧。按理说，只要交叉编译链支持c++11(MACE用了c++11)，只需要提供一个如何进行交叉编译的教程就行了额。
再说了，芯片的种类很多的，每种芯片的交叉编译链都不一样呢。。。

感谢mace这么赞的工作。arm linux需求巨大，支持armv8/aarch64加mali就很通用了。一个栗子
1.rk3399，双a72＋4个a53
2.ubuntu16.04
3.aarch64-linux-g**
4.opencl 1.2
再次感谢

@zhy520xp
需要提供一个bazel toolchain的一个guide，或者你如果跑通了可以反馈一下。
另外需要确认OpenCL的支持情况以及兼容的可行性，因为不同系统差别较大。我们没有开发环境，所以希望收集一下信息，同样如果你跑通了，也请反馈一下，非常感谢。

as @leogift  mentioned, rk3399 is widely used in industry

确实呀， RK3399，这个真的是需要的

https://github.com/zhy520xp/mace-makefile-project  做好了交叉编译，可以参考参考

像3559A和3536这类嵌入式平台，如何编译出能跑gpu版本的东西，是否应该支持一下。。

https://github.com/zhy520xp/mace-makefile-project已经可以把3288和3399的gpu跑起来了。

现在bazel 编译卡住在了 protobuf 的编译问题上。 mace 编译会调用protobuf 交叉编译出来的工具，这样就导致了执行格式错误。

@llhe  目前基本已经整理出了bazel 编译的方法，不过我在3516D 上跑的时间不理想。可以把前面整理的方法提供出来

@hbwangjinwu 赞，可以发一个PR吗？需要显式打开，可以参考此处宏定义：https://github.com/XiaoMi/mace/blob/master/mace/kernels/arm/conv_2d_neon_15x1.cc#L76

bazel 命令加上 --define neon=true

I got it working on the TinkerBoard and made a fork of the Makefile repo with English instructions:
https://github.com/madhavajay/mace-makefile-project
https://github.com/XiaoMi/mace/issues/167

@shuxiao9058 @zhy520xp I don't know why the performance is as it is, perhaps i can improve with different compile flags? However 6 fps is much better than 0.8-1 fps on a RPi 3, so I think the acceleration of MACE is fairly impressive. Any suggestion on faster improvement would be appreciated. I read Winograd is theoretically 2.2x faster?

@madhavajay if your model deploy on cpu,you  can try NCNN（https://github.com/Tencent/ncnn）。NCNN uses Winograd and 8-bit quantization for  convolution computation。You are worth a try!

@zhy520xp okay great I will look at it, thank you! :)

@zhy520xp do you know if it supports SSD MobileNet architecture?

We will add Linaro toolchain soon which will enable official cross compiling for ARM Linux.

近期将会添加一个基于Linaro的默认ARM交叉编译器工具链，支持ARM Linux的交叉编译

@tataganesh95 It will be integrated into the tools soon, and the documents will be updated accordingly.
Before that, you can simply build it with the following commands (not tested yet):
bazel build -s --config aarch64_linux --define openmp=true --define opencl=true --define neon=true //mace/libmace:libmace.so

Note: there is an issue with armeabi-v7a + NEON, which will be resolved soon.

@llhe you guys are awesome! Will test this soon. I assume that this will build on Ubuntu and just needs the correct arm toolchain installed? Is there more instructions for someone like me who isnt experienced with cross compiling?

Where do the neon headers come from are they part of the arm toolchain?

@madhavajay Yes, the toolchain contains libc/libc++/glibc/neon headers/libs. For the default Linaro toolchain, you don't need any installation steps, just run the previous bazel build -s --config aarch64_linux --define openmp=true --define opencl=true --define neon=true //mace/libmace:libmace.so command.
The default toolchain will be automatically downloaded here: https://github.com/XiaoMi/mace/blob/master/WORKSPACE#L150. You are free to change to your customized toolchain.

@llhe Sorry for extending this discussion, but I am not very experienced with cross-compilation, and a little confused regarding the model deployment process. Here are the steps I followed for cross compilation -
Note- I used the mace lite edition docker image

Changed build-standalone-lib.sh to cross-compile for aarch64. This creates the shared and static libraries.
Convert the model ( In this case, the mobilenetV2 model ) using
python tools/converter.py convert --config=/path/to/mace-models/mobilenet-v2/mobilenet-v2.yml with the configuration file present in mace-models. This generates the .pb and .data files.
Now, I am assuming here, that running python tools/converter.py run --config=/path/to/mace-models/mobilenet-v2/mobilenet-v2.yml --example generates an executable in bazel-bin, and this executable, along with the static and shared libraries are to be deployed on the target machine? ( Target  OS - Linux, Target architecture - aarch64 ).
Thank you!

Do you need Android aarch64 or Linux aarch64?

Linux aarch64
Cool! I will wait for Linux aarch64 to be fully supported. I was just trying to understand whether I am cross-compiling mace for linux aarch64 correctly.

if you want to try with ARM Linux aarch64 before all the tools ready, you can build libmace.so by bazel build -s --config aarch64_linux --define openmp=true --define opencl=true --define neon=true //mace/libmace:libmace.so and make the model conversion using the current tools.

I have done the same, ran the example script as well. But since my target os is linux, I am not sure how am I supposed to run example.cc. I could see that an executable named example_static is created when I run python tools/converter.py run --config=/path/to/mace-models/mobilenet-v2/mobilenet-v2.yml --example. When I ran this executable on my aarch64 device, I am able to pass command line parameters to it ( --input_node, --output_node, --device etc ), and run the executable as well ( I am still not getting the desired output for Mobilenet-V2, though.)
I just wanted to know, whether the steps I followed for cross-compilating mace , and running the example on the target device, are right, or have I missed something? ( Steps have been mentioned in my previous comment ),
Eagerly looking forward to tools that can facilitate cross compilation for Arm linux! Thank you once again for such a prompt response!

The result of python tools/converter.py run --config=/path/to/mace-models/mobilenet-v2/mobilenet-v2.yml --example is targeted for Anrdoid ABI. It's undefined when you run the binary in normal ARM Linux system. You can check the difference here: https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ#What_is_the_difference_between_arm-linux-androideabi_arm-linux-gnueabi_toolchain_linux_toolchain.3F

@llhe  I wasn't aware of that. Thank you! I will till the tools for ARM linux are built.

@tataganesh95 I was able to skip the Android stuff just by installing adb which is really easy:
https://github.com/XiaoMi/mace/issues/176
I didnt install the NDK, to get rid of the ADB error I installed adb from here:
https://askubuntu.com/questions/34702/how-do-i-set-up-android-adb

Then:
python tools/converter.py convert --config=/path/to/mace-models/mobilenet-v2/mobilenet-v2.yml

@madhavajay I was able to run the convert script and obtained .data and .pb ( For mobilenet ). But, I was trying to run example.cc through the same script. With few minor changes I was able to run that as well, and that in turn generated an exectuble example_static. I ran this on my target machine and it did ran successfully but generated the wrong output for a sample image ( I was testing the grace hopper image ), so I was just wondering whether I missed a step or am I doing something wrong here.

@tataganesh95 you have gotten further than me. I literally just got it compiled and ran the test code in the make file project. My task was to evaluate if it was possible, I havent had a chance to actually use it yet. Sorry. :) Please let me know if you solve the issue as I will likely have the same problems.

@llhe is there any update on when the Linux aarch 64 architecture might be ready? Do you have any provisional benchmark results for it?

I ran this:
$ bazel build --config arm_linux --define openmp=true --define opencl=true --define neon=true //mace/libmace:libmace.so --sandbox_debug

Got this issue:
arm-linux-gnueabihf-gcc: error: mace_version_script.lds: No such file or directory

Full output:
INFO: Analysed target //mace/libmace:libmace.so (0 packages loaded).
INFO: Found 1 target...

COLLECT_GCC=external/gcc_linaro_7_3_1_arm_linux_gnueabihf/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=external/gcc_linaro_7_3_1_arm_linux_gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/7.3.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/snapshots/gcc.git~linaro-7.3-2018.05/configure' SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared --without-included-gettext --enable-nls --with-system-zlib --disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no --disable-multilib --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --with-tune=cortex-a9 --with-arch=armv7-a --enable-threads=posix --enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-linux-gnueabihf/libc --enable-checking=release --disable-bootstrap --enable-languages=c,c++,fortran,lto --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)
src/main/tools/linux-sandbox-pid1.cc:437: waitpid returned 2
src/main/tools/linux-sandbox-pid1.cc:457: child exited with code 1
src/main/tools/linux-sandbox.cc:204: child exited normally with exitcode 1
Target //mace/libmace:libmace.so failed to build
INFO: Elapsed time: 28.551s, Critical Path: 0.29s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

@llhe any idea why i cant build the same cross compile libmace.so that the gitlab ci file says it builds?

Anyone know how to solve the above?  I'm also trying to solve this.

@pathwayai Do you have the same problem?

@madhavajay
Can you reproduce this error by executing this in the shell?
cd /home/pathwayai/.cache/bazel/_bazel_pathwayai/c7986ad00fc23123aa9184aa80c62d45/execroot/mace

/home/pathwayai/.cache/bazel/_bazel_pathwayai/c7986ad00fc23123aa9184aa80c62d45/execroot/mace/_bin/linux-sandbox -t 15 -w /home/pathwayai/.cache/bazel/_bazel_pathwayai/c7986ad00fc23123aa9184aa80c62d45/sandbox/linux-sandbox/1/execroot/mace -w /tmp -w /dev/shm -D -- tools/arm_compiler/linaro_linux_gcc/arm-linux-gnueabihf-gcc -shared -o bazel-out/armeabi-v7a-fastbuild/bin/mace/libmace/libmace.so -Wl,-soname,libmace.so -Wl,--version-script mace_version_script.lds -fopenmp '--sysroot=external/gcc_linaro_7_3_1_arm_linux_gnueabihf/arm-linux-gnueabihf/libc' '-fuse-ld=gold' -Wl,-no-as-needed -no-canonical-prefixes -v -Wl,-z,relro,-z,now '-Wl,--build-id=md5' '-Wl,--hash-style=gnu' -Wl,-S<EMAIL_ADDRESS>

Depend on

Before that, you can simply build it with the following commands (not tested yet): bazel build -s --config aarch64_linux --define openmp=true --define opencl=true --define neon=true //mace/libmace:libmace.so

I modified the "tools/build-standalone-lib.sh" to get aarch64 libraries:
echo "build shared lib for aarch64 + cpu"
bazel build -s --config optimization --config aarch64_linux --define openmp=true --define opencl=false --define neon=true //mace/libmace:libmace_dynamic
# bazel build --config android --config optimization mace/libmace:libmace_dynamic --define neon=true --define openmp=true --define opencl=true --define quantize=true --cpu=arm64-v8a
cp bazel-bin/mace/libmace/libmace.so $LIB_DIR/aarch64/cpu/

if [[ "$OSTYPE" != "darwin"* ]];then
	echo "build shared lib for linux-x86-64"
	bazel build mace/libmace:libmace_dynamic --config optimization --define quantize=true --define openmp=true
	cp bazel-bin/mace/libmace/libmace.so $LIB_DIR/linux-x86-64/
fi

then got a benchmark result on mobilenet-v1:
---------------------------------------------------------------------
                               Warm Up
----------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |   std |
----------------------------------------------------------------------
|     1 |   598.455 |  598.455 | 598.455 | 598.455 | 598.455 | 0.000 |
----------------------------------------------------------------------

-----------------------------------------------------------------------
                         Run without statistics
------------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |     std |
------------------------------------------------------------------------
|    18 |   566.921 |  566.962 | 566.583 | 568.177 | 566.871 | 315.777 |
------------------------------------------------------------------------

-----------------------------------------------------------------------
                          Run with statistics
------------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |     std |
------------------------------------------------------------------------
|    18 |   568.146 |  566.793 | 566.776 | 570.255 | 567.344 | 851.766 |
------------------------------------------------------------------------

but comparing to the benchmark result on the same model when using the latest release version mace without building libs for aarch64,  it is a bad latency performance degradation:
---------------------------------------------------------------------
                               Warm Up
----------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |   std |
----------------------------------------------------------------------
|     1 |   595.763 |  595.763 | 595.763 | 595.763 | 595.763 | 0.000 |
----------------------------------------------------------------------

-----------------------------------------------------------------------
                         Run without statistics
------------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |     std |
------------------------------------------------------------------------
|    18 |   566.886 |  566.457 | 566.317 | 567.475 | 566.790 | 218.869 |
------------------------------------------------------------------------

-----------------------------------------------------------------------
                          Run with statistics
------------------------------------------------------------------------
| round | first(ms) | curr(ms) | min(ms) | max(ms) | avg(ms) |     std |
------------------------------------------------------------------------
|    18 |   567.311 |  566.841 | 566.702 | 567.405 | 567.010 | 152.689 |
------------------------------------------------------------------------

Question

All the test running on host machine (ubuntu 16.04 X86_64 Intel)
Is this latency performance degradation normal?
Or I'm doing something wrong about this?

Close this which is official supported.

any one already got some benchmark on RK33XX series? we are using RK3399 and we'd love to leverage the Mali 860 on the board. But it seems a hard task. Just wanna get some sense about if the GPU can actually out perform the CPU cus I noticed in the above conversation it seems GPU is not always faster than CPU on mobile platform. BTW, this is really an awesome project! Thanks guys!

@ysyyork we have tested the mobilenet-v1 on RK3399 with GPU, Only Buffer-based OpenCL implementation could outperform the CPU, but only a small amount of Ops support Buffer-based OpenCL now. The detailed usage please refer to document.


Use sklearn GaussianProcessRegression instead of GPy

Not sure how I didn't come across this before....

This turns out to be a very slow implementation for high-dimensional data.


pod-checkpointer: Update to pod-checkpointer image that fixes #432

Fixes #432.

pod-checkpointer pod logs errors as it cannot talk to the kubelet api
as mentioned in the issue.
This is becuase the pod-checkpointer queries the localhost at 10250 and
10255 ports to talk to the kubelet API.
Since in Lokomotive, we run the kubelet as a pod, this causes
connection refused errors as nothing is listening at localhost.
To rectify the above problem, the solution requires chanves in two
places:

Provide a way to access the pod's status.hostIP as an environment
variable named HOST_IP to use instead of localhost. This is done by
modifying the daemonset configuration of kubelet.

Change the pod-checkpointer code to use the HOST_IP from above.
This is done in the PR: https://github.com/kinvolk/bootkube/pull/2

Next we update the image tag to use the new pod-checkpointer image.
The tag includes the commit id which made this change.

Lastly we update the generated assets.

Signed-off-by: Imran Pochi<EMAIL_ADDRESS>

You might wanna mention in the commit message the Kubelet running as a DaemonSet listens on the Host IP of the node and that's why you need the pod checkpointer to access the Host IP.

You might wanna mention in the commit message the Kubelet running as a DaemonSet listens on the Host IP of the node and that's why you need the pod checkpointer to access the Host IP.

done.

Baremetal pipline has been a PITA, @ipochi can you rebase and trigger CI again?

@surajssd @invidian @iaguis CI passes. Please re-review.


doc: documentation for Init.SizeOf

Also adds some missing SizeOf instances for all the types that were presumably added to Init.Prelude after this file was written.
PS: Perhaps this file's contents should be added to Init.Prelude instead and placed as high as possible, probably right after Nat? That would make it easier to keep this list in sync.

PS: Perhaps this file's contents should be added to Init.Prelude instead and placed as high as possible, probably right after Nat? That would make it easier to keep this list in sync.

It might be possible, but it is not worth doing it now.


Add test and CI

Codecov is added to run the tests and display the reports.
Golangci-lint is added to analyze code quality and its life cycle.

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Change preference sheet to page.

change the bottom sheet to full page.

Hey, please explain a bit more about the issue. I'm willing to work on this, please assign it.

Hi, Thank you for taking interest.
When you click hamburger, you will notice that it opens a bottom sheet. My naming conventions, I write bottoms sheets as (sheet) and full screen page as (page). So instead of open the preference screen as bottom sheet open it as full screen.
You will also have to change the class name from "sheet" to "page"
Hope this answers your query. feel free to ask further questions.

OK Got it. will reach out to you if I have any trouble while fixing this.

Sorry I am unable to fix this.

Sorry I am unable to fix this.

Oh Thank you for your time. Let me know if you need assistance in logic building, or code understanding. Or else I'll assign it to myself.


txn-layer-deposit-and-withdrawal

@josehernandezfintecheandomx : Can you review this PR?

Deposit service had no txn layer to validate rules (terms and settings configured at product level like limits). This creates that txn layer where txns of different type can be persisted.

Well done!
Note: This PR already includes the files of the PR https://github.com/apache/fineract-cn-deposit-account-management/pull/19

@fynmanoj : Merged as part of the other PR which was most up to date.


docs: doc site styling for increasing sidebar width to prevent text cutoff

Now the long texts in the sidebar is not cutoff.

Before:

After:

Pull Request Checklist

[ ] Did you add new tests and confirm existing tests pass? (yarn test)
[ ] Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
[ ] Do your commits follow the Conventional Commits standard?
[ ] Does your PR title also follow the Conventional Commits standard?
[ ] If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
[ ] Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
[ ] Did you follow the contribution guidelines?

PR-Codex overview
This PR updates the style.css file in the Vitepress theme to add a new CSS variable for the sidebar width.
Detailed summary

Added a CSS variable --vp-sidebar-width for the sidebar with a value of 320px.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@willhennessy at the moment, we cannot do what viem does (we can but requires vue.js work which is not worth the effort at the moment). For now, will merge this change in and we can plan/execute on more long term solution later. This PR just slightly increase the current sidebar width to remove the nit issues with long function name sections.


Enable Admiring Tokens

[GAL-3983]

This is an awesome start, Rohan! As mentioned in the PR, I realized that there are a few big pieces in this feature, and it makes sense if we break this up into smaller PRs to limit the scope of each. For this PR, let's only worry about saving the admires, and for future PRs we can handle retrieving admires and also supporting notifications.
To support saving token admires, one requirement is that the client will need some way of knowing if the user has already liked a particular token ID. I think you started thinking along those lines with the loadAdmireByActorIDAndTokenID function you added in dataloaders.go. Since the frontend won't use this feature anytime soon, I think we can save this for a later PR, so long as the backend already enforces that a user can only admire a token ID once.
I think we can kill two birds with one stone in a later PR by adding a field to the Token type that returns a connection (connection is just graphQL's name for pagination) that allows the client to paginate through all the admires for a given token
type Token {
   # Returns an admires connection
    admires(
        ...pagination params,
        userID, # client can optionally specify a user to determine if that user already liked a token, should return a list of length 1 if so
    ) AdmiresConnection
}


When a user tries to login with cookies disabled, there is an authentification error without explanation

Bug report given from IRC, by a user:
18:29 < davux> FYI, when a user doesn't allow cookies, there's an authentication error
18:29 < davux> without any explanation

When I turned off cookies and attempted to login, the login page reloads. Do we want to show a "Please accept cookies" notice? I can work on this.

@ctcyu: Yes. Something like. "Your browser does not seem to accept cookies. Please configure your browser to accept cookies."


[Fix] Fix error of new feature if verison of pip is slow

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Related PR: #73
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the back-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
The documentation has been modified accordingly, like docstring or example tutorials.

Codecov Report

Merging #74 (e2ea58d) into main (a64cd64) will decrease coverage by 0.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##             main      #74      +/-   ##
==========================================
- Coverage   63.95%   63.93%   -0.02%
==========================================
  Files          21       21
  Lines        1559     1561       +2
  Branches      346      347       +1
==========================================
+ Hits          997      998       +1
  Misses        428      428
- Partials      134      135       +1

Flag
Coverage Δ

unittests
63.93% <66.66%> (-0.02%)
:arrow_down:

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

Impacted Files
Coverage Δ

mim/commands/install.py
68.22% <66.66%> (-0.16%)
:arrow_down:

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 a64cd64...e2ea58d. Read the comment docs.


Incorrect TF nightly version

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): pip
TensorFlow version: 2.3
Python version: 3.6
Installed using virtualenv? pip? conda?: pip
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

Describe the problem
pip install tf-nightly installs TF v2.5. Shouldn't it be TF v2.3???
PyPI link - https://pypi.org/project/tf-nightly-gpu/2.5.0.dev20200626/
Provide the exact sequence of commands / steps that you executed before running into the problem
import tensorflow as tf
print(tf.__version__)

Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

@AjayReyo Due to some simple mistake in the TF build code, TF2.5 version ( https://pypi.org/project/tf-nightly-gpu/2.5.0.dev20200626/) was created. Correct version is adjusted back to TF2.4dev (https://pypi.org/project/tf-nightly/2.4.0.dev20200630/ ).
As next stable version is TF2.3, the tf-nightly is TF2.4dev2020MMDD (MM, DD- two digits for month and day respectively)
So if you run
import tensorflow as tf
print(tf.__version__)

The output will show correctly as 2.4.0-dev20200630. Sorry for the confusion. Thanks!
Please close the issue if this was resolved for you. Thanks!

This has been resolved.


Increase stability of random_horizontal_flip and random_vertical_flip tests

As noted in #263 these tests fail often (due to a high alpha/type-I error + randomization). In this PR I've:

increase num_samples
reduce alpha
fixed the seed for these tests

Awesome, thanks Aly!


fix(build): fix resolution algorithm when build.ssr is true (#9989)

This is a cherry pick of https://github.com/vitejs/vite/pull/9989, allowing it to be released as part of 3.1

@patak-dev It looks like the base branch, v3.1, might have a few issues here, not related to our changes. Is there anything else I need to bring across

I have directly cherrypicked it to keep the same reference f20d2854be0f00fe1df196df0eb01a8e30f6b43e. Thanks!


support recent versions of the Fantasy Land specification

I actually think it would be a good idea to deprecate this project and update the readme to suggest that people use Fluture instead. If you'd like to keep this project around, though, you're welcome to merge this pull request.

Thanks for the PR! :slightly_smiling_face:

Could you publish v2.0.0 so I can update plaid/async-problem#31?

@davidchambers done :+1:

It looks as though you tagged an existing commit rather than updating "version" in package.json and pushing a new tagged commit. Perhaps as a result of this v2.0.0 is not available on npm:
$ npm view lazy-either versions
[ '1.0.0', '1.0.1', '1.0.2', '1.0.3' ]

I recommend xyz for avoiding such mishaps.


Error reporting causes performance issues

We've noticed a couple of situations where the error rate is just high enough (e.g. someone deploys a broken version of a page), that the load caused by the Bugsnag middleware is high enough to cause performance issues on unaffected pages.
Having a dig through the code, it seems like there's a lot of CPU time spent preparing the notification in the main request-handling thread, before the actual HTTP work is offloaded to a background thread.
Would you be open to a PR moving that work to the background thread?

I think that the reason that it isn't done there is that we need to block for a certain amount of time to ensure we gather the requisite context from the thread locals etc before moving on. I think that we should raise a ticket internally to look at refactoring some of the library to improve performance.
Are there any areas you see as being especially bad for you? We'd have to look at what we can remove or how we can serialize information before offloading work to the background thread.

We have also raised an internal ticket to audit the performance and see if there are any quick wins in our test cases.

Has there been any movement on this? We have also been bitten by this issue. It cropped up recently in a case where some code inadvertently sends events to Bugsnag in a loop and can take 10–15 seconds to send a few dozen errors. We see heavy CPU usage during these times. We've started to mitigate this by sending events to Bugsnag in background jobs, but it's not ideal.

Hi @gigr, we haven't identified any performance improvements in this area yet.
Do you know what is causing the slowdown in your case?
Additionally, if it is possible for you to share a reproduction case, this would help us target performance upgrades.

We've shipped a number of performance improvements in recent releases; let us know if these don't seem to have helped


run dep ensure

closing; probably some upstream bug with dep as test/tags should'nt have been vendored according to Gopkg.lock

ah weird!
On Sat, Feb 24, 2018 at 12:36 PM, Matthew Fisher<EMAIL_ADDRESS>wrote:

closing; probably some upstream bug with dep as test/tags should'nt have
been vendored according to Gopkg.lock
https://github.com/jessfraz/img/blob/bcafcaceaf3abff9144f3d928103d526e4ca35b4/Gopkg.lock#L255-L265
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jessfraz/img/pull/41#issuecomment-368245100, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABYNbJE-6XWOi0oc9tsWs-HdWkLD9DoGks5tYEiDgaJpZM4SR-Ix
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3


Let Laravel discover migrations, using its default mechanism

As finely already exists, we can register our migrations, handwriting all files, one by one.
However, for some packages it is helpful, just to include all migrations at once, using the default Laravel way.
This PR adds this functionality, without any extra handling (stubs, timestamps etc).
Note: we can use only one of the two ways (manual vs auto registering)
You may proceed with this as you see fit

To keep this package simple, I'm going to leave things like they are for now.


doc: fix @Kha's issues with MonadControl docstring

#1083 got merged before some of @Kha's issues had been addressed so this PR sorts that out.

oops I messed up the rebase here trying again


Improve NN_opt

Nothing should be printed unless verbose is set to True
https://github.com/vindolineKis/QCircLearning/blob/25c1983882feefe685bf0a27dec32eebd6593b10/QCircLearning/trainerModel.py#L130-L131
https://github.com/vindolineKis/QCircLearning/blob/25c1983882feefe685bf0a27dec32eebd6593b10/QCircLearning/trainerModel.py#L134-L135

Are res.nfv = 0 necessary?
https://github.com/vindolineKis/QCircLearning/blob/25c1983882feefe685bf0a27dec32eebd6593b10/QCircLearning/trainerModel.py#L105-L107

Make the assignment of x0 a separate function, we may want to add some noises to x0 later.
https://github.com/vindolineKis/QCircLearning/blob/25c1983882feefe685bf0a27dec32eebd6593b10/QCircLearning/trainerModel.py#L167-L171

Partial done in PR #4 except "Make the assignment of x0 a separate function, we may want to add some noises to x0 later."

Is this been implemented now?

Partial done in PR #4 except "Make the assignment of x0 a separate function, we may want to add some noises to x0 later."

Is this been implemented now?

To-do today. This issue should close and merge into issue #10


Xcode 10.1 Compatibility

Currently
The project workspace is at the moment not fully compatible with the latest Version 10.1 (10B61) of Xcode.
Required

[ ] Update the project and xcworkspace and make it compatible with Version 10.1 (10B61)
[ ] Update the Unit test target and make it compatible with Version 10.1 (10B61)

We should push a new release out before closing this

I think Xcode version ‘10.1.0’ is not on circle. We should use ‘10.0.0’ for now I will change that so it will be all green 🥬

I’m a bit confused, 10.1.0 was all green yesterday


ScssphpFilter uses removed class from Scssphp

leafo/scssphp changed its architecture and now contains several classes under Leafo\ScssPhp namespace while Assetic ScssphpFilter still uses old \scssc class.

I think that this issue can be closed.


30051 - Tohoku - Reassign song 371

Song metadata states that this song is from Gumna Prefecture, Kantō Plain, Japan, not Tohoku region. Suggest reassigning to society 30054, Kanto.

Suggestion implemented


xWebsite throws error using net.tcp/net.pipe

Hi everybody,
I'm currently using the following code (where servicetype and environment are Test and DVLP for example):
xWebsite "Create-Site${ServiceType}${Environment}"
        {
            PhysicalPath = "C:\inetpub\${ServiceType}.${Environment}"
            State = "Started"
            Ensure = "Present"
            ApplicationPool = "${ServiceType}.${Environment}"
            Name = "${ServiceType}.${Environment}"
            BindingInfo     = @(
                        MSFT_xWebBindingInformation
                        {
                            Protocol = 'net.tcp'
                            BindingInformation = "808:*"
                        }
                        MSFT_xWebBindingInformation
                        {
                            Protocol = 'net.pipe'
                            BindingInformation = "*"
                        }
                    )

            PreloadEnabled = $true
            DependsOn = "[xWebAppPool]New-AppPool${ServiceType}${Environment}"
        }

The check always fails with the error:
PowerShell DSC resource MSFT_xWebsite  failed to execute Set-TargetResource functionality with error message: Failure to successfully set the state of the website "Test.DVLP". Error: "The object identifier does not represent a valid object. (Exception from HRESULT: 0x800710D8)".
I suspect it has something to do with the net.tcp/net.pipe bindinginfo...

Any progress on this issue? Same over here...

This sounds like a bug. I think an integration test need to be created for this issue to test this scenario.

FYI. found this bug as I am using this provider. This error seems to appear when a appool that doesnt exist is selected. In my case I had a typo in the app pool name in the app pool resource


fix issue occurred in service creation step 3 (config_containers) - [closed]

In GitLab by @sokril on Dec 6, 2017, 01:36
Merges fix683 -> dev

In GitLab by @wknet123 on Nov 13, 2019, 10:14
the build is FAILED console log

In GitLab by @wknet123 on Nov 13, 2019, 10:14
closed


Minor edits to UGDG, PPP

Also edited some comments to improve code quality.

Codecov Report

Merging #305 (c6d884e) into master (c1e20af) will increase coverage by 0.95%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #305      +/-   ##
============================================
+ Coverage     72.78%   73.73%   +0.95%
- Complexity      754      760       +6
============================================
  Files           105      105
  Lines          2436     2433       -3
  Branches        325      325
============================================
+ Hits           1773     1794      +21
+ Misses          537      516      -21
+ Partials        126      123       -3

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/AddressBook.java
83.33% <ø> (ø)

src/main/java/seedu/address/ui/MainWindow.java
0.00% <0.00%> (ø)

...c/main/java/seedu/address/model/person/Person.java
85.84% <0.00%> (+1.58%)
:arrow_up:

...rc/main/java/seedu/address/logic/LogicManager.java
74.19% <0.00%> (+19.35%)
:arrow_up:

...n/java/seedu/address/model/AddressBookHistory.java
100.00% <0.00%> (+45.45%)
: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 487fd1c...c6d884e. Read the comment docs.


Fetch summary only when reference sequence number advances

Currently, refreshLatestSummary() downloads the summary and checks whether the reference sequence number advances (https://github.com/microsoft/FluidFramework/blob/main/packages/runtime/runtime-utils/src/summarizerNode/summarizerNode.ts#L270). However, the summarizer already knows the reference sequence number from the last summary op (https://github.com/microsoft/FluidFramework/blob/main/packages/runtime/container-runtime/src/summarizer.ts#L275).
Rather than downloading the summary, we can just check the condition and only download summary when the refSeq actually advances. This will also help service summaries since summarizer will stop pulling older summaries unnecessarily just to perform the check.

@pleath FYI


Optimize queries preparation

Profiling indicates that a considerable amount of time is spent in a Esqueleto function toRawSql. This is used in select queries, like when inputs are resolved and when stake addresses are queried for stake distribution or for a new address in outputs. This means it is called many times, since it is called at least once for each stake distribution (896871 in epoch 297), input  (735923 epoch 297) and output (784975 in epoch 297). Profiling a time window which includes the stake distribution (start of an epoch) indicates that toRawSql consumes 15% of total execution time.
toRawSql is a pure function which takes a SqlQuery, creates the query and separates the [PersistValue]. Since the same queries are repeated many times, an optimization could involve caching it.

Worth re-running on https://github.com/input-output-hk/cardano-db-sync/pull/964
Do you have written instructions on how to perform the profiling?

Eventually the 15% I mention above is not over the total wall clock time, but time spent in MUT, so it apparently it doesn't include the io. I had opened a ticket in esqueleto about this https://github.com/bitemyapp/esqueleto/issues/293.


Makes fuzzer support more recovery edge cases

Makes fuzzer support the recovery case "the disk becames unreadable during recovery so the fuzzer model believes the database is empty and, after the subsequence DB restart the recovery process works and past commits get properly reneacted".
Removes a lot of code duplication in the fuzzers

This change is much easier to review commit by commit rater than reading the big final diff.


fixed example worm.json

The Example worm.json dosn't work becouse it tries to download the twitter and facebook sharelink as chapters, this changes the chapter_selector to fix that.

I merged #51 instead, which changed the way Worm is downloaded entirely.

I merged #51 instead, which changed the way Worm is downloaded entirely.


<EMAIL_ADDRESS>decompress error

https://pkg.authy.com/_squirrel/authy/stable/x64/RELEASES

version was rolled back to 2.2.2 by upstream.


Warn on unknown language extensions

See https://github.com/ndmitchell/hlint/issues/223#issuecomment-665951432 - if you type:
hlint -XQuasiQuoe Sample.hs

It doesn't warn or anything. It probably should at least warn. Not necessarily as a hint warn, but just putStrLn $ "Warning: Unknown extension, QuasiQuoe".

Ouch. For when we get to it, I think I see where we need to intervene: function getExtensions, CmdLine.hs:333.

Ouch. For when we get to it, I think I see where we need to intervene: function getExtensions, CmdLine.hs:333.

If that is indeed the right place, maybe error here?

It'll be easier to implement;
Consistent with the expected behavior of an unrecognized argument.

My first inclination was not to error, since if GHC adds a new extension we don't know about then we'd fail. But honestly, now we track GHC so closely, I'm not sure it's a real concern.

My first inclination was not to error, since if GHC adds a new extension we don't know about then we'd fail. But honestly, now we track GHC so closely, I'm not sure it's a real concern.

I agree with this; don't think that's a concern.

My first inclination was not to error, since if GHC adds a new extension we don't know about then we'd fail.

On reflection, I think that's the behavior we want if we find ourselves in this case too since it's a very much a pragma we can't satisfy!

My first inclination was not to error, since if GHC adds a new extension we don't know about then we'd fail.

On reflection, I think that's the behavior we want if we find ourselves in this case too since it's a very much a pragma we can't satisfy!

Ah but I see your point that warning would be preferable in this case - you'd want to say "I can't do that" and proceed to analyze what you can. Ok, scratch that and in any case as noted above, we don't intend to ever be in this path anyway 😉


Update to Angular 4??

When could we expect the CLI to be updated to generate project with Angular version 4?
Meanwhile if we manually change the version in "package.json" to v4, what issues should we expect?
I mean, what are the things (if any) in version 4 that is not yet compatible to the CLI?

The CLI trails the current NPM release (2.4), usually by a week.
You can update, but you'll need to check the release notes to find out what breaking changes required a Semver major update.

@tx8821 I installed angular 4.0.0-beta.3 without issues for now

I think, angular-cli should support the latest stable version of angular, by default. On demand, anybody can manually upgrade to version 4.

We plan on being Angular 4 compatible as soon as it's out. We overall also tests our code against the latest preview versions on angular/angular to make sure it's compatible and try to keep it working for both current and upcoming versions.
I don't think it's a good idea to force people to use the Angular 4 beta by default though.

@Codenator81 I'm getting following issue after upgrading angular manually to 4.0.0-beta.3
yarn install v0.18.1
[1/4] Resolving packages...
[2/4] Fetching packages...
warning<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning Incorrect peer dependency "<EMAIL_ADDRESS>>=2.2.0".
warning Incorrect peer dependency "<EMAIL_ADDRESS>>=2.2.0".
warning Unmet peer dependency "<EMAIL_ADDRESS>warning Unmet peer dependency<EMAIL_ADDRESS>[4/4] Building fresh packages...
Done in 8.18s.

Here is my package.json
{
  "name": "staff-ui",
  "version": "1.0.0",
  "license": "MIT",
  "angular-cli": {},
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "lint": "tslint \"src/**/*.ts\" --project src/tsconfig.json --type-check && tslint \"e2e/**/*.ts\" --project e2e/tsconfig.json --type-check",
    "test": "ng test",
    "pree2e": "webdriver-manager update --standalone false --gecko false",
    "e2e": "protractor"
  },
  "private": true,
  "dependencies": {
    "@angular/common": "^4.0.0-beta.3",
    "@angular/compiler": "^4.0.0-beta.3",
    "@angular/core": "^4.0.0-beta.3",
    "@angular/forms": "^4.0.0-beta.3",
    "@angular/http": "^4.0.0-beta.3",
    "@angular/platform-browser": "^4.0.0-beta.3",
    "@angular/platform-browser-dynamic": "^4.0.0-beta.3",
    "@angular/router": "^4.0.0-beta.3",
    "core-js": "^2.4.1",
    "rxjs": "^5.0.1",
    "ts-helpers": "^1.1.1",
    "zone.js": "^0.7.2"
  },
  "devDependencies": {
    "@angular/compiler-cli": "^4.0.0-beta.3",
    "@types/jasmine": "2.5.38",
    "@types/node": "^6.0.42",
    "angular-cli": "1.0.0-beta.25.5",
    "codelyzer": "~2.0.0-beta.1",
    "jasmine-core": "2.5.2",
    "jasmine-spec-reporter": "2.5.0",
    "karma": "1.2.0",
    "karma-chrome-launcher": "^2.0.0",
    "karma-cli": "^1.0.1",
    "karma-jasmine": "^1.0.2",
    "karma-remap-istanbul": "^0.2.1",
    "protractor": "~4.0.13",
    "ts-node": "1.2.1",
    "tslint": "^4.3.0",
    "typescript": "~2.0.3"
  }
}

Any idea what might be causing this?

@thekalinga It is just warnings not errors. Just ignore them

@Codenator81 ng serve is not loading the default screen in browser.

@Codenator81 Please ignore my previous comment. The reason ng serve was not working is due to the fact that my app prefix started with a number. Looks like angular does not like the prefixes that start with a number
i.e I have used my app prefix as 1ton & angular was not accepting it properly.
Now I changed it to ton & its working
BTW, I'm not sure what these warnings might break later on
warning Incorrect peer dependency "<EMAIL_ADDRESS>>=2.2.0".
warning Incorrect peer dependency "<EMAIL_ADDRESS>>=2.2.0".
warning Unmet peer dependency "<EMAIL_ADDRESS>warning Unmet peer dependency<EMAIL_ADDRESS>

@thekalinga From my long programming practice I learn newer name file names and classes (every thing) starting from anything but ABC character.
I have the same warning. It is just warning about peer dependency.

The product name 1ton that I am developing starts with a number :)

@thekalinga in code it probably makes sense to refer to it as oneton or one-ton then. :)

@thekalinga  In your case I name app OneTonn

@beeman Agree, just wanted to save some key strokes, as this would need to be repeated throughout the templates :)

Hi,
I was able to update my sample Angular CLI app to 4.0.0 using the guideline at http://angularjs.blogspot.com.au/2017/03/angular-400-now-available.html, and it worked. However I got following "invalid" errors. Should it be any real issue with the app at run time?
+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>invalid
+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>invalid
`-- UNMET PEER DEPENDENCY<EMAIL_ADDRESS>

@thucnguyen77 you need to update zone.js to ^0.8.4 as well.

I have the same error

So, yeah, now that angular 4 is out, shouldn't angular-cli use it by default as indicated above instead of having to update? That does not seem to be the case...

@megalucio I have just created new project with latest angular-cli (1.0.0) and it uses Angular 4.
package.json:
"dependencies": {
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "core-js": "^2.4.1",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
  },

Thanks, yeah I did not have updated my angular-cli properly. Now it is working.


(BKR-463) Rsync now fails with CommandFailed when destination path does not exist

Fixes BKR-463 as described, and includes improvement to spec mocking for rsync calls which should allow future rsync error handling improvements. Acceptance test coverage is modified to indicate fixed behavior.

Due to potential breaking behavior of throwing exceptions where previously would fail silently, this merge has been deferred to 4.0 release.


Installed 1.0.1 Via Pip and Scandir Dependency Not Installed

I followed the install instructions here:
http://graphite.readthedocs.io/en/latest/install-pip.html#installing-in-the-default-location
All dependencies should be installed but I'm getting the following error on syncdb:
# Filesystem layout
WEB_DIR = dirname( abspath(__file__) )
WEBAPP_DIR = dirname(WEB_DIR)
GRAPHITE_ROOT = dirname(WEBAPP_DIR)
/SECRET
    for pattern in resolver.url_patterns:
  File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 33, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 417, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 33, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 410, in urlconf_module
    return import_module(self.urlconf_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/opt/graphite/webapp/graphite/urls.py", line 22, in <module>
    url('^render/?', include('graphite.render.urls')),
  File "/usr/local/lib/python2.7/dist-packages/django/conf/urls/__init__.py", line 52, in include
    urlconf_module = import_module(urlconf_module)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/opt/graphite/webapp/graphite/render/urls.py", line 16, in <module>
    from . import views
  File "/opt/graphite/webapp/graphite/render/views.py", line 34, in <module>
    from graphite.remote_storage import extractForwardHeaders, prefetchRemoteData
  File "/opt/graphite/webapp/graphite/remote_storage.py", line 10, in <module>
    from graphite.readers import FetchInProgress
  File "/opt/graphite/webapp/graphite/readers.py", line 9, in <module>
    from scandir import scandir, stat # noqa # pylint: disable=unused-import
ImportError: No module named scandir

Fixed in master and 1.0.x branches.


Remove containerd-release tool from main repo

The release-tool is now located in the containerd/project repo.
Signed-off-by: Phil Estes<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2735   +/-   ##
=======================================
  Coverage   43.75%   43.75%
=======================================
  Files         100      100
  Lines       10725    10725
=======================================
  Hits         4693     4693
  Misses       5301     5301
  Partials      731      731

Flag
Coverage Δ

#linux
47.43% <ø> (ø)
:arrow_up:

#windows
40.91% <ø> (ø)
: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 133ac5c...0dd3211. Read the comment docs.

LGTM


Using outdated Guzzle version

Guzzle made some breaking changes starting with version 4.0 and php-coveralls doesn't work with the newer versions. From what I can tell only the Jobs::upload() method will need to be changed and the composer.json updated.

:+1: it's weird having both guzzlehttp/guzzle and guzzle/guzzle installed.

+1

+1

+1 I've been burned by using the wrong version of guzzle before.

I think it's fixed by #76 and #114. I'm closing this. Please feel free to re-open this if you think otherwise.

Am I missing something? I seems like you're still using guzzle instead of guzzlehttp.

Well, the thing is that this tool needs to support older version of PHP, specifically 5.3. Is there any good solutions for this?

Ah, I didn't realize that guzzle 5 required php 5.4.  If it was me, I would create a new major version that required >=5.4.  You would be supporting two major versions of the software.  I would suggest only cherry picking bugfixes/security updates onto the older version.

:+1: for a non-legacy version. A lot of us don't even support PHP 5.4, let alone 5.3.

Yeah, understood. Now I'm trying to get familiar with the releasing process. Let's release the next version which will be the legacy version supporting PHP 5.3, and let's move on. SG?

Yeah need to move on since most hosting has moved on to at least 5.5+ now that 5.4 was EOL on 3 Sep 2015. After all PHP 7.0 is dropping today or within the next couple days I understand.
It's really well beyond time to drop support for 5.3 since it's EOL was clear back on 14 Aug 2014 which is more than a year ago :)
On Thursday, December 3, 2015 6:29 PM, Takashi Matsuo<EMAIL_ADDRESS>wrote:

Yeah, understood. Now I'm trying to get familiar with the releasing process. Let's release the next version which will be the legacy version supporting PHP 5.3, and let's move on. SG?—
Reply to this email directly or view it on GitHub.

Alright. Update here.
We actually decided not to drop support for PHP 5.3.3. Rather, we started distributing the phar file, which solves dependency conflicting issue.
If the new phar file doesn't work for you, please let us know.

Support versions of PHP that are now over a year out of support with known security holes just doesn't make any sense to me. Also since travis has mostly stopped support for PHP 5.3 as well and I'm sure most people use coveralls with it this is a very backwards move on your part. With PHP 7.0 having been released is it really your intention to because a legacy site where the past is more important than the future?
The phar doesn't solve the issue for me (or probably most people) since I use Packagist and Composer to add coveralls and it's designed to pull from master branch source or Tags branches. If you need help learning to use VCS and start using version tags I'm sure I can help or there are many other even more knowledgeable that would be more than happy to help.

Support versions of PHP that are now over a year out of support with known security holes just doesn't make any sense to me. Also since travis has mostly stopped support for PHP 5.3 as well and I'm sure most people use coveralls with it this is a very backwards move on your part. With PHP 7.0 having been released is it really your intention to because a legacy site where the past is more important than the future?

@keradus wants to keep supporting PHP 5.3.3. Do you want to chime in?

The phar doesn't solve the issue for me (or probably most people) since I use Packagist and Composer to add coveralls and it's designed to pull from master branch source or Tags branches.

Using phar forces you to change how to install php-coveralls. I updated the README and hope it will help you migrate.

If you need help learning to use VCS and start using version tags I'm sure I can help or there are many other even more knowledgeable that would be more than happy to help.

I know them. We are just resource limited. That said, we always welcome contributions :)

Oh and I may miss something. @Dragonrun1 If you have a reason that you can not install php-coveralls phar file instead of installing via composer, please let me know.

You should just release a v1.0 of coveralls that only supports PHP 5.4+.

As @Dragonrun1 said, having a phar doesn't help me in any ways.

Agreed.  Keep in mind that PHP 5.4 has also reached EOL.  What is the reason for continued support of 5.3?

@shadowhand If you install the phar file, all the (legacy) dependencies are just included in that phar file. Also, in most cases, php-coveralls is an independent process, so you don't need to have php-coveralls in your composer.json. Do I miss something?

@tmatsuo you're not missing anything but you're also not addressing the fact that this library is effectively stuck in time by continuing to support 5.3.
I'm happy to implement Guzzle 6, but that will require PHP 5.5+ to be required.

Personally I'm fine with dropping support PHP 5.3 and PHP 5.4 with future versions.
@keradus may convince us :)

Guys, library is a tool to support collecting code coverage. And it is used by some 3rd projects. Projects that support multiple PHP versions. And they want to collect data from multiple versions. The less versions that PHP Coveralls will support, the less useful it will be.
It is a tool to support maintaining the code. It is not the application you use on its own without any other code - if it would be that case you could switch to PHP7 and all newest dependencies. But it is not.

@keradus that's not a problem, they can continue to use version 0.6.x or 0.7.x. The next version should use modern dependencies so that more modern projects can use it without conflicts or installing large phar files.

Then there should be 2 maintained version. And it is pointless for such small tool.
It has one simple thing to do and is already over complexed.

Then I think you will find this project forked very soon.

Alright. I, as the most active maintainer at the moment, decided to drop PHP 5.3 and 5.4 support in the future version. Let's make v0.7.x be the last version which supports PHP 5.4.
Any contributions welcome :)

Are you aware of https://github.com/php-http/httplug ? This pakage allows to let developers choose the underlying http client used in an elegant and powerfull way.

@egeloen I have never been able to figure out how to properly use httplug. The docs are horrible.

Well, indeed it can look complex at a first read as decoupling everything is not an easy topic (too much repository)... But when properly set up, it does the job well and it is definitively a good choice for this kind of package which should not require an explicit http client but instead let the developer choose which one it wants to use.

@egeloen That doesn't really seem like a solution to this problem.
The biggest issue for me is that both are available in my project, and it can be confusing which one to use at times.  I have built entire features using the wrong api by mistake before.

@egeloen the main problem with HTTPlug is that not all PSR-7 libraries implement all features. For instance, Guzzle doesn't implement ServerRequestInterface, so if I need that functionality I'll still need another PSR-7 library. HTTPlug can't solve that.

Not sure you have really understood what httplug can do for you.
@natebrunette The issue is you use guzzlehttp/guzzle in your own project and then, by installing this package you also get guzzle/guzzle (deprecated) which make you confusing between the two packages. By dropping it in this package and rely on httplug, then httplug will automatically discover it can use guzzlehttp/guzzle as it is already installed, then you issue is gone.
@shadowhand Guzzle doesn't implement ServerRequestInterface Then, don't use it and rely on an upper guzzle version. Httplug is also compatible with it as it is with older version of guzzle.
My point is this package should not rely on any direct http client. guzzle/guzzle or even guzzle/guzzlehttp but instead rely on httplug and then, let the app discover which one to use or let the developer choose which adapter it want to use.
Am I missing something?

@egeloen
Re: HTTPlug
Thanks, but I would rather not use HTTPlug right now. I'm thinking to just upgrade the guzzle since it seems a much easier path in my opinion.
Discussion:
guzzlehttp/guzzle#6.1.1 supports PHP 5.5, so can we just upgrade our dependencies from guzzle/guzzle to guzzzlehttp/guzzle ^6.1? or should we support both guzzlehttp/guzzle ^5.3 and ^6.1?
If we need to support both, we can leverage something like:
https://github.com/google/google-auth-library-php/blob/master/src/HttpHandler/HttpHandlerFactory.php
@shadowhand @natebrunette
What do you guys think?

@egeloen point is, I can't rely only on HTTPlug for my application, because not all PSR-7 libraries implement all interfaces. If I know that I need a server request implementation, HTTPlug won't solve my problems.
@tmatsuo Guzzle 5 and 6 have (mostly) compatible interfaces. If you use 5 - 6 it should be fine.

@tmatsuo wait that statement is not correct at all. Using guzzlehttp/guzzle ^6 is what you would want.

i don't know this library but on the HTTPlug question: HTTPlug is indeed only about abstracting HTTP clients. so if you want to build a HTTP server in PHP itself, HTTPlug does not help you.
what it does help you is have a simple client interface and a message factory interface to create PSR-7 requests and send them with any of the existing client implementations as long as a HTTPlug adapter has been written. if you want to support guzzle 5 and 6, this would be exactly the case covered by HTTPlug, saving you all the work of writing your own adapters abstraction.

Ok, if we can just use guzzle ^6 at the moment, that's an easy path. In a long run, HTTPlug might be a good option for us. Thanks for chiming in.
Question: If we start to use HTTPlug, what does our dependency look like? Do we still need to include a default http client implementation in our dependency? This tool is just for reporting coverage report to coveralls endpoiint, so it can be used with a software which doesn't use http client at all.

You would depend on HTTPlug and would have to suggest an adapter.

So if a project which tries to use coveralls, doesn't have an http client in its deps, coveralls won't work. Am I correct? Then I would just have guzzlehttp/guzzle ^6 as a dependency.

That said in a long run, it might be worthwhile to use something like HTTPlug in a hope that we will be easily change the underlining HTTP client.

@shadowhand You are right, documentation is probably hard to use at the moment. We are working hard to stabilize the interfaces and the package architecture, but documentation is also on the list and we will definitely improve it in the future.
Also @shadowhand I agree with @egeloen, maybe you missed the point what HTTPlug is. It is a set of client abstraction interfaces. It only relies on the PSR-7 interfaces, but you can decide which you want to use. Of course in case of guzzle its own PSR-7 implementation is installed, but you are free to install any other as well. Also, you can simply pass a request object to any client implementation, the message implementation doesn't matter. Also, please note that this is a client abstraction, so I am not sure how ServerRequest is related, maybe I missed something.
@tmatsuo the HTTPlug is abstraction both on code and package level. You can require the interface package in your project without an implementation. In this case your project will be compatible with HTTPlug, but will not require an implementation. But you can also require php-http/client-implementation which is a virtual package. In this case, you have to install an implementation providing this virtual package as a dev dependency and will force the users of the package to do so as well. With other words: you can require the user to install a client implementation along with your package without locking your package to one specific client.
About dependency: from a library implementor point of view, it is simple: you only need the httplug package and the interfaces and definitely no implementations. From a user point of view: it depends on the chosen client. Our POC implementation is a guzzle6 adapter which can just be instantiated without any constructor arguments. We also have a plain curl and a socket client. Unlike guzzle, they don't use any specific message implementation to construct Response objects (while guzzle obviously uses its own). In that case the client also needs a message factory. Currently we have two message factories: one for Guzzle and one for Diactoros. We also have a discovery system to detect installed implementations and return the correct message factory, so these clients can be used with nearly zero configuration.

Anyways, as I said before, let's just move to guzzle 6.1 for the first path. If anyone wants to start working on it, please say so in this thread. Also I will take this issue once I have time to do so.
Thanks!

@tmatsuo no problem, just reacted to questions arised. Noone is forcing anything. :smile:
Keep up the good work.

@tmatsuo PR has been submitted and CI is passing.


[Kagi FastGPT] ...

Extension
https://www.raycast.com/http.james/kagi-fastgpt
Description
When entering anything in the Kagi FastGpt extension, it just shows the "Something went wrong screen". My API key is correct and its still not working.

Error:
TypeError: Cannot read properties of undefined (reading 'output')

ask.tsx:30:39

---
27:       } finally {
28:         setLoading(false)

### Steps To Reproduce

1. Run Extension with any input
2. Look at the error.

### Current Behaviour

_No response_

### Expected Behaviour

_No response_

Hmm. Can you confirm the extension is up to date? Have you added credits to your account? The credits error should show up, but just checking.

Yep, I did all this and the extension is up to date. It seems to be working now so not sure what happened.

@raycastbot close this issue


Draft pr for initial review of apicurio

Early code for review of Apicurio Avro format prototyping

@mnuttall thank you very much for the review I will have a look.


remove workaround for bug in HTML imports

There is a bug in html imports that causes the browser to block in Chrome 36.
This happens when you have a DAG in your graph of imports, where the node in the merge of the DAG doesn't have a script tag.
See attached repro, which has a graph like this:
  index.html* -> n1 -> n2*
       |               |
       |               v
       +-------------> n3 -> n4*
where files with * have a script tag. The page doesn't load unless you add a script in n3, or you remove the one in n2.
This happens in polymer apps: polymer.html is a funnel, similar to n3 in the repro.

Attachment:
repro.tar (10 KB)

This issue has been moved to dart-lang/polymer-dart#218.


sourceMap option for ng test in angular.json is not working correctly

🐞 Bug report
Command (mark with an x)
- [ ] new
- [ ] build
- [ ] serve
- [x] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?
I suspect that this option has never worked correctly with ng test
Description
Setting styles false under sourceMap option of test disables source maps for ts code
🔬 Minimal Reproduction

create new project with ng new
edit test target of angular.json file to be as following:

        "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "src/karma.conf.js",
            "sourceMap": {
              "scripts": true,
              "styles": false,
              "vendor": true
            },
            "styles": [
              "src/styles.css"
            ],
            "scripts": [],
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ]
          }
        },

do a modification to app.component.spec.ts file that will cause test to fail
run tests with command ng test

🔥 Exception or Error

HeadlessChrome 72.0.3626 (Linux 0.0.0) AppComponent should render title in a h1 tag FAILED
        Expected ' Welcome to source-map-bug! ' to contain 'Welcome to source-map-bu!'.
            at UserContext. (http://localhost:9876/_karma_webpack_/main.js:307:58)
            at ZoneDelegate../node_modules/zone.js/dist/zone.js.ZoneDelegate.invoke (http://localhost:9876/_karma_webpack_/polyfills.js:2866:26)
            at ProxyZoneSpec.push../node_modules/zone.js/dist/zone-testing.js.ProxyZoneSpec.onInvoke (http://localhost:9876/_karma_webpack_/vendor.js:83958:39)
            at ZoneDelegate../node_modules/zone.js/dist/zone.js.ZoneDelegate.invoke (http://localhost:9876/_karma_webpack_/polyfills.js:2865:52)
HeadlessChrome 72.0.3626 (Linux 0.0.0): Executed 3 of 3 (1 FAILED) (0 secs / 0.307 secs)
HeadlessChrome 72.0.3626 (Linux 0.0.0) AppComponent should render title in a h1 tag FAILED
        Expected ' Welcome to source-map-bug! ' to contain 'Welcome to source-map-bu!'.
            at UserContext. (http://localhost:9876/_karma_webpack_/main.js:307:58)
            at ZoneDelegate../node_modules/zone.js/dist/zone.js.ZoneDelegate.invoke (http://localhost:9876/_karma_webpack_/polyfills.js:2866:26)
            at ProxyZoneSpec.push../node_modules/zone.js/dist/zone-testing.js.ProxyZoneSpec.onInvoke (http://localhost:9876/_karma_webpack_/vendor.js:83958:39)
HeadlessChrome 72.0.3626 (Linux 0.0.0): Executed 3 of 3 (1 FAILED) (0.369 secs / 0.307 secs)

🌍 Your Environment

Angular CLI: 7.3.3
Node: 10.15.1
OS: linux x64
Angular: 7.2.6
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router, upgrade

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.13.3
@angular-devkit/build-angular     0.13.3
@angular-devkit/build-optimizer   0.13.3
@angular-devkit/build-webpack     0.13.3
@angular-devkit/core              7.3.3
@angular-devkit/schematics        7.3.3
@angular/cli                      7.3.3
@ngtools/webpack                  7.3.3
@schematics/angular               7.3.3
@schematics/update                0.13.3
rxjs                              6.4.0
typescript                        3.2.4
webpack                           4.29.5

I found this issue when I was fighting with another ng test related problem: https://github.com/karma-runner/karma/issues/3267. Could it be so that vendor source maps are generated by default and that makes source map files too large to load quicky enough?

@jvalkeejarvi, vendor sourcemaps are off by default.

Thanks @alan-agius4 for quick fix!
I think there is some problem with vendor source maps when running ng test. I'll open another issue for that.


Add documentation

closed by @ddomingof with https://github.com/ComPath/compath_hgnc/commit/8fc455082a0b38432c3acbaa3e486067a66927f8


.NET runtime package on rhel6 fails to run

Issue Title
.NET runtime package on rhel6 fails to run dll with ICU error
General
When I run a program using .NET runtime, it throws an exception:
FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
at System.Globalization.GlobalizationMode..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.StringComparer..cctor()
at System.AppDomain.InitializeCompatibilityFlags()
at System.AppDomain.Setup(System.Object)
Aborted (core dumped)
Do I still need to install ICU package on official release 2.1.12?

@tarekgh do you know what causes this error?

Do I still need to install ICU package on official release 2.1.12?

Yes it is required to have ICU package installed to run on all .NET Core versions.
We have invariant mode can be enabled which will not require ICU https://github.com/dotnet/corefx/blob/a10890f4ffe0fadf090c922578ba0e606ebdd16c/Documentation/architecture/globalization-invariant-mode.md but I wouldn't recommend to enable it except if you really don't care about Globalization support.


Support for 1.1

Sadly, needs more work due to #17 .

This is now to a state where games can be loaded in 1.1 and trains will jump properly / various other errors are resolved.
Ramps have been changed so they're no longer rail signals, but constant combinators (lol). However, ramps are placed by using a "placer" that is a rail signal, which gets them properly aligned with the tracks. When a placer is built, we swap it for the real thing.
It was... interesting making this work with the older entities in the previous save. I had to do some wild stuff.
I also moved/rewrote bits of code so they could be reused, most notably in the ramp prototype generation and the magnet ramp range setting.
Anyway, this is now like 80% done. Functionally, it works, but a few more things need to be done:

Adjust the ramp sprites by have the offsets mentioned here * 32 pixels, this will make the placer images line up properly
Uncomment the shift lines for the ramp sprites to re-fix them from the offset changes
Hook into on_player_configured_blueprint to swap ramps for their placers in blueprints
Verify copy/paste works

Wow that's a lot of stuff. It's gonna take me a while to read through and understand everything but you're pretty good so I'm confident it works like a champ 😎. I'll take a look through and try to finish that checklist

I'm happy to keep plugging away at the 3rd and 4th items. If you have the original graphics on you, it'll probably be easier for you to do item 1, though my backup plan was going to be using imagemagick to separate the sprites, adjust them, and stitch them back together. That said I haven't really worked with actual graphics in Factorio before, so you'll probably have a better handle on those.

How can I add stuff to your branch? I fixed up the graphics and changed the ramp from a combinator to a simple-entity-with-owner so that the interface wouldn't open when clicking the magnet ramp to set range. By the way, the train ramps never actually worked with copy/paste and blueprints so I'm not sure how to implement that

Does a simple-entity-with-owner support the graphics required? From reading the docs it seemed like it only supported a single direction of graphics. If we need to keep it at a combinator, I can probably hack something up to keep the gui closed...

I changed it and it did work. Directional support for simple-entities was actually added in 1.1.0

Fascinating. I must have been bit by the prototype definitions not being updated until a few days after release.
Also if copy/paste didn't work before 1.1, I'm happy to leave that as "to be implemented in the future, maybe" :joy:


Attribute Error when accessing admin site.

Issue Summary
Using with an existing project, wagtail fails to render the admin login page(regular pages work, just the admin interface doesn't).

Steps to Reproduce

Install wagtail into an existing project.
Try to access the admin url at /cms/(per tutorial on documentation, can be any url path for the admin)
The page will fail to render with a 500 error.

Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
AttributeError at /cms/login/
'NoneType' object has no attribute 'COOKIES'
Request Method:	GET
Request URL:	http://localhost:8002/cms/login/?next=/cms/
Django Version:	3.2.17
Exception Type:	AttributeError
Exception Value:
'NoneType' object has no attribute 'COOKIES'
Exception Location:	/usr/local/lib/python3.8/site-packages/wagtail/admin/templatetags/wagtailadmin_tags.py, line 909, in sidebar_collapsed
Python Executable:	/usr/local/bin/python
Python Version:	3.8.8
Python Path:
['/app',
 '/app',
 '/usr/local/lib/python38.zip',
 '/usr/local/lib/python3.8',
 '/usr/local/lib/python3.8/lib-dynload',
 '/usr/local/lib/python3.8/site-packages',
 '/usr/local/lib/python3.8/site-packages/jaeger_client/thrift_gen']
Server time:	Fri, 17 Feb 2023 22:58:13 -0300
Error during template rendering
In template /usr/local/lib/python3.8/site-packages/wagtail/admin/templates/wagtailadmin/skeleton.html, error at line 17

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: (yes / no)

Technical details

Python version: 3.8.
Django version: 3.2.17.
Wagtail version: 4.2.
Browser version: Chrome 109.

Hi @mvellasco - thanks for the report.
Please could you try reproducing this on a fresh project created with django-admin.py startproject? Wagtail is in use on thousands of sites, so it's highly unlikely that there's a bug of this sort that affects all existing Django projects - more likely this is caused by some customisation in your project, such as a third-party middleware package. Without knowing the exact setup of the project where this occurs, we can't really investigate further.

Closing for now, as there's not enough information here to replicate the issue independently.


Support for PWA

We have the package application/pwa+zip format figured out but some process needs to serve the files. Either zapstore or on a separate app.
@hzrd149 anything I might be missing?

I should be able to create and release a PWA runner app in an afternoon

I build this a while ago. its a little cli tool for packaging an app as a .pwa, uploading, and publishing the 1063 event
https://github.com/hzrd149/nostr-pwa-pack
It doesn't have any documentation yet though :disappointed:


MRG: Deprecate mask_type -> "and"

Closes #4286.

Codecov Report

Merging #4292 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #4292      +/-   ##
=========================================
+ Coverage    86.2%   86.2%   +<.01%
=========================================
  Files         346     346
  Lines       64680   64684       +4
  Branches     9912    9914       +2
=========================================
+ Hits        55758   55762       +4
  Misses       6205    6205
  Partials     2717    2717

cc @jjnurminen

LGTM

The AcqParserFIF class quietly defaults to 'mask_type=and'. I guess that's ok?

Ahh good to check that -- in this case it's fine because it's already at the desired default

I'm very happy the mask_type and "not_and" are finally going away.

thx @Eric89GXL


If alias starts with ! send via DDG

Maybe pre-fetch with ajax... that way we could:

No bang, search bangs instead
Save bangs used in history (?) and offer to create aliases for them?

Done - moving to later to consider ajax


[Question] Meaning of green/red tooltip above system in map

What is the meaning behind green/red text and top/down caret?

▼4 means there were >4 pilots and count decreased to 4, and ▲1 means count was 0 and became 1.


Upgrade docker-client dep from 7.0.2 to 8.4.0

Codecov Report

Merging #1117 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1117      +/-   ##
============================================
- Coverage     52.12%   52.11%   -0.01%
  Complexity     1582     1582
============================================
  Files           267      267
  Lines         12827    12827
  Branches       1479     1479
============================================
- Hits           6686     6685       -1
  Misses         5634     5634
- Partials        507      508       +1

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 ab45c1b...5b31994. Read the comment docs.


[BUG] Change to POST (instead of GET) when uploading account certificate

Account certificates (whatever they are, and for whatever they are used…)

Old UI uses POST to post data, and I assume this is a valid way since the data can be huge (certificate length, key length, chain length etc…)
Primate sends it via simple GET – I’m questioning if this is wrong and should be fixed as with long text it will cause HTTP error with too long request etc.

The upload cert feature in Accounts -> SSL cert tab is not generally used by CloudStack LB (maybe netscaler etc.). If it's simple fix go ahead @utchoang or @davidjumani  - otherwise we can push it to 1.1

Doesn't seem too hard. I'll look into it

Moving this to 1.1, not generally used or that important; get request seems to work OK.


Debugger: Steps by statment instead of by line in VS Code

Environment data
dotnet --info output:
VS Code version: 1.9.1
C# Extension version: \scratch2\scratch\janraj\vsdbg2\csharp-1.8.0-beta1.vsix
.NET Core SDK: 1.0.0-preview2-1-003177
OS: Debian 8.2 x64
Steps to reproduce

Open attached folder.
step.zip
Select '.NET Core Launch(console).
Set a breakpoint at line of 22.
F5 to start debugging.
Press F11 after the breakpoint be hit.

Expected  behavior
The cursor should be hit 14 line.
Actual behavior
The cursor still stays at 22 line.
Investigation

This is automation test case, expected cursor hit 14 line.
On Zorin OS, the cursor hit 14 line after step#5 .
Could you please help me to confirm which is expected?

I am a little surprised this ever worked -- there are multiple statements on line 22, and I didn't think we did work to put the debugger in 'step by line' mode. At any rate, it wouldn't be too hard to put ourselves in 'step by line' mode in the VS Code case (we wouldn't want to for VS).

This issue also repro on windows.
Repro steps:

Perform the above repro steps .
Press F11 twice .

Expected behavior
The cursor should be hit 14 line.
Actual behavior
The cursor still stays at 22 line.
Investigation

If I press F11 Three times, The cursor hit in 23 line.

@pieandcakes please resolve this when you checkin.

@gregg-miskelly I checked in but I don't have access to assign myself or close issue.

@DustinCampbell any objection if I add Pierson as a member of this repo?
I will close this one now.

This issue will be resolved in the next 1.8 beta.

@DustinCampbell any objection if I add Pierson as a member of this repo?

nope

This issue also repro on windows.
Repro steps:
1.Perform the above repro steps .
Expected behavior
The cursor should be hit 14 line.
Actual behavior
The cursor still stays at 23 line.

@qian6 I am not able to repro this. If you clear out all your breakpoints (so VS Code isn't restoring your breakpoints from previous sessions) and reset them, do you still see it? If so, can you add a trace?

This issue can not repro, Thanks for your share information.

Thanks for checking.


Use Airflow's internal logging

Instead of importing a new logger, we can also use Airflow's internal logger.

@Fokko thanks.

My pleasure @nicor88. Let me know if you consider pushing this operator to Airflow upstream :-)


[INCOMPLETE] FEATURE: Resize account columns

Hey guys, this is a not-perfectly-working implementation of resizable account view columns.
I'm having issues with the anchoring of the columns. What I have here works but there's just some usability issues with it that I'd like some other people to help out with.
I'm going to keep looking at it but I think until we fix some of the usability issues, we should hold of on merging it.
The resize divs are currently an obnoxious red just to help debug...that should obviously change once we release it :D

This reminds me of something I've been meaning to do but haven't gotten around to it. That is to update populateFeaturesFile.py to allow a setting of hidden:true | hidden:false (default to false if the setting isn't present). Currently to get a feature to build you have to remove the setting altogether. Seems more logical to simply change the setting to false (I would probably remove it when the feature is ready for the public).


teuthology/misc: use parallel gzip to compress logs

I was hoping to evaluate this in testing but apparently this is one of those parts of teuthology that needs merged into main to run. Anyway, I expect this should dramatically reduce the time teuthology spends compressing logs at the end of long tests.

@batrick if you push your branch to this repo, you can use the --teuthology-branch arg for teuthology-suite. The supervisor will be run using that branch.

@batrick if you push your branch to this repo, you can use the --teuthology-branch arg for teuthology-suite. The supervisor will be run using that branch.

I tried but it did not seem to run this updated code. My u8nderstanding is that some parts of teuthology are always run from main via the teuthology host. I wonder if this is one of those parts.
 I wonder if this is dead code. This work is now done in Ceph in qa/tasks/ceph.py

Here's where the dispatcher spawns the supervisor (which in turn spawns the job process): https://github.com/ceph/teuthology/blob/main/teuthology/dispatcher/init.py#L154-L160
Just above that, it's calling prep_job and setting teuth_bin_path: https://github.com/ceph/teuthology/blob/main/teuthology/dispatcher/init.py#L141-L148
Here in prep_job is where the requested branch is cloned: https://github.com/ceph/teuthology/blob/main/teuthology/worker.py#L174-L176

Thanks for sketching that out @zmc!
Here's the ceph fix for this: https://github.com/ceph/ceph/pull/50616
Although maybe we still want this to be merged?

We might - can we run it through, say, a job from the smoke suite?

We might - can we run it through, say, a job from the smoke suite?

Here's a run with fs:workload: https://pulpito.ceph.com/pdonnell-2023-03-22_17:35:48-fs:workload-wip-pdonnell-testing-20230322.005419-distro-default-smithi/

Hello members, I am an Outreachy intern, hoping to be part of this open source contributing community. @zmc , @batrick.

Hello members, I am an Outreachy intern, hoping to be part of this open source contributing community. @zmc , @batrick.

Hi Kenneth, who is your mentor? Please feel free to communicate via the mailing lists to get more involved. These pull requests are not the right venue as you may get lost. :)

@zmc thanks for checking on it. This looks good to me:
https://pulpito.ceph.com/zack-2023-03-29_22:34:19-fs-wip-pdonnell-testing-20230329.131031-distro-default-smithi/

ok. Thanks @batrick for the advice. My mentors are Sirivadhna, and Mathuria. I wonder whether they are present on this platform.


Improve visual design / interaction design

Animate doors?

Always room for improvement but closing for now with #16