Possible to use RSpec core 3.3 with this gem so I can use --only-failures?

Is it possible to use the RSpec core 3.3 in my rails app so I can use the --only-failures option? That is amazing and I want it today!!

It should be. Have you tried upgrading?

I just tried this on a work project and it worked great :heart:. However, you will need to add the new configuration option for it to your spec/spec_helper.rb file:
  # Allows RSpec to persist some state between runs in order to support
  # the `--only-failures` and `--next-failure` CLI options. We recommend
  # you configure your source control system to ignore this file.
  config.example_status_persistence_file_path = "spec/examples.txt"

I have verified that running rails generate rspec:install will properly include that configuration setting; but that's usually just for new apps - or if you haven't customized the spec/spec_helper.rb file and would like to update it.
Don't forget to add /spec/examples.txt to your .gitignore file.
Glad you like the new features! :smile_cat:

@gregblass @cupakromer do you happen to know how to pass the --only-failures option in when using the rails task? i.e bundle exec rails spec?

Are the new rails tasks similar to rake tasks? Theres an rspec_opts for the Rake task which would allow you to do this.

ah, excellent thanks @JonRowe


Utility for symmetric metric

I think that it would be useful to add a utility to make the metric symmetric, as we'd want to sometimes have a symmetric mesh (when the problem is symmetric). I guess we can do this easily by copying the metric, rotating it and then taking the mean of the two?

Is it not sufficient to just apply the enforce_spd method?

Oh hang on, do you mean symmetric in space rather than within the entries at a given point?

Ah sorry for not being clear! I did mean in space, yes - so that the generated mesh would be symmetric.

And I think my suggestion would only work if the original mesh is symmetric.
Also saw this repo now https://github.com/MmgTools/MirrorMesh

Hey @jwallwork23, could you please tell me what you think about the workflow below? I modified the simple_metric.py animate demo to get this. In particular, I was wondering if there is a way to make a deepcopy of a mesh rather than redefining it (labelled below with TODO)?
from firedrake import *
from firedrake.pyplot import *
import matplotlib.pyplot as plt
from animate import *

mesh = UnitSquareMesh(40, 40)
P1_ten = TensorFunctionSpace(mesh, "CG", 1)
metric = RiemannianMetric(P1_ten)

x, y = SpatialCoordinate(mesh)
r = 0.4
h1 = 0.02
h2 = 0.05
high = as_matrix([[1 / h1**2, 0], [0, 1 / h1**2]])
low = as_matrix([[1 / h2**2, 0], [0, 1 / h2**2]])
metric.interpolate(conditional(sqrt((x - 0.3) ** 2 + (y - 0.3) ** 2) < r, high, low))
density, *_ = metric.density_and_quotients()

# TEMPORARY METRIC ON A ROTATED DOMAIN
mesh_rotated = UnitSquareMesh(40, 40)  # TODO: Can we make a deepcopy of mesh?
P1_ten_rotated = TensorFunctionSpace(mesh_rotated, "CG", 1)
metric_rotated_temp = RiemannianMetric(P1_ten_rotated)
metric_rotated_temp.interpolate(metric)
mesh_rotated.coordinates.dat.data[:] = 1 - mesh_rotated.coordinates.dat.data

# INTERPOLATE TEMPORARY ROTATED METRIC ON THE ORIGINAL MESH
metric_rotated = RiemannianMetric(P1_ten)
metric_rotated.interpolate(metric_rotated_temp)
density_rotated, *_ = metric_rotated.density_and_quotients()

# COMPUTE SYMMETRIC METRIC ON THE ORIGINAL MESH
metric_symmetric = RiemannianMetric(P1_ten)
metric_symmetric.assign(0.5 * (metric + metric_rotated))
density_symmetric,*_ = metric_symmetric.density_and_quotients()

amesh = adapt(mesh, metric)
amesh_rotated = adapt(mesh, metric_rotated)
amesh_symmetric = adapt(mesh, metric_symmetric)

fig, axes = plt.subplots(2, 3, figsize=(10, 6.5), sharex=True, sharey=True)
axes[0, 0].set_title("Metric density")
tripcolor(density, axes=axes[0, 0])
axes[0, 1].set_title("Rotated m. density")
tripcolor(density_rotated, axes=axes[0, 1])
axes[0, 2].set_title("(Density + Rotated density)/2")
tripcolor(density_symmetric, axes=axes[0, 2])

triplot(amesh, axes=axes[1, 0])
triplot(amesh_rotated, axes=axes[1, 1])
triplot(amesh_symmetric, axes=axes[1, 2])
for ax in axes.flatten():
    ax.set_xlim(0, 1)
    ax.set_ylim(0, 1)
    ax.set_aspect("equal")
plt.show()

Would it not be sufficient to just interpolate the rotated metric rather than rotating the mesh and interpolating between meshes?
To copy a mesh I normally do Mesh(old_mesh.coordinates.copy(deepcopy=True)).

Would it not be sufficient to just interpolate the rotated metric rather than rotating the mesh and interpolating between meshes?

That won't work if old_mesh isn't symmetric to begin with, since rotated vertices wouldn't match up with existing vertices. So in that case we need to interpolate between meshes. Or am I misunderstanding? If so, could you code/pseudocode what you mean please? :)

To copy a mesh I normally do Mesh(old_mesh.coordinates.copy(deepcopy=True)).

Thanks, but that doesn't seem to create a deepcopy unfortunately (the above example doesn't work). I'll dig more :)

And just a sidenote... having a symmetric metric doesn't guarantee at all that the mesh will be symmetric. But it should be close enough.

That won't work if old_mesh isn't symmetric to begin with, since rotated vertices wouldn't match up with existing (not rotated) vertices. So in that case we need to interpolate between meshes. Or am I misunderstanding? If so, could you code/pseudocode what you mean please? :)

But even with rotating the mesh you still interpolate back into P1 space on the old mesh, so it isn't going to be fully symmetric. I can see that a similar approach would work if you took a supermesh of the old mesh and rotated mesh.

Please could you clarify in what sense you want the metric to be symmetric? I was under the impression you wanted it to be symmetric (e.g.) in the $x$-axis, i.e., invariant to reflection top <-> bottom. But the discussion above refers to rotation, which is a different kind of transformation.


Bump Glance with the new storage interface

We currently provide both StorageClass and StorageRequest that can be propagated to the Glance underlying instances.
However, it might be possible that operators use extraMounts to plug a NFS share mapped to  /var/lib/glance/os_glance_staging_store.
In this case the API should be updated to not provision any PVC and let the human operator take care about it via the extraMounts interface.
This patch updates the Glance bits to reflect the new behavior introduced in the glance-operator.
Jira: https://issues.redhat.com/browse/OSPRH-6719

/test precommit-check

@fao89 do you know what's going on w/ make docs ? I tried it locally and it doesn't change anything compared to what I already pushed here, but I'm wondering if I'm missing something.

@fmount I don't know what is happening, but I checkout this PR, ran make docs and it did change. My best guess is something with the binaries, I would try deleting what you have on openstack-operator/bin and run make docs again to see if it changes the docs for you

@fmount I don't know what is happening, but I checkout this PR, ran make docs and it did change. My best guess is something with the binaries, I would try deleting what you have on openstack-operator/bin and run make docs again to see if it changes the docs for you

@fmount I don't know what is happening, but I checkout this PR, ran make docs and it did change. My best guess is something with the binaries, I would try deleting what you have on openstack-operator/bin and run make docs again to see if it changes the docs for you

I think it's bundle that makes the difference, and it's not in openstack-operator/bin. I'll look into that but so far I'm not able to reproduce (locally) that issue.

it makes sense, try to replace manifests with bundle on the docs dependencies: https://github.com/openstack-k8s-operators/openstack-operator/blob/main/Makefile#L94

it makes sense, try to replace manifests with bundle on the docs dependencies: https://github.com/openstack-k8s-operators/openstack-operator/blob/main/Makefile#L94
So there are weird things happening with ruby and bundle: do we enforce a specific version?

ok the combination of fedora40 with ruby-v3.3 did the trick, but if I slightly change version(s) (even for the asciidoctor) gem I generate a diff output.
@fao89 now pre-commit check passes, thanks for the help!

/test openstack-operator-build-deploy-kuttl

/test openstack-operator-build-deploy-kuttl

@abays @stuggi @konan-abhi we have green CI here and I'm wondering if we can land this

/test openstack-operator-build-deploy-kuttl

mm rechecking kuttl as it seems failing on FIPS check :/

/test openstack-operator-build-deploy-kuttl

/test openstack-operator-build-deploy-kuttl


Remove direct reference to absl::Status in Activity

First step along the path to having Activity return TrailingMetadata

@yashykt

/easycla


[Feature request] A Sym tab to show the outputted symbols

