isDayBlocked fails to block day until blur'd and refocused

react: 16.1.1
react-dom: 16.1.1
react-dates: 15.1.0

My component is initialized as follows:
<SingleDatePicker
    id="delivery_date"
    hideKeyboardShortcutsPanel
    placeholder="Date"
    isDayBlocked={this.isDayBlocked.bind(this)}
    numberOfMonths={1}
    date={this.state.date}
    focused={this.state.dateFocused}
    onDateChange={this.onDateChange.bind(this)}
    onFocusChange={this.onFocusChange.bind(this)}
/>

My isDayBlocked method looks like this:
isDayBlocked(day: Moment): boolean {
    let mock = moment().add(6, 'days').startOf('day')
    if(day.isSame(mock)) {
        return true;
    }
    return false;
}

The result I am seeing is as follows. The day (6 days from now) is not blocked when the calendar opens. However, if I blur the input field and then refocus it, you can see that the "blocked" date renders with the blocked style.  There is a catch though, I can still select the blocked date.
In the example below you can see that when the calendar open's the 23rd of November is not blocked. Blurring a refocusing the input field however causes it to draw properly.

^ example showing the focus->blur->focus behavior
If I change my isDayBlocked to just be return true Upon focusing on the calendar's input field it opens with all days blocked and non-clickable.
I am using all of the default styles. The only thing I can currently think of is this is being rendered by Hypernova so maybe that has something to do with it?
Though if I do something contrived like this:
let datePicker = null;
let isServer = true;

try{
    window
    isServer = false;
} catch(_){}

if(!isServer){
    datePicker = <SingleDatePicker
        id="delivery_date"
        hideKeyboardShortcutsPanel
        placeholder="Date"
        isDayBlocked={this.isDayBlocked.bind(this)}
        numberOfMonths={1}
        date={this.state.date}
        focused={this.state.dateFocused}
        onDateChange={this.onDateChange.bind(this)}
        onFocusChange={this.onFocusChange.bind(this)}
    />
}

... later...
{datePicker}

Then it still exhibits the same behavior.

Did you figure it out?

Ya, I’m good

@aventurella how did you solve this? Experiencing the same behaviour myself.

For me it was that I forgot to specify the comparison granularity for moment:
// before
  isDayBlocked(day) {
    const { unavailableDays } = this.props;
    return unavailableDays.some((unavailableDay) => moment(unavailableDay).isSame(day));
  }

// after
  isDayBlocked(day) {
    const { unavailableDays } = this.props;
    return unavailableDays.some((unavailableDay) => moment(unavailableDay).isSame(day, 'day'));
  }

@thomassnielsen hi, have the same problem, but granularity doesn't solve it. Maybe there were other issues along with this one, that you solved to make it work? @aventurella

We didn't change anything else, the code above is how we run it in production.

so the solution for me was to change
isDayBlocked={this.isDayBlocked} to isDayBlocked={(day) => this.isDayBlocked(day)}

@nazartry That makes sense as the latter forces a recalculation on every render.
If you are having trouble with performance as a result, it may be beneficial to have a class method like isDayBlockedFactory that creates a new isDayBlocked method only when you need it to be recalculated. :)
@thomassnielsen we also ship a isSameDay method with react-dates that's useful for this situation (and we've found to be a bit faster than the built in moment method). :) Glad you solved your issue!

@majapw cool! thanks for mentioning that, it will be super beneficial in my case

@nazartry That makes sense as the latter forces a recalculation on every render.

This solved my issue. I didn't know about this behaviour.


Add support of inline tables in include on pyproject.toml.

Resolves: #8

[x] tests
[ ] documentation will be added on poetry

This PR supports inline tables in the include directive. This is similarly functional to the package directive.

@stephsamson this should also resolve python-poetry/poetry#2087 correct?

As per our discussion in discord,
The feature I would like to see out of this is to be able to embed resource files into the wheel (and subsequently the installed package) at an arbitrary location.
For instance, in my project i would like to embed the pyproject.toml into the installed sources so the library may access this resource at runtime. I wish to do this to access the version string contained in the pyproject.toml. Presently, even if the tool.poetry.include directive is used the file does not end up in the installation directory, thus is unusable to the installed application.
My application has the structure
/
/pyproject.toml
/src/...
/test/...

What I would like to do is copy, at build time, /pyproject.toml to /src/pyproject.toml so it may be embedded as a resource.

@stephsamson this should also resolve python-poetry/poetry#2087 correct?

Yes!


Exported project does not open (scene parse error), works fine in editor

Godot version:
6b10e3750 (both tools and export compiled from same source)
OS/device including version:
Windows 10
Issue description:
Game opens and runs fine with editor, but when exported it exits immediately. Debug build with -v outputs:
[...]
Loading resource: res://Game.tscn
Loading resource: res://Game.gdc
Loading resource: res://Enceladus/Enceladus.tscn
ERROR: ResourceFormatLoaderText::load_interactive: Condition ' err != OK ' is true. returned: Ref<ResourceInteractiveLoader>()
   At: scene\resources\scene_format_text.cpp:1225
ERROR: Failed loading resource: res://Enceladus/Enceladus.tscn
   At: core\io\resource_loader.cpp:190
SCRIPT ERROR: GDScript::load_byte_code: Parse Error: Can't preload resource at path: res://Enceladus/Enceladus.tscn
          At: res://Game.gdc:14
ERROR: GDScript::load_byte_code: Method/Function Failed, returning: ERR_PARSE_ERROR
   At: modules\gdscript\gdscript.cpp:771
ERROR: ResourceFormatLoaderGDScript::load: Condition ' err != OK ' is true. returned: RES()
   At: modules\gdscript\gdscript.cpp:2118
ERROR: Dictionary::_unref: Condition ' !_p ' is true.
   At: core\dictionary.cpp:171

If I'm reading it correctly, It can't parse res://Enceladus/Enceladus.tscn, which causes error to propagate to preload in Game.gd.
There are no unusual files (json, etc) that are used/imported in the Enceladus.tscn
If I remove references (preloads) to Enceladus.tscn game runs fine - I'm assuming there is something in the scene that causes the error.
When I remove everything from the scene (every child), it still crashes with same output. Complete contents of Enceladus.tscn with every child node removed: Enceladus.zip
Files were not edited by hand. I assume that the dangling Image is what causes problem.
Steps to reproduce:
Happens in a large project, unable to create minimal reproduction.
Expected behaviour:
Best case: project runs when exported as it does in the editor.
Sufficient: increase verbosity of the error message in debug mode, allowing pinpointing of corruption in the scene file in case of further corruptions.
Ad-hoc advice as how to recover the scene would be also greatly appreciated, but the core issue is that the scene got corrupted in first place.
EDIT: Corrected the hash

48d0def do not seem to be a valid commit.
And that scene has a custom _editor_icon metadata with the icon embedded, try removing that icon subresource and all references from the tscn file.
I do not know how do you managed to do that without a custom editor or importer.

@eon-s I took the commit from my own project. Correct one is 6b10e3750.
The scene was over a week in the making, I can't really backtrack everything I did there. I will be vigilant for this to re-surface - I actually think I got this problem before, but it was a throw-away scene so I just re-created it.
How do I go about removing _editor_icon? Just edit it out with text editor, or is there an option for it in the Godot editor itself?

With a debug build and the provided Enceladus.tscn file, I get this error:
ERROR: create_from_image: Condition ' p_image.is_null() ' is true.
   At: scene/resources/texture.cpp:190.

When running from the editor I also get:
ERROR: texture_get_data: Condition ' !texture->active ' is true. returned: Ref<Image>()
   At: drivers/gles3/rasterizer_storage_gles3.cpp:1013.
ERROR: texture_get_data: Condition ' !texture->active ' is true. returned: Ref<Image>()
   At: drivers/gles3/rasterizer_storage_gles3.cpp:1013.

I haven't tried a release build, but it's expected that errors in debug builds can lead to crashes in release builds (as less checks are done to increase performance).
To fix your scene, you should be able to do something like this manually:
diff --git a/Enceladus.tscn b/Enceladus.tscn
index f1a4c8b..6925fb0 100644
--- a/Enceladus.tscn
+++ b/Enceladus.tscn
@@ -1,26 +1,4 @@
 [gd_scene load_steps=3 format=2]

