[Bug Report] OSMC with Kodi 18 alpha not installing all dependencies

I'm submitting a ...

[X] bug report
[ ] feature request
[ ] support request

General infomration
Prerequisites

[X] Are you running the latest version?

Description
I get this issue on 0.12.7, running OSMC updated to the latest alpha for KODI 18
After installing any version of the plugin I get an error and the dependencies area shows that inputstream.adaptive and script.module.pycryptodome are unavailable. Nothing I have been able to do gets them to install with the rest of the plugin.
I have tried to install multiple versions (after completely uninstalling between tries). I have tried 0.12.7, 0.12.6, 0.12.5, 0.12.4, 0.12.1, 0.12.0 and various 0.11.x versions with no success.
This seems related to this issue: https://github.com/asciidisco/plugin.video.netflix/issues/200 but I am not running windows but instead OSMC.
Steps to Reproduce

Install KODI 18 alpha onto OSMC nightly
download this repo
put on flash drive
install repo into OSMC
install netflix addon from repo
addon CANNOT install inputstream.adaptive and script.module.pycryptodome

Expected behavior: addon install dependencies and works
Actual behavior: addon fails to install dependencies inputstream.adaptive and script.module.pycryptodome
Context (Environment) OSMC nightly
Installation

[X] I installed the plugin via zip from the Releases page
[ ] I´m using the Netflix Repo
[ ] I´m using a different source (Please tell which)

Operating System

[ ] Linux (x86/x64)
[ ] OSX (x86/x64)
[ ] Windows (x86/x64)
[X] Linux (ARM) - OSMC running on Raspberry Pi 3
[ ] Android

Additional informatin on the environment
OSMC nightly running on Raspberry Pi 3
Debug log
No idea how to access the debug log in OSMC, everytime I go to the log it is empty despite getting a notice of error being put into it.

I second that, faced the same problem yesterday.

I had the same thing happen to me.

I tried to start over and only install 0.12.4 and that did not work either, exactly the same message about 2 dependencies not being available.

Same here. Tried to install inputstream.adaptive and script.module.pycryptodome manually. Did not help.

You need to manually enable inputstream in the add-ons.

I've tried that as well as manually installing it and it does not work nor allow you to enable it as far as I can determine. If you want to provide detailed instructions for how to enable it I can try to follow them and let you know if that specifically solves it but I have already attempted enabling the add-on.

I've also tried to install various different nightly builds of kodi 18 with no success...

Inputstream appears in my plugins without having installed it manually. Like @DrCord, it cannot be enabled.
I updated to a new build of OSMC and no change.

Gymnae has the exact same behavior I see with multiple version of OSMC nightlies. The plugin shows in my list but cannot be enabled.

Plugin is enabled here. But it does not solve the problem.

have you installed libwidevine library?

@kommagent agreed, my list of plugins does show inputstream.adaptive as active but this plugin during install shows inputstream.adaptive as "unavailable"

@pinoelefante that does not show as a package that is installable:
sudo apt-get install libwidevine
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libwidevine

curl -Ls http://nmacleod.com/public/libreelec/getwidevine.sh | bash

@pinoelefante output of that command is:
ERROR: Unable to determine ARCH for this system!
ERROR: Specify ARCH=arm or ARCH=x86_64 if /etc/os-release does not define a suitable ARCH

@pinoelefante output of above command:
ERROR: Unable to determine ARCH for this system!
ERROR: Specify ARCH=arm or ARCH=x86_64 if /etc/os-release does not define a suitable ARCH
also tried running command with ARCH:
curl ARCH=arm -Ls http://nmacleod.com/public/libreelec/getwidevine.sh | bash
and got the same output with the above error.

Check out the post below, you need to revise the getwidevine script.
https://discourse.osmc.tv/t/how-to-use-netflix-on-osmc-rpi2/11478/18?u=rspierenburg

@rspierenburg tyvm for the information, that seemed like it should work, however it did not...both things installed as the guide you linked to said but it did not make any change in the netflix plugin being able to show them as available dependencies.

I just went to the latest (17.8-136, 25 Nov 2017) build of Kodi 18, still no luck, same exact issue.

If you can tell me a version of OSMC nightly to install that does work for sure then we could proceed down that road. @Gymnae

I wish I could, I couldn't get it to run at all. Thus I hoped that mentioning Sam and his project here would maybe trigger an involvement.

I'm hearing people saying that it doesn't work with OSMC and HW Accerleration (aka OMXPLAYER).  I can get mine to play with the omxplayer disabled but its really jerky and the audio and video keep getting out of sync.  So if that is the case then, yes the Plugin does technically work for me eventhough it still mentions missing dependencies, but no it is not usable in its current state IMO.

Hi
Thanks for bringing this to my attention.
I don’t keep a close eye on nightlies as much as I should. Users are using Netflix with the latest builds.
If this is a recent regression, can someone point me to a report on the OSMC forum?
Cheers
Sam

Dear Sam, awesome that you post here as well, thank you.
I haven't posted on the forum, but the most up to date discussion regarding netflix and kodi 18 is pertaining the rpi2 and didn't cover the problems described here [1]  but mind you, vero4k has the same issues.
[1] https://discourse.osmc.tv/t/how-to-use-netflix-on-osmc-rpi2/11478/33

Cheers. I'll take a look at this shortly.
Sam

CC @StormTrooper

Maybe these two snippets from the log help to identify the problem:
08:04:46.265 T:3528401904   ERROR: Rename - Error renaming file /home/osmc/.kodi/addons/temp/4f0e9737-256f-46f9-99dd-e6845fc3b62c
08:04:46.265 T:3528401904   ERROR: Failed to move new addon files from '/home/osmc/.kodi/addons/temp/4f0e9737-256f-46f9-99dd-e6845fc3b62c' to '/home/osmc/.kodi/addons/plugin.video.netflix'
08:04:57.264 T:3930252272   ERROR: EXCEPTION: Non-Existent Control 300
08:05:08.442 T:3482317808 WARNING: CPythonInvoker(4): Script invoked without an addon. Adding all addon modules installed to python path as fallback. This behaviour will be removed in future version.

20:52:21.893 T:3885315056 WARNING: CPythonInvoker(1, /usr/share/kodi/addons/script.module.osmcsetting.updates/service.py): the python script "/usr/share/kodi/addons/script.module.osmcsetting.updates/service.py" has left several classes in memory that we couldn't clean up. The classes include: N9XBMCAddon7xbmcgui12ControlImageE,N14PythonBindings31XBMCAddon_xbmc_Monitor_DirectorE,N9XBMCAddon7xbmcgui6WindowE

Updated to new nightly and upgrade vero4k to debian stretch - same error

I've pinged GMC about this. We've just been working on preparing nightlies so they work well with Stretch.

Appreciate your support with this. I did not install a package manually with PIP, I just added the repo. libwine is already part of the nightlies, so I thought I did not need to add something manually via pip

I managed to get it to install.
Turns out that a previous installed via the repo created a file at /home/osmc/.kodi/addons/plugin.video.netflix instead of a dir. I removed that file and copied the temp folder created by a repo or zip based install over by hand:
cp -r /home/osmc/.kodi/addons/temp/5b0f783f-b12a-4c5d-8216-fa264f1d4040 /home/osmc/.kodi/addons/plugin.video.netflix
Now the plugin starts, I can log in, but nothing plays. Thus I added to the related bug https://github.com/asciidisco/plugin.video.netflix/issues/206

The file /home/osmc/.kodi/addons/plugin.video.netflix does not exist on my box so no way to apply this fix to get things working-ish... @Gymnae

@DrCord Do you have a folder in /home/osmc/.kodi/addons/temp/  which could be the plug-in stuck there? Do you have log messages which could relate to a copy problem?
In regards to your problem of
ERROR: Unable to determine ARCH for this system!
ERROR: Specify ARCH=arm or ARCH=x86_64 if /etc/os-release does not define a suitable ARCH

run export ARCH=arm before running the command

Just encountered a similar issue here, except I am using a 2nd Gen Fire TV stick and the latest Kodi nightly. I manually enabled inputstream.adaptive in the default Kodi repo so the Amazon Video addon works, but those two dependencies still show as "unavailable" so the Netflix addon won't install. (Not a big deal as there is a native Netflix app for me, but I do prefer the Kodi interface at times.)

It should now work on Vero 4K, but you still need to manually install the dependencies at this time I think.
https://github.com/osmc/osmc/commit/7e57403d751ecdd18852cf9614a0015439ed90a7 should be included in a GMC nightly shortly.

