Diagrams in Papyrus allow objects to stack on top of one another

Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
Tool currently lets you put objects on top of each other (this was an option in RSA turned off by default). So it becomes easy to accidentally hide things. This applies to ports on a component as well as components themselves (and probably assemblies too).

Hi @J17359. For this one, the tool should avoid overlapping objects both when creating new elements and moving elements around? In this cases what should be the behaviour if the user "releases" an object that overlaps an existing one? Returning it to its original position in the case of a move, or try to accomodate it somewhere that fits? And what about if this happens on creation of an element?
If objects in the diagram are already overlapping, should there be any effort made to clean it up? Some basic automatic diagram layout? Papyrus already includes some support for this.

I think having the elements snap back to where they were before being dragged could be annoying to users. Possibly, just placing the new diagram element as close to new position as possible without hiding anything, and without anything else moving would be the best solution.
Do you remember how did RSA handled this? I can't at the moment but I could go investigate it if needed.

@J17359 @j26151 This one has been a bit on the back-burner, but we have given it a little bit of thought. I do not remember how this is handled in RSA, so if you could could try it and let me know what's the behaviour it would be great.
It's important to note that we think this problem is definitely not trivial, as it is ultimately the general diagram layout problem. There are many issues that complicate it. For example: what if there is no space nearby the object where you want to put the new one? Where do you "snap-back" to? What do you do about connections? Ignore them, or try to avoid them? Answers to each of these seem to lead to different complications. In other words, I don't expect this one to be done quickly.


Please bump version number and push to NPM

As noted in https://github.com/shama/gaze/issues/210 the package.json file was recently updated to refer to globule 0.2.0, but that update never seems to have gone to the main npm.
I believe (but I'm new to this) that bumping the version number on gaze and re-pushing to npm will solve the problem. Thanks!

Thanks for the ping! The code that lives in the master branch is an updated version of 0.5.4. Slated to be released as 1.0.0 and latest. It will fix warnings and some other minor things. Unfortunately the tests are failing on Windows. So I can't yet publish it.
If you have access to a Windows machine I would appreciate some help debugging the failing tests. Thanks!

Alas, my Windows chops are not good enough to debug file system troubles. Sorry - and thanks for looking at this.

@shama what is the problem with windows?
Should it be possible to only upgrade lodash in a separate PR & patch release (0.5.x)? I have deprecation warnings during my npm install:
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained. Upgrade to<EMAIL_ADDRESS>
Thx.

@shama I've made a PR: https://github.com/shama/gaze/pull/213

Unfortunately the tests are failing on Windows

@shama I don't see any falling tests on Windows 10 as of today. All 54 assertions passed in 30 seconds. Where to look for the problem?

This issue was related to another version of this lib that had some failing tests. I ended up just releasing an updated version of 0.5.


Replace explicit type with <>.

@arturobernalg thanks a lot for the PR! Do you mind if I merge #116 first, and then we see what's left after that change? I guess some of the changes may have been fixed, and I also don't want to touch that PR again after the final review :sweat_smile:
Thank you!
Bruno

@arturobernalg thanks a lot for the PR! Do you mind if I merge #116 first, and then we see what's left after that change? I guess some of the changes may have been fixed, and I also don't want to touch that PR again after the final review 😅
Thank you! Bruno

HI @kinow
Sure.
TY

That PR has been merged. Can you rebase and take a look if your PR needs to be updated, please, @arturobernalg . Thanks!

That PR has been merged. Can you rebase and take a look if your PR needs to be updated, please, @arturobernalg . Thanks!

Hi @kinow
Done.
TY


RabbitMQ new client integration in stack

A new RabbitMQ client has been in development for Vert.x 5 : https://github.com/eclipse-vertx/vertx-rabbitmq-client/
We should properly integrate this client in the Vert.x stack.

For reference: https://github.com/vert-x3/vertx-stack#adding-a-new-module-to-the-stack


minio-client: 2020-04-25T00-43-23Z -> 2020-05-28T23-43-36Z

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/minio/mc/releases.
meta.description for minio-client is: "A replacement for ls, cp, mkdir, diff and rsync commands for filesystems and object storage"
meta.homepage for minio-client is: "https://github.com/minio/mc"
meta.changelog for minio-client is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2020-05-28T23-43-36Z with grep in /nix/store/irkn7dbsvn4f45bxfzjkb660jlqhlm0l-minio-client-2020-05-28T23-43-36Z

directory tree listing: https://gist.github.com/7a7c3c0261fa271bfa132acc51a2a6a6

du listing: https://gist.github.com/3fa2d6121e7a4a6c1e9e7c99879d4f6d

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
minio-client

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/irkn7dbsvn4f45bxfzjkb660jlqhlm0l-minio-client-2020-05-28T23-43-36Z \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A minio-client https://github.com/r-ryantm/nixpkgs/archive/492968009901488451d2fb17488a9ede50d61a62.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/irkn7dbsvn4f45bxfzjkb660jlqhlm0l-minio-client-2020-05-28T23-43-36Z
ls -la /nix/store/irkn7dbsvn4f45bxfzjkb660jlqhlm0l-minio-client-2020-05-28T23-43-36Z/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:
- minio-client

Maintainer pings
cc @edolstra @bachp @kalbasit for testing.

addressed by https://github.com/NixOS/nixpkgs/pull/95111


 If so, do you have an eta?

TVFs are supported, but are an optional feature that's off by default.  See LanguageOptions (in AnalyzerOptions).  You can call EnableMaximumLanguageFeatures() to turn everything on.

Works! Thank you!
For friends of Scala/Java:
val languageOptions = new LanguageOptions()
languageOptions.enableMaximumLanguageFeatures().setSupportsAllStatementKinds()
val analyzerOptions = new AnalyzerOptions()
analyzerOptions.setLanguageOptions(languageOptions)
val analyzer = new Analyzer(analyzerOptions, catalog)


Possible decoding error for some channels.

Executing the print channel example with
python print_channel_data.py > print_channel_data.txt

yields the attached output. For some channels the decoded date makes no sense as it is far in the future.

Index
Name

3
System.Device.Name

5
System.Device.BSP

9
System.Device.Serial

27
System.Device.AppVersion

31
System.Device.Version

33
System.Device.DeviceManager

41
System.CPU.ThreadInfo

48
System.Device.App

3: name: System.Device.Name
3: unit:
3: type: string
3: length: 2

0: ts= 2192-06-19T13:23:57.977671447 | y= smartRAIL-S_Colibri_STH
1: ts= 2192-06-19T13:23:57.977671447 | y= smartRAIL-S_Colibri_STH

The underlying int that is converted to this date format is<PHONE_NUMBER>977671447 which is already far to large to be in the present.
My guess is, that there is a decoding error from the OSF file.
Additional observations:

Most timestamps of the example recording are plausible.
It is always the data of the entire channel that is off.
The deviation (if present) is always the same for a channel but differs between channels.
The deviation is always in the future (except for System.Config.Version which seems to be a different problem).
The channels where it goes wrong have in common that sizeoflengthvalue="4".

print_channel_data.txt

Good observation @Mq89,
Faced the same issue yesterday.
Also faced it for more signals than the ones you already mentioned

Signal

system.modem.Level

system.hw.BoardVariantInfo

system.cfg.Version

system.modem.Network

system.modem.ICCID

system.hw.SoCVariantInfo

Bugfix is commited, please test it.

It works for me now.
Thank you!
I think, the issue can be closed.


Downgrade InvalidPhoneNumberNotice

Feature request
This notice (currently an ERROR) causes false positive. The first step for v3.0.0 release is to downgrade this notice (to avoid breaking changes) and then improve the validator so that it does not generate false positives.
Additional context
#1044

@lionel-nj I think https://github.com/MobilityData/gtfs-validator/issues/1058 should be the issue linked above in "Additonal context"?

Closing, resolved in #1062


[bug] Could not resolve dependency

Hello!
If we create a fresh latest expo app, the react version is 18.1.0. In Tamagui the peer dep is 18.2.0 which causes the following error:
peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/@tamagui/core
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@tamagui/adapt
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/@tamagui/dialog
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!       node_modules/@tamagui/alert-dialog
npm ERR!       1 more (tamagui)
npm ERR!     3 more (@tamagui/popover, @tamagui/select, tamagui)
npm ERR!   41 more (@tamagui/alert-dialog, @tamagui/animate-presence, ...)

To Reproduce
1. Create fresh expo app
2. Install tamagui latest

Package Json Info (please complete the following information):
{
  "name": "frontend",
  "version": "1.0.0",
  "scripts": {
    "start": "TAMAGUI_TARGET=native npx expo start --dev-client",
  },
  "dependencies": {
    "@react-native-community/netinfo": "^9.3.7",
    "@react-navigation/core": "^6.4.5",
    "@react-navigation/native": "^6.1.1",
    "@react-navigation/native-stack": "^6.9.7",
    "@tamagui/babel-plugin": "^1.0.1-rc.11",
    "@tamagui/colors": "^1.0.1-rc.11",
    "@tamagui/config-base": "^1.0.1-rc.11",
    "@tamagui/core": "^1.0.1-rc.11",
    "@tamagui/font-inter": "^1.0.1-rc.11",
    "@tamagui/shorthands": "^1.0.1-rc.11",
    "@tamagui/theme-base": "^1.0.1-rc.11",
    "babel-plugin-transform-inline-environment-variables": "^0.4.4",
    "expo": "~47.0.8",
    "expo-device": "^5.0.0",
    "expo-localization": "~14.0.0",
    "expo-notifications": "^0.17.0",
    "expo-splash-screen": "~0.17.5",
    "expo-status-bar": "~1.4.2",
    "expo-web-browser": "^12.0.0",
    "react": "18.1.0",
    "react-dom": "18.1.0",
    "react-native": "0.70.5",
    "react-native-reanimated": "^2.13.0",
    "react-native-safe-area-context": "^4.4.1",
    "react-native-screens": "^3.18.2",
    "react-native-web": "0.18.10",
    "tamagui": "^1.0.1-rc.11"
  },
  "devDependencies": {
    "@babel/core": "^7.12.9",
    "@babel/register": "^7.18.9",
    "@types/react": "~18.0.14",
    "@types/react-native": "~0.70.6",
    "babel-plugin-module-resolver": "^4.1.0",
    "ts-node": "^10.9.1",
    "typescript": "^4.9.4"
  },
  "engines": {
    "npm": ">=8.0.0 <9.0.0",
    "node": ">=16.0.0 <17.0.0"
  },
  "private": true
}

@los-ko in your package.json
  "engines": {
    "npm": ">=8.0.0 <9.0.0",
    "node": ">=16.0.0 <17.0.0"
  }

remove    "node": ">=16.0.0 <17.0.0"
then remove rm -rf node_modules package-lock.json
then install again npm i
also, better to use latest tamagui packages

@los-ko in your package.json
  "engines": {
    "npm": ">=8.0.0 <9.0.0",
    "node": ">=16.0.0 <17.0.0"
  }

1/ make sure that you are using correct node version. 2/ try to upgrade react to 18.2.0
then remove rm -rf node_modules package-lock.json then install again npm i
also, better to use latest tamagui packages

Same result.
Node version: 8.19.2
NPM version: 16.18.1

Ah realizing that manypkg reverts it when I set it to *, I'll have to find a workaround.

Fixed in rc 15


Unsupported type: Mediaplayer (Sonos)

@t0mg, is it possible to add support for the Mediaplayer switch? Yes another switch ;)
I use that one for a.o. my Sonos. It's shows what's playing on the Sonos and you can switch it on/off (the remote in the screenshot is not used).