-[sub_resource type="Image" id=3]
-
-data = {
-"data": PoolByteArray( 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 45, 59, 0, 82, 91, 121, 0, 83, 91, 121, 0, 83, 91, 121, 0, 82, 91, 121, 0, 40, 45, 59, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 122, 131, 176, 6, 163, 181, 239, 108, 164, 182, 242, 200, 165, 183, 243, 242, 165, 183, 2
43, 242, 164, 182, 242, 200, 163, 181, 239, 108, 122, 131, 176, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 122, 137, 181, 27, 164, 182, 242, 206,
 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 164, 182, 242, 206, 122, 136, 181, 27, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 122, 131, 176, 6, 164, 182, 242, 206, 165, 183, 243, 255, 165, 183, 243, 227, 160, 181, 237, 89, 164, 177, 238, 25, 164, 177, 238, 25, 160, 181, 237, 89, 165,
 183, 243, 227, 165, 183, 243, 255, 164, 182, 242, 206, 122, 131, 176, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 39, 44, 59, 0, 161, 180, 239, 107, 165, 183, 243, 255, 165, 183, 243, 227, 123,
 136, 181, 18, 38, 45, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0, 38, 45, 57, 0, 121, 136, 181, 19, 165, 183, 243, 227, 165, 183, 243, 255, 161, 180, 239, 107, 39, 44, 59, 0, 0, 0, 0, 0, 0, 0, 0, 0, 82
, 91, 121, 0, 164, 182, 243, 198, 165, 183, 243, 255, 160, 180, 237, 89, 38, 45, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 41, 41, 58, 0, 163, 174, 238, 89, 165, 183, 243, 255,
 164, 182, 243, 198, 82, 91, 121, 0, 0, 0, 0, 0, 0, 0, 0, 0, 82, 91, 121, 0, 165, 183, 242, 241, 165, 183, 243, 255, 163, 177, 238, 25, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 163, 177, 238, 25, 165, 183, 243, 255, 165, 183, 242, 241, 82, 91, 121, 0, 0, 0, 0, 0, 0, 0, 0, 0, 82, 91, 121, 0, 165, 183, 242, 241, 165, 183, 243, 255, 158, 180, 241,
23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 162, 176, 237, 24, 165, 183, 243, 255, 165, 183, 242, 241, 82, 91, 121, 0, 0, 0, 0, 0, 0, 0, 0, 0, 82, 91, 121, 0, 164, 182, 243, 198, 165, 183, 243, 255, 155, 178, 236, 87, 35, 43, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 35, 43, 57, 0, 155, 178, 236, 87, 165, 183, 243, 255, 164, 182, 243, 198, 82, 91, 121, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 45, 59, 0, 162, 181, 239, 107, 165, 183, 243, 255, 165, 183, 243, 226, 121, 135, 181, 18, 38, 45, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0, 38, 45, 57, 0, 121, 135, 181, 18, 164, 182, 243, 226, 165, 183, 243, 255, 162, 181, 239, 107, 40, 45, 59, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 118, 133, 177, 7, 164, 182, 242, 206, 165, 183, 243, 255, 165, 183, 243, 227, 160, 181, 237, 89, 164, 177, 238, 25, 164, 177, 238, 25, 160, 181, 237, 89, 165, 183, 243, 227, 165, 183, 243, 255, 164, 182, 242, 206, 118, 133, 177, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 122, 136, 180, 27, 164, 182, 242, 207, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 165, 183, 243, 255, 164, 182, 242, 206, 122, 136, 180, 27, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 122, 131, 176, 6, 163, 181, 239, 108, 164, 182, 242, 200, 165, 183, 243, 242, 165, 183, 243, 242, 164, 182, 242, 200, 163, 181, 239, 108, 122, 131, 176, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 45, 59, 0, 82, 91, 121, 0, 83, 91, 121, 0, 83, 91, 121, 0, 82, 91, 121, 0, 40, 45, 59, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ),
-"format": "RGBA8",
-"height": 16,
-"mipmaps": false,
-"width": 16
-}
-
-[sub_resource type="ImageTexture" id=2]
-
-flags = 0
-storage = 0
-lossy_quality = 0.7
-flags = 0
-image = null
-size = Vector2( 16, 16 )
-
 [node name="Enceladus" type="Node2D"]
-__meta__ = {
-"_editor_icon": SubResource( 2 )
-}

We still need to find out how such invalid metadata could be added, and how to improve error reporting in this case though.

Removing (with a text editor) the meta entry and related sub resources should be enough to recover it.

@willnationsdev Above comment sounds like one of your recent PRs caused this bug.

This is not, however, the root cause. My problem was related to filename case in/sensitivity (of course) somewhere else in the game, this metadata/icon just obfuscated it. You might still want to fix it, but it is not critical (does not actually break the exports).

@akien-mga Oh, interesting. I guess I'll have to look into how that might be happening.

@akien-mga I have a fix for that specific problem. Tested it with my own build, and reproducing the same steps no longer creates the problem in question.

It is generally true that ERROR messages in the editor will crash a release build. This is as far as I understand by design.

I thought we added some code on Windows to trigger warnings when load resources with incorrect case (which works on Windows, but wouldn't work anywhere else).
@lekoder I guess your example shows that it's not working as it should? If you can reproduce a minimal project with the same kind of case mismatch that causes an error on export, that would be great to debug further and improve the error reporting.

@akien-mga There is a warning when filename has different case, but I had a directory with different case, and that is not reported. Minimal reproduction.
I think it would be great if it was interpreted as error and highlighted in the code editor - it's not like the code is going to work on windows (after export) anyway.

There was mention of a dangling Image in the scene file earlier in this Issue. Did the recent editor icon refactoring fix this, or is this still a bug?

What's the status on this issue? I think the original issue has been fixed, are there other points pending that would be worth moving to a new issue?

Re-read and it does seem to me that later comments as of https://github.com/godotengine/godot/issues/21524#issuecomment-416557782 are about a different issue.
#21544 fixed the issue about a creating dangling Image references that raise errors.


Revert [SE-0283] Implement Equatable, Comparable, and Hashable conformance for Tuples

Hopefully I did this right...

@swift-ci Please test

Thanks! Sorry for the back-and-forth.

@swift-ci Please smoke test

@swift-ci Please test

Force-merging to get the revert in place, though someone will have to puzzle out the failures here.

Build failed
Swift Test Linux Platform
Git Sha - 93cc5976c589e9b51e7d81f1388710416e3a6853

Build failed
Swift Test OS X Platform
Git Sha - 93cc5976c589e9b51e7d81f1388710416e3a6853


Add Lando Support

Focusing on Vagrant first, but adding Lando would be goof to happen soon after.
Adding this to the tooling section would be good. Perhaps we could automate this? If not -- at least update documentation for it.
  wfl:
    service: appserver
  install-wfl:
    service: appserver
    cmd: "test ! -d /usr/local/bin/wfl && \
      curl -OL https://github.com/waffle-ops/waffle/releases/latest/download/waffle.phar && \
      chmod +x waffle.phar && \
      mv waffle.phar /usr/local/bin/wfl && \
      wfl list"

Command prefixes were added in v0.0.5-alpha.


Update Qt.gitignore

Qt generates build files for me that are build-Projname-WhateverWhatever so this change continues to support -build- folders as well as others.

:thumbsup:


Camera does not handle position values with Z >= 0

You can try this out in https://avs.auto/playground  Add a position: [0, 0, 200] to the vehicle pose manually and everything disappears.  If you instead set the Z to zero and use the mapOrigin, altitude field it works.

The workaround did not work with continuous frame data, here is what I did in the playground:
// metadata
xvizMetadataBuilder
  .stream('/vehicle_pose')
  .category('pose')

  .stream('/object/tracking_point')
  .category('primitive')
  .type('circle')
  .streamStyle({
    fill_color: '#fb0'
  })

  .stream('/object/shape')
  .category('primitive')
  .type('polygon')
  .streamStyle({
    extruded: true
  })

  .startTime(1000)
  .endTime(1010);

// frame
const timestamp = 1000.6;

xvizBuilder.pose('/vehicle_pose')
  .timestamp(timestamp)
  .mapOrigin(0, 0, 200)
  .orientation(0, 0, 0)
  .position(0, 0, 0);

xvizBuilder.primitive('/object/tracking_point')
  .circle([10, 10, 200])
  .id('object-1');

xvizBuilder.primitive('/object/shape')
  .polygon([[-5, 20, 200], [5, 14, 200], [8, 18, 200]])
  .style({
    fill_color: '#08f',
    height: 2
  })
  .id('object-2');


Wrong warning message when creating pipeline with existing index in OpenSearch

Describe the bug
When I create the pipeline with a index prefix, and the new index is overlapped with an active index in OpenSearch, then it will show me the error message: You have a deleted log pipeline that used this index prefix. If you keep creating this log pipeline will get mixed up..
The pipeline is active, and not deleted.
Expected Behavior

Change the error style popup window to warning style popup window.
Change Oops.. to Warning.
Change the text to It looks like there is an active or deleted pipeline configured with the index you entered. To proceed with creating this new pipeline and sending logs to the same index, please select "Continue Create". If you would like to use a different index prefix instead, please choose "Edit" to update.

Current Behavior
N/A
Reproduction Steps
N/A
Possible Solution
No response
Additional Information/Context
No response
Solution Version
v2.1.0
AWS Region. e.g., us-east-1
No response
Other information
No response

Fixed in v2.1.2


Places autocomplete not loading when IvoryGoogleMapBundle loaded before TwigBundle

I stumbled upon a this when I sorted my bundles in the kernel :)
When You load IvoryGoogleMapBundle before TwigBundle, the "twig.form.resources" parameter gets overwritten (when Twig loads), and places_autoload_widget.html.twig template is ignored when rendering forms. This results in the field being rendered as a plain text field -> no 'javascripts'  template variable printed -> google API not loaded -> maps and places not working.
I suggest moving the template registration to a CompilerPass instead, so as not to rely on TwigBundle being loaded before IvoryGoogleMapBundle.

Thanks for reporting it! It has been fixed in #160 but will only be part of the 3.x version of the bundle.


Remove DEVELOPMENT_TEAM and enable Automatic provisioning style

Frameworks should be set to Automatic ProvisioningStyle so that parent workspaces can control provisioning identites with Xcode 8.
Without this set, using xcodebuild archive will trip up if PROVISIONING_PROFILE_SPECIFIER has been set.

Thanks!


add TRWulfgar's file

created a branch, created a file and made a commit, and opened a pull request

whatever


ITX Commands: SetScale

SetScale/I x #waveX#[0],#waveX#[DimSize(#waveX#, 0)-1],"", '#wave2D#'
SetScale/I y #waveY#[0],#waveY#[DimSize(#waveY#, 0)-1],"", '#wave2D#'

Used in Write ITX (2D w X&Y) as shown below:


Enable branch coverage reporting.

Coverage remained the same at 89.966% when pulling a5af280bacacef2ec68021b7fda7a764f3258119 on coreyfarrell:branch-coverage into 6dddf687d84306ea5d4ff9b13a28dc22282c77e6 on akheron:master.


[Azure] Updated LoadBalancer module to use sovereign client factory.

This PR updates the load balancer testing module to support Azure sovereign clouds (Government, Germany, China, Azure Stack). This behavior is controlled by setting the AZURE_ENVIRONMENT environment variable to the appropriate environment name (as covered in examples/azure/client_factory.md).
Closes #824

@mjyeaney , @yorinasub17 would you please close the PR . it was addressed in #897

Closing as done in #897


[DOC] Add MWE to 3 more functions

PR Description
Please describe the changes proposed in the pull request:

Add MWE for functions/row_to_names, functions/shuffle, functions/round_to_fraction.
Fix #1004
Remove empty file fill_empty.py (leftover from the previous migration)

Resolves #1004 ; Related to #972 .
Aside:
Bugfix for issue 1005 (also relating to the round_to_fraction.py file) will be in another PR, I wanted to keep this PR more focused on the MWE additions.
I'll update the CHANGELOG for 1004 together with the fix for 1005 in that PR.

