Metrics to measure Shap accuracy

Are there any metrics available to measure  shap explainability for a prediction

You can check out Figure 3 of the TreeExplainer paper for some metrics (by accuracy I assume you mean how well the attributions capture model behavior).
Note that many of these metrics are "ablation" metrics that aim to remove/add features based on the the shap values (or feature attributions).  For instance if a feature has a very high positive attribution, that means it positively impacts the model's output.  If we remove that feature for a specific sample, then the model's output should probably decrease.
As a final note, (interventional) Shapley values in general should do very well for these metrics because ablation tests are close to the definition of Shapley values (which are the average marginal contribution of a feature).  One additional subtlety is that many approaches are approximate solutions (sampling/IME explainer, kernel explainer, although Interventional Tree Explainer is exact) so it can be tough to disentangle whether your metric measures how good your approximation is or how good the feature attribution is.

Hi Chen,
Thanks for the advice on the Tree Explainer paper! I just have a few questions:
The paper mentions that there are python implementations of the benchmark metrics available at https://github.com/suinleelab/treeexplainer-study however I can't seem to find them here?
I've since implemented some of the metrics myself based on my understanding of their descriptions (including the arxiv version of the paper). One thing I've noticed however is that when I use the kernel explainer on more than say 13 features with a background of 200+ and nsamples=2^13 I still only seem to score 0.6 on the local accuracy metric. Is there a reason why this is happening as I thought the kernel explainer would be exact when I enumerate all 2^M subsets?
Also, im not entirely sure how I would check the consistency of the explainer, is there any examples available on how I could check for this - I dont mind the computational burden as I'm in an awkward situation where I'm required to rigorously evaluate my work despite the theoretical certainties of Shapley values.
Any help would be much appreciated!
Kindest regards,
Pieter

