Federation Admin Service URL

Hi guys,
I have installed ArcGIS Enterprise on a single machine using this DSC library. I don't have a web adaptor as I'm using Azure App Gateway to route requests to the backend targets.
I have also set "AdminAccessEnabled" to true at a global level as I want to allow administrative access from the public endpoint. I don't want to use an internal load balancer to round-robin requests to the internal machines using port 6443 as it is not required.
The federation of the hosting server, even though I have "AdminAccessEnabled" set to true and have set the ExternalLoadBalancer URL, still uses the machine name of the hosting server, port 6443 and the web context arcgis. This same behavior happens when specialized GIS servers are federated with Portal for ArcGIS. Of course, I can use the InternalLoadBalancer to set up an HA endpoint but it overcomplicates the deployment when it does not need to be.
Maybe this is more of a preference thing, but in my opinion, if "AdminAccessEnabled" is set to true and an external load balancer URL has been supplied, the Admin Service URL used for the federation should match the Services URL.
Note that with self-signed certificates, the federation would fail because the certificate needs to be loaded to app gateway http settings first. Once loaded, the install would have to be re-run so the federation bit completes.
The way this works today, it forces me to unfederate, and federate manually. Also, note that when using a web adaptor and admin access is enabled, this is what happens. The Admin Service URL matches the Services URL. This behavior should be consistent even if App Gateway is used.
Also, as an enhancement, there should be a smarter way to automatically register the self-signed certificate automatically with app gateway to allow the end to end process to work in one go.
Hope this makes sense.
Cheers,
Jose
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request

Module Version

4.1.0

Affected Resource(s)

ArcGIS_Server
ArcGIS_Portal

Configuration Files
Expected Behavior
Federation Admin Services URL matches Services URL
Actual Behavior
Federation Admin Services URL uses the machine name of the server being federated with port 6443 and web context set to arcgis. We can use an internal load balancer sure, but it adds additional complexity where is not required in my view.
Steps to Reproduce
Configure App Gateway, and run an install of ArcGIS Enterprise and confirm that the hosting server is federated using port 6443 for the Admin Service URL.
Important Factoids
References

I have a similar issue for a Highly Available ArcGIS Enterprise deployment where the 'PrivatePortalURL' is recommended. This setting is used to access the Portal from any federated Servers and can either have the same value as the 'WebContextURL' or use an internal load balancer with the admin ports (6443 and 7443) allowed through.
Example:
"WebContextURL"="https://myserver.mydomain.mycom/portal"
"PrivatePortalURL"="https://myinternalservername.myinternaldomain:6443/arcgis"
The issue is that the PrivatePortalURL ALWAYS includes the Admin port (6443) when my requirement is to have it the same as the WebContextURL as it is simpler and the customer does not want a second (internal load balancer) in place.
Example of what we need:
"WebContextURL"="https://myserver.mydomain.mycom/portal"
"PrivatePortalURL"="https://myserver.mydomain.mycom/portal"
It is unclear to us how the DSC creates the value of the PrivatePortalURL. We've experimented with including the internalLoadBalancer and other tweaks but to no avail. It always includes the admin port number for the PrivatePortalURL. Due to this, the Federation steps in the PowerShell DSC module does not complete and crashes out. We have to then manually change the PrivatePortalURL via portal admin page and can then manually federate the servers. This manual process makes the process not fully automated, so am keen to see what settings controls the creation of the PrivatePortalURL and the population of the parameter and how we can change it.

I have a similar issue for a Highly Available ArcGIS Enterprise deployment where the 'PrivatePortalURL' is recommended. This setting is used to access the Portal from any federated Servers and can either have the same value as the 'WebContextURL' or use an internal load balancer with the admin ports (6443 and 7443) allowed through.
Example: "WebContextURL"="https://myserver.mydomain.mycom/portal" "PrivatePortalURL"="https://myinternalservername.myinternaldomain:6443/arcgis"
The issue is that the PrivatePortalURL ALWAYS includes the Admin port (6443) when my requirement is to have it the same as the WebContextURL as it is simpler and the customer does not want a second (internal load balancer) in place.
Example of what we need:
"WebContextURL"="https://myserver.mydomain.mycom/portal" "PrivatePortalURL"="https://myserver.mydomain.mycom/portal"
It is unclear to us how the DSC creates the value of the PrivatePortalURL. We've experimented with including the internalLoadBalancer and other tweaks but to no avail. It always includes the admin port number for the PrivatePortalURL. Due to this, the Federation steps in the PowerShell DSC module does not complete and crashes out. We have to then manually change the PrivatePortalURL via portal admin page and can then manually federate the servers. This manual process makes the process not fully automated, so am keen to see what settings controls the creation of the PrivatePortalURL and the population of the parameter and how we can change it.
Architecture:
Azure Application Gateway x2 All in one ArcGIS Enterprise 11.1 Base deployments.
Module 4.2

In this situation I recommend to only use ExternalLoadBalancer parameter. It will then be used for both the WebContextURL and PrivatePortalURL.


Basic Troubleshooting?

face_recognition version: Click-6.7 Pillow-3.1.2 dlib-19.7.0 face-recognition-1.0.0 face-recognition-models-0.3.0 numpy-1.13.3 olefile-0.44 scipy-1.0.0

Python version: 3.5.2

Operating System: Ubuntu

Description
I am just starting out, but for some reason, I can't get it to detect any faces in any of my pictures. Are there any basic beginning steps you would recommend?
What I Did
~/faceRec$ python3 find_faces_in_picture.py
I found 0 face(s) in this photograph.

The unnknown.jpg image is in the same folder that im running the script in (faceRec)

from PIL import Image
import face_recognition

# Load the jpg file into a numpy array
image = face_recognition.load_image_file("unknown.jpg")

# Find all the faces in the image using the default HOG-based model.
# This method is fairly accurate, but not as accurate as the CNN model and not GPU accelerated.
# See also: find_faces_in_picture_cnn.py
face_locations = face_recognition.face_locations(image)

print("I found {} face(s) in this photograph.".format(len(face_locations)))

for face_location in face_locations:

    # Print the location of each face in this image
    top, right, bottom, left = face_location
    print("A face is located at pixel location Top: {}, Left: {}, Bottom: {}, Right: {}".format(top$

    # You can access the actual face itself like this:
    face_image = image[top:bottom, left:right]
    pil_image = Image.fromarray(face_image)
    pil_image.show()

Is unknown.jpg a file included in the examples folder or one of your own files? All the example should "just work"
If it is one of your own image files, is it possible it's a jpeg image where the image is actually sideways but the image has an embedded EXIF rotation tag telling the program it needs to rotate the image before displaying it? If that's the case, you need to rotate the image yourself. This library won't do that automatically. This is a common source of problems if you originally took the picture on an iphone, for example. See this for more info.


App does not show up anymore when started since 2.17.3

My Setup

Operating System: CentOS 7.7.1908
App Version: 2.17.3, 2.17.4, 2.17.5
Installation type: RPM

[x] I have tested with the latest version
[x] I can simulate the issue easily

Description

When the app is started it shows no window, no tray icon but it does not die:
> /opt/Rocket.Chat/rocketchat-desktop
[bugsnag] Loaded!

That happens even with a test user that has not been logged in before. I tried the following desktop environments, but the result is always the same:

GNOME 3
XFCE
MATE

Current Behavior

App is not starting. Downgrade to 2.17.2 makes it work again.
Expected Behavior

The app should show a window.

Same here. With 2.17.5 no window shows up. We are on Cent OS 7.4.

works again for me with rocketchat-2.17.7.x86_64

one more comment: for some users it was necessary to remove ~/.config/Rocket.Chat, else the app would stop directly after starting

@atemp Thanks, I can confirm that it works with 2.17.7.


shiftReferences to true by default?

@christianalfoni, any opinion on this?

It depends. I got one comment on this flux-angular lib I have been working on. Shifting references will cripple objects that inherits from something else than Object. Lets say you wanted to put an instance of a class you have created that has its own prototype. If that object was changed by the Baobab API the object would loose its prototype.
That said. An instance of an object with some custom prototype should implement a constructor property on the prototype.
function MyConstr () {}
MyConstr.prototype = {
  constructor: MyConstr,
  myMethod: function () {}
};

So if you make this default I suggest that the code where you change references on objects, you do this:
// Some cursor that points to an object with custom prototype
var existingBaobabObjectValue = someCursor.get();

// Create a new object linking it to the prototype of the existingBaobabObjectValue
var newObject = Object.create(existingBaobabObjectValue.constructor.prototype);

// Move instance properties over to the new object
extend(newObject, existingBaobabObjectValue);

// Put it back
someCursor.edit(newObject);

I have not checked the source code of how it is done now, but hopefully this makes sense :-)

Hello @christianalfoni, I am more and more considering putting shiftReference to true by default in the future. This would dramatically simplify the validation routine for instance by giving the opportunity to the user to get past and future state.
As I see it, you should not put anything else than "raw" data in the tree but I perfectly understand that I should try to clone correctly "irregular" objects. I'll try to see what I can do.

Actually, you might be interested in this immutable-store I built, immutable-store, just as a daily input :-) It requires raw objects/array/primitives.
I think shiftReference could be true by default, though it has to be clear in the documentation. There might be situations where you want to mutate objects and arrays in the tree without using the tree API. But I would think that developers using Baobab would want to use the tree API for all updates, as you do want to notify about all changes.
 You could copy the few lines of code from PureRenderMixin into the default mixin. Then you would not need any configuration at all working with React. It is just highly optimized straight out of the box :-)
