bin/tfx is using dos line endings

bin/tfx is in windows mode
which gives me
env: node\r: No such file or directory
on the mac
I'm not sure if the file is being uploaded to npm or not, but I'm under the impression npm installs it
Using npm:
2.14.7

Working on a fix. Thanks.

Note that it doesn't affect what's in npm.  We pushed to npm with a LF after the shebang.
@halkeye - are you saying you were building or you got that after installing from npm

I did an npm install
On Nov 18, 2015 10:41 AM, "Bryan MacFarlane"<EMAIL_ADDRESS>wrote:

Note that it doesn't affect what's in npm. We pushed to npm with a LF
after the shebang.
@halkeye https://github.com/halkeye - are you saying you were building
or you got that after installing from npm
—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/tfs-cli/issues/56#issuecomment-157815208.

OK - investigating

I can't repro.
Here's what I did:
$ sudo npm install tfx-cli

$ tfx

worked

OK - I believe I fixed it.  I just pushed 0.3.1.

:+1: works for me!

Great.  Thanks for confirming


Update the documentation with the latest features

Feature Request
Description
It seems that the documentation is not up to date with the latest features.
I am talking in particular about the use of shared storage like Ceph.
It also seems that the roadmap is not up to date in the README.
Will this be updated soon?

Nice catch, thank. Yep, readme is outdated.
Probably, better to create issues as roadmap.
Thanks.


Add the -r flag for requirements.txt

Not sure why the Travis build keeps failing. Any ideas?

I think the root problem from below is that the ./travis/jekyll_build.sh script is checking the URLs linked to from the website and it is unable to get a valid response from https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/ which is causing the ./travis/jekyll_build.sh script to fail, which causes the Travis operation to fail.
Perhaps the Docker container does not have certs and so the request to https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/  is failing with Peer certificate cannot be authenticated with given CA certificates
Checking 243 external links...
Ran on 189 files!
- ./_www/www/news/index.html
  *  External link https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/ failed: response code 0 means something's wrong.
             It's possible libcurl couldn't connect to the server or perhaps the request timed out.
             Sometimes, making too many requests at once also breaks things.
             Either way, the return message (if any) from the server is: Peer certificate cannot be authenticated with given CA certificates
htmlproofer 3.9.2 | Error:  HTML-Proofer found 1 failure!
The command "./travis/jekyll_build.sh" exited with 1.

@EricBeach thanks Eric, I took a look at some of the previous doc PRs and noticed they built successfully. Any idea why things are different this time?

I just ran ./travis/jekyll_build.sh on GCE machine and got the same error as Travis is reporting.
When I run curl -v https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/from that machine, I get a certificate error. If I run curl -v https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/ from my local machine, everything works fine.
$ curl -v https://www.gcppodcast.com/post/episode-120-forseti-with-nenad-stojanovski-and-andrew-hoying/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to www.gcppodcast.com (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

The link is that the html-proofer is complaining about is working.  Opening #1881 to resolve this, so this can be merged.


The orm:generate-repositories command still uses psr-0

If you run orm:generate-repositories src/, repositories are generated in src/Vendor/Package/, psr-0 style.
Given the fact that psr-0 has been deprecated for over two years, I feel it would be a good step add support for psr-4.
The most straight forward way to do this would be an extra option to orm:generate-repositories called psr4-prefix or something in that spirit. EntityRepositoryGenerator::writeEntityRepositoryClass() could then be changed to remove that prefix from the start of $fullClassName before generating the $path.
If this is a change people would like to see, I'm more then willing to write the code and open a pull request.

Not gonna happen: Doctrine voted against the abbreviated PSR-4 directory prefixing approach ages ago, and still stands against it.
It is needless complexity that isn't needed.
In addition to that, code generators are likely targeted for removal in 3.x.

Doctrine voted against the abbreviated PSR-4 directory prefixing approach ages ago, and still stands against it.

I wasn't aware of that and a search of the issues didn't bring up anything; sorry for bringing it up again. :)
Thanks for the quick response.


[NEW ALGORITHM] Power-Aware Disk Scheduling Algorithm

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:
[NEW ALGORITHM]  Power-Aware Disk Scheduling Algorithm
About:
The Power-Aware Disk Scheduling (PADS) algorithm optimizes disk I/O by balancing power consumption and seek time. Using a modified SCAN approach, the disk head moves in one direction to service requests, reversing only when it reaches the last request or end of the disk. If the next request is beyond a defined distance threshold, the algorithm simulates entering a low-power mode, which reduces unnecessary disk head movement and conserves energy. This approach helps minimize power usage while maintaining efficient request servicing.
Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[X] Contributor in GSSoC-ext
[X] Want to work on it

@pankaj-bind Kindly assign this issue to me.

@pankaj-bind Kindly assign this issue to me.


Build failing for IE 11

Hi!
I also noticed some problem with the transpilation build, I digged a bit into it, I have @ngforage/ngforage-ng5 installed in my package.json and I noticed some weird stuff, during transpilation of @angular/common the source code is taken from esm5 directory while for this ng-forage package it is taken from esm2015 and it causes my build to fail in IE11 because I get the code that contains class syntax, also as far as I remember I've also seen some code from zone.js to also not being transpiled properly. Could someone explain to me how does the resolving of package main file work ? It is very weird to me as every package, but the one mentioned above seems to transpile properly. I checked package.json of if and it looks fine:
...
"es2015": "dist/esm2015/index.js",
  "homepage": "https://github.com/Alorel/ngforage",
  "jsdelivr": "dist/umd/index.min.js",
  "license": "MIT",
  "main": "dist/es5/index.js",
  "module": "dist/esm5/index.js", <--- looks fine
  "name": "@ngforage/ngforage-ng5",

Versions
Angular CLI: 1.6.5
Node: 9.3.0
OS: win32 x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.6.5
@angular-devkit/build-optimizer: 0.0.41
@angular-devkit/core: 0.0.28
@angular-devkit/schematics: 0.0.51
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.5
@schematics/angular: 0.1.16
typescript: 2.6.2
webpack: 3.10.0

Repro steps

create project
npm install --save @ngforage/ngforage-ng5
ng build --prod

OR

clone https://github.com/zaalbarxx/angular-ie11test
ng build --prod

Observed behavior
main.js file contains code with class keyword and the code from ngforage-ng5 is in ES6 version even though it should not
Desired behavior
main.js file should contain /dist/esm5/ version of ng-forage which is ES5 and IE11 ready

+1

+1

I encountered the same problem importing es6 version of Swiper: vendors bundle contains class keyword even if I'm targeting es5.
Just a workaround for the case if you have the opportunity:

import library as global script,
download types or declare them in src/typings.d.ts and DON'T import modules or declarations inside any .ts file.

This worked for me, hope also for someone else until this bug is solved.

Any update on this ?? Anyway, thanks for this workaround @davidefavia , looks like not quite optimal, but I will check it out.