This would be useful to see which symbols are getting exported (optionally with `-E1), or see what addresses some symbols end up at (particularly when a macro is creating them).

what is -E1 option?
also how symbols should be formated? it's easy to show map file like this:

BTW you can also see the symbol in "memory" view in current build

Yeah, a "Map" file tab would suffice for this issue.

I will do pr as soon as you would change secret labeling(because I'm removing them in this view). I did add some comments how to fix labeling.


Implementing XNOR-Net in MXNET

Hi,
I am implemented XNOR-Net (http://arxiv.org/abs/1603.05279) by creating a new operator that does the weight modification and convolution modification as suggested in the paper at Equation 5 and Equation 1.  Authors claim 32x reduction in memory and this should also significantly speed up the convolution, however I don't see any evidence of claims of memory/power/speed improvements with the implementation.   I ran the CIFAR dataset through both models and they produce the exact model size, memory usage and time of execution in both GPU and CPU.  The only difference is in the accuracy of the predication, the XNOR-Net produces lesser accuracy as expected.
My question is am I missing something in terms of benefits of memory/speed/model size when using XNOR-Net?, should I do try some other processing to take advantage of Binary values of weight matrix? or should I implement my own Convolution operation that operates on Binary values of weight matrix instead standard unpack/dot multiplication ?
Below are the changes I made to the Convolution Operator for implementing XNOR-Net
//Before Convolution is called, get average abs weight value per filter (Equation 5)
    Stream<cpu> *cpu_stream_ = NewStream<cpu>();
    Tensor<xpu,1> alpha_mat = NewTensor<xpu,real_t>(Shape1(wmat_shape[1]),0.0f,false,s);
    Tensor<cpu,1> alpha_cpu = NewTensor<cpu,real_t>(alpha_mat.shape_,0.0f,false,cpu_stream_);
    TensorContainer<xpu,3,real_t> wmat_b(wmat_shape);
    wmat_b.set_stream(s);
    alpha_mat += sumall_except_dim<1>(F<mshadow_op::abs>(wmat));
    alpha_mat /=wmat_shape.Size();

    //Copy to cpu in order to use value as index
    Copy(alpha_cpu,alpha_mat,s);
    wmat = F<mshadow_op::sign>(wmat);

//After Convolution is called, Equation 1
      TensorContainer<xpu,4,real_t> tmp_conv(mshadow::Shape4(param_.num_filter,
                                                  step,
                                                  out.size(2),
                                                  out.size(3)));
     tmp_conv.set_stream(s);
     tmp_conv = reshape(temp_dst,mshadow::Shape4(param_.num_filter,
                                                  step,
                                                  out.size(2),
                                                  out.size(3)));
           for(index_t filter_num =0 ; filter_num< alpha_cpu.size(0);++filter_num) {
                 real_t alpha = alpha_cpu[filter_num];
                tmp_conv[filter_num] = tmp_conv[filter_num]*alpha;
          wmat[filter_num] = wmat[filter_num]*alpha;
        }

Any insights or suggestions?

To get speedup for binary input, I do think we need to have a customized convolution that simply do bit counts, as opposed to using the traditional floating points

Thanks, I also assumed that I need to change the standard convolution to bit operations, how about storage of the model, do I need to implement some scheme to store compressed bit representation of Weight parameters in order to reduce the size of the model?

Related discussion in tensorflow https://github.com/tensorflow/tensorflow/issues/1592.

Hi,
Do you have implemented XNOR-Net (http://arxiv.org/abs/1603.05279)? And what problems about it now?


feat: add metadata options for AWS 4.x provider

Description
Updates the docker-machine to newest version to be able to add options for amazonec2-metadata-token and amazonec2-metadata-token-response-hop-limit. Both options are set by default.
Typical error message is
| Error: error configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.
│
│ Please see https://registry.terraform.io/providers/hashicorp/aws
│ for more information about providing credentials.
│
│ Error: no EC2 IMDS role found, operation error ec2imds: GetMetadata, canceled, context deadline exceeded

Refer to https://github.com/hashicorp/terraform-provider-aws/issues/23110 for a discussion about the changes introduced with the AWS 4.x provider.
Migrations required
Make sure that you do not specify the docker_machine_download_url and that you also not specify the above mentioned options in the docker_machine_options. If you do so, remove them.
If you have to use a special download url, make sure that the new options are supported by that version.
Verification
Installed the new module in our CI/CD system for manual checks. Looks good so far.
Also checked the config.toml for no docker_machine_options. Looks good too.
Documentation
We use pre-commit to update the Terraform inputs and outputs in the documentation via terraform-docs. Ensure you have installed those components.

@kayman-mk great work, we also have another PR open #444 Would prefer to merge the 4.x work together and relase. In the mean time I will check the veriosn.tf and lock the provider to 3* (before merging). Will check the PR this weekend

rebased

@kayman-mk Looks like this was added the latest gitlab release of docker machine (10 months ago). Can you run another rebase.
In the PR title you refer to AWS provider 4.0. What is the relation? As far i can't see there is norelation.

Updated one of my runners to 4.41.1 Working without any problems. Seems that this fix might be superfluous.

ok

@kayman-mk first of all, sorry for keep you waiting so long. Had some travels and got finally ill :(
Just tested the PR. Hoever the change looks goot and options seems to be supported no docker-machine is crated. I used the default example to test. With latest gitlab runner and docker machine version (gitlab one).
I have tested the PR on top of #460 which enables the terraform 4 provider. Without the PR the Terraform 4 provider works fine for mee. Build runners are crated as normal.
Any idea what could be wrong? Do you have time to check the change on top of the PR with the default example.

@kayman-mk seems I missed this PR in #460 please can you have a quick lock the conflicts?

@kayman-mk testing a solution based on the PR right now, looks good so far.  Keep you updated

Created a PR on top of #460  to add metadata options for docker machine, based on this PR
see https://github.com/npalm/terraform-aws-gitlab-runner/pull/490

Thanks a lot for you help, all work is nog back on develop. You are refered in the the commits as co-author!


Fix sampleindex for SparseDoubleSeq

This fixes a bug with SparseDoubleSeq.sampleIndex. Since only active elements are iterated, the last index needs to be carried with the sweep. Note that SparseDoubleSeq is tested via the cc.factorie.la.SparseTensor1 implementation.

@dozed Looks good to me, thanks for fixing this.


[opentitantool] Introduce JSON config for teacup shield

The HyperDebug "shield" has a number of MUX'es, buffers and other ICs (current sensors), which can be controlled through some signals in addition to what is used when e.g. simulating OpenTitan on an FPGA.
This PR introduces a new hyperdebug_teacup.json file, to be used with --interface=hyperdebug (not hyper310).  Both this file and existing FPGA-specific files refer to a common opentitan.json.

To be consistent with the existing names hyper310 and hyper340 we could call the new target hyperteacup.

My stance is that there is conceptual difference between "interface", which is kind of the debugger hardware, and then the configuration for the combined setup of debugger and device under test.
Until now, it has been a bit conflated, since the "debugger hardware" included both HyperDebug and Sam3X on either CW310 or CW340, which also fully described the device under test.
The "pure" hyperdebug debugger hardware, however, can be connected to a variety of devices to be tested.  The Teacup board is the first OpenTitan test board to use the pure "hyperdebug" debugger.  I foresee that the OpenTitan project in the future will have other test boards, which may feature newer revisions of the OT chip, but could also feature additional current sensors, mux'es, LEDs, connectors and other things, that require slight variations in the JSON configuration file.
The Google hardware security team already uses two other teacup-like boards on top of a pure HyperDebug, one for each of two previous generations of legacy Titan chips.  We have a configuration file for each of them, but use the generic interface "hyperdebug".
In short, there will be a one-to-many relationship between interfaces and configuration files, and this Teacup-specific file should not be called "hyperdebug.json", neither do I think that we should have an interface called "hyperteacup", which would use the same exact driver as "hyperdebug", the only difference being that the default configuration file is this new hyperdebug_teacup.json.  I would rather work towards build scripts that explicitly pass a --conf argument to opentitantool, instead of passing --interface, since as I describe above, there is a many-to-one relationship betwen the two, and we might as well pass a pointer to the "many" side, rather than artificially adding more entries to the "one"-side in order to try to keep up and make it one-to-one.

To be consistent with the existing names hyper310 and hyper340 we could call the new target hyperteacup.

My stance is that there is conceptual difference between "interface", which is kind of the debugger hardware, and then the configuration for the combined setup of debugger and device under test.
Until now, it has been a bit conflated, since the "debugger hardware" included both HyperDebug and Sam3X on either CW310 or CW340, which also fully described the device under test.
The "pure" hyperdebug debugger hardware, however, can be connected to a variety of devices to be tested. The Teacup board is the first OpenTitan test board to use the pure "hyperdebug" debugger. I foresee that the OpenTitan project in the future will have other test boards, which may feature newer revisions of the OT chip, but could also feature additional current sensors, mux'es, LEDs, connectors and other things, that require slight variations in the JSON configuration file.
The Google hardware security team already uses two other teacup-like boards on top of a pure HyperDebug, one for each of two previous generations of legacy Titan chips. We have a configuration file for each of them, but use the generic interface "hyperdebug".
In short, there will be a one-to-many relationship between interfaces and configuration files, and this Teacup-specific file should not be called "hyperdebug.json", neither do I think that we should have an interface called "hyperteacup", which would use the same exact driver as "hyperdebug", the only difference being that the default configuration file is this new hyperdebug_teacup.json. I would rather work towards build scripts that explicitly pass a --conf argument to opentitantool, instead of passing --interface, since as I describe above, there is a many-to-one relationship betwen the two, and we might as well pass a pointer to the "many" side, rather than artificially adding more entries to the "one"-side in order to try to keep up and make it one-to-one.

Thanks for explaining that.
So from my understanding, we call hyper310 and hyper340 these names due to the use of separated transport to load bitstreams, which is not the case with hyperdebug + any shield. Therefore, the --interface maps to the transport rather than the board configuration.

I agree that calling the interface hyperdebug make sense. There are already a number of assumptions baked into opentitantool that will have to be lifted in the future anyway: the tool always assume earlgrey for example so we might need a CLI option to specify the soc. It might make sense to have a board option in the future to specify how the interface is connected to the soc (that would be teacup here).

So from my understanding, we call hyper310 and hyper340 these names due to the use of separated transport to load bitstreams, which is not the case with hyperdebug + any shield. Therefore, the --interface maps to the transport rather than the board configuration.

Yes exactly. It is a bit of shame that for some reason both terms "interface" and "transport" are used in the source, meaning the same thing.  If done again, we should probably have called it --transport, to make it clear, and dropped the term "interface".

I agree that calling the interface hyperdebug make sense. There are already a number of assumptions baked into opentitantool that will have to be lifted in the future anyway: the tool always assume earlgrey for example so we might need a CLI option to specify the soc. It might make sense to have a board option in the future to specify how the interface is connected to the soc (that would be teacup here).

The new file in this PR has a line "interface": "hyperdebug", meaning that you can specify --conf hyperdebug_teacup.json and omit --interface=hyperdebug".  I think it would make sense to later on add "soc": "earlgrey"to this file, so that all of transport, soc, as well as the details of their interconnection would be specified through a single--confargument.  We would still have--interfaceand a new--socif someone wanted to manually specify everything on the command line, but I would like to move towards the default being specifying a--confargument, and not specifying--interface.  This will require some changes to BUILD files, but it should be rather mechanical for now, since hyper310andhyper340` are one-to-one.


Rough STOMP Adapter

Purpose: Adds STOMP adapter + interfaces + documentation for use with Sync.
Changes:

[X] Exercise more built-in bundler functionality in .travis.yml and force install.
[X] Added / Updated ruby versions in .travis.yml
[X] Add rabbitmq service and configuration in .travis.yml (for STOMP)
[X] Add api_key, auth_token, websocket, destination, and debug to configuration.
[X] Allow debug to fall back as true for !production? when omitted from sync.yml.
[X] Allow Sync.onReady(..) to accept an array of callbacks.
[X] Ensure Sync.readyQueue callbacks do not fire until adapter is available and connected.

[X] Start Sync inside self-closing interval (in case adapter dependency loading is deferred).
[X] Defer Sync.onReady callbacks until adapter is connected (see onConnectInterval).

[X] Use api_key and auth_token for login and passcode for STOMP client authentication.
[X] Removed redundant subscribe(..) under Pusher adapter class.
[X] Rename PUSHER_API_KEY to simply API_KEY.
[X] Added Stomp adapter + subscription classes to sync.coffee.erb.
[X] Added Stomp client adapter in ruby.
[X] Added template specification for STOMP adapter to sync.yml.
[X] Added message test, test helper, and fixture for STOMP.
[x] Updated README.md with basic instructions for using the STOMP adapter with RabbitMQ.
[X] Force bundler gem update in .travis.yml.

Fix for issue bundler/bundler#3558.

@chrismccord Thoughts?

It would be nice if this could be done as an external adapter. Any thoughts on going that approach?

It shouldn't be too hard to extract it to it's own gem. I was actually going to suggest that we extract Faye, Pusher, and this adapter out to their own plugin projects after this iteration was complete.
I think, though, that we need to solidify and maybe refactor a couple of the interface patterns used throughout the gem before we go down that route. Here are some thoughts:

Sync::Clients: We should define a base interface that other client adapters inherit from, which throws NotImplementedError's when necessary to emphasize expected delegation to the child class. Doing so would establish a very clear set of expectations and directions for the development of other adapters. It would probably yield more reusable patterns for testing examples, too.

Sync.Adapter: The idea is generally the same as above, but as this structure is much more evolved than on the ruby side, I think maybe only a little bit of cleaning would be necessary here. Probably just a more strict set of expectations or documentation regarding callbacks and boot structure, and it'd be done.

Extract inline-rendered javascript snippets from the ruby files into templates.

The general file organization under lib/sync could do with some cleaning, and could probably make good use of ActiveSupport::Concern versus vanilla module composition. Quick sketch:

- lib/sync
  |- clients/
     |- concerns/
        |- faye_extension.rb
     |- base.rb
     |- dummy.rb
     |- faye.rb
     |- pusher.rb
     |- stomp.rb
  |- helpers/
     |- concerns/
     |- controller_helpers.rb
     |- model_actions.rb
     |- etc
  |- interactors/
     |- partial_creator.rb
     |- refetch_partial_creator.rb
     |- refetch_partial.rb
     |- renderer.rb
  |- trackers/
     |- base.rb
     |- erb.rb

This is very rough, and I won't speak to how accurate it is, but I think that it should be ironed out before trying to enable a conventions-based plugin architecture. Just a little bit of reorganization could go a long way.

I think that minitest is becoming a bit burdensome as a test framework for this project. I'm usually quite impartial with regards to choices here, but rspec-rails would really make the suite more flexible and reusable. Something like rubocop would help clean up the existing codebase style and enable people to more readily contribute. I would also recommend using FactoryGirl to DRY things up and reduce/remove reliance on fixtures.

Those are my most immediate general thoughts. I wouldn't mind working through some of these thoughts in a follow-up pull request or two, but I think it would be a bit much for me to take on by myself. I would like to see this PR get merged first so that it's integrations aren't lost in the mean time. After that, I'd love to collaborate on this, as I'm actively using this gem and kicking off it's usage in another project with this STOMP adapter.
Sorry to dump so many thoughts on you, but drop your two cents in when you have a chance.
It's definitely worth the time, so let me know. Cheers.

@chrismccord is there anything I can do in the short-term to help get this merged?

I understand there are some merge conflicts due to recent changes, but I'm still looking for general feedback on how to get this PR merged. @chrismccord or @ajb, general feedback and advice for resolving merge conflicts, please?
Thanks, cheers.

Heya @aeberlin,
Sorry for the delay. I'm onboard with a lot of your ideas in the long comment above. In fact, I'd like to try and outline a rough plan for the next major version of sync, (which, by the way, will need to be renamed [#215]), but I haven't found the time to do so yet.
Anyway, I don't want to let that get in the way of this PR. This PR looks solid, and if you can resolve the merge conflicts, I can commit to taking the time to review & merge.

Great, thanks @ajb. Will start working through the conflicts.

@ajb Think I've resolved all the conflicts cleanly. Please review when you have a chance.
After looking over recent changes, I've noticed some similarities in the config keys for pusher and stomp, namely the websocket references. Do you have any thoughts on trying to generalize the pusher_-specific keys for more familiarity and flexibility across adapters? Not sure if we want to tackle that in this PR, but still curious.
Will check back after travis builds complete in case I missed something. Cheers.

@ajb Please restart this job when you get a chance, issue doesn't look related to the changes.
https://travis-ci.org/chrismccord/sync/jobs/108574596

This looks great; just added a few inline comments above.
Can you comment on some of the changes around the initialization, onReadyInterval, onConnectInterval, etc? Were they necessary for STOMP, or just refactoring?

@ajb,
With regards to the coffee initialization process, I think I can simplify it by requiring that sync dependencies be loaded explicitly, without auto-loading themselves. If we can require a minor breaking change which enables sync to initialize itself explicitly, instead of on require, initializing itself and binding to window, etc., it will allow me to omit those changes. Thoughts?

Overall reasoning was because of a race condition with dependencies I experienced locally. Not a huge deal, but it made me look at things a bit differently.

@ajb I still need to root out some issues with the debug_flag and stompjs, but do you see anything lingering still that needs to be addressed?

Looks good! The only big thing remaining is the initialization process & intervals... you say there was a race condition that you were experiencing locally? Maybe I can look into that for you?
I would also be fine with this, if you think it will be an improvement:

With regards to the coffee initialization process, I think I can simplify it by requiring that sync dependencies be loaded explicitly, without auto-loading themselves. If we can require a minor breaking change which enables sync to initialize itself explicitly, instead of on require, initializing itself and binding to window, etc., it will allow me to omit those changes. Thoughts?

Since we'll be releasing 1.0.0 (under a different name, too), now would be the time to make breaking changes.

@ajb,
The race condition was due to order of dependencies in sprockets. I took a stab last night at removing the auto-initialization and found that it was more complicated to include via sprockets than I had thought before. Having said that, I think that using the intervals is the best way to go, as it allows the Sync coffeescript to initialize (and later connect) itself fully as soon as things are ready and available.
Thoughts?

I see a couple of potential issues with the current implementation of setInterval:

setInterval(fn, 250) waits 250ms before calling fn, instead of calling it immediately. We want everything loaded as soon as possible.
The onReadyInterval variable in view_helpers.rb is leaking into the global scope. We should wrap everything in an anonymous function, and use the var keyword.


Be able to select privacy for email if available for hire

Right now, if you check the "available for hire" profile option, mailto:xxxx is always visible.
It would be good to have a combobox to select the privacy level of your email:

Everyone
Authenticated users (if you're logged in you see the user's email, else not)
Nobody

/ cc @xavijam @saleiva

I set the wrong task id at commit comment :_)


feat(nrf/spim): allow specifying drive of SPI pins

Makes nrf SPIM pin drives configurable, similar to the TWIM peripheral.
Apparently, high drive messes up interfacing with 3-wire SPI.

I originally had OutputDrive but I changed it to bool. AFAIK, both levels have to be driven for SPI, and I'm not sure if there's a case where you would want standard drive for 0 and high for 1 (or vice versa).

TWI only has a bool because in TWI (I2C) has to be open-drain, you never want to drive a line high. For SPI you can do anything, I imagine one might want a weird "open-drain SPI" in niche applications, perhaps when bitbanging another protocol. I would make the config setting the full OutputDrive.
Also, please make the default high drive to match the previous behavior.


No connection created when using plaintext port 5672

Attempting to leverage the library and connect to a internal testing instance of RabbitMQ and noticed via TCPDump that the client was not making the connection. It appears in the connection factory the port is being overridden to use the SSL port, even if SSL is not being specified:
https://github.com/RamblingCookieMonster/PSRabbitMq/blob/master/PSRabbitMq/New-RabbitMqConnectionFactory.ps1#L71-L72
$TcpPortProp = [RabbitMQ.Client.ConnectionFactory].GetField("Port")
$TcpPortProp.SetValue($Factory, 5671)

Perhaps it should be something like:
$TcpPortProp = [RabbitMQ.Client.ConnectionFactory].GetField("Port")
if( $Ssl ) {
  $TcpPortProp.SetValue($Factory, 5671)
} else {
  $TcpPortProp.SetValue($Factory, 5672)
}

I'll try to get something working and submit a PR but I'm not familiar with the .Net client DLL thats being leveraged here. I'm also unsure how to handle this bigger picture, ie: -Port flag for user overriding?

@gpduck @gaelcolas any thoughts on this?
From my perspective, yeah, I think it would make sense to offer some more intelligent defaults (the SSL bit you added), with a parameter for overriding the port (e.g. if $Port... elseif $ssl... else... to set that port value, among other options)
Cheers!

Agreed, adding a -Port parameter, non-mandatory, defaulting to 5672 makes sense to override the port number IMO.
Then adding logic such as:
if ($Psboundparameters.containskey('ssl')) {
   $Port = 5671
}

That said, it's a breaking change.

Sooo... How should we handle the versioning?  I'm all for semantic versioning, but we're not really practicing it now, and IMHO anyone pulling from the gallery with an expectation of compatibility can and must gate to specific versions.  On the other hand, wouldn't mind finally bumping this to version 1.x.x.
Any preference on this?

Agreed on SemVer, it's a shame that the gallery does not yet support pre-releases...
I'm happy for a breaking change with major version change. Bumping to 1 makes sense (I use this on production systems already anyway).
One of my goals for 2017 (but I have too many already), is to update to the RabbitMQ .Net lib version 4.x (targeting .Net core) and make PSRabbitMQ working on linux/nano... maybe this will be v2.x

Actually, the break was made in #8 when the port got 'hard-coded' for SSL (5671).
IMO That need to be fixed so that the port default to 5672 as it was before (when not specified), and setting SSL to something else than 'NONE' should override that to 5671 unless explicitly specified.
Will try to submit a PR to fix today.

Fixed by #17


67 find the urbanrural classification data by output area for scotland

This produces new estimates for transport accessibility disaggregated by urban/rural population.
The new data source is contained within data/urban_rural/scotland/
and can be downloaded here.
I have uploaded these to the sync website.
I will wait for #287 to be closed before merging. There are likely to be conflicts, so I will solve them after that is merged then request a review from @paigeh1 afterwards.
Closes #249

I have solved the conflicts & working. Ready for review whenever you have capacity. @paigeh1


DB replication and openshift config

PR for changes in the documentation according to changes in this pull request - https://github.com/thingsboard/thingsboard.github.io/pull/375


feat: strip the leading v by default if one exists

This pr changes the behavior slightly when dealing with leading vs.
Previously they were handled verbatim. If you had a git tag with
v1.2.3, then your version would be v1.2.3. Now by default this
strips the leaving v so that if you tag v1.2.3 your version will be
1.2.3.
If the user uses the tagModifier then this behavior no longer happens
and they user is in full control of the format still.
ref: #51

Thank you for this useful contribution!

Thanks for this useful plugin!


feat: add guidance on path normalization (#571)

Please check if the PR https://github.com/zalando/restful-api-guidelines/pull/600 introduces changes which are relevant to the Zally project.

add check forbidding // in the path.


TestDeclarationOverview: slightly deobfuscate by adding comments

@samuelhwilliams mentioned the paratrization was a little hard to decode. Hence added comments. Better, @samuelhwilliams ?

Works for me :+1:

https://www.python.org/dev/peps/pep-0008/#inline-comments

Use inline comments sparingly.

The comments don't make this any more readable.
The statement itself does too much.
It reminds me of when people used to challenge each other to do an entire task in one line on codewars.com. It was always eventually possible, but rarely, if ever advisable.

But this is how functional declarative programming is done and though it creates a few challenges over formatting & commenting etc., it means that every section in a set of brackets can be analyzed and understood totally separately from neighbouring scopes because it's all side-effect free.

I don't particularly see how using OO here would really benefit - it doesn't help that pytest seems to encourage use of classes are more or less organizational containers, not much more. FP and OO aren't mutually exclusive - they actually work really well together. I don't intend to pull away from OO using FP. And while performance isn't as wonderful as it could be, there are many cases where FP approaches being able to make use of lazy evaluation of iterables/generators will cause significant performance advantages (lazy evaluation doesn't work so well for key-value structures in python, I tend to use it less in these cases anyway).
It didn't really take much time to write - the time in writing these tests came from deciding what to test, what to assert and what not to assert. Although there's an initial investment in decoding the setup of the test, I think it is far more straightforward to understand a combined test than tests written in a more copy-pasta style that achieve the same amount of coverage (there would be a lot of copy-pasta). It also encourages someone coming to alter something to the view to consider the behaviour in all cases and understand the view as a whole, as opposed to just cherry-picking cases where they think their change is relevant and disregard other cases.
I've moved towards writing tests like this because I found my previous ways of doing it inadequate and actually ended up having a higher cognitive load because I had a harder time convincing myself that I'd written a test for all the "important" cases. This way, it's clear what gets tested and what doesn't - the actual test code is pretty compact and the machinery above is just there to feed it with the right combinations.
Finally, when I use this approach I regularly find significant numbers of bugs that would otherwise have made it through to released code, and I don't feel it's adequate to not write this style of tests for my code.


Custom templates or addition of a new section in template

Currently the templates are hardcoded and located in the templates directory of the plugin. In my use case I find myself constantly adding new section. I use daily notes not only as a planner (bullet journal), but also a daily scratchpad. I put code snippets and one off functions I wrote that day into the ## Scratchpad. This section serves me as a quick capture area. Latter on I have a bi-weekly session where I am moving some snippets into their own location in the knowledge base managed by Foam.
The ask for this ticket is to either:

add ability to specify location of templates directory (global and per workspace)
add ##Notes section into https://github.com/MCluck90/kaleidofoam/blob/main/src/templates/daily.md (it doesn't matter to much for me if I have to put entries into Notes instead of Scatchpad)

What do you think of having a config option for additional sections? It would just be a list of strings and each one translates to a new level 2 heading.

Sound good for first iteration.

thank you

Just wanted to confirm that my testing shows that the feature works as expected.


improves zoocache performance

ZooCache currently has zero contention among threads for reads of cached data.  It did this w/ snapshots of data.  However it has two problems for updates. First there is global lock for writes.  Second writes are expensive because the snapshots for reads must be recomputed, which can lead to O(N^2) behavior for a large series of rapid small updates.
This change removes the global update lock and the snapshots and replaces them with a ConcurrentHashMap.  It also replaces the three maps that existed with a single ConcurrentHashMap that has a complex value that represented the data in the three maps.  This single complex values allows removal of the global lock which existed to keep the three maps in sync for a given path.  Now for any path all of its data is stored in a single value in the map and can be safely updated with the compute function on ConcurrentHashMap which only allows one thread to update a path at a time.
This change should maintain similar read behavior performance as the snapshots because ConcurrentHashMap does not block reads for writes, if there is a concurrent compute operation happening when a read happens then it will return the previously computed value w/o blocking.  This is the same behavior that ZooCache used to have.  So hopefully this change has similar read performance as before and much better update performance.  Updates to different paths should be able to proceed in parallel and the snapshots no longer need to be computed on update.

Noticed that zoocache may not be properly caching the absence of a node for the case of getChildren, but did not want to change that in this PR.  Will open a follow on issue.  For this changes wanted to maintain the exact same behavior and only change the concurrency model.
Will open an issue about back-porting the changes to 2.1.0 or 3.1.0 if they do not cause problems in 4.0.0 testing.

Wrote the following test to experiment with these changes from a performance perspective.
package org.apache.accumulo.test.zookeeper;

import static java.nio.charset.StandardCharsets.UTF_8;
import static org.apache.accumulo.harness.AccumuloITBase.ZOOKEEPER_TESTING_SERVER;

import java.io.File;
import java.util.List;
import java.util.UUID;

import org.apache.accumulo.core.Constants;
import org.apache.accumulo.core.fate.zookeeper.ZooCache;
import org.apache.accumulo.core.fate.zookeeper.ZooReaderWriter;
import org.apache.accumulo.core.fate.zookeeper.ZooUtil;
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

@Tag(ZOOKEEPER_TESTING_SERVER)
public class ZooCacheIT {
  private static ZooKeeperTestingServer szk = null;
  private static ZooReaderWriter zk = null;
  private static final String ZK_ROOT = "/accumulo/" + UUID.randomUUID();

  @TempDir
  private static File tempDir;

  @BeforeAll
  public static void setup() throws Exception {
    szk = new ZooKeeperTestingServer(tempDir);
    zk = szk.getZooReaderWriter();
    zk.mkdirs(ZK_ROOT + Constants.ZTABLES);
  }

  @AfterAll
  public static void teardown() throws Exception {
    szk.close();
  }

  @Test
  public void testLotsOfNodes() throws Exception {
    for (int i = 0; i < 30_000; i++) {
      zk.putPersistentData(ZK_ROOT + Constants.ZTABLES + "/" + i, "i".getBytes(UTF_8),
          ZooUtil.NodeExistsPolicy.FAIL);
    }

    var zc = new ZooCache(zk, null);

    List<String> children = zc.getChildren(ZK_ROOT + Constants.ZTABLES);
    Assertions.assertEquals(30_000, children.size());

    for (int i = 0; i < 20; i++) {
      long t1 = System.currentTimeMillis();
      for (var child : children) {
        zc.get(ZK_ROOT + Constants.ZTABLES + "/" + child);
      }
      long t2 = System.currentTimeMillis();
      System.out.println(i + " : " + (t2 - t1) + "ms");
    }

  }
}

When running against these changes saw the following.  Assuming the first read from ZK its taking 22s to do 30K RPC to ZK.
0 : 21593ms
1 : 14ms
2 : 13ms
3 : 14ms
4 : 15ms
5 : 6ms
6 : 6ms
7 : 7ms
8 : 13ms
9 : 14ms
10 : 6ms
11 : 9ms
12 : 6ms
13 : 6ms
14 : 6ms
15 : 5ms
16 : 5ms
17 : 6ms
18 : 6ms
19 : 6ms

When running these test against the code that existed before these changes saw the following where it takes 57s to read the 30K entries the first time.  So the extra CPU overhead is causing it to take 2.6 times longer.
0 : 56883ms
1 : 11ms
2 : 11ms
3 : 11ms
4 : 11ms
5 : 9ms
6 : 9ms
7 : 8ms
8 : 6ms
9 : 5ms
10 : 6ms
11 : 5ms
12 : 9ms
13 : 6ms
14 : 5ms
15 : 5ms
16 : 5ms
17 : 5ms
18 : 5ms
19 : 6ms


Switch on typeof for keyof type loses information

TypeScript Version:  master 83fe1ead04545d9dce8d4a45e6619134d00a5248

Search Terms: switch typeof keyof intersection
Code
function keyofNarrowing<S extends { [K in keyof S]: string }>(k: keyof S) {
    switch (typeof k) {
        case 'number': k; return; // k has type number, should be keyof S & number
        case 'symbol': k; return; // k has type number, should be keyof S & symbol
        case 'string': k; return; // k has type number, should be keyof S & string
    }
}

Expected behavior:
The value k should narrow to an intersection type to retain keyof type.
Actual behavior:
The value k narrows to a primitive.
Playground Link:  N/A (Playground not on this version).

This one is fixed by #27157.

Great, I'll remove the fix I put in for #27182 (but will keep the tests).


Title is using file name full path when there is no #+TITLE: on the file

The root label function should use just the base file name as title (see file-name-base).
Also, if the TITLE property is set, but the title is an empty string, it should also fall back to the file name title.

Even with #+TITLE: set file path is still used

I believe the last commit fixed this.
The problem existed because I forgot to add a # character before the + 🤦🏻♂.
If you can update your config and give it another try, let me know if it indeed got fixed.

Close the wrong bug!

Latest commit has fixed this, thank you!


About Rocket-nginx.

Hi,
If I use WIB or Wordpress-nginx, is it okay to not use Rocket Nginx? Also I am using Woocommerce, and is it okay to use it as it is without any additional setting?
Thank you.

Yes, it is okay not to use Rocket Nginx repo. Rocket Nginx just makes things a bit easier to generate the configuration files by generating them automatically. In this repo, the configuration files are split over multiple files and directories. So, everything has to work together, but have the flexibility to change or tweak the setting further.
Yes, you may use this repo or Rocket Nginx without any additional settings for Woocommerce.

Hi, I appreciate your kind reply.
I also installed Wp In Box and am using it and I have a few questions with it.

Does Redis plugin need to be installed on Redis Object Cache plugin to use Redis Cache? Or is it okay without any plugin?

Can I choose a PHP version for installation? I checked file php-installation.sh but could not find out how to change it to 7.2.

I logged in Terminal through system_admin, changed to Root authorization, made WP directory and gave www-data authorization, but a window that requests for FTP authorization shows up when installing theme or plugin. Which authorization should I give to stop this window from showing up?

Thank you.

#1 - We need any one WP object cache plugin based on Redi to make use of redis for WP. Redis would be still used by the server to store sessions (from what I remember). Apart from what you mentioned, other plugins work too. Here's an example list of plugins based on redis... https://wordpress.org/plugins/tags/redis/ . All may not be object cache plugins.
#2 - Most clients do not care about the routine maintenance of the server. So, I kept the PHP version that comes with the OS that usually supports that built-in PHP version for longer time than the official PHP version. So, I don't plan to change it to install a third-party repo to have the latest version of PHP. If you wish to install the latest PHP, such as PHP 7.2, you may choose the OS that comes with that particular version (such as Ubuntu 18.04 for PHP 7.2) or choose a third-party repo such as Ondrej PPA to install the latest version of PHP. Actually, I've made it bit easier, if you have bootstrapped the server using WP In a Box repo. Install the Ondrej PPA and then use https://gist.github.com/pothi/873bc7e95843605ad51f6365f439b9a7 to install whatever version supported by Ondrej. I hope that helps.
#3 - You should use system_admin user only to use administer the system (as root for example). For everything related to WP, please use web_developer username. You can check the usernames and their passwords at /root/.envrc file. I plan to improve the documentation in the near future. So, sorry about the lack of documentation at the moment. Basically, PHP runs on web_developer user. Nginx runs as www-data or as simply as nginx. We should never give www-data or nginx to make changes to WP directory. So, please change the permissions to web_developer user.
There are only two users in the server. 1. system_admin user 2. web_developer user. System admin is meant for system admin activities, such as creating a new database (for WordPress) or for creating vhost entry in Nginx. Web developer should never touch the server on normal circumstances. So, web_developer user has the permission to modify only the WP related files. If you are a full-stack developer or a single user who handles everything for your client, then switch between these two users as and when required. I know it may seem complex at first. But, you'd appreciate this structure once you start working with a team of web developers who may just need SFTP and MySQL login details to work on the site.

Hi, Your instruction has helped me resolve most of my issues, but I still have trouble with my authorization on SFTP.
Though I have tested by web_ and sys_, I can neither upload a file nor create a folder due to the authorization problem(Root). Could you let me know which account I should use to log in?
Thank you.

Hello,
For SFTP, please use the username starting with web_.
For SSH, please use the other (sys_). You'd always type sudo -i or sudo su - after logging in as sys_ user, as there is nothing to do with this user alone.
If you can not upload or create a folder as SFTP user (web_), either the permissions are incorrect or you are trying to upload to the top-most directory (/home/web) of the SFTP user. This is not possible due to the limitations of built-in SFTP. The built-in SFTP requires the home directories to be owned by root user. You can not circumvent this limitation using ACL or by any other means. That's why most directories that are required by most use-cases are created by default when SFTP user is created at first using /etc/skel. Ref: https://github.com/pothi/wp-in-a-box/blob/master/scripts/linux-tweaks.sh#L32-L38 . If you wish to upload directories and files into the top-most directory of the SFTP user, then there are a few options...

Create the directories and (empty) files manually as root and then change the permissions to the SFTP user (like mkdir /home/web/mydir && chown web_xyz /home/web/mydir.

Convert SFTP user into SSH user by removing SFTP user from the group web and then updating the permission of /home/web from root to web_ user. Please know that this assumes you are the only user in the entire server. If you are going to share the credentials to another web developer, then he or she'd be able to see all the directories of the server, as SSH users do not have much limitation as SFTP users. SFTP users can be limited to $HOME. With SSH users, it is not easy. In such situations, the following option is recommended.

Use some alternative SFTP/SSH implementations such as https://github.com/mysecureshell/mysecureshell  that offers both SFTP / SSH without this particular limitation (of not able to upload files / folders into user's $HOME ).

I hope this has helped to resolve most issues.
Since, you've used this repo and WP in a box repo, would you mind sharing your feedback by answering the following questions?

Earlier, I was using the prefex sftp_ and ssh_ to distinguish SFTP user and SSH user. What naming scheme do you prefer for SFTP and SSH user? Would you prefer the current naming scheme for prefix like web_ and sys_ or sftp_ and ssh_.

Any other feedback (apart from improving the documentation that I'd be working on improving later today).

Providing feedback is completely optional. I already learned a few things to change after what you've gone through so far.
Thanks.

Hello,
I'd like to close this issue, as we discussed the actual issue in length and there is no further reply from you for a long time. Also, the title of the issue may be misleading for others.
Thanks,
Pothi.


Contacts with middle names are displayed incorrectly

I have a few contacts with the middle name field filled out, and when manually importing them, they are imported as Middle First Last rather than First Middle Last. I can't say if this also happens with automatic importing, I couldn't get it to work as per #613.
EDIT: I meant #612. I'm very sorry I had the wrong number!

Any chance you can grab a sample from the VCF file and redact the PII and replace it with sample data? Just so I have something to go off of

Yeah, here is a contact for a fictitious person whose full name is "John James Appleseed". When importing it manually, the Display Name becomes "James John Appleseed". (ZIPped for GitHub requirements. I can upload elsewhere if you need!)
John James Appleseed.vcf.zip

Fixed, my development branch. Thanks.


Recreating resources with deletion protection results in duplicate state entries

My team encountered some unexpected behavior when we accidentally renamed some resources that had deletion protection enabled.  I was able to reproduce this with Terraform v1.0.5 and, aiven/aiven provider v2.1.19.  Thanks in advance for taking a look, and let me know if I can provide more information.
Expected behavior
Rresource creation should fail if there is already a resource in the Terraform state with the same Aiven ID (e.g. <project_name>/<service_name> for type aiven_kafka).
Actual behavior
Terraform creates a duplicate resource in state pointing to the same Aiven ID.
Steps to reproduce

Define resources with deletion protection enabled.

Initial Terraform config:
terraform {
  required_version = "1.0.5"
  required_providers {
    aiven = {
      source  = "aiven/aiven"
      version = "2.1.19"
    }
  }
}

resource "aiven_kafka" "test" {
  project                 = local.project_name
  plan                    = "startup-2"
  service_name            = "terraform-test"
  termination_protection  = true
}

resource "aiven_kafka_topic" "test" {
  project                = local.project_name
  service_name           = aiven_kafka.test.service_name
  topic_name             = "my-topic"
  partitions             = 1
  replication            = 2
  termination_protection = true
}

Apply Terraform - goes as expected.

Plan/apply output
$ terraform apply
Terraform will perform the following actions:

  # aiven_kafka.test will be created
  + resource "aiven_kafka" "test" {
      + components              = (known after apply)
      + default_acl             = true
      + id                      = (known after apply)
      + maintenance_window_dow  = "tuesday"
      + maintenance_window_time = "11:00:00"
      + plan                    = "startup-2"
      + project                 = ***
      + service_host            = (known after apply)
      + service_name            = "terraform-test"
      + service_password        = (sensitive value)
      + service_port            = (known after apply)
      + service_type            = (known after apply)
      + service_uri             = (sensitive value)
      + service_username        = (known after apply)
      + state                   = (known after apply)
      + termination_protection  = true

      + kafka {
          + access_cert         = (sensitive value)
          + access_key          = (sensitive value)
          + connect_uri         = (sensitive value)
          + rest_uri            = (sensitive value)
          + schema_registry_uri = (sensitive value)
        }
    }

  # aiven_kafka_topic.test will be created
  + resource "aiven_kafka_topic" "test" {
      + id                     = (known after apply)
      + partitions             = 1
      + project                = ***
      + replication            = 2
      + service_name           = "terraform-test"
      + termination_protection = true
      + topic_name             = "my-topic"
    }

    Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

...

Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

Change the names of the Terraform resources.

Modified config:
terraform {
  required_version = ">= 1.0.0"
  required_providers {
    aiven = {
      source  = "aiven/aiven"
      version = "2.1.19"
    }
  }
}

resource "aiven_kafka" "test_2" {
  project                 = local.project_name
  plan                    = "startup-2"
  service_name            = "terraform-test"
  termination_protection  = true
}

resource "aiven_kafka_topic" "test_2" {
  project                = local.project_name
  service_name           = aiven_kafka.test_2.service_name
  topic_name             = "my-topic"
  partitions             = 1
  replication            = 2
  termination_protection = true
}

Attempt to apply Terraform.  It fails to delete the existing resource due to deletion protection, as expected.

Terraform plan/apply output
aiven_kafka_topic.test: Refreshing state... [id=***/terraform-test/my-topic]
aiven_kafka.test: Refreshing state... [id=***/terraform-test]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  - destroy

Terraform will perform the following actions:

  # aiven_kafka.test will be destroyed
  - resource "aiven_kafka" "test" {
      - cloud_name              = "aws-us-east-1" -> null
      - components              = [
          - {
              - component                   = "kafka"
              - host                        = "***"
              - kafka_authentication_method = ""
              - port                        = 26451
              - route                       = "dynamic"
              - ssl                         = false
              - usage                       = "primary"
            },
        ] -> null
      - default_acl             = true -> null
      - id                      = "***/terraform-test" -> null
      - maintenance_window_dow  = "tuesday" -> null
      - maintenance_window_time = "11:00:00" -> null
      - plan                    = "startup-2" -> null
      - project                 = "***" -> null
      - service_host            = "***" -> null
      - service_name            = "terraform-test" -> null
      - service_port            = 26451 -> null
      - service_type            = "kafka" -> null
      - service_uri             = (sensitive value)
      - state                   = "RUNNING" -> null
      - termination_protection  = true -> null

      - kafka {
          - access_cert         = (sensitive value)
          - access_key          = (sensitive value)
          - rest_uri            = (sensitive value)
          - schema_registry_uri = (sensitive value)
        }

      - kafka_user_config {
          - ip_filter       = [
              - "<IP_ADDRESS>/0",
            ] -> null
          - kafka_connect   = "false" -> null
          - kafka_rest      = "false" -> null
          - kafka_version   = "2.7" -> null
          - schema_registry = "false" -> null

          - kafka {
              - group_max_session_timeout_ms              = "300000" -> null
              - group_min_session_timeout_ms              = "6000" -> null
              - log_cleaner_min_cleanable_ratio           = "0.5" -> null
              - log_cleanup_policy                        = "delete" -> null
              - max_incremental_fetch_session_cache_slots = "1000" -> null
              - message_max_bytes                         = "1000012" -> null
            }

          - kafka_authentication_methods {
              - certificate = "true" -> null
              - sasl        = "false" -> null
            }
        }
    }

  # aiven_kafka.test_2 will be created
  + resource "aiven_kafka" "test_2" {
      + components             = (known after apply)
      + default_acl            = true
      + id                     = (known after apply)
      + plan                   = "startup-2"
      + project                = "***"
      + service_host           = (known after apply)
      + service_name           = "terraform-test"
      + service_password       = (sensitive value)
      + service_port           = (known after apply)
      + service_type           = (known after apply)
      + service_uri            = (sensitive value)
      + service_username       = (known after apply)
      + state                  = (known after apply)
      + termination_protection = true

      + kafka {
          + access_cert         = (sensitive value)
          + access_key          = (sensitive value)
          + connect_uri         = (sensitive value)
          + rest_uri            = (sensitive value)
          + schema_registry_uri = (sensitive value)
        }
    }

  # aiven_kafka_topic.test will be destroyed
  - resource "aiven_kafka_topic" "test" {
      - id                     = "***/terraform-test/my-topic" -> null
      - partitions             = 1 -> null
      - project                = *** -> null
      - replication            = 2 -> null
      - service_name           = "terraform-test" -> null
      - termination_protection = true -> null
      - topic_name             = "my-topic" -> null

      - config {
          - cleanup_policy                      = "delete" -> null
          - compression_type                    = "producer" -> null
          - delete_retention_ms                 = "86400000" -> null
          - file_delete_delay_ms                = "60000" -> null
          - flush_messages                      = "9223372036854775807" -> null
          - flush_ms                            = "9223372036854775807" -> null
          - index_interval_bytes                = "4096" -> null
          - max_compaction_lag_ms               = "9223372036854775807" -> null
          - max_message_bytes                   = "1000012" -> null
          - message_downconversion_enable       = "true" -> null
          - message_format_version              = "2.7-IV2" -> null
          - message_timestamp_difference_max_ms = "9223372036854775807" -> null
          - message_timestamp_type              = "CreateTime" -> null
          - min_cleanable_dirty_ratio           = "0.5" -> null
          - min_compaction_lag_ms               = "0" -> null
          - min_insync_replicas                 = "1" -> null
          - preallocate                         = "false" -> null
          - retention_bytes                     = "-1" -> null
          - retention_ms                        = "604800000" -> null
          - segment_bytes                       = "209715200" -> null
          - segment_index_bytes                 = "10485760" -> null
          - segment_jitter_ms                   = "0" -> null
          - segment_ms                          = "604800000" -> null
          - unclean_leader_election_enable      = "false" -> null
        }
    }

  # aiven_kafka_topic.test_2 will be created
  + resource "aiven_kafka_topic" "test_2" {
      + id                     = (known after apply)
      + partitions             = 1
      + project                = ***
      + replication            = 2
      + service_name           = "terraform-test"
      + termination_protection = true
      + topic_name             = "my-topic"
    }

Plan: 2 to add, 0 to change, 2 to destroy.
aiven_kafka_topic.test: Destroying... [id=***/terraform-test/my-topic]
aiven_kafka.test_2: Creating...
aiven_kafka.test_2: Still creating... [10s elapsed]
aiven_kafka.test_2: Creation complete after 16s [id=***/terraform-test]
aiven_kafka_topic.test_2: Creating...
aiven_kafka_topic.test_2: Creation complete after 7s [id=***/terraform-test/my-topic]

Error: cannot delete kafka topic when termination_protection is enabled

The Terraform state now contains duplicate resources:

$ terraform state list
aiven_kafka.test
aiven_kafka.test_2
aiven_kafka_topic.test
aiven_kafka_topic.test_2

I'll include the full output for terraform state show here, but the important part is that the IDs for aiven_kafka.test and aiven_kafka.test_2 are identical, as are the IDs of aiven_kafka_topic.test and aiven_kafka_topic.test_2.

State output
$ terraform state show aiven_kafka.test
# aiven_kafka.test:
resource "aiven_kafka" "test" {
    cloud_name              = "aws-us-east-1"
    components              = [
        {
            component                   = "kafka"
            host                        = "***"
            kafka_authentication_method = ""
            port                        = 26451
            route                       = "dynamic"
            ssl                         = false
            usage                       = "primary"
        },
    ]
    default_acl             = true
    id                      = "***/terraform-test"
    maintenance_window_dow  = "tuesday"
    maintenance_window_time = "11:00:00"
    plan                    = "startup-2"
    project                 = "***"
    service_host            = "***"
    service_name            = "terraform-test"
    service_port            = 26451
    service_type            = "kafka"
    service_uri             = (sensitive value)
    state                   = "RUNNING"
    termination_protection  = true

    kafka {
        access_cert         = (sensitive value)
        access_key          = (sensitive value)
        rest_uri            = (sensitive value)
        schema_registry_uri = (sensitive value)
    }

    kafka_user_config {
        ip_filter       = [
            "<IP_ADDRESS>/0",
        ]
        kafka_connect   = "false"
        kafka_rest      = "false"
        kafka_version   = "2.7"
        schema_registry = "false"

        kafka {
            group_max_session_timeout_ms              = "300000"
            group_min_session_timeout_ms              = "6000"
            log_cleaner_min_cleanable_ratio           = "0.5"
            log_cleanup_policy                        = "delete"
            max_incremental_fetch_session_cache_slots = "1000"
            message_max_bytes                         = "1000012"
        }

        kafka_authentication_methods {
            certificate = "true"
            sasl        = "false"
        }
    }
}
$ terraform state show aiven_kafka.test_2
# aiven_kafka.test_2:
resource "aiven_kafka" "test_2" {
    cloud_name              = "aws-us-east-1"
    components              = [
        {
            component                   = "kafka"
            host                        = "***"
            kafka_authentication_method = ""
            port                        = 26451
            route                       = "dynamic"
            ssl                         = false
            usage                       = "primary"
        },
    ]
    default_acl             = true
    id                      = "***/terraform-test"
    maintenance_window_dow  = "tuesday"
    maintenance_window_time = "11:00:00"
    plan                    = "startup-2"
    project                 = "***"
    service_host            = "***"
    service_name            = "terraform-test"
    service_port            = 26451
    service_type            = "kafka"
    service_uri             = (sensitive value)
    state                   = "RUNNING"
    termination_protection  = true

    kafka {
        access_cert         = (sensitive value)
        access_key          = (sensitive value)
        rest_uri            = (sensitive value)
        schema_registry_uri = (sensitive value)
    }

    kafka_user_config {
        ip_filter       = [
            "<IP_ADDRESS>/0",
        ]
        kafka_connect   = "false"
        kafka_rest      = "false"
        kafka_version   = "2.7"
        schema_registry = "false"

        kafka {
            group_max_session_timeout_ms              = "300000"
            group_min_session_timeout_ms              = "6000"
            log_cleaner_min_cleanable_ratio           = "0.5"
            log_cleanup_policy                        = "delete"
            max_incremental_fetch_session_cache_slots = "1000"
            message_max_bytes                         = "1000012"
        }

        kafka_authentication_methods {
            certificate = "true"
            sasl        = "false"
        }
    }
}

@expnch, thanks for reporting this issue and all the details.
This is happening because we ignore an error 409 already exists for some resources. We can change that for a Kafka service, but not for Kafka Topic, this part of Aiven API is a bit flaky, and sometimes it takes several attempts to create a Topic.

I did some additional experimentation and it's possible to end up with this duplicate items in state even without deleting anything.  I think deletion is a more likely user scenario than the following, though.
Applying the following:
resource "aiven_kafka" "test" {
  project                 = local.project_name
  plan                    = "startup-2"
  service_name            = "terraform-test"
}

resource "aiven_kafka" "test-2" {
  project                 = local.project_name
  plan                    = "startup-2"
  service_name            = "terraform-test"
}

Results in this plan:
Terraform will perform the following actions:

  # aiven_kafka.test will be created
  + resource "aiven_kafka" "test" {
      + components       = (known after apply)
      + default_acl      = true
      + id               = (known after apply)
      + plan             = "startup-2"
      + project          = "***"
      + service_host     = (known after apply)
      + service_name     = "terraform-test"
      + service_password = (sensitive value)
      + service_port     = (known after apply)
      + service_type     = (known after apply)
      + service_uri      = (sensitive value)
      + service_username = (known after apply)
      + state            = (known after apply)

      + kafka {
          + access_cert         = (sensitive value)
          + access_key          = (sensitive value)
          + connect_uri         = (sensitive value)
          + rest_uri            = (sensitive value)
          + schema_registry_uri = (sensitive value)
        }
    }

  # aiven_kafka.test-2 will be created
  + resource "aiven_kafka" "test-2" {
      + components       = (known after apply)
      + default_acl      = true
      + id               = (known after apply)
      + plan             = "startup-2"
      + project          = "***"
      + service_host     = (known after apply)
      + service_name     = "terraform-test"
      + service_password = (sensitive value)
      + service_port     = (known after apply)
      + service_type     = (known after apply)
      + service_uri      = (sensitive value)
      + service_username = (known after apply)
      + state            = (known after apply)

      + kafka {
          + access_cert         = (sensitive value)
          + access_key          = (sensitive value)
          + connect_uri         = (sensitive value)
          + rest_uri            = (sensitive value)
          + schema_registry_uri = (sensitive value)
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Which executes without any errors, leaving the state with:
$ terraform state list
tf state list
aiven_kafka.test
aiven_kafka.test-2

$ terraform state show aiven_kafka.test | grep id
    id                      = "***/terraform-test"

$ terraform state show aiven_kafka.test-2 | grep id
    id                      = "***/terraform-test"

If you run terraform destroy, it succesfully deletes the 1 resource from Aiven and removes the 2 resources from the state, so maybe this is more of a confusing than problematic bug.


Split response by article in scrape_ag.sh

Fixes #297

Does this fixes it actually? I still get wrong output.
Also,
d = "\n".join(l for l in d.split('<article'))

is equivalent to:
d = "\n".join(d.split('<article'))

@baryluk Thanks for the code tip! ☺
Hmm yes works for me as it runs now only on articles starting with "Neues Lagebulletin" (the first one). Note that the "Date and time" is now correct 27.03.2020:
$ scrapers/scrape_ag.sh
AG
Downloading: https://www.ag.ch/de/themen_1/coronavirus_2/alle_ereignisse/alle_ereignisse_1.jsp
Scraped at: 2020-03-28T22:19:16+01:00
Date and time: 2020-03-27T15:00:00
Confirmed cases: 364
Hospitalized: 50
ICU: 12
Vent: 9
Deaths: 3

Vent, should be 10. Not 9.
Maybe use this:
print('Vent:', sc.find(r'\b([0-9]+)\s*Person(en)? k(ü|ü)nstlich beatmet werden', d))

Similar modification could be made to ICU probably.
I didn't test it.

Ah yes, didn't notice Vent was wrong - fixed:
$ scrapers/scrape_ag.sh
AG
Downloading: https://www.ag.ch/de/themen_1/coronavirus_2/alle_ereignisse/alle_ereignisse_1.jsp
Scraped at: 2020-03-28T22:28:22+01:00
Date and time: 2020-03-27T15:00:00
Confirmed cases: 364
Hospitalized: 50
ICU: 12
Vent: 10
Deaths: 3


Error Check for Charter Max on Community Creation

Describe the bug
Tried to create a longer profile, but didn't realize it was over the max char length until after I was singing transaction, then i lost progress
To Reproduce
Steps to reproduce the behavior:

Create Community
Enter a description thats too long

Expected behavior

On front end; you are above the character count

Well it does let you know actually, on submit button a popup would be nice to prevent this

There's no validation on frontend yet, will be fixed in #172


⚠ Bofrost.at has degraded performance

In d8ba244, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1010 ms

Resolved: Bofrost.at performance has improved in 588b428 after 6 minutes.


feat(retrigger): add retrigger process steps

Description

add retrigger logic for processes
add documentation for processes

Why
To give the possibility to retrigger processes that failed
Issue
Refs: #209
Checklist

[x] I have followed the contributing guidelines
[x] I have performed IP checks for added or updated 3rd party libraries
[x] I have created and linked IP issues or requested their creation by a committer
[x] I have performed a self-review of my own code
[x] I have successfully tested my changes locally
[x] I have added tests that prove my changes work
[x] I have checked that new and existing tests pass locally with my changes
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added copyright and license headers, footers (for .md files) or files (for images)

@evegufy @ntruchsess this Pr should be merged after #235 is merged


Remove remnants of async-profiler based Java support experiment

Signed-off-by: Kemal Akkoyun<EMAIL_ADDRESS>

ref: #1


ftl kotlin init generates a pom.xml with a hard coded local endpoint

At the moment, when generating a kotlin project, the pom.xml contains an invocation of the ftl-generator command. By default it gets generated with an endpoint that is hardcoded to http://<IP_ADDRESS>:8892. This makes deployment to other FTL clusters tricky, as it forces you to change this value in order to compile for different environments.
It would be ideal if this value could somehow be set dynamically. Regular FTL commands use the FTL_ENDPOINT environment variable. Perhaps this could be either read in the ftl-generate command or used in the pom.xml file to set this endpoint command line option.
This may be relevant to work being done by @worstell on the Kotlin front.

Yeah I think we should remove the flag from the pom and make ftl-generator use ${FTL_ENDPOINT} if provided and if not, default to http://<IP_ADDRESS>:8892.


ListSerializer AlwaysEmitNil() forces output of null grandchild items

Regarding the ListSerializer, what is the point of  AlwaysEmitNil()  if null items are not serialized via the CustomSerializer class when the ShouldEmitNil option is false (the default)? The ListSerializer class calls upon the following CustomSerializer  method to emit the list item instance:
        public void SerializeObject(XSerializerXmlTextWriter writer, object instance, ISerializeOptions options)
        {
            if (instance == null && !options.ShouldEmitNil)
            {
                return;
            }
            <<< snip >>>
       }

The unfortunate impact of AlwaysEmitNil() is that it cascades down the serialization pipeline forcing the output of null grandchild items. From what I can tell, the integrity of the list can survive without the AlwaysEmitNil() behavior.

Noting that without the AlwaysEmitNil() option, the PrimitiveArrayTests fail for arrays containing nulls .


Updated lfortran to 0.36.0

Hi @anutosh491 ! It looks like the lfortran.wasm file is not packaged.
Files in package:
 │ │   - bin/lfortran.js
 │ │   - include/lfortran/impure/lfortran_intrinsics.h
 │ │   - lib/liblfortran_runtime.a
 │ │   - lib/liblfortran_runtime_static.a

Maybe we can try copying it manually to $PREFIX/bin in the build script. And then change the test to:
tests:
- script:
   - test -f ${PREFIX}/liblfortran_runtime.a
   - node ${PREFIX}/bin/lfortran.js --version
 requirements:
   build:
     - nodejs

Btw, this version works with -DWITH_TARGET_WASM=yes. It just needs
export EMSDK_PATH=${EMSCRIPTEN_FORGE_EMSDK_DIR}

Cool, let's try that out !

Btw, this version works with -DWITH_TARGET_WASM=yes. It just needs
export EMSDK_PATH=${EMSCRIPTEN_FORGE_EMSDK_DIR}

but this is the "to wasm compiled version with lfortran".
This is not the compiler which we use to compile fotran to wasm (this would be the recipe I tried to add here https://github.com/emscripten-forge/recipes/pull/1012)
So I think we do not need the -DWITH_TARGET_WASM=yes

cc @IsabelParedes
I think this is ready. We should use the test_lfortran.js file cause that's exactly what LFortran does in their CI
      - name: Test built lfortran.wasm
        shell: bash -l {0}
        run: |
            set -ex
            source $HOME/ext/emsdk/emsdk_env.sh # Activate Emscripten
            which node
            node -v
            node --experimental-wasm-bigint src/lfortran/tests/test_lfortran.js

The --experimental-wasm-bigint is only required if the node version is below 16 (Lfortran uses 14.xx)
This is the result on their master branch and we get the same
===============================================================================
[doctest] test cases:  49 |  49 passed | 0 failed | 0 skipped
[doctest] assertions: 456 | 456 passed | 0 failed |
[doctest] Status: SUCCESS!

Why is source $HOME/ext/emsdk/emsdk_env.sh # Activate Emscripten needed.
Since this is already compiled to wasm there should be no need to use the
emsdk for anything

Why is source $HOME/ext/emsdk/emsdk_env.sh # Activate Emscripten needed.

Ahh that's just reference code from LFortran's CI . Haven't used it for the recipes :)


pod install fails to install Flipper-Glog under 0.65.1 with Apple Silicon

Description
Installing pods fails under react-native 0.65.1 with macOS Apple Silicon (ARM64).
Specifically the Flipper-Glog, although I've seen glog fail as well:
Installing Flipper-Glog (0.3.6)
[...]
/Users/coco/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing: Unknown `--is-lightweight' option
Try `/Users/coco/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
Invalid configuration `arm64-apple-darwin20.5.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin20.5.0 failed

Full log on pastebin here.
React Native version:
❯ npx react-native info
info Fetching system and libraries information...
System:
    OS: macOS 11.4
    CPU: (8) arm64 Apple M1
    Memory: 89.67 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 15.10.0 - ~/.nvm/versions/node/v15.10.0/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 7.5.3 - ~/.nvm/versions/node/v15.10.0/bin/npm
    Watchman: 20201220.042258.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
    Android SDK:
      Android NDK: 20.0.5594570
  IDEs:
    Android Studio: Not Found
    Xcode: 12.5.1/12E507 - /usr/bin/xcodebuild
  Languages:
    Java: 15.0.1 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: Not Found
    react-native: Not Found
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce
Under macOS with Apple Sillicon, run:

npx react-native init RN65
cd RN65
arch -x86_64 pod install

Try this:https://github.com/facebook/react-native/issues/32033#issuecomment-902560416

Thank you @tylinux, your fixes appears to be solving this issue.
Also closing this one as duplicate in favor of #32033.


🌐 Update Spanish translation for docs/es/docs/tutorial/first-steps.md

This is the Spanish translation for the first steps page.
Fix Spanish translation structure for docs/es/docs/tutorial/first-steps.md

Version >= 0.108.0

📝 Docs preview for commit 19c0f42bf4e7a85c14e9f47a7710972137842d1b at: https://7df4a667.fastapitiangolo.pages.dev

📝 Docs preview for commit fac94e7b35a18fcfbf01a7706fd5eca802c62faf at: https://6e611d1c.fastapitiangolo.pages.dev

This was covered in another PR, so I'll close this one now, thanks for the effort! :cake: :coffee:


arity calculations disallow prop7

THEFT_MAX_ARITY is defined as 7, which is used for allocation of the type_info, but creating a prop7 property function always fails because theft_run.c:infer_arity will return 0.
The infer_arity should probably return THEFT_MAX_ARITY instead of 0 when falling out of the loop, but whether type_info should be NULL terminated, or whether there are other locations with THEFT_MAX_ARITY issues is an open question.

Good find, thanks. I recently reduced the max arity to 7 (it was 10), but I've never actually had reason to use an arity higher than 2. This got missed.

Fixed by a8af8fe, will be in the next release.

Excellent, thank you.  It was a pretty unusual test that needed this arity level, but it is handy when you do need it.

I'd love to hear more about how you're using theft! My contact info is in my profile.


Documentation update for reduce functions, swizzle

Working through giving example documentation to every Simd function.

The major change in this patch is using doc macros to generate
type-specific examples for each function, using a visually-apparent type
constructor. This makes it feel nicer to have twelve separate
documentation entries for reduce_product(), for example.

There's quite a lot to go through. I'm hoping this introductory patch sets something of a style for examples. In general, I tried to copy the style of the std::vec::Vec documentation, which I think is quite good.
The doc-macros here look a bit crafty, but I think the documentation they generate is very readable. Some examples:
for reduce_sum, specialized on u64:
let v = u64x4::from_array([1, 2, 3, 4]);
assert_eq!(v.reduce_sum(), 10);

// SIMD integer addition is always wrapping
let v = u64x4::from_array([u64::MAX, 1, 0, 0]);
assert_eq!(v.reduce_sum(), u64::MIN);

it would have looked cleaner with i64x2, but unfortunately i8x2 doesn't exist.
for reduce_max, specialized on f32:
let v = f32x2::from_array([1., 2.]);
assert_eq!(v.reduce_max(), 2.);

// NaN values are skipped...
let v = f32x2::from_array([1., f32::NAN]);
assert_eq!(v.reduce_max(), 1.);

// ...unless all values are NaN
let v = f32x2::from_array([f32::NAN, f32::NAN]);
assert!(v.reduce_max().is_nan());

If this looks OK, happy to keep this going in future patches. I think compiling the beginners-guide.md into top-level crate documentation would also likely be helpful, because it would give explanations that other documentation could refer to, instead of repeating concepts.

This is a very good improvement! I have only one note, which is mostly that there is not much need to take a cue from the existing content for phrasing.
In fact, while I realize it is currently everywhere, we want to somewhat reduce the presence of the "lanes" terminology because it is functionally "jargon". SIMD is a rather "specialty" subject, so we definitely don't have to go back to Programming 101, and certainly some users will be veteran SIMD programmers, thus familiar with it. But for others, like more mathematically-inclined users who may be coming from e.g. NumPy, and already feel in over their head with Rust, "lane" is mostly just Another Word, and ultimately SIMD is fine with borrowing terms that are mostly already used by Rust's arrays:

Length
Indices
Elements, and especially
"Elementwise"

That said, you don't have to actually do any changes to account for that yet, I am happy to merge this as-is, I just wanted to give you a heads up re: the incoming clobber.


Compiler error, on Windows 10

Hi.
I tried to build NSM project, using Windows 10 build of Golang 1.15.2 (x86_64).

~/Desktop/networkservicemesh/applications/nsmrs/cmd (master)
$ go run main.go
go: downloading github.com/opentracing/opentracing-go v1.1.0
go: downloading github.com/golang/protobuf v1.3.2
go: downloading google.golang.org/grpc v1.27.0
go: downloading github.com/uber/jaeger-client-go v2.17.0+incompatible
go: downloading github.com/spiffe/go-spiffe v0.0.0-20191104192205-d29ac0a1ba99
go: downloading golang.org/x/net v0.0.0-20200114155413-6afb5195e5aa
go: downloading github.com/uber/jaeger-lib v2.1.1+incompatible
go: downloading github.com/konsorten/go-windows-terminal-sequences v1.0.2
go: downloading google.golang.org/genproto v0.0.0-20200128133413-58ce757ed39b
github.com/networkservicemesh/networkservicemesh/pkg/tools
......\pkg\tools\tools.go:64:31: undefined: syscall.Stat_t

Looks like it is about this issue

@advancedwebdeveloper That appears to be in a utility function to get the current Network Namespace (a Linux feature I do not believe we have in Windows).
While we are taking care to get as much of the multi-repo work as we can so it still compiles and tests across MacOS/Windows... the networkservicemesh/networkservicemesh monorepo is probably mostly going to only work on Linux.

So this is not what you would require, on Windows containers?
Or it is the right thing?

CC @DCtheGeek

#2177 changed it from a "fails at runtime on Windows" failure to a "fails to compile for Windows" failure.
I don't know enough about this project to know if "fails at runtime on Windows" was correct for whatever functionality is needed (i.e. it's never called on WIndows), or whether someone needs to work out how to get the equivalent of an netns out of a Windows container so that (if I'm skimming correctly) code living outside the container can configure its network interfaces.

So this is not what you would require, on Windows containers?
Or it is the right thing?

OK... now I'm excited.  I'd be delighted to find out there are ways to get to full functionality on Windows.  Its just not an OS I know much about.  If folks can point to the appropriate analogous things in Windows, I'd be super super happy to get them proper support.
The thing we are tripping across here is a mechanism whereby a non-privilged container is providing information over GRPC about its network namespace (in this case getting the inode number of the netns from  /proc/self/ns/net and sending that along) and then we are using that to get a file for that network namespace such that we can insert an interface into it (that second half done by a fully privileged container, couldn't be done otherwise).  How would the analogous trick work in Windows?

Windows Network Namespaces are identified by GUID. I'm not sure how you would get the GUID for the current network namespace from inside the container. Perhaps calling hcn.ListNamespaces inside the container would only show your own namespace? I suspect the relevant services (HNS, HCS) are not even running inside a container though.
Kubernetes doesn't currently have privileged containers support for Windows. CSI node plugins for example work around this with a daemon (csi-proxy) running on the host. So you'd probably need something similar, something that can make HNS calls to the host OS to manage the virtual NICs attached to the containers.
The Google Docs-hosted proposal attached to the Windows privileged containers KEP mentions 'HNS Proxy' which I assume is like csi-proxy but for HNS calls, but I'm unable to locate such a thing with a brief search. It also says this:

Privileged containers will also enable service mesh support on Windows by enabling the creation of an init container that can configure HNS.

but that whole KEP's a few Kubernetes releases away at best.