A thought!
Btw, I can help you create a React section on the README, now that you got this tree values copied to state as default behavior. Got lots of experience using Baobab with React, shiftReference and PureRenderMixin now, so I think I could give some valuable input on that.

I don't really see situations where you want to mutate things on your own and if you want to do so you can as well wrap it into an $apply command.
I will think about integrating the purerendermixin but I fear that imposing it might lead to unexpected behaviour for some projects. Maybe a purerender setting or something similar.
Don't hesitate to contribute on the React section of the README. Your input is always welcome :)

Hehe, thanks @Yomguithereal!
Yeah, its better to be safe than sorry, though I am very confident that it will not be a problem. Let me give some background.
If you have a component using the Baobab mixin, where PureRenderMixin is included, it will only update if the property values on the "props" or "state" object changes. Since you listen to one or more cursors the component will update when events triggers on the respective cursors. The component will also update if a parent passes a property with a changed value. It could of course also update if it changes its internal state.
If a child of a component using the mixin does not use the mixin itself it will render whenever the parent renders, which is what you expect. The only way a child can render without its parent is if it listens to a cursor.
There is no way a child would want to render without a change on the parent, passing props, changes its own state or listens to a cursor.
But yeah, its just a small config, and it would be quite embarrassing if something bad would happen ;-) Could of course have pureRender default true, and set it to false just in case.

+1 on default to true with clear documentation of the change


Text component with long string has extra whitespace on Android

Description
On some Android 7.1.1 phones, when a Text component displays a long string, extra whitespace is added to the bottom. It appears that the whitespace occurs when strings wrap with hypens.

Nexus 5X device, Android 7.1.1
Nexus 5X Simulator, Android 7.1

Reproduction
This appears to work correctly (no extra whitespace) on rnplay. Taking the project from that page and running it on a Nexus 5X or Pixel running Android 7.1.1 does, however, demonstrate the bug.
Additional Information

React Native version: 0.40.0
Platform: Android, confirmed on Nexus 5X and Pixel running Android 7.1.1

We're cutting down on the number of outstanding issues, in order to allow us to focus. I'm closing this issue because it has been open for over 60 days with no activity. If you think it should still be opened let us know why. PRs are always welcome.

@hramos This is still an issue for us and we're getting closer to releasing. Can you reopen this ticket?
I can reproduce this on Snack https://snack.expo.io/BJfLGVoOb

@hramos Poke about this issue.  This is still very much happening, and I think this issue could be reopened for that reason.  Note that this affects android 8 phones as well.


chore: release 1.2.161

:robot: I have created a release *beep* *boop*
1.2.161 (2022-08-18)
Bug Fixes

trigger release (b1d68d5)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/werf/werf/releases/tag/v1.2.161 :sunflower:


Experimental packaging

This PR merges the new packaging functionality. It provides a new subcommand called experimental, along with three new packaging commands dcos experimental package add, dcos experimental package build, and dcos experimental service start. It also provides tests, although a large portion of them are commented out since some of the required functionality is not enabled in cosmos.

 We should have them run if an env var is set.

@tamarrow Yes.

Closing this to avoid permission issues. See for #858 for the continuation.


User method to get the database version

@juanignaciosl please review

Commented a couple of minor suggestions, but :+1:


Remove osversion usage in computestorage APIs

Due to some of the computestorage APIs calling osversion internally,
this can leave the caller in a precarious situation. Either they manifest
their binary or get:

Weird behavior that might not make sense for their operating system
The call just flat out won't work as we were blocking it based on
it not being available on certain versions.

There's two changes to functions that called the osversion package:

FormatWritableLayerVhd. This API had a breaking change in the operating
system on RS5+. On RS5 the API expects a file handle, while on > RS5 it
expects a vhd handle from the virtdisk APIs. Internally to be friendly
we were checking if the caller is on RS5 and doing this conversion for
them, so a vhd handle can always be passed. However the version check
requires the application to be manifested, and the version check was
if build < 19h1. If an application isn't manifested GetVersion will return
the windows 8 build number which fits this criteria, so we would always try
and do the conversion, breaking the call on anything but ws2019 if the binary
was not manifested.

There really doesn't seem like a nice solution here.
It's unfortunate that the OS had a breaking change, but to avoid
needing a caller of this to manifest just to be able to call the API on anything
but ws2019, remove the osversion check and document the need for a different
handle.

SetupBaseOSVolume. This API is only available on builds greater than
19645 and we were also checking via osversion if this is alright to call.
The issue for non-manifested binaries is the check inside that is asking
if the current build is less than 19645 before throwing an error will
always be true, so clients that want to check the version via some other
route (while not recommended) before calling, cannot. I've removed this
use of osversion entirely.

Add docs to the APIs describing if they're only available on a certain build
and for the breaking change information.

@TBBle I've went back and forth on this. As a user of the package, what do you think? Funnily enough this is not the only exposed API that calls osversion, ExpandSandboxSize bounces to wclayer.ExpandScratchSize which calls it to handle some edgecases on 19h1, albeit the work needed is much more than the breaking change with the disk handle described in this https://github.com/microsoft/hcsshim/blob/master/internal/wclayer/expandscratchsize.go#L35-L142
I don't want to end up in a spot where someone adding in a workaround in their code can break depending on whether they manifest in the future or not. e.g. someone adds in the file handle workaround for FormatWritableLayerVhd by checking the registry or RtlGetVersion etc. and then decide to manifest their binary later on causes us to enter that condition and try and AttachVirtualDisk using their file handle they passed us and their code breaks. While it is a tad annoying, maybe the best place to keep this API easily callable is to let the application worry about the extra logic on RS5.

Did you consider a different approach: just stop using GetVersion and instead obtain OS version info through more reliable sources?

Did you consider a different approach: just stop using GetVersion and instead obtain OS version info through more reliable sources?
GetVersion docs say that you should not use it at all:

GetVersion may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper functions.

They still require the binary to be manifested to return correct info. If it were up to me I'd just swap osversion to checking the registry or RtlGetVersion, but they were both recommended against internally as manifesting is still the route. I didn't hear any shouts for a need to get off GetVersion however. Curious if that notion has shifted since the last I checked though. VerifyVersionInfo which is what those helpers call underneath is also "deprecated" since Windows 10 which is funny

Yuck lol

For real

@jterry75 We may be able to use the supported schema version here. It seems the minor gets incremented per official windows release, but all we really care about is 2.1 (RS5) or > 2.1 here. There may be an odd pre-release build in between rs5 and 19h1 where they made the breaking change but the schema version was still 2.1 (not sure when they increment it in development, asked), but I don't think that'd be a huge population to worry about

Interesting idea. Insider builds are not supported anyways so I think thats fine. I suppose at the end of the day is no different than using build numbers. We say build NNN means features XYZ. We could just as easily say Schema Y.N means features XYZ

Right, they have a doc detailing the increments in schema version for each version so it'd even be possible to adopt it for other checks if need be. They just rev the minor for every windows release. Although your parsing of cmd /c ver is also an option. I guess we could even skip manifesting containerd in that case, although we miss out on a cool icon for containerd 😆

I guess we could even skip manifesting containerd in that case, although we miss out on a cool icon for containerd 😆

So funny
If we are ok calling cmd /c ver I think thats the easiest option, or we could have osversion do the trick for us, so basically ver = HCSAndGetSchemaVersion(); return osversion.V... when 2.1 etc. So that none of the code really considers it any different. Using the schema is sorta hidden. Either works for me.
We can figure out a new way to get a cool icon..

The only thing cmd /c ver brings to mind is the classic text parsing dilemma, if the format changes our parsing will implode. Don't picture that happening anytime soon, but something to note. Also.. I kind of like the idea of the cmd /c ver as a fallback instead of replacement. Given the query is only done once, if we GetVersion() and we get back the bogus win8 build number, we can fallback to cmd.

Fallback works for me. Then if someone wants to manifest they get the perf for free. I like it

@jterry75 Before making an osversion change, we're gonna try to fix the problem in here first. Given 0.9.x didn't have any friendly logic and just passed whatever handle you give it, if anyone WAS doing the workaround themselves, if they updated to v0.10.x and we try and be friendly inside that would also break them.
I think we're going to try and stick with this change, e.g. just revert any osversion usage, and then make another wrapper for this function for v0.10.0 with the "friendly" behavior and ideally deprecate this one. We're trying to get the HCS teams blessing if just checking the schemas sufficient

@kevpar Undrafted this. Lets get back to the v0.9.x behavior first and then we can deprecate/recommend a new call that handles things for the caller

@kevpar Reverted the commit instead of doing it manually and added an additional commit to document things a bit, PTAL

I haven't worked through the codebase, but since the early comment mentioned ExpandScratchSize, I saw the check there is only covering two releases (1903 and 1909), which are now out-of-support (even for Windows 10 Enterprise, as of May), and there was never a Windows Server LTSC build in that range.
So maybe that check/workaround can be dropped too. I think it'd be an interesting result if we can get rid of all the osversion.Build calls outside the testsuite, given that Windows Server 2016 has left mainstream support, so everything likely to use new hcsshim builds from whatever the next release branch is called is RS5 or later.

@TBBle I'm more curious if the OS fix that's mentioned that is being worked around was ever fixed 🤣.  We can probably remove that as well (not in this PR though)

As an experiment I threw the current PR into the containerd test-case from #1375, and it looks good. There's some unrelated failures, but unit and integration tests passed on both WS 2019 and WS 2022. (Both failed on TestContainerdRestart in the CRI integration test suite, which is mildly concerning, but I can't see how that would be related to what this PR is doing)