🚀 Deployed on https://deploy-preview-1006--pyjanitor.netlify.app

@thatlittleboy looks like we have one error that relates to syntax. Here is a direct link to the logs: https://github.com/pyjanitor-devs/pyjanitor/runs/5069210330?check_suite_focus=true#step:4:1617


elli_tcp: cast 'accepted' AFTER TLS handshake succeeded

fix #84

Coverage decreased (-0.03%) to 75.787% when pulling c919553bf1e214df69e564342e95c09e663f73a7 on sg2342:fix_tls_accept_logic into 968afee385f46c053fd46858713261db7dc03af4 on elli-lib:main.

Coverage decreased (-0.03%) to 75.787% when pulling c919553bf1e214df69e564342e95c09e663f73a7 on sg2342:fix_tls_accept_logic into 968afee385f46c053fd46858713261db7dc03af4 on elli-lib:main.

Thanks. This looks good to me. Would you be willing to add a test or two? Ideally they would fail before this patch and succeed after.

Thanks. This looks good to me. Would you be willing to add a test or two? Ideally they would fail before this patch and succeed after.

done.

OTP-20 and older reuse TLS sessions even when the (verify) connect options have changed. Since other successful tests might leave a reusable TLS session, one has to set reuse_sessions false to provoke the CLIENT ALERT needed to trigger the bug.
elli_ssl_tests:acceptor_leak_regression/0 will succeed (on all supported OTP releases) with the fixed elli_tcp accept logic. It will fail (on all supported OTP releases) without the fix.
BTW: rebar3 does start ssl by default which is why the application:start/1 and application:stop/1 calls in elli_ssl_tests are unnecessary. Removing them reduces the error_logger output of elli_ssl_tests
from
=INFO REPORT==== 30-Sep-2020::23:02:01 ===
TLS client: In state certify at ssl_handshake.erl:1293 generated CLIENT ALERT: Fatal - Bad Certificate