Not sure if this issue (#9508) is similar, but I wanted to link to it from here for awareness.
I'm having the same issue with my build in IE 11, both ng serve, ng serve --prod, and ng build --prod. I am using Angular CLI v1.7.3. Has anyone looked into this issue to determine what might be the root cause?

+1

I have the same issue with IE11 and library ngforage. The problem is only with --prod build and main bundle with contains class syntax and cause IE11 to crash. In debug mode build it works.

It is a problem with the version @ngforage/ngforage-ng5. It shortly became deprecated and new version resolves problem.
from npm :

This package has been deprecated
Author message:
Install<EMAIL_ADDRESS>for Angular 5 and<EMAIL_ADDRESS>for Angular 6. See the changelog at https://github.com/Alorel/ngforage/blob/master/CHANGELOG.md for the one breaking change regarding the module import.

I have a look at this, For Swiper it seems that in the module fields they are shipping ES2015 code thus the ES2015 code is being outputted. This is due that we are not performing any downleveling from our end.
@ngforage seems that they fixed they package structure which solved the issue. My 2 cents is that since the had dts sitting and es2015 code in the same folder they were being resolved incorrectly.

Please contact the author(s) of the Swiper project or file an issue on their issue tracker.


Added create category functionality

Solved #103
Added functionality for listing, creating, updating and deleting categories.
Created a new route (api/categories/category/:id) and a category controller.
https://user-images.githubusercontent.com/59537283/199980849-9712bcb2-1958-40af-8346-55b699c954f3.mp4

Please review it


Bug: Files Crashes When Accessing "Network," "Recycle Bin," or "This PC" Folders

Description
I've encountered an issue where clicking on the "Network," "Recycle Bin," or "This PC" folders, whether through the navigation bar for "Network" or using shortcuts on the desktop or elsewhere, results in Files crashing and becoming unresponsive. I've noticed that this problem occurs exclusively in the column view. Until this issue is resolved, I've found a workaround, which is to pin these folders to favorites.
Steps To Reproduce

Open Files
Click on "Network" folder
Or via a shortcut "This PC" or "Recycle Bin"

Requirements
Investigate and identify the root cause of the crashing issue when accessing "Network", "Recycle Bin", or "This PC" folders.
Files Version
Version <IP_ADDRESS>
Windows Version
22H2 22621.1848
Log File
debug.log

I'm curious... What are the steps to even add it to Favorites?

I can't find a way to navigate to the actual special shell object. It's not listed in Home.
Putting C:$Recycle.Bin or the "S-1-......." folder it contains into Favorites doesn't give full Recycle Bin functionality.
Browsing to Shell:RecycleBin in the address bar gives an error: NotAFolder

Thanks for the report. The log file doesn't show any errors but your issue may be fixed when #12679 is.

@Josh65-2201 I just noticed that all the folders listed with names starting with "Shell:" never respond when launched, except if we add them to favorites.

@Lukiluc29 do you have the option to sync folder preferences enabled?

do you have the option to sync folder preferences enabled?

No.


feat: add OData Version to options

Hey there,
I found an issue when using @cds-dk version 7.2.0 or later in my project.
@cds-dk offers the parameter odata-version which, if left blank, defaults to '4.01'. However if your OData service is still on version 4.0 (which should be the case for most projects), OData functions would will not be compiled correctly. Odata functions can be called without parentheses in OData version 4.01 but not in 4.0.
This PR adds an the odataVersion parameter to the options, so that projects can specify which OData version should be used for the OpenAPI compilation.
Feel free to suggest any changes.
Kind regards,
Yannick

@chgeo did you have a chance to take a look? I think the tests are failing are unrelated to my change.


Object comparison without timestamp

Changes:

Remove object_order_type_id_reverse_version_without_timestamp
Ignore the timestamp when comparing objects if one object does not have a valid timestamp. Invalid timestamps are internally stored as 0 and lead to wrong results when operator< is called. This makes some fixes in Osmium Tool (https://github.com/osmcode/osmium-tool/pull/87, https://github.com/osmcode/osmium-tool/pull/88, https://github.com/osmcode/osmium-tool/pull/94) easier because their code changes can be rejected and only their new unit tests merged into master.

Codecov Report

Merging #250 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
+ Coverage   83.19%   83.21%   +0.01%
==========================================
  Files         276      276
  Lines       22475    22490      +15
==========================================
+ Hits        18699    18714      +15
  Misses       3776     3776

Flag
Coverage Δ

#data_tests
60.78% <ø> (ø)
:arrow_up:

#examples
58.66% <ø> (ø)
:arrow_up:

#unit_tests
79.56% <100%> (+0.01%)
:arrow_up:

Impacted Files
Coverage Δ

test/t/osm/test_object_comparisons.cpp
100% <100%> (ø)
:arrow_up:

include/osmium/osm/object.hpp
98.44% <100%> (+0.02%)
:arrow_up:

include/osmium/osm/object_comparisons.hpp
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Can't see some things

Modpack Version Used
1.16.13
What happened?
I can't my see hand, items in my hands, items dropped on ground, or the outlines on blocks. I've looked through the game settings, mod configs, and the resource packs, and I can't find how to fix this. Halp plz
Screenshots (if applicable)

Relevant latest.log
https://gist.github.com/Mossy-Boi22/531ce867b387656f85b68a022977ec28#file-gistfile1-txt

I did absolutely nothing to my game, I restarted my PC, and the problem resolved itself? I had re-opened Minecraft multiple times with no change, but I restarted my PC and all the above issues are gone. I have no idea what happened, but I can give files if needed to figure out what happened.

Unfortunately, this is a known issue that we have no idea how to fix.
Normally restarting Minecraft by itself (including closing down the
launcher etc) should fix it, I'm not sure why it took a full PC restart for
you.
On Wed, Sep 4, 2024, 2:58 PM Mossy-Boi22 @.***> wrote:

I did absolutely nothing to my game, I restarted my PC, and the problem
resolved itself? I had re-opened Minecraft multiple times with no change,
but I restarted my PC and all the above issues are gone. I have no idea
what happened, but I can give files if needed to figure out what happened.
—
Reply to this email directly, view it on GitHub
https://github.com/katubug/CottageWitchRecast/issues/19#issuecomment-2329863966,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE7XE5WTUROQHZ2TEABHOTLZU5Q7RAVCNFSM6AAAAABNU2Z52WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRZHA3DGOJWGY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

It's alright I was just confused and concerned 😅


Can't publish port with IP binding

I tried to bind several container port to all host interfaces (<IP_ADDRESS>) without success using following config:
    ports: {48004: 48004, 48005: 48005, 48006: 48006, 9001: 9001, 8888: 8888}

Please correct me if I am wrong.

Your syntax looks correct. I will try to reproduce this issue.


"styles()" method not found

Apit reference : https://github.com/d3/d3-selection-multi/blob/master/README.md#selection_styles
but I can't find styles method in selection instance.

Did you import https://github.com/d3/d3-selection-multi ? Note that d3-selection and d3-selection-multi are separate packages, and the methods from d3-selection-multi are not in d3-selection, and also not in the default D3 build.

You are looking for d3-selection-multi.


Fix segfault

Fixes bug where accessing rectangles returned by HAAR detection caused a segfault

Please merge soon!

@deadprogram done. thanks for the reminder


⚠ Bofrost.de has degraded performance

In af25202, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 738 ms

Resolved: Bofrost.de performance has improved in 2977fe5.


Extending FS library

Describe the problem
Hi guys, I'm having a little bit fun with tauri and I found that in FS there is no function for  checkFileExistence (only try catch option).
Yeah I know there is plugin for it, but, I think, this one should be basic functionality. (Like common, everyone has this functionality, python, c++,....)
Describe the solution you'd like
Implement fileExists to fs.
Alternatives considered
No response
Additional context
No response

As i said on discord, there is an open pr for this... https://github.com/tauri-apps/tauri/pull/5060


FAQ

I'm submitting a ...

[ ] bug report
[x] feature request
[ ] design request

What is the current behavior? / What feature/design would you like to implement
Update the current FAQ and implement to the main webpage
The plan would be to:

Ammend 2019 FAQ
Implement in the 2020 webpage

Other info:
Have dependencies on the completion and linking to the

project pitch template
associated guidelines
Information regarding the Brainhack Global Code of Conduct workflow (eg. the committee, dedicated email etc.)
matching algorithm
project pitching workflow

The current amended template of the FAQ is listed here. Please make the amendments over this template first.


Improve user tags and emoji UX

We should be able to navigate through users tag and emoji by pressing up/down arrows, and selecting it by pressing enter key.

Added in https://github.com/antoine92190/vue-advanced-chat/commit/abf4589dd97b56c42fa642d9c82b5d2977f4cb00


Fix upgrade to zabbix7

What this PR does / why we need it:
Zabbix 7 has changed behaviour. DB upgrade can only happen if  server node is single and not HA configured.
DB upgrade is automatically performed by the server node. See comments in #42
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #42

Special notes for your reviewer:
I have disabled the creation of the job that runs the db-inint-script as I do not believe is necessary anymore with new Zabbix behaviour. This is a fundemental change, so rather than delete the template I have just forced the generation condition to false so it is not executed.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped

Agree its not nice, but logs from Server when starting up gave me the impression I did not have an alternative.
 1:20240627:120804.783 Starting Zabbix Server. Zabbix 7.0.0 (revision 49955f1).
 1:20240627:120804.783 ****** Enabled features ******
 1:20240627:120804.783 SNMP monitoring:           YES
 1:20240627:120804.783 IPMI monitoring:           YES
 1:20240627:120804.783 Web monitoring:            YES
 1:20240627:120804.783 VMware monitoring:         YES
 1:20240627:120804.783 SMTP authentication:       YES
 1:20240627:120804.783 ODBC:                      YES
 1:20240627:120804.783 SSH support:               YES
 1:20240627:120804.783 IPv6 support:              YES
 1:20240627:120804.783 TLS support:               YES
 1:20240627:120804.783 ******************************
 1:20240627:120804.783 using configuration file: /etc/zabbix/zabbix_server.conf
 1:20240627:120804.927 current database version (mandatory/optional): 06020000/06020013
 1:20240627:120804.927 required mandatory version: 07000000
 1:20240627:120804.927 mandatory patches were found
 1:20240627:120804.935 cannot perform database upgrade in HA mode: all nodes need to be stopped and Zabbix server started in standalone mode for the time of upgrade.
 1:20240627:120804.936 Zabbix Server stopped. Zabbix 7.0.0 (revision 49955f1).

I have proceeded with my upgrade, but look forward to understanding final solution.

Hi @sa-ChristianAnton!
How is your opinion about the solution proposed here?

Hi @sa-ChristianAnton! How is your opinion about the solution proposed here?

It is kind of obsolete by #115, sorry for "taking over":

HA mode will be switchable on and off
even with HA mode switched on, there will be seemless major release upgrades, by using a job taking care of these actions


Ribbon: use "DummyPing" instead of "NoOpPing"

com.netflix.loadbalancer.NoOpPing is used by default if no other IPing instance is created in the context.
However, com.netflix.loadbalancer.BaseLoadBalancer uses the following heuristics to determine if it should schedule a period Ping of the registered servers:
    private boolean canSkipPing() {
        if (ping == null
                || ping.getClass().getName().equals(DummyPing.class.getName())) {
            // default ping, no need to set up timer
            return true;
        } else {
            return false;
        }
    }

As you notice, no ping will be scheduled when a DummyPing is used. Since DummyPing and NoOpPing are actually doing exactly the same thing - it would be nice if SpringCloud's default were changed - this would save a couple extra threads, especially when used with Zuul.

Small question: is help wanted means a PR is welcome - or does it mean you need more information ?

PR Welcome


[Concurrency] completeWithTask expects to receive a @Sendable closure

Motivation
On the Swift main branch, the Sendable checking has been enabled. It currently emits warnings. Since we test with -warnings-as-errors, our CI does not succeed in the nightly-main step.
Changes

Make EventLoopPromise.completeWithTask require a @Sendable closure

Result

CI should pass on Swift main again

It looks like now it is failing, because of another crash. Not us anymore \o/


running polly test suite (yarn test) uses a lot of CPU

Description
I've noticed that running yarn test is slow and uses a lot of CPU, making it difficult to run tests in a tight loop when TDDing. As configured, the testem suite runs a full yarn test:clean followed by a yarn build test:build for each of the submodules in the monorepo.
I've got a '17 mbp, and just running $ yarn test puts my load over 200 for a solid couple minutes. I also made the mistake of mashing enter a few times in the testem ui, which wound up kicking off 143 yarn processes making my machine beachball until I gave up. This load is almost entirely due to running a full build and clean before each suite run.
While fully saturating the machine's resources may make sense in e.g. a CI environment, it took us a bit of investigation to figure out how to avoid melting our machines, and we worry that it may be a bit of a deterrent to new contributors.
So, after a lot of investigation, we wound up with this workflow:

Comment out the before_tests and on_start entries in testem.js
Manually clean & launch the testem watcher (with logging and a single target): yarn test:clean && yarn testem -d testem.log -l Node
Then, in a second tab, we'd manually trigger the build: yarn test:clean && ./node_modules/.bin/run-s build test:build

At this point, we were able to modify tests and the watcher would quickly kick-off a re-run. I'm not sure exactly when it's necessary to re-run the build, but especially when TDDing existing code, we were able to run the tests in a tight loop.
We also seem to be able to just run the build command for a specific sub-module if we're modifying it.
Anyways, tl;dr decoupling the build and test run steps seems to be the difference between a really long and cpu-intensive wait and fairly instantaneous test results.
So —

So first, I'd like to know — do you guys encounter this problem? Or are you using a different workflow we're not aware of?
If we're not missing something, I'd propose that we document / set up a workflow that either depends on the developer to build as needed, or selectively watches and builds just the changed parts of the app.

I'd be happy to take a swing at either the manual or selective build workflows but thought it would be good to broach the discussion here first!
Thanks for reading
Config
I'm just checking out pollyjs' master and running the tests with the default config.
Environment
OSX, yarn 1.17.3, node 10.16.0

@agraves thanks for opening up this issue! This is something i've been thinking about tackling for some time now and haven't been able to get around to it.

So first, I'd like to know — do you guys encounter this problem? Or are you using a different workflow we're not aware of?

Yes, we encounter this problem 100% of the time as well and my workflow for testing is similar to the one you've come up with. I usually comment out parts of testem as well as modify the mocha.opts glob to only build the tests Im currently working on.  Not only does it make testing extremely slow, but also creates a pretty poor developer experience as you've mentioned.

If we're not missing something, I'd propose that we document / set up a workflow that either depends on the developer to build as needed, or selectively watches and builds just the changed parts of the app.

Either of these options would be better than what we have now, thats for sure. Having a selective build would definitely be the ideal solution as it will reduce a lot of the initial overhead to get started with the project, but I'm not certain of the complexity nor the time it will take to get it working.
If you're willing to take a swing at this, I'd leave the decision up to you. If it'll be too difficult and/or time consuming to get the selective build working, then we can start by setting up and documenting the workflow you've been using and improve on it later on.


workspaces should treat source-replacement'd crates identically to crates.io ones

Consider a source tree layout like structure like:
- <root>
  - vendored_crates/
    - project/
      - Cargo.toml # defines workspace
      - sublibrary/
      - ... # subdirectories
  - foo/
    - Cargo.toml # defines workspace
    - library/
      - Cargo.toml # has path dependency on ../../vendored_crates/project/sublibrary

Furthermore, vendored_crates/ is treated as a source-replacement path for crates.io.
It doesn't matter too much whether foo/Cargo.toml is in foo/ or the project root: if you attempt to build foo/library/, Cargo will complain that vendored_crates/project/sublibrary/ belongs to the vendored_crates/project/ workspace, and that's one workspace too many.
This behavior makes using vendored crates inconvenient, because you would have to strip out workspace-ness from various places when vendoring, which is undesirable and fiddly.  Cargo should treat these source-replacement'd crates identically to the ones downloaded from crates.io.

I agree, the intention of source replacement is to be totally transparent!
I'm curious, though, how come <root>/foo/library has a path dependency on <root>/vendored_crates/project/sublibrary? Presumably if project is in crates.io so is sublibrary?

I'm curious, though, how come /foo/library has a path dependency on /vendored_crates/project/sublibrary? Presumably if project is in crates.io so is sublibrary?

The project/sublibrary in this case is actually servo/ports/geckolib/, where geckolib is part of servo and depends on parts of servo, but not the entirety of it.  All of servo is vendored (or, really, imported; we don't actually vendor it from crates.io).

So perhaps things do work fine and it's only our awkward directory structure that keeps this from working. =/

Oh ok so in the example above project is just coincidentally in the vendor directory, it's not actually being used through source replacement?
If that's the case I wonder if this boils down to https://github.com/rust-lang/cargo/issues/3192? You basically want a way to say "no, really, geckolib is not in this workspace"

Oh ok so in the example above project is just coincidentally in the vendor directory, it's not actually being used through source replacement?

That's correct.

If that's the case I wonder if this boils down to #3192? You basically want a way to say "no, really, geckolib is not in this workspace"

Probably!  Seems all of our problems boil down to that bug. :)


HTML export includes deleted comments

If I create a comment, delete it, then export to HTML the deleted comment appears in the export.

Good find.

Fixed in https://github.com/ether/ep_comments/commit/3f2b8fc0dbf3353d900d230d9c5947c8be7e2bb9


travis,functional: add go 1.7 and exclude ./gopath

First, for travis, add go 1.7 to the list of required go compiler versions. Now that go 1.7 was released, the list of required go compiler versions should also include go 1.7.
Also in functional tests, install go 1.7 instead of 1.6.3.
And also exclude ./gopath also from the list for checking license headers.

lgtm


[BUG] Error adding new monitor over API in v2: NOT NULL constraint failed: monitor.conditions

📑 I have found these related issues/pull requests
None
🛡 Security Policy

[X] I agree to have read this project Security Policy

Description
I've built a python script to read all ingress objects in a kubernetes cluster and update/add them into uptime-kuma.
It is working in kuma:v1, besides having to change the timeout in the python API to over 90 seconds (you know, because it's slow at v1)
So, last week I saw the v2 beta and I'm trying it out.
So far, it's working as expected, BUT..
My script doesn't work anymore, apparently because a new "conditions" field are required:
python3 script.py

Monitor 'api-1' updated successfully.

Traceback (most recent call last):
  File "/home/fp/folder/script.py", line 94, in <module>
    api.add_monitor(**monitor_data)
  File "/home/fp/folder/venv/lib/python3.12/site-packages/uptime_kuma_api/api.py", line 1472, in add_monitor
    return self._call('add', data)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fp/folder/venv/lib/python3.12/site-packages/uptime_kuma_api/api.py", line 550, in _call
    raise UptimeKumaException(r.get("msg"))
uptime_kuma_api.exceptions.UptimeKumaException:

insert into `monitor` (`accepted_statuscodes_json`, `auth_method`, `body`, `conditions`, `database_connection_string`, `description`, `dns_resolve_server`, `dns_resolve_type`, `expiry_notification`, `headers`, `hostname`, `http_body_encoding`, `ignore_tls`, `interval`, `kafka_producer_brokers`, `kafka_producer_sasl_options`, `maxredirects`, `maxretries`, `method`, `mqtt_password`, `mqtt_success_message`, `mqtt_topic`, `mqtt_username`, `name`, `packet_size`, `parent`, `port`, `proxy_id`, `rabbitmq_nodes`, `resend_interval`, `retry_interval`, `timeout`, `type`, `upside_down`, `url`, `user_id`)

values ('["200-299"]', '', NULL, NULL, NULL, NULL, '<IP_ADDRESS>', 'A', 'True', NULL, NULL, 'json', false, 60, NULL, NULL, 10, 10, 'GET', '', '', '', '', 'api-2', 56, 145, NULL, NULL, NULL, 3600, 60, 29, 'http', false, 'https://api-2.company.com/healthcheck', 1) -

SQLITE_CONSTRAINT: NOT NULL constraint failed: monitor.conditions

But it seems that this field is not yet implemented in the API, since it throws this error when I try to pass it:
python3 script.py

Monitor 'api-1' updated successfully.

Traceback (most recent call last):

  File "/home/fp/folder/script.py", line 94, in <module>
    api.add_monitor(**monitor_data)

  File "/home/fp/folder/venv/lib/python3.12/site-packages/uptime_kuma_api/api.py", line 1468, in add_monitor
    data = self._build_monitor_data(**kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

TypeError: UptimeKumaApi._build_monitor_data() got an unexpected keyword argument 'conditions'

👟 Reproduction steps
try to add a new http monitor into uptimekuma:v2
👀 Expected behavior
To be able to add monitors over the API.
😓 Actual Behavior
The API throw this error:
SQLITE_CONSTRAINT: NOT NULL constraint failed: monitor.conditions
🐻 Uptime-Kuma Version
2.0.0-beta.0
💻 Operating System and Arch
docker
🌐 Browser
uptime-kuma API
🖥 Deployment Environment

Runtime: Docker version 27.2.1, build 9e34c9b
Database: sqlite/embedded mariadb (not sure, using v2 migration default I guess)
Filesystem used to store the database on: docker path mount
number of monitors: 210

📝 Relevant log output
No response

Hi @louislam
Correct, I'm using the library that you mentioned.
So, just to be clear..
There is no way to manage uptime-kuma v2 programmatically?


Explicit section and paragraph numbering

This allows a number="N" attribute on cxx-clauses, cxx-sections, and p. Subsequent sections and paragraphs are numbered starting at the next number.

Thanks, I really needed this.
2015-06-06 18:24 GMT-04:00 Jeffrey Yasskin<EMAIL_ADDRESS>
Merged #13 https://github.com/cplusplus/html-doc-framework/pull/13.
—
Reply to this email directly or view it on GitHub
https://github.com/cplusplus/html-doc-framework/pull/13#event-324450415.


Steps

Describe the requested icon
Icon looks likes steps icon on smart watches

Added steps, stairs, footprints, sneaker-move in v2.0.0. Hope one of those works for you!


Add MongoDB.2FA.Disabled rule

Background
Detect when 2FA settings are disabled
Changes
Add MongoDB.2FA.Disabled rule

https://github.com/panther-labs/panther-analysis/pull/1178


add support for centos8-stream

I recently tried to set up an Oracle Linux machine using WSL 2 and basing it off of the CentOS 8 version, but I ran into insurmountable issues (at least, for me) while trying to update/upgrade everything necessary due to the fact that CentOS 8 has reached its EOL as of a month ago and the suggestion is to use either CentOS 7 or CentOS 8-stream.  As such, I installed CentOS 8-stream instead and tried to run the script.
Looking into the script, I ran into an error stating that the distribution wasn't supported.  Since my understanding of CentOS 8-stream is that it is CentOS 8, but supported upstream (or something like that), I figured I'd try to use the script anyway to see if it would work.
Lo and behold, I tweaked two lines of the script to include the -stream postfix and it upgraded smoothly.
Could this support be added for the help of others who, like me, might need it?
Otherwise, I could create an issue instead stating my workarounds for it.

And just for fun, I pushed this change up from the newly-converted Oracle Linux 8 machine I referred to in my opening description, so it definitely worked.  If you need more information, please let me know.

We can't add support for CentOS Stream because we don't support Stream. You'd have to convert to Oracle Linux prior to installing/upgrading to the Stream variant.

This does sound like something that could be a very useful discussion thought. :)

Very well.
Also apologies for not starting this out in an issue.  I'm currently fixing that problem now, and that would definitely be a better place to discuss that than here.

I added the issue for it (as you can see in the activity stream).  #131 should be where we take discussion of what needs to be done, particularly based on the contributing guidelines that I failed to read until after I put in a PR.

I'm going to close this PR and continue the discusson in #131.


Do not hard delete access and access tokens in auth service

Context
Original slack thread
Currently in testnet, there is a grants page that shows all of the grants for the user. However, once a user revokes a particular grant (outgoing payment grant), because the grant access is hard deleted from the DB, there is no way to get the grant to match user's wallet addresses anymore. This means in rafiki.money/testnet this grant becomes not visible.
We should not hard delete access when a grant is revoked.
We also hard delete access tokens when a grant is revoked, but for an audit trail, we should soft delete those instead.
Todo

[ ] Do not hard delete access when a grant is revoked
[ ] Soft delete accessTokens when a grant is revoked

@njlie
Based on the Slack message, we wanted to soft delete access. Since it doesn't have any status information/expiry or anything on the access model, I think we just don't do anything to it other than removing the delete call when a grant is revoked.


Deploy widget_driver_generator to pub.dev

Now we should deploy it to pub.dev

Done with:
https://github.com/bmw-tech/widget_driver/pull/62
https://github.com/bmw-tech/widget_driver/pull/64
https://github.com/bmw-tech/widget_driver/pull/65


Cleanup node test error conditions/messages

The recent kerfuffle over node tests revolve around how tape was being used to validate that no errors occurred.  The error stems from this line:
t.notOk(validate.errors, `${source}`);

Normally this is okay when errors is undefined and is even okay for tape when not undefined but produces unparseable input to tap-dot.  I switched this to:
t.ok(valid, `${source}: ${JSON.stringify(validate.errors)}`);

and all is fine now.  Here's the more meaningful error message that missing country in coverage would've produced:
  4053 tests
  2122 passed
  1 failed

  Failed Tests:   There was 1 failure

    x sources/mx/countrywide.json: [{"keyword":"required","dataPath":".coverage","schemaPath":"#/required","params":{"missingProperty":"country"},"message":"should have required property 'country'"}]

This should work and create more meaningful error messages until the testing framework gets converted to python.

Thanks for looking into this, @trescube!


Transforming https://huggingface.co/csarron/roberta-base-squad-v1

Hi,
I wanted double check how we can transform question answering models like the one mentioned above. (It is question answering model - transformers.AutoModelForQuestionAnswering) For example when using vanilla python for your input:
{ "question": "Did the stock come down?", "context": "Some text about stocks, with reference if stocks went up or down..." }

Q/A pipeline is answering with score, start and end of the sequence and chunk of text (based on start and end), e.g.
{"score": 0.02739531360566616, "start": 103, "end": 173, "answer": "sent stocks sliding to their worst performance in months on Wednesday."}

after I converted this model as classification model, I am seeing given input:
"inputs": [{"name": "TEXT", "shape": [2], "datatype": "BYTES", "data": ["Did the stock come down?", "\Some text about stocks, with reference if stocks went up or down..."]}]}

following output:
{"model_name":"roberta_onnx_inference","model_version":"1","parameters":{"sequence_id":0,"sequence_start":false,"sequence_end":false},"outputs":[{"name":"output","datatype":"FP32","shape":[1,2],"data":[-0.2091064453125,-0.06671142578125]}]}

As probably expected it doesn't really output what it should, I am wondering how we can change/extend the library to generate correct outputs.
Model itself generate set of tensors (the same shape as encoded input) for start and end of sequence https://github.com/huggingface/transformers/blob/master/src/transformers/pipelines/question_answering.py#L371, here I am given just two numbers, so I cannot use the output to invoke postprocessing logic in QA pipeline
Any support appreciate it :).

QA model requires a post processing to transform model output in span, etc.
I would advise to adapt the Python code run by Triton like we did for generative model to add the post processing.
-> https://github.com/ELS-RD/transformer-deploy/blob/main/src/transformer_deploy/utils/generative_model.py


How to change the keys  to  in normal mode?

I try to test following setting, doesn't work.
let g:Lf_CommandMap = {'<C-C>': ['<Esc>'],'<Esc>': ['<C-I>'],'<q>': ['<Esc>']}
or
nnoremap <esc> q

currently，there is no way to customize the key bindings in normal mode.

I try use the follow script, but it can not work
autocmd FileType leaderf call s:lf_my_settings()
function! s:lf_my_settings()
    map <buffer> <esc> :exec g:Lf_py "fileExplManager.quit()"<CR>
endfunction

if I use map <esc> :exec g:Lf_py "fileExplManager.quit()"<CR>, it can work , but this mapp effective all buffer.

Now you can do like this:
let g:Lf_NormalMap = { "File":   [["<ESC>", ':exec g:Lf_py "fileExplManager.quit()"<CR>']] }


After deleting chunks, surrounding chunk borders aren't being render updated.

Have a large area full of just solid block (Quartz in my example)

Delete the Chunk, it doesn't fix the borders of the chunks surrounding it.

A quick world reload does show that the chunk was properly removed

Another example, just deleted a chunk in a survival world I created:

Now, deleting chunk will cause a reload of the world (Just chunks reload, not actually reload of the map)


New Maintainer and the way forward

Hey all,
I am Cielquan / Christian and I am the new Maintainer of this repository.
I would like to shortly outline what I intend to do in general and in the upcoming time.
First of all this is my first bigger open source project I am maintaining and the first one I took over so please be lenient with me. 😃
I am generally rather active on github and it should not take too long for me to answer. But I also have other projects I am involved with which also take up my time.
For the near future I plan to get rstcheck up to date which involves:

[x] Updating the build process (PEP-517/PEP-518) by introducing poetry
[x] Migrating CI to Github Actions
[x] Introducing tox for automated testing
[x] Introducing linting and formatting via pre-commit hooks
[x] Introducing dependabot for automated dependency updates
[ ] Probably introducing pre-commit.ci for automated runs and updates of pre-commit hooks
[x] Drop support for python versions < 3.7 (version 3.5 will deprecate those versions and 4.0 will drop support then)

Then I would like to start working off the open issues and PRs. So please have some patience.

For pre-commit.ci I lack the permissions. Therefore the GHA workflow will need to suffice.


I hope to invoke addExtraLib method in vscode extension

please Add typescript types lib for code hint in vscode extension, I hope to invoke addExtraLib method in vscode extension; like monaco editor:
monaco.languages.typescript.typescriptDefaults.addExtraLib()

detail: https://microsoft.github.io/monaco-editor/playground.html#extending-language-services-configure-javascript-defaults

Duplicate of #139923
Please follow up on the original issue instead of posting a duplicate


Failed to upgrade from v0.13.2 to v0.13.3

Version

v0.13.2 -> v0.13.3
Platform/Architecture

Ubuntu 22.04, amd64
Describe the bug

clusterrole.rbac.authorization.k8s.io/system-upgrade-controller created
role.rbac.authorization.k8s.io/system-upgrade-controller created
clusterrole.rbac.authorization.k8s.io/system-upgrade-controller-drainer created
rolebinding.rbac.authorization.k8s.io/system-upgrade created
namespace/system-upgrade unchanged
serviceaccount/system-upgrade unchanged
configmap/default-controller-env unchanged
deployment.apps/system-upgrade-controller configured
Error from server (Invalid): error when creating "https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml": ClusterRoleBinding.rbac.authorization.k8s.io "system-upgrade-drainer" is invalid: subjects[0].namespace: Required value
Error from server (Invalid): error when applying patch:
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"ClusterRoleBinding\",\"metadata\":{\"annotations\":{},\"name\":\"system-upgrade\"},\"roleRef\":{\"apiGroup\":\"rbac.authorization.k8s.io\",\"kind\":\"ClusterRole\",\"name\":\"system-upgrade-controller\"},\"subjects\":[{\"kind\":\"ServiceAccount\",\"name\":\"system-upgrade\"}]}\n"}},"roleRef":{"name":"system-upgrade-controller"},"subjects":[{"kind":"ServiceAccount","name":"system-upgrade"}]}
to:
Resource: "rbac.authorization.k8s.io/v1, Resource=clusterrolebindings", GroupVersionKind: "rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding"
Name: "system-upgrade", Namespace: ""
for: "https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml": error when patching "https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml": ClusterRoleBinding.rbac.authorization.k8s.io "system-upgrade" is invalid: [subjects[0].namespace: Required value, roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"system-upgrade-controller"}: cannot change roleRef]