That test has been on and off failing for a bit, we'll fix one cause and out pops another. I think I saw it fail on main there a couple days ago so I don't think it's from this either, but we should take another look as it seems to be causing a mess again. I'm glad the pkg/os test that uses formatwritablelayer is passing again though it sounds like


Add sonarqube scan to test workflow

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

Please upload report for BASE (main@7268fcd). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #265   +/-   ##
=======================================
  Coverage        ?   90.93%
=======================================
  Files           ?        4
  Lines           ?      430
  Branches        ?        0
=======================================
  Hits            ?      391
  Misses          ?       39
  Partials        ?        0

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


FullScreenRectangle doesn't work on all screen resolutions

Overview: What does this pull request change?
fix: frame.py has been changed. The frame.py is updated, and the screen ratio is added to read the configuration file, which is no longer hard-coded 16:9.

It kind of only works for the config file then, if you use python -m manim -p -r "1500,1500" it breaks apart and doesn't fix the issue with the screen size

@MrDiver Your test is correct. But that is a function config bug, not related to any specific component such as this one.
Like config["frame_width"] should be able to get the current config parameter based on the order of precedence:

Library-wide config file,
user-wide config file, if it exists,
folder-wide config file, if it exists OR custom config file, if passed via --config_file,
other CLI flags, and
any programmatic changes made after the config system is set.

I guess that will not fix itself, i would probably search for it in the spirit of fixing future problems. Or just create an issue that this one is actually not passed to the config object

Stale for now

Stale for now

That is incorrect.


[AutoPR] containerinstance/resource-manager

Created to accumulate context: containerinstance/resource-manager

(message created by the CI based on PR content)

Empty PR


[Feature] Add support for dynamic rendering sections for 9pm onward

Make the calendar dynamically add rows past 9pm to allow classes that extend past 9pm to be added and render properly.

Also extended the height of the extension by 50px and shifted upwards

https://github.com/mlool/workday-calendar-extension/assets/89222914/c77482e0-6fc3-42ac-aa6d-f31c447e659f

Please resolve the conflict


Arch arm v8m mpu remove hal

Superset of #8457
Experimental, at the moment, DNM

Codecov Report

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

@@           Coverage Diff           @@
##           master    #8467   +/-   ##
=======================================
  Coverage   64.61%   64.61%
=======================================
  Files         421      421
  Lines       40296    40296
  Branches     6803     6803
=======================================
  Hits        26037    26037
  Misses      11126    11126
  Partials     3133     3133

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a313e5c...dc21dbf. Read the comment docs.

Looks good to me @ioannisg. Will let others approve though.


FR: Make step of log_iter be str compatible.

Currently it must be int.

Not possible because MLflow expects step to be an int.
See here: https://www.mlflow.org/docs/latest/python_api/mlflow.html#mlflow.log_metric
closing


Emmet doesn't get triggered in single line SCSS with nested rules

In the following example .foo{ dn| .bar{display: none;}} we get css completions but no emmet ones. Triggering with tab or with Expand Abbreviation command doesn't work either.
If we add a new line
.foo{ dn|
    .bar{display: none;}}

everything works fine.

This is because the upstream emmet css parser considers dn to be part of the selector .bar
With the newline, it no longer considers the same.
The fix would be very hacky and not worth the pains as this is a very corner case.
Closing for now and not fixing this unless there is enough user feedback about the same


ci: add rust caching for cargo

All of these are done directly after toolchain selection, since that is what the cache uses to determine the key.

I'm going to merge this when tests are done, can you add this to all of the repos' CI?


Set utf8 locale

Fixes https://github.com/servo/saltfs/issues/645. Setting it on all hosts
because it's good practices to not just assume they have the right default
across diverse systems.
Others have hit quirks like https://github.com/saltstack/salt/issues/24827
with locale.present but the latest comment is saying it's ok now.
literally just https://docs.saltstack.com/en/latest/ref/states/all/salt.states.locale.html except with a tweaked state name

This change is

Restricted to ubuntu only since it works there, definitely doesn't on osx, not sure about windows.
Second commit is to see if it fixes the apparently intermittent failure stemming from missing /usr/share/i18n/locales, seen in https://travis-ci.org/edunham/saltfs/jobs/268434026 but not https://travis-ci.org/edunham/saltfs/jobs/268434017 . Checking on my system reveals i did it wrong; amendment incoming.