Updates are being send with MQTT for this type of switch.
{"Battery":255,"RSSI":12,"dtype":"Light/Switch","id":"00014236","idx":486,"name":"Sonos kantoor - playing","nvalue":1,"stype":"Switch","svalue1":"The Weeknd - I Feel It Coming","switchType":"Media Player","unit":1}
{
   "ActTime" :<PHONE_NUMBER>,
   "ServerTime" : "2017-01-25 22:15:18",
   "Sunrise" : "08:28",
   "Sunset" : "17:07",
   "result" : [
      {
         "AddjMulti" : 1.0,
         "AddjMulti2" : 1.0,
         "AddjValue" : 0.0,
         "AddjValue2" : 0.0,
         "BatteryLevel" : 255,
         "CustomImage" : 123,
         "Data" : "The Weeknd - I Feel It Coming",
         "Description" : "",
         "Favorite" : 1,
         "HardwareID" : 3,
         "HardwareName" : "Dummy",
         "HardwareType" : "Dummy (Does nothing, use for virtual switches only)",
         "HardwareTypeVal" : 15,
         "HaveDimmer" : true,
         "HaveGroupCmd" : true,
         "HaveTimeout" : false,
         "ID" : "00014236",
         "Image" : "Sonos1",
         "IsSubDevice" : false,
         "LastUpdate" : "2017-01-25 22:15:09",
         "Level" : 0,
         "LevelInt" : 0,
         "MaxDimLevel" : 100,
         "Name" : "Sonos kantoor - playing",
         "Notifications" : "false",
         "PlanID" : "0",
         "PlanIDs" : [ 0 ],
         "Protected" : false,
         "ShowNotifications" : true,
         "SignalLevel" : "-",
         "Status" : "On",
         "StrParam1" : "",
         "StrParam2" : "",
         "SubType" : "Switch",
         "SwitchType" : "Media Player",
         "SwitchTypeVal" : 17,
         "Timers" : "false",
         "Type" : "Light/Switch",
         "TypeImg" : "Media",
         "Unit" : 1,
         "Used" : 1,
         "UsedByCamera" : false,
         "XOffset" : "0",
         "YOffset" : "0",
         "idx" : "486"
      }
   ],
   "status" : "OK",
   "title" : "Devices"
}

Similar to issue #25 but not exactly the same. In the MQTT message,  switchType is "Media Player" in both cases but dtype  is "Light/Switch" instead of "Lighting 2", stype is "Switch" instead of "AC".
Could you do the same as I did in #25, ie listing the commands of the remote widget ? Just on/off and play pause for now as I am still not sure that I want a full size remote in reacticz.
Thanks

For the Sonos part on and off would be enough. That is what I am using the switch for right now.
The remote of that switch is not working.
But the special part of this switch is that it shows the info on the song that is being played.
Would be great if you could show that info in Reacticz as well.
I also have a Mediaplayer switch for my Kodi. That one is indeed "Lighting 2" and "AC".
It also shows the title of what is playing on Kodi. The remote of that switch is working, but I guess on/off and play/pause would indeed be enough.
Let me know if you need some more info.

Made pull request #41. Let me know what you think of it.

Merged in #41.


Reinforcement Learning

Does candle also offers support for Reinforcement Learning?

There is nothing really specific for this in candle but it's the same for most ML framework that I would know of. E.g. in tch we didn't need any specific bits in order to build these examples. It might be possible to build some dedicated RL library on top of candle but that probably wouldn't belong to the core set of crates - that said incorportating some simple RL examples would probably be a good idea.

Tagging with "help-wanted". If anyone wanted to build some reinforcement learning based examples for candle, this would be great.
For example one could start by porting the a2c and ppo examples from tch-rs (see here) and use it on the same atari games. The tch-rs and candle api are very similar so this should hopefully not be too difficult.

It might take me a bit as I'm fairly new to Rust, but I'd like to take a stab at implementing / porting over the DDPG algorithm and setting up some tests / demos via your gymnasium wrapper PR that I just noticed :)

Ah actually I started with the gymnasium wrapper but plan on porting the RL bits from tch-rs (see here). So DDPG is the first one that I was planning to port to check that everything works out properly. Maybe there are other RL algorithms that you may want to take a stab at?

Fair enough :) I'm actually working part-time on a (masters) thesis involving DDPG so I'll be sticking to that one, but I can wait for your push since there are other to-dos on my list and then contribute the improvements / additions I end up implementing along the way.

Ah, great that you're doing your thesis on DDPG. I would say that if you think it's going to be a week or two, then you can go ahead and make a DDPG example, if it's likely to be more I would rather have a working example soon so that other folks can start playing with RL - and you can obviously also make your own implementation on the side.

It's likely going to take longer than a week or two. I have one too many projects going on right now and trying not to compromise on the work-life balance, so I'd rather not make such guarantees :)
I salute your pace and progress with Candle btw!

I've tried my hand at restructuring the ReplayBuffer and I'd appreciate some feedback, is this a good place to post & discuss code snippets or do you prefer another channel?

Great, here works well for me.

I thought a VecDeque would be an appropriate data structure, and instead of keeping track of several of them I grouped them into a Transition struct.
I left a comment in the hopes that you may know a nice way to "unzip" an iterator into several buckets in a single pass instead of iterating again for each bucket.
Also I am unsure whether my design introduces any other performance inefficiencies (e.g. Tensor::cat).
use std::collections::VecDeque;

use candle::{DType, Device, Tensor};
use rand::{distributions::Uniform, thread_rng, Rng};

#[derive(Clone)]
struct Transition {
    obs: Tensor,
    action: Tensor,
    reward: Tensor,
    next_obs: Tensor,
    terminated: bool,
    truncated: bool,
}
impl Transition {
    fn new(
        obs: &Tensor,
        action: &Tensor,
        reward: &Tensor,
        next_obs: &Tensor,
        terminated: bool,
        truncated: bool,
    ) -> Self {
        Self {
            obs: obs.clone(),
            action: action.clone(),
            reward: reward.clone(),
            next_obs: next_obs.clone(),
            terminated,
            truncated,
        }
    }
}

struct ReplayBuffer {
    buffer: VecDeque<Transition>,
    capacity: usize,
    size: usize,
}

impl ReplayBuffer {
    fn new(capacity: usize) -> Self {
        Self {
            buffer: VecDeque::with_capacity(capacity),
            capacity,
            size: 0,
        }
    }

    fn push(
        &mut self,
        obs: &Tensor,
        action: &Tensor,
        reward: &Tensor,
        next_obs: &Tensor,
        terminated: bool,
        truncated: bool,
    ) {
        if self.size == self.capacity {
            self.buffer.pop_front();
        } else {
            self.size += 1;
        }
        self.buffer.push_back(Transition::new(
            obs, action, reward, next_obs, terminated, truncated,
        ));
    }

    fn random_batch(&self, batch_size: usize) -> Option<(Tensor, Tensor, Tensor, Tensor)> {
        if self.size < batch_size {
            None
        } else {
            let transitions: Vec<Transition> = thread_rng()
                .sample_iter(Uniform::from(0..self.size))
                .take(batch_size)
                .map(|i| self.buffer.get(i).unwrap().clone())
                .collect();

            let obs: Vec<Tensor> = transitions.iter().map(|t| t.obs.clone()).collect();
            let action: Vec<Tensor> = transitions.iter().map(|t| t.obs.clone()).collect();
            let reward: Vec<Tensor> = transitions.iter().map(|t| t.obs.clone()).collect();
            let next_obs: Vec<Tensor> = transitions.iter().map(|t| t.obs.clone()).collect();

            //
            // would be nice to be able to unzip the iterator into the four buckets at once?
            // (without importing something like unzip_n)
            // then we could replace the above with the following:
            //

            // let (obs, action, reward, next_obs) = thread_rng()
            //     .sample_iter(Uniform::from(0..self.size))
            //     .take(batch_size)
            //     .map(|i| self.buffer.get(i).unwrap().clone())
            //     .map(|t| (t.obs, t.action, t.reward, t.next_obs))
            //     .collect::<(Vec<Tensor>, Vec<Tensor>, Vec<Tensor>, Vec<Tensor>)>();

            Some((
                Tensor::cat(&obs, 0).unwrap(),
                Tensor::cat(&action, 0).unwrap(),
                Tensor::cat(&reward, 0).unwrap(),
                Tensor::cat(&next_obs, 0).unwrap(),
            ))
        }
    }
}

If this looks fine to you, then I will continue on to the actual DDPG algorithm.