=ERROR REPORT==== 30-Sep-2020::23:02:01 ===
Elli request (pid #Port<0.72536>) unexpectedly crashed:
shutdown

=ERROR REPORT==== 30-Sep-2020::23:02:01 ===
Elli request (pid <0.1649.0>) unexpectedly crashed:
{shutdown,{gen_statem,call,[<0.1687.0>,{recv,0,60000},infinity]}}

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
TLS server: In state certify received CLIENT ALERT: Fatal - Bad Certificate

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: ssl
    exited: stopped
    type: temporary

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: public_key
    exited: stopped
    type: temporary

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: crypto
    exited: stopped
    type: temporary

to
=NOTICE REPORT==== 30-Sep-2020::23:21:13.058984 ===
TLS client: In state wait_cert_cr at ssl_handshake.erl:1948 generated CLIENT ALERT: Fatal - Bad Certificate

=NOTICE REPORT==== 30-Sep-2020::23:21:13.059186 ===
TLS server: In state wait_finished received CLIENT ALERT: Fatal - Bad Certificate

BTW: rebar3 does start ssl by default which is why the application:start/1 and application:stop/1 calls in elli_ssl_tests are unnecessary. Removing them reduces the error_logger output of elli_ssl_tests

Maybe we should prefer application:ensure_started/1 and remove the application:stop/1 calls.

I say we merge this and patch the application start/stop shortly after. I'll add this to my Wednesday evening session too heh

This looks good to me, and I've confirmed elli_ssl_tests:acceptor_leak_regression/0 fails on the main branch, and succeeds with c919553bf1e214df69e564342e95c09e663f73a7.
Given that rebar3 starts crypto, asn1, public_key, and ssl, perhaps we ought not bother starting (and stopping) them.
What do you think, @tsloughter?

Using ensure_all_started and not stopping those particular apps is probably a good idea.
I've wanted to move tests to Common Test since I think it has much clearer semantics for all this (and better error messages for where a failure happened in the tests).. but it would be a lot of work probably.

Maybe I'll start with adding a common test suite and over time cases can be moved to it.

Merging this for now then, and we can handle the move to CT in another (series of) PR(s). Thanks, @sg2342!


feat : about

What does this PR do?
-Add the About page
Description of Task to be completed?

How should this be manually tested?
-npm start
What are the relevant Trello Card stories?  Trello Card Item

https://trello.com/c/zt31Unan/40-about-page

Pull Request Type (check one)

[x] Feature
[ ] Bug Fixes
[ ] Chore

Developer Checklist

[ ] New code has been scanned for ESlint issues
[x] I have tested my code locally
[x] I made sure that there are no other pull requests that solve for this issue
[x] My code follows the same structure within the guidelines

Screenshots (if appropriate)

We went with naming folders with small letters, could you change the folder name fro About to about.
Also, I noticed some huge amounts of padding on the mobile view, maybe you want to add some media queries to fix that.
Once those are fixed, it's good to go for me. Good job.

@Easybuoy Changed folder name and made use of media queries. Please check as I am fairly new to media queries. Thanks


rexrov2: 0.1.3-0 in 'melodic/distribution.yaml' [bloom]

Increasing version of package(s) in repository rexrov2 to 0.1.3-0:

upstream repository: https://github.com/uuvsimulator/rexrov2.git
release repository: https://github.com/uuvsimulator/rexrov2-release.git
distro file: melodic/distribution.yaml
bloom version: 0.7.2
previous version for package: null

rexrov2_control

No changes

rexrov2_description
* Fix path to rexrov2_description
  Signed-off-by: Musa Morena Marcusso Manhães<EMAIL_ADDRESS>* Contributors: Musa Morena Marcusso Manhães

rexrov2_gazebo

No changes

@musamarcusso Thanks for the fixups. If you comment after making the fixup commits we'll get a notification and can know to rereview your PR sooner.


SyntaxError: Parse error with gulp-uncss

Hoping someone can offer some ideas on this one. This is one of those 'I wouldn't believe it is i hadn't seen it'
This is on a Windows 7 x64 system with the latest versions of node, npm, gulp and gulp-uncss.
Having used gulp-uncss successfully on different projects, it is now creating a 'SyntaxError: Parse error' when running the gulp script (and I've isolated down to this being the cause).
I've uninstallled / reinstalled, and also updated gulp itself and not sure what to do as the code in the gulpfile is unchanged (from successful uses).
Is there any way to find out what is causing this error? A Google search suggested  this might be related to Phantonjs but no relevant links or anyone with this issue are shown.
I'm not sure how to fix it, when it was not changed since in a working state, and the error doesn't describe where the issue is coming from.
Any help would be greatly appreciated.

Can you paste the relevant lines of your gulpfile? Is this an issue of needing to add .on('error', console.log) to get better error messages from gulp pipelines?

Hi. Here's the part of the script (two version, tried both, exactly same results):
.pipe(uncss({ 	html: [sitepath + '/layouts/**/*.html'], 	ignore: [/--/,/.in/] 	}, function(err, output) { 			if (err) { 				gutil.log(err) 			} 	} ))
and
.pipe(uncss({ 	html: [sitepath + '/layouts/**/*.html'], 	ignore: [/--/,/.in/] 	} ))
I have been trying to think what could have change from when it was working. The script hasn't (first version), i hadn't updated any node or gulp modules or plug-ins. Of course other things changed (the html and css files it is using), but all other pre-processing is working ok (css minification, useref) which happen after in this script.
How would i best add the .on('error' ...... here? I can try this.

Add it to the just before or just after the .pipe(...). I'm a bit unsure on the gulp semantics, myself.

I tried it at the start and end of the pipe. The script ran (so i guess i put the code in ok) but the same error without more info showed

Sorry it didn't help.
Without a repro case, not much to go on. My only remaining suggestion is to start chucking out large chunks of HTML/CSS until the error goes away, and then binary-tree search adding/removing chunks until you figure out what's triggering the error and have a small repro case.

I appreciate it's a bit of a strange one.
I'm just testing one other thing. One change I made previously was to use relative rather than absolute paths. Although it worked ok after change to a relative path before, i've just tried one test with absolute path and it may have worked. I mean this if it needs more expanation:
.pipe(uncss({ html: [sitepath +
i had sitepath simply as 'site' (the relative location to where the gulp sccript was called from, which I'm using throughout the gulp script),   now trying the C:.........\site  instead.
Does this highlight some obvious error in how I might be using relative paths?
(I read somewhere that uncss performed better with relative paths)

I don't have access to a windows box to test with.
One possibility: We use npm's glob.sync(), and according to the documentation on https://github.com/isaacs/node-glob , it has some issues regarding backslashes. Not sure how that would play out in your relative vs absolute scenario.
Without a repro case, I suspect you're going to have to dig into your node_modules/uncss/src/uncss.js' getHTML or other functions to add logging and figure out exactly what's going on.

Ok, I'll keep trying and report back

To update, I found the part of the HTML files that was causing the error. I don't why this is the case though.
This is it (id details replaced with ####):
<div id="wrapper" class="content">
    <script src="http://www.booking.com/general.html?tmpl=bookit;aid=#####;lang=en;hotel_id=######;hotel_cc1=en;hotel_page=#######"></script>
</div>

If I change the SRC to some local js file, the error is not shown. So it's the SRC as is causing it.
Two potential bugs here are 1) that the syntax error is preventing uncss working correctly (it seems to be stopping at that point).  2)  that this type of use of a script tag is not so uncommon

Uncss uses the phantom web browser to render web pages and figure out which css selectors are actually used. Yeah, a javascript error could interrupt things, same as a normal web page flow.
As far as why the above script src is giving you a Parse Error, it should support remote js without any issues. I suspect there's a problem with the actual contents of the js file, that the phantom (webkit) browser isn't parsing.
More thoughts for you:

Are you sure the file you are including is a js file? It appears to be general.html, which is suspicious.
Are you sure the js file you are including is valid js without parse errors? You didn't include the ### numbers, so I can't verify for myself.
Have you tried downloading the booking.com js file, and referencing that locally instead of remotely? Does it still give the same error?

@simplyeffectiveweb ping?

@seffw Is this still an issue for you?

Sorry for late reply. I've been busy with other things. I'll try to re-test this soon and willl report back

@seffw ping?

@seffw ping?

@seffw ping?

@mikelambert This looks abandoned IMO, can you close?


Update data-store-decision-tree.md

Updating to include ANF and specialized storage.

Hi @EdPrice-MSFT - This pull request was opened in the public repo. Would you like to close it and make the update in the private repo instead? Or we can merge it here as a one-off.


Support for mac silicon(M1) native library

org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64
at org.xerial.snappy.SnappyLoader.findNativeLibrary(SnappyLoader.java:299) ~[snappy-java-<IP_ADDRESS>.jar:na]
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:163) ~[snappy-java-<IP_ADDRESS>.jar:na]

Nvmd just saw the commit looks like just need to update my jars


Implement _ (underscore) in the REPL

In CPython:
>>> 1
1
>>> _
1
>>>

In RustPython:
>>>>> 1
1
>>>>> _
Traceback (most recent call last):
  File "<stdin>", line 0, in <module>
NameError: name '_' is not defined
>>>>>

This is pretty interesting, here's some other things to take into account if anyone wants to implement this:
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> _
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '_' is not defined
>>> 9
9
>>> _
9
>>> _; 8; _
9
8
8

I'm trying this now

Solved (at least partially, as per https://github.com/RustPython/RustPython/issues/921) in https://github.com/RustPython/RustPython/pull/912,


reassignment of a const variable

Screenshots

Describe the bug
Hi, just wanted to point out a small issue in tests/clockSkew.js.
There is a const defined variable "activityObservers" which is then reassigned. See screenshot.
Thanks!
[Bug]

@laghim thanks for the issue report. Would you be open to submitting a PR fixing this?

hi @a-b-r-o-w-n, sure I will open a PR and fix this. thanks!


[Bug]: Remounting of vscode button before the container session is started causes internal error HTTP 500 to /api/vscode-url

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Describe the bug and reproduction steps
The VSCode button should be disabled before the workspace is fully initialized and ready.
However, it will pre-maturely send request to /api/vscode-url if you switch tab to Jupyter then back to Workspace
Repro:

Ask the agent to 'do nothing' to trigger a workspace
Immediately switch to the Jupyter tab
Switch back to the Workspace tab, see network API call to backend /api/vscode-url that causes 500 internal server error due to container not ready yet

INFO:     <IP_ADDRESS>:48382 - "GET /api/vscode-url HTTP/1.1" 500 Internal Server Error
ERROR:    Exception in ASGI application

This is might be related to https://github.com/All-Hands-AI/OpenHands/pull/5544
OpenHands Installation
Docker command in README
OpenHands Version
No response
Operating System
None
Logs, Errors, Screenshots, and Additional Context
No response

Seen a couple of issues where interacting with OpenHands before things are initialized is causing issues. Might be worth it to just not allow interacting with anything until it's fully initalized.

I agree, until the container is past the ready state, we shouldn't let any of the APIs hit against the runtime


Add support for registering webpack build dependencies

This PR contains a:

[ ] bugfix
[x] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case
Allow plugins to register build dependencies to properly handle webpack 5 persistent cache invalidation.
Breaking Changes
None.
Additional Info
N/A

Okay I added a test for this

Thanks


1-2.5-5 scale

This is actually the same as the 1-2-5 series scale that is already implemented.


FR - A way to quickly glance spells and see their saves

Playing a psychic and trying to find my Will spells is a bit annoying, I keep having to open each spell individually
Something like this but better done (?)

I can see Defense being a valid column on the sheet


Distribution quartiles don't have the expected location on the graph

The question. The distribution is symmetrical when it's on the left side of the graph:

but becomes less so the more I move it towards the right:

Can replicate it on this question too.
left:

right:


[Question] run action after sending sms

Hello,
Thanks for this awesome package :)
Please I'm facing an issue when I call an api after each sms sent (success or failed), the sms sent but the api point never called,
Here my code :
 for (var sms in pendingSMS) {
        try {
          // Send SMS
          bool sent = await _sendSingleSMS(
            sms: sms,
            subscriptionId: defaultSim.subscriptionId,
          );

          // Update status based on send result
          if (sent) {
            await _apiService.updateSMSStatus(sms.id, 'sent');
          } else {
            await _apiService.updateSMSStatus(sms.id, 'failed');
          }
        } catch (e) {
          print('Failed to send SMS to ${sms.phone}: $e');
          // Ensure status update happens even if sending fails
          await _apiService.updateSMSStatus(sms.id, 'failed');
          // Don't rethrow here to allow processing of remaining SMS
        }
      }
    } catch (e) {
      print('Error in processing SMS: $e');
      rethrow;
    }

What I'm missing ?
Thanks :)

Hey, Thank you for using the package!
To better assist you, could you please provide a minimal reproducible example that I can run to investigate the issue? It’s a bit challenging to deduce the behavior from the code snippet shared, as the implementations are not included

Hi ! Thanks for quick reply,
Okey so for _sendSingleSMS : I'm using flutter_sim_data: ^1.0.5
and updateSMSStatus: it's my own server api point.
So what I'm doing here :
Get pending sms list from my api server
Then send sms for each item using sm_data package
and finally update the sms status using api server

Hey, so since I don’t have the exact implementation of _sendSingleSMS, my guess is that the issue might be due to the sendSMS function. While it has a return type of Future<bool?>, it may not be returning the actual status of the sent SMS at the moment.
This issue has already been addressed in an open PR #4 , but I haven’t had the chance to review and merge it yet. I’ll prioritize it and get it resolved as soon as possible.

Here's it :
Future<bool> _sendSingleSMS({
    required SMS sms,
    required int subscriptionId,
  }) async {
    try {
      await _simDataPlugin.sendSMS(
        phoneNumber: sms.phone,
        message: sms.message,
        subId: subscriptionId,
      );
      return true;
    } catch (e) {
      print('SMS sending failed: $e');
      return false;
    }
  }

I mean if we could have a callback after sending sms, something like this :
 await _simDataPlugin.sendSMS(
        phoneNumber: sms.phone,
        message: sms.message,
        subId: subscriptionId,
      )->then(
      // Do something
      );


chore(execution): move compiled class fetch upwards in deploy call stack

This change is

Codecov Report
Attention: Patch coverage is 85.71429% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 73.08%. Comparing base (38298d2) to head (9d30059).
Report is 13 commits behind head on main.

Files
Patch %
Lines

...lockifier/src/execution/deprecated_syscalls/mod.rs
0.00%
0 Missing and 1 partial :warning:

crates/blockifier/src/execution/syscalls/mod.rs
0.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1674      +/-   ##
==========================================
- Coverage   73.08%   73.08%   -0.01%
==========================================
  Files          59       59
  Lines        8547     8552       +5
  Branches     8547     8552       +5
==========================================
+ Hits         6247     6250       +3
  Misses       1809     1809
- Partials      491      493       +2

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


No such module 'Alamofire'

ℹ Please fill out this template when filing an issue.
All lines beginning with an ℹ symbol instruct you with what info we expect. You can delete those lines once you've filled in the info.
Per our *CONTRIBUTING guidelines, we use GitHub for
bugs and feature requests, not general support. Other issues should be opened on Stack Overflow with the tag alamofire.
Please remove this line and everything above it before submitting.

[ ] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?
ℹ Please replace this with what you did.
What did you expect to happen?
ℹ Please replace this with what you expected to happen.
What happened instead?
ℹ Please replace this with of what happened instead.
Alamofire Environment
Alamofire version:
Xcode version:
Swift version:
Platform(s) running Alamofire:
macOS version running Xcode:
Demo Project
ℹ Please link to or upload a project we can download that reproduces the issue.

cmd + b , then import it make sure working on the  workspace file

Sorry, we use our GitHub project for bug reports and feature requests. In the future, you should open questions like this on Stack Overflow.
Cheers. 🍻

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


Improve the Postman collection for IDP Rest API

Is your suggestion related to a missing or misleading document? Please describe.
The samples are incomplete in the existing postman collection and misleading.
ex: Some sample values are not defined, defined sample values are not meaningful

Describe the improvement

Update the postman collection with proper sample values.

Closing this since templates mgt has been deprecated now. Please reopen if necessary.


Handle log indenting in metaflow

Logs might have leading whitespaces which are currently being removed from the user-visible logs on console.
Addresses #223

lgtm!

lgtm


Make sure OSX ARM Migrator restarts

Comment:
#25 was closed for rerun, and I'm waiting for it to reopen. However it's been suspiciously long, so it might need follow-up.

I wonder why #33 took two weeks!? :man_shrugging:


Still depending on Growatt servers?

So, the Growatt servers went offline for a while today.  During that time Grott can't forward information, and if it can't forward to Growatt it won't push to MQTT either.  Anyone worked out  how to get around that?  Someone asked the same question on the original grott (https://github.com/johanmeijer/grott/issues/347) but no answers there either.

Yeah I can't work out why that happens either.
I think there's a way of making grott 'fake' responses from growatt but I haven't seen it in action yet. I've been focussing on other things but this is on my list of things to investigate.
If you find out how to solve it, please let me know.
C

Also getting that error.
s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started [17:30:07] INFO: Preparing to start... 	 ********************************************************************************** 	 - Grott - libscrc not installed, no CRC checking only record validation on length! 	 ********************************************************************************** Grott Growatt logging monitor : 2.7.8 Grott process configuration file Grott process environmental variables 	Pulled 'ginvtype=sph' from the environment 	Pulled 'ginvtypemap={"NLCUCD700T":"sph"}' from the environment 	Pulled 'gnomqtt=true' from the environment 	Pulled 'gextension=True' from the environment 	Pulled 'gextname=grott_ha' from the environment 	Pulled 'gextvar={"ha_mqtt_host": "core-mosquitto", "ha_mqtt_port": "1883", "ha_mqtt_user": "addons", "ha_mqtt_password": "Zeireivoopee3sie1ahruphaesooChah7iyahDooxei9eekeNg4Iizegi9saexoh", "ha_mqtt_retain": False}' from the environment Grott override settings if set in commandline Grott process json layout files Grott proxy mode started 	 ********************************************************************************** 	 - Grott - libscrc not installed, no CRC checking only record validation on length! 	 ********************************************************************************** Hostname : 8ce4abae-grott-current IP :  <IP_ADDRESS> , port :  5279  	 - Growatt packet received: 		  <socket.socket fd=4, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 33670), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=4, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 33670), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=4, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 33670), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=4, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 40232), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=4, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 40232), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=6, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 54032), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=6, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 54032), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=6, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 54032), raddr=('<IP_ADDRESS>', 5279)> 	 - Growatt packet received: 		  <socket.socket fd=5, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 5279), raddr=('<IP_ADDRESS>', 31683)> 	 - Grott - grottproxy - Invalid data record received, processing stopped for this record 	 - Growatt packet received: 		  <socket.socket fd=6, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 48262), raddr=('<IP_ADDRESS>', 5279)> 	 - Grott - grottproxy - Invalid data record received, processing stopped for this record 	 - Growatt packet received: 		  <socket.socket fd=6, family=2, type=1, proto=0, laddr=('<IP_ADDRESS>', 48262), raddr=('<IP_ADDRESS>', 5279)> 	 - Grott - grottproxy forward error :  [Errno 110] Operation timed out 	 - Grott - grottproxy forward error :  [Errno 110] Operation timed out
Inversor show as "LOST" on the server.growatt.com page.
Even if i change the datalogger to the default it's the same, maybe servers arent working yet...