Not sure if the nightly with the changes has been deployed, but I ran an update of kodi and tried again, same error:
0:58:05.552 T:4079677504  NOTICE: VideoPlayer::OpenFile: http://localhost:38286/manifest?id=80028554 20:58:05.553 T:3994022656  NOTICE: Creating InputStream 20:58:08.057 T:3994022656   ERROR: Interface_Filesystem::get_property_values - invalid data (addon='0xee1778d0', file='0xe809ec10') 20:58:10.821 T:3724550912   ERROR: Traceback (most recent call last): 20:58:10.835 T:3724550912   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 290, in _handle_request_noblock 20:58:10.836 T:3724550912   ERROR:     self.process_request(request, client_address) 20:58:10.836 T:3724550912   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 318, in process_request 20:58:10.836 T:3724550912   ERROR:     self.finish_request(request, client_address) 20:58:10.836 T:3724550912   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request 20:58:10.836 T:3724550912   ERROR:     self.RequestHandlerClass(request, client_address, self) 20:58:10.836 T:3724550912   ERROR:   File "/usr/lib/python2.7/SocketServer.py", line 652, in __init__ 20:58:10.836 T:3724550912   ERROR:     self.handle() 20:58:10.836 T:3724550912   ERROR:   File "/usr/lib/python2.7/BaseHTTPServer.py", line 340, in handle 20:58:10.836 T:3724550912   ERROR:     self.handle_one_request() 20:58:10.836 T:3724550912   ERROR:   File "/usr/lib/python2.7/BaseHTTPServer.py", line 328, in handle_one_request 20:58:10.837 T:3724550912   ERROR:     method() 20:58:10.837 T:3724550912   ERROR:   File "/home/osmc/.kodi/addons/plugin.video.netflix/resources/lib/MSLHttpRequestHandler.py", line 41, in do_POST 20:58:10.837 T:3724550912   ERROR:     self.wfile.write(base64.standard_b64decode(b64license)) 20:58:10.837 T:3724550912   ERROR:   File "/usr/lib/python2.7/base64.py", line 96, in standard_b64decode 20:58:10.837 T:3724550912   ERROR:     return b64decode(s) 20:58:10.837 T:3724550912   ERROR:   File "/usr/lib/python2.7/base64.py", line 75, in b64decode 20:58:10.837 T:3724550912   ERROR:     return binascii.a2b_base64(s) 20:58:10.837 T:3724550912   ERROR: TypeError: a2b_base64() argument 1 must be string or buffer, not bool 20:58:10.877 T:3994022656   ERROR: AddOnLog: InputStream Adaptive: License update not successful (no keys) 20:58:10.878 T:3994022656   ERROR: AddOnLog: InputStream Adaptive: Initialize failed (SingleSampleDecrypter) 20:58:10.879 T:3994022656   ERROR: CVideoPlayer::OpenInputStream - error opening [http://localhost:38286/manifest?id=80028554] 20:58:10.880 T:3994022656  NOTICE: CVideoPlayer::OnExit()

Not yet. Build is still running. Will be fixed in 17.8-150

Light speed, thank you :)

Keep an eye out for a new build and the instructions. You’ll need to uninstall and reinstall some addons

Nighty build uploaded which fixes the issue.
https://discourse.osmc.tv/t/testing-kodi-18-leia-builds-for-vero-2-4k/23059/216?u=gmc
If you previously had Netflix addon installed you will need to remove and re-install.  There is something cached within the addon so even with OSMC fixed it still failed for me until I removed/re-added plugin.

I still get the exact same inputstream adaptive and pycryptodome unavailable dependencies errors as before this new build. On raspberry pi 3.

Yeah! it works for me! Awesome!
Here are the steps I followed:
sudo apt-get update
sudo apt-get dist-upgrade

The apt commands might not have been necessary, but for me the GUI update command didn't give me the 150 nightly
To get rid of dependency errors:
sudo apt-get install build-essential python-pip
sudo pip install -U setuptools
sudo pip install wheel
sudo pip install pycryptodomex

(thanks to Joakim_Sandstorm of OSMC foum)

Then I deleted the addon via GUI and made sure no residues were left in addons folder via SSH
rebooted
Installed addon again via repo
Was asked for login, logged in

And it works!

This seemed to work for me! no playback slowdown as far as I can tell. Thanks so much for your help!!! @Gymnae

the expanse won't come up in my search on netflix and I cannot find any other 1080p video to play. 720p video works fine as well as 4k.

Interesting that 4k works fine for you. I also tried some 1080p movies and the problem was the same for all. I just checked my downstream, it's 90mbits - should be fine

I'll play some stuff today and report back if I see any issues.

It might be a vero4k problem. Just look at the load on the system when streaming a 720p video. There's no performance left for 1080p or more:

Yeah, I use a Raspberry Pi 3 with a heat sink for the ram and a dual fan as well as I was having overheating issues once I started running older versions of Kodi LEIA with certain videos, not at all since upgrading to the cooling case...

The decoding isn’t hardware accelerated so is indeed being done in software. We might be able to get some more performance out of this

I've been noticing that certain high def shows the audio and video get out of sync.

The device is probably struggling

I am running rbp2-mediacenter-osmc                17.8-152    and still having this error. Has anyone gotten this to work on the pi (since it seems to be working on the vero)

The dependency error?
This is just a warning provided that you have installed them -- Kodi is unaware that the dependencies are satisfied

I thought so. I get an error when I try and run the plug in but don't see anything new in /var/log what am I missing. How do I get the plugin to be aware the dependencies are satisfied?
Thank you!

We haven't solved that yet -- but it is not necessary for it to work as explained.


How can I use it in PWA React Native Web?

when I install it in react-native-web project in shows an error : Unexpected token
is this library only for Native (android and ios) ?

It's only for android and iOS. No web support.

Why is this closed? This module will be really valuable if we can have this in web either.
Here is a great example from expo!
@ravirajn22 Will react-native-image-picker not going to support web in future releases either?

I dont know about web API for image picking, so someone should send PR. I will look into expo to see if its feasible for this library to include Web support

Why is this closed? This module will be really valuable if we can have this in web either.
Here is a great example from expo!
@ravirajn22 Will react-native-image-picker not going to support web in future releases either?

It would be really nice to add web support to this library.
I'll try to send a PR based on that code but without Expo dependencies

Why is this closed? This module will be really valuable if we can have this in web either.
Here is a great example from expo!
@ravirajn22 Will react-native-image-picker not going to support web in future releases either?

It would be really nice to add web support to this library. I'll try to send a PR based on that code but without Expo dependencies

Hi @alessiocancian, have you able to achieve this?


"csi-node-driver" daemonset is using default service account in calico version - v.3.24.x

"csi-node-driver" daemonset is using default service account in calico version - v.3.24.x
Expected Behavior
csi-node-driver daemonset should use a custom service account.
Current Behavior
csi-node-driver daemonset created from tigera operator calico version - v3.24.x is using the default service account.
Possible Solution
a. A custom service account should be created by the operator and used by the csi-node-driver
(or)
b. Provide an option to pass the custom service account via values.yaml just like we have for image and registry variables currently.
Context
Our gatekeeper policies are not letting the pods to get created as its using the default service account instead of having a custom one. Though we can amend our gatekeeper policies, It's not ideal to have a default service account being used.

Yeah, we should do this for best-practice purposes.
I should note that in this case:

The default serviceaccount has no permissions bound to it, so anyone with that serviceaccount gets no API access.
The CSI driver itself doesn't make any API calls, so once we split off to another serviceaccount that SA will also not get any permissions bound to it.


Error on switch case that isn't valid pattern in 2.19 library

I'm testing enabling the records and patterns flags. I'm seeing a failure in language/switch/switch_legacy_test. A simplified repro:
// @dart = 2.19
main() {
  switch (1) {
    case 1 + 1:
      print('two');
  }
}

Since this sets the language version to 2.19, the switch case should be fine since it should be parsed as a constant expression, not a pattern. But I get:
../../../Documents/temp.dart:4:12: Error: The binary operator + is not supported as a constant pattern.
Try wrapping the expression in 'const ( ... )'.
    case 1 + 1:
           ^

I get this error even if I set the language version of the library to something ancient like 2.10.

Same root cause as #51625


Direct login for headnode/assets/templates/email/web-token.html

Am I correct in thinking that appending /login/{{.Token}} to the headnode URL is the most direct way to sign in to the Dashboard using the token? If so, I propose that we offer this URL directly as a clickable link.

That was for the portal that Ciro is developing. It will be replaced as soon as the EdgeNet Portal, an extension of Kubernetes Dashboard, is ready.

I am closing the issue due to the removal of password management by EdgeNet extensions. The file doesn't exist anymore.


Fix #112 by removing artifact type/extension check