To Reproduce

Create a new cluster.

k3d cluster create debug-system-upgrade-controller

Apply system-upgrade-controller v0.13.2.

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.2/system-upgrade-controller.yaml

Apply system-upgrade-controller v0.13.3.

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml

For the missing namespace, I suspect the intent was that you supply your desired namespace using kustomize. @SISheogorath, as the author of the new RBAC, can you confirm how you intended this to be used? Perhaps an update to the readme would help.

I used to follow this k3s docs to install system-upgrade-controller. Others may be the same. So maybe it needs to be updated as well.

For the error regarding the roleRef being immutable, I believe you'll need to delete and recreate the resource when upgrading.

Applying v0.13.3 with a new cluster also fails:

Create a new cluster.

k3d cluster create debug-system-upgrade-controller

Apply system-upgrade-controller v0.13.3.

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml

The output:
clusterrole.rbac.authorization.k8s.io/system-upgrade-controller created
role.rbac.authorization.k8s.io/system-upgrade-controller created
clusterrole.rbac.authorization.k8s.io/system-upgrade-controller-drainer created
rolebinding.rbac.authorization.k8s.io/system-upgrade created
namespace/system-upgrade created
serviceaccount/system-upgrade created
configmap/default-controller-env created
deployment.apps/system-upgrade-controller created
Error from server (Invalid): error when creating "https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml": ClusterRoleBinding.rbac.authorization.k8s.io "system-upgrade-drainer" is invalid: subjects[0].namespace: Required value
Error from server (Invalid): error when creating "https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml": ClusterRoleBinding.rbac.authorization.k8s.io "system-upgrade" is invalid: subjects[0].namespace: Required value