Yup, I'm LOST too at the moment!

Same here. I haven't looked at the code, but maybe because it times out (and hence an exception is thrown), no data is put in MQTT? Sending to Growatt servers should be the very last step and just fail gracefully, right?

Just to be clear, I'm more than happy to have this conversation here, but the fix for it will have to come from the grott repo itself so we should probably log a bug there and see what the response is.
The intention of switching to Grott was to get away from issues with the server, it seems like we're still going to have problems at present though!
There must be some way that grott can 'spoof' a response from the Growatt servers if this ever happens so that data can continue to flow.

https://github.com/johanmeijer/grott/issues/347

Just to be clear, I'm more than happy to have this conversation here, but the fix for it will have to come from the grott repo itself so we should probably log a bug there and see what the response is.
The intention of switching to Grott was to get away from issues with the server, it seems like we're still going to have problems at present though!
There must be some way that grott can 'spoof' a response from the Growatt servers if this ever happens so that data can continue to flow.

Agreed the issue doesn't like here, but this group seems more chatty :)
That said, it seems to have picked up some traction now in the right place (either grott or the grott/ha addon) so we can probably just close this one.

Just to be clear, I'm more than happy to have this conversation here, but the fix for it will have to come from the grott repo itself so we should probably log a bug there and see what the response is.
The intention of switching to Grott was to get away from issues with the server, it seems like we're still going to have problems at present though!
There must be some way that grott can 'spoof' a response from the Growatt servers if this ever happens so that data can continue to flow.

Agreed the issue doesn't like here, but this group seems more chatty :)
That said, it seems to have picked up some traction now in the right place (either grott or the grott/ha addon) so we can probably just close this one.

Do you have a link to the HA addon chat around this as well so I can keep an eye on it?
I'm hoping to spend a bit of time next week looking at a way of running the grott server and the method that uploads to growatt server in parallel and only using the grott server when the growatt servers are unavailable. I don't want to duplicate other people's efforts though.

Actually there's not one on there at the moment.  Given he keeps pretty up to date with the base grott, I think letting that get fixed first (if that's where the fix needs to be) is probably best, then with luck it'll make it to the add on too).
https://github.com/egguy/grott-home-assistant-add-on/issues

Ok cool. In my opinion (and what I'm hoping to try and implement and then make a PR to the Grott repo) is that there should be a feature flag/toggle in Grott to allow people to choose to have a "fallback" mode where if Growatt servers are unavailable it uses the Grott Server instead.

With that approach, I guess there will be a gap in the data that eventually makes it back to the Growatt servers although I'm not sure if that's an issue or not.  Grott doesn't buffer data, only the inverter if my understanding is correct.  So the inverter buffers the data until it gets a response (either from Growatt or GrottServer).  If Growatt is down, then when it comes back up it won't recover anything it missed
Perhaps a better fallback would be to have Grott still publish to MQTT, although if the inverter isn't getting a response then I'm not sure if the format of the supplied data looks different.  It's a shame Growatt don't publish better information on their protocol, but I suppose that's proprietary and they don't want to be responsible for people blowing up their equipment :)

From the chat with Johan yesterday on the grott side, the wifi dongle/shinelan box has to have some from of response in order to publish data, therefore grott server would have to be in the loop to respond for the data to keep flowing. It's either that, or no data anywhere.
From my experience the 'buffered data' never actually gets displayed in the growatt site/app anyway, so I've never really missed it. I just like the convenience of the app on my phone to be able to look at (when it's working).
Ultimately I need to have a play and work out what's actually possible. The Grott codebase is not the most friendly thing to navigate through.

Given this is being discussed on the grott pages (which is where the conversation belongs) I'll close this one :)


AAD-Domain shall be uppercase

Using Beeline on a client, connecting to a HDInsight Enterprise Security Package (ESP) cluster over an Azure Virtual Network: -u 'jdbc:hive2://<headnode-FQDN>:10001/default;principal=hive/_HOST@<AAD-Domain>;auth-kerberos;transportMode=http' -n <username>
Please add one note:The AAD-Domain shall use uppercase otherwise the credential can not be found. You can check /etc/krb5.conf for the realms.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 24986a8c-db21-cf34-1db6-d63936118bc8
Version Independent ID: 43b24d59-ba56-c4ba-cac2-4b2b58b725d3
Content: Use Apache Beeline with Apache Hive - Azure HDInsight
Content Source: articles/hdinsight/hadoop/apache-hadoop-use-hive-beeline.md
Service: hdinsight
GitHub Login: @hrasheed-msft
Microsoft Alias: hrasheed

@anssenfang1 Thank you for your feedback . We will investigate and update this thread further.

@anssenfang1 Thanks for the feedback! I have assigned the issue to the content author to review further and update the document as appropriate.

@anssenfang1
Thanks for the suggestion. When you see a minor edit, you may click the edit link and the pencil icon to type in the proposal to notify us. That would help us optimize a lot. Thanks, Jason


Add Docker

Since I run everything in Docker and wanted to give this another try, I fished out my old files and got this to a state which is working - at least on my Raspberry Pi 4.
The snippets in the RECIPES.md (should? - not tested it) work as a manual and effortful way to get some (any) version running. This PR uses the checked out repo state, so other branches, etc. can be run inside Docker.

Thank you! Would you be able to put this in a recipes/docker directory and update the RECIPES.md to reference this easier way to set up?

Thank you 🙂


Move to std::future::Future and Tokio 0.2 to support async/await

As discussed in Discord, this is a rebased and consolidated version of all of the work to move Rusoto to Tokio 0.2 and std::future::Future along with async/await support. All of the tests are working on MacOS, though I haven't run the integration tests directly against AWS yet.
A few notes on the process I used to get here:

Each crate had changes identified across the relevant pull requests and @iliana's merged branch, and they were reapplied in a single commit for each crate.
Authorship has been assigned to the authors who originally did the work, but via Co-authored-by tags on each of the single commits. This turns out primarily to be @dbcfd, @bcmcmill and @iliana.
All services were regenerated after addressing some of the issues in the code generator. Generation is now clean.
Wherever additional work was required to make more recent contributions compile or behave correctly, I've done so.
I've started (but not completed) fixing all lint warnings thrown up by Clippy. Some of these in particular appear to represent real bugs in the core library (particularly replacing for chunk in body.next().await with while let Some(chunk) = body.next().await in rusoto/credential/src/request.rs). Some others were noise and have been disabled via attributes to avoid complicating code unnecessarily to appease the linter.
All versions have been updated to 0.50.0 - in order to provide something very visually different from the current version number to verify correctness. This was done in a single commit and can easily be changed to 0.43.0 if this is more desirable.

There are however a few things which are not finished at this point:

[x] Some of the custom code in STS has not yet been updated for async and is currently commented out to avoid compilation errors in the meantime.
[x] README files have not been updated yet, though documentation tests have
[ ] ~Remaining clippy lints need either addressing or silencing.~
[x] Various new and outdated services are listed by the check function in service_crategen which need addressing.

I hope to look at some more of these over the next day or so.
Proposed CHANGELOG entries

Update all futures to std::future::Future, adding support for async and await usage.
Upgrade dependencies to Tokio 0.2, Futures 0.3 and associated libraries.

I think this is ready to go now. The CI issues do not look easily fixable without better access to the ADO account in which they are running (which I understand to be the original authors?), and GitHub Actions looks like a nonstarter for Windows unless we can self-host runners somehow, since the disk space there is not sufficient.

The CI failure is a missing crate in the workspace Cargo.toml:
error: current package believes it's in a workspace when it's not:
current:   /home/vsts/work/1/s/rusoto/services/forecast/Cargo.toml
workspace: /home/vsts/work/1/s/Cargo.toml

this may be fixable by adding `rusoto/services/forecast` to the `workspace.members` array of the manifest located at: /home/vsts/work/1/s/Cargo.toml

CI has been passing since #1670, so you may need to rebase/merge that in.

Hi @swarmer! Thanks for looking over this. I'll take a pass at some more cleanup work soon.

Ok, I've rebased on top of the latest changes to CI, so let's see how this goes. I'll wait to see that until addressing the other issues here.

In order to get this landed, my approach for code generation issues with new services is to remove them where there are issues, and follow up with new PRs once each individual issue is resolved. Currently, there are problems with:

[ ] pinpoint - generates code which gives a very strange compiler error (more to follow)
[ ] wafv2 - generates a recursive type about which the compiler complains

There may be some others too (pending CI since my current temporary laptop is even slower!)

(Maintainer note: I'm fine with dropping service crates for this merge as long as we open an issue and treat that as a blocker for 0.43.0. But I don't have a problem with doing a beta release without those crates.)

@iliana It's worth noting that the dropped crates were all added as part of PR anyway, nothing that was in 0.42.0 is dropped from what I can tell.

Pushed ea7e190 to fix skeptic tests.