I think it's a great start and VecDeque makes a lot of sense here. I don't have a better suggestion re unzipping but your code looks fine, there might be some small typos around the t.obs though that you want to adapt.
This indeed will not be super efficient using Tensor::cat but to start with it's probably good and once you get something working we can profile it to see where the time is actually being spent and optimize these bits.

Oh yeah, good catch! Alright, thanks for the feedback.

Can you point me to some resources explaining / motivating the VarMap / VarBuilder APIs?
In tch-rs there is the VarStore which (in the DDPG example) is saved by the model structs (I guess to facilitate cloning) and the optimizer as well as the layers (via some steps through Path) are registered there automatically.
In the Mnist example in candle, the VarBuilder is only passed to the constructor functions as an argument and things are registered there (somehow?), and the VarMap is not passed down to the models at all. Also the VarBuilder knows the Device and DType so that doesn't need to be saved by the model struct either I would guess?
I guess I'm trying to understand and wrap my head around the concepts, which are new to me, to figure out how to handle them in the most idiomatic way and I could use some more reading material or examples.
For instance, in my first draft for the Actor constructor, I am unsure whether I should be passing down both the VarBuilder and the VarMap (since I need the VarMap to initialize the optimizer and the VarBuilder to initialize the layers) or should I construct the VarBuilder within the constructor on the fly?
struct Actor {
    network: Sequential,
    optimizer: Optimizer,
    num_obs: usize,
    num_actions: usize,
    learning_rate: f64,
}
impl Actor {
    fn new(
        varbuilder: VarBuilder,
        varmap: VarMap,
        num_obs: usize,
        num_actions: usize,
        learning_rate: f64,
    ) -> Self {

        // let varmap = VarMap::new();
        // let vb = VarBuilder::from_varmap(&varmap, DType::F32, &Device::Cpu);

        let optimizer = AdamW::new(
            varmap.all_vars(),
            ParamsAdamW {
                lr: learning_rate,
                ..Default::default(),
            },
        ).unwrap();

        let prefix = "actor";
        let network = seq()
            .add(linear(num_obs, 400, varbuilder.pp(concat!(prefix, "fc1"))))
            .add(Activation::Relu)
            .add(linear(400, 300, varbuilder.pp(concat!(prefix, "fc2"))))
            .add(Activation::Relu)
            .add(linear(300, num_actions, varbuilder.pp(concat!(prefix, "fc3"))))
            .add(Activation::Sigmoid); // TODO: This should be Tanh.

        Self {
            network,
            optimizer,
            num_obs,
            num_actions,
            learning_rate,
        }
    }
}

Sorry there isn't much documentation here.
The VarMap actually stores the variables, it can be used to serialize and deserialize them.
A VarBuilder can be queried for some variables (and maintains some notion of path). It's a very thin wrapper over a backend that may either load the variables from disk, take them from memory, initialize them, or do whatever. In the VarMap case new variables get initialized.
When building a model, you want to pass the VarBuilder around. This abstracts what is used to retrieve the variables so the same code can be used either to create a model for training or for inference with pre-trained weights. The VarMap is only typically used at top level, as you mentioned to pass all the variables to the optimizer, save the variables in a checkpoint (or load them from a checkpoint).

I'm trying to create a copy of a network, so for example with a Linear layer I am calling .get on a VarBuilder, to get the weights Tensor, then I .copy() that Tensor and create a new Linear layer explicitly with ::new(). However I still need to register this Tensor on the VarMap right? But I don't see a way to do that, so I'm thinking I'm probably going about this the wrong way...
I want to be able to make a copy of a Sequential network and give everything a specific prefix because I use the prefix to register only that part of the network on an Optimizer like so:
fn filter_varmap_by_prefix(varmap: VarMap, prefix: &str) -> Vec<Var> {
    varmap.data().lock()
        .unwrap()
        .iter()
        .filter_map(|(name, var)| name.starts_with(prefix).then_some(var.clone()))
        .collect::<Vec<_>>()
}

let actor_optim = AdamW::new(
    filter_varmap_by_prefix(varmap.clone(), "actor-target"),
    ParamsAdamW {
        lr: actor_lr,
        ..Default::default()
    },
)?;

Along the way I'm also trying to translate this code over:
fn track(dest: &mut nn::VarStore, src: &nn::VarStore, tau: f64) {
    tch::no_grad(|| {
        for (dest, src) in
            dest.trainable_variables().iter_mut().zip(src.trainable_variables().iter())
        {
            dest.copy_(&(tau * src + (1.0 - tau) * &*dest));
        }
    })
}

So far I have something like this, but I need to insert a Var and not a Tensor into varmap..
let layers: Vec<Linear> = Vec::new();
for (i, (in_dim, out_dim)) in zip(1..=3, [(self.num_obs, 400), (400, 300), (300, self.num_actions)]) {
    let weight = vb.get((out_dim, in_dim), &format!("{source_prefix}-fc{i}.weight"))?.copy()?;
    let bias = vb.get(in_dim, &format!("{source_prefix}-fc{i}.bias"))?.copy()?;

    varmap.get((in_dim, out_dim), &format!("{target_prefix}-fc{i}.weight"), Default::default(), vb.dtype(), vb.device());

    varmap.data().lock().unwrap().insert(format!("{target_prefix}-fc{i}.weight"), weight).unwrap();
    varmap.data().lock().unwrap().insert(format!("{target_prefix}-fc{i}.bias"), bias).unwrap();

    let layer = Linear::new(weight, Some(bias));
    layers.push(layer)
}

Ah these very reinforcement learning specific workflows are certainly not well supported on candle at the moment, great time to polish this and make it easier :)
What I would suggest there is relying on the set method on variables which should be the equivalent of PyTorch copy_ (but only is available on Var and not on Tensor).
Do you think you would be able to implement track with this? Ideally you would have two varmap only and don't need to add new variables on each step but rather just copy the contents.
Your filter_varmap_by_prefix sounds good. Note that you can probably avoid a bit of cloning by using references and also rely on all_vars rather than data() would be simpler to extract the variables and then filter them.
Let me know if I can be of any more help (or if I misunderstood some of the difficulties you mentioned :) ).

Sorry for the pause, had to focus on work again for a few days. I'll be focusing again on this for the next few days.
I have a (very ugly) version of track going and it seems to work, and it seems like the weights are updating but (of course) it's not improving / learning correctly. Is there a way to check which variables are registered on an optimizer to sanity check that the rights things are being updated?

Also I just watched the bias of the last layer of the critic (which is a single float) update and change over time and then suddenly go from ~ -0.035.. to NaN, do you have an idea what could cause that?

Is there a way to check which variables are registered on an optimizer to sanity check that the rights things are being updated?

You can print the variables when passing them to the optimizers. That won't guarantee that they get updated though if the loss doesn't depend on them (or if there is a bug in candle). Maybe you can use a model that is simple enough so that you can just print the tensor values and check that they change?

It works!! I'll make a pull request in a bit

Oh I'm not sure what is going on with my pull request to be honest?

Yeah you may want to transplant your changes to the current git tip and make a clean one instead as it seems pretty odd.

Still seems odd right?
Then I will make a clean one...

Okay sorry about that! Now it should be fine

Closing this now that we have some RL example.


Remove/clear postFX's pixelate effect

Version

Phaser Version: 3.60-beta 21

Operating system: win10

Browser: chrome, firefox

Description
Test code,

Add then remove preFX 's pixelate effect works fine
Can add postFX's pixelate effect , but remove/clear seems not work. No error message shown.

Thank you for submitting this issue. We have fixed this and the fix has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.


Serverless setup

Hello,
Will this work in a serverless setup like Vercel or Cloudflare Workers? Any other requirements to make it support?

Yes, it will work there, but you should remember that some providers will limit the time that your code is running. This means that if the rate limit is too high, this plugin cannot work correctly.


2024 March Update: Updates from Sep2023 Branch, Typo fixes and improved reboot notify

Overall Review of Changes:

September 2023 Updates

Bug Fixes
Added Updated Discord Links
Updated Galaxy Score Links
Updated Readme
Control 18.2.6 - Fixed Spelling For Member server
Control 18.3.1 - Adjusted when statement for Member server only.
PR'S Closed
#37 - 9.2.1/9.3.1 Fixed Module Parameters in win_firewall - Thanks @gberginc
#37 - Section 18 Fixed Module Parameters in win_regedit - Thanks @gberginc
Reviewed all DC Only and MS Only Controls to verify when statements are valid.
Updated win_skip_for_test controls

August 2023 Updates

Updated to Central org based workflow.
Updated Linting files and ran against playbook
All modules fit FQCN standard.
Updated Readme.md

Issue Fixes:
#37
Enhancements:
Reboot Notify Enhancements
How has this been tested?:
Locally and Azure

Thank you @MrSteve81 !


Restrict access to application

This has been placed on hold. It should be reworked to provide access control for a GUI developed in the future. The API-only tools are going to be secured via a much simpler method of just needing an auth header.

Created proof of concept using a lambda authorizer with an API gateway. Next steps are:

Move the 'valid token' into SSM, if we are only going to authorizer a single allow-listed value
Add JWT validation and parsing, if needed


Result Screen Rating Color

colors of the rating results in the result list don't work as expected
Example: Purpurschwalbe
56% -> Yellow
50% -> green

resolved


Update CI and README.md to use the main branch

CI is not running for this PR because I've updated the config, it should be triggered once the master branch gets renamed

Could you also update the link at the top of lib.rs?

Good catch! Updated. Thanks.

@nnmm thanks for the prompt review :slightly_smiling_face:


[SPARK-18352][SQL] Support parsing multiline json files

What changes were proposed in this pull request?
If a new option wholeFile is set to true the JSON reader will parse each file (instead of a single line) as a value. This is done with Jackson streaming and it should be capable of parsing very large documents, assuming the row will fit in memory.
Because the file is not buffered in memory the corrupt record handling is also slightly different when wholeFile is enabled: the corrupt column will contain the filename instead of the literal JSON if there is a parsing failure. It would be easy to extend this to add the parser location (line, column and byte offsets) to the output if desired.
These changes have allowed types other than String to be parsed. Support for UTF8String and Text have been added (alongside String and InputFormat) and no longer require a conversion to String just for parsing.
I've also included a few other changes that generate slightly better bytecode and (imo) make it more obvious when and where boxing is occurring in the parser. These are included as separate commits, let me know if they should be flattened into this PR or moved to a new one.
How was this patch tested?
New and existing unit tests. No performance or load tests have been run.