Fixes #112. The extension as returned by the Maven Artifact Type Registry is always used. As a test I'm attaching a test file -- using the Build Helper Maven Plugin -- for which the type (text-file) and extension (txt) don't match. With the PR all tests pass, without it they don't.

Pull Request Test Coverage Report for Build 400

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.7%) to 74.206%

Totals

Change from base Build 394:
0.7%

Covered Lines:
584

Relevant Lines:
787

💛  - Coveralls

Wow. Thank you for this contribution.
This bit of code existed from the very early beginnings of the project, where one it's first uses were on mulesoft applications. The mule packaging type from the mulesoft plugins worked by attaching a .zip file, but didn't properly map that the 'mule' package should produce a .zip, causing issues. The resulting idea was to just use the extension from the attached artifact file rather than the extension defined by the packaging type (which wasn't defined) and log a warning that things weren't configured properly with the packaging plugin being used (in my previous case - mule).
I never modeled a test case for this, because I'd moved on from supporting the mulesoft app efforts at that client, and without a test case existing, forgot about this. :-( It may have been that the master branch builds would have failed for those projects as well -- I don't think those projects ever updated to using this plugin, and if they did, they'll be using a very old version of the plugin and this won't matter anyhow. :-)
So if I'm looking at this PR properly, this should get things 'working' again for you, and for other properly-configured packaging plugins.
Anyone want to take a stab at seeing if a mulesoft package will work with this?

It looks like the Artifact Type Registry doesn't always return the right extension. For example the Maven Bundle Plugin offers a packaging type bundle, with extension jar. See its components.xml. Using the ArtifactHandler instead of the Type Registry does return the correct extension, and also works for the other cases (e.g. files attached with the Build Helper Maven Plugin).


tls/random: set min version to 7

Ticket
If your pull request is related to a Suricata ticket, please provide
the full URL to the ticket here so this pull request can monitor
changes to the ticket status:
Redmine ticket: https://redmine.openinfosecfoundation.org/issues/6990

Merged in #1809, thanks!


How to get the file size of the selected image?

Thanks.

Closing as duplicate to https://github.com/NativeScript/NativeScript/issues/5465


WebApp:staticwebapp - add command for zip deploy

Add a command to deploy to a site by providing a URL to a zip file.
@miwebst to provide API details and sample zip file.

staticwebapp

staticwebapp

Thanks for reporting. Considering this as feature request,we will work on this based on priority.

FYI @panchagnula


tornado.iostream.StreamClosedError

Problem Description
I honestly have no idea. The terminal popped an error message saying:
Traceback (most recent call last):

  File "/opt/homebrew/Cellar/mitmproxy/8.1.0/libexec/lib/python3.10/site-packages/tornado/websocket.py", line 1102, in wrapper
    await fut

tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

  File "/opt/homebrew/Cellar/mitmproxy/8.1.0/libexec/lib/python3.10/site-packages/tornado/websocket.py", line 1104, in wrapper
    raise WebSocketClosedError()

tornado.websocket.WebSocketClosedError

Please lodge a bug report at:
	https://github.com/mitmproxy/mitmproxy/issues

and I thought I'll be a good citizen and report the error.
Steps to reproduce the behavior:

System Information
Mitmproxy: 8.1.0
Python:    3.10.4
OpenSSL:   OpenSSL 1.1.1o  3 May 2022
Platform:  macOS-12.4-arm64-arm-64bit

I was able to reproduce this once but not consistently. I had two browsers open at 8081, then opening a browser that proxied a website with lot of requests and then closed one of the mitmweb clients. It actually looked like this:
// hundreds more of these
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message
tornado.websocket.WebSocketClosedError
[::1]:39066: client disconnect
[::1]:39068: client disconnect
[::1]:39070: client disconnect
[::1]:39074: client disconnect
[::1]:39076: client disconnect
Traceback (most recent call last):

  File "tornado/websocket.py", line 1102, in wrapper

tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

  File "tornado/websocket.py", line 1104, in wrapper

tornado.websocket.WebSocketClosedError

Please lodge a bug report at:
	https://github.com/mitmproxy/mitmproxy/issues

I think this is a matter of mitmweb not properly keeping track of WebSockets and trying to write to closed ones.

After doing some digging this might as well be caused by an upstream bug https://github.com/tornadoweb/tornado/issues/2958 which would cause the WebSocket to never be removed from the set:
https://github.com/mitmproxy/mitmproxy/blob/73c38f698d42002947e46294498b2166f3139cf4/mitmproxy/tools/web/app.py#L275-L283

Honestly it feels like we should just swallow the error in broadcast here and be done with it.

And also if closedError: self.connections.remove(self) :eyes: ?
But I think that would only get rid of the
ERROR:root:Error sending message
Traceback (most recent call last):
  File "mitmproxy/tools/web/app.py", line 292, in broadcast
  File "tornado/websocket.py", line 337, in write_message

and not the uncaught exception? I don't know where that originates though.

Also seeing this if I make a large number of requests (like a load test).


Sanity checks are hit when creating a tx with a too large feerate

Reported by @kloaec

Happens with 555 feerate. I think I remember such an error before

I'm not even sure it's about the feerate, here is the checks we are currently performing, for reference:
https://github.com/wizardsardine/liana/blob/e4d4fcd9fc13b33ee89be0662bab5107fd8493c4/src/commands/mod.rs#L130-L180

Hmm actually @kloaec reported that using a lower feerate (55) was fine. So it must be the negative fee check that is failing:
https://github.com/wizardsardine/liana/blob/e4d4fcd9fc13b33ee89be0662bab5107fd8493c4/src/commands/mod.rs#L154-L161

Lol: https://github.com/wizardsardine/liana/issues/181. As in most cases, it's because it was missing a functional test..


Create chart annotation?

Create chart annotation?
same: https://www.dropbox.com/s/9nr5hqo5deoxxvi/ex.png?dl=0

This is called "Legend" in this system.
You can have a look on "legendTemplate" option ;)

@TRUNGKIEN1013 chart annotations have been discussed in #511
On canvas legends are supported in version 2 (currently in beta). If you'd like to try out v2, documentation is available at http://nnnick.github.io/Chart.js/docs-v2/


A few simplifications related to ops.cond.

Fixed an issue where an error resulting from using ops.cond was obscured by a different error caused by doing a symbolic call.
Remove support for KerasTensor as return values for the functions passed to ops.cond as it is not a valid use case.
Remove support for functions instead of tensors as inputs in backend.compute_output_spec as there is no use case for it.

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

Project coverage is 59.49%. Comparing base (c8700f4) to head (21aa357).
Report is 62 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #19221       +/-   ##
===========================================
- Coverage   80.14%   59.49%   -20.65%
===========================================
  Files         341      362       +21
  Lines       36163    39149     +2986
  Branches     7116     7579      +463
===========================================
- Hits        28982    23291     -5691
- Misses       5578    14371     +8793
+ Partials     1603     1487      -116

Flag
Coverage Δ

keras
59.49% <100.00%> (-20.50%)
:arrow_down:

keras-jax
59.49% <100.00%> (-3.57%)
:arrow_down:

keras-numpy
?

keras-tensorflow
?

keras-torch
?

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

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


Failed upgrade to 0.13.27

Issue

Tried to update to latest version 0.13.26 -> 0.13.27.
Upgraded dependent Node.js first. v16.13.0
Update failed.  Message as below.
Log Messages

USER: pi
DIR: /usr/local
CMD: sudo -E -n npm install -g homebridge-hue@latest
TypeError: Class extends value undefined is not a constructor or null
at Object. (/usr/local/lib/node_modules/npm/node_modules/socks-proxy-agent/dist/agent.js:114:44)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object. (/usr/local/lib/node_modules/npm/node_modules/socks-proxy-agent/dist/index.js:5:33)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object. (/usr/local/lib/node_modules/npm/node_modules/make-fetch-happen/lib/agent.js:161:25)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
Command failed. Please review log for details.
Debug Files

same here

Ditto

I think this is an error with an old version of npm that fails under NodeJS v16.  Can you (re-)install npm or does that show a similar error?  I’m afraid the workaround is to downgrade NodeJS, update npm, update NodeJS.  See https://github.com/homebridge/homebridge/issues/3002#issuecomment-955994607

Hmm, beyond my abilities. I’ll have to wait until someone else confirms or a way to update through the normal tools arrives.