11225f5 fixes the without_signature integration test.
Next up:
     Running target/debug/deps/elastictranscoder-b8f330228f4a53c3

running 7 tests
test list_jobs_by_status ... FAILED
test list_pipelines ... FAILED
test read_preset ... FAILED
test delete_preset ... FAILED
test create_preset ... FAILED
test list_presets ... FAILED
thread panicked while panicking. aborting.
error: test failed, to rerun pass '--test elastictranscoder'

Caused by:
  process didn't exit successfully: `/home/fedora/rusoto/integration_tests/target/debug/deps/elastictranscoder-b8f330228f4a53c3` (signal: 4, SIGILL: illegal instruction)

As of afa3a3a all integration tests pass for me.
We need to look into the Semaphore CI failure; it appears something is now wrong when talking to Ceph.
I'm debating whether I disable the Semaphore tests that now have issues temporarily and build a beta, creating issues to re-enable those as blockers for a final release.

The Ceph (and MinIO) tests were failing for the same reason the S3 tests were locally. The commit message for ca192de explains setting --test-threads 1, and I'll open an issue to track fixing that.
Assuming we win the CI-doesn't-time-out lottery I will merge this :)

Thank you so much @jen20 @dbcfd @bcmcmill!!

@iliana Thank you so much for this!! Thank you as well for all of the other work you put into this project.


Custom tab file support

There are (edit: no longer) two commits here, which are best reviewed independently.
The first fixes a slew of issues that flake8 complained about when I opened wordnet.py. Besides the redundant import, I believe that all the changes are either outright, objective PEP8 violations or at least arguably PEP8 violations (some of the stuff in PEP8 is a little woolly and not all of pycodestyle's linting rules 100% match up with the wording of PEP8) and that as such fixing these is consistent with the contributing guidelines. Regardless, it made my editor not throw so many errors in my face, which made the next commit easier to write. :) is already merged via #1633.
The second provides a method for telling nltk.corpus.wordnet to read a custom tab file and expose its data, resolving https://github.com/nltk/nltk/issues/1620
I have not written any tests for the new functionality, nor have I run any existing tests, but I have tested this briefly at my shell (in both Python 3.5 and Python 2.7), as shown below:
>>> import nltk
>>> nltk.corpus.wordnet.use_tab_file_for_language(open('/home/krzana/Downloads/data/wikt/wn-wikt-deu.tab'), 'deu')
>>> nltk.corpus.wordnet.synsets('monkey')[0].lemmas(lang='deu')
[Lemma('monkey.n.01.Affe')]
>>> nltk.corpus.wordnet.synsets('monkey')[0].lemmas(lang='fra')
[Lemma('monkey.n.01.singe')]

@ExplodingCabbage – it's hard to process these two commits at the same time. The first is important housekeeping, and the second is a significant enhancement that deserves some discussion first, or at least, the opportunity for discussion. Could I trouble you to submit this as two PRs? The first I'll merge right away, and the second I'll write to nltk-dev to invite comment first (or you could write). Thanks very much.

Could I trouble you to submit this as two PRs?

Done. New PR at https://github.com/nltk/nltk/pull/1633

the second I'll write to nltk-dev to invite comment first (or you could write)

I'm not familiar with nltk-dev, so if you could do this, I'd appreciate it.

Thanks @ExplodingCabbage – I'm happy to post to nltk-dev about the PR for extending the functionality of wordnet.

Thanks.
I've updated the first post here and have also swapped to target branch away from and back to develop to trigger GitHub to update the overall diff and commit history here to reflect the fact that  c95624a is now merged. (The merge itself didn't trigger such an update, which is a long-standing GitHub bug.)

I posted to nltk-dev last week. Will leave it a few more days before going ahead.

@fcbond any suggestions?

Sorry for not coming to this conversation when invited months ago.
Currently there are two things strange to me about this:

one is the requirement that a 3-letter language code be used, rather than allowing the user to trial arbitrary variations on a lexicon (why not?)
the other is that the data is loaded immediately on registration. Should we instead have a register_language function, and the data be loaded dynamically as for other languages? This allows the registration to be performed as a preamble, even if it lands up not being used...

the requirement that a 3-letter language code be used, rather than allowing the user to trial arbitrary variations on a lexicon (why not?)

Users who are willing to be slow can just swap out tab files between calls to whatever other functions they're using, and users who are willing to be hacky can put in a made-up language code if they want to use different lemma sets for the same language side by side. I guess in principle we might want to support that flow through a fast, non-hacky means, but that would mean doing one of these two things:

Changing all the pre-existing functions in the module that take a lang argument to instead take some other sort of identifier. This would be a significant backwards-incompatible change (since users of the library might be calling those methods use keyword arguments).
Changing all those functions to take an additional argument called variant or something like that, defaulting to None.

(Both approaches would need documentation explaining the meaning and intended usage of this new argument.)
The first option seems like a bad idea - we'd be making the API for the most common use case more confusing that it needs to be, and breaking backwards compatibility at the same time, all avoidably. The second approach I have no objection to, but it's a whole additional feature on top of what I've done here that I've personally got no interest in building.

the other is that the data is loaded immediately on registration. Should we instead have a register_language function, and the data be loaded dynamically as for other languages? This allows the registration to be performed as a preamble, even if it lands up not being used...

I also wouldn't object to this. It's not obviously the right approach, though - loading a new tab file takes a small fraction of a second on even a modest modern machine, and making the loading lazy means deferring detecting any errors in the tab file until usage time, meaning a user of the library will see an exception when they call some non-loading-related method like wn.lemmas() rather than at the time of loading their tab file. There's a trade-off between a tiny performance consideration and a similarly-tiny ease-of-debugging consideration, both of which can be easily worked around by a user of the library. I have no real preference one way or the other.


Can't create new file on folders via ftp

Last week i can create new files via ftp but now i click to add file and nothing happen.

@OmarPinedaD What platform are you using?

Hi @jimmaaay, its in atom.io

I already saw that the problem is not with Remote FTP, the problem is with some themes for Atom.io do not let you see the file creation window or folder, an apology


Create mymail.txt

Create mymail.txt

@monfee I am sorry, the domain mymail.tstc.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).

@monfee I am sorry, the domain mymail.tstc.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


update-child-modules is doing more than I wish...

Hello!
I have a maven project with submodules:
A 1.0.0

B 1.1.0

B-one 1.1.0

B-two 1.1.0

B-three 1.1.0

C 1.1.1

C-one 1.1.1

C-two 1.1.1

All sub-modules of level 3 have the same version than its parent, for example version of module B-two is the same than its parent B.
If I change the version of my root project A to 2.0.0 and I run the command mvn versions:update-child-modules -DallowSnapshots=true from the root project then the version of the parent of the 3rd-level modules is updated: version of the C-one parent becomes 2.0.0!!
But that is not what I wish, I just want to update the version of artifact A and its direct children = modules of 2nd level.
Help! :)
Thanks. Chris.

Taken a look on http://www.mojohaus.org/versions-maven-plugin/update-parent-mojo.html ? Best would be you make an example project on Github and describe what you've done and then what you like to see...a concrete project is better than describing it in a long abstract...

I understand the issue, mainly because i'm hitting it as well
Say I have 3 layers of parent inheritance: A, B, and C
A will be an aggregate pom
A pom.xml
  <groupId>com</groupId>
    <artifactId>A</artifactId>
    <version>3.0.0</version>
    <modules>
       <module>B1</module>
        <module>B2</module>
        <module>B3</module>
    </modules>

B1 pom.xml
  <parent>
        <groupId>com</groupId>
    <artifactId>A</artifactId>
    <version>3.0.0-SNAPSHOT</version>
    </parent>

  <groupId>com</groupId>
     <artifactId>B1</artifactId>
     <version>1.0.0-SNAPSHOT</version>

    <modules>
         <module>C1</module>
        <module>C2</module>
         <module>C3</module>
     </modules>

C1 pom.xml
     <parent>
         <groupId>com</groupId>
   <artifactId>B1</artifactId>
    <version>1.0.0-SNAPSHOT</version>
     </parent>