Hi Pieter,
The benchmarks are implemented here!
I believe that Kernel Explainer should satisfy local accuracy - have you tried with any of the other explainers?  Two possible subtleties are (1) being careful about what output you explain for binary classification (probability or log-odds space) or (2) the l1_reg parameter in kernel explainer will regularize the number of important features, you can set it to l1_reg="num_features(13)".
If you are willing to incur exponential cost, you could also try SamplingExplainer which monte carlo samples the exponential subsets, although it may sample the same subsets multiple times so it may not be exact (in which case you may want to just implement the exact calculation yourself).  A final subtlety is that the number of background samples you use means that you may actually need (# background samples)*2^13 samples to get exact solutions.
Checking consistency is awkward as you said because it should be guaranteed, but you probably do it by defining a function v(S) that calculates the interventional conditional expectation (which is what Kernel/Sampling/Tree Explainer interventional calculate) of the function given an explicand and a background distribution.

Hi @HughChen ,
Thanks very much for your help, my results have been much better since trying out your suggestions - somehow I wasn't aware that we have to multiply nsamples by the background size as well!
Also thanks for pointing out where to find the benchmarking code. Unfortunately I'm finding it hard to follow and decipher how the code actually works. Do you think perhaps it would be possible to create a notebook down the line that gives some brief overview on how to use the various functions in our own code?
I think these benchmarking methods can be extremely helpful not only for comparing various explainers (kernel, Sampling, linear, Tree etc) but also for helping us to determine the best 'hyperparameters' of these explainers, such as comparing different methods for creating a background dataset etc. One thing that I'm currently working on in my own version of these benchmarks is to calculate the theoretical optimal curves that are possible when the shapley values are 100% correct in identifying which features cause the model to increase decrease the most etc. as this would allow one to verify that there method is robust, independent on how it performs relative to other methods.
Kindest regards,
Pieter

any updates on the metrics?

Hi Spidy,
I actually implemented my own version of these metrics for a paper that I was working on at the time (for a regression-based problem). In addition to implementing the mask metrics proposed in the Tree SHAP paper, I also implement my own version that provides an explicit ground truth that can be used to see how well explanations compare to the optimal case.
I tried my best to make the code legible and easy to follow at the time when I was writing it, however, I didn't intend to make it public. I've just created a repo where the files can be found (https://github.com/barnardp/Explainable-Resource-Reservation). Hopefully, they can provide you with some answers, or at least a good starting point for whatever you're working on. NB please note that calculating the ground truth for the mask metrics requires a lot of complexity, if I recall correctly it's close to the order of N!N^2 for most of them, so I suggest only running the code on one explanation first to see how long it takes!
Best regards,
Pieter


Fix issue with type narrowing in if-else-stmt

Purpose
$title
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/33380
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/33463
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/33444
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Will send a separate PR addressing the other suggestions.


fix 'cargo run' in README

The command as given in the README fails with cargo complaining that there are two binaries and it does not know which one to run.

Ah, I only now saw  #166. I could also implement the subcrate solution, I guess, if that's preferred.

Ah, I only now saw #166. I could also implement the subcrate solution, I guess, if that's preferred.

This is a good change nontheless. Feel free to open a new PR if you want to fix #166


Add a retry option

Add a retry option, sometimes you can get connection errors or timeout errors that can be solved with a retry.

https://github.com/kevva/download/tree/bac7dd9913302c37564b087f9e198658f5692234#options
https://github.com/sindresorhus/got/tree/f4cf6c7b44d047d505ed1fdf3a4e361b743bdfc2#retries


About the personX_spgan

Hi, @Simon4Yan
Thanks for providing this to pave the way to entering this competition!
I walked around and tried to run python learn/train.py and foud that the provided dataset, ie., challenge_data.zip has no subdirectory named personX_spgan. Am I missing something on this? Could you shed me some light on this?
Thanks in advance!

Thanks for your attention.
The personX_spgan denotes the translated images from SPGAN. SPGAN conducts source-target image translation on personX, such that the translated images follow the distribution of the target. Thus, the Re-ID model trained on the translated images achieves high accuracy on the test set.
The baseline should use personX as the training dataset. I have updated this.
Thanks.

Can we use personX_spgan in the challenge?


Different activity level for 'landed' and 'in orbit

I wish some parts had higher activity levels on the ground when in space. It makes sense since there is a gravity on the surface and also kerbanauts can easily hop out and walk around while player is not watching.

Oops. Turns out that is already implemented. Cool!


Re-enable JVMTI test WaitNotifySuspendedVThreadTest

Test has been fixed by eclipse-openj9/openj9#16943
Signed-off-by: Dipak Bagadiya<EMAIL_ADDRESS>

Grammar nitpick (The test has been ... :
The test has been fixed by https://github.com/eclipse-openj9/openj9/pull/16943.

Grammar nitpick (The test has been ...):
The test has been fixed by eclipse-openj9/openj9#16943.


Add support to pickup unnamed foreign assets

https://github.com/temptemp3/arccjs/commit/0e5b905555ecd5b5be2feef86e648f479cc88e13


USHIFT-1551: only log gateway address when it changes

We only want to log changes in state. This patch moves a log statement
into a conditional so that the message is only emitted when the
host gateway IP address changes.
/assign @pliurh @pacevedom

/lgtm

/test microshift-metal-tests


[ompl] Cannot find lib files when using CMake

Describe the bug
After doing find_package and successfully finding ompl, linking fails because it can't find /lib/boost_serialization-vc140-mt.lib
Environment

OS: Windows 10
Compiler: MSVC 2019

To Reproduce
Steps to reproduce the behavior:

./vcpkg install ompl --triplet=x64-windows
find_package(ompl REQUIRED)

Expected behavior
I expect to be able to link the library after successfully using find_package
Failure logs
LINK : fatal error LNK1181: cannot open input file '\lib\boost_serialization-vc140-mt.lib'
Additional context
This appears to occur because both ${OMPL_LIBRARY_DIRS} and ${OMPL_LIBRARIES} use ${_IMPORT_PREFIX} in omplConfig.cmake which seems to be empty, leading to paths like /lib and /debug/lib being in ${OMPL_LIBRARY_DIRS} and /lib/boost_serialization-vc140-mt.lib in ${OMPL_LIBRARIES}. During port installation, all the paths were correct absolute paths at one point, and parts of the paths were replaced by ${_IMPORT_PREFIX} when vcpkg_fixup_cmake_targets was called.

See https://github.com/microsoft/vcpkg/pull/18908#issuecomment-878693222


🛑 EBUSY: resource busy or locked, rmdir 'C:\Users\hp.amplify\lib\amplify-dynamodb-simulator\emulator'

🛑 EBUSY: resource busy or locked, rmdir 'C:\Users\hp.amplify\lib\amplify-dynamodb-simulator\emulator'
This error has appeared after the upgrading amplify

Hey @KinyanjuiJonathan :wave: thanks for raising this! To better assist, would you mind porting this over to one of our issue templates?

I am getting it too

+1 - after upgrade

Y'all could have fixed this bug 4 months ago, but chose not to because... ?


test(rpc): add tests of rpc module, including rpc error, settings, he…

…lpers

Codecov Report

Merging #149 into develop will increase coverage by 2.02%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #149      +/-   ##
===========================================
+ Coverage     92.3%   94.32%   +2.02%
===========================================
  Files            9        9
  Lines          195      194       -1
  Branches        38       38
===========================================
+ Hits           180      183       +3
+ Misses          12       10       -2
+ Partials         3        1       -2

Impacted Files
Coverage Δ

packages/ckb-sdk-rpc/src/resultFormatter.ts
100% <ø> (+50%)
: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 47928ab...609731d. Read the comment docs.


BUG: fix wheel version numbering and sdist content

We can hardly release version 0.0.0. now can we...

Okay, need this and is pretty trivial so hitting the green button.


Fixing hero section image

Issue that this pull request solves
Closes: #233
Proposed changes
added object-fit: cover
Brief description of what is fixed or changed
Fix the hero image in about us
Types of changes
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Put an x in the boxes that apply

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] My changes does not break the current system and it passes all the current test cases.

Screenshots

Other information
Any other information that is important to this pull request

@abhay313 are you a SWoC or DWoC participant?

@abhay313 are you a SWoC or DWoC participant?

SWoC participant

SWoC participant


[PowerRename] Loading files indicator

Description of the new feature / enhancement
When loading multiple files, PowerRename is sometimes unresponsive and as a user it is hard to see what's happening. Therefore, we could polish the UI by adding a loading indicator that provides feedback that files are loading.
Scenario when this would be used?
Loading files in PowerRename
cc @stefansjfw

is this still pressing?  thought our load times were drastically better

@stefansjfw you did some testing with many files right? Do you think we still need this?

With current PowerRename (v0.53.1) loading a folder with ~100k files and ~13.5k subfolders takes about 1 minute without any feedback other than high CPU utilisation (Windows 10, i7-9700).
Some indicator that PowerRename is in fact working on loading files would be nice.

This was originally discussed because we had this indicator in old PowerRename UI. Loading times are the same as for old PowerRename.

@nox-4O4 how often do you rename that many files / point it at such a large?

Right now, i am marking this pri-3.  Would be nice to have but my gut (no data but based on my own usage) says most renames are against sub 100 files so stuff should be near instant.

@nox-4O4 how often do you rename that many files / point it at such a large?

Not very often. The few times I do, I kind of use the CPU consumption as a "still alive and working" indicator.

my gut (no data but based on my own usage) says most renames are against sub 100 files

That matches my experience too.


Changed rentEpoch type in AccountHeader from number to BigInt

Addressed issue #99

I ran unit tests, and it worked. (please don't get mad if I messed up, I'm still a noob)

Umm...I don't understand why it failed the first test.
It passed on the first commit??????

INPUT_BRANCH value: issue_99_fix
Should I merge the branch with main and then give pull request again?

It's a linting problem. If you run pnpn lint:fix && pnpn format:fix then commit the result, it should be happy.


proposal: spatial manipulation matrices

Background
Most (if not all) 3D renderers use spatial transformation matrices. For example, here is the documentation of three.js' Matrix4 type which allows for rotations and translations. Similarly, the corresponding matrix for 2D rotation+translation is a 3x3 matrix (three.js link).
Today there is a 3x3 spatial matrix implementation, the r3.Mat type. This type was thought of for use as a rotation tensor, which describes a complete rotation in 3D space, without translation. This is useful for studying rigid-body dynamics of arbitrarily oriented frames in space, such as is the case with planes and drones. However, its functionality is a far cry from a Matrix4 type, which brings rotation and translation into the equation, something which is crucial for 3D rendering.
These matrices have been implemented in sdfx by Jason Harris in Go: https://github.com/soypat/sdf/blob/main/matrix.go. The "important" methods this matrix should have for the correct functioning of the sdf package are as follows for the Matrix4 type:

func NewMatrix4(data []float64) Matrix4
func (a Matrix4) MulPosition(b r3.Vec) r3.Vec Worth mentioning three.js calls this "applying". Maybe that is a more apt name ApplyPosition
func (a Matrix4) Inverse() Matrix4
func (a Matrix4) Det() float64
func (a Matrix4) MulBox(box r3.Box) r3.Box  rotates/translates a 2d bounding box and resizes for axis-alignment. Maybe rename to ApplyBox
func (a Matrix4) Scale(k float64) Matrix4 multiplies all values by k and returns new matrix

Matrix3 should have corresponding methods of the same name too for r2 types.
Proposal
Add a similar-to Matrix3 and Matrix4 types somewhere in the spatial package. My guess of the package name where it belongs is at best as good as yours (r2, mat2, mat?) .
Will Matrix3 use r3.Mat, or should these methods be implemented for r3.Mat? It seems as though the latter would mix too many responsibilities in one type i.e. a matrix that can be used for 3D rotations or 2D spatial transformations.
Another idea is to add these types as r3.Transform (Matrix4). The possible downside to this is that if r2.Transform wants to use the underlying r3.Mat type then there could be a future import cycle waiting to happen (I figure it would be more natural for r3 to import r2).

Could breaking the r3.Mat type be entertained to figure out a elegant way to solve this?
Or maybe the r3.Mat logic could be moved to an internal package that can be shared between r2 and r3.
Or just implement the above methods without typical matrix methods for now.

The code shown above uses "direct" types- they should probably be pointers to the Matrix though (?).
I am in no hurry to implement these so this proposal can serve as a floor to discuss the idea.
Zero value
The zero value of a Transformation matrix should be the Identity matrix, ideally.
Potential impact of proposal
3D renderer libraries are happy with gonum!

I went out of my way to create a minimal quasi-working example of what the Matrix3 type could look like: https://github.com/soypat/sdf/blob/main/internal/d2/transform.go

I'm OK with this in principle. It would be worth looking into how gioui does tranforms since they have worked on efficient implementations that could be generalised to the cases here.

gioui.org's affine transformation matrix.
https://git.sr.ht/~eliasnaur/gio/tree/0e2e02a66237/f32/affine.go#L12 (2D)
Here's my take on it:
https://github.com/soypat/go-play3d/blob/main/transform.go (3D)

@kortschak Ran into a conundrum adding shear/skew. I have the following signature for Compose and AddShear
func ComposeAffine(translate, scale Vec, q Rotation, sxy, sxz, syx, syz, szx, szy float64) Affine

func (a Affine) AddShear(origin Vec, sxy, sxz, syx, syz, szx, szy float64) Affine

Feel like the verbosity with all these floats might be too much to comfortably use these functions.
// Hard to decipher which number corresponds to which shear plane/component.
a := ComposeAffine(r3.Vec{}, r3.Vec{}, r3.Rotation{}, 1, .2, 0, 0, math.Pi, 6)

This could be solved by adding a Shear type that has Sxx, Sxy... fields. This Shear type could also implement Transformer.

Adding XX, YY, ZZ fields to Shear type would then allow scaling functionality. Maybe this type could be called Warp? This would further simplify ComposeAffine:

func ComposeAffine(translate Vec, scaleShear Warp, q Rotation) Affine
identityAffine := ComposeAffine(Vec{}, Warp{}, Rotation{})

The cool thing about this is that now the zero values of all arguments would yield the identity transform!

Another question: What does shear XY do?
Does it:

Shear on plane X, in direction Y. Similar to how tensors are represented in solid and fluid mechanics. In this example a vector Vec{Z:z} -> Vec{Z:z, Y: z*w.XY}. I'm biased towards this representation since I've studied these fields in depth.
Shear position X in direction Y. This is how three.js does things. Vec{X:x} -> Vec{X:x, Y: x*w.XY}. Might be more intuitive to most users.

All respect to mathgl library, it's got nearly everything I need and I've used it several times in the past. However, it's not quite my cup of tea with respect to what a good API should look like. I find gonum has hit the nail on the head by sectioning vector operations as package level functions resulting in readable vector operations, something that has burned me in the past with the sdfx library as well.


Alt model

looks like https://github.com/bvernot/freezing-archer/blob/master/bin/LL_analysis_fn.R#L51
should be dt.alt.arc3 = with(dt.model[keys.arc3][ms_intr_ss_sites.arc3 > 10]

No difference in dt.alt.arc2 and dt.alt.arc3 generated by freezing-archer

dt.model[keys.arc2] and dt.model[keys.arc3] are join operations, which joins data.table dt.model with keys.arc2 and keys.arc3. See https://medium.com/analytics-vidhya/r-data-table-joins-48f00b46ce29
What is the purpose to use join operation here?

looks like dt.alt.arc3 is just the results from dt.alt.arc2 by swapping column hap_pval.arc2 with column hap_pval.arc3
https://github.com/bvernot/freezing-archer/blob/master/bin/LL_analysis_fn.R#L47
https://github.com/bvernot/freezing-archer/blob/master/bin/LL_analysis_fn.R#L55
Why wrote so many codes to perform swapping?


Add database fields and update struct

Looks good, agree with Ali that it needs to be merged with developer to resolve the merge conflicts to complete the the PR.


Opportunity for code cleanup in FrankDocModel.createAttributes()

Two tasks of this method can be removed:

Currently, a getter that accompanies an attribute setter is used for type checking. The return type of the getter is compared with the argument type of the setter. This check becomes irrelevant because getters may be hidden. Getters that are done with Lombok @Getter will not be visible when the de-lombok step is out of the F!F build.
Attributes of an enum type will always have the enum as argument type. The check for getXxxEnum() to find the enum type will become irrelevant and can be removed.

See https://github.com/frankframework/frankframework/issues/6344.

A lot of information is lost if we don't delombok our code, because the Javadoc tool does not use the lombok plugin to do annotation processing. The XSD diff which I tested only on the core module code had about 500 lines of differences. The current solution is in the PR, keeping the delombok step.

Just discussed with Niels: number 2 is OK to perform, so if you have some time for that, that's ok. 👍🏻
Number 1 should stay.


Provide a makefile target and rule to link all object files into a st…

…atically linked library 'libPCM.a'.
This provides a convenient way to link projects with PCM.

thanks!

I just figured we have to link all object files and not onley the executable's object files. I will file another pull request for the fix. My bad.


Please add support for Options just like in the .Net socket - e.g. add custom TImeOut/SubProtocol

Please add support for Options just like in the .Net socket - e.g. add custom TImeOut/SubProtocol.
Just make another class inside Core folder - UniformSocketOptions.cs, let it be a simple class and copy paste fields from the .Net Socket Options.
Also don't forget to add SetOptions(UniformSocketOptions) under the IWebSocket interface

@studentutu  Thanks for your suggestion, I will think about it.

Subprotocol supported at version 2.6.5 .


Change Bibliography category dropdown to per-category toggles

As mentioned by @mkarmona, our new Bibliography section will allow for users to select more than one category (e.g. targets AND diseases).
The current implementation is a single-select drop down, which limits users to only selecting one category. We would like to change this so that users can select multiple categories, with the default that all categories are selected.
Material UI offers different options that we can integrate:

Switches: https://material-ui.com/components/switches/
Toggles: https://material-ui.com/components/toggle-button/
Checkboxes: https://material-ui.com/components/checkboxes/

closing this as work is done


Performance view prototype

Feature goal: The user should be able to assess the impact of change detection on each component at-a-glance.
@abmohan – we're probably looking to prototype the best way of doing this.
/cc @winkerVSbecks

I think it would be cool to incorporate useful data:

Total heap size
Heap usage
Total components counted
Render performance

of observables (subscriptions)

Few other suggestions that came up in the discussions were:-

Rendering time of each of the components would be great
How long a route takes for render as well as the resolutions time

Do we know if any of this stuff is already available through WTF?

Not yet I am just exploring options for these

This feature is no longer planned, though we may reopen it at a later date.


Feature Request: Gradle Plugin

It would be great to have a Gradle plugin as well beside Ant and Maven in order to work along with Spring Boot (no web.xml).

It seems BundleProcessor needs a re-work here in order to create a servlet context without web.xml. I just created a Gradle Plugin (not tested yet). Feel free to copy the code: https://github.com/dtrunk90/jawr-gradle-plugin


OmniSharp-rosyln releases needs releases for more Linux distros

There isn't a single CoreCLR which is compatible with all Linux distros. So there shouldn't be a 'omnisharp-linux-x64-netcoreapp1.0.tar.gz' but rather multiple .gz's (or a single .gz or nupkg with just the OmniSharp bits).
If you want to follow the CoreCLR model, there should currently be three gz's with many more to come --

Ubuntu-14.04
Red Hat Enterprise Linux 7.2 / Centos 7
Debian 8.2

From what we can tell, the Ubuntu CoreCLR actually works fine on Debian, so you can omit that if you want.

We need to add two more runtime targets. The current linux build is actually Ubuntu-14.04.
/cc @david-driscoll

Marking this as done. It was actually done awhile ago, but it is now "more" done with https://github.com/OmniSharp/omnisharp-roslyn/pull/596.


Modify service catalog list to show plans

This PR modifies service catalog list services command to show corresponding plans
to services,
For example,
$ odo catalog list services
NAME                         PLANS
dh-gluster-s3-apb            default
dh-nginx-apb                 default
dh-proxy-config-apb          passthrough,custom
dh-eclipse-che-apb           prod
dh-galera-apb                persistent,ephemeral

Is there a command to see the detail of the plan ? Without this information, it is impossible for a user/developer to determine what are the parameters, their type, ... ?

@cmoulliard I am working on that. Taking baby steps, first plans then parameters :smile:

This PR modifies service catalog list services com

Can you also add a column with short or long description of the service like also the versions avalaible 10.1, 10.2, ... ?

@cmoulliard , I can't see version field in clusterserviceclass resource:
$ svcat get class dh-galera-apb -o yaml
metadata:
  creationTimestamp: 2018-09-05T10:33:24Z
  name: 192097962f2955b0582b5d53ddb942e4
  resourceVersion: "525"
  selfLink: /apis/servicecatalog.k8s.io/v1beta1/clusterserviceclasses/192097962f2955b0582b5d53ddb942e4
  uid: 1e717de3-b0f7-11e8-b1af-0242ac110002
spec:
  bindable: true
  bindingRetrievable: false
  clusterServiceBrokerName: openshift-automation-service-broker
  description: Deploy Galera with a Replication Operator
  externalID: 192097962f2955b0582b5d53ddb942e4
  externalMetadata:
    displayName: galera
  externalName: dh-galera-apb
  planUpdatable: false
status:
  removedFromBrokerCatalog: false

and some of the descriptions are so big that table for odo catalog list services looks messy

version field

This is an info that you will get from the plan. It seems that is not so easy to get it as it is defined as part of the plan within the properties ...
svcat get plan dh-mariadb-apb/dev -o yaml
metadata:
  creationTimestamp: 2018-09-03T08:01:20Z
  name: 7f88be6129622f72554c20af879a8ce0
  resourceVersion: "1879"
  selfLink: /apis/servicecatalog.k8s.io/v1beta1/clusterserviceplans/7f88be6129622f72554c20af879a8ce0
  uid: 8af1fdad-af4f-11e8-821e-0242ac110005
spec:
  clusterServiceBrokerName: openshift-automation-service-broker
  clusterServiceClassRef:
    name: 67042296c7c95e84142f21f58da2ebfe
  description: This plan deploys a single MariaDB instance with ephemeral storage
  externalID: 7f88be6129622f72554c20af879a8ce0
  externalMetadata:
    cost: $0.00
    displayName: Development
    schemas:
      service_binding:
        create:
          openshift_form_definition: []
      service_instance:
        create:
          openshift_form_definition:
          - mariadb_database
          - key: mariadb_root_password
            type: password
          - mariadb_user
          - key: mariadb_password
            type: password
          - mariadb_version
        update:
          openshift_form_definition:
          - mariadb_version
  externalName: dev
  free: true
  instanceCreateParameterSchema:
    $schema: http://json-schema.org/draft-04/schema
    additionalProperties: false
    properties:
      mariadb_database:
        default: admin
        description: MariaDB default database name
        pattern: ^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$
        title: MariaDB Database Name
        type: string
      mariadb_password:
        title: MariaDB Password
        type: string
      mariadb_root_password:
        title: MariaDB Root Password
        type: string
      mariadb_user:
        default: admin
        pattern: ^[a-zA-Z0-9_]*[a-zA-Z_]+[a-zA-Z0-9_]*$
        title: MariaDB User
        type: string
      mariadb_version:
        default: "10.2"
        enum:
        - "10.2"
        - "10.1"
        title: MariaDB Version
        type: string
    required:
    - mariadb_database
    - mariadb_root_password
    - mariadb_user
    - mariadb_password
    - mariadb_version
    type: object
  instanceUpdateParameterSchema:
    $schema: http://json-schema.org/draft-04/schema
    additionalProperties: false
    properties:
      mariadb_version:
        default: "10.2"
        enum:
        - "10.2"
        - "10.1"
        title: MariaDB Version
        type: string
    required:
    - mariadb_version
    type: object
  serviceBindingCreateParameterSchema:
    $schema: http://json-schema.org/draft-04/schema
    additionalProperties: false
    type: object
status:
  removedFromBrokerCatalog: false

@mik-dass  @cdrage @syamgk please review :smile:

@surajnarwade do we have tests for this?

@ashetty1 , we have separate issue for tracking test and document related to service catalog here https://github.com/redhat-developer/odo/issues/678

@ashetty1 , we need to enable service catalog, template-service-broker and automation-service-broker while doing oc cluster up in travis and also this don't hurt any odo core functionality, that's why I was tracking test and docs in separate PR

@syamgk , @ashetty1 , I added unit test as well, can you please review once ?

Apart from the comments, code LGTM. Also tested locally and it works :+1:

@cdrage @kadel , Check now,
 time odo catalog list services
...
...
real	0m0.135s
user	0m0.076s
sys	0m0.031s

time reduced :dancer:

@surajnarwade Wayyyy faster :fast_forward:
This code LGTM!


Clarify that "empty string" means "" for unlock on unlocked file

Addresses https://github.com/Microsoft/Office-Online-Test-Tools-and-Documentation/issues/319

Really? It's hard to imagine how 'empty string' might be confusing, but fine, if you've got somebody asking for clarification I'm fine with the change.

Per offline conversation with @chrisbro-MSFT, I'm rejecting this PR. I filed #323 to track whatever changes we want/need to make regarding the lock header.


48_ChanInputCB "E1510: Value too large"

not sure why im getting this error, basically when connecting (and sometimes just at random when using the plugin and editing text/executing commands etc) I get these errors pop up on screen:

Can confirm. Same thing here on nvim 0.10.0. Which package manager are you using?

good to know... I recently migrated from lazy to rocks.nvim, so I thought it might have something to do with that. Apparently not!

Hmmmm... the problem just vanished into thin air. I did a quickload update a bit earlier. Might have done the trick.

I get the same error when I ASDF:LOAD-SYSTEM my website project (https://gitlab.com/HiPhish/workshop2), so it's not related to QL:QUICKLOAD. There must be something specific to this project, because it does not happen with others.

The offending line seems to be the call to json_decode. I changed the function a big to echo out the function argument:
function! s:ChanInputCB(job_id, data, source) dict

  let obj_list = []
  let buffered = get(self, 'recv_buffer', '')
  for frag in a:data
    let buffered ..= frag
    try
      " XXX: what about E488: Trailing characters?
      try
      	let json_obj = json_decode(buffered)
      catch /E1510/
      	echom buffered
      endtry
      " echomsg 'RECV <<' json_obj
      call add(obj_list, json_obj)
      let buffered = ''
    catch /^Vim\%((\a\+)\)\=:E474/  " Invalid argument
    endtry
  endfor
  " ...
endfunction

Using writefile to output the variable contents did not work, the result was always cut off for some reason. I had to :echom it and then manually copy-paste the output from the terminal. Here is the output, one is the raw form, the other is the pretty-printed form for your sanity:

buffered.json
buffered_pp.json

Reading those file back in and decoding them worked without issue though, so I have no idea what is going on.
let buffered = readline('buffered.json')
echo json_decode(buffered)

Doing some more investigation, this time into the Neovim source code; the following is valid for Neovim 0.10.1.

The error string "E1510: Value too large: %s" is defined as the constant e_val_too_large in src/nvim/globals.h

That constant is used in three places:

src/nvim/cmdhist.c:639 (implementation of the histnr() Vim function)
src/nvim/ex_cmds.c:3446 (implementation of the :substitute ex-command and its preview)
src/nvim/strings.c:999 (the helper C function format_overflow_error)

This last one is our only real candidate because none of the other functions get used in C.

All calls to format_overflow_error happen when the check if (i > MAX_ALLOWED_STRING_WIDTH) fails for some integer i. The hardcoded value of MAX_ALLOWED_STRING_WIDTH is 6400.

All calls are in one of two functions within strings.c:

get_unsigned_int
vim_vsnprintf_typval

This is as far as I can get by just looking at the code. The next step will probably require some debugging. In any case the issue seems to be that some string is too large.

More information: The json_decode_string function has received an incomplete JSON string:
incomplete.json (line breaks and indentation added by me for your viewing pleasure)
The in-memory string has a length of 32768 bytes (including the terminating NUL), which is 0x8000 or 0b100000000000.  If it is the latter the problem might be solvable in Nvlime by accumulating received strings until the JSON is complete.

@monkoose I am concluding my investigation for now. The way I understand there are two unrelated issues:

The incomplete JSON string
The useless error message E1510: Value too large

The latter is an unfortunate path Neovim took when it was trying to format the actual error message, it's not relevant here. The next step would be to investigate why the JSON string is incomplete. Neovim can definitely handle strings this large; take the buffered.json file I posted above:
let buffered = readfile('buffered.json')
" works without issue:
echo json_decode(buffered)
" Also works
echo json_decode(buffered[0])

Oh, now I see that nvlime is already accumulating partial JSON strings. In that case he only thing that needs to be done is add a second catch clause:
  let obj_list = []
  let buffered = get(self, 'recv_buffer', '')
  for frag in a:data
    let buffered ..= frag
    try
      " XXX: what about E488: Trailing characters?
      let json_obj = json_decode(buffered)
      " echomsg 'RECV <<' json_obj
      call add(obj_list, json_obj)
      let buffered = ''
    catch /^Vim\%((\a\+)\)\=:E474/  " Invalid argument
    catch /^Vim\%((\a\+)\)\=:E1510/  " <--- NEW
    endtry
  endfor

But I think the error that's thrown is just plain wrong, so I have opened an issue in the Neovim repo: https://github.com/neovim/neovim/issues/29886. If Neovim always throws E474 for incomplete JSON strings we don't need a second catch in nvlime.

Hello @HiPhish does this new catch helps?
There are some things happen in my life so I'm not so active on GitHub, but adding just this line is trivial, and fixing this issue on neovim side could take a lot of time if ever.
So if this another catch is enough I will add it, it the same PR is welcome.

I would guess that the new catch should do the trick, but I would like to test-drive it for a while first before I open open a PR. We should probably add a comment to the new catch that links to the Neovim issue so it can be removed at some later point when the issue is fixed in Neovim.

@monkoose PR is up: https://github.com/monkoose/nvlime/pull/15
The issue has been fixed in Neovim, but I would merge this workaround anyway at least until a new fixed version gets released. Maybe keep it around for a while after that to give users the time to upgrade to the new Neovim. To remove this hack again a simple git revert should be enough.

Thanks for investigation and the PR.


Botnet C&C domain list

I searched a little bit. Looks like some people have discussed about it before in "Are botnets considered for inclusion? #2045", but no further info any more.
I try to find a combined botnet command-and-control(c&c or c2) domain list to protect the IoT devices, but seems not available yet in the environment.
Would this be considered ?
For more info about botnet c&c domain, please refer to this: https://www.techtarget.com/whatis/definition/command-and-control-server-CC-server.
Regards,

Example domains:

cbdgzy.pirate
cncvwk.libre
czbrwa.geek
dogchink.oss
edrnhe.oss
fawzpp.indy
fuckdafurry.dyn
gottalovethe.indy
gropethe.indy
hbakun.geek
hbpngf.oss
hfoddy.dyn
hinetlab.gopher
hxqytk.geek
iarrfd.dyn
iaxtpa.parody
icansinga.parody
icanteatthedog.pirate
icecoldfridge.libre
ksarpo.parody
kxynjt.indy
metbez.gopher
mfszki.gopher
monkeyontop.gopher
mqcgbs.gopher
onthereps.geek
pektbo.libre
pwskys.dyn
qhedye.oss
rikzgj.pirate
rmdtqq.libre
roaqxg.parody
rwziag.pirate
shetoldmeshewas12.dyn
shetoldmeshewas12.geek
shetoldmeshewas12.gopher
shetoldmeshewas12.indy
shetoldmeshewas12.libre
shetoldmeshewas12.oss
shetoldmeshewas12.parody
shetoldmeshewas12.pirate
shetoldmeshewas13.dyn
shetoldmeshewas13.geek
shetoldmeshewas13.gopher
shetoldmeshewas13.indy
shetoldmeshewas13.libre
shetoldmeshewas13.oss
shetoldmeshewas13.parody
shetoldmeshewas13.pirate
suckmytoe.libre
thischinkisa.geek
tjanwl.gopher
ujbljw.pirate
ulkvmb.oss
vbffwf.dyn
vrodpw.indy
vvsjfn.parody
wnisyi.libre
xtltgx.geek
xtvyez.indy
yelloskinscant.parody
yellowskin.oss
youra.geek
pboconline1023.dyn
pboconline1248.geek
pboconline2389.geek
pboconline3615.parody
pboconline7629.pirate
pboconline8271.parody
pboconline8273.pirate
pboconline9080.dyn
hiakamai.dyn
himrresearcher.dyn
infectedslurs.geek
netfags.geek
dogeatingchink.parody
w3d0ntlikebot5.parody
infectedchink.pirate
yellowchink.pirate
pb1345.dyn
pb3928.parody
pb9827.parody
pb2871.pirate
pb5872.pirate
etbez.gopher
fszki.gopher
qcgbs.gopher
hbpngf.libre
rdtqq.libre
ede.dyn
oke.dyn
ulkvb.oss
ujbljw.pirate
husd8uasd9.online
asdjjasdhioasdia.online
infectedchink.online
cooldockmantoo.men
fuckmy.website
iliveona.cloud
infectedchink.cat
pqahzam.ink
sdfsd.xyz
cjfop.xyz
hbdfblf.xyz
idfdfh.xyz
jxhfn.xyz
homehitter.tk
shetoldmeshewas12.uno
skid.uno
dogeatingchink.uno
getcred.uk
fuckmy.site
fuckmy.store

Thank you for this @WFANG12719.
Issue #2045 explains why hosts files can't stop bots.
Bots call us. Hosts files don't operate on inbound.
Closing.


Aligning content according to screen size

The content on the welcome screen is now aligned nicely for different screen sizes. On smaller screens the Raiden logo appears on top of the app name and on larger screens it appears to the left of the app name.
Smaller Screens

Larger Screens

Thank you very much It looks good. I only have a request. Could we please change the double <br />? one approach would be to wrap the second line in a tag and use css to give it the space it requires.

Sure thing, will do that!


Connecting mysql on host

Hi,
First of all, thanks for the great work on this image! Unfortunately I'm having a problem connecting to my mysql server on the host. Using <IP_ADDRESS> does not work, so I think I have to use a socket connection.
The problem is I don't know how to configure this using the environment variables.
Could you point me in the right direction?
Best regards,
Peter

@ploef using <IP_ADDRESS> will not work, because it would address the container itself. If you are trying to connect to a mysql server that is running on the same host as the container you should rather use <IP_ADDRESS> or whatever the output of ifconfig docker0 is. Also make sure the mysql user is allowed remote access originating from the 172.17.%.% address space.
Use of the mysql socket is technically possible, but not yet supported by the image so it will not work at the moment.

@ploef did you get the issue resolved?


Add xplicit transaction passing api

Thanks to suggestion by @gasche.

There is a lot of code duplication with slightly-different variants of the same functions. This could be avoid by turning update_as to CPS style (instead of ... -> casn * cass * 'a, make that (casn -> cass -> 'a -> 'r) -> 'r), and then using it in Tx to return log * 'a and in Xt to mutate the input and return just 'a.

There is a lot of code duplication with slightly-different variants of the same functions. This could be avoid by turning update_as to CPS style (instead of ... -> casn * cass * 'a, make that (casn -> cass -> 'a -> 'r) -> 'r), and then using it in Tx to return log * 'a and in Xt to mutate the input and return just 'a.

Yes, CPS can reduce duplication here.
I made a quick experiment to use CPS and unfortunately it seems to perform worse.  I assume the compiler is not quite as capable inlining CPS style functions.  The amount of duplication doesn't feel high enough to warrant reducing performance by 5%-20% (based on benchmarks against main).  But this is certainly worth revisiting if there is some specific way to coerce the compiler to perform the necessary optimizations to avoid performance regression.
Note that the implementation already intentionally has some amount of duplication (e.g. perform first iteration of a loop outside the loop) for performance reasons.

In a private conversation, @kayceesrk asked about the possibility of breaking the abstraction by spawning a domain.  That is a good question, because it is well known that multi-shot continuations basically allow one to break all sorts of higher-order mutable abstractions.
I believe the implementation can be considered reasonably safe against that.  There are a couple of reasons for that.
First of all, a log can only be attempted or commited through a transaction function that needs to be polymorphic with respect to the log.  So, even if a domain could be spawned inside that transaction function and retain reference to the log, there is no way to attempt or commit that log (without using unsafe features of OCaml).
The log itself, however, contains both atomic and non-atomic mutable locations and it is not thread/domain safe — log construction needs to happen within a single thread of execution and we should document that.  However, the only location that is being mutated during the log construction is the mutable cass : cass field.  This means that even if the log would be captured by a domain and then modified after the log has been attempted, such mutations could not change any of the k-CAS locations.  However, it is possible to (un)safely mutate the mutable cass : cass field and change the log before the log attempt is finished, just like with ordinary captured refs or other mutable fields.

My understanding of your point is as follows: if we move from a persistent API (returning a new state) to a mutable API (mutating the previous state), do we get in trouble on unsynchronized concurrent usage? In other words, now we have to decide whether the log value is domain-safe or not -- if we wanted to make it domain-safe we would need to use Atomic.t which incurs extra overhead. You seem intent on documenting this as "not domain-safe", and this seems fine.
More prose on this, less important:

The implementation choices may influence what users observe if they use the data-structure incorrectly. Correctly you use a record with two fields that are mutated independently. You could also use a mutable reference to a pair of states (that is, exactly log ref with your previous log type); then data races would never break the guarantee that the two elements of the pair have been produced together, they represent a valid log. You would, at worst, only miss some of the log operations performed by other domains.
You could also equip the structure with an atomic version counter to detect incorrect usage and fail early. But then again, this is probably overkill for something that is only going to be used in short sections of sequential code performing lock-free operations.

You seem intent on documenting this as "not domain-safe", and this seems fine.

Yes.

You would, at worst, only miss some of the log operations performed by other domains.

Hmm... I think it is worse than that.  Log update in (another) domain spawned inside a transaction could read cass at the start (when it contains NIL) and then update the cass just before the initiator domain reads cass. All the operations made by the initiator domain would be lost and the result computed by the initiator domain would be completely inconsistent with the log.
Whether using a mutable field (i.e. casn * mutable cass) or reference (i.e. (casn * cass) ref) doesn't change that because the casn part of the log is (for the updates of the cass reference) constant so there is no difference in level of consistency between the two implementations.  I wondered about this myself, but upon a closer look, there is no difference.
But, yes, I would say it is fine to say that the log itself is not domain-safe and adding safety guards to it seems overkill to me at this point, because misuse basically requires cleverness (you need to spawn something that lives beyond the scope) and seems reasonably unlikely to happen accidentally.
I think that to make the log domain-safe, one could change the log updates to be performed atomically.  IOW, instead of just writing to xt.cass
    xt.cass <- CASN (loc, state, l, r);

the updates would be done using compare_and_set
  let old_cass = Atomic.get xt.cass
  ...
  if not (Atomic.compare_and_set xt.cass old_cass new_cass) then
    retry_log_update ...
  else
    ...

This should work to ensure that updates to the log are atomic, because the cass updates always allocate so the value of cass is always unique after each update.
The problem with this is that it would likely make the log updates substantially slower, because then they would be done inside a retry loop (inhibiting compiler optimizations) and using slower atomic operations.

(A very very minor point: due to my at-name in your commit message, I get two notification emails each time you rebase this PR, so I got about 80 right now. It's a silly aspect of the Github interface, but for this reason I generally prefer to use full names or just nicknames without the at-mention sign in commit messages; when the information is available I use the semi-standard Suggested-by: name <email> form. Thanks for the explicit crediting anyway, it's a nice touch.)

so I got about 80 right now

Ouch! Sorry about that!
I didn't realise GH sends so many emails as I personally tend to always disable email notifications from every service I use (and I have disabled those on GH also).
BTW, I think the PR is pretty much ready.  I just made some tweaks to the documentation.  I'll update the main note with some more information on the PR shortly.

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.5 ms ±   0.1 ms    [User: 2.6 ms, System: 0.6 ms]
  Range (min … max):     3.4 ms …   4.1 ms    730 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.5 ms ±   0.0 ms    [User: 2.6 ms, System: 0.6 ms]
  Range (min … max):     3.4 ms …   4.1 ms    731 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

Summary
  'kcas-main/_build/default/test/benchmark.exe 1 10000' ran
    1.00 ± 0.02 times faster than 'kcas-this/_build/default/test/benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       8.1 ms ±   0.1 ms    [User: 7.2 ms, System: 0.6 ms]
  Range (min … max):     8.0 ms …   8.5 ms    368 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       7.8 ms ±   0.1 ms    [User: 6.9 ms, System: 0.6 ms]
  Range (min … max):     7.7 ms …   8.2 ms    387 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 2 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      13.4 ms ±   0.1 ms    [User: 12.5 ms, System: 0.6 ms]
  Range (min … max):    13.2 ms …  13.8 ms    224 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      12.9 ms ±   0.1 ms    [User: 12.0 ms, System: 0.6 ms]
  Range (min … max):    12.7 ms …  13.3 ms    231 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 4 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 1 10000
  Time (mean ± σ):       5.2 ms ±   0.0 ms    [User: 4.3 ms, System: 0.6 ms]
  Range (min … max):     5.1 ms …   5.6 ms    573 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 1 10000
  Time (mean ± σ):       5.2 ms ±   0.0 ms    [User: 4.3 ms, System: 0.6 ms]
  Range (min … max):     5.1 ms …   5.7 ms    575 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 1 10000' ran
    1.00 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 2 10000
  Time (mean ± σ):      10.5 ms ±   0.1 ms    [User: 9.6 ms, System: 0.6 ms]
  Range (min … max):    10.4 ms …  10.9 ms    283 runs

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 2 10000
  Time (mean ± σ):      10.1 ms ±   0.1 ms    [User: 9.2 ms, System: 0.7 ms]
  Range (min … max):    10.0 ms …  10.9 ms    295 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 2 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 4 10000
  Time (mean ± σ):      18.9 ms ±   0.1 ms    [User: 17.9 ms, System: 0.7 ms]
  Range (min … max):    18.8 ms …  20.1 ms    159 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 4 10000
  Time (mean ± σ):      17.9 ms ±   0.2 ms    [User: 16.9 ms, System: 0.7 ms]
  Range (min … max):    17.7 ms …  19.1 ms    167 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 4 10000' ran
    1.06 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      21.8 ms ±   0.8 ms    [User: 32.8 ms, System: 2.0 ms]
  Range (min … max):    20.4 ms …  23.5 ms    144 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      20.2 ms ±   1.0 ms    [User: 30.4 ms, System: 1.9 ms]
  Range (min … max):    18.7 ms …  21.9 ms    142 runs

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 100000' ran
    1.08 ± 0.07 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 100000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      40.8 ms ±   1.8 ms    [User: 63.8 ms, System: 2.9 ms]
  Range (min … max):    38.6 ms …  47.0 ms    69 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      38.5 ms ±   2.0 ms    [User: 60.6 ms, System: 2.8 ms]
  Range (min … max):    35.1 ms …  42.6 ms    83 runs

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 200000' ran
    1.06 ± 0.07 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 200000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      79.7 ms ±   5.1 ms    [User: 126.2 ms, System: 4.9 ms]
  Range (min … max):    75.3 ms … 102.9 ms    36 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      75.0 ms ±   3.8 ms    [User: 120.5 ms, System: 4.6 ms]
  Range (min … max):    68.3 ms …  78.5 ms    43 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 400000' ran
    1.06 ± 0.09 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 400000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      35.2 ms ±   0.3 ms    [User: 34.2 ms, System: 0.7 ms]
  Range (min … max):    34.6 ms …  35.7 ms    86 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      35.3 ms ±   0.3 ms    [User: 34.2 ms, System: 0.7 ms]
  Range (min … max):    34.6 ms …  35.7 ms    86 runs

Summary
  'kcas-main/_build/default/test/benchmark.exe 1 200000' ran
    1.00 ± 0.01 times faster than 'kcas-this/_build/default/test/benchmark.exe 1 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     129.4 ms ±   0.4 ms    [User: 128.0 ms, System: 1.0 ms]
  Range (min … max):   128.6 ms … 130.0 ms    23 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     121.7 ms ±   0.4 ms    [User: 120.3 ms, System: 1.0 ms]
  Range (min … max):   121.1 ms … 122.4 ms    24 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 2 200000' ran
    1.06 ± 0.00 times faster than 'kcas-main/_build/default/test/benchmark.exe 2 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     235.0 ms ±   0.3 ms    [User: 233.4 ms, System: 1.2 ms]
  Range (min … max):   234.5 ms … 235.5 ms    12 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     224.6 ms ±   0.4 ms    [User: 223.0 ms, System: 1.2 ms]
  Range (min … max):   224.1 ms … 225.5 ms    13 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 4 200000' ran
    1.05 ± 0.00 times faster than 'kcas-main/_build/default/test/benchmark.exe 4 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.5 ms ±   0.1 ms    [User: 2.6 ms, System: 0.6 ms]
  Range (min … max):     3.4 ms …   4.1 ms    730 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.5 ms ±   0.0 ms    [User: 2.6 ms, System: 0.6 ms]
  Range (min … max):     3.4 ms …   4.1 ms    731 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

Summary
  'kcas-main/_build/default/test/benchmark.exe 1 10000' ran
    1.00 ± 0.02 times faster than 'kcas-this/_build/default/test/benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       8.1 ms ±   0.1 ms    [User: 7.2 ms, System: 0.6 ms]
  Range (min … max):     8.0 ms …   8.5 ms    368 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       7.8 ms ±   0.1 ms    [User: 6.9 ms, System: 0.6 ms]
  Range (min … max):     7.7 ms …   8.2 ms    387 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 2 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      13.4 ms ±   0.1 ms    [User: 12.5 ms, System: 0.6 ms]
  Range (min … max):    13.2 ms …  13.8 ms    224 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      12.9 ms ±   0.1 ms    [User: 12.0 ms, System: 0.6 ms]
  Range (min … max):    12.7 ms …  13.3 ms    231 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 4 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 1 10000
  Time (mean ± σ):       5.2 ms ±   0.0 ms    [User: 4.3 ms, System: 0.6 ms]
  Range (min … max):     5.1 ms …   5.6 ms    573 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 1 10000
  Time (mean ± σ):       5.2 ms ±   0.0 ms    [User: 4.3 ms, System: 0.6 ms]
  Range (min … max):     5.1 ms …   5.7 ms    575 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 1 10000' ran
    1.00 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 2 10000
  Time (mean ± σ):      10.5 ms ±   0.1 ms    [User: 9.6 ms, System: 0.6 ms]
  Range (min … max):    10.4 ms …  10.9 ms    283 runs

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 2 10000
  Time (mean ± σ):      10.1 ms ±   0.1 ms    [User: 9.2 ms, System: 0.7 ms]
  Range (min … max):    10.0 ms …  10.9 ms    295 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 2 10000' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/tx_benchmark.exe 4 10000
  Time (mean ± σ):      18.9 ms ±   0.1 ms    [User: 17.9 ms, System: 0.7 ms]
  Range (min … max):    18.8 ms …  20.1 ms    159 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/tx_benchmark.exe 4 10000
  Time (mean ± σ):      17.9 ms ±   0.2 ms    [User: 16.9 ms, System: 0.7 ms]
  Range (min … max):    17.7 ms …  19.1 ms    167 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_benchmark.exe 4 10000' ran
    1.06 ± 0.01 times faster than 'kcas-main/_build/default/test/tx_benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      21.8 ms ±   0.8 ms    [User: 32.8 ms, System: 2.0 ms]
  Range (min … max):    20.4 ms …  23.5 ms    144 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      20.2 ms ±   1.0 ms    [User: 30.4 ms, System: 1.9 ms]
  Range (min … max):    18.7 ms …  21.9 ms    142 runs

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 100000' ran
    1.08 ± 0.07 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 100000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      40.8 ms ±   1.8 ms    [User: 63.8 ms, System: 2.9 ms]
  Range (min … max):    38.6 ms …  47.0 ms    69 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      38.5 ms ±   2.0 ms    [User: 60.6 ms, System: 2.8 ms]
  Range (min … max):    35.1 ms …  42.6 ms    83 runs

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 200000' ran
    1.06 ± 0.07 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 200000'

Benchmark 1: kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      79.7 ms ±   5.1 ms    [User: 126.2 ms, System: 4.9 ms]
  Range (min … max):    75.3 ms … 102.9 ms    36 runs

Benchmark 2: kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      75.0 ms ±   3.8 ms    [User: 120.5 ms, System: 4.6 ms]
  Range (min … max):    68.3 ms …  78.5 ms    43 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/tx_parallel_cmp_bench.exe 400000' ran
    1.06 ± 0.09 times faster than 'kcas-main/_build/default/test/tx_parallel_cmp_bench.exe 400000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      35.2 ms ±   0.3 ms    [User: 34.2 ms, System: 0.7 ms]
  Range (min … max):    34.6 ms …  35.7 ms    86 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      35.3 ms ±   0.3 ms    [User: 34.2 ms, System: 0.7 ms]
  Range (min … max):    34.6 ms …  35.7 ms    86 runs

Summary
  'kcas-main/_build/default/test/benchmark.exe 1 200000' ran
    1.00 ± 0.01 times faster than 'kcas-this/_build/default/test/benchmark.exe 1 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     129.4 ms ±   0.4 ms    [User: 128.0 ms, System: 1.0 ms]
  Range (min … max):   128.6 ms … 130.0 ms    23 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     121.7 ms ±   0.4 ms    [User: 120.3 ms, System: 1.0 ms]
  Range (min … max):   121.1 ms … 122.4 ms    24 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 2 200000' ran
    1.06 ± 0.00 times faster than 'kcas-main/_build/default/test/benchmark.exe 2 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     235.0 ms ±   0.3 ms    [User: 233.4 ms, System: 1.2 ms]
  Range (min … max):   234.5 ms … 235.5 ms    12 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     224.6 ms ±   0.4 ms    [User: 223.0 ms, System: 1.2 ms]
  Range (min … max):   224.1 ms … 225.5 ms    13 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 4 200000' ran
    1.05 ± 0.00 times faster than 'kcas-main/_build/default/test/benchmark.exe 4 200000'

@lyrm Noticed an issue with the Xt.update and Xt.modify operations.  See comments here and here.
Thanks!  That is an excellent catch!
The problem is that the internal higher-order update assumes that the function passed does not mutate the transaction log.
I see a number of ways to address this:

Somehow make the internal update work even with functions that might modify the log as a side-effect.
Do not expose higher-order operations Xt.update and Xt.modify  to users.
Document that the function passed to Xt.update and Xt.modify must not modify the transaction log and assert that inside the (internal) implementation of update.

For practical reasons I think that option 3 is the way to go.  The reason for that is that the "ideal fix" to make the internal update work even for cases where the log is mutated is likely to be expensive — in the general case it basically requires doing two splays on the log and avoiding that is the whole point of having those in the first place.  On other hand, the higher-order functions are quite important for performance reasons (i.e. for reducing accesses to the log), so it would be unfortunate to not give those to users.  Adding an assert to check that the xt.cass remains unmodified should be relatively cheap (and should get compiled away when asserts are disabled).

If you want to provide semi-guarantees-by-convention that the higher-order argument does not mutate the transaction log, one way to do this would be the following:

Document that a local function should never capture a xt log variable. If the function uses xt in its body, it should take it as an ~xt parameter. (Scala has an experimental feature called "capability" for this sort of should-not-be-captured values, and Jane Street's local stuff would also prevent that.) (You probably already need this convention to for correctness, independently of the update/modify business, otherwise an xt value could be leaked in a unit -> unit closure.)

In the higher-order functions, pass an extra unit parameter with the convention to rebind it to xt to shadow the ambient xt variable: Xt.modify ~xt h (fun xt hv -> ...), where the inner xt has type unit (or a local type no_access or whatever to give even more suggestive error messages.)

Document that a local function should never capture a xt log variable.

But that is not really a problem.
It is entirely fine to capture the log and it is one of the main advantages of the API.  You can, for example, use higher-order collection operations like List.iter and pass them a closure that captures the log and updates it during the iteration.
The problem is with Xt.update and Xt.modify as they are optimized to only access the log once and assume that the given function does not mutate the log.  It is a limitation that could be easily "fixed":
let modify ~xt r f = set ~xt r (f (get ~xt r))

But doing so one of the main reasons for modify to exist would be lost (i.e. that it only accesses the log once).  There is nothing that you could do with such a "fixed" modify or update that you cannot already do (with get and set).  You would just lose the optimization.

Scala has an experimental feature called "capability" for this sort of should-not-be-captured values, and Jane Street's local stuff would also prevent that.

Hmm... I haven't looked at the proposal in detail, but I got the impression from talking with Stephen Dolan that locals can actually be used inside closures —  maybe the locals proposal also allows one to give higher-order arguments such types that they cannot capture locals.  At any rate, being able to use locals from closures without passing them as arguments was interesting to me as F# (and .NET in general) allows one to pass a variable by reference (i.e. byref<_> arguments), but in F# such references cannot be captured — you can only pass them as arguments.  I've used this feature of F# specifically to ensure these kinds of properties (cannot leak, avoid allocations).

You probably already need this convention to for correctness, independently of the update/modify business, otherwise an xt value could be leaked in a unit -> unit closure.

It is possible to leak the log, but after the log has been attempted there is really nothing you can do with the log.  You can record accesses to the log, if you capture it, but you cannot use the log to mutate anything aside from the log itself.  That is guaranteed by the type system.

In the higher-order functions, pass an extra unit parameter with the convention to rebind it to xt

I see the idea, but strictly speaking that doesn't guarantee anything and would make the API more cumbersome as then you'd always have to wrap the function.  So, for example, you couldn't just say modify ~xt q.back (List.cons elem).


Switch to pyproject.toml

Closes #52.

Failing CI due to #61.

Only for contributors. Contributors need to have a pip version >= 21.3 and a setuptools version >= 64.0.0. If they don't, an error message will tell them specifically to upgrade pip or setuptools when they try to install the package in editable mode. End users aren't affected. (IIRC, setuptools still packages the distribution with a setup.py, setup.cfg, and pyproject.toml when you build it with a pyproject.toml.)


Send Stream live notification to Discord webhook

Implemented in https://github.com/mjfwebb/twitch-bot/pull/207


IDVA5-1180- Improving Test coverage

Adding, correcting and removing not required tests to get more coverage

CI: No security warnings found