Tried to do the downgrade of node and upgrade of npm without instructions (didn't see the link).  Ended up somehow removing npm completely.  Had to reinstall my homebridge image from scratch and then restore the config.  Now working.  From what I saw whilst trying to do this, I would concur with your assessment.  Even just running npm -V with latest node.js was giving me the same error until I downgraded node.js to 16.1.0.

I think this is an error with an old version of npm that fails under NodeJS v16. Can you (re-)install npm or does that show a similar error? I’m afraid the workaround is to downgrade NodeJS, update npm, update NodeJS. See homebridge/homebridge#3002 (comment)

I can confirm that following the steps in the link work.


Update Kured chart to create Service for prometheus metrics

Signed-off-by: Raza Jhaveri<EMAIL_ADDRESS>What this PR does / why we need it:
Creates a svc to expose the prometheus exporter
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ x ] DCO signed
[ x ] Chart Version bumped
[ x ] Variables are documented in the README.md

/assign @lachie83

/ok-to-test


Less Nauseating Game of Life 3D Settings for First Example

Seriously, I can see this affecting your adoption rates. The Game of Life 3D example eventually chills out and is less nauseating. But I can tell you that, as a new user struggling to get the settings right and not yet knowing how to change what I'm recording, I'm getting nauseous every time I try to learn your software.
That's not a state of mind that you want new people experiencing on top of the necessary stress involved in learning a new system. I highly suggest you fast forward the example to a more chill state within Game of Life 3D. You can include the frantic state to demonstrate slow motion and blur effects in a second or third example file.

Fixed in https://github.com/spite/ccapture.js/commit/1a11d17968c57a7f061219b53f703519288b01c2


[all] interrupt consolidation

This is a topic that both @eunchan and @mdhayter raised before.
Right now, all interrupts of a module are fully exposed to the top level.  For blocks like UART / I2C, where there will likely be multiple instantiations per design, this greatly increases the number of overall interrupts and connections / logic to rv_plic.
I would like to propose we limit each peripheral to no more than 4 interrupts.. Just at a quick glance, these modules all have a lot

GPIO
UART
I2C
USBDEV
USBUART

For GPIO, @eunchan has already proposed that there might not be a need for an interrupt per GPIO.
For UART, it might make sense to group all the tx / rx interrupts.
For I2C, it might make sense to group all the tx / rx / error interrupts separately.
Similar story for USB.
Let me know what you guys think.

I should acknowledge that this interrupt consolidation might cause a lot of pain for DV (especially for UART / I2C).
So we think a bit about whether this makes sense.
On bronze for example, there are 3~4 UART / I2Cs each, so these probably easily scale into 50~60 interrupts?

Can we get a cost-benefit analysis on this?  As with everything, I'm really concerned about the burden involved in this change.    The effort spent on this change should be balanced against the effort on meeting our other M3/M4 goals.    I think we have a big challenge ahead of us as it is.
If these types of details are essential design, then we can adapt, but we should retool the schedule to account for them, because I'm sure there are lots of small things like this that we could do to simplify the design.   However, making cost-saving--but non-critical-- things like this a requirement without relaxing the schedule does not seem feasable to me right now.

Can we do this at top level?  Is there some way to merge interrupts outside the IP but before the PLIC?  Just throwing that out there...

i would not want to do this out in the top level. If we choose to do this, it should be contained in the ip.  In terms of critical, this is NOT super critical.
I think the main issue (as Eunchan had pointed out), we are running out of interrupt slots on rv_plic, and by having this many interrupts, the rv_plic (which uses a tree-like function to determine priority of interrupts) gets unnecessarily big.
I think a change like this is a really small burden on the design, most of it lands on DV.  (Just based on experience going through a similar exercise before elsewhere).
Eunchan let me know if I'm wrong about what you noticed on bronze.

Regarding schedule / resources from WD, sorry I don't have any visibility into that.
So feel free that to discuss that with Dom / Scott on what's realistic for WD.
From Google side, I think it's going to be a sprint for the next 6 months anyways (no it is not going to be a marathon, just long range sprinting).

i've removed i2c from the initial proposed list.
Let me know what others think.  It sounds like there's no appetite for such a change.  That's fine with me also.
I'll close this issue by EOD if there are no other thoughts.

Hi @tjaychen I agree it is small.  However even small things take far longer in this project than I would have expected, and I think Google management would concur.
I see the technical benefit certainly.   However I'm inclined to make this a lower priority than getting all V2 related tasks for I2C, PWM, SPI HOST, and pattgen done, as those are all slated for the same DV person.   Well get there eventually, it's just a matter of timing.

i've removed i2c from the initial proposed list.
Let me know what others think. It sounds like there's no appetite for such a change. That's fine with me also.
I'll close this issue by EOD if there are no other thoughts.

Hi Tim,
Please don't get me wrong, I think there is technical merit.  We should leave I2C on the list.   I just don't want to break momentum for a small change, and I want to see us finish the critical stuff before making non-critical changes.
If you think it is important and we should do this, then please keep I2C on the list.   We'll get to it when we can!  Though I think we do need to prioritize all changes from here on out.
I wonder if @igk8 and @tunghoang290780 weigh in with their opinions.

I expect with fully implemented designs in top_earlgrey, rv_plic could be 5 times bigger than current, which is around 50kGE ?
But personally, I think the IPs need normally one or two interrupts unless the IP is time sensitive thing (I don't see anything other than alert_handler has that kind of time critical events..). One for normal operation events, the other is for error notification (not through alert system). Then we could maintain or even reduce the rv_plic IP size.
From SW perspective, I envision that SW will have one more wrapper ISR that reads Interrupt Status register from IP and call the sub ISR.

This does increase DV effort. One thing that could mitigate it is if we could standardize the aggregation across ALL comportable IPs.

@eunchan agreed, if/when we decide this is need, we probably could do this with just two interrupts, if we really wanted to economize. I'm trying to think if there is some clean way we could recommend for mapping all the exising interrupts to these priority categories.  Some special registers for mapping out the status.   If we were to do this could this be done with some "interrupt sub-status" register, that enumerates all the original interrupt status conditions that we want to advertize?
Such a generalization probably wouldn't reduce the DV burden though.

On a procedural note:  Does this count as a port change from the point of view of the lifecycle review process?   It would change the hjson.  Does this mean we would want a D1/V1/D2/V2 review all the way through again?  I suppose the reviews could be merged...

closing the issue.
It seems in general the project needs to trend forward.  So until this breaks, no point looking back i guess.

I want to leave this open as it will continue to grow to be a bigger issue. It can be a big change to DV but if it blows up our area we won't have much choice. @eunchan can you give a full accounting here of where all of the interrupts are coming from? Then we can poll the different designers and see if we expect more growth. Also, if we're near a tipping point, it might just be the case that we only need to slim down a few that are multiply instantiated.
As for D transitions, I think it would drop a design from D2 back to D1 with a change like this, but not farther back, and I think it would recover pretty quickly.

Here's the summary of current interrupt in opentitan.
https://docs.google.com/spreadsheets/d/1IISseleV-Ho44div_9d0YXhIXC0fKzb9NHQvZqiWoDM/edit?usp=sharing
At the "TBD" sheet, I tried to add the modules to be instantiated in the top-earlgrey but not complete yet.

thanks eunchan, do you know if there's a max that the rv_plic spec is able to support..?
Also, I'm guessing the biggest cost with lots of interrupts is just the function that determines priority, is that right?

thanks eunchan, do you know if there's a max that the rv_plic spec is able to support..?

it depends on the PLIC memory map and as far as I know (maybe wrong) around 1023 interrupts.

Also, I'm guessing the biggest cost with lots of interrupts is just the function that determines priority, is that right?

yeah right. This affects the area a lot.

Two things we can do to reduce the cost of the interrupts:

Interrupt consolidation:

Need to change the design (IP top level) by designer, to have ORed interrupt as an interrupt output not the individual one.
.hjson to be revised to indicate whether the IP has consolidated interrupt or not. If consolidated, its name too
topgen to assume the interrupt port name and connect to RV_PLIC.
Need to revise DV interrupt agent.

Keep the interrupt generation logic as it is but reducing the RV_PLIC size:

Make some portion of the interrupts to have fixed priority when generating the RV_PLIC --> reduce the area on interrupt aggregation logic (plic_gateway)
Removing the option of edge and level selection for certain register (removing edge detector mostly)
Need to work on RV_PLIC to be parameterized those values too.
Need slight modification of DV environment to get the fixed priority value.

CC: @gkelly

these are good options, in addition to SW feedback (@gkelly) we should have @sriyerg and DV team consider the cost to these two.

With option 1:

We just have a "pin" interface for sampling interrupts - there is no dedicated interrupt agent - so 0 extra cost here.
IP level DV environment / checks will need to be updated however

UART for example, should be back to V3 status / clean regression in about a week (similar or less for other IP level environments depending on current status). @weicaiyang

Common base lib has some "shared" interrupt testing that will have to be updated - ~3 days

Will need to know whether intr are consolidated or not (easy, just add a bit setting)
This will need to make the assumption that ALL interrupts are consolidated (easier to implement)
If the desire is to pick and choose only a subset of interrupts to consolidate and expose the rest, (or consolidate in separate groups) then that will incur more work (not at all preferred)

At chip level:

No change in current PLIC test plan (will stick to the plan to develop the automated test, it will just work slightly differently), so 0 extra cost.
Existing tests will need some updates: ~3 days.

With option 2:

Will RV_PLIC still remain "generic" with this approach?
There are now two specializations - multi vs fixed prio, level/edge vs level only. Does this mean 4 sets of interrupt inputs (multi prio+level/edge, fixed prio+level/edge, multi prio+level only, fixed prio+level only)?
RV PLIC is FPV only - so I suppose a weeks time here as well to get the FPV TB updated. @cindychip
No change in DV testbenches, so 0 extra cost
At chip level:

No change in current PLIC test plan, so 0 extra cost.
Existing tests / PLIC DIFs will need some updates: ~4-5 days.

Option 2 seems better overall in terms of amount of work.

A week time should be good to get FPV updated if we plan to use option 2).

