IE9 is not supported

both feed reads and writes are not supported. This is related to (missing) CORS support in IE9. We should at least add read support via JSONP

7% current market share
https://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

according to most browser market share websites IE9 is around 2%


Windows install reverts ultralytics to old version. autodistill not found

Search before asking

[X] I have searched the Autodistill issues and found no similar feature requests.

Question
How can I install ultralytics AND autodistill with latest version?
pip install --upgrade
Using cached ultralytics-8.0.196-py3-none-any.whl (631 kB)
Installing collected packages: ultralytics
  Attempting uninstall: ultralytics
    Found existing installation: ultralytics 8.0.81
    Uninstalling ultralytics-8.0.81:
      Successfully uninstalled ultralytics-8.0.81
**autodistill-yolov8 0.1.1 requires ultralytics==8.0.81, but you have ultralytics 8.0.196 which is incompatible.**
Successfully installed ultralytics-8.0.196

Additional
No response

Thank you for leaving this Issue! Can I confirm you installed the autodistill-yolov8 package?
We have previously run into breaking changes with the ultralytics package so we pinned the version for autodistill. I can test the latest version of ultralytics and make sure it works as expected.
While we do this, you can run autodistill in a virtual environment so that the ultralytics dependencies do not conflict with packages you have installed globally on your system.


Switch to grid from normal mode behaviour

When switching to grid mode from normal (after placing cursor with hint mode) the grid re-positions the cursor to the center. Is it possible to have the grid start centered at the cursor position when switched on while normal mode active. Ideally with an option to have the grid start smaller in this mode too.
This would enable a great way of refining the position after a hint mode placement. If you place the cursor with the hint then immediately see the grid mode at the size of one of the hint zones, you could quickly use the grid to refine in to the target without battling with the normal mode direction keys.
This is a very exciting project by the way - kudos!

I thought about doing something like this early on, but I've found hint mode in conjunction with the movement keys sufficient for quickly pinpointing most things on screen. The grid and hint modes are only intended for macroscopic movement to facilitate quick warping to the proximate region of interest, at which point normal mode can be used to make any adjustments. I'm not convinced there is room for an intermediate movement mode, but I am open to persuasion on the point if your experience suggests otherwise.
Incidentally, I rarely use grid mode in practice, it only exists because warpd originally started as a small C program to add a visual dimension to the quadrant based warping found in the keyboardio firmware. The person for whom it was originally developed uses some unorthodox hardware, so it has mainly been retained for backward compatibility, though I personally find hints to be much more efficient.
My usual pattern is to warp to a hint, make any necessary adjustments, and click. I find that about 70% of the time I don't need to make any adjustments, and when I do, it usually consists of one or two taps of the movement keys.
P.S
I thought your name looked familiar, it would seem we are both afflicted by the same input bug. It turns out I've recently enjoyed some of your content, so this feels like a serendipitous encounter :P.

Ok this sounds good I will keep familiarising myself with the direction keys for final adjustment. I may try adding some more characters to the hint grid to increase resolution too.
Thanks - someone actually emailed me to recommend warpd, so glad they did, I've been looking for something like this for a while.
I'm sure it won't be long before I include this in a video if that's all ok with you!
Cheers
Ben

On 7 Apr 2022, at 08:40, rvaiya @.***> wrote:
I thought about doing something like this early on, but I've found hint mode in conjunction with the movement keys sufficient for quickly pinpointing most things on screen. The grid and hint modes are only intended for macroscopic movement to facilitate quick warping to the proximate region of interest, at which point normal mode can be used to make any adjustments. I'm not convinced there is room for an intermediate movement mode, but I am open to persuasion on the point if your experience suggests otherwise.
Incidentally, I rarely use grid mode in practice, it only exists because warpd originally started as a small C program to add a visual dimension to the quadrant based warping found in the keyboardio firmware. The person for whom it was originally developed uses some unorthodox hardware, so it has mainly been retained for backward compatibility, though I personally find hints to be much more efficient.
My usual pattern is to warp to a hint, make any necessary adjustments, and click. I find that about 70% of the time I don't need to make any adjustments, and when I do, it usually consists of one or two taps of the movement keys.
P.S
I thought your name looked familiar, it would seem we are both afflicted by the same input bug. It turns out I've recently enjoyed some of your content, so this feels like a serendipitous encounter :P.
—
Reply to this email directly, view it on GitHub https://github.com/rvaiya/warpd/issues/84#issuecomment-1091203460, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVUJKCSZKOZFXYU5JPP6PTVD2GONANCNFSM5SYC6Z3A.
You are receiving this because you authored the thread.

Ok this sounds good I will keep familiarising myself with the direction keys for final adjustment. I may try adding some more characters to the hint grid to increase resolution too.

You may also want to fiddle with max_speed and acceleration. I picked defaults which work well on my machine, but if you find normal movement cumbersome for short distances you may need to adjust them.

I'm sure it won't be long before I include this in a video if that's all ok with you!

Sounds good :). I've been thinking about making a video to provide a better idea of what real world warpd usage looks like, so this would be quite helpful. I should note that the program still has several warts, some of which exist for legacy/implementation reason. I've recently invested some more time into the project given the influx of interest, but the macOS port is not my daily driver (and relatively new), so it is inclined to have a few more bugs. Feel free to open an issue or email me if you have any questions.

I'm closing this for now, but feel free to reopen it if you still feel strongly about it.


Mapping using distributive object type fails when key is generated in for loop

Bug Report

🔎 Search Terms
Mapped index with enum index
typescript dynamic generic type enum loop

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about distributive object types

⏯ Playground Link

Playground link with relevant code
💻 Code
https://www.typescriptlang.org/play?strictPropertyInitialization=false&jsx=0&ts=4.7.4&ssl=60&ssc=2&pln=27&pc=1#code/KYOwrgtgBAygLgQzsACgJwPYAdhrgTygG8AoKcqAQQCEYoBeKAIhpiYBoyKARAUQDEGzPvw5dyAeQBGAK2ABjOEKYTqAKV4BhACpMSAXxIkCOWImTpsuAgFkEWLAEsQAcyGkKUANpZMOPITOZkioftb4ALoAXFAAqgDOwPGU2vg4ADwIIPgAfAZG8gA2CPHxUKk4dg7OLprFpVCOEFiFwBCgcGXwIZb+tvZOrsTi3t0WYQEAdKzRcYnJFcDpUhgYrVk5ANwjXmOhVlMiswlJKWlL4BBSuFs7e73hk9JyisfzZxlECDGX12ibUCkMRWa2AWX0t0MJCKJTKJwW53S2hyHgoWDAUkKjnkUAAJsAAGYIMCFOAANQQhTAwBi2m2UJhDXhiyqgxc6QA0sBCMAAB7IEC4rrmfZ9XKo8jozHYqAAa25MS5+G2nilWJxADdKdTaedWTU6rCvEqIl4AOT4okk8na4BmiIqtEY9VQRDy+IUqnAIQACg1usqAwN9Xixu5pothOJpM91PtAEoGDliGhgHAwGgQFANfp6UYAPT57iE5yOOCODBZgCMJELcxqroAFo4ypbS+XK1AXI4NUkoFkoLhMGgm0hguMDgQoPIsmalNcoGBErjXRhGoK+VAqsy9UHXLX867zlv7PEd4HqkNGKQ6xQvPLAln7hMCG8kiy9+yH3k6-pdiKHgCCICyLEsQDLCsswAJgPBIGzgZtWzAiDO27XsygHLAEDQBB2mQEc4DXN0kljb0WygEAMCUWFHBcEAEExb1CIo4BezQYxjyqM95g-S83GvHYH3XcdRXCN94l4tl0m-fJoRDKAAHUy0bKpKHiGw2j+YZVWdGUIHsDSrlwGIuPPYB9VcbYRnkSt4jgNAwEUDA0B9fSsEMv4TNPMyLJcRMJU8JsW0mNyPNwIRQs03BHXIKEdOlHEEJbAB9IlHEKeIfXjALPAJZyfVaJQyiCZ9J3wbKRkCihC14NBhygDB5HkDMykbXBgEqqqgviEKDKitAvAw4UehfSJJmIj1bR9JKesioyBqGkTANfSYtS9eNOtikY4qdBLuuSgB3ZzZXiQ7lOSmc7JqLKcooPKXMKqBiqfADRoqrrAsepRGEW0qxRij6oELbREKgI60BOzbAp9dIfM-dITGADACVdHIchm3r3P6rw4AieNxoQd1SOmxDMbCgbcdW20No+wxPEMfQgA

//Enum
enum StateProperty {
    ABS = "ABS",
    DEF = "DEF",
    Object = "OBJECT"
}

//Type definition for mapping type
type StatePropertyMapping = {
    [property in StateProperty]: UsesAType<any>
}

//Actual type mappings
class TypeMappingClass implements StatePropertyMapping {
    [StateProperty.ABS]: UsesAType<boolean>;
    [StateProperty.DEF]: UsesAType<number>;
    [StateProperty.Object]: UsesAType<{a: number; b: boolean}>;
}

class UsesAType<T>{
    public defaultValue: T;
}

class UsesTypeMapping<Key extends StateProperty>{
    public key: Key;
    public value: TypeMappingClass[Key]['defaultValue']; //This is a separate class that wants to know the type mapping for 'Key'
    public takesValue = (v: TypeMappingClass[Key]['defaultValue']) => {return v};
}

//Definition 1
// Using this definition gives an error that 'StateProperty can't be used to index MapUsesTypeMapping'
// type MapsUsesTypeMapping = {
//    [key in StateProperty]: UsesTypeMapping<key>
// }[StateProperty]

//Definition 2
//Using this definition gives an error that 'parameter to takesValue is not assignable to never'
type MapsUsesTypeMapping = {
    [key in StateProperty]: UsesTypeMapping<key>
}

class WithMapAsMember {
    public mapMember: MapsUsesTypeMapping;

    constructor(mapMember: MapsUsesTypeMapping) {
        this.mapMember = mapMember;
    }

    public this_fails(){
        for(let s in StateProperty){
            //Error occurs here
            this.mapMember[s as StateProperty].takesValue(this.mapMember[s as StateProperty].value)
        }
    }

    public this_works_with_casting(){
        for(let s in StateProperty){
            let t = s as StateProperty;
            //This works with definition 2 only
            (<UsesTypeMapping<typeof t>>this.mapMember[t]).takesValue(this.mapMember[t].value)
        }
    }
}

🙁 Actual behavior

If I try to setup the mapping using an enum, the compiler is unable to infer the type mapping based of the union type when the value is generated at runtime (i.e. in a loop)
🙂 Expected behavior

I expect that the compiler will be able to infer the type that takesValue accepts when mapMember is indexed using a specific state property, similar to how it is described in this issue: https://github.com/microsoft/TypeScript/pull/47109