Yes, the indent is to use kustomize to avoid hardcoding namespaces. As a fix, to allow plain installation, adding a namespace to the kustomization that is generated during the release, can fix this fully backwards compatible.
If you can wait, I'll write a PR until tomorrow.

You could probably also just pass the namespace when applying the manifest:
kubectl apply -n system-upgrade -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.13.3/system-upgrade-controller.yaml
But yeah, since the manifest also includes a namespace, the CRB should use that namespace.

Adding the missing namespaces addresses some of the errors, but it looks like in an upgrade 0.13.2 to 0.13.3, there's an attempt to change an immutable object:
The ClusterRoleBinding "system-upgrade" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"system-upgrade-controller"}: cannot change roleRef`


Creation date / modification date of tables, views and packages

Hallo,
can I see the creation / modification date of tables, views and packages somewhere? Best directly with the properties of the table or package, ... . Unfortunately, I haven't found it anywhere.
Best regards.

Hello, @Kaennchen80,
What database are you talking about? Not every database offer such information, so we can't retrieve it and display somewhere.

Oracle
Von: Who cares<EMAIL_ADDRESS>Gesendet: Dienstag, 2. Februar 2021 14:48
An: dbeaver/dbeaver<EMAIL_ADDRESS>Cc: Grosse, Anne<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [dbeaver/dbeaver] Creation date / modification date of tables, views and packages (#11179)
Hello, @Kaennchen80https://github.com/Kaennchen80,
What database are you talking about? Not every database offer such information, so we can't retrieve it and display somewhere.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dbeaver/dbeaver/issues/11179#issuecomment-771646028, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASVXJGHPKJPSEODOIVXXWH3S477ARANCNFSM4W4LGLTQ.

Thank you for insanely fast response!
Indeed, Oracle can provide such information. We can implement it in the future

Probably db community edition do not have interface to display the table created date, how the sql SSMS show.
Here is a query I use in DBeaver
SELECT CREATED, * FROM INFORMATION_SCHEMA."TABLES"  WHERE TABLE_NAME ='INTEGRATION_FOREIGN_KEY'
BINGO_DWH_DEV.STAGING.INTEGRATION_FOREIGN_KEY

Thank you very much!

For now, this ticket will be open for packages metadata enhancement. I'm working on it right now. We will close this ticket when the work will be finished :)


mont doesnt move when settings changed in homekit

Here is the log:
homebridge.log

Hi @SSMARTREPAIR,
It seems that the device running the homebridge / hoobs with this plugin does not receive any move actions. You should see something like this in your logs:
25/03/2021 à 12:42:55 [MotionMountDynamicPlatform] [moveToPosition] Going to Kitchen
25/03/2021 à 12:42:55 [MotionMountDynamicPlatform] [getPeripheral] Connecting ...
25/03/2021 à 12:42:55 [MotionMountDynamicPlatform] [getPeripheral] Connection established, rssi = -73
25/03/2021 à 12:42:55 [MotionMountDynamicPlatform] [moveToPosition] Getting characteristics ...
...

Since bluetooth connectivity between the TV mount and the homebridge device seems good I would probably check if there is connectivity issues between the homebridge device and your homekit hub. Wish you good luck.


Accumulators with initial value may fire with unbound internal values.

This behavior isn't defined so it may not be a bug, but I wanted to log this here for reference. Consider this rule, originally from issue #101:
(mk-session [(dsl/parse-rule [[?res <- (acc/all) :from [Temperature (= ?t temperature)]]
                              [:test (or (< ?t 10)
                                         (< 10 ?t))]]

                             (println "hello world"))])

The all accumulator can fire with no content, which would trigger the test to fire. But since ?t has no defined value, it will be nil when test fires, yield a NullPointerException.
We could argue that the accumulator shouldn't fire unless all variables in its :from clause are populated. This would solve this problem, but at the same time it may not be intuitive to other users that would expect an empty ?res to fire if nothing matches at all.
Getting an idea of how other rule engines handle this situation could inform our behavior here.

This is a tricky case and a good question.  I'd like to experiment some, like you said, with how other engines deal with this case.
The funny part of this issues, is I completely did not intend to make an example that exposed this strange case.  I just pulled out an arbitrary accumulator to use for the sake of example.  Serendipity.

I'd propose that we shouldn't fire an accumulator if its bindings can't be satisfied. This was my initial intention early on as described in this comment [1]. If you bind inside an accumulator, you probably want to join to or do something with the binding, so we should make sure the items are bound. If users don't want this behavior, users skip bindings inside the accumulator and just access fields in the result returned from the accumulator.
In short, I think the current behavior of propagating nil bindings that can't be satisfied is a bug, and the description way back at [1] is what we want.
I'd welcome feedback on this line of reasoning.
[1]
https://github.com/rbrush/clara-rules/issues/22#issuecomment-27188706

The behavior I proposed in the above comment -- to only propagate accumulators if their values can be bound -- does break the test-accumulator-with-init-and-binding-groups test, which was introduced by @mrrodriguez in https://github.com/rbrush/clara-rules/pull/89. It also breaks two other tests that happened to rely on propagating initial values with unsatisfied bindings in an accumulator, so this would be a non-passive change. (Although possibly still worth doing.)

So ?t has a value here. Should we propagate the empty sequence of the accumulate node when there are no Cold facts inserted?

Yes, I think we should propagate an initial value in this case because everything has a binding. That's actual the behavior the user was looking for in issue #22, and has a well-defined and (I think) intuitive behavior.

That makes sense to me.  I was just double checking.

When working on https://github.com/rbrush/clara-rules/issues/190 I have done a reasonable amount of work around the semantics of propagating the :initial-value and retracting to it etc.
When I was doing that, I noticed that in the current implementation left-activate of both the AccumulateNode and AccumulateWithJoinFilterNode there is a check of
(has-keys? (:bindings token)
                          binding-keys)

This check actually doesn't make sense to me because I don't think it is accomplishing anything right now.  I do think that back when it was added in https://github.com/rbrush/clara-rules/commit/e14f93d2497523d175578b22cfbbd84679bcea91 that it did make sense.  This was done for https://github.com/rbrush/clara-rules/issues/22, which was around this same sort of scenario described in this issue.
Why this made sense before is that the accumulate node considered the binding keys from its "inner condition" to be part of its own binding keys.  This was done regardless of whether these were even join binding keys or not.  The accumulate had visibility into all the binding keys that it needs to join with incoming tokens, as well as any new bindings it is establishing.
Since then, both accumulate node's binding keys only include keys that are used as join bindings.  I actually think this is how other nodes work as well now.  So the accumulate nodes do not seem to have any way to "know" what new bindings they may be setting up in their "inner condition".
I'm not sure on what approach you have been wanting to take on this, but I wanted to offer a few insights because I think some of it leads to simplifications for me in https://github.com/rbrush/clara-rules/issues/190.
Currently both accumulate nodes check this (I believe) superfluous check of all binding keys "being in place".  I don't think a token could propagate to this level with binding keys that were missing from the join binding keys the accumulate node is looking for.  In order for these join bindings to be missing, the token would somehow have to match facts that didn't bind to bindings that were introduced in previous conditions.  The only tokens that can have this problem, should just be from other accumulate nodes that have this same problem we are facing here.
I tried removing these checks in both nodes and didn't see any tests fail across my suite of tests I have available, as well as Clara's own.
Since this check is checking against the incoming tokens, the :initial-value propagation logic is doing these checks per-token propagating.  I do not actually think that whether or not to propagate the :initial-value needs to be something decided at a per-token level.  Since this check seems to not be checking anything useful right now, I was wanting to move it out of the per-token loop.
To fix this issue, it seems to me that the accumulate nodes need to have visibility to the bindings being introduced by their "inner conditions".  I do not think this is the same thing as the "binding keys" though.  The accumulate node should be able to determine whether or not the :initial-value should be propagated to all incoming tokens, just by checking that it does not have any newly introduced binding keys by its inner conditions.
I'm just looking for feedback on your thoughts around this.  Hopefully I expressed my thoughts/concerns well enough to be understood.
Clarification on this may help me a little in organizing the :initial-value propagation issues that have came up with my work on https://github.com/rbrush/clara-rules/issues/190.  I can work around all of this, but I think it may simpler to get this particular issue cleared up at least conceptually - around if the current binding key check per-token makes sense, and if we even need a per-token check at all in the future or not.

Yes, I think we can check this statically and remove the runtime check. If the tests I added for #22 still pass then I think changes in this space are okay. Also, you're right it isn't the binding keys that need to be checked here, it is the inner bindings in the accumulator. And since we know those when assembling the network, we should know when the parent satisfies them.
In short, yes, I think we can remove has-keys? as you suggest, and this is possible because statically. Back in #22 we didn't sort the nodes topologically or do much static analysis of the bindings, so this was done at runtime.

As @mrrodriguez  mentioned, I've been giving some thought to how to approach this one.
My thinking here is that we are already generating the information to know which bindings in a condition need to come from right activation binding groups or are its result binding (i.e. are new bindings generated by that condition) and which are coming from its left activations (i.e. from ancestor nodes in the network).  This information is currently being discarded.  My plan is to change that so that the beta-graph [3] has a new key, something like
{code}
{:node-id-to-new-bindings #{Symbol}}
{code}
Note that this would also need to distinguish between the result bindings and bindings in the constraints.  The accumulator nodes would take a new field indicating whether new bindings are created in the constraints; if so they would not propagate initial values if no elements are present.
After this, in combination with the changes in https://github.com/rbrush/clara-rules/issues/188 and https://github.com/rbrush/clara-rules/issues/189 that @mrrodriguez is working on, the behavior would be:

If an accumulator has binding groups in its constraints that use a binding that is populated from its elements, it cannot propagate an initial value without elements.  Such elements must meet all constraints, not just be of the correct fact type, in order to be considered.
If an accumulator does not create any new bindings from its constraints, excepting the result bindings, then it should accumulate and fire once per distinct set of bindings.

@mrrodriguez , does the behavior I describe accord with what you are implementing for https://github.com/rbrush/clara-rules/issues/189 ? It is a bit different from what you described there, but I believe that is just because you're not fixing this issue there.  I'd like to be sure we're on the same page regarding what the final state should be though.
@rbrush , do you have any thoughts on this approach?  Obviously, if someone else is working on this one please let me know; no need to duplicate work.

https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L693
https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L612
https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L931

@WilliamParker I think what you are saying makes sense and is something that can layer over #188 and #189 issues.  It sounds like it'd just be one additional check on whether or not the :initial-value is to be propagated.
The bigger concern I have is this would be a breaking change.  I know we do have code that relies on the current behavior.  I can also see why we have this code in cases.  I understand why we are semantically trying to fix this issue.  I also understand the "workaround" to get the same old behavior with these new proposed changes in place.
However, I would like to consider offering alternatives that are more obvious for the cases that we have right now where people do rely on this behavior.
A common usage of the :initial-value for us is concerning the idea of a condition that may or may not be satisfied, but the rule should fire anyways.  This is, in a sense, an "optional" condition of a rule.  Often the acc/all accumulator is used to achieve this goal.
e.g.
(defrule make-outcome-for-results
  [Person (= ?id id)]
  [(acc/all) :from [Result (= ?id person-id) (= ?result-id id)]]
  =>
  (insert! (->Outcome ?id ?result-id)))

The result-id is unique to any any given Result, so it is not a good fact binding for an accumulator.  However, in this sense it is syntactically saving time to just bind it like this.  To do this correctly after this issue is addressed, you would have to do something like
(defrule make-outcome-for-results
  [Person (= ?id id)]
  [?results <- (acc/all) :from [Result (= ?id person-id)]]
  =>
  (insert! (->Outcome ?id (-> ?results first :result-id))))

Or you could even go through the extra trouble of using an :or except you'd have to have the ?result-id binding in both branches of the :or for it to be usable in the RHS, which is not practical here.
You could use 2 rules, but that becomes very heavy when the number of optional conditions increases.
I don't think this workaround is particularly difficult, what I think is difficult is making it clear how this change will make this old pattern not work.  What is worse, it would be fairly easy to overlook the fact that it doesn't work anymore.  If tests were written in my example above always with some Result data present, the rule would always fire and produce outcomes.  It may be an edge case that there are no Result data.  When that happens, the rule wouldn't fire and may not have been expected by the rule writer.

What I am now thinking is that what may be missing is the ability to syntactically, and perhaps more efficiently, write a rule that has true support of an "optional" condition.  This optional condition would have full support for fact bindings.  For the sake of demonstration consider:
(defrule make-outcome-for-results
  [Person (= ?id id)]
  [:maybe [Result (= ?id person-id) (= ?result-id id)]]
  =>
  (insert! (->Outcome ?id ?result-id)))

Perhaps a first-class construct like this could separate this case explicitly instead of trying to conflate rules like this with accumulators.  Perhaps this is just implemented as some sort of syntactic sugar as well, but maybe we could do more with it - I haven't thought about it.
Also, a question that should come up is the same on that we have for accumulators prior to fixing this issue,

what should ?result-id be in the RHS when there were no facts matching for the Result condition?

I think nil would be an obvious choice.  Of course you would have have a little ambiguity on whether nil was the actual value of a Result fact's id field or you had no Result facts matching at all.  This ambiguity may be fine here and just something to be aware of.
We could even consider allowing a (optional) sentinel/default perhaps.
(defrule make-outcome-for-results
  [Person (= ?id id)]
  [:maybe [Result (= ?id person-id) (= ?result-id id)]
   :default (= ?result-id ::none)]
  =>
  (insert! (->Outcome ?id ?result-id)))

I'm not sure about this syntax or even the suggestion being solid.  I'm just posing the idea here to get the conversation started at least.

To be honest this thread makes me a bit uncomfortable because we seem to be adding a number of caveats to the behavior to address the problem at hand. If it takes more than thirty seconds to explain why a rule will or won't fire, then I think we've missed the mark, giving users too much to reason about. Previously I had tried to keep things really simple:

Rules fire once for each unique combination of bindings.
In this spirit, accumulators that use bindings will fire with no matching results if those bindings are bound elsewhere in the rule.

The behavior proposed in #189 changes that, so accumulators with bindings only fire if they match some facts...but accumulators without bindings don't. I had +1'd that but am having second thoughts, especially if we have to keep piling on more semantics like the ones described here.
Rather than adjusting the semantics, might it be better to stick with a couple small axioms, and handle these cases in user code...or in generated rules or specialized accumulators that do what we want? I know user code would have to handle things like empty items when (acc/all) is run...but at least we could point to the above simple rules as how to reason about it.
Also, I'm not necessarily opposed to the :maybe proposal, but am a bit reluctant to add further expression types, since it increases the surface area and learning curve of the API. Could we handle this in specialized accumulators or some other generated construct above Clara's core API as well?

I'm becoming confused here.  My thinking was that
- Rules fire once for each unique combination of bindings.
- In this spirit, accumulators that use bindings will fire with no matching results if those bindings are bound elsewhere in the rule.

is the behavior we want to restore.  My problem with the current behavior is not with this goal, but rather that this goal is not actually being achieved.  My impression from conversations with @mrrodriguez  was that the behavior he describes in https://github.com/rbrush/clara-rules/issues/189 is a "midway point" where the end goal is to get back to the behavior we want that @rbrush described above (and then add testing to ensure we have no regressions).  Mike, please correct me if this is a misrepresentation of your views.
The only thing that I think was new in https://github.com/rbrush/clara-rules/issues/189  was defining the behavior when an accumulator received facts that matched the bindings, but not the actual constraints on the rule.  Namely, whether something like
(acc/all) :from [Temperature (= ?location location) (< temperature 20)]

when we have a Temperature that is not less than 20.
Regarding
The behavior proposed in #189 changes that, so accumulators with bindings only fire if they match some facts...but accumulators without bindings don't.

I don't understand the "accumulators without bindings don't" part.  If the constraints are not fully satisfied, then the elements should not be given to the accumulator in any case.  The ambiguity concerns whether those elements create a binding group despite their failure to match any additional constraints.  This is a case that fundamentally doesn't exist for accumulators without binding groups and doesn't seem to me to have a counterpart there.
Regarding an earlier part of the thread, I definitely would not expect the behavior in https://github.com/rbrush/clara-rules/issues/189#issuecomment-226542746 to change.
If I'm misunderstanding anyone's thoughts, please correct me/elaborate on those thoughts.

Regarding the :maybe proposal, I haven't thought about it as deeply as the generalized accumulator semantics, but could we accomplish this by providing the option for accumulators to allow nil to propagate and to fire without binding groups existing?  I think this probably would need some work in Clara's core API, but perhaps it could be done in a less intrusive and probably more extensible manner as an option on accumulators than as a top-level boolean expression form.  To me this would have the benefit of choosing sensible defaults for most cases and then allowing the user the option to deviate from those defaults, but in a way that does not impose a burden on a user that just uses the defaults.  Say something like
{:reduce-fn some-function-here
:propagate-without-bindings-satisfied true
:propagate-nil true}

where a user who does not need them can just ignore those last two keys.
Regarding the use-case for :maybe, the main motivation in my mind is that we've had use cases where there are facts in the session that don't actually logically impact the semantics of our rules in any way, but the downstream consumers nevertheless want certain data to be passed along in a final outcome fact if it is present.
This stuff on :maybe is just some preliminary thoughts though.  I agree that making too many options part of the core knowledge one needs to effectively read rules could be problematic.

The confusion may be on my side, so perhaps some examples would help. Here's what I would expect to happen:

This would match once for temperatures:

(defquery get-all-temps
 []
 [?all-temps <- (acc/all) :from [Temperature]])

This would match once per location that exists:

(defquery get-all-temps-by-location
 []
 [?all-temps <- (acc/all) :from [Temperature (= ?location location]])

This would match once per location, even if there are no temperatures in that location, since ?location is bound in the Windspeed rule. (This was the issue fixed way in #22).

(defquery get-all-temps-where-its-windy
 []
 [Windspeed (= ?location location) (> windspeed 20)])
 [?all-temps <- (acc/all) :from [Temperature (= ?location location)]])

Similar to the above item (3), this would match once per location, even if no temperatures match, since the location

(defquery get-all-cold-temps-where-its-windy
 []
 [Windspeed (= ?location location) (> windspeed 20)])
 [?all-temps <- (acc/all) :from [Temperature (= ?location location)  (< temperature 32)]])

I'm not sure if we're all on the same page for item 4. If there are no cold temps, should this accumulator fire? I've waffled on this, but the two axioms I stated above suggest that it should.

I'd agree on number 4 that you have above.  I think the discussion was more about a case like

(defquery get-all-freezing-temps
 []
 [?all-temps <- (acc/all) :from [Temperature (= ?location location)  (< temperature 32)]]))

where there are Temperature facts, but the temperature is, say, 40.  The ambiguity here (to me) was whether facts that did not actually satisfy the constraint of having a low temperature would still have an impact on rule execution by creating a binding group.  I'd say not, since I'd suggest a general axiom of

If a fact does not satisfy the constraints of a condition, it should not impact downstream logic that depends on that condition.

So in this case of having a Temperature fact with a temperature of 40, I don't believe that query should match.

The main discussion and confusion on #189 has been about case 4 above as well as Will's example after it

I'm not sure if we're all on the same page for item 4. If there are no cold temps, should this accumulator fire? I've waffled on this, but the two axioms I stated above suggest that it should.

The issue is not around there being no temperatures at all. The issue is around when there are some temperatures. And either none of them or some of them match the constraint of being less than 32.
If there are none matching that constraint, but some temperatures do exists for a location that matches a wind speed. It gets really confusing on whether you should propagate the initial value for every location binding group.  It is like a "fake match". Temperatures are matching on location thus forming groups. However none of them are satisfying the otherconstraint of the rule.
Similarly if some binding groups do have matches, should the other binding groups with "fake matches" propagate the initial value anyways?
I'm leaning towards the most meaningful and straight forward behavior to just be, do not propagate the initial value when there are actually temperatures present but they are not satisfying the constraints of the rule. For any number of location binding groups that they may potentially be able to join with.

I'm open to these options as long as we can come up with a concise description of the behavior that does have a bunch of caveats. Here's another attempt that covers the behavior your'e looking for in case 5:

Rules fire once for each unique combination of bindings.
In this spirit, accumulators that use bindings will fire with no matching results if those bindings are bound elsewhere in the rule.
Variables are bound only if the fact that matches them satisfies all other criteria.

For case 5, the rule won't fire because ?location can't be bound since no fact satisfies it. But this doesn't cover case 4, which I'll re-post here for convenience:
(defquery get-all-cold-temps-where-its-windy
 []
 [Windspeed (= ?location location) (> windspeed 20)])
 [?all-temps <- (acc/all) :from [Temperature (= ?location location)  (< temperature 32)]])

In this case, if there is a Windspeed that matches, but only temperatures above 32 degrees, I'd expect for the rule to match with an empty sequence for ?all-temps. The query is to get all cold temperatures where it is windy...so we have a windy location that has no cold temperatures, hence the empty sequence for ?all-temps.
I'm fine with changing this behavior if we have a simple way to describe the behavior to a new user. Is there an amendment or a different description than the one I proposed that captures what your'e looking for?

I can see where you are coming from in the thought process behind
(defquery get-all-cold-temps-where-its-windy
 []
 [Windspeed (= ?location location) (> windspeed 20)])
 [?all-temps <- (acc/all) :from [Temperature (= ?location location)  (< temperature 32)]])

I've fought with this one quite a bit.  The situation that is most weird to me is like what you described above, but when you have multiple binding groups in play.  I'll show a few test data points to demonstrate:
;; fact-1
(->WindSpeed 30 "MCI")

;; fact-2
(->WindSpeed 40 "LAX")

;; fact-3
(->Temperature 20 "MCI")

;; fact-4
(->Temperature 10 "LAX")

In this situation, there are 2 binding groups, "MCI" and "LAX".  The "MCI" group has a match for both conditions and therefore is straightforward.
The "LAX" group however, does not have a matching pair.  It does have a Temperature, but not one that matches all constraints.  I believe with your rules above, there is nothing necessarily long with this, so we'd get the empty sequence for ?all-temps.
Also, consider the case where fact-4 doesn't exist at all.  Now the "LAX" binding group doesn't have any possible matches,  The bindings are all in place though, so perhaps it fires with ?all-temps bound as well.
There may be an arbitrary number of binding groups without matches here, and under these rules, they all get an :initial-value propagated.  The groups with actual matches fire as well with actual accumulated values.
This may all be fine and if we decide it is what makes sense, I can incorporate it into my changes for AccumulateWithJoinFilterNode.  AccumulateNode would have to be re-worked a little as well to behave like this since it doesn't after #190
As I said previously in #189 , the rule I was following was:

if no binding group has any matching facts, the :initial-value is sent to all binding groups
If some binding group has matching facts, the :initial-value is not sent to any binding group that doesn't have matches.

I'm fine with adjusting this if it is what makes the most sense to everyone.  I think it may be slightly more complicated in the implementation, but that's besides the point.  :)

Regarding @WilliamParker's comment:

I changed

In this spirit, accumulators that use bindings will fire with no matching results if those bindings are bound elsewhere in the rule.

to

In this spirit, accumulators that use bindings will fire with no matching results if those bindings are bound in a previous condition.

I don't think this adjustment is necessary. Case 4 should work identically even if conditions are reversed, as shown in Will's example. Today we do a topological sort of bindings, preferring non-accumulator bindings to accumulator bindings, to make this work. Subjectively this seems simpler to me since I don't have to worry about the order in which I write my conjunctions in a rule, and rules won't break if a change that order.
Regarding @mrrodriguez's comment:
I'm in favor of making the adjustment we describe here as it applies to #189 if it doesn't cause too much trouble. (And I know I'm flipping my previous +1.) The example behavior you describe is what I'd expect given that rule and can be relatively easily explained to a user without getting into the details of the nodes and initial values. But I'm happy to discuss further if this will cause a lot of headaches elsewhere.

Using the existing topological sort to create the bindings without relying on the ordering seems reasonable.  The part that still seems ambiguous to me with that behavior is what happens when you have something like
(defquery two-temp-conditions
       [?t1 <- (acc/all) :from [(< temperature 20) (= ?location location)]
      [?t2 <- (acc/all) :from [(even? temperature) (= ?location location)])

Which accumulator should be required to create a ?location binding?  This sort of case is something I'd like to mull on some tonight.

Will's example above is interesting.  Typo'ed some it looks like
However, I do think we need to consider the general idea.  This looks like a potential problem.
(defquery cold-or-temps
  []
  [?t1 <- (acc/all) :from [Cold (= ?location location)]]
  [?t2 <- (acc/all) :from [Temperature (= ?location location)]])

I don't think the extra constraints in the rule are even necessary to show the issue.
The way this fires or doesn't fire depends if the Cold or Temperature condition comes first, which should end up being an impl detail of how the Clara compiler sorts the conditions.
However, if there is a Cold, but no Temperature, whether or not this will be able to fire will depend on the order they were sorted in.
We could try to do something to make them independent here.  I think it does start to get quite a bit more complex in the Clara engine side, not the semantic side.

@mrrodiguez had an interesting idea here.  For cases where one or more accumulators are stacked and it is not clear which should create a binding group, we could extract them into separate rules with each possible ordering.  So, for example,
[?t <- (acc/all) : from [Temperature (= ?location location)]]
[?w <- (acc/all) :from [WindSpeed (= ?location location)]]

would propagate a result downstream for any ?location with a corresponding WindSpeed or Temperature.
This conflicts with a created AccumulateNode requiring that facts exist under a binding
group to propagate a result, since either way it is ordered a child would depend on a parent.  So, for example, if the WindSpeed AccumulateNode was a child of the TemperatureNode, then if we have only one path the WindSpeed node might need to do something to its parent to cause it to propagate its initial value.  This is extremely different from the current engine architecture.
Mike's thought was to extract this into different rules, with each possible ordering.  The results of these rules would then be fed into some form of "just-one" accumulator to maintain the expected cardinality from the original rule.  If both nodes have results, then assuming that the accumulators obey assumptions regarding order independence (i.e. commutativity and associativity) then I believe the results of these extracted rules should be the same.  I believe this would allow us to support this case without needing to fundamentally change the engine.  Essentially, it would be a similar idea to the current extraction of complex negations.
I'm planning to start kicking around what fixing this issue (the original one, not this stacked accumulator issue) in the compiler would look like.  That part shouldn't be particularly susceptible to merge conflicts with other accumulator work.  I do want to ensure we have a viable path forward for the stacked accumulator problem and avoid going in a direction that would prevent from us from fixing it though.

I have a first pass at compiler changes to give AccumulateNode and AccumulateWithJoinFilterNode visibility to what, if any, bindings they create at https://github.com/WilliamParker/clara-rules/commit/243e405c01c2bdce635d6fcba7c5482937b9e635  Note that this is a bit different from my (incorrect) initial thoughts; sort-conditions wasn't involved.
Note that this does not actually fix the functional problem yet; it just provides information to the nodes that will be helpful in doing so.  It mostly doesn't change anything functionally, with the exception that I think there are probably some very edge-case scenarios where a node could be shared by multiple parents, some of which might pass in all bindings it needs and others of which might not, where it cannot be shared with these changes, since the :new-bindings will be part of the equality check at https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L973
I don't see any problems for correctness, since condition-to-node is called in add-conjunctions [1], which is itself called in add-productions.  We'd have problems if the parent-bindings in condition-to-node didn't come from the true parent, but rather a parent from another rule, but I don't immediately see a way for this to happen.
I'll let this sit for a bit and look at it later to see if I see any problems, but I wanted to give some visibility to the path I'm looking at.  If I think it is all correct I might go ahead and submit a pull request even without the functional fix to either node.  My reason for doing so would be that the actual fixes to either node might be done by multiple people (I know @mrrodriguez is looking at AccumulateWithJoinFilterNode) and dealing with that coordination might be easier if the change to provide the information to the node were in master.  @rbrush, your preference on how you want to do the coordination/project management of course.

https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L956
https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L1051

https://github.com/rbrush/clara-rules/pull/208 fixes this issue for AccumulateNode.

https://github.com/rbrush/clara-rules/pull/210 fixes this issue for AccumulateWithJoinFilterNode.

I think the only functional problem remaining here is described at [1].
Otherwise, I think the issues described here, in https://github.com/rbrush/clara-rules/issues/188, and in https://github.com/rbrush/clara-rules/issues/189 have been addressed.  My thinking is to log a new issue for the remaining edge case described in [1] and a few following comments and to close the current 3 issues.  Does anyone else see anything left to address in these 3 issues?

https://github.com/rbrush/clara-rules/issues/102#issuecomment-227581784

Sounds like a plan, Will. +1 to tracking that specific edge case separately; the other changes here seem important enough to merit a release by themselves.

Alright, I logged #218 to track the open edge case. Anything left to do on this one, or should we close it?

@rbrush , I don't see anything left to do here.  @mrrodriguez , do you agree?

+1 to closing

Closing and tagging for the 0.12 release.


[ZEPPELIN-1720] Adding tests to verify behaviour of dynamic forms

What is this PR for?
Adding Selenium tests to ensure proper behaviour of dynamic forms.
What type of PR is it?
Test
Todos
N/A
What is the Jira issue?
ZEPPELIN-1720
How should this be tested?

Once should first get Firefox v. 41 as it is the latest version that works with the current version of Selenium in Apache Zeppelin.
You can then run the tests with following command:

TEST_SELENIUM="true" mvn package -DfailIfNoTests=false -pl 'zeppelin-interpreter,zeppelin-zengine,zeppelin-server' -Dtest=ParagraphActionsIT
Screenshots (if appropriate)
N/A
Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

Cool!

Hi @randerzander. Thanks for contribution.

Zeppelin build system relies on travis. So please setup your travis account and travis project for Zeppelin.
https://zeppelin.apache.org/contribution/contributions.html#continuous-integration
The repository name must be zeppelin (not incubator-zeppelin, ...)

@1ambda Thanks, I actually did setup Travis while I was developing, I did not realize that every commit triggered a build so I deactivated my Zeppelin fork on Travis after I noticed this (so only have 2 builds on Travis). I activated it before I got this PR, so now I am in a state where I don't have a build for my latest commit and this PR does not show up on Travis. Should I trigger a manual build of last commit via the Travis API? Is there any other way to get back on track?

@guicaro I see. There are many ways to trigger travis again. but what you actually need is pushing new commits so that travis get noticed.

Amend your last commit with git commit --amend and push --force

Thanks again @1ambda it all worked like a charm and now all green :)

@guicaro Thanks for your great contribution!
I left some comments. Could you take a look at them? Please let me know if there is something that I missed :)

Seems some review comments are mixed up in github side :(
I just removed some of them and left comment again. Please let me know if you're confused.

@AhyoungRyu I'm currently looking at why testMultipleDynamicFormsSameType is failing. It now fails after I rebased from master. It's the test case that includes two select forms in one single paragraph. Basically the select foms are not showing up in GUI. I tested this with new version of Chrome (Version 56.0.2924.87 (64-bit)) to see if this might be an issue with the old Firefox version we use for Selenium, but also happens in Chrome. Here is the pic:

You can reproduce by entering the following string into a paragraph and then running (this used to work before I rebased).
%spark val options = Seq(("han","Han"), ("leia","Leia"), ("luke","Luke")); println("Greetings "+z.checkbox("skywalkers", options).mkString(" and "))

Quick question, what is the behavior when we have more than 2 select forms? Shouldn't we also have a "Run on selection" check box? I believe this was one of the pain points for some (see ZEPPELIN-1013). Here is a screen shot showing a paragraph with 2 forms created programmatically but not showing the drop down menus nor the 'Run on selection" checkbox:

Maybe I'm missing something? I rebased yesterday from master and have changes up to March 17 on my fork

@guicaro Thanks for letting me know. Let me check again.

@guicaro I feel so sorry to you since it was my bad. Just created hotfix patch #2154 to fix below two issues that you reported.

Select form is not shown up when multiple dynamic forms (e.g. 2 select forms / 1 checkbox + 1 selectform) are in one paragraph
Can't see Run on selection change menu under the paragraph control menu

It'll be appreciated if you can help me out to review #2154!
BTW I tested all your test cases on my patch, most of them passed except testMultipleDynamicFormsSameType. It's because of this line. The expected matcher should be "Howdy 1\nHowdy " instead of "Howdy \nHowdy " since the paragraph runs right after the selection has been changed. (as I said before :D)
And after you rebased, some irrelevant commits are mixed and pushed together in here. Could you handle them? Feel free to ping me if you're in trouble while you resolve it.

@AhyoungRyu  no worries, will be glad to review your work, fix testMultipleDynamicFormsSameType and fox my commits, will definetly ping you about this last issue :) Thanks

@guicaro There are some unrelated commits in here after you rebased. Can you try to fix it?

@AhyoungRyu Fixed the issue with my commits, big shoutout to @DrIgor for helping resolve my issue! I also updated the tests (ex. testSingleDynamicFormSelectForm, testSingleDynamicFormCheckboxForm, testMultipleDynamicFormsSameType) to work with the new paragraph behaviour. All 14 tests pass now with the latest code in master.

Selenium tests are red in Travis but due to:
SparkParagraphIT.testSqlSpark:185 » NoSuchElement Unable to locate element: {"...
https://travis-ci.org/guicaro/zeppelin/jobs/212973588

@guicaro Thanks for the contribution!
CI problem has been fixed on master branch. Could you try rebase or merge master branch and see if CI becomes green?

@Leemoonsoo rebased from master and all green now, thanks for the heads up!

@guicaro Thanks for such great work! LGTM

Merge into master and branch-0.7 if there are no more comments on this.


pkg/client: no compile time Get or Put methods that mirror semantics of pk-get and pk-put

while looking for a programmatic interface to perkeep for a scraper of mine, i noticed there wasn't a one-to-one relationship between the contract of the cmd and the contract of the client.
should i just be using client.Fetch for gets and client.Upload for puts? i really want to avoid invoking the cmd from the shell each time and forking off a child process for each put
what i'm really looking for is some way to do something like this
httpRes, _ := http.Get(url)

pkRes, _ := pk.Put(httpRes.Body)

ping :D

Absolutely agree. I've created github.com/tgulacsi/camutil/camproxy but it's not ideal.

oh tyvm! will check it out

@mpl @bradfitz any official comment on this?

@mpl @bradfitz hey i’m going through old issues i’ve opened and will probably close this tomorrow. thought i’d bump it one more time

@atecce see what https://pkg.go.dev/github.com/tgulacsi/camproxy/camutil?tab=doc Uploader/Downloader does.

ohhhhhhh awesome. tyvm again i guess we'll just say it's supported elsewhere!


Added pyfhel hello world demo nb

Added a notebook exploring the FHE schemes "bfv" and "ckks" along with examples by taking and integer and float variables.
Related : #11

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from suppathak by writing /assign @suppathak in a comment. For more information see:The Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: erikerlandson
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 [erikerlandson]

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

This is great!  I notice a lack of division, at least dividing one encrypted value by another encrypted value

This is great! I notice a lack of division, at least dividing one encrypted value by another encrypted value

Thank you @erikerlandson . Have looked into it. However, Pyfhel package does not support any division.  One way thorough would be to find the clear text inverse and then multiplying with the ciphertext inverse..

I see you can do:   encrypted / unencrypted, like with the average example:  (e1 + e2) / 2.
Out of curiosity, does:  1 / e work?  Because if that works one could do:   d = 1 / e:  followed by e2 * d

Out of curiosity, does: 1 / e work? Because if that works one could do: d = 1 / e: followed by e2 * d

Unfortunately, no. Not for the ciphertext values and not even for plain text values. The only way is, 1/(actual_value), and then followed by encryption and multiplication is the way out.

One other I forgot:  I see they provide e1 == e2 (which is of course easy) - can they do e1 < e2 ?

I see they provide e1 == e2 (which is of course easy) - can they do e1 < e2 ?

This is a good point. I will try to update these point in another PR.
The point is Pyfhel only offers, == and != comparison. It does not support > or < comparison operations. One of the reason is for the security of cipher-text itself. Any cipher we would trust will generate a cipher text that looks random, which is one of the criteria we use on whether the cipher is trustworthy. If it is not random, it isn't.
We will however try to look into it more, to see if there is any clever mathematics that goes into comparing two ciphertexts.

It may be that < is unsafe - because if you have that, you can narrow your value down to any precision by trial and error, which (as you say) would defeat the value of the encryption.


iOS: Could not connect to development server.

name: iOS -- Could not connect to development server.
about: Something is not working as expected.

I have reviewed the documentation
I have searched existing issues
I am using the latest React Native version

After I upgrade the node version（brew upgrade） and delete the old version（brew cleanup）, my project can not run.When I create a new project again, it does not still work ，The error is the same。
The error:
2018-05-29 11:56:56.492993+0800 WFNowRupiah[53558:479116] Task <8C75D585-C49B-43A7-9660-CCA1575E61BB>.<1> finished with error - code: -1001
2018-05-29 11:56:56.556 [error][tid:NSOperationQueue 0x604000222120 (QOS: UNSPECIFIED)][RCTCxxBridge.mm:420] Failed to load bundle(http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false) with error:(Could not connect to development server.
Ensure the following:

Node server is running and available on the same network - run 'npm start' from react-native root
Node server URL is correctly set in AppDelegate
WiFi is enabled and connected to the same network as the Node Server

URL: http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false The operation couldn’t be completed. (NSURLErrorDomain error -999.))
Environment

Environment:
OS: macOS High Sierra 10.13.4
Node: 10.2.1
Yarn: 1.7.0
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.3.1 Build version 9E501
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.4 => 0.55.4
Steps to Reproduce

Xcode / react-native run-ios
Expected Behavior

Hope it works！
Actual Behavior

same error here

Try changing "localhost" (in  http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false) to your IP address. Type into terminal ifconfig and under en0 you will find your ipaddress next to inet (and before netmask).

I have the same problem , I fix terminal: killall node


fix: multiple calls to connect creates multiple (leaking) sockets

Check and return the _connectionCompleter.future when calling connect multiple times.
Check if there is already a _socketChannel created before making a connection to avoid creating multiple leaking sockets.
Cancel the StreamSubscription created when creating a socket after disconnecting.

This is a good observation. But it is not a fault of WebSocketConnectionDelegate - the delegates just does what you tell it to do - to connect, disconnect or reconnect (it must stay as abstract at this point). To avoid the leaks - it must be prevented by the higher structure PusherChannelsClient. But I will add StreamSubscription to connect method.

This is a good observation. But it is not a fault of WebSocketConnectionDelegate - the delegates just does what you tell it to do - to connect, disconnect or reconnect (it must stay as abstract at this point). To avoid the leaks - it must be prevented by the higher structure PusherChannelsClient. But I will add StreamSubscription to connect method.

Oh yeah you are right. Will modify this PR later with those changes!

@nicobritos  Closing with #11


chore(main): release 1.0.1

:robot: I have created a release beep boop
1.0.1 (2024-08-21)
Bug Fixes

chat: changing adapters in chat buffer to Ollama (5cc04a1)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.0.1
:sunflower:


Improved documentation of Hamiltonian models, fix bug in spinless Hubbard model

Edited the documentation of the Hubbard and mean-field models and moved them from the module header to the actual function so it shows up in the online documentation.
Fixed what seems to be a bug in the spinless Hubbard model in which the chemical and magnetic potentials aren't added as described in the model description.

@kevinsung Can you push a trivial change to this? I am not sure why it isn't running on Travis but maybe if you make a change it will run.

@dabacon do you have insight about what might be going on here? It's been two days and Travis hasn't started on this PR.

I accidentally fixed the checks not having run when I created a test PR with the same commits and travis did trigger against it. I guess it groups across PR boundaries by commit id.
Anyways, that means the only remaining issue is the CLA check being unable to verify author consent.


Add icons for Arch, Kali and OpenBSD

When you're other PR lands, rebase this and we can get it merged 🙂

Will do :+1:

Really weird: When running build.sh, for Kali the overlaid Quickemu icon is always the one with white background and a pink emu - but all other icons are fine!
Are you having the same result as me, or is my machine haunted? xD


Update dependencies

Hi !
babel-core new version is available, so an update could be great.

This isn't necessary. The range is ^ so the latest will be used each time babel-jest is installed.