:umbrella: The latest upstream changes (presumably #850) made this pull request unmergeable. Please resolve the merge conflicts.


document game service packet 0x131

Thanks! I think you need to go update references to this struct since you changed the ID (just the one in the nearest index.ksy probably.) That should make CI green.


Android app crashes when encrypted

Godot version:

3.2.2.stable
OS/device including version:

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-42-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 7,7 ГиБ
GLES3
Issue description:

I am making an application for android.
I decided to encrypt the scripts as stated in the documentation at https://docs.godotengine.org/ru/latest/development/compiling/compiling_with_script_encryption_key.html
Compilation takes place without problems, but after installing the application on the device after launching the application, it closes without error.
The adb logcat -s godot command outputs:

07-27 13:10:16.388 17004 17043 E godot   : ERROR: Condition "err" is true. Returned: err
07-27 13:10:16.388 17004 17043 E godot   :    At: modules/gdscript/gdscript.cpp:772:load_byte_code() - Condition "err" is true. Returned: err
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Cannot load byte code from file 'res://Scripts/constants.gde'.
07-27 13:10:16.388 17004 17043 E godot   :    At: modules/gdscript/gdscript.cpp:2281:load() - Condition "err != OK" is true. Returned: RES()
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Failed loading resource: res://Scripts/constants.gde.
07-27 13:10:16.388 17004 17043 E godot   :    At: core/io/resource_loader.cpp:278:_load() - Condition "found" is true. Returned: RES()
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Can't autoload: res://Scripts/constants.gd
07-27 13:10:16.388 17004 17043 E godot   :    At: main/main.cpp:1749:start() - Condition "res.is_null()" is true. Continuing.
07-27 13:10:16.388 17004 17043 E godot   : ERROR: The MD5 sum of the decrypted file does not match the expected value. It could be that the file is corrupt, or that the provided decryption key is invalid.
07-27 13:10:16.388 17004 17043 E godot   :    At: core/io/file_access_encrypted.cpp:97:open_and_parse() - Condition "String::md5(hash) != String::md5(md5d)" is true. Returned: ERR_FILE_CORRUPT
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Condition "err" is true. Returned: err
07-27 13:10:16.388 17004 17043 E godot   :    At: modules/gdscript/gdscript.cpp:772:load_byte_code() - Condition "err" is true. Returned: err
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Cannot load byte code from file 'res://Plugins/Firebase.gde'.
07-27 13:10:16.388 17004 17043 E godot   :    At: modules/gdscript/gdscript.cpp:2281:load() - Condition "err != OK" is true. Returned: RES()
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Failed loading resource: res://Plugins/Firebase.gde.
07-27 13:10:16.388 17004 17043 E godot   :    At: core/io/resource_loader.cpp:278:_load() - Condition "found" is true. Returned: RES()
07-27 13:10:16.388 17004 17043 E godot   : ERROR: Can't autoload: res://Plugins/Firebase.gd
07-27 13:10:16.388 17004 17043 E godot   :    At: main/main.cpp:1749:start() - Condition "res.is_null()" is true. Continuing.

Everything works without encryption.

did you set the encryption key at export setting?

@volzhs

07-27 15:56:28.435 21157 21193 E godot   : ERROR: The MD5 sum of the decrypted file does not match the expected value. It could be that the file is corrupt, or that the provided decryption key is invalid.
07-27 15:56:28.436 21157 21193 E godot   :    At: core/io/file_access_encrypted.cpp:97:open_and_parse() - Condition "String::md5(hash) != String::md5(md5d)" is true. Returned: ERR_FILE_CORRUPT
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Condition "err" is true. Returned: err
07-27 15:56:28.436 21157 21193 E godot   :    At: modules/gdscript/gdscript.cpp:772:load_byte_code() - Condition "err" is true. Returned: err
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Cannot load byte code from file 'res://Scripts/check_connect.gde'.
07-27 15:56:28.436 21157 21193 E godot   :    At: modules/gdscript/gdscript.cpp:2281:load() - Condition "err != OK" is true. Returned: RES()
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Failed loading resource: res://Scripts/check_connect.gde.
07-27 15:56:28.436 21157 21193 E godot   :    At: core/io/resource_loader.cpp:278:_load() - Condition "found" is true. Returned: RES()
07-27 15:56:28.436 21157 21193 E godot   : ERROR: res://MainScene.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Scripts/check_connect.gd
07-27 15:56:28.436 21157 21193 E godot   :    At: scene/resources/resource_format_text.cpp:440:poll() - res://MainScene.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Scripts/check_connect.gd
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Failed to load resource 'res://MainScene.tscn'.
07-27 15:56:28.436 21157 21193 E godot   :    At: core/io/resource_loader.cpp:208:load() - Condition "err != OK" is true. Returned: RES()
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Failed loading resource: res://MainScene.tscn.
07-27 15:56:28.436 21157 21193 E godot   :    At: core/io/resource_loader.cpp:278:_load() - Condition "found" is true. Returned: RES()
07-27 15:56:28.436 21157 21193 E godot   : ERROR: Failed loading scene: res://MainScene.tscn
07-27 15:56:28.436 21157 21193 E godot   :    At: main/main.cpp:1936:start() - Condition "!scene" is true. Returned: false

Make sure to compile both editor and export templates (tools=no), with the same key.

Probably something went wrong with the export templates compilation, check if your encryption key is set in the core\script_encryption_key.gen.cpp file (it should be generated from the SCRIPT_AES256_ENCRYPTION_KEY variable during compilation), and you have compiled both debug, release_debug libraries for all required architectures and apk (see https://docs.godotengine.org/en/stable/development/compiling/compiling_for_android.html for full Android build instruction).

I've been using encrypted script feature for android also.
complied editor without SCRIPT_AES256_ENCRYPTION_KEY and compiled android templates with SCRIPT_AES256_ENCRYPTION_KEY
it works for me.
I think something went wrong with templates as @bruvzg said.

I have the same issue with newest Godot 3.2.3 version when exporting to LinuxX11. I even created empty project with one scene and attached default script template. I haven't changed any options beside export script to Encrypted and provided valid key. Project was exported without any issue. When exporting with option for script: text or compiled everything working properly after export but encrypted script option throw error when I try to run it:
./ExportBug.x86_64
Godot Engine v3.2.3.stable.official - https://godotengine.org
libGL error: failed to create dri screen
libGL error: failed to load driver: nouveau
OpenGL ES 3.0 Renderer: Mesa Intel(R) HD Graphics 530 (SKL GT2)

ERROR: open_and_parse: The MD5 sum of the decrypted file does not match the expected value. It could be that the file is corrupt, or that the provided decryption key is invalid.
   At: core/io/file_access_encrypted.cpp:97.
ERROR: load_byte_code: Condition "err" is true. Returned: err
   At: modules/gdscript/gdscript.cpp:772.
ERROR: load: Cannot load byte code from file 'res://Node.gde'.
   At: modules/gdscript/gdscript.cpp:2282.
ERROR: _load: Failed loading resource: res://Node.gde. Make sure resources have been imported by opening the project in the editor at least once.
   At: core/io/resource_loader.cpp:279.
ERROR: poll: res://Node.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Node.gd
   At: scene/resources/resource_format_text.cpp:440.
ERROR: load: Failed to load resource 'res://Node.tscn'.
   At: core/io/resource_loader.cpp:208.
ERROR: _load: Failed loading resource: res://Node.tscn. Make sure resources have been imported by opening the project in the editor at least once.
   At: core/io/resource_loader.cpp:279.
ERROR: start: Failed loading scene: res://Node.tscn
   At: main/main.cpp:1944.
WARNING: cleanup: ObjectDB instances leaked at exit (run with --verbose for details).
   At: core/object.cpp:2135.
ERROR: clear: Resources still in use at exit (run with --verbose for details).
   At: core/resource.cpp:477.

Export encrypted bug.zip
I use Manjaro Linux.
uname -a
Linux 5.8.6-1-MANJARO #1 SMP PREEMPT Thu Sep 3 14:19:36 UTC 2020 x86_64 GNU/Linux

Did you compile your own export template with the encryption key? https://docs.godotengine.org/en/stable/development/compiling/compiling_with_script_encryption_key.html

I'm fairly sure that OP omitted to compile the export templates, so the error is expected.
@Pawel82S opened #42162 and indeed this was the same problem.
Closing.


How does work "justify" for htmlView?

i don't know how it does work. "right" alignment worked but justify doesn't work.

Justify is not supported currently. Adding clean support might be tricky. I'd start with distributing the available space at rendering time (which means it would need to get handed down there). Then move logic up and/or add caching as needed


loadWithXhr resolve undefined for status code 204

loadWithXhr tries to resolve content for status code 2XX.  However, if the status code is 204 that means that there shouldn't be any content in the response so we should resolve(undefined) instead.
Also, I updated WebStorm and it added new project files
@mramato

@hpinkos, thanks for the pull request! Maintainers, we have a signed CLA from @hpinkos, so you can review this at any time.
:warning: I noticed that CHANGES.md has not been updated. If this change updates the public API in any way, fixes a bug, or makes any non-trivial update, please add a bullet point to CHANGES.md and comment on this pull request so we know it was updated. For more info, see the Pull Request Guidelines.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:

@hpinkos you need to go through all of the Core/loadXXX functions and make sure they handle undefined properly.  For example, loadText will already properly resolve to undefined, but loadJson tries to parse it and needs to be updated to just resolve to undefined if the result of loadText is undefined.

@mramato I look at all of them, they're pretty much just wrappers for loadWithXhr

Oh nevermind, I get what you're saying.  I need to look further up the chain to see what calls loadText

Juse the Core loadXXX functions.  From what I can tell, the functions that need to be updated are loadJson, loadCRN, loadImageViaBlob, and loadKTX.

@mramato ready.  Sorry for misunderstanding that the first time

Thanks.


use ruby 2.6

use a non EOL version of ruby

sadly this is blocked by older rails 4.2 version - closing for now as this will require a rails v5 min bump


Replaced javax Nonnull and Nullable's annotations with Jetbrains

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[x] Internal code
[ ] Library interface (affecting end-user code)
[ ] Documentation
[ ] Other: _____

Closes Issue: NaN
Description
See the v5 project
Replaces all javax.annotation.Nonnull with org.jetbrains.annotations.NotNull
And replaces all javax.annotation.Nullable with org.jetbrains.annotations.Nullable
Reordered imports

Wrong target and start branch


Overall code cleanup

The codebase is pretty messy right now, this issue suggests what to fix to change that.

Remove unused imports like this:

const fetch = require('cross-fetch') // Not Used
const path = require("path")
const express = require('express')
const bodyParser = require('body-parser') // Not Used
const url = require('url') // Not Used
const querystring = require('querystring') // Not Used
const fs = require('fs') // Not Used
const SpotifyWebApi = require('spotify-web-api-node')
const cors = require('cors');

Remove unused vars, for example:

let songName, songArtist, songImageURL; // Not Used

Use await for the newToken function instead of the current then method:
Use awaits instead of thens in the searchTracksByName and searchTracksById functions
Use a join instead of this:

    for (let i = 0; i < artistList.length; i++) {
        if (i==artistList.length-1) {
            artistString += artistList[i]
        }
        else {
            artistString += artistList[i] + ", "
        }
    }

Merge the searchTracksByName and searchTracksById functions. I suggest to provide the function with a string called searchType using which the function decides whether to call the spotify API for song data like in the searchTracksByName function or like in the searchTracksById function.
Remove unused comments, for example:

            // const spotifyCard = {
            //     spotifyCardURL: cardURL
            // }
            // res.render('api', spotifyCard)
            // res.send(cardURL)
            // res.write('<img src = "'+cardURL+'">');
            // console.log(cardURL) // Image which we want
            // fs.writeFileSync('./test.png', buffer)

These are all of my suggestions for now, I can do all of them, let me know if I should do this and which ones.

yeah you can go with
1st, 5th, 7th. Others I want for further development. :+1:


update goreleaser

What type of PR is this?
/kind cleanup
/kind feature
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:

update goreleaser

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: cpanato
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [cpanato]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign @Issif

LGTM label has been added.  Git tree hash: deae971634e23b318ff36b34bc797a023ce94a7b


Feature#170

Concrete hexagonal architecture migration

Fixe coverage front conflicts (remove tracked files)
Continue mapping courses -> pages -> posts


Use a separate py file to register nlp models and provide an appropriate dim_param_dict with some sane defaults

Tested and was able to get to some numerical failures!!!!

Thanks!


SRv6 L3VPN message

Couple cosmetic changes:
local_block_length to locator_block_length
local_node_length to locator_node_length
optional: send Argument field even when empty

Closing, PR #84 implemented requested changes


Revert PM power state constraint code

PR was merged without any reviews from device model maintainer. I don't think changes in device.h are acceptable, a better solution is required to not pollute device.h with PM-related code. PM code in device.h was removed a long time ago to keep responsibilities clear, that PR seems to go against such principles by introducing unnecessary coupling again.

I missed the original too. This was not well thought trough. If it is a very specific use case, why generalizing this on all devices?

This is optional and depends on device, e.g it is in a power rail that will be power down when the SoC change states.
It is not an unusual use case, there are many drivers that set power state constraints to prevent the SoC to go to certain power states and it is hardcoded what makes them less portable.

There is still time to revert this before this becomes a bulky legacy.

The implementation is not really important and can change, only the API / functionality needs to be preserved.

PM code in device.h was removed a long time ago to keep responsibilities clear, that PR seems to go against such principles by introducing unnecessary coupling again.
That is not entirely true, device  has reference to  pm (https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/device.h#L429) and it is part of device definition which is not much different from these changes.
That's said, that is not device power management, a device may need / use it without even support device power management since it is related with system power management.
Please what is the biggest problem with current implementation ? Be defined in all devices when the feature is enabled ? or just because it is define in the device struct ?
It can't be added in the power management struct because it is not part of device power management.

@gmarull  what are you expecting the TSC to do here? If this is an escalation, please follow the process outlined here before escalating to the TSC:

I do not see any attempt to resolve any technical differences in the PR/issue or other forums.

It would be nice to have comments replied otherwise there is no review / discussion. It shouldn't be an one way conversation :/

I have a prototype removing it from device.h. https://github.com/zephyrproject-rtos/zephyr/pull/75003

@gmarull what are you expecting the TSC to do here? If this is an escalation, please follow the process outlined here before escalating to the TSC:

I do not see any attempt to resolve any technical differences in the PR/issue or other forums.

Just flagged as TSC because no new features are allowed now, so I thought it would require "special" approvals.

The feature was reviewed following all required process. Removing is not the right thing to do IMHO, if there is a better way we should work on it and not removing.

I'm fine with an alternative solution as shown in #75003. I opened this PR to propose a revert if none was provided before the release. As explained in there, the main concerns from a device model perspective are:

Unnecessary coupling between device model and PM.
struct device will get bigger for every device when the feature is enabled, even if the device doesn't require the feature. This used to be the same for device PM but was fixed a long time ago by struct device just holding a pointer to resources allocated by each device, based on its requirements.

While the PR followed the process, it introduced non-trivial changes to device.h (e.g. modify the struct device layout). This requires some extra approvals IMHO, even if I wasn't the assignee. Processes will never be perfect, people need to make sure to tag/ping relevant people for these kinds of changes, and accept a potential revert or breaking change if this does not happen.

Just flagged as TSC because no new features are allowed now, so I thought it would require "special" approvals.

Just for info: The TSC needs to get involved only when such a PR is ready to merge otherwise. (meaning it passes CI, it has the appropriate approvals, and so forth)

The feature was reviewed following all required process. Removing is not the right thing to do IMHO, if there is a better way we should work on it and not removing.

I'm fine with an alternative solution as shown in #75003. I opened this PR to propose a revert if none was provided before the release. As explained in there, the main concerns from a device model perspective are:
* Unnecessary coupling between device model and PM.

That is open to discuss since that is an information that device wants to know. The proposed solution is moving it way from here in the cost of having to lookup a list to find a device constrainsts.

* struct device will get bigger for every device when the feature is enabled, even if the device doesn't require the feature. This used to be the same for device PM but was fixed a long time ago by struct device just holding a pointer to resources allocated by each device, based on its requirements.

That is true, but it works exactly the same way you are saying was fixed a long time ago, holding a reference to an external object. It is not like the list of dependencies are part of the struct.

While the PR followed the process, it introduced non-trivial changes to device.h (e.g. modify the struct device layout). This requires some extra approvals IMHO, even if I wasn't the assignee. Processes will never be perfect, people need to make sure to tag/ping relevant maintainers for these kinds of changes, and accept a potential revert or breaking change if this does not happen.

@gmarull  you were in the review list since the beginning and the pr was discussed for a long time, anyways I don't want to go this path ...
Honestly, I think the other solution is fine for the problem it is addressing but removing the whole feature without caring with who needs it and without asking for changes or suggestions  .... amuses me.

The feature was reviewed following all required process. Removing is not the right thing to do IMHO, if there is a better way we should work on it and not removing.

I'm fine with an alternative solution as shown in #75003. I opened this PR to propose a revert if none was provided before the release. As explained in there, the main concerns from a device model perspective are:
* Unnecessary coupling between device model and PM.

That is open to discuss since that is an information that devices want to know. The proposed solution is moving it way from here in the cost of having to lookup a list to find a device constrainsts.

This is really up to you, I, personally, don't care about PM anymore, but I do about device.h, and as a maintainer of device.h I don't find the current solution acceptable. There are likely other solutions, like re-using struct pm_device already referenced in struct device. After all, you're storing per-device information.

* struct device will get bigger for every device when the feature is enabled, even if the device doesn't require the feature. This used to be the same for device PM but was fixed a long time ago by struct device just holding a pointer to resources allocated by each device, based on its requirements.

That is true, but it works exactly the same way you are saying was fixed a long time ago, holding a reference to an external object. It is not like the list of dependencies are part of the struct.

While the PR followed the process, it introduced non-trivial changes to device.h (e.g. modify the struct device layout). This requires some extra approvals IMHO, even if I wasn't the assignee. Processes will never be perfect, people need to make sure to tag/ping relevant maintainers for these kinds of changes, and accept a potential revert or breaking change if this does not happen.

@gmarull you were in the review list since the beginning and the pr was discussed for a long time, anyways I don't want to go this path ...
Honestly, I think the other solution is fine for the problem it is addressing but removing the whole feature without caring with who needs it and without asking for changes or suggestions .... amuses me.

Zephyr has a wide audience, and core areas should be well-maintained. If a core area is touched in a non-trivial way and the process doesn't enforce reviews, it should be PR author responsibility to ensure it gets proper reviews, or, accept a potential revert until the feature is iterated to an acceptable state.

The feature was reviewed following all required process. Removing is not the right thing to do IMHO, if there is a better way we should work on it and not removing.

I'm fine with an alternative solution as shown in #75003. I opened this PR to propose a revert if none was provided before the release. As explained in there, the main concerns from a device model perspective are:
* Unnecessary coupling between device model and PM.

That is open to discuss since that is an information that devices want to know. The proposed solution is moving it way from here in the cost of having to lookup a list to find a device constrainsts.

This is really up to you, I, personally, don't care about PM anymore, but I do about device.h, and as a maintainer of device.h I don't find the current solution acceptable. There are likely other solutions, like re-using struct pm_device already referenced in struct device. After all, you're storing per-device information.

That is not part of device power management, that is why it was not stored in struct pm_device. A device may need it without having device power management enabled.

* struct device will get bigger for every device when the feature is enabled, even if the device doesn't require the feature. This used to be the same for device PM but was fixed a long time ago by struct device just holding a pointer to resources allocated by each device, based on its requirements.

That is true, but it works exactly the same way you are saying was fixed a long time ago, holding a reference to an external object. It is not like the list of dependencies are part of the struct.

While the PR followed the process, it introduced non-trivial changes to device.h (e.g. modify the struct device layout). This requires some extra approvals IMHO, even if I wasn't the assignee. Processes will never be perfect, people need to make sure to tag/ping relevant maintainers for these kinds of changes, and accept a potential revert or breaking change if this does not happen.

@gmarull you were in the review list since the beginning and the pr was discussed for a long time, anyways I don't want to go this path ...
Honestly, I think the other solution is fine for the problem it is addressing but removing the whole feature without caring with who needs it and without asking for changes or suggestions .... amuses me.

Zephyr has a wide audience, and core areas should be well-maintained. If a core area is touched in a non-trivial way and the process doesn't enforce reviews, it should be PR author responsibility to ensure it gets proper reviews, or, accept a potential revert until the feature is iterated to an acceptable state.

Zephyr has a wide audience, and core areas should be well-maintained. If a core area is touched in a non-trivial way and the process doesn't enforce reviews, it should be PR author responsibility to ensure it gets proper reviews, or, accept a potential revert until the feature is iterated to an acceptable state.

please do not make up rules, it is the responsibility of the maintainer of an area to monitor changes to that area and review them. In this case, you were added as a reviewer and had plenty of time to take a look at the change. It is as simple as searching for PRs labeled with the areas you maintain on a regular basis, for example this filter.  And that if as a maintainer you did not get the notification or if you have not noticed the change coming in....
Putting the responsibility on the submitter to go after each reviewer just does not work and does not scale.
Please do not use reverts as a way to get things resolved, this does not always work and in many cases can be very counter-productive. In this case, file a bug, make it a blocker or whatever and negotiate the best way forward through productive discussions.
Nobody was acting  maliciously here or trying to work-around the system. Like 100s of PRs every week, reviews are not done in time or things fall down the crack and we have to learn how to deal with that.
Here is one way this could be avoid in the future, will cover similar cases, but not all of them. https://github.com/zephyrproject-rtos/zephyr/pull/75016

Zephyr has a wide audience, and core areas should be well-maintained. If a core area is touched in a non-trivial way and the process doesn't enforce reviews, it should be PR author responsibility to ensure it gets proper reviews, or, accept a potential revert until the feature is iterated to an acceptable state.

please do not make up rules,

I’m not making any rules, just applying common sense, based on what I see happening in other areas.
it is the responsibility of the maintainer of an area to monitor changes to that area and review them. In this case, you were added as a reviewer and had plenty of time to take a look at the change. It is as simple as searching for PRs labeled with the areas you maintain on a regular basis, for example this filter. And that if as a maintainer you did not get the notification or if you have not noticed the change coming in....

Putting the responsibility on the submitter to go after each reviewer just does not work and does not scale.

Larger projects than Zephyr seem to succeed with less rules, but they tend to have a stronger core team IMHO.

Please do not use reverts as a way to get things resolved, this does not always work and in many cases can be very counter-productive. In this case, file a bug, make it a blocker or whatever and negotiate the best way forward through productive discussions. Nobody was acting maliciously here or trying to work-around the system. Like 100s of PRs every week, reviews are not done in time or things fall down the crack and we have to learn how to deal with that.

Reverts are a way to remove features that were not reviewed properly or prematurely merged, so a new iteration can be re-introduced later. A quick fix is also fine, I never opposed to that.

Here is one way this could be avoid in the future, will cover similar cases, but not all of them. #75016

I doubt more rules will avoid issues like this in the future. It’s just too easy to get PRs touching multiple areas merged.

https://github.com/zephyrproject-rtos/zephyr/pull/75003 merged


Does not work with example when generating from https://github.com/graphql/swapi-graphql

I'm runngin the server with npm start and generating with
npx graphqelm http://localhost:56196/? --output src --base Swapi

when running example from https://github.com/dillonkearns/graphqelm/blob/11.1.0/examples/src/Starwars.elm I got error
Starting downloads...

  ● Skinney/murmur3 2.0.6
  ● elm-community/json-extra 2.7.0
  ● elm-lang/virtual-dom 2.0.4
  ● elm-lang/core 5.1.1
  ● rtfeldman/elm-css-util 1.0.2
  ● krisajenkins/remotedata 4.4.0
  ● elm-community/list-extra 7.1.0
  ● lukewestby/elm-string-interpolate 1.0.2
  ● elm-lang/html 2.0.0
  ● elm-lang/websocket 1.0.2
  ● rtfeldman/hex 1.0.0
  ● dillonkearns/graphqelm 11.1.0
  ● elm-lang/http 1.0.0
  ● elm-community/string-extra 1.4.0
  ● rtfeldman/elm-css
13.1.1
Packages configured successfully!
I cannot find module 'Swapi.Enum.Episode'.

Module 'Main' is trying to import it.

Potential problems could be:
  * Misspelled the module name
  * Need to add a source directory or new dependency to elm-package.json

Works with this https://graphqelm.herokuapp.com though.

Hey @rofrol, the StarWars example code is based off of the GraphQL demo, but I have some tweaks in order to demo some of the Graphqelm features. https://graphqelm.herokuapp.com is running code from this repo, so you'd need to run this locally to generate the code: https://github.com/dillonkearns/graphqelm-demo.


Initial Visual Tests

I expect this will change as more tests are added, but hopefully it's a reasonable starting point.

I think it makes sense to get merged in even unfinished. It gives a
structure to any visual tests others may want to add.
On Tue, 6 Jan 2015 15:22 James Leftley<EMAIL_ADDRESS>wrote:

I expect this will change as more tests are added, but hopefully it's a
reasonable starting point.
You can merge this Pull Request by running
git pull https://github.com/jleft/d3-financial-components visual-tests
Or view, comment on, or merge it at:
https://github.com/ScottLogic/d3-financial-components/pull/214
Commit Summary

Initial commit for visual tests
Added livereload
Add fc extent to indicator tests
Add scale (date time, linear) and gridlines tests
Add bar series visual test

File Changes

M Gruntfile.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-0
(27)
A visual-tests/assets/style.css
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-1
(26)
A visual-tests/index.html
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-2
(97)
A visual-tests/test-scripts/indicators/bollingerBands.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-3
(65)
A visual-tests/test-scripts/indicators/movingAverage.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-4
(64)
A visual-tests/test-scripts/indicators/relativeStrengthIndex.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-5
(53)
A visual-tests/test-scripts/scale/d3-time-d3-linear.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-6
(63)
A visual-tests/test-scripts/scale/d3-time-fc-linear.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-7
(63)
A visual-tests/test-scripts/scale/fc-time-d3-linear.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-8
(63)
A visual-tests/test-scripts/scale/fc-time-fc-linear.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-9
(63)
A visual-tests/test-scripts/series/bar.js
https://github.com/ScottLogic/d3-financial-components/pull/214/files#diff-10
(98)

Patch Links:

https://github.com/ScottLogic/d3-financial-components/pull/214.patch
https://github.com/ScottLogic/d3-financial-components/pull/214.diff

—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3-financial-components/pull/214.


Move original request to container

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
❌

Tests pass?
✔

What's the use case for it? That is original request that is not modified by any middleware.

What's the use case for it? That is original request that is not modified by any middleware.

See https://github.com/yiisoft/di/pull/120

Maybe it makes sense to move the part from config/web.php to the yii-web package.

@yiiliveext I know it's useful for https://github.com/yiisoft/di/pull/120 as is but it's very confusing in general.


Hdinsight over ADLS with SQL server

A template to deploy:

An hdinsight cluster using ADLSv1 as storage
A SQL server
A DSS instance preconfigured to use it

Deprecated, will not merge.


[DO NOT MERGE UPSTREAM]

@mjsML Can we close this in favor of #53 and #54?

Yes please

Closing in favor of #53 and #54


Undefined proptypes

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.

Here is the diff that solved my problem:
diff --git a/node_modules/react-native-confirmation-code-input/components/ConfirmationCodeInput.js b/node_modules/react-native-confirmation-code-input/components/ConfirmationCodeInput.js
index 239c85a..a76a0d5 100644
--- a/node_modules/react-native-confirmation-code-input/components/ConfirmationCodeInput.js
+++ b/node_modules/react-native-confirmation-code-input/components/ConfirmationCodeInput.js
@@ -1,10 +1,15 @@
 import React, {Component} from 'react';
 import PropTypes from 'prop-types';
-import { View, TextInput, StyleSheet, Dimensions, ViewPropTypes } from 'react-native';
+import { View, TextInput, StyleSheet } from 'react-native';
 import _ from 'lodash';
+import {
+  ViewPropTypes,
+  TextInputPropTypes,
+} from "deprecated-react-native-prop-types";

 // if ViewPropTypes is not defined fall back to View.propType (to support RN < 0.44)
 const viewPropTypes = ViewPropTypes || View.propTypes;
+const textInputPropTypes = TextInputPropTypes || TextInput.propTypes;

 export default class ConfirmationCodeInput extends Component {
   static propTypes = {
@@ -19,7 +24,7 @@ export default class ConfirmationCodeInput extends Component {
     inactiveColor: PropTypes.string,
     ignoreCase: PropTypes.bool,
     autoFocus: PropTypes.bool,
-    codeInputStyle: TextInput.propTypes.style,
+    codeInputStyle: textInputPropTypes.style,
     containerStyle: viewPropTypes.style,
     onFulfill: PropTypes.func,
   };

This issue body was partially generated by patch-package.

@raazatul7
Without this issue and with better maintainability, you can utilize a fork: https://github.com/retyui/react-native-confirmation-code-field


detailed description

Hello, thank you very much for your contribution. When will the detailed description be released？

Thanks for your interest!
The core implementation of our method is at https://github.com/HPLQAQ/SAM-Deblur/blob/main/basicsr/models/archs/SegNAFNet_arch.py .
Detailed description and config files will be updated after paper acceptance result in a week.

Thanks again for your interest! Our paper has just been accepted to ICASSP 2024.
Detailed description has been released.
Now you can start an experiment easily following instructions in README.
Also, welcome visit our project page for a quick overview of the paper.


Tracker: v2 gas optimization todos

[ ] try preallocate for all, encodePacked statics, and direct encode dynamics in
render-table/record.ts (see https://github.com/latticexyz/mud/pull/422#discussion_r1119458406)

on 2nd thought maybe you were planning to add more issues here, in which case it should be reopened, my comment was about the tightcoder thing (which is the only one here)


[Feature request] Allow throwing an error in key getter function

So, my actual use case is this:
I want to do client-side validation, and I have a general wrapper for useSWRV that passes back refs for data, error, etc. For some query parameters, I want to do client-side validation, and if it errors, I want to assign that to the error ref.
My first thought was: "Oh, maybe I can just throw an error in the key getter." However, that didn't work, as there's no error handling there. I thought maybe I could dynamically pass it to the fetcher function, but I don't see how without messing up hashing of the key. In other words: the query object is reactive, and will trigger a mutate automatically, so this validation has to happen "within" the useSWRV callback somehow.
IMO the easiest would be to allow errors to be thrown in the key getter, which then get assigned to error. Unless there's some other method you can think of?

For some query parameters, I want to do client-side validation, and if it errors, I want to assign that to the error ref.

Does this mean you're wanting to validate the query parameters match a certain format, etc.? If that's the case, wouldn't it be done before the call to swrv?
I'd need to see a reproduction or something to fully understand what you're wanting to do, but as I understand what you're suggesting I don't believe throwing an error in the key getter is ideal.


Update README.md

There were the following issues with your Pull Request

Commit: 57e5f2c7a5484151dc9d572d72b0d3a6cb75d3c0
Commits must be in the following format: %{scope}: %{description}

This message was auto-generated by https://gitcop.com

I sucked up the change...


Bump apiVersion to snapshot.storage.k8s.io/v1

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

Codecov Report

Merging #146 (1196855) into main (33d2d80) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #146   +/-   ##
=======================================
  Coverage   11.18%   11.18%
=======================================
  Files          17       17
  Lines        1681     1681
=======================================
  Hits          188      188
  Misses       1474     1474
  Partials       19       19

Flag
Coverage Δ

unittests
11.18% <ø> (ø)

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

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33d2d80...1196855. Read the comment docs.

LGTM


Why long time no commits

I have a question, Is this tool dead?

HI,
You remind me I did something long ago with this code. I just open a pull
request but it seems the maintainer is not responding at all. There are
about 12 pull requests waiting.
On Sat, May 23, 2020 at 7:57 AM danny<EMAIL_ADDRESS>wrote:

I have a question, Is this tool dead?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/millermedeiros/requirejs-plugins/issues/79, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMMJYWKMRVTLC5QMZ3326TRS5JT3ANCNFSM4NIJJZIA
.

--
איתי מרחב Itay Merchav

yeah, I agree with you.
It look like not as popular as before.
many persion use vue develope the front end.


Bug in CodeSandbox demo

🐛 Bug Report
This is a bug in the CodeSandbox-demo linked from the React & Immer page.
The rendered demo-page shows none of the 2 checkboxes being checked, and the sentence "Tasks left: 1".
I would expect the sentence to be "Tasks left: 2".
The todos in the collection have the attribute done. The state of the checkbox though is based on an attribute named finished.
The following patch should fix the example:
diff --git a/src/index.js b/src/index.js
index cc78d65..7cc5e4b 100644
--- a/src/index.js
+++ b/src/index.js
@@ -58,7 +58,7 @@ const Todo = memo(({ todo, onToggle }) => (
   <li>
     <input
       type="checkbox"
-      checked={todo.finished}
+      checked={todo.done}
       onClick={() => onToggle(todo.id)}
     />
     {todo.title}

Fixed, thanks for noticing!

hey @mweststrate, seems this does not be fixed? https://codesandbox.io/s/use-immer-bvd5v?file=/src/index.js


How to go beyond pure Python?

The goal, particularly for the machine parser, is to use a faster platform for parsing than standard Python, while still being a Python module. It's not clear what is the best option, in terms of speed and efficiency, startup time, availability/portability, maintainability, licensing, etc. Here are some options:

PyPy -- the nice thing here is that nothing is really required besides using PyPy
Cython -- works well with CPython, can get very fast
CPython extension modules -- even more control, but more expertise needed
llvmlite -- maybe good for a state machine, but it's not clear how to work with string data instead of numbers

I recently added machine.pyx as a Cython solution. It is now nearly as fast as my old textpy implementation, but without the recursion limit.
I think this can be closed now.


Crash after extended run

Hey Kevin:
I have been running for longer periods of time on my logger as some of the non-Vera devices that were failing have been corrected.
I had a multiday run going then received an error:
Exception in thread Thread-848:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 86, in run_poll
    data = json.loads(connect())
  File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 84, in connect
    return connect()
  File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 84, in connect
    return connect()
  File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 84, in connect
    return connect()
  File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 84, in connect
    return connect()

These connect errors repeat go on for an extended number of lines before I get this different part of the exception dump:
 File "/home/sabolcik/.local/lib/python2.7/site-packages/micasaverde_vera/vera_connect.py", line 79, in connect
    timeout=1
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 57, in request
    with sessions.Session() as session:
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 392, in __init__
    self.mount('https://', HTTPAdapter())
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 126, in __init__
    self.init_poolmanager(pool_connections, pool_maxsize, block=pool_block)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 162, in init_poolmanager
    block=block, strict=True, **pool_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/urllib3/poolmanager.py", line 155, in __init__
    dispose_func=lambda p: p.close())
  File "/usr/local/lib/python2.7/dist-packages/urllib3/_collections.py", line 47, in __init__
    self._container = self.ContainerCls()
  File "/usr/lib/python2.7/collections.py", line 69, in __init__
    self.__update(*args, **kwds)
  File "/usr/lib/python2.7/abc.py", line 151, in __subclasscheck__
    if subclass in cls._abc_cache:
  File "/usr/lib/python2.7/_weakrefset.py", line 75, in __contains__
    return wr in self.data
RuntimeError: maximum recursion depth exceeded in cmp

My database thread was still running and my other loggers were still logging away.  I will try to dig into the vera_connect file to see if anything makes sense.  I am not wrapping every vera access with a try/except clause but will attempt to put some additional debugging into the threads to see if I can get better visibility.  Based on the logging that I already have I think this error occurred in the vera callback thread.  This is the only place that I access the vera library after the initial call.
Does this exception indicate anything obvious to you?

One additional datapoint.  I was reviewing the code in vera_connect that failed and it looks like you're just trying to send a JSON to the vera and it times out.
Here is the code I am running in my vera event callback:
def device_callback(event):

	update_lock.acquire()
	now = datetime.datetime.now().isoformat()

	name = event.name
	split_event = event.event.split('.')

	if split_event[-1] == 'changed':
		parameter_name = split_event[-2:][0]

		try:
			vera_log.update_value(name, parameter_name)
			logging.info('--------------------------------------------')
			logging.info(now)
			logging.info("Callback: " + event.event)
			logging.info(name)
			logging.info(parameter_name)
			logging.info("Value: " + vera_log.get_value(name, parameter_name))
			logging.info('--------------------------------------------')
			json = vera_log.get_json()
			update_database(db_client, json)
		except KeyError:
			logging.info("Invalid device: " + name + " " + parameter_name)

	update_lock.release()

The vera_log.update_value is a simple class I have the maintains some data to make it easy to write to the database.  It basically just calls getattr on the vera instance for the particular device that created the callback.
I added the following additional exception handler after the KeyError exception:
except:
			logging.info("Error logging Vera sample in device_callback")
                        traceback.print_exc()

Not sure the library will recovery gracefully if I simply ignore this failure but I will run it and give it a shot.

yes that error does make sense to me, It could be that your Vera took a long time to reboot. or the lua engine froze up on it. some kind of a network issue. I do know that at say like 2:00 AM every day the Vera does a zwave heal. and when doing this it shuts down all other communications. it could have taken to long and you banged against the recursion depth limit in python. instead of making a looping call to connect I will use a while loop. and i will also generate a disconnected and connected event

I have updated the library. give it a go. I also added 2 events vera.connected and vera.disconnected this way you can have your program change what it is doing when this happens. if you are not running the polling loop the only way a disconnect/connect event will take place is when you change something in the library.

After reviewing the code it did appear that the event was a timeout with my
Vera.  Wasn't sure the best way to handle the timeout.
With your most recent change what would be the preferred way to handle a
timeout or do I even need to worry about a timeout condition?  I only read
the Vera at initial startup and in the event handler.  Does your change to
a while loop mean that the event handler won't get called in the
disconnected condition and hence my code will not get invoked in the event
handler if the Vera is disconnected?  That way I don't need to do anything
special like checking the disconnect state.
Thanks again for the quick turnaround.  I will download the updated code
this evening.
Regards....
On Mon, Feb 19, 2018 at 12:01 PM, Kevin Schlosser<EMAIL_ADDRESS>wrote:

I have updated the library. give it a go. I also added 2 events
vera.connected and vera.disconnected this way you can have your program
change what it is doing when this happens. if you are not running the
polling loop the only way a disconnect/connect event will take place is
when you change something in the library.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/5#issuecomment-366766447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhSL40G-jvC-cfJ3-bBtVpI5QZQobmMIks5tWbcEgaJpZM4SJ0K_
.

no events will take place when it is in a disconnected state. save for the event letting you know that it has become disconnected.
You can use the disconnected event to maybe give you some kind of a notification the thing has become disconnected.
The modifications I made does not recurse at all and will keep on looping until the end of time connection or no connection. it only produces a single event for connection and disconnection while in the loop. I will need to modify this so it will produce an event on poll startup.
I do have another library i keyed up that you can send SMS and MMS text messages with. I do not have it up on github i can put it up if ya like. this way you can get a text message sent to you phone if there is some kind of a connection issue.

Hi Kevin:
Thanks for the quick response.  Let me get this current version up and
running.  I'll ping you to let you know if I want to go the full SMS route.
On Tue, Feb 20, 2018 at 4:59 PM, Kevin Schlosser<EMAIL_ADDRESS>wrote:

no events will take place when it is in a disconnected state. save for the
event letting you know that it has become disconnected.
You can use the disconnected event to maybe give you some kind of a
notification the thing has become disconnected.
The modifications I made does not recurse at all and will keep on looping
until the end of time connection or no connection. it only produces a
single event for connection and disconnection while in the loop. I will
need to modify this so it will produce an event on poll startup.
I do have another library i keyed up that you can send SMS and MMS text
messages with. I do not have it up on github i can put it up if ya like.
this way you can get a text message sent to you phone if there is some kind
of a connection issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/5#issuecomment-367151186,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhSL499FSLvABFjy_JZqQRGNVI-yAxRJks5tW05cgaJpZM4SJ0K_
.

I was able to get it running by removing what I think is the statement that raises the event for connected and disconnected  in vera_connect.py.  I'm not sure why the connect and disconnect call events behaves differently than the others
def send(self, **params):
       if 'output_format' not in params:
           params['output_format'] = 'json'

       self._lock.acquire()

       try:
           response = requests.get(self.URL, params=params)
           if not self._connected:
               self._connected = True
               #Notify('vera.connected', self)
       except (ConnectionError, Timeout, ReadTimeout, ConnectTimeout):
           if self._connected:
               self._connected = False
               #Notify('vera.disconnected', self)
           time.sleep(random.randrange(1, 5) / 10)
       else:
           try:
               return json.loads(response.content)
           except ValueError:
               if 'ERROR' in response.content:
                   if 'No implementation' in response.content:
                       raise VeraNotImplementedError
                   if (
                       'Device does not handle service/action' in
                       response.content
                   ):
                       raise VeraUnsupportedByDevice
       finally:
           self._lock.release()

Also had to pull the Notify events out of the run_poll() function.

it's because i am passing the parameters to Notify Backwards,.
swap the string literal with the self.
so
Notify(self, 'vera.disconnected')

would become
Notify('vera.disconnected', self)

Yup.  That fixed it.  Thanks will keep you posted on any additional
findings.
On Wed, Feb 21, 2018 at 11:39 PM, Kevin Schlosser<EMAIL_ADDRESS>wrote:

it's because i am passing the parameters to Notify Backwards,.
swap the string literal with the self.
so
Notify(self, 'vera.disconnected')
would become
Notify('vera.disconnected', self)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/5#issuecomment-367573406,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhSL4zql9R2WbnadPgRksxohwZNwtB7-ks5tXP2sgaJpZM4SJ0K_
.

I didn't know if you are still using this library or not. and if you are I just updated it. It has better output handling (using the logging module) and is also python 3.3+ compatible. I already made the changes posted here. I was also read over your other issue again. and I was thinking to myself.. I am such a ding dong.. this is an easy thing to code up.

# vera connection assumed

# start the polling loop. this is the speed in which the micasaverde_vera
# library is going to update it's data from the vera. every 10 seconds.
# you can set this to 0.1 without causing too much of a performance impact on the vera
vera.start_polling(10.0)

import threading
event = threading.Event()

def loop():
    while not event.is_set():
        for device in vera.devices:
            watts = getattr(device, 'watts', None)
            if watts is None:
                watts = getattr(device, 'Watts')
            if watts is not None:
                # do your code here to handle the watts
                pass
        # 60 second stall between loops
        event.wait(60.0)

t = threading.Thread(target=loop)

# make sure the thread gets closed if the app crashes for some reason.
t.daemon = True

# start the thread
t.start()

# wait forever or until a keyboard interrupt occurs
try:
    event.wait()
except KeyboardInterrupt:
    # set the event so the loop closes gracefully
    event.set()
    # join the thread if it is still running so it can finish up
    # what it is doing and the process can close gracefully
    if t.is_alive():
        t.join()

vera.disconnect()

Hey Kevin:
Thanks for the update.  I literally just got back to using the library
again.  I updated to a VeraPlus from my old VeraLite so that took a fair
amount of monkeying to get it right.   I'm hoping that the VeraPlus is more
robust than the VeraLite.
I have a pretty complicated logging system with a bunch of different data
sources feeding my database in addition to the Vera.  I have separate
loggers for my whole house energy monitor, my pool pump, my outdoor weather
station, etc.  They are all derived from a single logger class with
different guts underneath.
I have an issue where every few weeks the system will crash.  Ultimately I
wanted to setup a cron job to restart my logger every evening at midnight
to handle the hanging situation.  Unfortunately I couldn't get a shell
script that would fire off from cron to work properly so I never got around
to it.  I'm hoping that with some additional tweaking I can make that work.
I'll try installing your latest library in the coming days and see how it
works for me.
Thanks again for putting such a great tool together.
Regards,
Ross
On Tue, Sep 10, 2019 at 3:22 PM Kevin Schlosser<EMAIL_ADDRESS>wrote:

I didn't know if you are still using this library or not. and if you are I
just updated it. It has better output handling (using the logging module)
and is also python 3.3+ compatible. I already made the changes posted here.
I was also read over your other issue again. and I was thinking to myself..
I am such a ding dong.. this is an easy thing to code up.
vera connection assumed
start the polling loop. this is the speed in which the micasaverde_vera # library is going to update it's data from the vera. every 10 seconds.# you can set this to 0.1 without causing too much of a performance impact on the vera
vera.start_polling(10.0)
import threading
event = threading.Event()
def loop():
while not event.is_set():
for device in vera.devices:
watts = getattr(device, 'watts', None)
if watts is None:
watts = getattr(device, 'Watts')
if watts is not None:
# do your code here to handle the watts
pass
# 60 second stall between loops
event.wait(60.0)
t = threading.Thread(target=loop)
make sure the thread gets closed if the app crashes for some reason.
t.daemon = True
start the thread
t.start()
wait forever or until a keyboard interrupt occurstry:
event.wait()except KeyboardInterrupt:
# set the event so the loop closes gracefully
event.set()
# join the thread if it is still running so it can finish up
# what it is doing and the process can close gracefully
if t.is_alive():
    t.join()

vera.disconnect()
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/5?email_source=notifications&email_token=AIKIXY4QPADQWRDUXD5NVSTQI76YHA5CNFSM4ERHIK72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ML22I#issuecomment-530103657,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIKIXY6SLJGZG3XDHFOVPOTQI76YHANCNFSM4ERHIK7Q
.

well how about this. I can add the bits needed so that this thing can run as a service and you can connect to it from a loopback socket connection or if you want to do up a remote connection I can do that as well and secure it with AES and optionally SSL.
The whole system will operate the same for the most part. the only things that would be added that would be different is on the client side you point the library at the "server" service instead of a Vera and then you supply the password to connect to the service and optionally the path to the ssl cert files.
the service will just sit there in a loop receiving updates from the Vera and updating whatever it needs to and it will wait for a client to ask for information.
The funny thing is not a few weeks ago i just coded up this exact same kind of a connection scheme for python-openzwave so it can be installed as a service on Windows, Linux and OSX, it to also allows for remote connections. So it shouldn't be all to hard to do some copying and pasting.
Do NOT test the new version of the library in your production environment. I am not sure if it is running properly and I do not want you to end up with any corrupted data in your database. The Vera I am not worried about because it's not going to change anything on it. I do not know if it is going to build the files correctly. There is another user that posted an issue about it not running in python 3. so I made the changes needed to get it running in python 3. He is still having problem getting it to run. I no longer have a Vera (YAY!!) and I am pretty much heading up python-openzwave now. so my knowledge of the low level portion of ZWave is pretty good.
I do not remember how to get this library running anymore. so if you can chime in on the issue #8 the user seems like they might be newish to python not sure tho. maybe you can walk them through how to connect the library to the vera.

Hey Kevin:
Thanks for the update.  I'd be game to try the Unix service but would
likely need some sample code showing how to interface with it.  It's been a
long time since I've done anything with services.  So if you're game I'm up
for it.
I can check out the issue on github and see if I can remember the steps I
went through to get everything working.  Surprisingly moving to the new
Vera wasn't too bad with my system.  I needed to do some configuration on
the devices on my Vera so they would report wattage properly but the vera
python code worked without a hitch.
Interesting that you coded the OpenZwave library.  I run 1/2 of the IoT
business at Silicon Labs and we purchased ZWave last year.  It's a great
technology and gives us pretty much every wireless portfolio under one roof.
Regards,
Ross
On Thu, Sep 19, 2019 at 2:02 AM Kevin Schlosser<EMAIL_ADDRESS>wrote:

well how about this. I can add the bits needed so that this thing can run
as a service and you can connect to it from a loopback socket connection or
if you want to do up a remote connection I can do that as well and secure
it with AES and optionally SSL.
The whole system will operate the same for the most part. the only things
that would be added that would be different is on the client side you point
the library at the "server" service instead of a Vera and then you supply
the password to connect to the service and optionally the path to the ssl
cert files.
the service will just sit there in a loop receiving updates from the Vera
and updating whatever it needs to and it will wait for a client to ask for
information.
The funny thing is not a few weeks ago i just coded up this exact same
kind of a connection scheme for python-openzwave so it can be installed as
a service on Windows, Linux and OSX, it to also allows for remote
connections. So it shouldn't be all to hard to do some copying and pasting.
Do NOT test the new version of the library in your production environment.
I am not sure if it is running properly and I do not want you to end up
with any corrupted data in your database. The Vera I am not worried about
because it's not going to change anything on it. I do not know if it is
going to build the files correctly. There is another user that posted an
issue about it not running in python 3. so I made the changes needed to get
it running in python 3. He is still having problem getting it to run. I no
longer have a Vera (YAY!!) and I am pretty much heading up python-openzwave
now. so my knowledge of the low level portion of ZWave is pretty good.
I do not remember how to get this library running anymore. so if you can
chime in on the issue #8
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/8 the user seems
like they might be newish to python not sure tho. maybe you can walk them
through how to connect the library to the vera.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kdschlosser/MiCasaVerde_Vera/issues/5?email_source=notifications&email_token=AIKIXY5SL3SRY2Y3KI2CMH3QKMPXTA5CNFSM4ERHIK72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7COEJY#issuecomment-532996647,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIKIXYZL7G64BFNMKBBAVNLQKMPXTANCNFSM4ERHIK7Q
.

I do not code OpenZWave.. I do code python-openzwave. python-openzwave is a python binding for OpenZWave. there is all kinds of code that has to be written to handle the interface between Python code and C++ code. and also an Python API to know what to do with the data from OpenZWave.
I actually just asked sent in my first support request to Sil about the ZWave Specification. and there was an error or an inconsistency between the supplied header file and what the written specification was stating... I am also trying to get a better understabnding of how the THERMOSTAT_FAN_STATE works in terms of knowing what data a node can send and how I would go about asking the node for what it supports in terms of the state... I am waiting for an answer back on that last part..


#886 Added paramDef getter/setter methods in propertiesController

Fixes #886
Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Modified App.js, common-canvas-dev.js and common-canvas.js files in harness to test this PR -

Used structureTableParamDef for testing. Logged response of PropertiesController.getParamDef() and PropertiesController.getPropertyValues() methods -


Not clear what NonRestrictive means

Not clear what NonRestrictive means. What makes it different from Disabled?

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

ID: 5e9a88b1-f7e9-e4cb-6b06-4d9e11ef4e35
Version Independent ID: c9b7c384-2643-75e6-c9cd-308d3b77042f
Content: TestPermissions Property - Business Central
Content Source: dev-itpro/developer/properties/devenv-testpermissions-property.md
Service: dynamics365-business-central
GitHub Login: @blrobl
Microsoft Alias: SusanneWindfeldPedersen

This issue is hanging now for almost 5 month. When is this going to be picked up?

@SusanneWindfeldPedersen could you please give an update?

While working on the 2nd edition of my test automation book I cleared it for myself, but I still think this topic could be improved on this.
This is how I have described the 3 main values of the TestPermissions property:

Disabled: Based on this value the test runner should not implement any permission restrictions.
NonRestrictive: Based on this value the test runner could implement a broad set of user permissions.
Restrictive: Based on this value the test runner could implement a restricted set of user permissions. Note that this is the default value.

Congratulations on your book. And thanks for the patience. We have updated the topic with more information since - in an earlier refresh. Thanks.


RE3 an error occurred during seed generation

Every seed for RE3 an error occurs and it says my directory is good.

Can you please upload the log file, you can click Jill log to open it.

BioRand 3.0.1 (412b94e)
Seed: R730-6AXH-T6HHHH4ZCY000N49F49200000000ZZZZ00Z
Player: 0 Jill
Scenario: A
Creating Original Room Graph:
Exception: Object reference not set to an instance of an object.
at IntelOrca.Biohazard.DoorRandomiser.GetOrCreateNode(RdtId rdtId)
at IntelOrca.Biohazard.DoorRandomiser.CreateOriginalGraph()
at IntelOrca.Biohazard.BaseRandomiser.GenerateRdts(RandoConfig config, IRandoProgress progress, FileRepository fileRepository)
ok i clicked Jill log I hope I got it right, I figured Jill log

I can't reproduce it, it might be caused by a difference in your version of RE 3. Where did you get your version from, is it possible for me to get the same version?

I got Xplosiv brand or what ever, turned it into Sourcenext by adding files and added files for Seamless HD project

Closing due to incompatible version