for (let s in StateProperty) and s as StateProperty doesn't make much sense unless the keys and values of the StateProperty enum are identical, and they aren't.  Even if they were, it's sketchy to do this.  You should maybe be doing something like for (let s of Object.values(StateProperty) instead.
Anyway I'm not seeing this as a bug... the way #47109 works is to use generics, and you're not using generics.  If you think this should be possible without generics then maybe this is a re-reporting of #30581?
Anyway my refactoring here to use the solution in #47109 would be
Object.values(StateProperty).forEach(
    <S extends StateProperty>(s: S) => {
        this.mapMember[s].takesValue(this.mapMember[s].value)
    }
);

and this is quite close to what you're doing.  Is there some version of this which isn't easily translated into a generic forEach() callback?

No what I'm working on should be easily translated to the forEach callback.
Could you help me understand why it's necessary to typecast the 's' parameter to <S extends StateProperty>(s: S) => ...? I don't understand how the compiler doesn't already know that s is of type StateProperty.

There's no typecasting going on there.  It's a generic callback function.  It's the same as
function cb<S extends StateProperty>(s: S) {
    this.mapMember[s].takesValue(this.mapMember[s].value)
}

Object.values(StateProperty).forEach(cb);

All this behavior looks right to me. Relevant thread - https://twitter.com/SeaRyanC/status/1544414378383925250

Thanks for the comments! Closing


waitForFunction has no DOM references for: document, window

Steps to reproduce
Tell us about your environment:

Puppeteer version: 1.2, also tested with 1.7 and 5.0.0
Platform / OS version: OSX Mojave 10.14.6 (18G5033)
URLs (if applicable):
Node.js version: Tested with 8.9.0, 12.14.1, 14.5.0

What steps will reproduce the problem?
Assuming you have a frontend JS file running in a localhost application that loads JS inline:
window.screenCaptureReady = false;