Test build #70531 has started for PR 16386 at commit 7ad5d5b.

Hello recent JacksonGenerator.scala commiters, please take a look.
cc/ @rxin @hvanhovell @clockfly @hyukjinkwon @cloud-fan

Test build #70531 has finished for PR 16386 at commit 7ad5d5b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70531/
Test FAILed.

Merged build finished. Test FAILed.

the corrupt column will contain the filename instead of the literal JSON if there is a parsing failure

I am worried of changing the behaviour. I understand why it had to be here as you described in the description but we have input_file_name functions for these. I would not expect, at least, there are file names in _corrupt_record.
We need to document this around spark.sql.columnNameOfCorruptRecord in SQLConf and columnNameOfCorruptRecord in read/writer in Python and Scala if this is acceptable.

Why do we need this at all? just use wholeTextFiles and parse them as JSON.

@srowen It is functionally the same as what you're suggesting. The question is how (or if) it should it be first class in the DataFrameReader api. If we agree that it should be exposed, either via a new FileFormat or an option to JsonFileFormat, some abstraction is necessary to support reading from different RDD classes.
This PR just pushes that boundary a little further and let's the inference and parser code work over more types, not just String. This may make parsing more efficient in the line oriented codepath by avoiding a conversion from Text and UTF8String (in JsonToStruct) to String, and also lets us parse an InputStream without requiring all of the data to be in memory. For small files it's not likely to have a benefit (if the file is smaller than 4k it will be read entirely anyways) but as the file size increases this reduces the amount of memory required for parsing, is friendlier (in theory) on the GC and let's us consume files larger than 2GB.

Test build #70644 has started for PR 16386 at commit aa5a6db.

Test build #70644 has finished for PR 16386 at commit aa5a6db.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70644/
Test FAILed.

Merged build finished. Test FAILed.