UART for example, should be back to V3 status / clean regression in about a week (similar or less for other IP level environments depending on current status). @weicaiyang

one week should be enough to update uart TB.

@eunchan would option 2 mean we are not in compliance with the plic spec..?

Reading of the register should look like conforming to the spec but writing to the priority registers for that specific interrupt will be ignored. So, yes, not 100% comply to the PLIC spec.

Hum.. Thinking about the fixed priority more.. I think the comparison logic won't be disappeared, as the threshold value is still configurable. Only the register portion would be eliminated. So, I think it won't affect the area much?

The latest guidance here is to:

We leave the pre-validated/ verified IPs as it is. No need to revise the designs to reduce the number of interrupts. But maybe worth to visit GPIO IP to reduce the 32 GPIO interrupts into one.
We encourage the new IP to have some consolidated interrupts. We do not mandate it to have only one interrupt but worth to have common thing into one (error interrupts into one , etc)

General guidance here is to not exceed 3~4 interrupts from IP.

In order to make consolidated IP, we could let IP designer to create Interrupt related registers (INTR_STATE, INTR_ENABLE, TEST) by hands or let auto gen and connect interrupt event line from merged events.

For example, if err_onekind , err_otherkind events exist, the owner may create err interrupt and connect as below:

assign event_error = err_onekind | err_otherkind;

prim_intr_hw #(
  ..
) u_err_intr (
  .event_intr_i(event_error),
 // ...
);

The latest guidance here is to:

We leave the pre-validated/ verified IPs as it is. No need to revise the designs to reduce the number of interrupts. But maybe worth to visit GPIO IP to reduce the 32 GPIO interrupts into one.
We encourage the new IP to have some consolidated interrupts. We do not mandate it to have only one interrupt but worth to have common thing into one (error interrupts into one , etc)

General guidance here is to not exceed 3~4 interrupts from IP.

In order to make consolidated IP, we could let IP designer to create Interrupt related registers (INTR_STATE, INTR_ENABLE, TEST) by hands or let auto gen and connect interrupt event line from merged events.

For example, if err_onekind , err_otherkind events exist, the owner may create err interrupt and connect as below:

assign event_error = err_onekind | err_otherkind;

prim_intr_hw #(
  ..
) u_err_intr (
  .event_intr_i(event_error),
 // ...
);

@eunchan thanks for the guideline. If there is no concern from gate count, verification, and integration can we close this issue? @sriyerg , @tjaychen
@tomroberts-lowrisc,  perhaps this info can be disseminated in a OT silicon meeting.

@eunchan thanks for the guideline. If there is no concern from gate count, verification, and integration can we close this issue? @sriyerg , @tjaychen
@tomroberts-lowrisc,  perhaps this info can be disseminated in a OT silicon meeting.

@eunchan @tjaychen Can we resolve this or should we move some of this guidance into our documentation still?

i think we should move this to future enhancement and documentation guidance.
it's still good to do long term.

Triaged for i2c, agree that some consolidation is worth considering but not for M2.5 so 'FutureRelease' is appropriate.

Triaged for gpio, same conclusion as for 'i2c'

Triaged for uart, same conclusion as above

Triaged for rv_plic, agree with @GregAC

Triaged for usbdev, same conclusions as above

I don't think this is something that is within scope for PROD due to the added churn.
Moving to backlog instead.
CC @moidx @GregAC @vogelpi


Validate and sanify openpype settings values when using them

Is your feature request related to a problem? Please describe.
Hello, i've just encountered a problem while using workfile builder on photoshop and Openpype did not find the file. The cause was a space character before my path in openpype settings.
My fault, yet ... I can't help but feel that a system should exist to sanify
settings assuring no bad entry exists. Actually openpype settings is a simple dict, OpenPype settings should be
a special dict incorparating with custom behaviour to check inputs.
Describe the solution you'd like
A class acting as a dict (implementing getitem method or inhereting dict class) returning sanified values (trimed, clamped, defaulted and formated) from settings to users (devs)
Information on each setting sanification could be in current openpype setting's json objects
Describe alternatives you've considered
Sanifying inputs on save for openpype settings ? More static, less usefull for formating case.
Sanifying inputs on json load ? Same problem than sanify on save, maybe easyer to debug, yet not as easy than a clearly defined class with getitem()
Doing my job and double checking when i change a setting ? Valid point, but a smart setting system could be nifty and open possibilities to other many systems and operations on settings (specificaly path formating)
[cuID:OP-2346]

Actually openpype settings is a simple dict

Well on load it is just dict but there are settings entities used for saving, validation, handling overrides, etc. . We have in plan to validate values more but we have somehow define their validations per entity type which is not as easy considering they should somehow work in Setting UI too.
Your issue can be actually solved right now as path input entity can strip value on save but that's actually all that can do.

As in ... Path input entity trim by default the value or should i add somewhere in the entity an key to true to ask for a trim ?
Because for now, Workfile Builder settings is using path entities and yet I encountered the above issue.

Created PR https://github.com/pypeclub/OpenPype/pull/2550


dartdevc.bat on windows crashes when using rxdart ^0.23.1

This tracker is for issues related to:

dev_compiler

Dart SDK Version (dart --version)
C:\tools\dart-sdk\bin\dartdevc.bat --version
2.7.1

Whether you are using Windows, MacOSX, or Linux (if applicable)
Windows server 2016

Whether you are using Chrome, Safari, Firefox, Edge (if applicable)
Powershell in administrator mode

repro step:
install chocolatey on Windows
install dart using choco:
choco install -y dart-sdk
make a new dart project with this pub.yaml
name: bloc
description: Bloc Dart package.
version: 0.0.1
author:
homepage:

environment:
  sdk: ">=2.1.0 <3.0.0"

dependencies:
  rxdart: ^0.23.1
  tuple: ^1.0.3
  meta: ^1.1.8

dev_dependencies:

get packages
C:\tools\dart-sdk\bin\pub.bat get
here is how the file structure looks like:
./.packages
./lib
./lib/main.dart
./pubspec.lock
./pubspec.yaml
Running a compilation crashes:
And if I comment the import of rxdart the crash disappears
C:\tools\dart-sdk\bin\dartdevc.bat lib\main.dart  -o dart_bundle.js
here is the crash:
We're sorry, you've found a bug in our compiler.
You can report this bug at:
https://github.com/dart-lang/sdk/issues/labels/web-dev-compiler
Please include the information below in your report, along with
any other information that may help us track it down. Thanks!
dartdevc arguments: --dart-sdk=C:\tools\dart-sdk lib/bloc.dart --modules es6 -o dist/dart_bundle.js
dart --version: 2.7.1 (Thu Jan 23 13:02:26 2020 +0100) on "windows_x64"
Unsupported operation: tried to generate an unreachable node: `extension ConnectableStreamExtensions<T> on Stream<T> {ConnectableStream<T> publish() => PublishConnectableStream<T>(this); ValueConnectableStream<T> publishValue() => ValueConnectableStream<T>(this); Value
nnectableStream<T> publishValueSeeded(T seedValue) => ValueConnectableStream<T>.seeded(this, seedValue); ReplayConnectableStream<T> publishReplay({int maxSize}) => ReplayConnectableStream<T>(this, maxSize: maxSize); Stream<T> share() => publish().refCount(); ValueStrea
T> shareValue() => publishValue().refCount(); ValueStream<T> shareValueSeeded(T seedValue) => publishValueSeeded(seedValue).refCount(); ReplayStream<T> shareReplay({int maxSize}) => publishReplay(maxSize: maxSize).refCount();}`
#0      CodeGenerator._unreachable (package:dev_compiler/src/analyzer/code_generator.dart:6293:5)
#1      CodeGenerator.visitExtensionDeclaration (package:dev_compiler/src/analyzer/code_generator.dart:6678:59)
#2      ExtensionDeclarationImpl.accept (package:analyzer/src/dart/ast/ast.dart:3819:49)
#3      CodeGenerator.visitCompilationUnit (package:dev_compiler/src/analyzer/code_generator.dart:564:30)
#4      List.forEach (dart:core-patch/array.dart:112:8)
#5      CodeGenerator.compile (package:dev_compiler/src/analyzer/code_generator.dart:319:22)
#6      compileWithAnalyzer (package:dev_compiler/src/analyzer/module_compiler.dart:108:33)
#7      _compile (package:dev_compiler/src/analyzer/command.dart:152:16)
#8      compile (package:dev_compiler/src/analyzer/command.dart:56:18)
#9      compile (package:dev_compiler/src/compiler/shared_command.dart:410:18)
#10     main (file:///C:/b/s/w/ir/cache/builder/sdk/pkg/dev_compiler/bin/dartdevc.dart:32:24)
#11     _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:303:32)
#12     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:174:12)