(function() {
   // some loading stuff here and then...
   window.screenCaptureReady = true;
}();

Then you have another process that loads the page that contains that Javascript.
const browser = await puppeteer.launch({
  headless: true,
  defaultViewport: {
    width: pageWidth,
    height: pageHeight,
    isLandscape: true
  },
  args: ['--no-sandbox', '--disable-web-security',
            '--hide-scrollbars', '--disable-setuid-sandbox']
});

const page = await browser.newPage();
await page.goto(filePath, {waitUntil: 'networkidle0', timeout: 60000});

const waitForFunction = 'window.screenCaptureReady';
await page.waitForFunction(waitForFunction);

const buffer = await page.screenshot({
  encoding: 'binary',
  type: 'png',
  fullPage: true
});

await page.close();
await browser.close();
// do something with buffer

Expected result is that screenCaptureReady becomes true and the screenshot renders.  However, the waitForFunction reaches a timeout and the screenshot never generates.  Upon inspection with some logging using:
page.on('console', message => console.log(message.text());

Both window and document are  undefined within the waitForFunction context.  My workaround was to use a
await page.evaluate(() => {
  const captureCheck = function() {
    if (!screenCaptureReady) {
      setTimeout(captureCheck, 100);
    }
  }
})

Am I doing something wrong?

I cannot reproduce with this simplified code. Can you?
'use strict';

const puppeteer = require('puppeteer');

(async function main() {
  try {
    const browser = await puppeteer.launch(); // { headless: false, defaultViewport: null, args: ['--lang=en'] }
    const [page] = await browser.pages();

    await page.goto('https://example.org/');

    await page.evaluate(() => {
      window.screenCaptureReady = false;
      setTimeout(() => { window.screenCaptureReady = true; }, 5000);
    });

    console.log(`window.screenCaptureReady is ${
      await page.evaluate(() => window.screenCaptureReady)
    }. Waiting...`);

    await page.waitForFunction('window.screenCaptureReady');

    console.log(`window.screenCaptureReady is ${
      await page.evaluate(() => window.screenCaptureReady)
    }.`);

    await browser.close();
  } catch (err) {
    console.error(err);
  }
})();

Output:
window.screenCaptureReady is false. Waiting...
window.screenCaptureReady is true.

Can there be any error in "some loading stuff here and then" preventing the execution of  window.screenCaptureReady = true;?

Also, can it be that this code (window.screenCaptureReady = true;) is executed in an iframe or a web worker?

So I think I just uncovered the issue.  There is another page.evaluate() to call initialization code which runs before-hand that runs the long-running Ajax processes to change the status of window.screenCaptureReady.  I would assume that the window scope is somehow different.
Example:
await page.evaluate(() => {
   setTimeout(() => {
     window.screenCaptureReady = true;
   }, 3000);
});

I am going to break it down to what I am precisely doing to see if I can replicate:
simple.html
<!DOCTYPE html>
<html>
  <head>
    <script src="simple.js"></script>
  </head>
  <body>
  </body>
</html>

window.screenCaptureReady = false;
const App = {};

(function() {
  App.init = function(params) {
    setTimeout(() => {
      window.screenCaptureReady= true;
    }, 3000);
  };
})();

screenshot.js
await page.evaluate((params) => {
  App.init(params);
}, params);

await page.waitForFunction('window.screenCaptureReady');
await page.close();

It seems the timeout is related to the frontend code not resolving the Ajax requests in the Promises.  You can close this issue.


add log methods to context class

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


Loop Back Works... kinda

I was able to make the loopback work when I set the velodyne plugin to have the sensor ip be my private IP, then set the destination ip to <IP_ADDRESS>. With that, you can bind a docker container to <IP_ADDRESS> with udp to listen to the port. The hardest part is configuring (if you're using a velodyne ros driver) the ip address to listen to... it will not be the same as either ip address. For me it was <IP_ADDRESS> and I only found out by a log another container I had posting it, and throwing a hail mary. I didn't need anything fancy though like network_mode host. Hopefully this can help other people dealing with this.
Awesome work,
Cheers

Hi, @Interaze
Thanks for sharing the loopback connection! I will try it.


fix: Change to names for statistics so that other implementations can be added

Context
The response for statistics is an array, but is always used as named/value pairs.  Having a single response type that allows either makes creating new statistics calculators much easier.
Changes & Results
Use a named object from Calculator instead of an array, but include the array as one of the named objects.
Testing

Checklist
PR

[] My Pull Request title is descriptive, accurate and follows the
semantic-release format and guidelines.

Code

[] My code has been well-documented (function documentation, inline comments,
etc.)

[] I have run the yarn build:update-api to update the API documentation, and have
committed the changes to this PR. (Read more here https://www.cornerstonejs.org/docs/contribute/update-api)

Public Documentation Updates

[] The documentation page has been updated as necessary for any public API
additions or removals.

Tested Environment

[] "OS:
[] "Node version:
[] "Browser:

FYI @salimkanoun @Celian-abd


"unable to authenticate (unauthorized)" error

Trying to set up a new volume:
➜ cat docker-compose.yml
version: "3.5"

volumes:
    test:
        driver: hetzner
        driver_opts:
            apikey: xxxx
            fstype: xfs
            size: 10 # in GB, default: 10
            loglevel: debug

When running docker-compose up, I get:
Creating volume "docker-volume-test_test" with hetzner driver
ERROR: create docker-volume-test_test: VolumeDriver.Create: could not get cloud server 'test': unable to authenticate (unauthorized)

Note that the token is correct; I could successfully activate the context in hcloud and run:
➜ ~/go/bin/hcloud server describe test
ID:     xxxxxxxx
Name:       test
Status:     running
Created:    Wed Dec 11 09:00:43 CET 2019 (5 hours ago)
Server Type:    cx41 (ID: 7)
  ID:       7
  Name:     cx41
  Description:  CX41
  Cores:    4
  Memory:   16 GB
  Disk:     160 GB
  Storage Type: local
Public Net:
  IPv4:
    IP:     xx.xx.xx.xx
    Blocked:    no
    DNS:    static.xx.xx.xx.xx.clients.your-server.de
  IPv6:
    IP:     xx.xx.xx.xx
    Blocked:    no
  Floating IPs:
    No Floating IPs
Private Net:
  - ID:         17489
    Name:       internal-network
    IP:         <IP_ADDRESS>
    MAC Address:    86:00:00:39:19:92
    Alias IPs:      -
Volumes:
  No Volumes
Image:
  ID:       168855
  Type:     system
  Status:   available
  Name:     ubuntu-18.04
  Description:  Ubuntu 18.04
  Image size:   -
  Disk size:    5 GB
  Created:  Wed May  2 13:02:30 CEST 2018 (2 years ago)
  OS flavor:    ubuntu
  OS version:   18.04
  Rapid deploy: yes
Datacenter:
  ID:       2
  Name:     nbg1-dc3
  Description:  Nuremberg 1 DC 3
  Location:
    Name:       nbg1
    Description:    Nuremberg DC Park 1
    Country:        DE
    City:       Nuremberg
    Latitude:       49.452102
    Longitude:      11.076665
Traffic:
  Outgoing: 7.4 MB
  Ingoing:  2.4 GB
  Included: 22 TB
Backup Window:  Backups disabled
Rescue System:  disabled
ISO:
  No ISO attached
Protection:
  Delete:   no
  Rebuild:  no
Labels:
  No labels

Any idea what's wrong? When I run hostname, I also get test.

The README holds a clue to the misunderstanding:

The following options can be passed to the plugin via docker plugin set

The only options that make sense in the volume definition are fstype and size (also mentioned in the README)
Maybe this could be more clearly worded, or maybe with a :warning:
It would also probably be a good idea to display a warning when trying to pass unsupported options.

Ohhh, that makes sense, thanks. I was going to ask if it wasn't a bad idea to add the API key to the config :smile:
I think the README could be split between the general plug-in options that you'd set after installation, and only then, later, give a full example of the compose config.
I can give it a shot tomorrow and provide a PR for a README that tired me would have understood.


[BUG] Unable to download data, "please download farsight" error

I've been using version 1.5.37 without fail for the last week but all of a sudden it started prompting an erro saying data could not be downloaded (as if there was an update) and it asks me to either write or download the farsight.json file.
I still get the same issue when trying to delete the current installation and re-installing. I do not know much about code or github, so if there'a a way to download that farsight file separately, I have not found it.
Steps to reproduce the behavior:

Go to your installation path
Open LeagueBroadcast.exe
Update sequence animation goes through
See error

I am using this for a lol league we're doing in our country (the only one) with Riot's license and we would like to maintain the high quality we achieved through LB

Desktop (please complete the following information):

Windows 11 Pro
Version [22H2] 22621.900 Windows Feature Experience Pack 1000.22638.1000.0

Could you post error logs as well? This usually happens only after a patch and offsets havent been updated yet

Issue resolved itself by deleting farsight and forcing a re-download. Thanks Floh!


PR for Single Barplot

Given an explanation object, we need to be able to

[x] plot RFI values in a barplot
[x] describe the RFI results using a legend/title/...
[x] indicator of standard deviations over multiple runs
[x] absolute results (numbers) should be plotted as well

At this point we do not focus on colormaps etc.
At this point only a single RFI result needs to be plotted.

All requirements fulfilled.


stylix in home-manager standalone  will not allow to start new gnome session

Tried in two different VMs:
debian 12.8.0
oraclelinux 9.3
enabled stylix in homemanager standalone as stated in the manual.
then

home-manager switch -b backup
logout
login

Screen just flickers and back to gdm login
flake.nix
{
  description = "Home Manager configuration";

  inputs = {
    # Specify the source of Home Manager and Nixpkgs.
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    stylix = {
      url = "github:danth/stylix";
    };
  };

  outputs = { nixpkgs, home-manager, stylix, ... }@inputs:
    let
      system = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages.${system};
    in {
      homeConfigurations."user" = home-manager.lib.homeManagerConfiguration {
        inherit pkgs;

        extraSpecialArgs = {
          inherit inputs;
          inherit system;
        };
        # Specify your home configuration modules here, for example,
        # the path to your home.nix.
        modules = [
           stylix.homeManagerModules.stylix
          ./home.nix
        ];

        # Optionally use extraSpecialArgs
        # to pass through arguments to home.nix
      };
    };
}

home.nix
{ config, pkgs, nixvim-conf, system, inputs, stylix, ... }:

{
  # Home Manager needs a bit of information about you and the paths it should
  # manage.
  home.username = "user";
  home.homeDirectory = "/home/user";

  # This value determines the Home Manager release that your configuration is
  # compatible with. This helps avoid breakage when a new Home Manager release
  # introduces backwards incompatible changes.
  #
  # You should not change this value, even if you update Home Manager. If you do
  # want to update the value, then make sure to first check the Home Manager
  # release notes.
  home.stateVersion = "24.05"; # Please read the comment before changing.

  # The home.packages option allows you to install Nix packages into your
  # environment.
  stylix = {
    enable = true;
    polarity = "dark";
    base16Scheme = "${pkgs.base16-schemes}/share/themes/gruvbox-dark-hard.yaml";
    image = pkgs.fetchurl {
       url = "https://www.pixelstalk.net/wp-content/uploads/2016/05/Epic-Anime-Awesome-Wallpapers.jpg";
       sha256 = "enQo3wqhgf0FEPHj2coOCvo7DuZv+x5rL/WIo4qPI50=";
    };

  };
  home.packages = [

    # # Adds the 'hello' command to your environment. It prints a friendly
    # # "Hello, world!" when run.
    # pkgs.hello

    # # It is sometimes useful to fine-tune packages, for example, by applying
    # # overrides. You can do that directly here, just don't forget the
    # # parentheses. Maybe you want to install Nerd Fonts with a limited number of
    # # fonts?
    # (pkgs.nerdfonts.override { fonts = [ "FantasqueSansMono" ]; })

    # # You can also create simple shell scripts directly inside your
    # # configuration. For example, this adds a command 'my-hello' to your
    # # environment:
    # (pkgs.writeShellScriptBin "my-hello" ''
    #   echo "Hello, ${config.home.username}!"
    # '')
  ];

  # Home Manager is pretty good at managing dotfiles. The primary way to manage
  # plain files is through 'home.file'.
  home.file = {
    # # Building this configuration will create a copy of 'dotfiles/screenrc' in
    # # the Nix store. Activating the configuration will then make '~/.screenrc' a
    # # symlink to the Nix store copy.
    # ".screenrc".source = dotfiles/screenrc;

    # # You can also set the file content immediately.
    # ".gradle/gradle.properties".text = ''
    #   org.gradle.console=verbose
    #   org.gradle.daemon.idletimeout=3600000
    # '';
  };

  # Home Manager can also manage your environment variables through
  # 'home.sessionVariables'. These will be explicitly sourced when using a
  # shell provided by Home Manager. If you don't want to manage your shell
  # through Home Manager then you have to manually source 'hm-session-vars.sh'
  # located at either
  #
  #  ~/.nix-profile/etc/profile.d/hm-session-vars.sh
  #
  # or
  #
  #  ~/.local/state/nix/profiles/profile/etc/profile.d/hm-session-vars.sh
  #
  # or
  #
  #  /etc/profiles/per-user/matt/etc/profile.d/hm-session-vars.sh
  #
  home.sessionVariables = {
     EDITOR = "nvim";
  };

  programs.nh = {
    enable = true;
  };
  programs.bash = {
    enable = true;
  };
  programs.zsh = {
    enable = false;

  };
  targets.genericLinux.enable = true;
  # Let Home Manager install and manage itself.
  programs.home-manager.enable = true;
}

if I change stylix.enable to false the gnome session login works again.
Any idea what is missing? Just activating the configuration is fine btw, no error messages and theming applied as far as I can see.

Is commit ffba1f1bab63 ("gnome: update to GNOME 47.2 (#658)") causing version mismatches with your installed GNOME version?

Quite likely it is a version mismatch between stylix and the non nixos version if gnome. I guess this is beyond the scope of stylix and home-manager. I have good results with arch and hyperland configuring themes, but it is safe to assume that the versions are just close enough. Feel free to close this issue if my assumption is correct.

Screen just flickers and back to gdm login

The issue you describe happens very occasionally in my setup too (NixOS 24.11 + Home Manager standalone). I always assumed the cause was some other things I have in my configuration, but perhaps it's actually Stylix. Next time it happens I'll do some digging into the logs.


Connection Error to the js-algorand-sdk package

Hi, I got this error when trying to run yarn add algob
yarn add v1.22.4
[1/4] 🔍  Resolving packages...
error An unexpected error occurred: "https://raw.githubusercontent.com/algorand/js-algorand-sdk/3999aa43fc3d945b38419339c593bb5fd72e49c6/package.json: connect ECONNREFUSED <IP_ADDRESS>:443".
info If you think this is a bug, please open a bug report with the information provided in "/Users/haichaozhu/code/algob-project/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

I figured this might be a connection problem of my network. (I'm in China and I'm using a local mirror site for all yarn and npm packages).
However I don't have problems installing algorand js SDK alone.
Not an expert in js coding. So could be a silly question.

Could be because the HTTPS connection is blocked.
Can you do this, please
mkdir test-algob
cd test-algob
yarn init
yarn add algob

I've just did it and it worked.
If this doesn't work then try to run (no need to repeat other steps):
npm install algob

Please let me know if this works.

If you have a local mirror site you should somehow make sure that it came from our repository and that it's compiled correctly.
This is what I have in my yarn.lock after a successful install:
<EMAIL_ADDRESS>  version "0.0.3"
  resolved "https://registry.yarnpkg.com/algob/-/algob-0.0.3.tgz#6ea5f46463ffb183e443b10ccca9c7a7ad79d243"
  integrity sha512-g9uKdoi5SmHh9ujBeNn92ao/wHymibiWc785UvbClp40769aiawBeZHyaUIVzG/m/3mI9K9izLsr8C06Hilvhg==
  dependencies:
    algosdk "github:algorand/js-algorand-sdk#v1.7.0-beta"
...

And if I go to https://registry.yarnpkg.com/algob then I can find a link to our github repository:
git+https://github.com/scale-it/algorand-builder.git
I don't know which version is deployed to https://www.npmjs.com/package/algob/v/0.0.3 but it has to be a commit of a master branch.

If none of this suggests a solution then you can compile algob by hand and do yarn link to have it locally.
We currently don't have a way to import directly from github because we have a monorepo project (this would be a way to not have a npmjs package this early).
To run a linked package with yarn you can do this (assuming you use unix-like terminal):
git clone https://github.com/scale-it/algorand-builder/
cd algorand-builder/packages/algob
yarn build
yarn link

Then go to your project, and execute yarn link algob
This will add a link in your project (not exactly this way but it works similarly to this):
project/node_modules/algob -> ~/.../algorand-builder/packages/algob/build/
Then if you have your local yarn bin/ directory in $PATH you'll be able to even use the CLI tool (as you would regularly):
$> algob -h

Thanks. I'll give it a try.
Since it's my own problem then it's ok.
Let me try to figure it out myself.
Feel free to close the issue.

Let's keep it open to see if this worked or not.

BTW - in the master branch we did some breaking changes and checking now with the example.


[grafana] Fix spelling mistake

what

ACCOUT should be ACCOUNT

fixed in https://github.com/cloudposse/helmfiles/pull/26


Test rebase upstream approach

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 12 committers have signed the CLA.:white_check_mark: guicaulada:white_check_mark: iainlane:x: erik-bershel:x: shamil-mubarakshin:x: sergei-pyshnoi:x: mikhailkoliada:x: Alexey-Ayupov:x: sssharif:x: MaksimZhukov:x: lzandman:x: Codes-Lab:x: paveliakYou have signed the CLA already but the status is still pending? Let us recheck it.


small mistakes

Description
I was just going through the docs and saw a couple of small things that look a little wrong.
Reference issue
None.

Awesome! Thank you so much for fixing this @coryschwartz :)


Preparation or improvement of the guide for guide classes and dynamic systems overview (issue #622 related)

The goal is to prepare or improve a guide class that is stored in the File

Improvment has been implemented in the class.


Rename and refactor some ProjectorElement methods. Fixed #1631.

Ok for me. Is there something to do on client-side? If not you can merge after travis is fixed.

Nothing to do for the client.


FlipView Back/Forward buttons not visible

FlipView arrow buttons is missing with latest binaries (1.6.5). I can make placeholders visible by changing Panel.ZIndex of this buttons to any value, but content of the buttons still not visible.
You can see details on attached image

<Window.Resources>
        <DataTemplate x:Key="ImageTemplate">
            <Grid>
                <Image Source="{Binding}"/>
            </Grid>
        </DataTemplate>
    </Window.Resources>
    <Grid>
        <mah:FlipView CircularNavigation="True"
                      ItemsSource="{Binding Images}"
                      ItemTemplate="{StaticResource ImageTemplate}"
                      IsNavigationEnabled="True"
                      MouseHoverBorderEnabled="False"
                      DownTransition="Down"
                      IsBannerEnabled="True"
                      Orientation="Horizontal"
                      >
        </mah:FlipView>
    </Grid>

Just forgot to add Metro resources to App.xaml
Thanks to @punker76 for help.


Add support for non persistent connections.

In an escenario where the wavefront proxy is in an ASG behind an ELB
where the proxy instances may change, is better to not have persistent
connections in order to ensure that the current one is always created
against a running instance. What is more, if you are using the
connection draining feature of the ELB's using non persistent
connections will ensure you that you can replace the instances in the
ASG without any data loss.
As the wavefront protocol doesn't expect to receive an ACK from the
remote server the client can't notice a dropped connection, a connection
that was not properly closed, and it can lead to send metrics to nowhere.

Thx @AgarFu, we had same issue using AWS ELB. Can we have this merge?


New package: CLOUD v0.1.0

Registering package: CLOUD
Repository: https://github.com/tristanmontoya/CLOUD.jl
Created by: @tristanmontoya
Version: v0.1.0
Commit: 10d7c7f3f570de29b2d2b4a754d262cb86b99d87
Reviewed by: @tristanmontoya
Reference: https://github.com/tristanmontoya/CLOUD.jl/issues/33#issuecomment-1575952592
Description: CLOUD.jl: A spectral-element framework for conservation laws on unstructured domains

I think the name is fine, but you'll have to ask on Slack in the #pkg-registration channel for one of the maintainers to merge it manually (after you fix the problem with the julia compat entry and wait the obligatory 3-day period)

I think the name is fine, but you'll have to ask on Slack in the #pkg-registration channel for one of the maintainers to merge it manually (after you fix the problem with the julia compat entry and wait the obligatory 3-day period)

Thanks for your help - I am new to registering packages and wasn't aware of the name guidelines, but now after looking into it, I might actually just end up renaming it.

Sounds good! Personally, I think pronounceable acronyms are totally okay. They're not really different from the "less systematic" names that the guidelines talk about. If Gadfly is allowed, so should CLOUD, in my opinion. But of course, you can also rename your package if you prefer, and if you want it to be merged automatically instead of having  to ask one of the maintainers.


Excel showing error while i am exporting xlsx format

   $data = array(
       array('data1', 'data2'),
       array('data3', 'data4')
   );

   Excel::create('Filename', function($excel) use($data) {

       $excel->sheet('Sheetname', function($sheet) use($data) {

           $sheet->fromArray($data);

       });

   })->export('xlsx');

Not sure how you expect me to help you if you don't specify which error?

It seems that I have the same problem. Export works properly with 'xls' or 'csv' but when it comes to xlsx it returns a 500 error and Firefox reports "File not Found".
Searching on laravel logs I found this
[2017-04-25 11:45:44] local.ERROR: Symfony\Component\Debug\Exception\FatalThrowableError: Class 'ZipArchive' not found in ~/application/vendor/phpoffice/phpexcel/Classes/PHPExcel/Writer/Excel2007.php:227

I think I have found the error. It seems that zip module needs to be installed and apache restarted. In Ubuntu I did:
sudo apt-get install php7.0-zip
sudo service apache2 restart

and now it works.

Thanks for posting your solution @skarampatakis

same problem for me, installing zip is not working...


Make it SP friendly

The original version is SP compatible and has no limitations (for example, when I try to buy the night stalker scope it says it's not allowed).

The game is already SP compatible, it is however more driven towards MP. You can disable arsenal blocks within the lobby parameters or you can remove the scope classname from the blacklisted_from_arsenal array in kp_liberation_config.sqf.
Change:
	"RHS_SPG9_Gun_Bag", 	"RHS_SPG9_Tripod_Bag", 	"optic_Nightstalker", 	"optic_tws", 	"optic_tws_mg"
to:
	"RHS_SPG9_Gun_Bag", 	"RHS_SPG9_Tripod_Bag", 	"optic_tws", 	"optic_tws_mg"
Notice that there is no comma on the last entry, this is intentional and needs to be exact.
Other recommendations whilst running it in SP include putting the unit cap lobby parameter at 50%. You can edit the mission_params.sqf file to change lobby parameter defaults so you don't have to do this every session.

The old 924 version has also limitations. What is "SP compatible" for you? Without further details this phrase hold no information.
As Apple said you can play the mission without problems as SP.
Concerning limitations in 924:
Line 305
https://github.com/GreuhZbug/greuh_liberation.Altis/blob/master/classnames_extension.sqf

What is "SP compatible" for you?
Sorry, I meant SP friendly!
Also, in the original version there was an option that replaced crates with passive income (so I didn't have to go all the way over to the bases to collect the crates, come back and recycle them)

🙂 No worries!

There is still a passive income feature, it just requires some work, like an "investment" to get it setup. This takes away the magical give me resources dependent on progress and creates a virtual reality regarding how you would justify gaining resources. See these two links for further details:

https://github.com/Wyqer/kp_liberation/wiki/EN:Production
https://github.com/Wyqer/kp_liberation/wiki/EN:Logistic

Specifically:

https://github.com/Wyqer/kp_liberation/wiki/EN:Logistic#creating-a-passive-income

Even with the resource multiplier at 1, myself and team of say 5 max always run into "too many" resources, once we set it up passively 95% of the game the trucks are waiting on standby as I have nowhere else to store more resources. 😅

As far as I was aware, the Unit Cap is how many sectors would activate at a time. So if 8 sectors would activate on 100%, only 4 would activate on 50% and the same response would work for reinforcements and battlegroups too. As one person, you wouldn't need 4 sectors at once, let alone 8. It's just a recommendation to help keep the local host server clean and running well. If it's fine already, I wouldn't worry about it for the most part.

Secondary objectives you can access and initiate via the scroll menu at an FOB. They cost intel, which is gained by bringing prisoners back to an FOB or finding intelligence laptops around military bases. They each come with their own rewards, an FOB hunt would be the best for lowering the enemy alert.
There's no possibility of updating between new versions, only hotfixes of the same versions, so 0.924 won't update to 0.955 without wiping your save unfortunately. You could always "cheat" your way back to a similar progress using an unlocked Zeus, see here:

https://github.com/Wyqer/kp_liberation/wiki/EN:FAQ#how-can-i-enable-full-zeus

There's no possibility of updating between new versions

Pity, I put a lot of work into the old one!

Nothing force you to use the latest version. Just finish your actual campaign and change afterwards. :)

Yeah. I know!
One thing I forgot: Can you increase the amount of resources at startup? At least enough to create a darter and a light rifle squad, which is 20 green resources (don't know what it's called!) and 5 fuel.

Ok I just actually played your mission and I must say the unit and asset costs are unreasonably high. The original version costs were much better. This makes me resort to cheating! (using full zeus to create something like M5 sandstorm and then recycle them). Can you create a parameter like "cost multiplier" (with options lower than 1 of course!)?

No, there'll be no multiplier parameter, as everyone can just edit the prices to their own likings in the preset file. A multiplier is unnecessary code.

Just wanted to clarify, those hummingbirds won't explode if you give the mission 20 seconds to load entirely. When you load into the briefing screen, you'll see the map and mission sector icons, find a base and wait for the locked "elite" vehicle to show above it, as these are the last things to load in on the map. Starting the mission and hitting go instantly; that causes the hummingbirds to clip and explode.
Also, the "cost" multiplier would be the same as the resource multiplier but in a different direction, so entirely redundant and as Wyqer said, you can change the costs within the preset files but honestly, you should quickly realise you'll have more resources than you can spend. Capture 3 sectors, have these 3 sectors produce each resource type respectively, have logistics carry those resources back to your FOB on an infinite loop, all explained within the Wiki. You'll have more resources than you can spend in a realistic, milsim and co-operative environment. Remember, you're not buying vehicles per sector operation, you should be buying and preserving a vehicle, the entire campaign.

OK, so I reduced all unit costs in the preset but I don't know how to reduce squad costs!

It's the scripts\shared\classnames.sqf file.
Top of that is...
squads = [ 	[blufor_squad_inf_light,200,0,0], 	[blufor_squad_inf,300,0,0], 	[blufor_squad_at,200,250,0], 	[blufor_squad_aa,200,250,0], 	[blufor_squad_recon,250,0,0], 	[blufor_squad_para,200,0,0] ];

@Applejakerie Thank you!


Support for flit, conda (or similar) based plugin installs

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2580
Originally created by @IanKnox on 2021-02-15 21:21:03

Problem to solve
By supporting a wider group of package builders/installers we can allow for easier plugin development and (in certain cases) a more flexible usage pattern in production.
Target audiences

A developer who doesn't like/can't use pip.
A developer who doesn't like/can't use setuptools and requires installing taps/targets locally (pip does not allow local installs to utilize PEP-517, which pretty much forces you to use setuptools instead-- this is my current use case, and probably a semi-common one for plugin devs).

Proposal
Include an optional plugin-level parameter that overrides the entire install process maybe? install_command option at the plugin level which could be flit install -s path/to/plugin or whatever your heart desired.  Obviously you would have to manage the given environment so the necessary tools could be installed (does this already exist in meltano?  It feels like it should somewhere)
What does success look like, and how can we measure that?
Plugins can be installed via a number of different package installer systems.

View 3 previous comments from the original issue on GitLab

Conda plugin support is unlikely to be implemented, since it only really works with Conda environments, unlike everything else from the standard Python packaging ecosystem.
Installing using a tool other than pip seems unnecessary, since pip will respect the build system declared via PEP-517 metadata in pyproject.toml. I believe the following statement is no longer true:

pip does not allow local installs to utilize PEP-517


Staging environments PRIVACY_BUDGET_AUTHORIZATION_ERROR

Hi team,
We enrolled https://ebayadservices.com/ as our production environment a few weeks ago, and confirmed with your team that it was completed.

and we noticed this sentence on your document: Your staging, beta, QA and test environments will be automatically enrolled if they use the same site as your production environment.
However, when we use https://staging.ebayadservices.com/ to do the tests, the job failed to pass the authorization. Could you please help to investigate this issue?
BTW, because our company’s testing environment does not allow external sites, we use a internal proxy to access https://staging.ebayadservices.com/. I don't know if this is the root cause of this issue.
The avro files:
report avro
domain avro
The api response are as followed.
{
    "job_status": "FINISHED",
    "request_received_at": "2024-05-22T02:15:53.301731Z",
    "request_updated_at": "2024-05-22T02:16:02.790976116Z",
    "job_request_id": "test11",
    "input_data_blob_prefix": "output/output_regular_reports_2024-05-21T19:12:54-07:00.avro",
    "input_data_bucket_name": "tracking_tf_state_bucket",
    "output_data_blob_prefix": "output/summary_report.avro",
    "output_data_bucket_name": "tracking_tf_state_bucket",
    "postback_url": "",
    "result_info": {
        "return_code": "PRIVACY_BUDGET_AUTHORIZATION_ERROR",
        "return_message": "com.google.aggregate.adtech.worker.exceptions.AggregationJobProcessException: Aggregation service is not authorized to call privacy budget service. This could happen if the createJob API job_paramaters.attribution_report_to does not match the one registered at enrollment. Please verify and contact support if needed. \n com.google.aggregate.adtech.worker.aggregation.concurrent.ConcurrentAggregationProcessor.consumePrivacyBudgetUnits(ConcurrentAggregationProcessor.java:451) \n com.google.aggregate.adtech.worker.aggregation.concurrent.ConcurrentAggregationProcessor.process(ConcurrentAggregationProcessor.java:329) \n com.google.aggregate.adtech.worker.WorkerPullWorkService.run(WorkerPullWorkService.java:142)\nThe root cause is: com.google.scp.operator.cpio.distributedprivacybudgetclient.TransactionEngine$TransactionEngineException: PRIVACY_BUDGET_CLIENT_UNAUTHORIZED \n com.google.scp.operator.cpio.distributedprivacybudgetclient.TransactionEngineImpl.createTransactionEngineException(TransactionEngineImpl.java:203) \n com.google.scp.operator.cpio.distributedprivacybudgetclient.TransactionEngineImpl.proceedToNextPhase(TransactionEngineImpl.java:67) \n com.google.scp.operator.cpio.distributedprivacybudgetclient.TransactionEngineImpl.executeDistributedPhase(TransactionEngineImpl.java:196)",
        "error_summary": {
            "error_counts": [],
            "error_messages": []
        },
        "finished_at": "2024-05-22T02:16:02.778068915Z"
    },
    "job_parameters": {
        "output_domain_blob_prefix": "domain/output_local_domain.avro",
        "output_domain_bucket_name": "tracking_tf_state_bucket",
        "attribution_report_to": "https://staging.ebayadservices.com"
    },
    "request_processing_started_at": "2024-05-22T02:15:55.674601807Z"
}

Hi @ruclohani ,
Thanks for your reply. Looking forward to message about your successful fix! Much appreciated.


upgrade tokio to latest version(v0.3)

Before merging, I think it may be better to wait a bit until most of the async ecosystem upgrades to the latest tokio release.
A bunch of examples are using reqwest and causes duplicated dependencies, as it has not been upgraded yet: https://github.com/seanmonstar/reqwest/pull/1076

Tested locally, and this works for the Game of Life and Solar System example programs.

As I mentioned, reqwest has not yet migrated, so examples like pokedex and download_progress do not work.
We could use the compatibility layer, but we can just wait.

I think we can merge it

I have rolled back the latest changes to .gitignore.
We should try to keep the repository decoupeld from specific dev environments. For that purpose, you should change the .git/info/exclude instead.

It seems I forget checkout a new branch, sorry for the inconvenient


Noto Emoji: Add zero width joiner sequences

Adds zero width joiner sequences for each of:
u1F469+u200D+u2764+uFE0F+u200D+u1F48B+u200D+u1F468 = 1F48F
(couple kissing)
u1F469 + u200D + u2764 + uFE0F + u200D + u1F468 = u1F491
(couple with heart)
and u1F468 + u200D + u1F469 + u200D + u1F466 = u1F46A
(family)
As well as the various keycap sequences (#, 0-9)
Adds a features.fea file to define these sequences,
Adds an empty uni200D Zero Width Joiner glyph to the project,
Adds an empty uniFE0F Variation Selector 16 glyph to the project,
Modifies glyphs/contents.plist, and
Modifies lib.plist
Addresses googlei18n/noto-emoji/issues/61

This causes the Noto Emoji font to fail its build on my machine, so some review, and any input to make this build properly is appreciated.
I am running Linux Mint 18, in case that may be related to the build failure.

what I get when I run ./build setup:
mint@mint-Inspiron-518 ~/wat/noto-source $ ./build setup
Requirement already up-to-date: fonttools==3.6.2 in ./env/lib/python2.7/site-packages (from -r scripts/fontmake/requirements.txt (line 1))
Requirement already up-to-date: cu2qu==1.1.1 in ./env/lib/python2.7/site-packages (from -r scripts/fontmake/requirements.txt (line 2))
Collecting glyphsLib==1.4.0 (from -r scripts/fontmake/requirements.txt (line 3))
  Using cached glyphsLib-1.4.0-py2.py3-none-any.whl
Requirement already up-to-date: ufo2ft==0.3.2 in ./env/lib/python2.7/site-packages (from -r scripts/fontmake/requirements.txt (line 4))
Collecting MutatorMath==2.0.1 (from -r scripts/fontmake/requirements.txt (line 5))
  Using cached MutatorMath-2.0.1-py2.py3-none-any.whl
Requirement already up-to-date: defcon==0.2.1 in ./env/lib/python2.7/site-packages (from -r scripts/fontmake/requirements.txt (line 6))
Requirement already up-to-date: booleanOperations==0.6.4 in ./env/lib/python2.7/site-packages (from -r scripts/fontmake/requirements.txt (line 7))
Requirement already up-to-date: ufoLib>=2.0.0 in ./env/lib/python2.7/site-packages (from cu2qu==1.1.1->-r scripts/fontmake/requirements.txt (line 2))
Requirement already up-to-date: compreffor>=0.4 in ./env/lib/python2.7/site-packages (from ufo2ft==0.3.2->-r scripts/fontmake/requirements.txt (line 4))
Requirement already up-to-date: fontMath>=0.4.1 in ./env/lib/python2.7/site-packages (from MutatorMath==2.0.1->-r scripts/fontmake/requirements.txt (line 5))
Requirement already up-to-date: pyclipper>=1.0.5 in ./env/lib/python2.7/site-packages (from booleanOperations==0.6.4->-r scripts/fontmake/requirements.txt (line 7))
Installing collected packages: MutatorMath, glyphsLib
  Found existing installation: MutatorMath 2.0.2
    Uninstalling MutatorMath-2.0.2:
      Successfully uninstalled MutatorMath-2.0.2
  Found existing installation: glyphsLib 1.5.0
    Uninstalling glyphsLib-1.5.0:
      Successfully uninstalled glyphsLib-1.5.0
Successfully installed MutatorMath-2.0.1 glyphsLib-1.4.0
Processing ./scripts/fontmake
Requirement already up-to-date: fonttools>=3.1.2 in ./env/lib/python2.7/site-packages (from fontmake==1.1.1.dev0)
Requirement already up-to-date: cu2qu>=1.1 in ./env/lib/python2.7/site-packages (from fontmake==1.1.1.dev0)
Collecting glyphsLib>=1.1 (from fontmake==1.1.1.dev0)
  Using cached glyphsLib-1.5.0-py2.py3-none-any.whl
Requirement already up-to-date: ufo2ft>=0.2 in ./env/lib/python2.7/site-packages (from fontmake==1.1.1.dev0)
Collecting MutatorMath>=2.0 (from fontmake==1.1.1.dev0)
  Using cached MutatorMath-2.0.2-py2.py3-none-any.whl
Requirement already up-to-date: defcon>=0.2 in ./env/lib/python2.7/site-packages (from fontmake==1.1.1.dev0)
Requirement already up-to-date: booleanOperations>=0.6 in ./env/lib/python2.7/site-packages (from fontmake==1.1.1.dev0)
Requirement already up-to-date: ufoLib>=2.0.0 in ./env/lib/python2.7/site-packages (from cu2qu>=1.1->fontmake==1.1.1.dev0)
Requirement already up-to-date: compreffor>=0.4 in ./env/lib/python2.7/site-packages (from ufo2ft>=0.2->fontmake==1.1.1.dev0)
Requirement already up-to-date: fontMath>=0.4.1 in ./env/lib/python2.7/site-packages (from MutatorMath>=2.0->fontmake==1.1.1.dev0)
Requirement already up-to-date: pyclipper>=1.0.5 in ./env/lib/python2.7/site-packages (from booleanOperations>=0.6->fontmake==1.1.1.dev0)
Installing collected packages: MutatorMath, glyphsLib, fontmake
  Found existing installation: MutatorMath 2.0.1
    Uninstalling MutatorMath-2.0.1:
      Successfully uninstalled MutatorMath-2.0.1
  Found existing installation: glyphsLib 1.4.0
    Uninstalling glyphsLib-1.4.0:
      Successfully uninstalled glyphsLib-1.4.0
  Found existing installation: fontmake 1.1.1.dev0
    Uninstalling fontmake-1.1.1.dev0:
      Successfully uninstalled fontmake-1.1.1.dev0
  Running setup.py install for fontmake ... done
Successfully installed MutatorMath-2.0.2 fontmake-1.1.1.dev0 glyphsLib-1.5.0

What I get when I try to build the font:
mint@mint-Inspiron-518 ~/wat/noto-source $ ./build src/NotoEmoji/NotoEmoji-Regular.ufo
INFO:fontmake.font_project:Building TTFs
INFO:fontmake.font_project:Decomposing glyphs for NotoEmoji-Regular
INFO:fontmake.font_project:Converting curves for NotoEmoji-Regular
INFO:cu2qu.ufo:New spline lengths:

INFO:fontmake.font_project:Saving TTF for NotoEmoji-Regular
Traceback (most recent call last):
  File "/home/mint/wat/noto-source/env/bin/fontmake", line 11, in <module>
    load_entry_point('fontmake==1.1.1.dev0', 'console_scripts', 'fontmake')()
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontmake/__main__.py", line 183, in main
    ufo_paths, is_instance=args.pop('masters_as_instances'), **args)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontmake/font_project.py", line 470, in run_from_ufos
    mti_paths=mti_paths, **kwargs)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontmake/font_project.py", line 187, in build_ttfs
    self.save_otfs(ufos, ttf=True, **kwargs)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/misc/loggingTools.py", line 372, in wrapper
    return func(*args, **kwds)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontmake/font_project.py", line 286, in save_otfs
    convertCubics=False, optimizeCff=subroutinize)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/ufo2ft/__init__.py", line 42, in compileTTF
    return compileOTF(ufo, outlineCompilerClass=outlineCompilerClass, **kwargs)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/ufo2ft/__init__.py", line 31, in compileOTF
    featureCompiler.compile()
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/ufo2ft/makeotfParts.py", line 41, in compile
    self.setupFile_featureTables()
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/ufo2ft/makeotfParts.py", line 179, in setupFile_featureTables
    filename=feapath)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/builder.py", line 25, in addOpenTypeFeaturesFromString
    addOpenTypeFeatures(font, featurefile)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/builder.py", line 16, in addOpenTypeFeatures
    builder.build()
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/builder.py", line 78, in build
    self.parseTree = Parser(self.file).parse()
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 51, in parse
    statements.append(self.parse_feature_block_())
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 1063, in parse_feature_block_
    self.parse_block_(block, vertical, stylisticset, size_feature)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 1140, in parse_block_
    statements.append(self.parse_substitute_())
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 578, in parse_substitute_
    gc = self.parse_glyphclass_(accept_glyphname=True)
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 213, in parse_glyphclass_
    self.expect_symbol_("[")
  File "/home/mint/wat/noto-source/env/local/lib/python2.7/site-packages/fontTools/feaLib/parser.py", line 1245, in expect_symbol_
    self.cur_token_location_)
fontTools.feaLib.error.FeatureLibError: src/NotoEmoji/NotoEmoji-Regular.ufo/features.fea:3:69: Expected '['

I am making progress on this, got my first working ZWJ sequence down, and the font builds (couple w heart):
features.fea:
feature liga {
sub u1F469 uni200D uni2764 uni200D u1F468 by u1F491;
sub u1F469 uni200D uni2764 uniFE0F uni200D u1F468 by u1F491;
} liga;

new features.fea has all three person-related ligatures we can support with the current glyphs (family, couple w heart, couple kissing).
feature liga {
sub u1F469 uni200D uni2764 uni200D u1F48B uni200D u1F468 by u1F48F;
sub u1F469 uni200D uni2764 uniFE0F uni200D u1F48B uni200D u1F468 by u1F48F;
sub u1F469 uni200D uni2764 uni200D u1F468 by u1F491;
sub u1F469 uni200D uni2764 uniFE0F uni200D u1F468 by u1F491;
sub u1F468 uni200D u1F469 uni200D u1F466 by u1F46A;
sub u1F468 uni200D u1F469 uni200D u1F466 uni200D u1F466 by u1F468 uni200D u1F469 uni200D u1F466 uni200D u1F466;
} liga;

The only problem with this, is that it matches for "Family"(Sequence: Man+Woman+Boy+Boy) and turns it into "Family"+Boy.
The font conditional substitution and chaining rules are rather complicated, so I would appreciate some help with this, although I may be able to get it to work on my own.

Alright, it works now.
I also added the "keycap #" and "keycap [0-9]" ligatures, because the glyphs were already there for it. "*" and "Keycap *" were not present, so the ligature could not be added at this time, but it would be easy to add them in the future if the glyphs were made for it.
There is only one remaining issue: Typing a sequence: "u1F46A+ZWJ" results in "Man + Woman + Boy". I had to do that, because otherwise we will ligaturize "Man + Woman + Boy + Boy" to "Family + Boy". Thankfully no-one manually enters ZWJ sequences (at least not that I know of) and therefore it is unlikely to affect real-world users. Nonetheless, if anyone knows a better way, please let me know, or you can just directly add a commit to my repo to fix this, whatever you prefer.
That said, I think this is ready for review.
cc @brawer ?

Thank you!


defaultLocale ignored

Thanks @Thar0x for creating this issue. I'll try to recreate it locally and keep this thread up to date.


Core: Allow callbacks to be re-used and unreferenced

Maintain a local callback cache and purego wrappers to support wrapped callbacks.
Move callback handling to glib to avoid import cycles since gobject already depends on glib.
Implements the design described in https://github.com/jwijenbergh/puregotk/pull/1#issuecomment-1874747415
Depends on accompanying PR against purego: https://github.com/jwijenbergh/purego/pull/1

So just so I understand, this is only needed because we're wrapping the callback?

So just so I understand, this is only needed because we're wrapping the callback?

Correct, we map the address to the user callback to the purego callback for the wrapper, so that users can unref the cb using their local value, and we only do it for wrapped callbacks - any unwrapped callback is delivered straight to purego to handle.

The latest commit brings this into line with the latest version of https://github.com/jwijenbergh/purego/pull/1
However, it does so by breaking all current callback APIs by altering them from accepting functions to accepting function pointers. I'd quite understand if you're not keen on making this breaking change, but I've pushed it so that you can examine what it would look like.
If such a break is undesirable, we'd have to take the API duplication approach that I originally had in #1 but with function pointers instead of uintptrs for the callback args.

Thanks for spending so much time on this. I can see why function pointers would be better regarding equality checks, but I like the fact that we can use closures. Let me think about this, end of work day today :D

Rebased against main.

I like the fact that we can use closures. Let me think about this

I can understand that. We could provide duplicate APIs, but anyone who uses the non-pointer APIs is likely to encounter callback exhaustion.
For some clarity, we would still support closures with this API, they're just required to be assigned to a variable first:
var cb glib.SourceFunc
cb = func(_ uintptr) bool {
	defer glib.UnrefCallback(&cb)
	// stuff from scope
	item := newNotificationItem(n, data)
	n.addNotification(item)
	return false
}

glib.IdleAdd(&cb, 0)

Anyway, have a think about it. I've nearly finished the MVP for my holiday hackathon, and converting it (~11kloc of Go) to this API was pretty trivial.

Thoughts? This is the last thing I need to resolve before squaring away the MVP of my holiday project. As an anecdote, my project is a desktop panel/pager/taskbar/systray/notifications implementation, so lots of object/callback churn and this has been dealing with that scenario very well, multiple days of runtime with no callback exhaustion, thanks to the ability to unref.

Hi, apologies. I will try to get back to this before the end of the week. What I meant with support for closures is that we can do:
	app.ConnectActivate(func(_ gio.Application) {
		// do some stuff my lord
	})

So yes you can assign it to a var but that does make it a bit less nice. That being said I don't directly see a better solution currently so I will either merge this soon or try to come up with something else

Since purego cannot support unreferencing callbacks on Windows, if we wish to allow Windows as a target this PR will need a minor change to add some build-tags.
Either we can expose glib.UnrefCallback() only on sysv-compatible targets (which will force all consumers to add build-tagged code if they wish to take advantage of unreferencing in cross-platform applications), or we can make it a NOOP on Windows, documenting that it is non-functional on that platform.

can you update deps (GOPROXY=direct go get -u ./... && go mod tidy)
after that let's merge and improve on this later

I'm going to be unavailable for a couple of weeks travelling for work, will revisit once I'm back in-country.

I'm going to be unavailable for a couple of weeks travelling for work, will revisit once I'm back in-country.

Okay have a good travel! Will you be at fosdem in any chance?

I think I should do this, so that this can compile for Windows, though I have no way to test it - apps targeting Windows will just be subject to the Windows limitations on callback counts since they cannot unref. Dedup will work at least.
Also, since this is now a breaking change, unless you object I'd like to drop the gobject.NewCallback() wrapper in favour of glib.NewCallback(), since this functionality needs to live in glib due to the existing gobject -> glib dependency.

I've gone ahead and added these as separate commits. Ready for review.

Thanks for your work on this, one tiny nit and then it's ready to be merged

Done, appreciate your working through all this with me

Done, appreciate your working through all this with me

No worries, sorry for the late responses
Thanks a lot for this! I will re-gen ASAP


[SPARK-9459] [SQL] use generated FromUnsafeProjection to do deep copy for UTF8String and struct

When accessing a column in UnsafeRow, it's good to avoid the copy, then we should do deep copy when turn the UnsafeRow into generic Row, this PR brings generated FromUnsafeProjection to do that.
This PR also fix the expressions that cache the UTF8String, which should also copy it.

Merged build triggered.

Merged build started.

Merged build finished. Test FAILed.

Test build #1264 has started for   PR 7840 at commit 9aecb88.

Test build #1264 has finished for   PR 7840 at commit 9aecb88.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      class FromUnsafeProjection extends $

Merged build triggered.

Merged build started.

Test build #39297 has started for   PR 7840 at commit 81360b8.

Test build #39297 has finished for   PR 7840 at commit 81360b8.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      class SpecificProjection extends $

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #39319 has started for   PR 7840 at commit 8ef5b0b.

Test build #39319 has finished for   PR 7840 at commit 8ef5b0b.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      class SpecificProjection extends $

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #39333 has started for   PR 7840 at commit e095dd0.

Test build #39333 has finished for   PR 7840 at commit e095dd0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      class SpecificProjection extends $

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #39346 has started for   PR 7840 at commit fd797c9.

Test build #39346 has finished for   PR 7840 at commit fd797c9.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 public static final class BytesToBytesMapIterator implements Iterator<Location>
public abstract class UnsafeKeyValueSorter
abstract class InternalRow extends GenericSpecializedGetters with Serializable
trait GenericSpecializedGetters extends SpecializedGetters
      class SpecificProjection extends $
case class GetArrayItem(child: Expression, ordinal: Expression)
case class GetMapValue(child: Expression, key: Expression)
class ArrayBasedMapData(val keyArray: ArrayData, val valueArray: ArrayData) extends MapData
class GenericArrayData(array: Array[Any]) extends ArrayData with GenericSpecializedGetters
abstract class MapData extends Serializable
public abstract class KVIterator<K, V>

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #39378 has started for   PR 7840 at commit 230c8a1.

Test build #39378 has finished for   PR 7840 at commit 230c8a1.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      class SpecificSafeProjection extends $

Merged build finished. Test PASSed.

I'm going to merge this to unblock others (unsafe array and map).


goPackages: make it easier to automate updates

This is a new PR based on the old #13701, which merged in ee3b295 and reverted in 7760d6e (see there for commentary re: process).
To restate what this does:
What this does
This moves revisions and checksums to a separate, machine readable (specifically, JSON) file.
Why?
Presently, we have to go chasing each dependency of each go package in order to update revisions. This requires opening a browser, going to each GitHub repo, looking at the commits and tags, think long and hard about which revision to choose, open a terminal and get the sha256, then plug the revision and sha256 back into the go-packages.nix file. I tried updating the serf package by hand, and that took almost 3 hours.
Ideally, a tool would provide a central way to pull the last couple commits and tags from each GitHub repo, and either completely automatically update the package set (or a given subset, like serf and it's closure), or it would provide a UI for users that presents the revisions from upstream so you can make intelligent decisions about which revision to use (e.g. there are 4 new commits on master, but version 1.0.0 was tagged just a couple days ago... I think I'll go with tag).
However, this commit doesn't place a dependency on such tooling (in fact, none exists as of yet), so we can consider the design later.
Why JSON, and not Nix?
The Node and Haskell package sets are good examples of where we can update the whole package by regenerating the Nix expressions from scratch. That works for those ecosystems, because they have a culture of tagging releases. They also explicitly state their dependencies and the version bounds thereof. So, with minimal tweaks a separate file (e.g. pkgs/development/haskell-modules/configuration-common.nix) can extend the few troublesome packages with patches and such.
However, that doesn't work for Go packages. Go projects don't explicitly list their dependencies and version bounds. Go projects don't tag releases[1]. If we want to have any chance of updating Go packages in an assisted or automatic way, we need to know what revisions we currently package.
What this doesn't do

This does not place a dependency on a particular auto-packaging tool.
This does not make it any harder to update packages by hand.
This does not change the currently packaged versions.
This does not introduce massive rebuilds.
This does not change any interfaces in a backwards incompatible way.
This does not break any existing packages.

[1]: If you're unfamiliar with the Go ecosystem, I repeat: they don't tag releases. They don't have any sort of package repository, so they all pull from each other's  master and hope everything works out.

Maybe it's better to view the individual files in github's UI, or some unusual tool (perhaps word-diff).

Yeah, you can also look at the individual files and compare with the parent commit. But I figure it's much easier to see what exactly is going on by just looking at the patch. Conceptually, this is a really simple, mechanical change (in fact, the JSON was dumped by a program).

/cc @edolstra @copumpkin @viric @hrdinka
Feedback in the positive, negative or passive would be greatly appreciated.

and @wkennington

From @edolstra on 7760d6e:

Yeah, sorry for being a bit abrupt about reverting this, but I've learned it's better to revert quickly when dealing with commits that have a potentially high impact. (E.g. last year wkennington introduced some new derivation style that IMHO wasn't a good idea, and when I finally decided to revert that, it took me half a day to untangle the web of commits that depended on those changes. In this case there were already two commits depending on this commit. Since go-packages.nix contains hundreds of packages, )
Note I'm not necessarily opposed to this commit, but it's kind of a "strategic" change that requires some careful thought, for these reasons:

It introduces the notion of writing packages in JSON format rather than as Nix expressions. I don't know if that's something we want to promote. In any case it's a new derivation style, and those should always be carefully considered since they make it harder for people to understand / modify a package.

It introduces yet another auto-update mechanism, and we already have a lot of those, most of them only used by the person who introduced them. (E.g. gnupdate, the .upstream files, language-specific mechanisms...) This too raises the burden for someone else to modify a package because they have to figure out how the particular auto-updater for that package works. We should really come up with a universal auto-update tool, or at least a standard for what they should do (e.g. update Nix expressions in place or overwrite an external version file?).

(Slightly tangential) It further entrenches go-packages.nix, which I already objected to when it was introduced. We don't have a giant c-packages.nix for everything written in C either. Having one big file is suboptimal e.g. due to the risk of conflicts between different PRs, inability to do git log to see the history of an individual package, etc.

The meta-problem is of course that we don't have a good process for dealing with such changes. Hopefully #13602 will help a bit with that.

@edolstra

It introduces yet another auto-update mechanism, and we already have a lot of those, most of them only used by the person who introduced them. (E.g. gnupdate, the .upstream files, language-specific mechanisms...) This too raises the burden for someone else to modify a package because they have to figure out how the particular auto-updater for that package works.

With what I propose, we won't lose the ability to continue updating packages as we currently do, that is, manually. When a tool is created, I would definitely want to see it documented, so people could benefit from it. Unlike the Haskell case, however, we could continue to update packages by hand without having them clobbered and rolled back upon running an update tool (which is something I've had happen long ago when I first tried contributing something Haskell related).

It introduces the notion of writing packages in JSON format rather than as Nix expressions.

I could make the format Nix, and just parse (or evaluate) the file in the (as of yet hypothetical) tool I suggest using to update package revisions.

This too raises the burden for someone else to modify a package because they have to figure out how the particular auto-updater for that package works. We should really come up with a universal auto-update tool, or at least a standard for what they should do (e.g. update Nix expressions in place or overwrite an external version file?).

If it's possible to pull off a single, universal updater, then I agree -- that sounds great. However, I think that's a monumental effort, vs creating a few specialized tools, and providing really good documentation on how to use them (which is precisely what I intend to do once I've written such a tool, but that comes next). I would argue that the burden of needing to know how to use a tool for automated or assisted updates far outweighs the present burden of updating Go packages.

It further entrenches go-packages.nix, which I already objected to when it was introduced. We don't have a giant c-packages.nix for everything written in C either.

Speaking of burden, I think there's an important difference to keep in mind between Go and C packages. The release cycle for C libs usually spans something between months and years; the go release cycle is effectively each commit -- if you don't keep up with changes, your stuff is broken. One change in a single library causes a cascade of required version bumps. C libs have versioned releases; Go packages don't.
Trying to keep up with changes by hand is going to become an intractable ordeal as we package more Go packages. I wanted to update serf, consul and vault for a presentation I planned to give at work at the beginning of this week (totally missed that goal), and updating serf alone took over 2 hours of my time. As is evidenced by my previous work updating other C libs and apps, the C ecosystem usually requires just a couple minutes of effort to find the latest version, update the version in the nix expression (which is usually sufficient to update the url), do a quick nix-prefetch-url -A somePackage.src and plug the resulting sha256 back into the expression. In the go world, I would literally draw a pentagram on the ground and shower myself in goat's blood if it would somehow let me update Go packages that quickly.

You could try using my updater. Its not precise at adding new dependencies
or removing old ones, but it will update everything
On Thu, Mar 10, 2016 at 12:01 PM Charles Strahan<EMAIL_ADDRESS>wrote:

@edolstra https://github.com/edolstra
It introduces yet another auto-update mechanism, and we already have a lot
of those, most of them only used by the person who introduced them. (E.g.
gnupdate, the .upstream files, language-specific mechanisms...) This too
raises the burden for someone else to modify a package because they have to
figure out how the particular auto-updater for that package works.
With what I propose, we won't lose the ability to continue updating
packages as we currently do, that is, manually. When a tool is created, I
would definitely want to see it documented, so people could benefit from
it. Unlike the Haskell case, however, we could continue to update
packages by hand without having them clobbered and rolled back upon running
an update tool (which is something I've had happen long ago when I first
tried contributing something Haskell related).
It introduces the notion of writing packages in JSON format rather than as
Nix expressions.
I could make the format Nix, and just parse (or evaluate) the file in the
(as of yet hypothetical) tool I suggest using to update package revisions.
This too raises the burden for someone else to modify a package because
they have to figure out how the particular auto-updater for that package
works. We should really come up with a universal auto-update tool, or at
least a standard for what they should do (e.g. update Nix expressions in
place or overwrite an external version file?).
If it's possible to pull off a single, universal updater, then I agree --
that sounds great. However, I think that's a monumental effort, vs creating
a few specialized tools, and providing really good documentation on how to
use them (which is precisely what I intend to do once I've written such a
tool, but that comes next). I would argue that the burden of needing to
know how to use a tool for automated or assisted updates far outweighs the
present burden of updating Go packages.
It further entrenches go-packages.nix, which I already objected to when it
was introduced. We don't have a giant c-packages.nix for everything written
in C either.
Speaking of burden, I think there's an important difference to keep in
mind between Go and C packages. The release cycle for C libs usually spans
something between months and years; the go release cycle is effectively
each commit -- if you don't keep up with changes, your stuff is broken. One
change in a single library causes a cascade of required version bumps. C
libs have versioned releases; Go packages don't.
Trying to keep up with changes by hand is going to become an intractable
ordeal as we package more Go packages. I wanted to update serf, consul
and vault for a presentation I planned to give at work at the beginning
of this week (totally missed that goal), and updating serf alone took
over 2 hours of my time. As is evidenced by my previous work updating other
C libs and apps, the C ecosystem usually requires just a couple minutes of
effort to find the latest version, update the version in the nix expression
(which is usually sufficient to update the url), do a quick nix-prefetch-url
-A somePackage.src and plug the resulting sha256 back into the
expression. In the go world, I would literally draw a pentagram on the
ground and shower myself in goat's blood if it would somehow let me update
Go packages that quickly.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/pull/13819#issuecomment-195023398.

@wkennington Where is your updater hosted?

https://github.com/triton/triton/blob/master/pkgs/development/tools/godep/updatePackageAndDeps.sh
On Thu, Mar 10, 2016 at 12:18 PM Charles Strahan<EMAIL_ADDRESS>wrote:

@wkennington https://github.com/wkennington Where is your updater
hosted?
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/pull/13819#issuecomment-195030245.

@wkennington Thanks

Is this will only work for github repos? What we should do with projects hosted on bitbucket and others then?
How can we handle projects that specifies revisions of its dependecies with tools like godep or glide (eg. vault)?

@kamilchm
Hey, thanks for taking a look at this :).

Is this will only work for github repos? What we should do with projects hosted on bitbucket and others then?

As this stands, this just attempts to factor out the GitHub repos, as they represent the overwhelming majority of Go packages (there are only 4 non-GitHub packages, while there are 344 GitHub packages). I would also be fine with extending this to support other hosts, and I'm open to suggestions for how to do so (i.e. what should go-packages.json look like?).

How can we handle projects that specifies revisions of its dependecies with tools like godep or glide (eg. vault)?

That's actually something that I think needs to be discussed. For big projects that use godep to vendor their packages (and their will likely be more vendored projects when 1.6 lands in the next, due to the experimental vendoring system being turned on by default).
Personally, within the context of Go packaging, I feel a lot more comfortable using the vendored packages, as they have been vetted by the authors. I greatly appreciate your work on go2nix for this reason.  However, despite my personal feelings on the matter, this PR attempts to address the problem of managing a single set of non-vendored packages - the reason being that I think (or at least thought) that getting something like this accepted would be more likely than getting a whole bunch of vendored packages into Nixpkgs (I figured at some point that would raise some red flags, and then we'd be stuck waiting to hear about how to package really important things like hologram, vault, packer, etc...).
So some questions remain:

What are the guidelines for packaging Go stuff?
If upstream vendors their dependencies, do we provide a package separate from e.g. go-packages.nix?
Do we not use vendored dependencies?

Personally, this makes sense to me:

If an app provides vendored dependencies, use go2nix to generate a package containing the entire closure, and expose that in all-packages.nix.
For all go projects provide a unified set of packages that build - and hopefully work - together.

Whatever we do, I think we must keep in mind that the perfect is the enemy of the good. The Go community have yet to settle on any meaningful packaging/versioning story, and given the built-in support for vendoring coming up in Go 1.6, I doubt that's going to change any time soon.

On vendoring, I think it's undesirable in the context of Nix, as much as it's appealing from the "developer chose the versions" angle. That's probably a whole separate can of worms to discuss in another thread, as it's broader than just Go, but it also applies heavily to Go as you say.

@copumpkin I completely agree about it being undesirable. I'm torn, really.
Regardless, I want to reiterate that this PR is focused on how to improve the current state of affairs, where we try to provide single, curated set of Go packages.
Our Go stuff is woefully outdated, and I want an effective way to keep stuff up to date. I will soon be recording a professional-grade, free instructional course on Nix/NixOS/NixOps, and I need this stuff updated before I can finish the course outline and start recording.

Why can't we just generate nix expressions from Godeps.json files for each project ?
Maintaining one big set of working packages is not practical for any language except Haskell because they already do all the work. It's an exponential problem that's made worse by the fact that each commit is a potential candidate in go (but it's also unpractical for all the other languages IMO).
Especially for go it doesn't make much difference on the closure size since all themost dependencies are statically linked anyways.
At least by using the project's Godeps.json we will be using the exact same set of dependencies that they vetted works with the project. It means that if we have any issue to report to upstream we will also be much more credible. I think that's quite important if we want to be perceived as a reliable platform.

I have one big thing (that may fail) in mind and I hope that I find some time to challenge it next week. I want to start from the roots and extract all goPackages from all-packages.nix, then automatically create separate derivations for all of them with some format of declaring its dependencies (json,nix,..). I hope that I could merge the same dependecies from different top level projects to make final go-packages.{nix|json} then.
But I also agree with @cstrahan that the perfect is the enemy of the good. So if this PR could help us to update current packages quickly, I would merge it. As @cstrahan said it won't make it harder to update packages by hand but gives us a possibility to automate updates.

I tried to generate complete separate derivations for few big packages with go2nix. I encountered one error with Consul that needs one more change in buildGoPackage https://github.com/NixOS/nixpkgs/pull/14493. I can try to extract common dependencies for all generated packages with go2nix then.

I took me a while, but I have basic PoC of go packages rework that I'm thinking about.
It's related to https://github.com/kamilchm/go2nix that can be used for package updates then.
This is example of moving 2 programs exposed in all-packages from go-packages to separate top level derivations with reuse of Go dependencies defined in one json file than can be updated automatically https://github.com/kamilchm/nixpkgs/pull/2/files
Few thing you can see there:

Deis and Gawp derivations was generated by go2nix save, each having its all dependencies in separate deps.json files and using it instead of extraSrcs.
go2nix merge was used go2nix merge deps.json development/go-modules/libs.json to move dependencies to common libs.json and include it in deps files from step one.
Each derivation deps file include dependencies from common libs.json, but it can also define its own or override any dependency from libs.json.

Many things needs too be done, like using fetchFromGitHub and go2nix update for updates of dependencies without touching nix derivations or TDD and code refactoring. But I want to know if I'm going in the right direction?

@cstrahan what do you think about my proposal?

this pull request has been superseded.


[SPIKE] Check if it is possible to use backup and restore feature with new Epiphany version

Is your feature request related to a problem? Please describe.
In version 0.7 we have introduced backup/restore feature and we need confirmation that it works fully as expected with newer Epiphany versions.
Describe the solution you'd like
We want to confirm that backup/restore still works for the version 1.0 and newer of Epiphany and create a list of features that are currently being backed up properly and which need to be fixed.
Describe alternatives you've considered
None.
Additional context
Previously mentioned components were backed up:
https://github.com/epiphany-platform/epiphany/blob/develop/docs/home/howto/BACKUP.md#4-how-backup-and-recovery-work

DoD checklist

[ ] Ability for reader to understand results of spike is key value.
[ ] If possible, results of spike should be presented in table to show simply what are compared or researched parameters. Each value / cell should be also described more briefly later.
[ ] If possible, spike demo should be automated as much as possible.
[ ] design doc updated

For each component we need to check that both data and configuration is restored after backup.

Backup and restore works only on the same environment. The main goal was to provide backup/restore on already deployed environments
for example as an option before performing upgrade. This can be used to fix issues on existing environments with the same setup (IPs, and so on).
Procedures for backup and restore were taken from our documentation:
https://github.com/epiphany-platform/epiphany/blob/develop/docs/home/howto/BACKUP.md
Given procedure work as described in the documentation (restore of K8s hasn't been tested), but the scope and the way how they are performed should be discussed.
We will need to implement additional automation or update our documentation (with some scripts?) to use existing backup/restore solution.
For Kubernetes also previously considered in Epiphany velero seems to be an interesting option.
https://github.com/vmware-tanzu/velero
Backups for all components are by default stored on each machine and on repository host in location /epibackup/mounted.
List of generated files:
root@ec2-52-212-221-159:/epibackup/mounted# tree
.
├── grafana_data_20210716-052323.tar.gz
├── grafana_data_20210716-052323.tar.gz.sha1
├── haproxy_etc_20210715-142306.tar.gz
├── haproxy_etc_20210715-142306.tar.gz.sha1
├── haproxy_etc_20210716-050457.tar.gz
├── haproxy_etc_20210716-050457.tar.gz.sha1
├── haproxy_etc_20210716-052218.tar.gz
├── haproxy_etc_20210716-052218.tar.gz.sha1
├── k8s_snapshot_20210716-093422.tar.gz
├── k8s_snapshot_20210716-093422.tar.gz.sha1
├── postgresql_20210716-052725.tar.gz
├── postgresql_20210716-052725.tar.gz.sha1
├── postgresql_20210716-081301.tar.gz
├── postgresql_20210716-081301.tar.gz.sha1
├── prometheus_etc_20210716-052323.tar.gz
├── prometheus_etc_20210716-052323.tar.gz.sha1
├── prometheus_snapshot_20210716-052323.tar.gz
├── prometheus_snapshot_20210716-052323.tar.gz.sha1
├── rabbitmq_definitions_20210716-081704.tar.gz
├── rabbitmq_definitions_20210716-081704.tar.gz.sha1
├── rabbitmq_etc_20210716-081704.tar.gz
└── rabbitmq_etc_20210716-081704.tar.gz.sha1

Kubernetes

Backup:

Etcd snapshot
Public Key Infrastructure /etc/kubernetes/pki
Kubeadm configuration files

root@ec2-34-254-181-99:/epibackup/backup# tree
.
├── etcd-snapshot.db
├── etcd_ver.txt
├── kubeadm-config.yml
└── pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── apiserver.crt
├── apiserver.key
├── ca.crt
├── ca.key
├── ca.srl
├── etcd
│   ├── ca.crt
│   ├── ca.key
│   ├── etc-encryption.conf
│   ├── healthcheck-client.crt
│   ├── healthcheck-client.key
│   ├── peer.crt
│   ├── peer.key
│   ├── server.crt
│   └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub
Restore:
No restore option. Restore needs to be performed manually.

HA Proxy
Backup:

configuration
certificates

root@ec2-54-74-170-183:/epibackup/backup# tree
.
├── haproxy
│   ├── dhparam
│   └── haproxy.cfg
└── ssl
└── haproxy
└── self-signed-test.tld.pem
Restore:
Restores properly configuration files and certificate.

Monitoring

Backup:
Backups properly configuration files and data.
root@ec2-34-249-254-105:/epibackup/backup-grafana# tree
.
├── dashboards
├── grafana.db
├── plugins
└── png
root@ec2-34-249-254-105:/epibackup/backup-prometheus-etc# tree
.
├── file_sd
│   ├── haproxy-exporter-ec2-54-74-170-183.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-18-202-240-19.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-3-248-202-204.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-3-250-163-76.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-240-68-31.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-241-191-248.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-244-4-159.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-249-254-105.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-250-26-26.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-34-254-181-99.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-52-212-221-159.eu-west-1.compute.amazonaws.com.yml
│   ├── node-ec2-54-74-170-183.eu-west-1.compute.amazonaws.com.yml
│   └── postgres-exporter-ec2-3-250-163-76.eu-west-1.compute.amazonaws.com.yml
├── prometheus.yml
└── rules
root@ec2-34-249-254-105:/epibackup/backup-prometheus-snapshot# tree
.
├── 01FAP6C0EAX85JDGS9Q2GH712T
│   ├── chunks
│   │   └── 000001
│   ├── index
│   ├── meta.json
│   └── tombstones
├── 01FAPM3DMQRF61SD4EGCJZ4FFD
│   ├── chunks
│   │   └── 000001
│   ├── index
│   ├── meta.json
│   └── tombstones
├── 01FAPM3FCFZ7RHHFNH0Q2SKGR8
│   ├── chunks
│   │   └── 000001
│   ├── index
│   ├── meta.json
│   └── tombstones
├── 01FAPTZ4WBRJJ64FTACXER7PZ5
│   ├── chunks
│   │   └── 000001
│   ├── index
│   ├── meta.json
│   └── tombstones
└── 01FAPWA2CJ4KQHMT8X5HVHFJ7X
├── chunks
│   └── 000001
├── index
├── meta.json
└── tombstones
Restore:
Restores configuration files with data.

Postgresql

Backup:
Performs backup of configuration and databases.
Paths are right now related to postgres 10 so need to be update after posgres upgrade.
root@ec2-3-250-163-76:/epibackup/backup# tree
.
├── configs
│   ├── pg_ctl.conf
│   ├── pg_hba.conf
│   ├── pg_ident.conf
│   ├── postgresql-epiphany.conf
│   ├── postgresql.conf
│   └── start.conf
└── data
└── database_dump.sql
Restore:
Performs only restore of the databses without restoring the configuration.
If the configuration is broken it needs to be manually restored.

Rabbitmq

Backup:
Backups configuration and messages definitions without messages.
root@ec2-34-241-191-248:/epibackup/backup-definitions# tree
.
└── definitions-20210716-081704.json
root@ec2-34-241-191-248:/epibackup/backup-etc# tree
.
├── enabled_plugins
├── rabbitmq-env.conf
└── rabbitmq.conf
Restore:
Restores configuration and messages definitions without messages.

Logging

Backup:
Needs security implemented to work with Open Distro.
Restore:
Needs security implemented to work with Open Distro.

For K8s, shouldn't we at least try to do a manual restore to see what we backup is actually enough?
Rest looks ok.

Do we know what are required changes for OpenDistro?
Do we know why PostgreSQL configuration files are not restored?
Did you remove machines? In prometheus section IPs are visible.
Do I see it correctly that each component backups to different "random" directory?
Can you describe what would be required to fix to allow restore on new infrastructure?

@seriva From the point of restore I think that we should look for different solution than existing one in Epiphany. Right now I think that we should focus on finding the new backup solution for K8s.

@mkyc

Do we know what are required changes for OpenDistro?
Yes, we need to add authentication to backup.
Do we know why PostgreSQL configuration files are not restored?
According to @plirglo this should be done manually as it can be problematic sometimes during restoring cluster.
Did you remove machines? In prometheus section IPs are visible.
No, I have remove and restore the whole blocks of data on disk.
Do I see it correctly that each component backups to different "random" directory?
No, they are stored in /tmp/epibackup on given server and also in the directory /tmp/epibackup/mounted as tar.gz files. Here I just have extracted tar.gz and give meaningful names to extracted folder to easier distinct what is what.
Can you describe what would be required to fix to allow restore on new infrastructure?
The thing that doesn't work at the moment is Open Distro, because of lack of authentication and we should probably find a new way to backup Kubernetes.

Ok LGTM.


extending image with s2i: proxy env variables for build only?

Hello
I have another Problem when extending the jenkins image via s2i.
I added the following settings to the build config:
[...]
		"strategy": {
			"sourceStrategy": {
				"env": [
					{
						"name": "https_proxy",
						"value": "proxy:3128"
					},
					{
						"name": "http_proxy",
						"value": "proxy:3128"
					},
					{
						"name": "no_proxy",
						"value": "openshift.default.svc.cluster.local,localhost"
					}
[...]

Why? I need to use a proxy in order to download the additional plugins from jenkins-ci
Whats the problem?
The problem is, that these env variables also exist in the running image and not onyl the builder. This forces me, to have an exessive long no_proxy host list (partial wildcards like *.interndon't work), so i have to list EVERY possible internal host.
So my Question:
Is there a way, to have these proxy settings only while assembling the image? Or unset them after that?
I don't want to copy the complete run script just to extend it with the line unset https_proxy.
Any suggestions?
Thanks
Dakky

you can update the deploymentconfig to set http_proxy/etc to "" in your pod template.
but no, there is no way to set env variables at build time only today.  they will always exist in the final image.  so you have to override the value in the deploymentconfig for the image if you don't like that value.

a that was easy :D thanks


Investigate tooltip lighthouse error

Lighthouse is giving an "ARIA tooltip nodes must have an accessible name" error for the post-tooltip:
https://dequeuniversity.com/rules/axe/4.9/aria-tooltip-name
### Tasks
- [ ] Check with a screenreader if tooltip is being read
- [ ] Check lighthouse test and try to fix the issue

Check if we can implement <post-popovercontainer> to be visually hidden only (for tooltip, not for popover).


Priority of using .then() when I try to Get Text of web element

Hi All,
when I try to Get Text of web element , I made it in 2 technique . one of those style with .then() like below
firstApproach
let expecttedHeaderH1=element(by.css(''locator')).getText();
let actualText="Actual text";
expectedHeaderH1.then(function(expectedText){
expect(expectedText).toequal(actualText);
});
secondApproach
let expecttedHeaderH1=element(by.css(''locator')).getText()
let actualText="Actual text";
expect(expectedText).toequal(actualText);
and other Approach I made it without using promises.then and also works fine ! I wonder from this technique because as I know that protractor make webdriverJs uses an object called the ControlFlow, which coordinates the scheduling and execution of commands operating on a queue and each call that interacts with the browser, such as get(), findElement(), sendKeys(), and click(), is being scheduled and pushed onto the WebDriver ControlFlow, allowing us to not have to worry about using .then() on the resulting promises.
Please Advice when I should .then() in a Protractor

getText returns a promise, so you should always use then to reliably resolve that call to a value.
Hi there!
Additionally, your question is better suited for StackOverflow or Gitter. In the future, please ask a question there with the 'protractor' tag or post in the Gitter Channel to get help.
From the the getting help section of the README:

Please ask usage and debugging questions on StackOverflow (use the "protractor" tag) or in the Angular discussion group. (Please do not ask support questions here on Github.)

Thanks!