Now if i  execute this goal on the A pom.xml, not only will it update the Parent of B1 pom.xml (which is good, because B1's parent is A, and makes sense since the Group and Artifact match
BUT
it will also update the parent of C1's pom.xml, which is BAD, as C1's parent should not jump to 3.0.0, as C1's parent is not A, it's B1.
Basically, this goal is blindly setting all parents to whatever is in A, instead of actually checking if a submodules parent is that of what's in the aggregate pom.

I think i found the issue, i also have some additional unit tests created.
I'll attempt to push them up for review. Need to get my company's OK first however.

@DiJu519 Do you have the Ok ?

Still waiting.
On Fri, Dec 1, 2017 at 2:07 PM, Karl Heinz Marbaise <
<EMAIL_ADDRESS>wrote:

@DiJu519 https://github.com/diju519 Do you have the Ok ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mojohaus/versions-maven-plugin/issues/190#issuecomment-348585696,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4BBC1ZcwODxDJ9UCOYRhWLP8aLMNcMks5s8E5_gaJpZM4Obmjw
.

Ok. Thanks for the fast feedback.

See: https://github.com/mojohaus/versions-maven-plugin/issues/312#issuecomment-472498993


Add support for new lines

New lines are currently not respected in output. Consider the following example
consolePanel.log('This\nis\na\nmulti-line\nstring');

Actual output:
This\nis\na\nmulti-line\nstring

Expected output:
This
is
a
multi-line
string

Please ignore, my string contained \n-Strings, not line-breaks


Standard emoji set is several years out of date

In the early days of Zulip, it included all the standard emojis by default. As far as I can tell, the standard set of zulip emojis is now several years out of date from standard emojis on other platforms. I would love to see the emojis refreshed so I can express complex emotions like 🥑 , 🛶 , 🥃 , 🥇 , etc.

@akaptur thanks for the report!  This is actually already in progress.  It turns out that emoji is one of the most complicated technical systems around.
We actually now have the images in place for this, it's just the data that needs to be updated.
@HarshitOnGitHub I think this is caused by the fact that emoji-map.json doesn't have newer emojis, and we haven't flipped to the newer data set yet.  I'm not sure there's an easy fix until we can finish the sprite sheet migration, though.

@zulipbot claim


net6.0 support and fixes

A couple of changes, mostly "code sugar" style changes.
Supported Frameworks net472 & the latest LTS net6.0.
Added strong name signing (important!)
Fixed ToString conversion on currentculture & invariantculture systems.

Thank you for submitting this PR. I'm reviewing it now.


[Misc]: Missing cu118 wheels for 0.6.2 release

Hello,
For version 0.6.2, the cu118 wheels are not available on the release page:
0.6.2 release page
While 0.6.1.post2 has them:
0.6.1.post2 release page
Are you planning on continuing to release those wheels or should we start building vllm+cu118 from source?

I'm wondering if it's related to the failures in the Create Release action?

Yes, I think its this build specifically : https://github.com/vllm-project/vllm/actions/runs/11041663331/job/30672417507


Android non-biometry support + ios localization

thanks, looks good to me 👍
i've just renamed androidBiometryOnly to androidBiometricOnly and rebased on master.
merge

fyi, i've encountered two problems

I forgot that iOS and MacOS uses the same implementation, so the MacOS version crashed because it was also looking for iosPromptInfo. I'm now simply passing the same prompt info to MacOS as well. https://github.com/authpass/biometric_storage/commit/acdf6eff8a3efbca202696f8435f0ea250328577
To keep the same behavior i've changed the default for androidMetricOnly to true. I still don't quite understand if it should be completely customizable (ie. also let users change weak/strong) but anyway. at least this way the old behavior stays the same.


CI: Update first-party GitHub Actions

Description

CI: Update first-party GitHub Actions
Update first-party GitHub Actions from v2/v3 to v4. This should reduce warnings on CI.
Motivation and Context

Want less warnings on CI to see what really needs updated/fixed.
How Has This Been Tested?

It hasn't.
Types of changes

Tweak (non-breaking change to improve existing functionality)

Checklist:

[x] My code has been run through clang-format.
[x] I have read the contributing document.
[x] My code is not on the master branch.
[ ] The code has been tested.
[x] All commit messages are properly formatted and commits squashed where appropriate.
[x] I have included updates to all appropriate documentation.

I ran a test run on my fork's master branch and this seemed to go fine.


TimesNet about classification job

What's the "pred_len" meaning in TimesBlock ? Why inputs of TimesBlock are padded to length of "seq_len + pred_len"？( not seq_len)

Hi, we have unified all the five tasks in one code base. Pred_len is for the forecasting task, which means the length of predicted future. In the classification problem,  pred_len is set as 0 (line 25 of https://github.com/thuml/Time-Series-Library/blob/main/exp/exp_classification.py).


Does this repo fix the bug from "WINDOW ATTENTION IS BUGGED" ?

Hi,
Beside Hiera paper I have also read  WINDOW ATTENTION IS BUGGED:
HOW NOT TO INTERPOLATE POSITION EMBEDDINGS . Does this repository fix this issue ? Thanks

Unfortunately, this repo does not. However the SAM2 github does have it:
https://github.com/facebookresearch/segment-anything-2/blob/7e1596c0b6462eb1d1ba7e1492430fed95023598/sam2/modeling/backbones/hieradet.py#L265

Dear developer,
Thank you for the amazing works on "Hiera" and "Absolute Window Embeddings".
Since I'm currently working on self-supervised learning research, I would like to know that are you planning to release the implementation of "Absolute Window Embeddings" and their IN1k MAE pre-trained weights? (which will help me a lot)
Thank you so much!


Remove support for CentOS 7 and CentOS Stream 8

In addition:

Update driver to 550 and CUDA to 12.4
Ensure we install linux-headers on Debian-based systems
Update tests

Signed-off-by: Lance Albertson<EMAIL_ADDRESS>

!bump minor ~

Jenkins has merged this PR into main and has automatically performed a minor-level version bump to v1.2.0.  Have a nice day!


Library release removal request

Library name
wolfssl
Version to remove
4.7.1

See https://github.com/arduino/library-registry/pull/4056 and https://github.com/arduino/library-registry/issues/4101

Done:
2024/02/29 14:56:29 Loaded 6704 libraries from DB
Removing<EMAIL_ADDRESS>Success!

Confirmed. Thank you!


STAC 4s upgrades

Epic to cover STAC4S work.

Model interval ADT with periodic and non-periodic intervals https://github.com/azavea/stac4s/issues/268

Closed via azavea/stac4s#268, all on-hold tasks are not blocking this epic and can be moved into a separate one, if necessary.


chore: disable renovate digest pinning

The PRs for digests are getting too frequent.

Coverage remained the same at 100.0% when pulling 9cdc9c3c07bbd72a38286c6ffe95df3da6913582 on chore-renovate-digest into 334e17a28ca3baa7a1380ba5a3e4eecd26e6c327 on master.


Add S3 Bucket ACL Allows Read to AllUsers query for CloudFormation

Platform
CloudFormation
Description
S3 Bucket ACL should not allow read operations to 'AllUsers' grantee

Waiting for AWS account to confirm if PublicAccessBlockConfiguration needs to be considered
@ruigomescx @NunoAraujoCX


relax filepath version boundaries

:+1: I would love to see this merged and a new version cut.

Done. It's available on hackage.

Awesome! Thanks!


Migrate mutation decorators

Acceptance Criteria

[ ] It should bring in all missing mutations from Holtzman

It seems all have been brought in at this point except for setPhoneNumber and saveDeviceRegistrationId (I didn't know there were push notifications, maybe we need to bring this up?). Profile mutations continue in a different issue here


Update readme with more info

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

Project coverage is 74.71%. Comparing base (3eeeb6e) to head (a38b13f).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #33      +/-   ##
==========================================
+ Coverage   74.60%   74.71%   +0.11%
==========================================
  Files          17       17
  Lines        1327     1325       -2
==========================================
  Hits          990      990
+ Misses        337      335       -2

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


Generalize pois queries for diverse tags

I modified the parse_poi_query, osm_poi_download, and pois_from_place functions so they accept a tags dictionary that allows querying a variety of tags, not just the 'amenity' tag, as previously implemented.
Desired tags are passed to pois_from_place with a dictionary like this:
tags = {
    'amenity':True,
    'leisure':False,
    'landuse':['retail','commercial'],
    'highway':'bus_stop'
}
gdf = ox.pois_from_place(place='Santa Clara, Santa Clara County, California, USA', tags=tags)

A particular key:value pair (e.g., 'highway':'bus_stop') returns elements with that particular pair. A list of values for a certain key (e.g., 'landuse':['retail','commercial']) returns all elements with any of those values. A True value (e.g., 'amenity':True) retrieves all elements with that key.
In theory, a False value (e.g., 'leisure':False) would filter out any element with that key, but this doesn't seem to work reliably. I don't know if this is an issue with my query construction or a bug with Overpass. To help troubleshoot this, I included an optional boolean parameter (return_query) to return the constructed Overpass query alongside the GDF. For example, this is query constructed based on the tag dictionary above:
'[out:json][timeout:180];((nwr[~"^(amenity)$"~".*"](37.812276,-122.249374,37.833026,-122.210148);(._;>;););(nwr["leisure"!~".*"](37.812276,-122.249374,37.833026,-122.210148);(._;>;););(nwr[landuse~"retail|commercial"](37.812276,-122.249374,37.833026,-122.210148);(._;>;););(nwr[highway~"bus_stop"](37.812276,-122.249374,37.833026,-122.210148);(._;>;);););out;'

@chesterharvey let me know if you are able to respond to the code review

@chesterharvey I'm going to close this PR for now as it has gone stale and I don't have permissions to push to your branch. Happy to re-open if you have time for the code review + resolving the merge conflicts.

I was just looking at the code and was thinking about submitting a similar PR to get POIs that aren't given a tag of amenity.
I may submit a PR for this soon, but I'll probably try to write my own code instead of starting from this PR.

superseded by #449


Vue.util.extend()

This project is with Vue 2.0, however, I'm not able to find the Vue.util in API or Guides.  This line of code is in the app.js file:
//app.js
...
const app = new Vue(Vue.util.extend({
  router,
  store
}, App))
...

Please advise where it is coming from.
Thanks!

That's an internal method, just a property mixing method. It can be replaced with Object.assign. I've avoided using it now.


Build failure on macOS Mojave

I was looking for a simple example of how to use Rust with Verilog, via Verilator and found this.  It isn't clear to me how to use it, but cargo build seems to fail, ending in
  = note: Undefined symbols for architecture x86_64:
            "Vtop::final()", referenced from:
                _top_final in libVtop__ALL.a(top.o)
            "Vtop::~Vtop()", referenced from:
                _top_delete in libVtop__ALL.a(top.o)
            "Vtop::Vtop(char const*)", referenced from:
                _top_new in libVtop__ALL.a(top.o)
            "Vtop::_eval_initial(Vtop__Syms*)", referenced from:
                Vtop::_eval_initial_loop(Vtop__Syms*) in libVtop__ALL.a(Vtop.o)
            "Vtop::_eval_settle(Vtop__Syms*)", referenced from:
                Vtop::_eval_initial_loop(Vtop__Syms*) in libVtop__ALL.a(Vtop.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is after applying the attached patch for trivial issues.
I don't know if this is still maintained, but I figured I'd point this out.
minor-build-issues.patch.txt

Thanks for the report, I haven't used this crate in a long time. Can you tell me what platform you tried to compile on and I'll see if I can reproduce?

I pulled the latest master and:
djg in ~/Work/verilated-rs on master!
$ cargo run -p example
   Compiling unicode-xid v0.1.0
   Compiling fnv v1.0.7
   Compiling cc v1.0.66
   Compiling proc-macro2 v0.3.8
   Compiling quote v0.5.2
   Compiling syn v0.13.11
   Compiling verilator v0.1.4 (/Users/djg/Work/verilated-rs/verilator)
   Compiling verilated v0.1.1 (/Users/djg/Work/verilated-rs/verilated)
   Compiling example v0.0.0 (/Users/djg/Work/verilated-rs/example)
   Compiling verilated-module v0.1.1 (/Users/djg/Work/verilated-rs/verilated-module)
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
warning: warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
warning: 1 warning generated.
    Finished dev [unoptimized + debuginfo] target(s) in 13.10s
     Running `target/debug/example`
0: count_o = 0
1: count_o = 0
2: count_o = 1
3: count_o = 2
4: count_o = 3
5: count_o = 4
6: count_o = 5
7: count_o = 6
8: count_o = 7
9: count_o = 8
10: count_o = 9
11: count_o = 10

I have the following version of verilator:
djg in ~/Work/verilated-rs on master!
[1] $ verilator --version                                                                                ⤬
Verilator 4.030 2020-03-08 rev v4.028-50-g95c4b6aa

I'm on an iMac 5K, running macOS 10.14.6 (Mojave), but otherwise up-to-date.  Rust
Verilator is from Mac Home Brew and is fresh:
$ rustc --version
rustc 1.48.0 (7eac88abb 2020-11-16)
$ verilator --version
Verilator 4.106 2020-12-02 rev v4.104-91-gb350b6a0f

My repo is up-to-date at
commit fb8922a68f686071aa1b0db5fbe60bbeb0fc7522 (HEAD -> master, origin/master, origin/HEAD)
Author: Dan Glastonbury<EMAIL_ADDRESS>Date:   Tue Apr 21 15:05:16 2020 +1000

    Bump version to 0.1.4

If I clean all and run cargo run -p example I get
cargo-run.output.txt

Slightly unrelated, but I'm trying to make the example standalone, but I need a hint.  My Cargo.toml of
[package]
name = "example"
version = "0.0.0"
authors = ["Dan Glastonbury<EMAIL_ADDRESS>edition = "2018"
build = "build.rs"

[dependencies]
verilated = "*"

[build-dependencies]
verilator = "*"

clearly isn't right as it complains that
  cargo build
   Compiling example v0.0.0 (/Users/tommy/projects/Rust/verilated-example)
   Compiling verilated v0.1.1
error[E0432]: unresolved import `verilator::module`
 --> build.rs:6:16
  |
6 | use verilator::module::ModuleGenerator;
  |                ^^^^^^ could not find `module` in `verilator`

error: aborting due to previous error

but I'm setting the feature didn't work either.

If I clean all and run cargo run -p example I get
cargo-run.output.txt

Thanks for the info. I pulled that latest verilator from homebrew and have the same issues, so something major changed between version 4.030 and 4.106. I hand wrote the bindings to verilator. Perhaps it's time to invest in rust-bindgen to generate the bindings?

clearly isn't right as it complains that
  cargo build
   Compiling example v0.0.0 (/Users/tommy/projects/Rust/verilated-example)
   Compiling verilated v0.1.1
error[E0432]: unresolved import `verilator::module`
 --> build.rs:6:16
  |
6 | use verilator::module::ModuleGenerator;
  |                ^^^^^^ could not find `module` in `verilator`

error: aborting due to previous error

That is odd. I'll take a look once I finish updating the crates to edition 2018.

I've hacked together a version that compiles with Verilator 4.108 here: https://github.com/adamwalker/verilated-rs

@adamwalker I don't appear to be able to file issues so I'll report it here: your version doesn't build for me either:
$ cargo run -p example
   Compiling verilated v0.1.1 (/home/tommy/projects/verilated-rs/verilated)
The following warnings were emitted during compilation:

warning: src/verilated_shim.cpp: In function ‘void verilated_flush_call()’:
warning: src/verilated_shim.cpp:92:14: error: ‘flushCall’ is not a member of ‘Verilated’
warning:    92 |   Verilated::flushCall();
warning:       |              ^~~~~~~~~

error: failed to run custom build command for `verilated v0.1.1 (/home/tommy/projects/verilated-rs/verilated)`
...
$ verilator --version
Verilator 4.038 2020-07-11 rev v4.036-114-g0cd4a57ad
$ rustc --version
rustc 1.50.0 (cb75ad5db 2021-02-10)

I did start reworking verilator over the Christmas break. I'll see if I can
get some time tonight to just this working with version 4.038 of
Verilator instead of rewriting the entire world.
On Tue, 16 Feb 2021 at 04:14, Tommy Thorn<EMAIL_ADDRESS>wrote:

@adamwalker https://github.com/adamwalker I don't appear to be able to
file issues so I'll report it here: your version doesn't build for me
either:
$ cargo run -p example
Compiling verilated v0.1.1 (/home/tommy/projects/verilated-rs/verilated)
The following warnings were emitted during compilation:
warning: src/verilated_shim.cpp: In function ‘void verilated_flush_call()’:
warning: src/verilated_shim.cpp:92:14: error: ‘flushCall’ is not a member of ‘Verilated’
warning:    92 |   Verilated::flushCall();
warning:       |              ^~~~~~~~~
error: failed to run custom build command for verilated v0.1.1 (/home/tommy/projects/verilated-rs/verilated)
...
$ verilator --version
Verilator 4.038 2020-07-11 rev v4.036-114-g0cd4a57ad
$ rustc --version
rustc 1.50.0 (cb75ad5db 2021-02-10)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/djg/verilated-rs/issues/5#issuecomment-779382997, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABGDLPWAJLFPQW3ILJT5LLS7FP6ZANCNFSM4UPW75GQ
.

--
Dan Glastonbury, Dan dot Glastonbury at gmail dot com
`Pour encourjay lays ortras'

I did some work to get the example compiling in PR #6.

Thanks!


Chore: Adjust Project

Changes summary:

Rename package to github.com/Haraj-backend/go-sse
Include Haraj-backend authors to LICENSE
Move CI pipeline to Github Action instead TravisCI
Update links in README.md to github.com/Haraj-backend/go-sse

Any comments, @knightazura, @isdzulqor?


Woocommerce search not working.

If I search 'Mix', even with a woocommerce search plug in the out put is below.
"Create your own bundle with Mix and Match.
Create your own bundle with Mix and Match.
MIX & MATCH
MIX & MATCH"
There are two products with the term in with one of each of the above in title and description.
This is all it shows. Just plain text. It works in other themes, just not this one. It does not show the woocommerce products.
Any idea to mak e this work ?

It is not possible that all themes will be supported WooCommerce.
For example, one of popular Bootstrap ( Flat Bootstrap by XtremelySocial ) still not fully supported. The search result is just product title, description same as this theme.
You have to search for theme that has marked as WooCommerce supported. Example ( https://wordpress.org/themes/search/woocommerce/? ).

This theme has nothing about search result modification. If you disable all other plugins except Woo then it will be able to search the product but search result did not display product's thumbnail. It still be able to click on the link to see product description page.
So, what you said It does not show the woocommerce products isn't true. WordPress can search across any different post types. Try to disable other plugins that may interfere the search result.


Coway changed auth backends (I think)

Looks like the official iOS app made everyone migrate to a Coway account this week. The error I get from the integration when asked to reauthorize is "Coway API authentication error: unable to retrieve auth 'code'. Likely due to invalid username/password."
Please me know if there's anything I can do to help debug -- HA runs on HAOS and I can SSH to the underlying OS freely so I can get whatever logs you might need/want from my setup.

Yup, looks like they did and in turn probably changed the authorization. I'll have to sniff out the new endpoints/auth method and make those changes to the backend.

Thanks @RobertD502, I'm seeing the same issue as well...

@mckern @jerrice
After migrating your account using the Coway IoCare mobile app (note: use the same email and password for your new "coway account"), update the integration to 0.1.4, which I just released. That should take care of things.

Confirmed @RobertD502 , 0.1.4 works.
I was just troubleshooting this and saw a release from minutes ago. Perfect timing.

+1, 0.1.4 is also working for me.

Reference

Yup, works perfectly, thank you!!

Works perfectly for me; great turnaround time. Thank you so much!

Works perfectly for me; great turnaround time. Thank you so much!

No problem! I realize a lot of people rely on this integration so I had to work fast. Not sure why they decided to add an openid layer, but hopefully that's the last of any major changes they make.


feat: Upgrade go to 1.14

Signed-off-by: Brad Beam<EMAIL_ADDRESS>

Get the /Dockerfile and /go.mod as well.


Override cargo target dir

Currently, install.sh build will fail if cargo target dir is changed in cargo config or using env variables, this PR fixes this by passing --target-dir ./target to cargo.
Ideally we should use cargo config but it's unstable.

lgtm, Thanks


Race condition in showing and hiding the suggestions widget

We are using Monaco to provide syntax highlighting and autocomplete for a search bar. This issue popped up when upgrading from Monaco from 0.18.1 to 0.23.0. When typing very quickly, the Monaco suggestions widget will sometimes get stuck in an empty state when it should be hidden.
Here is a normal screenshot of our autocomplete:

Here is a screenshot of when this bug happens:

I have narrowed down the issue to a race condition in suggestionWidget.ts. When showing the widget, there is a 100ms timeout. However, hiding is immediate. Therefore, typing very fast could cause the hiding to happen before the showing.
I was able to fix this by modifing suggestionWidget.ts to not add the visible class if the widget is in a hidden state.
private _show(): void {
	this._status.show();
	this._contentWidget.show();
	this._layout(this._persistedSize.restore());
	this._ctxSuggestWidgetVisible.set(true);

	this._showTimeout.cancelAndSet(() => {
+		if (this._state !== State.Hidden)
			this.element.domNode.classList.add('visible');
			this._onDidShow.fire(this);
+		}
	}, 100);
}

monaco-editor version: 0.23.0
Browser: Latest Chrome/Edge
OS: masOS 11
Playground code that reproduces the issue: I am still working on a minimal repro for this in the playground.

Thanks @jrieken for helping get this into vscode! @alexdima what is the process for getting a new monaco-editor release with this fix? Is there a regular train?

@connor4312 What is needed to get a new Monaco release out with this fix?

We will create a new monaco-editor release in the following days.


Type constraints

Some type predicates, like var/1, are impossible to turn into a constraint, but here are some that probably can:

[x] atom_c/1
[x] integer_c/1
[x] float_c/1
[x] number_c/1
[x] atomic_c/1
[x] list_c/1
[x] character_c/1
[x] chars_c/1
[x] compound_c/1

There's probably still some bugs, but all these are down.