@MagicPoulp thanks for your bug report!
Sorry in advance for the long answer.
As surprising as this may sound, this is working as intended.
We did a migration in dartdevc to use a different frontend, and with the default set of flags you seem to be using the old frontend. If you pass --kernel to the command-line arguments, you may bypass this error by using the new frontend. In 2.8 the old frontend has been deleted and the new one is run by default.
That being said, we generally recommend that you don't invoke dartdevc directly on the command line. Dart ships with 2 compilers for javascript, one meant to build applications so you can ship them (dart2js) and the other (dartdevc) is meant for development behind a development server. The latter is a modular compiler that requires carefully building separate modules based on the dependencies in your app. Because of that, we recommend invoking dartdevc indirectly via build tools like [webdev][1]. The latest version of webdev knows how to invoke dartdevc to use the correct set of flags, so this issue wouldn't have been visible under that workflow.
One general benefit of using webdev with dartdevc is that it is designed to support your edit/refresh cycle: when using webdev serve, you can iterate on edits and when you refresh your app, only the modules that were modified will be recompiled.
Hope this clarifies things a bit.
[1]: https://dart.dev/tools/webdev

Thanks for the detailed answer.
I am on linux, but our build server is on windows. I installed dart-sdk with chocolatey and maybe the version was old (if you say the new kernel should be active by default).
I tried on cygwin to use a linux based dartdevc but it does not work. The file is too much for Cygwin to run. It complains about the file format, and I don't think it is carriage return related (not sure) because when it did in a powershell it mentionen the \r, but not in Cygwin. I think Cygwin is not a real linux on many aspects.
I tried webdev and also dart2js directly. dart2js does not support the option --modules es6 that I need.
So fart dartdevc seems to be able to generated working javascript. Just one minor issue. It exports window instead of $window (then why would there not be more  similar error?). I did not have "the energy" the need to create a reproducible new issue but it is a real one.
dartdevc  --modules es6 -o dart_bundle.js
Many blogs around say one can use dart-angular and reuse the code in flutter and web. I went one step further. I am using dart to generate es6 Javascript that is then used with a strongly typed interface in the vanilla Typescript Angular. I prefer the vanilla Angular.
A barrel file (to help angular compilation) imports the file generated by dart. The barrel file looks like this:

import {
InjectionToken,
} from '@angular/core';
import {
src__base_bloc as BaseBloc,
src__pages__image_gallery__image_gallery_bloc as imageGalleryObject,
// @ts-ignore
} from 'GenericFrontEndBlocAngularBundle/dart_bundle';
/*
Exporting helps the production build to find types
*/
// @Injectable is not needed because it is an alias for @Inject
// applied to the contructor's arguments
class ImageGalleryBloc extends imageGalleryObject.ImageGalleryBloc {}
interface ImageGalleryBlocIf {
currentViewStream: any;
showImagesList: any;
showImageDetails: any;
backButtonMoveToNextView: any;
}
// interfaces require an injection token as mentioned here:
// https://stackoverflow.com/questions/45570484/how-to-enforce-component-service-interface-in-angular?rq=1
const imageGalleryBlocToken = new InjectionToken('imageGalleryBlocToken');
export {
// eslint-disable-next-line no-undef
BaseBloc, ImageGalleryBloc, ImageGalleryBlocIf, imageGalleryBlocToken,
};

this worked:
choco install <IP_ADDRESS>-dev-0

If you know a place where I can document the dart generation for vanilla Angular, please tell me. I could also make a working code sample.

Thanks for sharing about your experience. That's a very unique setup you have!
I want to make sure you are aware of the risk with this setup. Since this is not what we've designed dartdevc to do, we may accidentally or purposely make breaking changes that could affect you. Our goal is to make dartdevc a good experience for fast iteration cycle during development, and we do not support using its output directly as an input to a larger JavaScript application. Just to name one example, we currently support the es6 module format, but we have plans to consolidate into a single module format. Given some constraints we have with support for hot-reload in flutter, this format is unlikely going to be es6, so there is a possibility that we may drop that as a supported format.
For these reasons, I would like to encourage you to invest now in a more stable approach that is well supported. Our recommended approach for interoperability with JavaScript is to use the package:js APIs, which you can use to explicitly expose your dependencies. That approach will enable you to use dart2js to bundle your code and combine it with other JavaScript modules if you like, since at that point you are in control of how the JavaScript we generate is embedded and exposed as a module in the context of a bigger app.

OK thanks for the good info.
Yes I will try to use dart2js and package:js.