@HyukjinKwon I agree that overloading the corrupt record column is undesirable and F.input_file_name is a better way to fetch the filename. It would be nice to extend this concept further and provide new functions (like F.json_exception) to retrieve exceptions and their locations, and this would work for the base case (parsing a string) as well as wholeFile. Plumbing this type of change through appears to require thread locale storage (unfortunately) but otherwise doesn't look too bad.
The question then is what to put in the corrupt record column, if one is defined, when in wholeFile mode. To retain consistency with the string paths we should really put the entire file in the column. This is problematic for large files (>2GB) since Spark SQL doesn't have blob support... so the allocations will fail (along with the task) and there is no way for the end user to work around this limitation. Functions like substr are applied to byte arrays and not file streams. Perhaps it's good enough to issue a warning (along the lines of "don't define a corrupt record column in wholeFile mode" and hope for the best?

The tests failed for an unrelated reason, looks to be running out of heap space in SBT somewhere.

Only regarding the comment, https://github.com/apache/spark/pull/16386#issuecomment-269386229, I have a similar (rather combined) idea that we provide another option such as corrupt file name optionally (meaning maybe the column appears only when user explicitly set for backwards compatibility), don't add a column by columnNameOfCorruptRecord with a proper documentation in wholeFile mode and issue a warning message if columnNameOfCorruptRecord is set by user in wholeFile mode. This is a bit complicated idea that might make users confused though. I am not sure if it is the best idea.

Test build #70730 has started for PR 16386 at commit 9dc084d.

@HyukjinKwon I just pushed a change that makes the corrupt record handling consistent: if a corrupt record column is defined it will always get the json text for failed records. If wholeFile is enabled a warning is emitted.
I think more discussion is needed to figure out the best way to handle corrupt records and exceptions, perhaps it can be shelved for now and we can pick it up later under another ticket?

Test build #70730 has finished for PR 16386 at commit 9dc084d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70730/
Test FAILed.

Can someone kick off the tests again? The last failure was in another module (Kafka).

Jenkins, retest this please

Test build #71147 has started for PR 16386 at commit 9dc084d.

Test build #71147 has finished for PR 16386 at commit 9dc084d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71147/
Test PASSed.

Any other comments?

cc @gatorsmile can you please take a look?

can we focus on supporting multiline json in this PR? We can leave the improvements in new PRs, or this PR is kind of hard to review.

Sorry, I missed the ping. Will review it tonight.

Hi @NathanHowell , do you have time to work on it? thanks!

Test build #72601 has started for PR 16386 at commit 6f8b0c3.

I rebased to master and hopefully addressed all of your comments @cloud-fan, please have another look.

Test build #72601 has finished for PR 16386 at commit 6f8b0c3.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72601/
Test FAILed.

Rebased again to pickup the build break hotfix in c618ccdbe9ac103dfa3182346e2a14a1e7fca91a

Test build #72603 has started for PR 16386 at commit 30fb509.

Test build #72603 has finished for PR 16386 at commit 30fb509.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72603/
Test PASSed.

Test build #72620 has started for PR 16386 at commit f71a465.

Test build #72620 has finished for PR 16386 at commit f71a465.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72620/
Test PASSed.

Test build #72685 has started for PR 16386 at commit aafe7bd.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72685/
Test FAILed.

Jenkins, retest this please.

Test build #72694 has started for PR 16386 at commit aafe7bd.

Test build #72694 has finished for PR 16386 at commit aafe7bd.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72694/
Test FAILed.

Test build #72726 has started for PR 16386 at commit 0f4686d.

Test build #72729 has started for PR 16386 at commit b0a5cc8.

@cloud-fan I just pushed a few more changes to address some of your comments. I'll be back later next week to continue work.

Test build #72726 has finished for PR 16386 at commit 0f4686d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72726/
Test FAILed.

Test build #72729 has finished for PR 16386 at commit b0a5cc8.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72729/
Test FAILed.

Test build #72975 has started for PR 16386 at commit 7296f7e.

Test build #72975 has finished for PR 16386 at commit 7296f7e.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72975/
Test FAILed.

LGTM if the test can pass. It will be good if you can also address https://github.com/apache/spark/pull/16386#discussion_r100679183

@cloud-fan When implementing tests for the other modes I've uncovered an existing bug in schema inference in DROPMALFORMED mode: https://issues.apache.org/jira/browse/SPARK-19641. Since it is not introduced in this set of patches I will open a new pull request once this is one merged. You can inspect the fix here: https://github.com/NathanHowell/spark/commit/e233fd03346a73b3b447fa4c24f3b12c8b2e53ae

Test build #73029 has started for PR 16386 at commit e323317.

Test build #73030 has started for PR 16386 at commit 58118f2.

Test build #73032 has started for PR 16386 at commit b801ab0.

Test build #73029 has finished for PR 16386 at commit e323317.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/73029/
Test PASSed.

Test build #73030 has finished for PR 16386 at commit 58118f2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/73030/
Test PASSed.

Test build #73032 has finished for PR 16386 at commit b801ab0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/73032/
Test PASSed.

thanks, merging to master!

@NathanHowell It sounds like we also can provide multi-line support for JSON too. For example, in a single JSON file
{"a": 1,
"b": 1.1}
{"a": 2, "b": 1.1}
{"a": 3, "b": 1.1}

When using the wholeFile mode, we only parse the first Json record {"a": 1, b": 1.1} but ignore the following records. It sounds like we should also parse them too and rename wholeFile to multiLine?

Yep, should be doable without too much effort.
On Sun, Jun 4, 2017 at 9:54 PM, Xiao Li<EMAIL_ADDRESS>wrote:

@NathanHowell https://github.com/nathanhowell It sounds like we also
can provide multi-line support for JSON too. For example, in a single JSON
file
{"a": 1,
"b": 1.1}
{"a": 2, "b": 1.1}
{"a": 3, "b": 1.1}
When using the wholeFile mode, we only parse the first Json record {"a":
1, b": 1.1} but ignore the following records. It sounds like we should
also parse them too and rename wholeFile to multiLine?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/spark/pull/16386#issuecomment-306102836, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKbTeYAiNRX7wtQDPt4NRvVgAbIcbSGks5sA4nvgaJpZM4LUihp
.


docs: Add recommended jar versions to run MongoToGCS template

MongoToGCS template does not work for some versions of required jars. Therefore, adding recommended jar versions for the template. This has been discussed with  @surjits254.

@SatpreetMakhija We can close this PR for now as we have another PR created from a feature branch


Use github wiki or github pages for the Guidelines?

Discussion moved here from #440.
A lot of things need to be added/revised in the Guidelines. Should we use the wiki here or github pages for the Guidelines. Is there a reason to prefer one over the other?

Benni said:

I don't think a wiki is a good place for the guidelines, at least in the sense of controlled versioning and tying the guidelines to a specific schema version. Although it might be in the sense of "contribution ease".
I don't know enough about the mechanisms of GitHub pages though…
Although this might ease contribution, I think we have to maintain the guidelines with the schema and publish a PDF version.

This is primarily a way to facilitate contributions.  But, I hope it would help with on-going maintenance too.  Also, I'm holding onto the hope that the markdown version can be machine-transformed into TEI (Lite or Tite?) for validation and publication on the web and as a PDF.
This change would also provide an opportunity to reorganize and rewrite the Guidelines in a more-accessible style.

For what it's worth, GitHub wiki pages can be 'cloned' and committed to, like any other git repo. This would be very useful for a bulk upload of the existing guidelines.
It may be a big problem, though, that the guidelines would no longer be in TEI. Once we put it in markdown and get people editing it, we probably won't be able to easily put it back into TEI. Personally, I'm OK with that, but others may not be.

Also -- documentation versioning would be tricky. How do you show the guidelines for v3.0 once 4.0 has been released? And how do you maintain the links in the prose of the guidelines with the element definitions?

I'm not exactly certain of the process or the terminology, but since GitHub wiki pages can be treated like another repo, I assume that any given state of the guidelines could be marked/tagged as "released". The guidelines for v 3.0 would be available via its own, unique URL, as would 4.0.  In addition, once the markdown is converted to TEI, that file could also be part of a release, couldn't it?
What I'm imagining is the same process we have in place now -- the TEI text documentation and schemaSpec, filtered through a stylesheet (TEI now, but perhaps something else later), become an HTML document (for web browsing and generation of the PDF) -- but with the addition of a markdown "front-end".  That is, the markdown files (one for each section/chunk/page of the documentation) are transformed into the textual part of the Guidelines.  Additional hand or mechanical editing might be necessary at this stage, but I hope it would be minimal.  The biggest problem, as you point out, is the creation and maintenance of links between "pages".  But there's a mechanism for that in markdown, which could be transmogrified into TEI, couldn't it?
If we're not able to access older versions of the Guidelines from within GitHub itself, then we could at least maintain the generated HTML and PDF versions on music-encoding.
Maybe it's a pipe dream ...

Sure. But let's say someone comes along and does a cleanup of the guidelines on the wiki -- after all, that's what a wiki is for, so that we can allow more people to edit and contribute.
So it's not just a one-way street. We'll need to then be able to back-convert the markdown pages to TEI if we want to keep the TEI versions of the guidelines.

Markdown -> TEI -> HTML -> PDF is still a one-way street, isn't it, no matter when or how many times you traverse it?
Perhaps a silly question -- where are the markdown-encoded wiki pages actually stored?
Another question, can we trigger the Markdown -> TEI process on commit of the wiki page?  If so, then we can always keep the TEI pages/files in sync with the wiki.
The major issue, of course, is assembling the collection of TEI files (via external parsed entities or XInclude) into one big TEI document.  But, if there's an index page in the wiki that contains only pointers to the pages with actual content, then that page can be used as a "driver" in which the pointers are replaced by the content of the referenced files, right?

The system I am using for VHV documentation is fairly easy for general user editing of content:
http://doc.verovio.humdrum.org
Here is a page mostly edited by someone else after I set it up:
http://doc.verovio.humdrum.org/filters/dissonant
which I think is being edited via the Github online editor.
Notice that on this page and most other pages in the VHV documentation, there is an edit button at the bottom of the page:

Clicking on the button takes you to the page where the markdown file is located on Github, and then you can press the edit button to edit online:
https://github.com/humdrum-tools/vhv-documentation/edit/gh-pages/filters/dissonant/index.md

To edit, a person has to have a Github account.  People outside of the repository can submit a change for review; otherwise, changes can be saved and the page is rebuilt on Github pages within 10 minutes (typically less than a minute).
The VHV documentation is based on this Jekyll template:
http://idratherbewriting.com/documentation-theme-jekyll
This template has a search feature built into it:
http://idratherbewriting.com/documentation-theme-jekyll/mydoc_search_configuration.html
And a method of converting the website into a PDF:
http://idratherbewriting.com/documentation-theme-jekyll/mydoc_generating_pdfs.html
although I have not be interested in this, so no PDFs of VHV documentation.
Another useful feature to note is that the dissonant tool documentation:
http://doc.verovio.humdrum.org/filters/dissonant
displays notation generated from verovio automatically in the browser when the page is loaded.  For example this music notation:

Is generated by the text:
{% include verovio.html
	humdrum-visible="false"
	source="passing"
	scale="50"
	pageWidth="1000"
	tabsize="10"
%}
<script type="application/x-humdrum" id="passing">
**kern	**kern
*M2/4	*M2/4
4C	8cL
.	8dJ
4AA	4e
=2	=2
4FF	8fL
.	8eJ
4GG	4d
=	=
*-	*-
!!!filter: dissonant
</script>

"verovio.html" is a liquid template file:
https://github.com/humdrum-tools/vhv-documentation/blob/gh-pages/_includes/verovio.html
which takes the above text and transforms it into an SVG image with verovio.

"Markdown -> TEI" will be a pretty fraught process, since it will involve "upconverting" (introducing semantic tags into what is, essentially, a markup language). It's better to skip TEI altogether: Markdown -> PDF for example. Markdown -> HTML is the most standard use, so there is no problem there.
I see TEI as being the biggest barrier to entry for contributing to the guidelines. Moving it to Markdown will almost certainly help remove that barrier.

but how will a markdown data entry process be integrated into the schema generation? Aren't there dependencies of the schema to the documentation?

Aren't there dependencies of the schema to the documentation?

The RNG schema and the Elements, Attributes, Model Classes, and Data Types pages are generated from the <schemaSpec> portion of the full TEI file.  There are no dependencies between the <schemaSpec> and the prose portions of the Guidelines.
So, we can separate the generation of the schema from that of the prose.  Schema generation could be handled using the TEI stylesheets and the prose could all be in markdown.

There are auto-generated links between the guidelines and the spec, though. It would need to be tested whether we could control those links or if they're done automagically in the documentation generation process.

At this point, we have links going from the guidelines to the spec only, but not the other direction – something we should take care of anyway.
Since I wrote the current transformations for both HTML and PDF outputs for the guidelines (including specs), I think I know them quite a bit. Since it's possible to convert markdown to angle brackets, it should be fairly straightforward to adjust the existing pipeline to support markdown input. After all, it's just another level of abstraction ;-)

Am 08.08.2017 um 21:43 schrieb Andrew Hankinson<EMAIL_ADDRESS>There are auto-generated links between the guidelines and the spec, though. It would need to be tested whether we could control those links or if they're done automagically in the documentation generation process.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

At this point, we have links going from the guidelines to the spec only, but not the other direction – something we should take care of anyway.
mentioned in in #394 and created separate issue #450

Since it's possible to convert markdown to angle brackets, it should be fairly straightforward to adjust the existing pipeline to support markdown input.

Would that also allow editing the TEI or would we then have the markdown as single entry point?

We have created a new repo, music-encoding/guidelines, a Jekyll site that will host the new guidelines.  We will be deprecating the old ODD-based guidelines. It's currently in a state of conversion, and help is definitely appreciated.
I will close this issue, but feel free to comment.


Update installation instructions

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Let's remove those en-us/ bits, while we're at it?


Implements color matrices, allows /atom.color to be set with one

Summary
This was supposed to be me doing something very simple to dip my toes into the graphics side of this project, but lucky for me, this has been a total trap. After a few days of losing my mind, here's something that only works with novel RT code.
Changelog

Setting /atom.color to a color matrix now works.
The color filter (instantiated by filter(type="color",..) now works.

minor bug found: setting color to a matrix and then setting filters seems to delete the color matrix filter.
/obj/thing
    color = list(null, null, null, "#0000", "#333f")

    New()
        src.filters = filter(type="alpha", render_source="button")```

minor bug found: setting color to a matrix and then setting filters seems to delete the color matrix filter.
/obj/thing
    color = list(null, null, null, "#0000", "#333f")

    New()
        src.filters = filter(type="alpha", render_source="button")```

I've pretty much come to the conclusion that "color" will have to be treated very specially by filter() to handle the fact that it's implicitly also interfaced with by /atom.color

PR should be Ready:tm:

Setting a color on /turf's definition like
/turf
	color = matrix(1,0,0,0,1,0,0,0,1)

causes a lot of this error to spam:
=DM StackTrace=
   /atom/<init>
   new /turf
2

=C# StackTrace=
System.Collections.Generic.KeyNotFoundException: The given key '4294967295' was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at OpenDreamRuntime.Rendering.ServerAppearanceSystem.MustGetAppearance(UInt32 appearanceId) in /home/amy/OpenDream/OpenDreamRuntime/Rendering/ServerAppearanceSystem.cs:line 50
   at OpenDreamRuntime.DreamMapManager.MustGetTurfAppearance(DreamObject turf) in /home/amy/OpenDream/OpenDreamRuntime/DreamMapManager.cs:line 196
   at OpenDreamRuntime.AtomManager.UpdateAppearance(DreamObject atom, Action`1 update) in /home/amy/OpenDream/OpenDreamRuntime/AtomManager.cs:line 88
   at OpenDreamRuntime.Objects.MetaObjects.DreamMetaObjectAtom.OnVariableSet(DreamObject dreamObject, String varName, DreamValue value, DreamValue oldValue) in /home/amy/OpenDream/OpenDreamRuntime/Objects/MetaObjects/DreamMetaObjectAtom.cs:line 129
   at OpenDreamRuntime.Objects.MetaObjects.DreamMetaObjectTurf.OnVariableSet(DreamObject dreamObject, String varName, DreamValue value, DreamValue oldValue) in /home/amy/OpenDream/OpenDreamRuntime/Objects/MetaObjects/DreamMetaObjectTurf.cs:line 26
   at OpenDreamRuntime.Objects.DreamObject.SetVariable(String name, DreamValue value) in /home/amy/OpenDream/OpenDreamRuntime/Objects/DreamObject.cs:line 111
   at OpenDreamRuntime.Procs.DMProcState.AssignReference(DMReference reference, DreamValue value) in /home/amy/OpenDream/OpenDreamRuntime/Procs/DMProc.cs:line 538
   at OpenDreamRuntime.Procs.DMOpcodeHandlers.Assign(DMProcState state) in /home/amy/OpenDream/OpenDreamRuntime/Procs/DMOpcodeHandlers.cs:line 27
   at OpenDreamRuntime.Procs.DMProcState.Resume() in /home/amy/OpenDream/OpenDreamRuntime/Procs/DMProc.cs:line 297
   at OpenDreamRuntime.DreamThread.Resume() in /home/amy/OpenDream/OpenDreamRuntime/DreamThread.cs:line 231```

Is it actually valid to set color with a 3x3 matrix (as in, via matrix()) in BYOND? The BYOND ref seems to imply it's not supported.

You are correct, it should be a list(), but also the error is still the same. Also also we should probably compile error on invalid color setting like that.


Processes Merged By Object from Merge Request Response

Include Merge By from Merge Request Response json returned by Gitlab.

Codecov Report

Merging #163 into master will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #163      +/-   ##
==========================================
- Coverage   70.84%   70.81%   -0.03%
==========================================
  Files         170      170
  Lines        2367     2368       +1
==========================================
  Hits         1677     1677
- Misses        690      691       +1

Impacted Files
Coverage Δ

...ent/Models/MergeRequests/Responses/MergeRequest.cs
82.14% <0.00%> (-3.05%)
:arrow_down:

@nmklotas I've ran the dotnet format on my machine and there were no changes to the files. Is there a specific config required?


Add custom scrollbar

Describe your issue here in detail or in short also mention your where you found the issue...
Add custom scrollbar in the application to make it more attractive.

which type of scrollbar are you talking about ?

Something like this.

Yea ok go for it but make sure you use materialized css components and match it according to the theme

#40 done with the issue


Query parameter example values are used as default values

The example values are used as default values with query parameters in swagger ui. The example value is useful in the help text, but when actually trying to make a request it might provide illegal values when the example contains multiple different examples

This is unfortunately solely in the Swagger UI itself. As seen in the picture, I have only set example and it is also used as a default value for parameters. Perhaps Swagger UI configurations has a flag to turn this behavior off but I would not raise hopes too high.

Ok, thx for the input

what means? the utoipa does not support to generate query param default value?


Update install.md

add ./app prefix in order to install deps.

Thank you. We have added your pull request to version 0.5.0 of the EUDIW Issuer.


[Chore] Remove DISCLAIMER file

Purpose of this pull request
This PR remove DISCLAIMER file cause SeaTunnel is TLP now.

Does this PR introduce any user-facing change?
no

How was this patch tested?
unnecessary.

Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

@CalvinKirs @kezhenxu94 Could you help to review this? Thanks.


Add labels for partners

For certain projects, we need  a way to label one partner as "partner A" and the other as "partner B". Is there a way to do that on the website?

We were not able to assign per-partner scores this semester. I think we need this feature to grade accurately.

The front-end is ready. Here is the UI for students:

We could run into problems, if students were to switch arbitrarily and get credit for another partner's work. So:

At the most basic level, we lock the order if the assignment deadline has passed.

To prevent unfairness while the assignment is live, we could do one or more of the following:
a. lock 24 hours before it is due
b. require confirmation for switch <- this would be unnecessarily ugly though - it would be as, if not more, complicated than group invitations
c. allow only the invitation-issuer to switch order

@soumyabasu What do you think? I'm going to implement 1 and 2a, right now, in case we don't think of anything better.

Implemented. Order is locked after deadline passes. (Gray is an assignment past due date)

That's nifty!
On Wed, Jun 17, 2015 at 11:27 AM, Alvin Wan<EMAIL_ADDRESS>wrote:

Implemented. Order is locked after deadline passes. (Gray is an
assignment past due date)

[image: site-partner-lock]
https://cloud.githubusercontent.com/assets/2068077/8215263/b7709c48-14e3-11e5-8128-c7908c4b4540.gif
—
Reply to this email directly or view it on GitHub
https://github.com/Cal-CS-61A-Staff/ok/issues/252#issuecomment-112904487
.

(I, like John, love how it looks! XD)
The main issue I have with locking things is people will inevitably forget to add their partners and many other issues that will need to be taken care of manually by some staff member. I think these issues should be resolved by the lock_date, after which no submissions could be automatically uploaded to OK. So, I think the solution here is to lock partner reordering after the lock_date. (I'm fine with locking any group modifications after the lock date tbh.)
For unfairness while the assignment is live, I think the 'right answer' technically is to have both parties approve the order change. However, in practice that probably won't work out very well since it'll be another round of invitations for them to accept. Since one group member being unfair to another is an issue that will probably end up requiring TA support or the group breaking up, we should probably just leave it alone and assume that both parties are trustworthy.

I agree. I think we should, in general, assume that the students are trustworthy, but make sure that we have a way to deal with them being sneaky, or whatever. I think we've spent a lot of engineering effort thinking about "security issues" which probably haven't even popped up. Or, have they? I'm not sure. I just know we had a lot of these discussions where we were worried about students trying to game the system or whatever. Did stuff like this happen in the past?

Most of the security issues have happened at least once and they've gotten caught/handled. But I agree entirely with your general motto of 'assume trustworthiness, but make sure that we can deal with sneakiness'.


Multiple Frame Creation

Whats the process of automating extracting multiple frames?
i only see this option through use of time code
$video->frame(\FFMpeg\Coordinate\TimeCode::fromSeconds(10))->save('frame-10.jpg');

What do you exactly mean with "automating extracting multiple frames"?

I mean every seconds extract frames
exec('/usr/local/bin/ffmpeg -i "video.mp4" -vf fps=1/60 capture/img%03d.jpg');


Fix maven publish plugin for datacapture module and add source jar to engine module

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #307 #391
Description
Maven publish module does not work for the datacapture module after the kotlin migration due to missing group ID and version. The datacapture module release also misses the source jar.
This PR also adds source jar to the engine module release.
Alternative(s) considered
N/A
Type
Bug fix
Screenshots (if applicable)
N/A
Checklist

[x] I have read and acknowledged the Code of conduct
[x] I have read How to Contribute
[x] I have read the Developer's guide
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally
[x] I have built and run the reference app(s) to verify my change fixes the issue and/or does not break the reference app(s)

One more problem(regression) I discovered last night, that with #364, inadvertently we bumped our agp to 4.2.0-beta06 from beta02. Apologies from my side for committing that error and pushing : (
In our current master branch:
https://github.com/google/android-fhir/blob/1e9fe1c4219d38ae547bb82d8fca6d0c256a7ce6/buildSrc/src/main/kotlin/Plugins.kt#L37
Previously(a commit in repository ~29 days back):
https://github.com/google/android-fhir/blob/80a9de1813df8ba95c7413a2e13f96e73d41afb2/deps.gradle#L16

@s-ayush2903 that's ok. it's not ideal at the moment our gradle plugin version is beta. rather than downgrading, we'll just wait till 4.2.0 is stable and move to the stable versions.


molecule: 6.0.1 -> 6.0.2

Description of changes

https://github.com/ansible/molecule/releases
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg eval

Result of nixpkgs-review pr 252322 run on x86_64-linux 1

4 packages built:

molecule (python310Packages.molecule)
molecule.dist (python310Packages.molecule.dist)
python311Packages.molecule
python311Packages.molecule.dist


Using "wallet balance"，error: JSON-RPC error: RPC error response: RpcError { code: -18, message: "Wallet file verification failed.

im trying to do this：ord --bitcoin-data-dir "D:\BtcData\blocks" --cookie-file "D:\BtcData.cookie" --data-dir "D:\OrdData" wallet balance
error: JSON-RPC error: RPC error response: RpcError { code: -18, message: "Wallet file verification failed. Failed to load database path 'D:\\BtcData\\ord'. Data is not in recognized format.", data: None }
i do not set anything about RPC in bitcoin.conf file，need help!!!
Thanks！

Hi - a much quicker resolution is waiting for you and others having issues like these on the Ordicord.  Please consider closing this and instead posting in the tech-support channel.  https://discord.gg/fwTTXMGJ


AK1001 - giving wrong code fix and warning? when using with ReceiveAsync?

Version Information
Version of Akka.NET? 1.5.15
Which Akka.NET Modules? Akka.Analyzers
Describe the bug
When using Akka.Analyzers I now see the following warning (which in our solution turns into an error because we threat warnings as errors).

The code fix however suggests the following 'fix'. But outside the ReceiveAsync (in the constructor of my actor in this case) I don't have a valid Sender. So this code fix is wrong IMO (please explain if I'm wrong).

Expected behavior
I expect that this is the correct way to fix it:

Additional question is (if I need to create a separate issue for this, please let me know), why is this wrong?

As I've been using this over the past years on a lot of places and it always was working fine. We however always await tasks in our actors and never do async work in our actors which we don't await.

Hi @wesselkranenborg - this the ReceiveAsync is what I think is throwing this off. We should probably have a separate warning for telling users not to use ReceiveAsync if they aren't actually await-ing anything (it creates extra overhead.)
However, you are also correct that the code fix here is incorrect - it's not reasoning about the method body correctly in this instance. We need to fix that.

Also @wesselkranenborg, you code is fine - minus the bit I said about the perf hit using ReceiveAsync instead of Receive when you're not performing any awaits.

And we might thus break the actor model?

Not breaking the actor model, just slightly lower performance.

Your first example would be flagged with a warning if we implemented https://github.com/akkadotnet/akka.analyzers/issues/57
Your second example is fine and should not be flagged by AK1001 (is it being flagged currently?)
Your third example will be flagged by AK1001 unless you close over the Sender property, which the code fix will do automatically (and @Arkatufus fixed it so this is now done correctly.)


[Feature request]: E340 "Enable Floodlight" not to be confused with Light On

Describe the solution you'd like
Would it be possible to add enable/ disable to the Floodlight for the E340. There are times when we are in the backyard when we still need recording of activity at the pool but dont need the flood. It would be great if I could turn off the floodlight when say our pool pump is on via a Homeassistant automation or motion activated illumination toggle if motion and pool is on turn off flood.  The option is under E340 "Light Settings"  Enable Floodlight which is different than light "On"

The option is under E340 "Light Settings" Enable Floodlight which is different than light "On"

This functionality is already available (property lightSettingsEnable).


Window number slightly off

Hi there!
This may be an issue with my font (using FiraCode Nerd Font), but I've noticed that the window number is slightly off and shows almost like a box around it (see below). Any idea why that may be like that? Thanks!

Relevant tmux.conf part:
set -g @catppuccin_window_left_separator "█"
set -g @catppuccin_window_right_separator "█ "
set -g @catppuccin_window_number_position "right"
set -g @catppuccin_window_middle_separator "  █"

set -g @catppuccin_window_default_fill "number"

set -g @catppuccin_window_current_fill "number"
set -g @catppuccin_window_default_text "#W"
set -g @catppuccin_window_current_text "#W"

set -g @catppuccin_status_left_separator  ""
set -g @catppuccin_status_right_separator " "
set -g @catppuccin_status_right_separator_inverse "yes"
set -g @catppuccin_status_fill "all"
set -g @catppuccin_status_connect_separator "no"```

hi @carter-twi this problem is with how the terminal renders fonts. Here is a better explanation: https://github.com/romkatv/powerlevel10k#sub-pixel-imperfections-around-powerline-symbols
In this case the space between the number and the left or right separator is a unicode character making the number look off.

Thanks for the link. I greatly appreciate it.


Overview: define OTLP on first use?

Refering to diagram on main page https://opentelemetry.io/docs/
Short form OTel is explained in text and used in diagram, BUT
OTLP (guessing OpenTelemetryProtocol) is only used in diagram but not introduced for the reader.

Thank you for raising this @kDot. Do you have yourself any suggestions how to improve? Feel free to provide it via a PR

I did not want to come up with a solution but rather want to point out a very minor issue. But as you have asked for PR, here we go..
I could have added OTLP into the textual representation but as i am a fan keep things simple, i just removed the OTLP from the arrows in the svg.
The term is still introduced in the documentation quite early (https://opentelemetry.io/docs/what-is-opentelemetry/).


fix: display data card

Description

Display the data_card in a simple manner for now.

Resolves #1888

@blanchco could you show me how you did the document selection (provenance)?


chaos(engine): fix etcd-endpoints for servermaster

What problem does this PR solve?

Issue Number: close https://github.com/pingcap/tiflow/issues/6511
What is changed and how it works?
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
None

/hold
Wait https://github.com/gozssky/tiflow/actions/runs/2753060449 to pass.

Codecov Report

Merging #6512 (5c2066c) into master (f0e21a6) will increase coverage by 6.1083%.
The diff coverage is 68.5446%.

Flag
Coverage Δ

cdc
66.1389% <67.2500%> (+0.0618%)
:arrow_up:

dm
?

engine
63.6943% <70.7113%> (-0.4066%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #6512        +/-   ##
================================================
+ Coverage   59.4618%   65.5702%   +6.1083%
================================================
  Files           762        523       -239
  Lines         87377      47822     -39555
================================================
- Hits          51956      31357     -20599
+ Misses        30815      13986     -16829
+ Partials       4606       2479      -2127

Test passed. See https://github.com/gozssky/tiflow/runs/7559346443.

/unhold
/merge

/run-all-tests


Diff of builds

Hi, please find the diff of builds. Let me know what you think? I thought this seemed a good checkpoint - everything seems to work.
Next step will be to add a diff of the artifacts size / files added/removed to the build diff screen

Hi, I've failed to make it work. No js errors in browser console or exceptions on server side.

It also better not to use the same javascript object names BS.AgentsDiff for both features. So please split it to BS.BuildsDiff and BS,AgentsDiff.

Sure, will look through and ensure the naming is consistent. I will test it
out on a few other teamcity instances to try and catch any edge cases.
On Sunday, 11 September 2016, Evgeniy Koshkin<EMAIL_ADDRESS>wrote:

It also better not to use the same javascript object names BS.AgentsDiff
for both features. So please split it to BS.BuildsDiff and BS,AgentsDiff.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ekoshkin/teamcity-build-agents-diff/pull/8#issuecomment-246170898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxEiNtsGgDyo5Puy-sXuDG4xbDqo8-zks5qo8oEgaJpZM4J5p1J
.

"build types chooser redirects to empty page"  - can you put the
chrome inspector on and on console click preserve log. Keen to know which
url it tries to redirect to.

To be fair that bit is a tad clunky as I couldn't find a way to get the
ajax updater to re-evaluate the list of available builds once it had been
selected. The first two points are fair, although comparing to yourself and
seeing no differences is a nice control.
I will keep whittling away at it to get it simpler and more robust. Will
ping you once I think it's ready.
On Tue, Sep 20, 2016 at 8:51 PM, Evgeniy Koshkin<EMAIL_ADDRESS>wrote:

@ekoshkin commented on this pull request.
unfortunatly build diff doesn't work for me
i've made a simple setup with two build configurations and couple of build
in each
it never shows me diff, every time there is a message "Please choose a
build to compare with."
There are several other issues i've found

there are duplicates in the list of build types, current build
configuration is shown two times
currebt build is not excluded from the list of compare to builds
build types chooser redirects to empty page

I use chrome latest version
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ekoshkin/teamcity-build-agents-diff/pull/8#pullrequestreview-826141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxEiM7wEXse4JDEK6v6YFnYNAmzUmiCks5qsDkvgaJpZM4J5p1J
.


ocm: Add aliases for local development

This ensures that developers and contributors can use the full flow of
commands necessary for STS cluster requirements.

/lgtm


Image build fails on installing python-base

I have rebased recently and make build fails for me with an error message:
Failed to init/update submodules: Submodule 'kubernetes/base' (https://github.com/TomasTomecek/python-base) registered for path 'kubernetes/base'
Cloning into '/tmp/ansible.P3kbWB/kubernetes/base'...
error: Server does not allow request for unadvertised object 42fa54406a00fda0fb2723da0fcfc95ff4b4a2d0
Fetched in submodule path 'kubernetes/base', but it did not contain 42fa54406a00fda0fb2723da0fcfc95ff4b4a2d0. Direct fetching of that commit failed.

my bad

I fixed it by pointing my fork to a proper submodule & commit hash:
Successfully built 78009293faa0

Please try to rebuild (no need to rebase).

Thanks! now it works.


ERROR:ceph-osd : manually prepare ceph "filestore" non-containerized osd disk(s) with collocated osd data and journal

when I ansible-playbook -vvv site.yml -i hosts
Error:TASK [ceph-osd : manually prepare ceph "filestore" non-containerized osd disk(s) with collocated osd data and journal]
"start": "2018-04-20 15:14:31.653003",
"stderr": "usage: ceph-disk [-h] [-v] [--log-stdout] [--prepend-to-path PATH]\n                 [--statedir PATH] [--sysconfdir PATH] [--setuser USER]\n                 [--setgroup GROUP]\n                 \n                 {prepare,activate,activate-lockbox,activate-block,activate-journal,activate-all,list,suppress-activate,unsuppress-activate,deactivate,destroy,zap,trigger,fix}\n                 ...\nceph-disk: error: unrecognized arguments: --filestore",
"stderr_lines": [
"usage: ceph-disk [-h] [-v] [--log-stdout] [--prepend-to-path PATH]",
"                 [--statedir PATH] [--sysconfdir PATH] [--setuser USER]",
"                 [--setgroup GROUP]",
"                 ",
"                 {prepare,activate,activate-lockbox,activate-block,activate-journal,activate-all,list,suppress-activate,unsuppress-activate,deactivate,destroy,zap,trigger,fix}",
"                 ...",
"ceph-disk: error: unrecognized arguments: --filestore"
],
"stdout": "",
"stdout_lines": []
}
I read it /ceph-ansible/ceph-ansible-3.0.0/roles/ceph-osd/tasks/scenarios/collocated.yml,
find  command: "ceph-disk prepare {{ ceph_disk_cli_options }} {{ item.1 }}"
there is no filestore
I dont unstand it ?
and I look for webiste http://docs.ceph.com/docs/hammer/man/8/ceph-disk/ and not find filestore .
so why?

Your doc links Hammer, are you trying to deploy Hammer?

This problem is  solved. I think its cause from .repo  My repo is no have L version.

Glad you solved your issue.


proposal: errors: As with type parameters

Currently in 1.18 and before, when using the errors.As method, an error type you would like to write into must be predeclared before calling the function. For example:
var myErr *MyCustomError
if errors.As(err, &myErr) {
  // handle myErr
}

This can makes control flow around handling errors "unergonomic".
I'd propose that a new, type parameterized method be added to the errors package in 1.19:
func IsA[T error](err error) (T, bool) {
	var isErr T
	if errors.As(err, &isErr) {
		return isErr, true
	}

	var zero T
	return zero, false
}

This enables more "ergonomic" usage as follows:
err := foo()
if err != nil {
	if myErr, ok := errors.IsA[*MyCustomError](err); ok {
		// handle myErr
	} else if otherErr, ok := errors.IsA[*OtherError](err); ok {
		// handle otherErr
	}

	// handle everything else
}

instead of
err := foo()
if err != nil {
	var myErr *MyCustomError
	if errors.As(err, &myErr) {
		// handle customer error
	}

	var otherErr *OtherError
	if errors.As(err, &otherErr) {
		// handle other error
	}

	// handle everything else
}

This change would reduce the overall LOC needed for handling custom errors, imo improves readability of the function, as well as scopes the errors to the if blocks they are needed in.
Naming is hard so IsA might be better replaced with something else.

Interesting, but changing the signature of errors.As is not a backwards compatible change.
It will have to be a new function.

CC @jba @neild
(My vague recollection is that this was considered and rejected when errors.As was introduced, even beyond the fact that at the time type parameters did not yet exist.)

@rsc made the case in the original proposal issue that a type-parameterized version of errors.As would not be an improvement:
https://github.com/golang/go/issues/29934#issuecomment-490091428
@dsnet also pointed out that the non-type-parameterized version of As can be used in a switch, while the type-parameterized one cannot:
https://github.com/golang/go/issues/29934#issuecomment-460093518
I don't recall if there were any other arguments against a type-parameterized As (aside from, obviously, the fact that type parameters didn't exist at the time).
I personally think that a type-parameterized As seems fairly reasonable, although the practical benefit over the current As seems small. It would need a good name. I don't know what that name would be. IsA does not seem right. Under the current design, "Is" is an enhanced form of equality and "As" is an enhanced form of type assertion; blurring that distinction would add confusion.
An argument against adding a type-parameterized As is that the benefit does not justify the cost in API churn and user confusion. I don't have a strong opinion on whether the benefits do outweigh the costs.

I personally think that a type-parameterized As seems fairly reasonable, although the practical benefit over the current As seems small. It would need a good name. I don't know what that name would be. IsA does not seem right. Under the current design, "Is" is an enhanced form of equality and "As" is an enhanced form of type assertion; blurring that distinction would add confusion.

AsA() could work, though it's a little oddly close to the existing one. if pe, ok := errors.AsA[*os.PathError](err); ok { ... } reads pretty well to me, though it should technically be 'an *os.PathError', not 'a'.
New proposal: Automatically alias all functions with names that match ([a-z0-9])A$ to ${1}An.

I like this proposal, but I fell the call errors.IsA[*MyCustomError](err) is not very natural.
If would be good if we could pass type arguments to unnamed value parameters (_) of type parameter types.
For example,
func IsA[T error](err error, _ T) (T, bool) {
	var isErr T
	if errors.As(err, &isErr) {
		return isErr, true
	}

	var zero T
	return zero, false
}

err := foo()
if err != nil {
	if myErr, ok := errors.IsA(err, MyCustomError); ok {
		// handle myErr
	} else if otherErr, ok := errors.IsA(err, OtherError); ok {
		// handle otherErr
	}

	// handle everything else
}

Or more generally, it would be good to pass type arguments to any value parameters of type parameter types.
It is equivalent to pass zero values of the type arguments.

I don't see much benefit to duplicating the existing API. This also implies a similar change to eg json.Marshal etc. We would end up with duplicate functions throughout the standard library. And as noted this doesn't add any type safety; it is just more convenient, although even that is debatable. I think generics should be reserved for areas where they either add real type safety or big convenience, and cases like this of minor convenience can stay as they are.

And as noted this doesn't add any type safety

That's not quite true: This does add type safety at the language level, rather than leaving it to a go vet check. Under this proposal, this code would not be valid:
type MyError struct{}
func (*MyError) Error() string { return "MyError" }

func main() {
	var err error
	m, ok := errors.AsA[MyError](err) // MyError does not implement error (Error method has pointer receiver)
	fmt.Println(m, ok)
}

The equivalent errors.As call is a run-time panic or go vet failure:

second argument to errors.As must be a non-nil pointer to either a type that implements error, or to any interface type

A sidenote is the original error inspection draft design includes this blurb:

Here we are assuming the use of the contracts draft design to make errors.As explicitly polymorphic:
func As(type E)(err error) (e E, ok bool)

so its not I guess a new idea

Love this, I stumbled across this pattern, made a quick blog post about it. Then, of course, that is when I find all the proposals 😂.
I think you can get it down to this terse definition:
func AsA[E error](err error) (e E, _ bool) {
    return e, errors.As(err, &e)
}

There are a few benefits of having a generic version of As, that I don't think have been brought up here.
I mentioned them in: https://github.com/golang/go/issues/56949
User @Jorropo writed the function this way:
func AsOf[E error](err error) (E, bool) {
	var ptrToE *E
	for err != nil {
		if e, ok := err.(E); ok {
			return e, true
		}
		if x, ok := err.(interface{ As(any) bool }); ok {
			if ptrToE == nil {
				ptrToE = new(E)
			}
			if x.As(ptrToE) {
				return *ptrToE, true
			}
		}
		err = Unwrap(err)
	}
	var zero E
	return zero, false
}]

Note that it does not use the current As implementation.
The benefits of this implementation are:

No usage of reflection
No runtime panic possibility
An allocation free path
Compile time type safety

All of these proposals are looking for a way to return the error as a specific type, which I agree is nice if possible, but have there been any discussions around simply improving errors.As with generics? Specifically:
func As[T error](err error, target *T) bool {
	return errors.As(err, target)
}

At first glance this appears to be a breaking change, but passing anything that doesn't meet this criteria into the As function would result in a panic. This change would alert people of the issue sooner (during compile time) rather than at runtime.
It is also very possible I am missing an edge case.
I have looked, but haven't found an issue that discusses this approach, but please let me know if one exists.

At first glance this appears to be a breaking change

This would break the following:
var _ = errors.As

This would break the following:
var _ = errors.As

Darn, you are right. I missed that case. Kinda sucks though, because the change would absolutely reduce bugs that aren't discovered until testing (or some other runtime occurrence).

#64629 was closed as duplicate, so let me advertise my idea here. Perhaps, instead of adding new IsA function, it would be easier to add something that actually produces that double pointer? Like this:
func AsTarget[T error](err T) **T {
	p1 := &err
	p2 := &p1
	return p2
}

Then we could:
if errors.As(err, AsTarget(MyErr)) {
    ...
}

You couldn’t use the value, so it seems like it wouldn’t be useful most of the time.

Oooh, okay, now I get it. I'm new to go, and I didn't RTFM, so that's on me. I missed the fact that error.As actually sets the target to the value of the error it finds (if it finds it). My idea still holds when one doesn't need that value (which is rare, probably) and makes little sense in a wider context.
Learned something today, thanks @carlmjohnson.

@mkielar: If you do not need value, you use errors.Is.

Per (closed) duplicate proposal #64771, I advocate for the name errors.Has. Implementation would look like:
// Has returns true if err, or an error in its error tree, matches error type E.
// An error is considered a match by the rules of [errors.As].
func Has[E error](err error) bool {
  return errors.As(err, new(E))
}

A) It's an Is check, not really an As check, which is less useful. B) That would be very prone to accidental misuse in which the type system would infer error instead of a concrete error type.

  err = container.RunExec(ctx, s.dockerCli, target.ID, exec)
  if errors.Has[*cli.StatusError](err) {
    return sterr.StatusCode, nil
  }
  return 0, err

sterr.StatusCode won't work because sterr is never declared.

Until this gets into the stdlib, I'm using a simple wrapper around the whole errors package: https://pkg.go.dev/github.com/imax9000/errors

In our codebase, we've noticed the need for two different methods:

func AsA[E error](err error) (E, bool)
func IsA[E error](err error) bool

AsA can generally be used everyone IsA is used by ignoring the first return value, except for switch statements. The value of IsA is that it matches on types as compared to errors.Is which will generally fail unless the error instances are exactly equal (or the error has an Is method that overrides the default behavior).
I doubt both methods would get included in the standard library, but besides added type safety and convenience, I've found that both methods make for much cleaner and simpler error-checking code.

FWIW, I've just released jub0bs/errutil, a small utility package that exports the following two functions:
func As[T error](err error, target *T) bool
func Find[T error](err error) (T, bool)

Note that Find is more efficient than As and never panics.


AMQP Support Document

Hi,
I didn't find any official document which demonstrates Azure IoT Hub AMQP support similar to MQTT Support Doc.
Can you please share the details of it.

Hi @sanket-kulkarni-vmware
I confirm that we don't have a single document for AMQP as we have for MQTT and we should definitively consider it.
In the meantime, you can find information (scattered across our documentation and SDKs code):

Authentication
our C SDK implementation for AMQP
, including detailed requirement docs
our node.js SDK implementation for AMQP, including detailed requirement docs

Using our SDKs should make your life way easier and I am wondering what's the reason for deciding not to use them (that'd help us make our SDKs and docs even better and more useful for you).
Hope this helps.

Documentation is there - closing as resolved


README fix

The README refers to/links browser_mod in relation to color-coding the trend icons. I think this should say card_mod.

This has been fixed. Thanks.


App Service Authentication CORS issue with BCP

When App Service Auth is enabled on an app service running BCP BCP is unable to get schema related data due to a CORS issue.
Here's a sample of the error.
Access to manifest at 'https://login.windows.net/common/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%mysite.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=4-c94ee2e731de&scope=openid+profile+email&response_mode=form_post&nonce=a886b168118040c3bd912c7875e4f2e7_20210622134124&state=redir%3D%252Fapi%252Fgraphql%252Fplayground%252Fmanifest.json' (redirected from 'https://mysite.azurewebsites.net/api/graphql/playground/manifest.json') from origin 'https://mysite.azurewebsites.net' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Here's an article that talks about addressing this issue by changing the UI to support sending access credentials:
http://jsandersblog.azurewebsites.net/2020/04/23/azure-app-service-authentication-cors-error-easy-auth/
Cause:
This behavior can occur if they are using fetch within their application. When using EasyAuth, a “Cookie” header is passed with the “AppServiceAuthSession” token. If the header is missing, an “authorize” request will be sent from provider. Sample below.
Fix:
By default, fetch doesn’t automatically send cookies. To resolve the issue, the customer will need to add the “credentials” property with either “same-origin” or “include” provided.

Did you have a look at the BCP settings?
They also can be preconfigured from the server.
The following example integrates with the identity server bff flow.
 endpoints.MapGraphQL()
    .WithOptions(new() { Tool = { Credentials = DefaultCredentials.Include } })
    .WithMetadata(new BffLocalApiEndpointAttribute(true));

this is correct, if you use cookie auth the headers are not added to /graphql/manifest json (which will try to trigger the auth flow)

compared to the request for /graphql/bcp-config.json which does include the headers

As a workaround I can use static files middleware and manually add at path wwwroot/graphql/manifest.json
{
"short_name": "Banana Cake Pop",
"name": "Banana Cake Pop",
"icons": [
{
"src": "icon.ico",
"sizes": "64x64 32x32 24x24 16x16",
"type": "image/x-icon"
}
],
"start_url": ".",
"display": "standalone",
"theme_color": "#000000",
"background_color": "#ffffff"
}


add authorization header in fetch request

Description
Shortcut: (link?)
Please include a summary of the change. If required, also include relevant info about motivation and context... And if PR includes UI elements (or if it helps for understanding it), please add extra files: snapshots, videos...
If this PR requires a companion in carto-react-template, please also link them both.
Type of change
(choose one and remove the others)

Fix
Feature
Refactor
Tests
Documentation

Acceptance
Please describe how to validate the feature or fix

go to X
test Y
assert Z

If feature deals with theme / UI or internal elements used also in CARTO 3, please also add a note on how to do acceptance on that part.
Basic checklist

Good PR name
Shortcut link
Changelog entry
Just one issue per PR
GitHub labels
Proper status & reviewers
Tests
Documentation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 2 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 71.721%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/react-api/src/hooks/useTileFeatures.js
0
2
0.0%

Files with Coverage Reduction
New Missed Lines
%

packages/react-api/src/hooks/useTileFeatures.js
1
23.26%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
1703

Relevant Lines:
2220

💛  - Coveralls