Record error rate at build time

Due to rounding, a feature may not have exactly the same number of points as its population. Irregular shapes with high population counts are especially error-prone.
It would be good to report this at build time, so I know exactly how far off a count is.

Maybe we could write errors to a separate stream, using an output writer. That would preserve errors without interrupting the build.

The error happens here: https://github.com/eyeseast/dorchester/blob/main/dorchester/dotdensity.py#L65-L79
We do know, in that function, how far off we are, so that's the place to record it.

There's probably no good reason for either point_in_shape or point_in_feature to be generators. My habit of relying on yield to build streams might actually be getting me in trouble here.

I have errors being returned in a structured way, so that's a start. Tests now check that we get the expected number of points, subtracting out errors (or adding, if we undershoot).
For recording, I think I'm going to basically do a parallel write.
For files at least, if I have a destination like points.csv, errors will (by default) go to points.errors.csv. Same for GeoJSON. (I'll have to think through what this means for other formats, but kick that down the road for now.)
I'm going to add methods to write errors onto the output classes. That keeps everything explicit, and one writer can handle both points and errors.

This is turning into a bigger refactor, but probably for the best. Plotting should now look something like this:
with CSVWriter(path) as writer:
    for points, errors in dotdensity.generate_points(source, "population"):
        writer.write_all(points)
        writer.write_all_errors(errors)

Might end up moving all of that to the CLI, since that's where I want to be using it anyway, and leaving the Python API for generating stuff.


Compatible with file paths containing single quotes

If file paths containing single quotes, cmd of the menu items which recent-menu sends to dyn_menu.lua will be like this, but it doesn't work.
loadfile 'D:\[LPSub&LP-Raws] BanG Dream! It's MyGO!!!!! [BD 01-13 Fin][AVC AAC][1080p][JPTC]\[LPSub] BanG Dream! It's MyGO!!!!! [BDRip][01][1080p][AVC AAC][JPTC].mp4'
According to mpv.io, argument witch single quotes or double quotes must be in style of `X <custom_quoted> X`.

Try this https://github.com/natural-harmonia-gropius/recent-menu/pull/30

Didn't work. Here are logs:
[input] Broken string escapes: ...>"D:\[LPSub&LP-Raws] BanG Dream! It's MyGO!!!!! [BD 01-13 Fin][AVC AAC][1080p][JPTC]\[LPSub] BanG Dream! It's MyGO!!!!! [BDRip][01][1080p][AVC AAC][JPTC].mp4"<.

[input] Command loadfile: error in argument 1.

[input] Command was defined at menu.

PR updated, try again.

Work Properly.


Add uglifyjs dependency..

.. so that npm run min doesn't fail if you don't have it globally

Ah, great! :+1: I guess I installed it using apt-get. :grin:


⚠ ClamAV has degraded performance

In 41f0e8e, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 217 ms

Resolved: ClamAV performance has improved in d4a96ed.


ja: Make docs/concepts/extend-kubernetes/operator.md follow v1.19 of the original text

This is a Feature Request

What would you like to be added
Update docs/concepts/extend-kubernetes/operator.md to follow v1.19 of the original (English) text.
Why is this needed
content/ja/docs/concepts/extend-kubernetes/operator.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/tree/dev-1.19-ja.1/content/ja/docs/concepts/extend-kubernetes/operator.md
Original
https://github.com/kubernetes/website/tree/release-1.19/content/en/docs/concepts/extend-kubernetes/operator.md
diff between translated and v1.19
https://gist.github.com/76a16bf9a8473c46b7192e8737d430fe
Note
Currently, we use dev-1.19-ja.1 branch. Please open a PR targeting the branch.
ref
https://kubernetes.io/ja/docs/contribute/localization/
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel.

/triage accepted

/assign

/close


Increasing power_mng.soc_min and power_mng.soc_charge at the same time?

By default, the inverter has set a value of 0.07 (7%) for power_mng.soc_min and a value of 0.05 (5%) for power_mng.soc_charge.
When power_mng.soc_min is reached, the battery discharges through self-consumption (?) until power_mng.soc_charge is reached. The inverter then charges with the power of power_mng.soc_charge_power from the grid until power_mng.soc_min is reached.
Should the value power_mng.soc_charge also be adjusted for the “emergency power reserve” scenario so that there is really enough reserve?

https://github.com/do-gooder/rctpower_writesupport/commit/a7d97751fa2c77d80e91dd59417cc10056ef1a4d

Hi do-gooder,
I can confirm this behavior: 5% is the default low SOC threshold to start forced charging from grid until soc_min is reached again.
I guess this a meaningful reserve to prevent deep discharge for the battery to increase battery's lifetime.
In the docs of rctclient, it is called  "SOC min maintenance charge".
Your idea to set ich 2% below soc_min sounds good, but also let it stay on 5% as per default seems also okay, because self-drain will practically not be reached, if soc_min is set significantly higher than 7%!


Calibration canvas refactor

Cleaned up the calibration canvas

There's a lot still to be done, but I'd love to hear opinions on this one before I go much further.
TODO:

Press and hold arrow key will continue to move corners
Clean up code to remove duplication of logic from hooks and share progressive increase
Make it draggable? Maybe with a move icon to show it can be dragged. Not sure about this one. It feels really nice where it is on a tablet.
Maybe add the toggling button to the right side like the layers menu?
Save visibility of pad in localStorage
Maybe name change? Not sure about movement pad.

I just took a peek at the calibration canvas. Wow, a lot has changed! I see the grid is now white on black, the corners no longer have color - not sure when any of that happened 😅
(The colors on the corners were intended to help people figure out which corners matched on their projected space, in the case that their screen was flipped from their computer screen. Not sure if it actually helped or not, but that was the original purpose)
Here are my comments on the above:

Can we detect a touchscreen? I remember this being dubious from my research, but I think we will want to only show the buttons on touchscreens (I'm assuming you are leaving them on desktop for now for testing purposes, but just wanted to make this note)
I think that holding down the button should behave exactly like holding down the mouse. Having to tap a million times to line up the corners is going to be annoying if the touchscreen user has to go long distances. Maybe this is what your third point is referring to?
As far as dragging, it's going to be tough to communicate that one, especially since all the functions are already touch handlers. My opinion: let's leave it be for now and see if anyone complains!
I think the toggle button is potentially a better option, but I'll say same thing: let's start without it and see if anyone complains!
Movement pad makes sense to me, other alternatives might be: touchscreen movement, movement buttons. I don't really know. I am terrible at naming things!

I just took a peek at the calibration canvas. Wow, a lot has changed! I see the grid is now white on black, the corners no longer have color - not sure when any of that happened 😅

The grid inversion on light mode was because of #126. I had a few people complain. Fix happened on #138 :)

(The colors on the corners were intended to help people figure out which corners matched on their projected space, in the case that their screen was flipped from their computer screen. Not sure if it actually helped or not, but that was the original purpose)

I took these out because it's not easy to see the difference in colours on my projector. I was originally planning on replacing them with some symbol to mark each corner as unique but then realized that the dimension labels are probably enough to orient someone with a weird setup. The dimension labels are nice because text has an orientation so you know where the corner is. What do you think?

Here are my comments on the above:

Can we detect a touchscreen? I remember this being dubious from my research, but I think we will want to only show the buttons on touchscreens (I'm assuming you are leaving them on desktop for now for testing purposes, but just wanted to make this note)

At first I was going to try to detect this but the more I think about it the more I like leaving it there for all cases and someone can simply toggle it off once if they don't want to use it. Two main reasons: someone using their mouse on their cutting mat without having to reference their device and someone who doesn't know about the arrow key movement. What do you think?

I think that holding down the button should behave exactly like holding down the mouse. Having to tap a million times to line up the corners is going to be annoying if the touchscreen user has to go long distances. Maybe this is what your second point is referring to? EDIT: Wow, I can't read. That is exactly what your first point says 😅 in short, yes I agree!

Lol, great! It's going to take me a minute to refactor the two and set up the intervals. React really boggles my mind on things like this.

As far as dragging, it's going to be tough to communicate that one, especially since all the functions are already touch handlers. My opinion: let's leave it be for now and see if anyone complains!

I'm happy with that!

I think the toggle button is potentially a better option, but I'll say same thing: let's start without it and see if anyone complains!

There is a toggle button in the menu bar. Do you think I should remove that for now?

Movement pad makes sense to me, other alternatives might be: touchscreen movement, movement buttons. I don't really know. I am terrible at naming things!

How about move tool?

=== EDIT
Another note:
Maybe this icon for the center button, possibly rotated?
https://fonts.google.com/icons?selected=Material Symbols Outlined%3Arefresh%3AFILL%400%3Bwght%40400%3BGRAD%400%3Bopsz%4024
Or maybe this one?
https://fonts.google.com/icons?selected=Material Symbols Outlined%3Arefresh%3AFILL%400%3Bwght%40400%3BGRAD%400%3Bopsz%4024
I thought the center button was going to center the canvas 😅 just an idea, might not be that important.

I'm seeing the same refresh icon for both those links but I like that!

I took these out because it's not easy to see the difference in colours on my projector. I was originally planning on replacing them with some symbol to mark each corner as unique but then realized that the dimension labels are probably enough to orient someone with a weird setup. The dimension labels are nice because text has an orientation so you know where the corner is. What do you think?

Ooh, that's a good point. I hadn't considered the new text - that will probably fix it!

At first I was going to try to detect this but the more I think about it the more I like leaving it there for all cases and someone can simply toggle it off once if they don't want to use it.

Maybe default on for touchscreen and default off for desktop? I was really annoyed by it being there when I first opened up the page. It felt like unnecessary screen usage (but admittedly, I'm on a desktop with a mouse right now).

Two main reasons: someone using their mouse on their cutting mat without having to reference their device

I don't understand the use case here. Are you saying they would rather use the mouse to click on the buttons than the mouse to click on the corners? I guess MAYBE I could see that. I am still a little skeptical that we should use up screen space (by default) for it.

and someone who doesn't know about the arrow key movement. What do you think?

I'm also a little skeptical on this. I don't think we should justify using screen space to lower the learning curve even further than it already is. I think the vast majority of people "get it" without too much trouble. My personal opinion!

There is a toggle button in the menu bar. Do you think I should remove that for now?

If there's already a button, then say no more! Let's just leave it in there!
I did notice on some of Sasha's help posts that her screen is cutting off several of the buttons. That also can be fixed by menu management, though. I wish I had more time to work on this right now! I would love to tackle menu management.
This was the alternate icon. Sorry about that!
https://fonts.google.com/icons?selected=Material Symbols Outlined%3Acycle%3AFILL%400%3Bwght%40400%3BGRAD%400%3Bopsz%4024

I think you're right! The majority of people have keyboard setups where the nicest way to calibrate is with the arrow keys and tab. I'll see if I can reliably determine if people are using touch screens and conditionally show. If not, I'll hide it by default. I may move the toggling button in with the movement pad so it's more obvious how to toggle it.

Lol, great! It's going to take me a minute to refactor the two and set up the intervals. React really boggles my mind on things like this.

I also wanted to throw in a bit of a tidbit here - with the existing hooks, you should be able to abstract out the event type and pass it in as an argument ("onmousedown", "ontouchtap" <= or whatever the touch event is) then reuse the logic completely! You shouldn't have to do too much here (at least I believe this is the case!)

I think it's a bit more complicated because onClick and onPointerDown events don't repeatedly fire on hold like onKeyDown so I believe I need to create my own interval timer to fire until onPointerUp. Ideally with the same speed as the onKeyDown repeat to have the same feel as the arrow key movement. Please correct me if I'm wrong!

I think it's a bit more complicated because onClick and onPointerDown events don't repeatedly fire on hold like onKeyDown so I believe I need to create my own interval timer to fire until onPointerUp. Ideally with the same speed as the onKeyDown repeat to have the same feel as the arrow key movement. Please correct me if I'm wrong!

Oh darn it. That's right. I ran into the same thing with the "hide after 3 seconds" logic we were trying to implement. I started experiencing performance lag, unfortunately, even using recommended React methods for debouncing. I should get my branch up there so you can take a look at it - the code will be similar. But, as I said, it currently suffers from drawing/performance issues (which jhuff also ran into).
In fact, I'm a little worried that we are going to start running into performance bottlenecks in general. The issue where on hover text stops working after awhile smells strongly of performance/memory limitations.

...ok, now I'm thinking about it a bit...
Wouldn't you use onmousedown/onmouseup? It also appears there is onTouchStart and onTouchEnd. I think those might solve your debouncing problem...

...ok, now I'm thinking about it a bit...
Wouldn't you use onmousedown/onmouseup? It also appears there is onTouchStart and onTouchEnd. I think those might solve your debouncing problem...

That's my plan! onPointerDown -> onPointerUp. I started working on it but ran into the problem described here. I'm planning on using a reducer for the points to solve the problem. We'll see how that goes!
I got a React book yesterday to learn a bit more about fixing some of these performance issues and using better design patterns. Hopefully it helps!

I believe I added all the features discussed. I used a slightly different pixel list for the progressive increase on the movement because it felt too fast when I tested it out on a tablet. Probably because it fires less frequently than with the keyDown. Please let me know if you think I should change those numbers! If you think it looks ok, I'm happy enough with merging this one into beta.

I accidentally added the fix for #170 on this branch. Since I'd like to get that one out there and am too lazy to switch it to beta, I'm just going to merge this PR into beta. If you notice any issues with this one, I'll just fix them directly on beta! Sorry for the clumsiness!


[Bug]: plugin fails to be loaded

Issue validation

[X] I checked the issue to prevent duplicate
[X] I checked my configurations files and the documentation
[X] My issue concern doesn't concern the Mkdocs template

Command used
Test the connection to the configured repository
Plugin version
6.11.1
Describe the bug
I hope this message finds you well. I am writing to report an issue I encountered while attempting to install the plugin. After installing the plugin, the commands and options associated with it do not load. Consequently, when following the installation instructions provided at , I am unable to proceed with Step 5, which involves configuring the plugin's options by setting the repository name, GitHub username, GitHub token, and branch name.
To provide further context, none of the eight commands listed below appear in the command palette:
Upload single current active note
Upload all notes
Upload unpublished notes
Refresh published and upload new notes
Refresh all published notes
Purge depublished and deleted files
Test the connection to the configured repository
Check the rate limit of the GitHub API
I am using Obsidian version 1.4.16.
Thank you for your attention to this matter, and I appreciate any assistance you can provide in resolving this issue.
How to reproduce ?
In Obsidian version 1.4.16:
Open new vault
Turn on community plugins
Search for Github Publisher
Install and enable
Minimal Reproducible Example
plugin fails to be loaded

Configuration
plugin fails to be loaded

Relevant log output
[GITHUB PUBLISHER] v.6.11.1 (lang: en) loaded
VM214 plugin:obsidia…mkdocs-publisher:19 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'plugin')
    at H (plugin:obsidian-mkdo…-publisher:19:67205)
    at Cr.eval (plugin:obsidian-mkdo…publisher:36:104630)
    at Generator.next (<anonymous>)
    at r (plugin:obsidian-mkdocs-publisher:2:729)
VM214 plugin:obsidia…mkdocs-publisher:36 [Github Publisher] unloaded

OS
Windows
Anything else?
No response
Obsidian information
SYSTEM INFO:
	Obsidian version: v1.4.16
	Installer version: v1.4.16
	Operating system: Windows 10 Enterprise 10.0.19045
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 2
	Plugins enabled: 2
		1: Webpage HTML Export v1.7.3
		2: Github Publisher v6.11.1

RECOMMENDATIONS:
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Strange, I would think that my last fix fixed the issue. Will working on it ASAP.


pki: add fuzzer

Signed-off-by: AdamKorcz<EMAIL_ADDRESS>
Summary

Adds a fuzzer that tests the public key APIs and the signature APIs.
With the public key APIs it:

Creates a public key
Gets the canonical value
Creates another public key with the canonical value

With the signature APIs it:

Creates a signature
Gets the canonical value
Creates another signature with the canonical value
Verifies some test data.

Release Note

Documentation

Codecov Report

Merging #1256 (345e656) into main (042ae08) will decrease coverage by 21.10%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main    #1256       +/-   ##
===========================================
- Coverage   63.19%   42.08%   -21.11%
===========================================
  Files          82       74        -8
  Lines        7670     7225      -445
===========================================
- Hits         4847     3041     -1806
- Misses       2210     3876     +1666
+ Partials      613      308      -305

Flag
Coverage Δ

e2etests
?

unittests
42.08% <ø> (+0.04%)
:arrow_up:

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

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


AMBARI-25965: Upgrade service version to Bigtop 3.3.0

What changes were proposed in this pull request?
Add bigtop stack 3.3.0 files
How was this patch tested?
(Please explain how this patch was tested. Ex: unit tests, manual tests)
(If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)
Please review Ambari Contributing Guide before opening a pull request.

Stack and Versions

skimmed through changes and verified individual service versions, looks good so far, will take another look. thank you @smallyao!
IIUC we are expecting bigtop 3.3.0 for ambari 2.8.0 release, correct?

Hi @virajjasani
Since 2.8.0 has launched  a release vote， i would like to propose supporting  bigtop 3.3.0 in ambari 2.9.0.
What do you think about it?

i would like to propose supporting bigtop 3.3.0 in ambari 2.9.0.

sounds good, the changes also look good for this PR

i would like to propose supporting bigtop 3.3.0 in ambari 2.9.0.

sounds good, the changes also look good for this PR
Thanks @virajjasani


#MiWiFiPasswords showing Empty Passwords (Not showing passwords)

MiWiFiPasswords is showing empty fields after completing the hacks...

MiWiFiPasswords is showing empty fields after completing the hacks...

This occurs when you run the system on a system that requires administrative privileges to get into certain areas of the System core operations.
Solution >> Manually right click the MiWiFiPasswords either v2 or v1, and then Tap/click Run as Administrator
I am sure this should get rid of your problem/>


Build failed on adding the dependency to the commonMain.dependencies

On adding the dependency to the
commonMain.dependencies {
            implementation("com.stevdza-san:app-rating:1.0.0")
}

got the below error
Could not resolve com.stevdza-san:app-rating:1.0.0 for :composeApp:desktopMain
Could not resolve com.stevdza-san:app-rating:1.0.0 for :composeApp:desktopTest

Added a PR to support the desktop URL - https://github.com/stevdza-san/AppRating-KMP/pull/2


'encoder_activation' parameter listed in LSTM model documentation is not included in LSTM initialization

Describe the bug

'encoder_activation' parameter listed in LSTM model documentation is not included in LSTM initialization.
'activation' and 'shared_weights' parameters listed in TFT model documentation are not included in TFT initialization

Model training fails when these parameters are included.
To Reproduce
Steps to reproduce the behavior:

Run the example code below
See error (ex: Trainer.init() got an unexpected keyword argument 'shared_weights')

Expected behavior
Parameters are recognized and model training is successful.
Desktop (please complete the following information):

OS: Springdale Open Enterprise Linux (--> based on Red Hat Enterprise Linux)
Browser: N/A
Version: 8.7 Moderna]

Code Example
import torch
import pandas as pd
from datasetsforecast.long_horizon import LongHorizon

from ray import tune
from ray.tune.search.hyperopt import HyperOptSearch

from neuralforecast.auto import AutoLSTM, AutoTFT
from neuralforecast.core import NeuralForecast
from neuralforecast.losses.pytorch import MAE

import logging
logging.getLogger("pytorch_lightning").setLevel(logging.WARNING)

def main():
    Y_df = pd.read_csv('/home/scratch/wpotosna/longhorizon/datasets/ili/M/df_y.csv')
    Y_df['ds'] = pd.to_datetime(Y_df['ds'])

    n_time = len(Y_df.ds.unique())
    val_size = int(.2 * n_time)
    test_size = int(.2 * n_time)
    horizon = 96

    lstm_config = {
       "learning_rate": tune.choice([1e-3]),
       "max_steps": tune.choice([4]),
       "val_check_steps": tune.choice([2]),
       "input_size": tune.choice([2 * horizon]),
       "encoder_activation": tune.choice(['tanh']),
       "encoder_n_layers":tune.choice([2]),
       "encoder_hidden_size":tune.choice([128]),
       "context_size":tune.choice([10]),
       "decoder_hidden_size":tune.choice([128]),
       "decoder_layers":tune.choice([2]),
       "random_seed": tune.choice([1, 2, 3, 4, 5]),
    }

    tft_config = {
       "learning_rate": tune.choice([1e-3]),
       "max_steps": tune.choice([4]),
       "val_check_steps": tune.choice([2]),
       "input_size": tune.choice([2 * horizon]),
       "hidden_size": tune.choice([256, 512]),
       "dropout": tune.choice([0]),
       "attn_dropout": tune.choice([0]),
       "shared_weights": tune.choice([False]),
       "activation": tune.choice(['ReLU']),
       "random_seed": tune.choice([1, 2, 3, 4, 5]),
    }

    models = [AutoLSTM(h=horizon,
                       loss=MAE(),
                       config=lstm_config,
                       search_alg=HyperOptSearch(),
                       num_samples=1),
              AutoTFT(h=horizon,
                      loss=MAE(),
                      config=tft_config,
                      search_alg=HyperOptSearch(),
                      num_samples=1),
             ]

    fcst = NeuralForecast(models=models, freq='15min')

    fcst_df = fcst.cross_validation(df=Y_df, val_size=val_size,test_size=test_size, n_windows=None)

if __name__=='__main__':
    main()

Is it already fixed?
I'm using the latest version (v1.6.4 from oct 2023) and I'm still getting this error message.
Thanks in advance.

encoder_activation is not used in LSTM and it was removed from the docstring already. shared_weights is not used in TFT. A PR will add the choice of activation function in the GRN module of TFT.


TypeError: expected a character buffer object

  File "/usr/local/bin/format-sql", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/format_sql/main.py", line 83, in main
    _write_back(filename, lines, args.dry_run)
  File "/usr/local/lib/python2.7/dist-packages/format_sql/main.py", line 148, in _write_back
    f.write(lines)
TypeError: expected a character buffer object

I've tried this with several files, including one ruby file with embedded SQL and then just with the SQL itself. Any insight into this? I'm just surprised that others aren't getting the same error.

I get this error too. The troubling part is that when this happens it truncates the source file:
~/code/ruby >ll /tmp/x.sql
-rw-r--r--  1 skyes  wheel   965B Sep  6 15:05 /tmp/x.sql
~/code/ruby/gettxt-test >format-sql /tmp/x.sql
/tmp/x.sql

Traceback (most recent call last):
  File "/usr/local/bin/format-sql", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/site-packages/format_sql/main.py", line 83, in main
    _write_back(filename, lines, args.dry_run)
  File "/usr/local/lib/python2.7/site-packages/format_sql/main.py", line 148, in _write_back
    f.write(lines)
TypeError: expected a string or other character buffer object
~/code/ruby/gettxt-test >ll /tmp/x.sql
-rw-r--r--  1 skyes  wheel     0B Sep  6 15:06 /tmp/x.sql

😱 🙀 :rage4:

Ran into this as well. I created https://github.com/paetzke/format-sql/pull/6 which I believe fixes the issue.


Bump softprops/action-gh-release action to v2

Bump softprops/action-gh-release action to v2 as v1 uses Node 16 which is being deprecated in a few months

Not really a way to test this other than making a release with it ^^"


Running on Debian - dash doesn't support double bracket

Please adjust the scripts so it doesn't throw errors like [[: not found
On my Debian machine, /bin/sh is a link to dash, not bash
Thank you.
$ ./use-standalone-widevine.sh
./fetch-latest-widevine.sh: 13: [[: not found
/usr/bin/wget
/usr/bin/curl
./fetch-latest-widevine.sh: 19: [[: not found
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   133  100   133    0     0    621      0 --:--:-- --:--:-- --:--:--   618
./fetch-latest-widevine.sh: 25: [[: not found
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100 6561k  100 6561k    0     0  9163k      0 --:--:-- --:--:-- --:--:-- 9163k

I got this error too on Debian 12 but I use Bash (not Dash).
However even with the errors the installation was successful (because the double brackets from the script are just used for error handling) and I got DRM working when testing on https://integration.widevine.com/player.


Why messages over callbacks?

I never used Elm, so I'm just going by my experience using iced, but it feels like iced is asking me to go through extra hoops to write callbacks. I have been working through the tour example, trying to modify it to resemble the GUI I want. Say I want some code to run when the user presses a button. In other GUI frameworks you would pass a callback to the button when constructing the button. In the tour example I have to go through extra song and dance to get the same effect -- I need to define a message type, then I need to add a constructor corresponding to that particular button, then I need to add a new pattern match inside my update method, then I get to write the code I actually originally wanted to write. I assume there are some advantages to doing it this way but as a newbie it's not clear to me. Why is this preferred?

Iced is based off Elm - most evident in it structuring things into messages, views, and state. It sounds like you are used to an event driven API, or a retained mode API like in GTK. This is one way of doing things, but not the only way.
I can't speak for Iced' author, but personally ive found the more verbose state + view + message approach to scale better than using a callbacks API that hides the message passing. Ive found composing messages and state objects to be more understandable and readable as the project gets larger, compared to yeeting gobject callbacks everywhere as is the case with GTK. But thats just my opinion.
Another reason the callbacks approach might not be ideal is Rust lifetimes.  Iced has no such overhead, but has to be clever about the types and API as a result. How would you prove to Rust that all references you use in your callback will be alive for as long as the callback is callable?

Echoing all of @twitchyliquid64 's points, Iced's Elm style actually works quite well once enough patterns are learned. I came from mostly React UI, and I learned quite quickly, components were mot the way to go.
I can't speak to how optimal the ZCAs are, nor its approach to type-correctness, but judging by what I've seen so far, with basically zero macro usage, Iced is one of the best and full-featured Rust-idiomatic UI frameworks around.
Just try to roll with it. You'll struggle for about a month, try this and that, but eventually you'll get there. It's a worthwhile approach, even if it's still early days.

Echoing all of @twitchyliquid64 's points, Iced's Elm style actually works quite well once enough patterns are learned. I came from mostly React UI, and I learned quite quickly, components were mot the way to go.
I can't speak to how optimal the ZCAs are, nor its approach to type-correctness, but judging by what I've seen so far, with basically zero macro usage, Iced is one of the best and full-featured Rust-idiomatic UI frameworks around.
Just try to roll with it. You'll struggle for about a month, try this and that, but eventually you'll get there. It's a worthwhile approach, even if it's still early days.

Thanks all for the answers, now that I have a little bit more experience with it I would also add that you don't actually have to do all the steps I listed every time. Technically if you want you can use the same message type for everything but vary values inside, it's just most idiomatic for the message to be an enumeration at the top level. But if there are two very similar actions, it may be clearer to make them alternative data inside the same variant.

Thanks all for the answers, now that I have a little bit more experience with it I would also add that you don't actually have to do all the steps I listed every time. Technically if you want you can use the same message type for everything but vary values inside, it's just most idiomatic for the message to be an enumeration at the top level. But if there are two very similar actions, it may be clearer to make them alternative data inside the same variant.

@jgarvin have you ever tried Xielm? here is an example, https://github.com/linebender/xilem/blob/main/xilem/examples/to_do_mvc.rs, apparently, it doesn't have the boilerplate codes as Iced does. I have to say I don't like the Elm approach,  too much pain, recently I built a complex home page with Iced,  here is the link  that contains some thoughts about Iced,  please correct me if am wrong.

@videni Pain is not always a bad sign. I don't see any meaningful arguments made here other than "I don't like it".

@hecrj , Sorry for the negative feelings; I am just very interested in knowing if there is a better way to structure application logic without those boilerplate works.


Options based on type (Error, Success, Info, Warning)

Hey!
It would be great to have options by type (Error, Success, Info, Warning). For example, 10 secs with a close for error messages, 5 secs with no close on positive feedback ect..
I can do this now but it's all manual overrides and it would be great to change a type in one hit.
Thanks!

Right. I need to be able to not dismiss errors toasts by clicking on them and also have Copy Text and Send Email for the errors. Do you think it's possible to add?
Thanks in advance.

Yes, a copy would be amazing, however, it looks like this repo isn't being updated whatsoever.. :cry:


Better notify user about empty/incorrect PSK/PSK_ID

Hardware Target
all
Golioth Dsdk Commit Hash
309597316d6963832bb777f901e5c869f99daff3
What Host OS are you using?
Other (Mention Below)
What happened?
Using empty PSK/PSK_ID results in errors appearing from Zephyr logging subsystem, but there is no clear way what is the source of the problem. We should at least point users into PSK/PSK_ID being invalid, as that is often the case.
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

The PSK_ID now has a specific format ([device ID]@[project ID]), so apart from checking for empty string, we could check for a well formatted PSK_ID.
For example, at least one character of device ID and one character of project ID, with @ in the middle.

Implemented in #79


Machine create fails with latest Docker

Hello
docker-machine version 0.12.0, build 45c69ad
docker-machine create fails now:
docker-machine -D create \
    --driver google \
    --google-project project \
    --google-zone us-east1-d \
    --google-machine-type n1-standard-1 \
    --google-disk-size 20 \
    --google-preemptible \
    build-vm2

The machine is created and Docker is installed, but it won't start. The problem appears to be a related to a new version of Docker getting installed by a new version of the install script over at https://get.docker.com. My installs went from 17.05.0-ce to 17.06.0-ce, and with that change, Docker installs but does not start.
Jun 29 00:50:08 build-vm2 docker[5705]: `docker daemon` is not supported on Linux. Please run `dockerd` directly

or
Jun 29 00:56:12 build-vm2 dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

Unless I change:
/usr/bin/docker daemon -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider=google

to
/usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider=google

in /etc/systemd/system/docker.service.d/10-machine.conf.

Same problem here
docker-machine create
    --driver=digitalocean
    --digitalocean-access-token=XXX
    --digitalocean-size=2gb
    machinename

Yesterday the same command worked fine with docker version 17.05.0-ce
Today my new machine's docker won't start (17.06.0-ce)
I've tried multiple time.

I can confirm this too:
dm create -d digitalocean \
--digitalocean-access-token XXX \
--digitalocean-size 4gb machine

Is there any idea for a workaround?

I have the same issue.
docker version : Docker version 17.06.0-ce
docker-machine version : 0.12.0, build 45c69ad
docker-machine create --driver amazonec2 --amazonec2-region eu-west-1 --amazonec2-instance-type t2.small --amazonec2-access-key XXX --amazonec2-secret-key XXX test-create-machine
Jun 29 12:26:56 ip-172-31-10-149 systemd[1]: Starting Docker Application Container Engine...
Jun 29 12:26:56 ip-172-31-10-149 docker[5234]: docker daemon is not supported on Linux. Please run dockerd directly

docker daemon is not supported on Linux. Please run dockerd directly

I temporary downgraded docker to 17.05.0-ce on the same machine and everything work fine.

I was able to get it working with this PR
https://github.com/docker/machine/pull/4128
Just compile docker-machine with this fix and everything works again

@gnomus super, that's interesting! I wonder why it was working for 17.05.0-ce, though.
@therealppa haahaha awesome! I was wondering how I might get the old version of that script, or whether the live script takes params to install older version. web.archive.org definitely didn't not occur to me.

@dminkovsky I don't think it will work forever, if you look into the script it doesn't actually specify the version anywhere... Still, right now it works.

@therealppa @dminkovsky A longer term fix is to change the line 457 of the script from
$sh_c 'apt-get install -y -q docker-ce'

to
$sh_c "apt-get install -y -q docker-ce=17.05.0~ce-0~$lsb_dist-$dist_version"

Hopefully the fixed version of docker-machine is released soon.

@fabio-barile what about the --storage-driver aufs arg? Mine wouldn't start unless I got rid of that, too.

@dminkovsky I had the same problem on a autoscaling ci with gitlab, got the aufs problem + dockerd problem, had to solve it with specifying overlay in the storage driver.

@JustEra beyond the storage driver issue I'm also seeing verification errors for certificates created by gitlab-runner (9.3.0). Have you been running into the same issue or am I the only one?
http: TLS handshake error from ...:
 tls:
  failed to verify client's certificate: x509:
   certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "unknown")

ERROR: Error creating machine:
 Error checking the host:
  Error checking and/or regenerating the certs:
   There was an error validating certificates for host "...":
    remote error: tls: bad certificate  driver=amazonec2 name=...

This fixed storage-driver issue for me (just removed that parameter). Apply on top of https://github.com/docker/machine/pull/4128 and re-build:
diff --git a/libmachine/provision/systemd.go b/libmachine/provision/systemd.go
index 90d02603..05d63bb5 100644
--- a/libmachine/provision/systemd.go
+++ b/libmachine/provision/systemd.go
@@ -53,7 +53,7 @@ func (p *SystemdProvisioner) GenerateDockerOptions(dockerPort int) (*DockerOptio

        engineConfigTmpl := `[Service]
 ExecStart=
-ExecStart=/usr/bin/` + arg + ` -H tcp://<IP_ADDRESS>:{{.DockerPort}} -H unix:///var/run/docker.sock --storage-driver {{.EngineOptions.StorageDriver}} --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}
+ExecStart=/usr/bin/` + arg + ` -H tcp://<IP_ADDRESS>:{{.DockerPort}} -H unix:///var/run/docker.sock --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}

For anyone who wants a specific older version, we (Rancher) maintain slightly modified get.docker.com scripts to install each one:
http://rancher.com/docs/rancher/v1.6/en/hosts/#supported-docker-versions

@fabio-barile above is entirely correct. How 'testing' lets things be emitted, can't imagine.
More information here: https://github.com/docker/for-linux/issues/11#issuecomment-312143765

+1
I check back every day for a new docker-machine release... This bug is killing me :-)
For now, I add /etc/systemd/system/docker.service.d/20-machine.conf which overrides 10-machine.conf with the correct command line.   That way further docker-machine command which would normally break it, doesn't.  Of course the longer it takes for this to be fixed in the release, the more work I have putting everything back!

Thanks for the great breakdown of details on the issue - We're looking into it to try and figure out what went wrong.

So this is not related to the install script at get.docker.com but rather related to the version comparison not working correctly and with 17.06.0-ce being the first to officially deprecate docker daemon that is why we are seeing failures.
This PR (docker/machine#4128) seems to remedy this issue and I'll have a PR up by late afternoon that adds tests for the other comparison functions so that we don't run into something like this again.

@seemethere  Sounds good, thanks.  Like to hear about the test.
The diff on one of the PRs appeared a little odd to me, but think you guys will have taken care of that.

The 0.12.1 release fixes this bug. Thanks everyone for your patience and your help.

@shin- thanks for the quick fix! Looking forward to using it.

@shin- it the docker daemon -> dockerd part, but Docker still doesn't start on the machine due to
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

@shin- I was able to get around the storage driver issue by adding --engine-storage-driver=overlay (https://github.com/docker/machine/issues/3895#issuecomment-270934728). So here's my whole docker-machine` invocation.
docker-machine -D create \
    --driver google \
    --google-project $project \
    --google-zone $zone \
    --google-machine-type $type \
    --google-disk-size $size \
    --google-preemptible \
    --engine-storage-driver=overlay \
    $name

Without --engine-storage-driver=overlay it still fails with
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

as before and as in #3895

@shin- unfortunately 0.12.1 didn't fixed this for me.
$ docker -v
Docker version 17.06.0-ce, build 02c1d87
$ docker-machine -v
docker-machine version 0.12.1, build c8b17e8

I'm creating an amazonec2 machine with --amazonec2-region=eu-central-1 which creates an ami-fe408091 for me.
The output from docker-machine create is:
Running pre-create checks...
Creating machine...
(test-d-m) Launching instance...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: ssh command error:
command : sudo systemctl -f start docker
err     : exit status 1
output  : Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

Output from launched machine is:
$ systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/docker.service.d
           └─10-machine.conf
   Active: inactive (dead) (Result: exit-code) since Fri 2017-07-07 13:34:47 UTC; 36s ago
     Docs: https://docs.docker.com
  Process: 5522 ExecStart=/usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacer
 Main PID: 5522 (code=exited, status=1/FAILURE)

Jul 07 13:34:46 test-d-m systemd[1]: docker.service: Unit entered failed state.
Jul 07 13:34:46 test-d-m systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 13:34:47 test-d-m systemd[1]: docker.service: Service hold-off time over, scheduling restart.
Jul 07 13:34:47 test-d-m systemd[1]: Stopped Docker Application Container Engine.
Jul 07 13:34:47 test-d-m systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 13:34:47 test-d-m systemd[1]: Failed to start Docker Application Container Engine.

Did you see the log that explained why it crashed?
On Fri, Jul 7, 2017 at 9:39 AM, Seweryn Zeman<EMAIL_ADDRESS>wrote:

@shin- https://github.com/shin- unfortunately 0.12.1 didn't fixed this
for me.
$ docker -v
Docker version 17.06.0-ce, build 02c1d87
$ docker-machine -v
docker-machine version 0.12.1, build c8b17e8
I'm creating an amazonec2 machine with --amazonec2-region=eu-central-1
which creates an ami-fe408091 for me.
The output from docker-machine create is:
Running pre-create checks...
Creating machine...
(test-d-m) Launching instance...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: ssh command error:
command : sudo systemctl -f start docker
err     : exit status 1
output  : Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
Output from launched machine is:
$ systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─10-machine.conf
Active: inactive (dead) (Result: exit-code) since Fri 2017-07-07 13:34:47 UTC; 36s ago
Docs: https://docs.docker.com
Process: 5522 ExecStart=/usr/bin/dockerd -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacer
Main PID: 5522 (code=exited, status=1/FAILURE)
Jul 07 13:34:46 test-d-m systemd[1]: docker.service: Unit entered failed state.
Jul 07 13:34:46 test-d-m systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 13:34:47 test-d-m systemd[1]: docker.service: Service hold-off time over, scheduling restart.
Jul 07 13:34:47 test-d-m systemd[1]: Stopped Docker Application Container Engine.
Jul 07 13:34:47 test-d-m systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 13:34:47 test-d-m systemd[1]: Failed to start Docker Application Container Engine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/machine/issues/4156#issuecomment-313683311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANWZXHODzL3Lumb5NqlmXwnSi3VZBBkks5sLjUlgaJpZM4OIt7R
.

@dminkovsky Thanks for the workaround.  I decided to use overlay2 since its a latest version of the driver instead.
Do you know if there a workaround for docker-machine rm {instance-name} as well?  I'm getting an error related to EOF and it leaves remnants of key pairs on the AWS cloud preventing me from recreating the instance.

Sorry, I removed my message after I debugged hard and noticed it's actually due to what @dminkovsky wrote:

Without --engine-storage-driver=overlay it still fails with
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported
as before and as in #3895

Do we have any issue for this one particular case of using AUFS engine storage?

@cadavre

Do we have any issue for this one particular case of using AUFS engine storage?

I've seen https://github.com/docker/machine/issues/3895, which is open and which you also referenced.

@drujensen

I decided to use overlay2 since its a latest version of the driver instead.

Oh cool, thanks, I didn't know that.

Do you know if there a workaround for docker-machine rm {instance-name} as well?

Not sure, I haven't had that bug. I use docker-machine rm -f when the machine has been terminated and won't respond. With -f, docker-machine removes the VM and associated disks even if it can't reach the box.

@dminkovsky Can you create a new issue for this? It's unrelated to the dockerd/docker daemon issue, so we should treat it separately as well. And please indicate what OS you're provisioning as well :)

@shin- i'm all good. docker-machine is working 100% right now for me. are you referring to the overlay2 thing?

My other issue regarding removing machines was addressed in pr #4187. Thx.

@dminkovsky Sorry - yes, the one you mention here

@shin - After experiencing the issue in https://github.com/docker/machine/issues/4168, I attempted to re-create my staging server and found a slough of issues with  docker-machine create that has been reported in multiple recent tickets:

https://github.com/docker/machine/issues/4156
https://github.com/docker/machine/issues/4166
https://github.com/docker/machine/issues/4189
https://github.com/docker/machine/issues/4197
https://github.com/docker/machine/issues/4198

Are these all related? Start tracking these here? I can confirm that this issue is still happening today.

@shin- docker-machine v0.12.1 exhibits the same issue still

same issue with docker-machine v0.12.2

I have the same issue on aws:
when running following command:
docker-machine create --amazonec2-access-key $(aws --profile $ENV configure get aws_access_key_id) \
                          --amazonec2-secret-key $(aws --profile $ENV configure get aws_secret_access_key) \
                          --amazonec2-region $EC2_REGION \
                          --amazonec2-vpc-id $VPC_ID \
                          --amazonec2-subnet-id $SUBNET_ID \
                          --amazonec2-zone $ZONE \
                          --amazonec2-instance-type $INSTANCE_TYPE \
                          --amazonec2-private-address-only=$PRIVATE_ADDRESS_ONLY \
                          --amazonec2-monitoring=$CLOUDWATCH_ENABLED \
                          --amazonec2-root-size $ROOT_DISK_SIZE \
                          --amazonec2-use-ebs-optimized-instance=$EBS_OPTIMIZED \
                          --amazonec2-volume-type $VOLUME_TYPE \
                          --amazonec2-tags $TAGS \
                          --driver amazonec2 $LATEST_DOCKER_MACHINE_NAME

RESULT
Running pre-create checks...
Creating machine...
(**************) Launching instance...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: ssh command error:
command : sudo systemctl -f start docker
err     : exit status 1
output  : Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

MORE DETAIL
systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/docker.service.d
           └─10-machine.conf
   Active: inactive (dead) (Result: exit-code) since Wed 2017-07-26 22:20:37 UTC; 39s ago
     Docs: https://docs.docker.com
  Process: 5200 ExecStart=/usr/bin/docker daemon -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docke
 Main PID: 5200 (code=exited, status=1/FAILURE)

Jul 26 22:20:37 ************ systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jul 26 22:20:37 ************ systemd[1]: Failed to start Docker Application Container Engine.
Jul 26 22:20:37 ************ systemd[1]: docker.service: Unit entered failed state.
Jul 26 22:20:37 ************ systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 26 22:20:37 ************ systemd[1]: docker.service: Service hold-off time over, scheduling restart.
Jul 26 22:20:37 ************ systemd[1]: Stopped Docker Application Container Engine.
Jul 26 22:20:37 ************ systemd[1]: docker.service: Start request repeated too quickly.
Jul 26 22:20:37 ************ systemd[1]: Failed to start Docker Application Container Engine.

RESULT WHEN DOING MANUAL START OF DOCKER SERVICE
systemctl start docker.service
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.

EXTRA OUTPUT
journalctl -xe
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.service has finished shutting down.
Jul 26 22:21:55 ************** systemd[1]: Closed Docker Socket for the API.
-- Subject: Unit docker.socket has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.socket has finished shutting down.
Jul 26 22:21:55 ************** systemd[1]: Stopping Docker Socket for the API.
-- Subject: Unit docker.socket has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.socket has begun shutting down.
Jul 26 22:21:55 ************** systemd[1]: Starting Docker Socket for the API.
-- Subject: Unit docker.socket has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.socket has begun starting up.
Jul 26 22:21:55 ************** systemd[1]: Listening on Docker Socket for the API.
-- Subject: Unit docker.socket has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.socket has finished starting up.
--
-- The start-up result is done.
Jul 26 22:21:55 ************** systemd[1]: docker.service: Start request repeated too quickly.
Jul 26 22:21:55 ************** systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.service has failed.
--
-- The result is failed.
Jul 26 22:21:55 ************** systemd[1]: docker.socket: Unit entered failed state.
lines 3665-3703/3703 (END)

I'm still getting the same issue with version 0.12.1.

Please update to the latest release found on github:
https://github.com/docker/machine/releases/tag/v0.12.2
@eamontaaffe @ajwah @costa

Still getting the same issue with 0.12.2

Thank you @dminkovsky I was getting this error on 0.12.2 today as well!!! Seems like 10-machine.conf file does not get overridden during update

You're welcome!
I specify "overlay" in the command line option for storage engine and since
the my machines boot.
ср, 2 авг. 2017 г. в 12:05, Denis<EMAIL_ADDRESS>
Thank you @dminkovsky https://github.com/dminkovsky I was getting this
error on 0.12.2 today as well!!! Seems like 10-machine.conf file does not
get overridden during update
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319719085,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANWZSYqy1uGhWeXozx35OnFhPRSb144ks5sUJ5YgaJpZM4OIt7R
.

If using systems with kernel >4.4 I suggest using overlay2.

I wasn't able to get the machine to use overlay2, and the use case for this
fortunately was just building/CD
ср, 2 авг. 2017 г. в 12:36, Seweryn Zeman<EMAIL_ADDRESS>
If using systems with kernel >4.4 I suggest using overlay2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319727847,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANWZXLGHjLvfOOAgmBWV0zOEBDZBdSVks5sUKWBgaJpZM4OIt7R
.

Also getting this error on 0.12.2 :-(

When I try to create machine in D.O, i got the same prolem (Docker v17.06.1-ce build 874a737, Docker machine v0.12.0). I just pasted the link that may be help you to solve it: https://forums.docker.com/t/failed-to-start-docker-application-container-engine/35594/2

this still opened!

I still see this issue with docker-machine 0.12.2.  I moved forwards by uninstalling docker on the provisioned machine (sudo apt purge docker-ce && sudo apt autoremove) and used correct Rancher install script for my version as listed above.
For some reason, this still fails to start docker, but rebooting the machine then solves it.

Can confirm, still the same error

@jhartma I guess is necessary upgrade to latest release (linux image) and works

@kassanmoor seems my AMI didn't support it on AWS, I got it to work with the default one


Stop / Default pagination to pre-defined page number on initialization / load

Looks like the pagination is setting the page to 1 when it's generated on the page. Is there a way to stop this default action?

Could you elaborate? It is not clear what you mean here.

@jamespsterling, do you mean that you would like to control the selected page when the directive is first rendered?  If so, take a look at our plunker example for pagination here (the blue button).

This only happens when you use the items-per-page attribute, see plunker: http://plnkr.co/edit/HoStFd9m0EdsQCZgwJcr?p=preview.
The initial page value will be overwritten to 1 and a change event occurs. My current work-around is to use an intermediate view value to silence the first change event and revert the view based on the actual model value.

already resolved in #3118 . add ng-if  to check totallItems  whether exist.
<div ng-if="totalItems">
  <pagination ...>
</div>

There are some explanations: http://www.ngroutes.com/questions/1a9e63c/ui-bootstrap-pagination-resetting-current-page-on-initialization.html

Closing due to above explanations and lack of response from original author.


InputLockManager behavior (AGX conflict)

Alright, looking at your code, specifically this line:
https://github.com/zentarul/camerafocuschanger/blob/master/CameraFocusChanger/CameraFocusChanger.cs#L140
I have to ask what you are trying to accomplish with the InputLockManager check?
The reason I ask is that I don't think it is doing quite what you expect.
The InputLockManager class works on an enum variable and the ALL_SHIP_CONTROLS value is a combination value of the individual pieces of the vessel.
So when my AGX mod locks out CUSTOM_ACTION_GROUPS, which is part of the ALL_SHIP_CONTROLS collection, when the line of code I linked above query's InputLockManager.ALL_SHIP_CONTROLS, because CUSTOM_ACTION_GROUPS (and only that) is set, it still causes ALL_SHIP_CONTROLS to return true for locked even though only CUSTOM_ACTION_GROUPS is actually locked.
What are you actually trying to check with this line of code? Perhaps there's value I could point you towards that would work?
Regardless, I believe that it needs to be changed. As is stands, CFC will not work when:
-Stock Vessel is out of control (no kerbals and no probe core on board)
-Stock Vessel is in limited control (no kerbals onboard, probe core on board but no link to KSC)
-Stock Timewarp is engaged.
-AGX is installed.
-RemoteTech is installed (but only under certain conditions)
-Any other mod that applies a ControlLock.

Hi @SirDiazo, thanks for the heads up! The code in question is something that hvacengi from kOS gave me. I admit that I didn't look deep into what it was doing.
In any case, the goal of that line of code is to figure out if someone else has keyboard focus for a text input field, such as the Flag name and description or the kOS console or any other mod with a text field like MechJeb or whatever.
I'll look at the other values for that lock flag, but if you have a better idea of what to do, please let me know!


Emoji are rendered within code and code blocks

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.71.1/extended linux/amd64 BuildDate: 2020-05-25T13:06:06Z

Does this issue reproduce with the latest release?
Yes
Problem Description
Emoji strings with code (single backticks) or code blocks (triple backticks) are rendered to images. They should remain as strings.
By comparison, GitHub does not transform emoji strings when they appear in code.
I came across this problem while trying to document the use of emoji strings. Not very important...

Having a way to escape emojis in code as on GitHub (where :grin: won't be rendered as :grin:) would be nice indeed.

I suppose we can already do that with HTML entities but it's a few more characters to type. :slightly_smiling_face:

Workaround per @maelle: use :grin: instead of :grin: in your markdown.

I just posted this issue to goldmark-emoji and was promptly told to come back here :-|

goldmark is not dedicated for Hugo.
If you have an issue 'via' Hugo, Please submit issues in Hugo repository.

So here I am :smile:
Here's my original issue:
I have a table full of MAC addresses, some of them containing e.g. :de: which gets translated to :de:, even though it is surrounded by back-ticks.
e.g.: (with fake data)

What I See
What I Expect

ab:cd:01:de:ef:02
ab:cd:01:de:ef:02

I have wrapped all of the data in backticks, but that has no effect on goldmark, but works here on github.
I have not found any way to disable the emojification, e.g. \:de: just adds a \ before the emoji, :\de: disables the emoji, but leaves a spurious \ in my data, killing copy-pastability.
I'm using goldmark v1.4.4 via Hugo v0.93.0

Either set enableEmoji = false in site configuration, or insert a zero-width space between the colon and the string.

Either set enableEmoji = false in site configuration, or insert a zero-width space between the colon and the string.

As clever as those solutions might be...

I don't want to have no emojis, just not in code blocks
inserting invisible characters does not help when dealing with copy/paste-able data. That would result in data which looks ok but is silently and invisibly broken

@cobber Inserting invisible characters is a particularly poor idea. Sorry about that. Seemed like a good idea at the time...

The yuin/goldmark-emoji extension did not exist when emoji support was added to Hugo, and that extension seems to handle these cases as desired. We could retain our emojify template function, but replace everything else.
I do not understand what impact that would have on alternate content formats (HTML, adoc, org, etc.).
I'd love to make this somebody else's problem, particularly when the "somebody else" is yuin/goldmark. That project is exceptionally well-maintained.

I worked around this particular issue by leaving emoji rendering off by default and adding an emoji shortcode.
Content:
{{< emoji ":+1:" >}}  Everything is A-OK. Carry on!

Shortcode (emoji.html):
{{ .Get 0 | emojify }}

I looked into the yuin/goldmark-emoji extension:

It has full coverage of GitHub emojis (a few gaps will be filled when #5 is merged).
Emoji shortcodes in code blocks, fenced code blocks, and inline code are not converted (what this issue is about)
Adding 5 lines of code (excluding tests/docs) we can do:

[markup.goldmark.extensions]
emoji = true

But this is overridden if enableEmoji in the configuration root is true, and I think that's OK. We support emoji in markdown (goldmark), org mode, asciidoctor, pandoc, and rst. And we do that by parsing the content before we hand off to the renderer.
So, if you are only using emoji in markdown, the configuration would be:
enableEmoji = false # default is false

[markup.goldmark.extensions]
emoji = true # default is false

So, that's quick to do.
As a second and optional step, we could (perhaps) replace kyokomi/emoji with yuin/goldmark-emoji in hugo/helpers/emoji.


feat(CoinIcon): Added BNB icon

:tada: This PR is included in version 1.0.0-alpha.37 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Added Ravindra's profile in README.md

I have made my first contribution and have added my name in the README.md

Hi


feat,test(inventory): Support listing stopped VMs and major rework of unit tests

What this PR does / why we need it:
This adds support to list stopped VMs to the inventory plugin and applies a major rework to the inventory's unit tests. See the individual commit messages for a more detailed explanation of changes.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #93
Special notes for your reviewer:
Release note:

Added support to list stopped VMs to the inventory plugin

/approve
Thanks the rest looks good!

/lgtm


PHP Docs: int/bool vs integer/boolean

Currently the int params and returns are being updated to integer. Same from bool to boolean.
The following doc (right):
/**
 * @param int $n
 *
 * @return int
 */
public function a(int $n):int
{
	return 2 * $n;
}

is updated to it (wrong):
/**
 * @param integer $n
 *
 * @return integer
 */
public function a(int $n):int
{
	return 2 * $n;
}

The issue is that @return integer is not int (a number)... On returns it must be int because updating to integer we say that we are returning an instance of the class integer... Then the type hint :int would have to be changed to :integer, but the PHP will show a fatal error. Because the correct would be:
/**
 * @param integer $n
 *
 * @return integer
 */
public function a(int $n):integer
{
	return new integer(); // An instanceof integer
}

The same applies to boolean's, while the short syntax is the correct.
See:

https://stackoverflow.com/questions/10636321/#answer-44301450

Test:
<?php

class Test
{
	public function a(int $n):int
	{
		return 2 * $n;
	}

	/**
	 * [b description]
	 *
	 * @param integer $n
	 *
	 * @return integer
	 */
	public function b(integer $n):integer
	{
		return 2 * $n;
	}
}
$test = new Test;
var_dump($test->a(5));
// int(10)
var_dump($test->b(5));
// PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Test::b() must be an instance of integer, integer given, called in...

The CodeIgniter4 Standard is not updating the method type hint, but the docs. What instructs wrong params and return types.
Detected with PHP Integrator.

Thanks for the report, I'll have to look into the PHP Codesniffer core for this one I think.

The conversion is done here. I do not know yet if is possible change it, or if php-integrator is that conflicts with that... since int is integer but not integer(), kk.

Thanks for tracking that down @natanfelles , I haven't had a chance to take a look yet, I've a deadline for Tuesday 16th so I'll be able to look at after that if I cant squeeze it in before.

Just dropping an approach I use on huge projects. Coding standard can break typehints in many ways, since they don't know the context of parent/child files:
 <?php

 final class SuperCoolSniff implements Sniff
 {
     /**
      * @param int $position
      */
-    public function process(File $file, $position)
+    public function process(File $file, int $position)
     {
         // ...
     }
 }

It's better to use AST for this in tools like Retor instead of token_get_all(): https://www.tomasvotruba.cz/blog/2018/12/10/rocket-science-behind-migration-of-docblock-types-to-php-typehints/


fix rendering issue

This PR fixes a rendering problem in client2 when moving nodes within a tree, and contains a patch to make client errors more readable in log

@SmithChart: Thanks for having a look anyway!


Detected warnings while compiling a static version of OpenSSL 3.1.14

Hi there,
I tried to build a static version of OpenSSL, but received some warnings from libcrypto.a. Well, make test passed. I wonder if it is really working ok?
What is the correct configure command to get rid of these warnings? Thank you!
OpenSSL version: 3.1.14
Linux distribution: Rocky Linux 9   (with glibc-static installed)
Configure:
mkdir -p /opt/github.com/openssl/openssl/current/.build;
cd /opt/github.com/openssl/openssl/current/.build;
../config no-shared -static --prefix=/opt/github.com/openssl/openssl/current/.dist --openssldir=/opt/github.com/openssl/openssl/current/.dist

${LDCMD:-gcc} -pthread -m64 -Wa,--noexecstack -Wall -O3 -L.  -static \
        -o test/versions \
        test/versions-bin-versions.o \
        -lcrypto -ldl -pthread
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x13): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-bio_addr.o): in function `BIO_lookup':
bio_addr.c:(.text+0xc19): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-bio_sock.o): in function `BIO_gethostbyname':
bio_sock.c:(.text+0x281): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x13): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-bio_addr.o): in function `BIO_lookup':
bio_addr.c:(.text+0xc19): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./libcrypto.a(libcrypto-lib-bio_sock.o): in function `BIO_gethostbyname':
bio_sock.c:(.text+0x281): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Those warnings are safe.  It would be possible to avoid them by specifying no-dso at configure time but this would prevent external providers from being used (FIPS plus any third party ones).


[KYUUBI #3839][Authz] Introduce signature mechanism to protect session variable on engine side

Why are the changes needed?

to close #3839 .
The session signing feature is introduced with asymmetric encryption to prevent manipulation of session user identity or other key session elements, which could cause privilege leaking in scripts.

Server: Server creates and holds the singleton keypair for session signing if feature enabled
Server -> Engine: Server passes the public key to Engine when launching
Server -> Engine: Server generates session signing on session user when opening Kyuubi Session to Engine
Session -> Statement: Kyuubi session create Statement with context bringing publickey and session user signature
Engine: Engine verify session user signature with signature wherever necessary, e.g. in Authz for session name authentication.

ECDSA, with a shorter key length and better performance than RSA, is the supported asymmetric encryption in the initial implementation, which is widely supported on JDK7+ in HotSpot or OpenJDK. The session signature is generated with SHA256withECDSA.
How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[x] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Linked to issue #3839 .

cc @yaooqinn @turboFei @pan3793

also cc @cfmcgrady

Codecov Report

Merging #3838 (5272e5d) into master (6bf4e49) will decrease coverage by 0.05%.
The diff coverage is 52.63%.

@@             Coverage Diff              @@
##             master    #3838      +/-   ##
============================================
- Coverage     52.97%   52.92%   -0.06%
  Complexity       13       13
============================================
  Files           497      498       +1
  Lines         28022    28061      +39
  Branches       3863     3869       +6
============================================
+ Hits          14845    14851       +6
- Misses        11781    11805      +24
- Partials       1396     1405       +9

Impacted Files
Coverage Δ

...he/kyuubi/plugin/spark/authz/util/AuthZUtils.scala
42.64% <0.00%> (-12.07%)
:arrow_down:

.../org/apache/kyuubi/config/KyuubiReservedKeys.scala
0.00% <ø> (ø)

.../kyuubi/engine/spark/operation/ExecutePython.scala
89.86% <80.00%> (-0.35%)
:arrow_down:

...kyuubi/engine/spark/operation/SparkOperation.scala
82.55% <80.00%> (-0.16%)
:arrow_down:

.../main/scala/org/apache/kyuubi/util/SignUtils.scala
92.30% <92.30%> (ø)

.../kyuubi/server/mysql/constant/MySQLErrorCode.scala
13.84% <0.00%> (-6.16%)
:arrow_down:

...uubi/engine/spark/events/SparkOperationEvent.scala
88.88% <0.00%> (-5.56%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLCommandHandler.scala
76.84% <0.00%> (-4.22%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLGenericPackets.scala
76.59% <0.00%> (-2.13%)
:arrow_down:

...apache/kyuubi/session/KyuubiBatchSessionImpl.scala
90.66% <0.00%> (-1.23%)
:arrow_down:

... and 6 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Could you add some ut？
Shall we redact the key for en/decryption？

Could you add some ut？ Shall we redact the key for en/decryption？

OK, let me mark this as WIP. Will add some ut soon.

Overall this LGTM, could you please add test cases on server side? I think it should include

positive case
sign enabled can not disable by session configuration
unmatched user and sign
sign enabled but no sign in configuration

With the session user bowen2, querying with pyspark.
In Authz plugin on engine side, the session user bowen2 are verified with public key generated on server side and checked for table privileges with session user.

session user verified, no access privileges to the table:

session user disguised as superadmin directly in SparkContext in user code (multi-line scripts for single execution), session user superadmin  is not verified:

Thanks @bowenliang123 great work! Merged to master

Thanks @bowenliang123 great work! Merged to master

Many thanks for the support, help, and discussion from all the reviewers!
Hope this PR will bring general security improvement in current and future expected scenarios, especially for dynamic scripting like Scala, Python and etc, which is greatly in demand for dynamic flexibility while privileges are guarded at the front line.

This is also applied to pyspark support. https://github.com/apache/kyuubi/issues/3780


link to collection development policy is broken

From the policies and guidelines page, the link to the new collection development policy is broken.
from here: https://cdr.lib.unc.edu/external?page=about.guidelines
this link is broken: https://cdr.lib.unc.edu/external?page=about.collectionPolicy

Fixed, file permissions were wrong.


For sign in add warning message, to make sure user is logging in with the correct URL

From @Citi3enKane on November 19, 2018 5:13

To better protect from phishing we could add this:

Copied from original issue: worbli/worbliportal#19

Underneath 'Welcome back to WORBLI'

cleaner version:


Trailing comma json(519)

Trailing comma json(519)

Closing as not actionable. Please make sure to fill in the issue template


chore: fix typo in doc

Just a typo in the doc :)

@freerdp-bot test please

@hugo-syn  thank you for the contribution


Light Intensity from alpha?

Is it possible to get the light intensity from the alpha channel for VRC as Amplify has this node setup;
https://wiki.amplify.pt/index.php?title=Unity_Products:Amplify_Shader_Editor/Light_Color

With a custom function node add a float4 output
Out = _LightColor0.rgba;


Error Handling in 0.27

Is your feature request related to a problem? Please describe.
Handling errors with 0.27 gets much harder as methods are returning anyhow trait. It is a step back from 0.26 which had dedicated error(s).
As rust-s3 is a library change to anyhow  will make harder for users to handle errors.
Describe the solution you'd like
Have you considering exposing thiserror instead of anyhow ?
Even anyhow documentation says

Comparison to thiserror
Use Anyhow if you don't care what error type your functions return, you just want it to be easy. This is common in application code. Use thiserror if you are a library that wants to design your own dedicated error type(s) so that on failures the caller gets exactly the information that you choose

Describe alternatives you've considered
Other alternative would be to handle errors yourself but this would make no sense.
Additional context
Have no motivation to get into flame wars about library, this is just a suggestion for your consideration.

Hey ! I've being giving this a look today, would you mind tell me what you think of this?
https://github.com/durch/rust-s3/compare/dev...nightmared:thiserror
Also, before opening a PR, I think it would be useful to know if this is a wanted feature (Maybe @durch would prefer keeping anyhow?)
As an important note, this is not API compatible with the current 0.27 branch but I guess this is acceptable in a 0.x release.
Also, I fixed the two clippy 1.49 issues (one of them yields code that I actually find less legible that before, but oh well let's not upset clippy!).
finally, I added the sync tests to the Makefile so that it is executed when calling make ci.

Hey ! I've being giving this a look today, would you mind tell me what you think of this?
https://github.com/durch/rust-s3/compare/dev...nightmared:thiserror
Also, before opening a PR, I think it would be useful to know if this is a wanted feature (Maybe @durch would prefer keeping anyhow?)
As an important note, this is not API compatible with the current 0.27 branch but I guess this is acceptable in a 0.x release.
Also, I fixed the two clippy 1.49 issues (one of them yields code that I actually find less legible that before, but oh well let's not upset clippy!).
finally, I added the sync tests to the Makefile so that it is executed when calling make ci.

Hi @nightmared,
it looks good to me but it's up to @durch to decide.
Also, I'd recommend you to split the pr to two commits, one addressing thiserror other addressing clippy

Hi @nightmared,
it looks good to me but it's up to @durch to decide.
Also, I'd recommend you to split the pr to two commits, one addressing thiserror other addressing clippy

@milenkovicm, @nightmared thank you both for the discussion, anyhow was mostly a spur of the moment decision. There has been a lot of development around error handling, and I'm sort of still stuck in error_chain days. I'm very open to a PR or additional discussion as to how we'd want to handle errors in general.

@milenkovicm, @nightmared thank you both for the discussion, anyhow was mostly a spur of the moment decision. There has been a lot of development around error handling, and I'm sort of still stuck in error_chain days. I'm very open to a PR or additional discussion as to how we'd want to handle errors in general.

@nightmared did a decent job with on this issue in his branch, maybe that could be a good starting point to address this issue.

@nightmared did a decent job with on this issue in his branch, maybe that could be a good starting point to address this issue.

Right now 0.27 feels like a downgrade of sorts with loss of custom error types.
thiserror would be strongly preferable to anyhow in error handling.
is there maybe something that can be helped with to get #189 over the line?

I'd like to add to this that the current use of anyhow in 0.27 seems to be broken as well. In the following output I printed the current anyhow::Error using println!("{}") first and then manually running down the .cause() chain.
It seems that on each layer, the previous error has been converted to a string and then embedded into the next error up the chain.
Using anyhow's implementation of Display:
error sending request for url (http://<IP_ADDRESS>:9000/test/test): error trying to connect: tcp connect error: Connection refused (os error 61)

Caused by:
    0: error trying to connect: tcp connect error: Connection refused (os error 61)
    1: tcp connect error: Connection refused (os error 61)
    2: Connection refused (os error 61)

Manually iterating the .cause() chain:
error sending request for url (http://<IP_ADDRESS>:9000/test/test): error trying to connect: tcp connect error: Connection refused (os error 61)
---
error trying to connect: tcp connect error: Connection refused (os error 61)
---
tcp connect error: Connection refused (os error 61)
---
Connection refused (os error 61)

Overall, I'd definitely agree with the fact that this crate should go with thiserror as it allows downstream crates or applications to more easily treat errors and react to them. It then effectively becomes their choice to either ignore, handle, or print the error while the usage of anyhow basically makes anything but printing a big headache.

We've switched to thiserror finally :)


Remove late final from keyboardVisibilitySub.

This change was made in dea76 commit.
This commit reverts this change because of the following problem.
It causes the problem:
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following LateError was thrown while finalizing the widget tree:
LateInitializationError: Field 'keyboardVisibilitySub' has not been initialized.
When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 266:49  throw_
packages/visual_editor/main.dart 152:40                                       get keyboardVisibilitySub
packages/visual_editor/editor/services/editor.service.dart 47:11              disposeEditor
packages/visual_editor/main.dart 233:20                                       dispose
packages/flutter/src/widgets/framework.dart 5088:11                           unmount
packages/flutter/src/widgets/framework.dart 1917:12                           [_unmount]
packages/flutter/src/widgets/framework.dart 1915:7                            <fn>
packages/flutter/src/widgets/framework.dart 6381:16                           visitChildren
...

Similar problem discussed on SO:
https://stackoverflow.com/questions/69309379/lateinitializationerror-field-has-not-been-initialized-in-flutter

I don't think I'll be merging this on. I found problems that seem to be higher up in the call stack. I'll be updating you once I have a clear answer.


Additional transforms

This pull request adds several new image transforms. They should work on images with arbitrary number of channels. Rescales, RandomGamma and RandomBlur preserve bit depth of the input image, while AutoContrast outputs float32 image, similar to Normalize as it is meant to be a replacement for it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Python SDK dev module

Summary
This change adds a module for developing the Python SDK.
Motivation
Main purpose is to allow others to run Python tasks without having to have a Python environment in their computers. This can be done in phases but includes something from all of the following:

Migrate hatch tasks;
Add utilities for testing or linting any Python files (e.g., doc snippets);
Migrate CI tasks (from mage);

The last one is related to a backlog item for using zenith in our CI. The ./ci module will use ./sdk/python/dev as a dependency.
Interesting patterns
I found the following patterns interesting while making this module.
Project structure
It’s a good example of how to structure bigger projects into multiple files. Instead of a single src/main.py file, you can turn it into a src/main package, with __init__.py as the “entrypoint” and other files imported from there.
Constructors
With latest constructor support in https://github.com/dagger/dagger/pull/6152 it’s also possible to re-use an object’s constructor in another object’s method or top level function.
So the following lines allow breaking into dedicated objects various aspects of development, and provide top-level functions to instantiate those objects, without duplication:
https://github.com/dagger/dagger/blob/3f0163be8d8565e449ce8c7bb0903e0b0802f435/sdk/python/dev/src/main/__init__.py#L26-L30
Laziness
The object types were created with modularity principles in mind, and maximum laziness. Especially in the Deps object, there’s no special care to resolve things before using. By passing around lazy objects like any programing object, the engine resolves the DAG more efficiently.
https://github.com/dagger/dagger/blob/3f0163be8d8565e449ce8c7bb0903e0b0802f435/sdk/python/dev/src/main/deps.py#L219-L225
I was surprised however at how little async calls I actually needed in the end seeing how much this module actually does. One is a joke[^1], the other is an experiment and the last one was needed to get the an endpoint value for a test condition (Test.provision) that’s hardcoded right now in  a GHA workflow that’s only run when PR’s are merged into main. I tested the condition locally on macOS and it failed in Linux on CI. This test reproduces that environment with docker so anyone can test it locally.
[^1]: dagger -m dev call joke: "['hip', 'hip'] (hip hip array!)"
Concurrency
The experiment is between dagger call all-tests (lazy) and dagger-call tests (concurrent). One uses concurrency to test the SDK with multiple Python versions, while the other just returns a list of lazy Test objects for each version.
https://github.com/dagger/dagger/blob/3f0163be8d8565e449ce8c7bb0903e0b0802f435/sdk/python/dev/src/main/__init__.py#L98
What’s interesting is that returning a list of functions seems viable to replace the need for concurrency at the language level in some cases.
If you run dagger call tests it’s fixed to executing Test.default, which runs all tests. If you just want to run unit tests you’re out of luck if you want a single command. But with dagger call all-tests unit, you’re basically selecting a field for each item the the list so there’s more freedom to sub-select a function on multiple objects, while executing them concurrently and without having to do any concurrency at the language level.
with_focus and pipeline
If you rely on dagger call adding .sdout() to a Container, then you’ll need the let it finish to see the test run’s results, unless you have --focus=false. But if you take care in adding .with_focus() before the execs that you’re interesting in seeing the output of, then it’ll stream that output in the TUI during execution in the default --focus=true, without showing the clutter.
https://github.com/dagger/dagger/blob/3f0163be8d8565e449ce8c7bb0903e0b0802f435/sdk/python/dev/src/main/test.py#L56-L61
This is especially nice when you’re returning multiple lazy Test objects for different Python versions and seeing their output in real-time, concurrently.
There’s a catch 22 problem however. On one hand, the automatic addition of .stdout by dagger call creates duplicated output (one from the focused step, the other from the final response). On the other, if you don’t add stdout you wouldn’t see anything without the TUI (e.g., --silent).
There’s several ways this could be fixed but I think relying more on with_focus provides the better experience. Paired with pipeline you can group the output in the TUI with your own labels, while with stdout from multiple objects you get all the output but they’re not categorized or grouped. Just printed one after the other, in the ordered the happened to arrive.
What’s next?

Directories are only filtered when using the default sources (from host). If you provide an alternative dir via the CLI, that’s not filtered. Try to exclude files from any Directory instead.
Port more functions from mage and use as dependency of a ./ci module in Go, to delegate all Python related tasks to, for example, linting doc snippets. Related to:

https://github.com/dagger/dagger/issues/6137

Document how to:

test a doc snippet using the module
lint doc snippets

Ready for review. Updated the description with more context.

Rebased.
Note for reviewer. While there's some functions that don't work quite right from outside of the sdk/phython dir, like linting docs, the module does what was intended initially: to replace hatch tasks with dagger. CI with mage works as usual, replacing it is part of a larger effort and out of scope for this PR.
Easier to make improvements over time in followups because while this isn't merged it takes effort to use it in other branches.

Starting to look into this one now.

@gerhard you may need hack/dev if you haven't built it. It depends on main.

The only thing I noticed is that I'm currently getting this when I run ../../hack/dev dagger call -m dev tests
+ exec dagger call -m dev tests
✔ dagger call tests [48.49s]
┃ true
✘ sync ERROR [0.01s]
✘ exec foobar ERROR [0.13s]
┃ panic: exec: "foobar": executable file not found in $PATH goroutine 1 [running, locked to thread]:
┃ runtime/debug.Stack()
┃         /usr/local/go/src/runtime/debug/stack.go:24 +0x64
┃ main.main.func1()
┃         /app/cmd/shim/main.go:63 +0x34
┃ panic({0xa7dae0?, 0x40005d8b80?})
┃         /usr/local/go/src/runtime/panic.go:914 +0x218
┃ main.shim()
┃         /app/cmd/shim/main.go:291 +0xda8
┃ main.main()
┃         /app/cmd/shim/main.go:76 +0x98
✘ directory(path: "foobar") ERROR [0.02s]

However, quite mysteriously I hit that, had to go look at something else for a few hours and then when I came back and ran it again it passed. So could be a flake? Just worth double checking

That's a known issue actually! It's harmless but we should fix it I think. I forgot to create an issue.
There's a few integration tests around .sync that trigger errors on purpose because .sync behavior is harder to test on a successful case.

@sipsma So the Go panic is being raised on non-existing withExec command and directory path. I haven't looked into shim/main.go yet.


Make TCMalloc GC Thread and CurrentThread can be exited gracefully.

The TCMalloc GC Thread is not been joined when exited. It may be referenced resource already been released.
The CurrentThread thread local variable is used to gather the memory statistics and is defined in ExecEnv.
Because the exit of ExecEnv is after the StorageEngine. So we can check the exit state of StorageEngine to exit the CurrentThread as soon as possible.

run starrocks_be_unittest

run starrocks_be_unittest


fix(solc): remove default include paths

Motivation
currently, the default include_paths contain the sources, test & script dirs, which lead to the possibility of ambiguous imports like import 'interface/IContract.sol'; given the project tree
- src
-- Contract.sol
-- interface
--- IContract.sol

while it is possible to make the Graph resolve such import paths properly, it leads to ambiguity while trying to reconstruct sources for standard json input, since the same node can be imported as interface/IContract.sol and src/interface/IContract.sol
more info here
Solution
remove default include paths since they are all covered by the base path
PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Updated the changelog

@mattsse @gakonst removed

remove the usage of this from foundry?
are you talking about disabling custom include_paths altogether?
https://github.com/foundry-rs/foundry/blob/433be903a02be0e49c37deacd4f3fe4d71b4c97c/config/src/lib.rs#L155

this we should keep, since this is a valid solc customization, but remove the default paths in ProjectPathConfig


feat!: support platform settings via preferences apis

Requires https://github.com/raystack/proton/pull/307

BREAKING CHANGE: the admin settings (earlier supported via the config file) will now be configured with Preferences API.
Settings such as disable_orgs_on_create or invite email subject and body for instance can be listed with CLI commands for preferences or via Describe Preferences API, and the values can be updated via the Create Platform Preferences API

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

91 of 253 (35.97%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 50.11%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/store/postgres/preference_repository.go
0
5
0.0%

cmd/server.go
12
20
60.0%

cmd/serve.go
0
32
0.0%

internal/api/v1beta1/preferences.go
1
38
2.63%

cmd/preferences.go
77
157
49.04%

Totals

Change from base Build<PHONE_NUMBER>:
-0.3%

Covered Lines:
6174

Relevant Lines:
12321

💛  - Coveralls


Search for go.mod whenever if found a Go file

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Go modules lints are run only when go.mod is included, not when only some Go files are included.
This is strange when VALIDATE_ALL_CODEBASE is set to true. A Go module does exist but it's not identified because go.mod is not updated.

Anything else?
No response

Hi @harryzcy ! Isn't this covered by VALIDATE_GO to true (the default)?

Hi @harryzcy ! Isn't this covered by VALIDATE_GO to true (the default)?

VALIDATE_GO_MODULES: true has a lot more lint cases than VALIDATE_GO. I got many of those after upgrading super-linter to v6. And those lints only show up when go.mod gets changed.

@harryzcy this is not supported by golint. The last time I looked, it only supports the whole set of checks when linting Go modules, while only a subset of checks is enabled when linting file by file.

Ah,

I think I get what you mean. Linting of Go modules triggers when there are changes in go.mod only:
https://github.com/super-linter/super-linter/blob/d33107802b1ecab6ffc4146ac2d5644c72a673e4/lib/functions/buildFileList.sh#L316-L329

I mean I want to lint Go modules even when go.mod is not changed, but some Go files are changed.

Makes sense. I'll happily review a PR for this. We probably need a way to get the path to the go.mod file that is related to a Go file.


Use the model for other animals

Hi Silvia,
In your paper it is mentioned that this model can be used on other animals as well. I am having difficulties to do so. I crop my image and enter the bounding box in the crop file. When running the evaluation script the result for my own image is not adequate.
Would you kindly outline the steps necessary to use this model on new images of other type of animals?
I would appreciate your help!
Thanks,
Best,
Arian

Hi,
The model can be used for other animals in the sense that you can train a network for other species.
This does not mean that the model trained for the Grevy’s zebra can be used on other animals directly.
Best,
Silvia

On 14. Jul 2021, at 16:44, arianme @.***> wrote:
Hi Silvia,
In your paper it is mentioned that this model can be used on other animals as well. I am having difficulties to do so. I crop my image and enter the bounding box in the crop file. When running the evaluation script the result for my own image is not adequate.
Would you kindly outline the steps necessary to use this model on new images of other type of animals?
I would appreciate your help!
Thanks,
Best,
Arian
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/silviazuffi/smalst/issues/25, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNYVFOWCWUMFEMSAZKOBALTXWPE5ANCNFSM5ALTP54A.

I see, thank you for your quick reply.
Best,
Arian


Myrecords migrations rebased

Overview
This PR includes the following proposed change(s):

{List all the changes, if possible add the linked issue/ticket #}

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Screenshots
Please add any relevant UI screenshots if applicable.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] New and existing unit tests pass locally with my changes

hey champ if you can update this branch again i'll review it and merge it in today - i don't want to do it for you because i'm not sure if you've done more work locally.  @dogcomplex

@dogcomplex going to merge this one as it has new changes stacked ontop of the dev > this branch merge, but next time please resist the temptation to hit the 'update branch' button here, it merges dev into you branch vs rebase and makes reviews painful as it includes everyone else's recent changes in files changed.