Why does the doc says stream is a ValueStream whereas in the source code it is a Stream?
https://pub.dev/documentation/rxdart/latest/rx/BehaviorSubject-class.html
I cannot do .value on it.
~/.pub-cache/hosted/pub.dartlang.org/rxdart-0.23.1$ e lib/src/subjects/behavior_subject.dart:
class BehaviorSubject extends Subject implements ValueStream {
_Wrapper _wrapper;
BehaviorSubject._(
StreamController controller,
Stream stream,
this._wrapper,
) : super(controller, stream);

I found why. A BehaviorSubject extends ValueStream. And the stream property is a Stream. They jsut have a typo in the doc.
Concerning your comment that you may decide to support only a certain format and not es6. You should know that es6 can run faster in modern browsers than es5, and bundles become smaller.

Help with the problem below is appreciated.
with dartdevc, I could compile,
with dart2js, it first complains there is no main function defined. Even with an empty main file, it does not compile my library.
This is my file, and the library in question contains a class that is exported.
import 'package:bloc/bloc.dart';
void main() {
}

Still trying. I found a good example in the sass package.
node.dart:
/// The entrypoint for the Node.js module.
///
/// This sets up exports that can be called from JS.
void main() {
exports.render = allowInterop(_render);
exports.renderSync = allowInterop(_renderSync);
exports.info =
"dart-sass\t${const String.fromEnvironment('version')}\t(Sass Compiler)\t"
"[Dart]\n"
"dart2js\t${const String.fromEnvironment('dart-version')}\t"
"(Dart Compiler)\t[Dart]";

If I have to use dart version 1 for the package js, I think I should stick to dartdevc and freeze my version of dart-sdk 2.8.

I could compile something but the output has 2 problems.
first it does not fetch the content of the class ImageGalleryBloc.
second, it makes a global function that will contain everything, it does not just generates code that can be imported by a larged JS application.
here is the code. If you compile the code below, the function showImagesList and the exporession HERE cannot be found in the generated code.
import 'dart:async';
import 'dart:convert';
import 'dart:js_util';
import 'dart:typed_data';
import 'package:js/js.dart';
class ImageGalleryBloc {
void showImagesList() {
print("HERE");
}
}
@JS()
class Exports {
external set ImageGalleryBloc(Type imageGalleryBloc);
}
@JS()
external Exports get exports;
void main() {
exports.ImageGalleryBloc = allowInterop(ImageGalleryBloc);
}


POM-367 Add Azure Application Insights integration

Added Azure Application Insights integration.
POM-367

@luziczek linter is failing, can you fix?

We are using prettier so please also run it locally so that all files are formatted properly; that's why it's failing.

@luziczek Paweł wrote to me that ideally we'd define the field applicationInsightsConnectionString in the prod environment file with a value that's a very obvious placeholder to replace, maybe something like %BACKEND_REPLACED_APPLICATION_INSIGHTS_CONNECTION_STRING%.


Cannot copy symlinks.

I'm on 4.0.0.
Using the simply gulp.src('foo/**/*').pipe(gulp.dest(bin')) approach to copying files doesn't work with symlinks - it turns them into executable regular files.
According to #1427, this was fixed upstream in vinyl-fs but this doesn't seem to be the case. Symlinks still aren't copied correctly at all.
This makes it impossible to package Electron with Gulp. Is there a workaround?

Nevermind. It was an issue with gulp-decompress. gulp-unzip doesn't work either, and gulp-run-command doesn't work with gulp@4 and I've already migrated. At this point, I'm just going to use a dockerfile because I'm tired of battling with it.


migrate all subclasses of DailyIndexDocType to the implementation in new_models.

will need to address the handling of raw fields as well as determine how best (if at all) to present aggregations of search data.  It may be easier to convert the existing implementations (EventData, MetricData, etc.) to subclasses of SavedSearch.

@lexjacobs here are three variants of response to the updated spawns API call:
No spawns ever:
{"count":0,"next":null,"previous":null,"results":[]}
No spawns in window:
{"count":0,"next":null,"previous":null,"results":[],"aggregations":{"per_interval":{"buckets":[]}}}
A successful spawn (no failures).  Note that if there are no failures/successes in the a bucket, that field will not be present:
{"count":1,"next":null,"previous":null,"results":[{"_score":1.9162908,"_type":"nova_spawns","_id":"AVLCFtUMTT9wXzuqbiIw","_source":{"success":"true","syslog5424_host":"rdo-kilo","@timestamp":"2016-02-06T00:18:05.702Z","event":"finish","host":"rdo-kilo","@version":"1","received_at":"2016-02-08T18:13:41.796Z","type":"nova_spawns","port":34792},"_index":"goldstone-2016.02.06"}],"aggregations":{"per_interval":{"buckets":[{"success":{"buckets":[{"key":"true","doc_count":1}],"sum_other_doc_count":0,"doc_count_error_upper_bound":0},"key_as_string":"2016-02-06T00:18:00.000Z","key":1454717880000,"doc_count":1}]}}}

@jxstanford can you please provide an example of the structure of a return call that includes a failure?

I managed to coerce some failures as shown by nova list by simultaneously spawning some --flavor m1.xlarge instances, but...

... the call to /nova/hypervisor/spawns/ still shows 4 successes, 0 failures.
{
  "count": 4,
  "next": "http://localhost:8000/nova/hypervisor/spawns/?%40timestamp__range=%7B%22gte%22%3A1455039547748%2C%22lte%22%3A1455043147748%7D&interval=2.5m&page=2&page_size=1",
  "previous": null,
  "results": [
    {
      "_score": 4.7695713,
      "_type": "nova_spawns",
      "_id": "AVLHShDGg_1kSX18mQsd",
      "_source": {
        "success": "true",
        "syslog5424_host": "rdo-kilo",
        "@timestamp": "2016-02-09T18:27:44.018Z",
        "event": "finish",
        "host": "rdo-kilo",
        "@version": "1",
        "received_at": "2016-02-09T18:27:45.296Z",
        "type": "nova_spawns",
        "port": 50029
      },
      "_index": "goldstone-2016.02.09"
    }
  ],
  "aggregations": {
    "per_interval": {
      "buckets": [
        {
          "success": {
            "buckets": [],
            "sum_other_doc_count": 0,
            "doc_count_error_upper_bound": 0
          },
          "key_as_string": "2016-02-09T17:37:30.000Z",
          "key":<PHONE_NUMBER>000,
          "doc_count": 0
        },

     [ ... ]
        {
          "success": {
            "buckets": [],
            "sum_other_doc_count": 0,
            "doc_count_error_upper_bound": 0
          },
          "key_as_string": "2016-02-09T18:30:00.000Z",
          "key":<PHONE_NUMBER>000,
          "doc_count": 0
        },
        {
          "success": {
            "buckets": [
              {
                "key": "true",
                "doc_count": 2
              }
            ],
            "sum_other_doc_count": 0,
            "doc_count_error_upper_bound": 0
          },
          "key_as_string": "2016-02-09T18:32:30.000Z",
          "key":<PHONE_NUMBER>000,
          "doc_count": 2
        },
        {
          "success": {
            "buckets": [
              {
                "key": "true",
                "doc_count": 1
              }
            ],
            "sum_other_doc_count": 0,
            "doc_count_error_upper_bound": 0
          },
          "key_as_string": "2016-02-09T18:35:00.000Z",
          "key":<PHONE_NUMBER>000,
          "doc_count": 1
        }
      ]
    }
  }
}


Using Slick in Angular 2 SPA

Not sure if anyone has used the slider in an ng2 app yet but Im noticing that it works fine when you visit the page first but then on any subsequent visits the slider go a lot faster than they should

Have you found out how to do it? I am also stuck with it. Any help shall be highly appreciated.

Yeah I couldnt get it to work with slick but I used Owl Carousel and it works pretty good.

@REPTILEHAUS lol thanks! Looks fine :)


⚠ Bofrost.at has degraded performance

In cdf9126, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1360 ms

Resolved: Bofrost.at performance has improved in e5c14bc after 8 minutes.


Mimirsbrunn repository has gone missing?

The README in this repository references https://github.com/CanalTP/mimirsbrunn multiple times but that link now leads to a 404 page. I think previously that link redirected to https://github.com/hove-io/mimirsbrunn but that's also a 404 now.

Hi, it seems that Hove has closed source this repository few days ago. you can still follow our repository at https://github.com/Qwant/mimirsbrunn


fix: Upgrade dart dependencies to match latest language API

Codecov Report
Patch coverage has no change and project coverage change: -50.60 :warning:

Comparison is base (b24f87f) 74.65% compared to head (b9c0a61) 24.05%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##             main     #583       +/-   ##
===========================================
- Coverage   74.65%   24.05%   -50.60%
===========================================
  Files          22       14        -8
  Lines         722     2307     +1585
===========================================
+ Hits          539      555       +16
- Misses        183     1752     +1569

Impacted Files
Coverage Δ

python/trinsicokapi/didcomm.py

python/tests/okapi_demo.py

python/trinsicokapi/oberon.py

python/trinsicokapi/wrapper.py

python/trinsicokapi/__main__.py

...thon/trinsicokapi/proto/okapi/metadata/__init__.py

python/trinsicokapi/hashing.py

python/tests/test_oberon.py

python/trinsicokapi/didkey.py

python/trinsicokapi/metadata.py

... and 26 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fab revisions

Remove categories from the FAB and create a dedicated activity to select the category to choose goals from. The FAB contains three options now, Choose goals, Create goal (which is not implemented yet), and Choose interests.

looks good :+1:


Removes mandrill

Removes Mandrill from app due to EOL for their Heroku add-on.
@patbenatar

:shipit: !


Consider making sbt less verbose

Current sbt is extremely verbose. Messages could be improved to be:

More concrete. Straight to the point.
Shorter. This also includes removing unnecessary messages.
Grouped by topic (perhaps with progress bars).

I'm going to illustrate my points with examples.
Very short extract of publishLocal in sbt/sbt:

[info] will publish locally with javac version 1.8.0_92
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#test-agent;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:11 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/testing/agent/target/ivy-0.13.14-SNAPSHOT.xml
[info] :: delivering :: org.scala-sbt#collections;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:11 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/collection/target/ivy-0.13.14-SNAPSHOT.xml
[warn] bootstrap class path not set in conjunction with -source 1.6
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#cross;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:12 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/cross/target/ivy-0.13.14-SNAPSHOT.xml
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#sbt-launch;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:12 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/launch/target/ivy-0.13.14-SNAPSHOT.xml
[info] Packaging /data/rw/code/scala/sbt/util/collection/target/collections-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#control;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:12 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/control/target/ivy-0.13.14-SNAPSHOT.xml
[info] Packaging /data/rw/code/scala/sbt/util/cross/target/cross-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#process;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:12 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/process/target/ivy-0.13.14-SNAPSHOT.xml
[info] 	published collections to /home/jvican/.ivy2/local/org.scala-sbt/collections/0.13.14-SNAPSHOT/jars/collections.jar
[info] 	published collections to /home/jvican/.ivy2/local/org.scala-sbt/collections/0.13.14-SNAPSHOT/srcs/collections-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/collections/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] 	published cross to /home/jvican/.ivy2/local/org.scala-sbt/cross/0.13.14-SNAPSHOT/jars/cross.jar
[info] 	published cross to /home/jvican/.ivy2/local/org.scala-sbt/cross/0.13.14-SNAPSHOT/srcs/cross-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/cross/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] Packaging /data/rw/code/scala/sbt/util/control/target/control-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] 	published sbt-launch to /home/jvican/.ivy2/local/org.scala-sbt/sbt-launch/0.13.14-SNAPSHOT/jars/sbt-launch.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/sbt-launch/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] Packaging /data/rw/code/scala/sbt/util/process/target/process-0.13.14-SNAPSHOT.jar ...
[info] will publish locally with javac version 1.8.0_92
[info] Done packaging.
[info] :: delivering :: org.scala-sbt#apply-macro;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/appmacro/target/ivy-0.13.14-SNAPSHOT.xml
[info] 	published control to /home/jvican/.ivy2/local/org.scala-sbt/control/0.13.14-SNAPSHOT/jars/control.jar
[info] 	published control to /home/jvican/.ivy2/local/org.scala-sbt/control/0.13.14-SNAPSHOT/srcs/control-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/control/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] 	published process to /home/jvican/.ivy2/local/org.scala-sbt/process/0.13.14-SNAPSHOT/jars/process.jar
[info] 	published process to /home/jvican/.ivy2/local/org.scala-sbt/process/0.13.14-SNAPSHOT/srcs/process-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/process/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] Packaging /data/rw/code/scala/sbt/util/appmacro/target/apply-macro-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#io;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/io/target/ivy-0.13.14-SNAPSHOT.xml
[info] will publish locally with javac version 1.8.0_92
[info] 	published apply-macro to /home/jvican/.ivy2/local/org.scala-sbt/apply-macro/0.13.14-SNAPSHOT/jars/apply-macro.jar
[info] 	published apply-macro to /home/jvican/.ivy2/local/org.scala-sbt/apply-macro/0.13.14-SNAPSHOT/srcs/apply-macro-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/apply-macro/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] :: delivering :: org.scala-sbt#tasks;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/tasks/target/ivy-0.13.14-SNAPSHOT.xml
[info] Packaging /data/rw/code/scala/sbt/tasks/target/tasks-0.13.14-SNAPSHOT.jar ...
[info] Packaging /data/rw/code/scala/sbt/util/io/target/io-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] Packaging /data/rw/code/scala/sbt/testing/agent/target/test-agent-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] Done packaging.
[info] Compiling 4 Scala sources to /data/rw/code/scala/sbt/cache/target/classes...
[info] 	published tasks to /home/jvican/.ivy2/local/org.scala-sbt/tasks/0.13.14-SNAPSHOT/jars/tasks.jar
[info] 	published tasks to /home/jvican/.ivy2/local/org.scala-sbt/tasks/0.13.14-SNAPSHOT/srcs/tasks-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/tasks/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] Compiling 2 Scala sources to /data/rw/code/scala/sbt/util/complete/target/classes...
[info] 	published test-agent to /home/jvican/.ivy2/local/org.scala-sbt/test-agent/0.13.14-SNAPSHOT/jars/test-agent.jar
[info] 	published test-agent to /home/jvican/.ivy2/local/org.scala-sbt/test-agent/0.13.14-SNAPSHOT/srcs/test-agent-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/test-agent/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] will publish locally with javac version 1.8.0_92
[info] will publish locally with javac version 1.8.0_92
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#datatype-generator;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/datatype/target/ivy-0.13.14-SNAPSHOT.xml
[info] :: delivering :: org.scala-sbt#completion;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/util/complete/target/ivy-0.13.14-SNAPSHOT.xml
[info] :: delivering :: org.scala-sbt#cache;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/cache/target/ivy-0.13.14-SNAPSHOT.xml
[info] will publish locally with javac version 1.8.0_92
[info] 	published io to /home/jvican/.ivy2/local/org.scala-sbt/io/0.13.14-SNAPSHOT/jars/io.jar
[info] 	published io to /home/jvican/.ivy2/local/org.scala-sbt/io/0.13.14-SNAPSHOT/srcs/io-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/io/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] :: delivering :: org.scala-sbt#scripted-framework;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:13 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/scripted/base/target/ivy-0.13.14-SNAPSHOT.xml
[info] Packaging /data/rw/code/scala/sbt/scripted/base/target/scripted-framework-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] Packaging /data/rw/code/scala/sbt/util/datatype/target/datatype-generator-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] 	published scripted-framework to /home/jvican/.ivy2/local/org.scala-sbt/scripted-framework/0.13.14-SNAPSHOT/jars/scripted-framework.jar
[info] 	published scripted-framework to /home/jvican/.ivy2/local/org.scala-sbt/scripted-framework/0.13.14-SNAPSHOT/srcs/scripted-framework-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/scripted-framework/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] 	published datatype-generator to /home/jvican/.ivy2/local/org.scala-sbt/datatype-generator/0.13.14-SNAPSHOT/jars/datatype-generator.jar
[info] 	published datatype-generator to /home/jvican/.ivy2/local/org.scala-sbt/datatype-generator/0.13.14-SNAPSHOT/srcs/datatype-generator-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/datatype-generator/0.13.14-SNAPSHOT/ivys/ivy.xml
[info] will publish locally with javac version 1.8.0_92
[info] :: delivering :: org.scala-sbt#interface;0.13.14-SNAPSHOT :: 0.13.14-SNAPSHOT :: integration :: Mon Mar 06 15:03:14 CET 2017
[info] 	delivering ivy file to /data/rw/code/scala/sbt/interface/target/ivy-0.13.14-SNAPSHOT.xml
[info] Writing version information to /data/rw/code/scala/sbt/interface/target/resource_managed/xsbt.version.properties :
[info] version=0.13.14-SNAPSHOT
[info] timestamp=20170306T140314
[info] Packaging /data/rw/code/scala/sbt/interface/target/interface-0.13.14-SNAPSHOT.jar ...
[info] Done packaging.
[info] 	published interface to /home/jvican/.ivy2/local/org.scala-sbt/interface/0.13.14-SNAPSHOT/jars/interface.jar
[info] 	published interface to /home/jvican/.ivy2/local/org.scala-sbt/interface/0.13.14-SNAPSHOT/srcs/interface-sources.jar
[info] 	published ivy to /home/jvican/.ivy2/local/org.scala-sbt/interface/0.13.14-SNAPSHOT/ivys/ivy.xml

To me, those error messages look unhygienic and clutter my screen. I cannot focus on what sbt does.
What I'd like is:

Remove deduplicated error messages (see how many times "using javac version" appears).
Make messages more concise. Most of the error messages in that report are unnecessary. Why do I care where a xml file is published? And whether sbt writes or not the version to a file? Most of the times I don't. If I want that information, I'd like to pass in a verbose flag that does it.

We see these messages bazillion of times a day. It's time that we optimize them for the most common use cases and unclutter our workspaces.
Proposed error message for publish*:
[info] Using javac version 1.8.0_92.
[info] Packaging sbt-util.control-0.13.14-SNAPSHOT.jar ...
[success] Packaged artifacts can be found in  /data/rw/code/scala/sbt/util/control/target/.
[success] Published sbt-util to /home/jvican/.ivy2/local/org.scala-sbt/sbt-util/0.13.14-SNAPSHOT/.

Ah, the "it's all spam" vs "I've no idea what it's doing" endless debate..
Personally I've become numb to verbosity, but I would welcome changes that lowered their visibility (e.g they would only be visible in last).
I don't think we should outright remove the messages, or at least not without a strong argument as to why.
:+1:

but I would welcome changes that lowered their visibility (e.g they would only be visible in last).

Yes, I agree they should not be thrown away. I'd like to pass in a verbose flag, as I said in the previous message, or yust make them visible to last. I think this change will be very welcome from the community. After discussing with several people, I'm not the only one that thinks sbt should be less verbose.

Another thing I'd like to propose to current maintainers: drop logs like "Done X". I think that it should be implicit the fact that a task has finished when another task starts. Example:
Updating blabla.
Done updating.
Compiling $blabla.
Done compiling.

We should just remove the "Done" sentences since they don't bring anything to the table and make sbt output larger than it should, IMO.

I think the approach in #3122 is good, demote the severity of some verbose statements from info to debug. That's less radical than dropping logs.

We should just remove the "Done" sentences since they don't bring anything to the table and make sbt output larger than it should, IMO.

Totally agree. @olafurpg Yes, I like the direction of that PR.

I think that it should be implicit the fact that a task has finished when another task starts

tasks run in parallel

@SethTisue not necessarily, tasks can be run in sequential. It depends on your build graph.


Quiz says none of the options are correct

The quiz given after the first section in the Chapter 13 "Handling Errors" says none of the options is right
The browser I am using is Firefox on Ubuntu, but I was able to reproduce this on a mobile phone as well
Screencast from 2023-10-26 22-27-29.webm
I think the right answer should be not-found.tsx.
Edit: Couldn't really find the tutorial repo, so sorry if this bug was something you guys were already tracking internally...just came across it so reported it😅

Thank you for filing! 🙏 We have a fix on the way

Good to know :)