Ensuring that a given axis is always used in a consistent grid position

Reported by ansley b manke on 15 Dec 2010 23:44 UTC
Some datasets have dimensions or coordinate variables that don't explicitly tell Ferret their direction. In such cases the flag line_direction(line) gets the value of 'NA' and then when the grids are created, the axis might take on different directions for variables in the dataset.  This can cause troubles in f-tds.
Here's a short cdl file, where the axes bbb and ccc have no defined direction. The behavior is similar if the dimensions do not have corresponding coordinate variables - though we need to work out the behavior in both cases.
netcdf ambiguous {
dimensions:
	bbb = 3 ;
	ccc = 5 ;
variables:
	float E(ccc, bbb) ;
		E:missing_value = -1.e+34f ;
		E:_FillValue = -1.e+34f ;
		E:long_name = "2D variable (ccc,bbb)" ;
	float F(bbb) ;
		F:missing_value = -1.e+34f ;
		F:_FillValue = -1.e+34f ;
		F:long_name = "1D in bbb dimension" ;
	float G(ccc) ;
		G:missing_value = -1.e+34f ;
		G:_FillValue = -1.e+34f ;
		G:long_name = "1D in ccc dimension" ;
	double bbb(bbb);
		bbb:point_spacing = "even" ;
		bbb:point_spacing = "even" ;
	double ccc(ccc);
		ccc:point_spacing = "even" ;

// global attributes:
		:history = "FERRET V6.65   15-Dec-10" ;
		:Conventions = "CF-1.0" ;
data:

 bbb =
  1, 2, 3 ;

 ccc =
  1, 2, 3, 4, 5 ;

 E =
  2, 3, 4,
  3, 4, 5,
  4, 5, 6,
  5, 6, 7,
  6, 7, 8 ;

 F = 2, 4, 6 ;

 G = 1, 2, 3, 4, 5 ;

}

Opening the corresponding nc file, the SHOW DATA has the ccc dimension being used as the X axis in some variables, and the Y axis in another.
yes? use ambiguous.nc
yes? sh dat
     currently SET data sets:
    1> ./ambiguous.nc  (default)
 name     title                             I         J         K         L
 E        2D variable (ccc,bbb)            1:3       1:5       ...       ...
 F        1D in bbb dimension              1:3       ...       ...       ...
 G

The approach advocated below is based on the following:

   1. line (aka axis) orientations of "NA" are OK.  A non-"NA" line orientation should be assigned (in cd_get_1_axis) only when there is firm evidence to support the conclusion
   2. if a netCDF file is interpreted correctly then any given axis should be found in the same idim position in every grid
   3. we will create new code to resolve simple ambiguities in the placement of "NA" axes into grids.  We can correct only problems that can be fixed by "sliding" an axis to one side or another in the grid.
          * this is the case in Rich's file where we have two "NA" axes, "boundary" and "tracer".  The ambiguity of having (boundary, tracer) in grid1 and (tracer) alone in grid2 can be resolved by sliding "tracer" over to slot 2 in grid2

   1. in cd_get_1_axis when determining the orientations of axes (setting of line_direction)
         1. test appropriate standard_name strings (e.g. for sigma levels)
         2. remove weak inferences of orientation
                * remove the block of code below:  "* If still undefined,
                  try the starting letter."  (though shall we still interpret axes
                  named with the single letters X, Y, Z, T as axes in those
                  directions?)
                * If you find other weak inferences of orientation lets talk about
                  them.

   2. in cd_init_dset just after cd_get_parent_grid.F has been called, call this
      new routine: CD_CONSISTENT_AXIS_ORIENTATION
         1. scan the grids just created for this dataset to generate a list of any
            axes that occupy different idim positions in different grids.
         2. if multiply-oriented axes are found
                * (START)  if the axis is of known orientation issue a warning and
                  do not try to fix
                * if the axis is of "NA" orientation then try this simple (tho not
                  fool-proof) algorithm:
               1. choose the first grid where the axis is found as grid1
               2. let pos1 be the position of the axis in grid1
               3. set adjustment_success flag to TRUE
               4. for each other grid (always including the full list of this
                  dataset's grids )
                      * if grid has this axis in a different position then
                            o let pos2 be the position of the axis in grid2
                            o in grid2 if pos1 and all positions between pos1 and
                              pos2 are unoccupied
                              (** or are occupied by other "NA" axes)
                                  + then
                                        # shift the axis in question from pos2 to
                                          pos1
                                  + else
                                        # set adjustment_success flag to FALSE
               5. if adjustment_success is FALSE, find the next grid where the axis
                  is found and go back to #2.  If no next grid exists, give up on
                  adjustments and issue a warning about ambiguous orientations of
                  this axis.
               6. if adjustment_success is TRUE, move to the next multiply-oriented
                  axis and go back to START.  IF no more, then we're done.

** Note above where it says "** or are occupied by other "NA" axes" that it can be desirable to shift other "NA" axes.   For example if grid1 has axes (na1, na2, na3)  and grid2 has (na2, na3) it would be desirable to shift both na2 and na3 axes to the right by one idim position in grid2.  The simple algorithm above needs to be enhanced to allow this. Suppress the warnings, and repeat the entire algorithm from #1 above START any time you shift an axis other than the current multi-oriented axis.  And then you have to include a trap to make sure that you don't repeat the process more than (say) 4 times.  Else (I suspect) you could become caught in an infinite loop.

The above neglects the possibility of a permuted grid. Probably implement non-permuted grids, first and then look at the possibility of permuted ones. The logic of "sliding an axis to one side or the other in the grid" needs to be considered in the context of the permutation.

The bad news is that the permutation logic is, itself, not clean.  (The routine tm_axis_order.F has the gory details.  The good news is that permutation is rarely anything other than the default 1-2-3-4).   idim slots must be neighbors in the sense of the permutation array to allow shifting.   This is a nasty problem.  Key to understanding it will be having some concrete examples to work from.  For example

example file #1:

    * var1(tracer, lon,lat)
    * var2(tracer)

example file #2:

    * var1(tracer,lat,lon)
    * var2(tracer)

Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1774

Modified by ansley.b.manke on 5 Jan 2011 18:22 UTC

Comment by ansley.b.manke on 20 Jan 2011 21:27 UTC
I have this working. The grids for the dataset are checked, and axis positions moved if they are inconsistent. The issue of permutations needs more testing; what I have done is to make axis positions consistent and then apply the user-supplied ordering. This works for the cases I've tried, but as Steve notes it's not entirely clear how that should be done.

Modified by ansley.b.manke on 20 Jan 2011 21:28 UTC

Comment by ansley.b.manke on 28 Jan 2011 01:03 UTC
Fixed in the ferret_v67beta executable installed on Dunkel and Stout. The issue of permutations needs further testing but I think it works consistently.

Comment by ansley.b.manke on 29 Feb 2012 00:26 UTC
Reopening.  Reported by Josefine Ghattas, a colleague of Patrick Brockmann.
When an axis in the netCDF file is reversed ( here a Y-axis listed with coordinates as follows: rlatu = 1.55, 1.52, 1.48, ...,  -1.48, -1.52, -1.55 ;  )
and two datasets that use the same grids are opened, the reversed-character of the axis is not applied to the second dataset. The information is lost when doing the consistent-axis-ordering fixes here. The dataset has a dimension with ambiguous direction, SIGS, so the code to figure out a consistent axis ordering is called.
I created a subset of the datset, see short_data.nc attached to this ticket. Here is an example:
yes? use short_data.nc
yes? sh dat
     currently SET data sets:
    1> ./short_data.nc  (default)
 name     title                             I         J         K         L
 UCOV     UCOV                             1:6       1:9       1:3       1:1
 CONTROLE CONTROLE                         1:6       ...       ...       ...
 NIVSIGS  NIVSIGS                          ...       ...       1:3       ...
 NIVSIG   NIVSIG                           1:6       ...       ...       ...
 AP       AP                               1:6       ...       ...       ...

yes? sp cp short_data.nc short_copy.nc
yes? use short_copy.ncyes? list/k=3/i=1 ucov[            VARIABLE : UCOV
             FILENAME : short_data.nc
             SUBSET   : 9 points (Y)
             X        : 1
             Z        : 3
             TIME     : 08-JAN-1980 00:00
                1.014
                 1
 -1.554 / 1: -642176.
 -1.521 / 2: -621550.
 -1.488 / 3: -700065.
 -1.455 / 4: -640073.
 0.033  / 5: -375011.
 1.455  / 6: -153460.
 1.488  / 7:   10663.
 1.521  / 8:   60693.
 1.554  / 9:       0.
yes? list/k=3/i=1 ucov[d=2](d=1]
)
             VARIABLE : UCOV
             FILENAME : short_copy.nc
             SUBSET   : 9 points (Y)
             X        : 1
             Z        : 3
             TIME     : 08-JAN-1980 00:00
                1.014
                 1
 -1.554 / 1:       0.
 -1.521 / 2:   60693.
 -1.488 / 3:   10663.
 -1.455 / 4: -153460.
 0.033  / 5: -375011.
 1.455  / 6: -640073.
 1.488  / 7: -700065.
 1.521  / 8: -621550.
 1.554  / 9: -642176.

What happens is that cd_consistent_axis_orient.F has been trying to use the an array of logicals marking the axis "reversed". That's set when initializing the first datset from which the axis is read. When looking at the grid for the variable in the second dataset, Ferret has determined that the axes match, but that "reversed" flag is no longer set for an axis that came in from the first datset. The grid has been created, and the info we need is stored in another variable, ds_ordering, which cd_consistent_axis_orient.F can use instead.

Attachment from ansley.b.manke on 29 Feb 2012 00:25 UTC
the file for reversed-axis example
REPLACE THIS TEXT WITH UPLOADED FILE ./attachments/TRAC_1774_GIT_1046/short_data.nc

This last issue with reversed axes is the same as the report in #1941, closed.


Make Danger work well with --package-path

Warnings

:warning:

Any changes to library code should be reflected in the Changelog.
Please consider adding a note there and adhere to the Changelog Guidelines.

:warning:

Sources/Runner/Commands/RunDangerJS.swift#L5 - Function body should span 40 lines or less excluding comments and whitespace: currently spans 42 lines (function_body_length)

:warning:

Sources/RunnerLib/Runtime.swift#L38 - TODOs should be resolved (Support running from a fork?). (todo)

  Generated by :no_entry_sign: Danger Swift against 7629898cca0d4087ced03d028e8013ff9412d2e6


Cards for pets info

We can improve the visibility by displaying the pet info in a responsive flip card.

I can create responsive and animated pet cards that will draw users to this website.

I want to work on this issue under GSSoC'23. Please assign me this.


networking.nameservers does not work with networkmanager

Issue description
I wanted to switch my dns server. After searching through man configuration.nix, it seemed that the option to set for that would be networking.nameservers. It didn't have any effect though. I assume that is because I use networkmanager. Using networkmanager.insertNameservers instead had the effect I wanted (confirmed by cat /etc/resolv.conf). This is at best confusing for users.
Steps to reproduce
networking = {
	networkmanager.enable = true;
	nameservers = [ "<IP_ADDRESS>" ];
	# networkmanager.insertNameservers = [ "<IP_ADDRESS>" ];
};

Technical details

system: "x86_64-linux"
host os: Linux 4.19.41, NixOS, 19.09pre179224.8e1852ac7e7 (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.2.2
channels(root): "nixos-19.09pre179224.8e1852ac7e7, nixos-unstable-small-19.09pre179138.9d208b26995, pkgs-unstable-19.09pre178895.9ebc6ad944c, unstable-19.09pre179224.8e1852ac7e7"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

This works for me:
networking.networkmanager.enable = true;
networking.nameservers = [ "<IP_ADDRESS>" "<IP_ADDRESS>" ];

What do you mean by "works"? What does cat /etc/resolv.conf show?

At boot it shows:
# Generated by NetworkManager
nameserver <whatever is pushed by my dhcp server>

When I do a nixos-rebuild --siwtch:
# Generated by resolvconf
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
options edns0

So "it works" but in fact NetworkManager will override it most of the time.

so it seems networking.insertNameservers != networking.nameservers after all. We should have a "debug" mode :
# Generated by resolvconf
# Set by networking.nameservers
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
# networking.dnsExtensionMechanism
options edns0

:D (edns still fails regularly for me)

So it seems like it would be a good idea to either  use networking.nameservers in the networkmanager configuration or at least alert the user when networking.nameservers is set and networkmanager is enabled.

How to setup static nameservers for no daemon wipe them:
https://github.com/NixOS/nixpkgs/issues/61490#issuecomment-492277879


Custom activity indicator issue Swift 4

Check List
Thanks for considering to open an issue. Before you submit your issue, please confirm these boxes are checked.

[x] I have read the wiki page and cheat sheet, but there is no information I need.
[x] I have searched in existing issues, but did not find a same one.
[x] I want to reoprt a problem instead of asking a question. It'd better to use kingfisher tag in Stack Overflow to ask a question.

Issue Description
When creating struct conforming to Indicator protocol as described in Cheat Sheet the view is empty and nothing happens.
What
The func startAnimatingView() never gets called and logging imageView.kf.indicator prints out nil.
Reproduce
override func viewDidLoad() {
    super.viewDidLoad()
    //Set image
    struct MyIndicator: Indicator {
        let view: UIView = UIView(frame: CGRect(x: 0, y: 0, width: 50, height: 50))

        func startAnimatingView() { print("start"); view.isHidden = false }
        func stopAnimatingView() { view.isHidden = true }

        init() {
            view.backgroundColor = UIColor.blue
        }
    }

    galleryImageView.kf.indicatorType = .custom(indicator: MyIndicator())
    galleryImageView.kf.setImage(with: media.image, completionHandler: { (image,error, cacheType, url) in
        if let image = image {
            let scale = image.scale
            self.imageWidthConstraint.constant = image.size.width * scale
            self.imageHeightConstraint.constant = image.size.height * scale
            self.updateMinZoomScaleForSize(self.view.bounds.size)
            self.updateConstraintsForSize(self.view.bounds.size)
            self.scrollView.setZoomScale(self.minimumZoomScale, animated: false)
            self.view.setNeedsLayout()
            self.view.layoutIfNeeded()
        }
    })

Other Comment
Am I doing something wrong here, or is this an issue with the current version of swift or something.
Thanks in advance.

@alfasolutions It seems that associated object does not work well with Swift protocol, even it is marked to receive Any? now.
A workaround is in #878 and I think we could release it later as an update.

Thanks for reporting this!

Thanks for resolving the issue.
@onevcat When are you going to release a new version?

@chyrta Sorry for the delay. But I guess I could not do a release until approximate 10hrs later. I would release it tonight (JST)!

@onevcat Nice to hear that. Thanks for maintaining this cool library 👍

hello. my custom indicator position is wrong. is this issue fixed? i made it as instructed in the documentation.
`struct ImageIndicator: Indicator {
let view: UIView = UIView()
let lottie = LOTAnimationView(name: "mamaLoader")
func startAnimatingView() {
    view.isHidden = false
    lottie.play()
}
func stopAnimatingView() {
    lottie.stop()
    view.isHidden = true
}

init() {
    view.backgroundColor = .clear
    view.layout(lottie).topBottom().leftRight()
}

}`


No aria suggestions for on react element when suggestions are manually triggered

From https://github.com/microsoft/vscode/issues/97220
TypeScript Version:  4.0.0-dev.20200708

Search Terms:

jsx
react
aria
suggest / suggestions / completions

Code
For the TS
import * as React from 'react';

export const a = (

)

After the classname attribute:

Manually trigger suggestions.
Type aria

Expected behavior:
Suggestions for aria show up
Actual behavior:
No suggestions.
In my testing, the suggestions do show up in a few different cases:

When you manually trigger suggestions before className
When you start typing to trigger suggestions

If the aria- tags are defined, it should just be a matter of refining our completion filtering logic.

Following this issue... is it resolved?

😆Apparently no.

Thanks @Zzzen!


set opacity=0.01 and add more meta data

Yup agreed. It was only there to allay your concerns that it wasn't a
proper page. :P
On 28 Nov 2017 9:05 am, "LoneRifle"<EMAIL_ADDRESS>wrote:

@LoneRifle commented on this pull request.
In src/index.js
https://github.com/datagovsg/beeline-frontend-proxy/pull/5#discussion_r153369545
:

@@ -64,20 +64,29 @@ const listener = async (req, res) => {
const response = payload
.replace('', `

${h(routeData.label)}: ${h(routeData.from)} – ${h(routeData.to)}

${h(routeData.schedule)}

Your browser is unable to display this page correctly.

Download the Beeline app for your phone and book this route today!

${h(routeData.label)}: ${h(routeData.from)} – ${h(routeData.to)}

${h(routeData.schedule)}

Your browser is unable to display this page correctly.

I don't know if we really need this.. The call to action to download
Beeline from the store should be good enough to hint to the user that he
won't be able to do this through his browser. Removing this should give us
more room to put relevant things into our snippet
@artylope https://github.com/artylope @xkjyeah
https://github.com/xkjyeah - thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/datagovsg/beeline-frontend-proxy/pull/5#pullrequestreview-79364163,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACiTR7lx4egFV1WBEDPuAmZc2c3XZvnVks5s61xMgaJpZM4QrRkv
.


Use Path2D, if available, when rendering Type3-fonts (bug 810214)

Note that in order to avoid unnecessary allocations we build the Path2D-object inline during parsing, rather than iterating through the complete outlines-Array at the end.
This patch was tested using the PDF file from bug 810214, i.e. https://bug810214.bmoattachments.org/attachment.cgi?id=9254990, with the following manifest file:
[
    {  "id": "bug810214",
       "file": "../web/pdfs/bug810214.pdf",
       "md5": "2b7243178f5dd5fd3edc7b6649e4bdf3",
       "rounds": 100,
       "lastPage": 25,
       "type": "eq"
    }
]

which gave the following results when comparing this patch against the master branch:

Overall

-- Grouped By browser, stat --
browser | stat         | Count | Baseline(ms) | Current(ms) | +/- |     %  | Result(P<.05)
------- | ------------ | ----- | ------------ | ----------- | --- | ------ | -------------
firefox | Overall      |  2500 |          123 |          78 | -44 | -36.25 |        faster
firefox | Page Request |  2500 |            2 |           2 |   0 |   9.11 |        slower
firefox | Rendering    |  2500 |          121 |          76 | -45 | -36.93 |        faster

Page-specific

-- Grouped By browser, page, stat --
browser | page | stat         | Count | Baseline(ms) | Current(ms) | +/- |     %  | Result(P<.05)
------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ------ | -------------
firefox | 0    | Overall      |   100 |           36 |          35 |  -1 |  -2.89 |
firefox | 0    | Page Request |   100 |            2 |           2 |   0 |   7.33 |
firefox | 0    | Rendering    |   100 |           34 |          33 |  -1 |  -3.47 |
firefox | 1    | Overall      |   100 |          123 |          81 | -42 | -33.92 |        faster
firefox | 1    | Page Request |   100 |            2 |           2 |   0 |  -3.31 |
firefox | 1    | Rendering    |   100 |          121 |          79 | -42 | -34.44 |        faster
firefox | 2    | Overall      |   100 |          129 |          82 | -47 | -36.61 |        faster
firefox | 2    | Page Request |   100 |            2 |           2 |   0 |  24.84 |        slower
firefox | 2    | Rendering    |   100 |          127 |          80 | -47 | -37.33 |        faster
firefox | 3    | Overall      |   100 |          114 |          68 | -46 | -40.18 |        faster
firefox | 3    | Page Request |   100 |            2 |           2 |   0 |  15.63 |        slower
firefox | 3    | Rendering    |   100 |          112 |          66 | -46 | -41.07 |        faster
firefox | 4    | Overall      |   100 |          102 |          75 | -27 | -26.09 |        faster
firefox | 4    | Page Request |   100 |            2 |           2 |   0 |   9.62 |
firefox | 4    | Rendering    |   100 |          100 |          73 | -27 | -26.71 |        faster
firefox | 5    | Overall      |   100 |          103 |          77 | -26 | -25.15 |        faster
firefox | 5    | Page Request |   100 |            2 |           2 |   0 |  -6.86 |
firefox | 5    | Rendering    |   100 |          100 |          75 | -26 | -25.53 |        faster
firefox | 6    | Overall      |   100 |           48 |          37 | -11 | -22.56 |        faster
firefox | 6    | Page Request |   100 |            2 |           2 |   0 | -10.14 |
firefox | 6    | Rendering    |   100 |           46 |          35 | -11 | -23.16 |        faster
firefox | 7    | Overall      |   100 |          109 |          70 | -39 | -35.59 |        faster
firefox | 7    | Page Request |   100 |            2 |           2 |   0 |   5.29 |
firefox | 7    | Rendering    |   100 |          107 |          68 | -39 | -36.23 |        faster
firefox | 8    | Overall      |   100 |           39 |          31 |  -9 | -22.14 |        faster
firefox | 8    | Page Request |   100 |            2 |           2 |   0 |   1.72 |
firefox | 8    | Rendering    |   100 |           38 |          29 |  -9 | -23.38 |        faster
firefox | 9    | Overall      |   100 |          156 |          96 | -60 | -38.49 |        faster
firefox | 9    | Page Request |   100 |            1 |           2 |   0 |  13.61 |
firefox | 9    | Rendering    |   100 |          155 |          94 | -60 | -38.98 |        faster
firefox | 10   | Overall      |   100 |          173 |         105 | -68 | -39.20 |        faster
firefox | 10   | Page Request |   100 |            2 |           2 |   0 |  -8.81 |
firefox | 10   | Rendering    |   100 |          171 |         103 | -68 | -39.60 |        faster
firefox | 11   | Overall      |   100 |          152 |          89 | -64 | -41.88 |        faster
firefox | 11   | Page Request |   100 |            2 |           2 |   0 |   6.04 |
firefox | 11   | Rendering    |   100 |          150 |          87 | -64 | -42.47 |        faster
firefox | 12   | Overall      |   100 |          141 |          90 | -51 | -35.91 |        faster
firefox | 12   | Page Request |   100 |            2 |           2 |   0 |  17.37 |
firefox | 12   | Rendering    |   100 |          139 |          88 | -51 | -36.60 |        faster
firefox | 13   | Overall      |   100 |           97 |          61 | -36 | -36.79 |        faster
firefox | 13   | Page Request |   100 |            2 |           2 |   0 |  25.44 |        slower
firefox | 13   | Rendering    |   100 |           95 |          59 | -36 | -37.87 |        faster
firefox | 14   | Overall      |   100 |          118 |          82 | -36 | -30.33 |        faster
firefox | 14   | Page Request |   100 |            2 |           2 |   0 |   9.20 |
firefox | 14   | Rendering    |   100 |          117 |          80 | -36 | -30.95 |        faster
firefox | 15   | Overall      |   100 |          111 |          73 | -37 | -33.85 |        faster
firefox | 15   | Page Request |   100 |            2 |           2 |   0 |  13.25 |
firefox | 15   | Rendering    |   100 |          109 |          71 | -38 | -34.61 |        faster
firefox | 16   | Overall      |   100 |          145 |          88 | -57 | -39.19 |        faster
firefox | 16   | Page Request |   100 |            2 |           2 |   1 |  33.75 |        slower
firefox | 16   | Rendering    |   100 |          143 |          86 | -57 | -40.03 |        faster
firefox | 17   | Overall      |   100 |          171 |         126 | -45 | -26.27 |        faster
firefox | 17   | Page Request |   100 |            2 |           2 |   0 |  17.92 |        slower
firefox | 17   | Rendering    |   100 |          169 |         124 | -45 | -26.69 |        faster
firefox | 18   | Overall      |   100 |          126 |          78 | -47 | -37.71 |        faster
firefox | 18   | Page Request |   100 |            2 |           2 |   0 |   2.43 |
firefox | 18   | Rendering    |   100 |          124 |          76 | -48 | -38.43 |        faster
firefox | 19   | Overall      |   100 |           92 |          58 | -34 | -37.19 |        faster
firefox | 19   | Page Request |   100 |            2 |           2 |   0 |  12.74 |
firefox | 19   | Rendering    |   100 |           90 |          56 | -35 | -38.13 |        faster
firefox | 20   | Overall      |   100 |          178 |          96 | -82 | -46.18 |        faster
firefox | 20   | Page Request |   100 |            2 |           2 |   0 |  -2.23 |
firefox | 20   | Rendering    |   100 |          176 |          94 | -82 | -46.67 |        faster
firefox | 21   | Overall      |   100 |          181 |         102 | -79 | -43.77 |        faster
firefox | 21   | Page Request |   100 |            2 |           2 |   0 |  12.36 |        slower
firefox | 21   | Rendering    |   100 |          179 |          99 | -79 | -44.34 |        faster
firefox | 22   | Overall      |   100 |          140 |          84 | -55 | -39.59 |        faster
firefox | 22   | Page Request |   100 |            2 |           2 |   0 |  12.50 |
firefox | 22   | Rendering    |   100 |          138 |          82 | -55 | -40.25 |        faster
firefox | 23   | Overall      |   100 |          119 |          73 | -46 | -38.48 |        faster
firefox | 23   | Page Request |   100 |            2 |           2 |   1 |  35.71 |        slower
firefox | 23   | Rendering    |   100 |          117 |          71 | -46 | -39.48 |        faster
firefox | 24   | Overall      |   100 |          165 |          96 | -68 | -41.51 |        faster
firefox | 24   | Page Request |   100 |            2 |           2 |   0 |   2.81 |
firefox | 24   | Rendering    |   100 |          163 |          94 | -68 | -42.00 |        faster

/botio test

Would it be possible to build the paths in the worker ? would it be useful to do that if possible ?

Would it be possible to build the paths in the worker ?

Well, it doesn't actually seem possible to send a Path2D-object via postMessage according to some quick tests (it's not supported by the structured cloning algorithm as far as I can tell). Hence it seems like the answer is NO, and looking at all of the Type3-code in canvas.js it probably wouldn't have been exactly trivial anyway.

would it be useful to do that if possible ?

I'm actually not so sure if would've helped much, had it worked, considering that:

Type3-fonts are, thankfully, not all that common in PDF documents. It seems that we're no longer collecting the relevant Telemetry-data, since the most recent data I could find is a bit old.
Type3-fonts are already, thanks to the pre-existing compiling and caching on first use, rendered fairly quickly.
With this patch, the rendering time in real world test-cases is reduced even further.

Out of curiosity, what makes Path2D so much faster here? AFAICT in the previous code we populated an array and looped over that at the end to perform the drawing instructions, while we now make a Path2D object where we do the same operations on so it seems, so it it purely the prevention of the array creation/loop that saves so much here or is Path2D doing something else more efficiently?

Is it purely the prevention of the array creation/loop that saves so much,

While I obviously don't know, this is likely more-or-less completely unrelated to the performance improvements.

or is the fact that all drawing instructions are now being performed on the canvas object in one go instead of individually,

That'd rather be the most likely explanation, as far as I understand things.
In the old code we'd apply lots of moveTo/lineTo operators individually during rendering, whereas with Path2D all those instructions are applied at once instead (and thus allowing the browser to optimize things a fair bit). Also, everytime that we render one specific Type3-glyph we're now also using the same identical Path2D-object.

/botio test


Vickel: Watch getintopc.ink

Vickel requests the watch of the watch_keyword getintopc\.ink. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

getintopc\.ink has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Create pythonptbr.md curse of python in pt br

Hacktoberfest notes:

due to volume of submissions, we may not be able to review PRs that do not pass tests and do not have informative titles.
please read our contributing guidelines
be sure to check the output of Travis-CI for linter errors
if this is your first open source contribution, make sure it's not your last!

What does this PR do?
Add Resource(s) | Remove Resource(s) | Add info | Improve Repo
For resources
Description
Why is this valuable (or not)?
How do we know it's really free?
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[ ] Not a duplicate
[ ] Included author(s) if appropriate
[ ] Lists are in alphabetical order
[ ] Needed indications added (PDF, access notes, under construction)

Can you please add resources to existing files if one exists, and prefer YouTube URLs from the /playlist endpoint over the /watch endpoint?
ie: https://www.youtube.com/playlist?list=PLvE-ZAFRgX8hnECDn1v9HNTI71veL3oW0
You can get more guidance on the formatting and conventions of this repository by checking out the contribution guide.

Please read CONTRIBUTING.md guidelines!


added Go variant

Hello there!
This PR contains the Go variant of the kata.

Thx man, very much appreciated!
BR, Matthias.


Style registration page

Registration page should reflect mockup

https://github.com/5-gwoap/adopt-a-family/issues/21


Raw dataset

Hi,
First of all, thank you for sharing the code of this interesting code. I find it really helpful.
Second, I am wondering whether you can share the original HD videos you have used to create the tuples? I mean the data before computing averages to generate sharp and long exposure images.

Hi,
I update all the links in README file, please check: https://github.com/zhaoyuzhi/D2HNet#3-d2-dataset
The original videos are quite large to upload, please use youtube-dl to download those videos from the link

I see. Thank you.


Add hexa archi to React generator

Related to #648

 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.1 out of 2 committers have signed the CLA.:white_check_mark: qmonmert:x: Florian CarréFlorian Carré seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

I need a maintainer to approve running workflows :)

Think this one is the good one, need maintainer to run workflows again :)

Closing this, following https://github.com/jhipster/jhipster-lite/issues/293#issuecomment-1048229094


Nice, but not working

In Chrome console I have something like this: IP:22222/netdata/dashboard.js” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
After I remove line with "nosniff" from nginx.conf, I have a lot of "502" errors and no graphics displayed.

Hello @vasiler,
have you used WordOps to setup this dashboard ?

I have wordops and I followed "Manual installation"

Have you run the command wo stack install to setup the dashboard and netdata ?

No. Now seems to work, but in two boxes (4 and 5) I have:
net.eth0: chart not found on url "/api/v1/chart?chart=net.eth0"

This issue will be fixed by the next pull request.
You have to replace eth0 with the name of your network interface.
To get your network interface name, use :
ip -4 route get <IP_ADDRESS> | grep -oP "dev [^[:space:]]+ " | cut -d ' ' -f 2

Then replace eth0 by running the command (example for a network interface named ens18) :
sed -i 's/eth0/ens18/' /var/www/22222/htdocs/index.php

Now is ok. I have pages displayed without css and look like 404 pages, ex File Manager (ip:22222/files/ )

you need to run wo stack install or wo stack install --admin to setup backend tools

I've already run, the file manager is still missing.

I updated wordops, I ran wo stack install and it's all right now.


add unifi

Ran Plan for dir: infrastructure/local/lhr/unifi workspace: terragrunt
Plan Error
Show Output
running "terragrunt init -reconfigure" in "/atlantis-data/repos/siutsin/otaru/731/terragrunt/infrastructure/local/lhr/unifi": exit status 1: running "terragrunt init -reconfigure" in "/atlantis-data/repos/siutsin/otaru/731/terragrunt/infrastructure/local/lhr/unifi":
16:04:54.835 ERROR  Error: Error in function call

16:04:54.835 ERROR    on ../../../terragrunt.hcl line 22, in locals:

16:04:54.835 ERROR    22:   unifi_username = get_env("UNIFI_USERNAME")

16:04:54.836 ERROR

16:04:54.836 ERROR  Call to function "get_env" failed: EnvVarNotFoundError: Required environment
variable UNIFI_USERNAME - not found.

16:04:54.845 ERROR  ../../../terragrunt.hcl:22,20-28: Error in function call; Call to function "get_env" failed: EnvVarNotFoundError: Required environment variable UNIFI_USERNAME - not found.
16:04:54.845 ERROR  Unable to determine underlying exit code, so Terragrunt will exit with error code 1


Port issues that matter here

See https://github.com/sitemesh/sitemesh2/issues
If any are addressed, just port them over and mark completed here with links back.

Just review what didn't get flagged over there as this is mostly done.

Do we want this change https://github.com/sitemesh/sitemesh2/commit/ecebc10545363de0f3aa7001f92310dedc51d806

Do we want this change https://github.com/sitemesh/sitemesh2/commit/0e6af2ab6c6bb42245a045c524d5892a2033b163

Note the earlier part about decade back does differ.  See https://github.com/sitemesh/sitemesh2/compare/2.5.0-M1...2.5.0.  The 2.5.0-M1 tag is missing.  From there, there are many things that either were partially done or possibly missing.  Maybe not needed.


returning full path when using as json

i found in stapler docs that it should return attachment sizes with full path when returning data as json, but it does not seem to work with laravel-stapler
https://github.com/CodeSleeve/stapler/blob/master/docs/attachments.md

The stapler trait doesn't currently 'automagically' add it when you cast to JSON, so you'll need to handle this yourself. One option is to add it to the toArray() method of your model like this:
/**
     * Convert the model instance to an array.
     *
     * @return array
     */
    public function toArray()
    {
        return array_merge(parent::toArray(), ['avatar' => $this->attachments['avatar']]);
    }

It'll then be encoded to JSON along with the rest of the model attributes/relationships.

Also there is an another method like below.
You can add this to your model.
public function getFullPathAttribute() {        return $this->avatar->url(); }
And then add 'full_path' to the $appends to bind it to every json data.
protected $appends = ['full_path'];


Setup a Docker volume that can be accessed via FTP

"I'm using my own custom container. I want the platform to mount an SMB share to the /home/ directory.
You can do that by setting the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting to true."
https://docs.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq


Parse revert reason strings if present

Parse the revert strings now that Solidity support this in 0.4.22.
ethereum/solidity#3364

@seesemichaelj Ping on this.

@fabioberger Sorry, @benjamincburns was in India for a training event for the last ~6 days and is back today. Hasn't fallen off our radar!

@benjamincburns added test and rebased off of master.

@seesemichaelj will merge this one manually to take care of the conflicts.


ad center becomes white and unclosable when script tries to close it

been having this issue sense update 2.7

same. Hope it's fixed soon

This was fixed in the latest version.


Uncertainty on stereo parameters (h_max)

Please describe the use case that requires this feature.
This could help in event reconstruction through Random Forests (and in optimizing reconstruction algorithms)
Describe the solution you'd like
Maybe a new key in ReconstructedGeometryContainer
Additional context
While comparing different Random Forest implementations, some of the results are 'anomalous' (it looks like the higher the number of telescopes detecting an event, the worse is the stereo reconstruction): knowing the uncertainty on this parameter could help in improving training and event reconstruction.
I hope this won't bother you too much... (I can't implement it by myself, sorry)

it looks like the higher the number of telescopes detecting an event, the worse is the stereo reconstruction

That is strange in some respects, generally the reconstruction should improve with more telescopes, but:

More telescopes triggered usually means higher energy
Higher energies have a larger likelihood of being truncated

In ctapipe itself, we can apply selections on the telescope events in several steps, so that we don't include truncated images in the stereo reconstructions (both for applying the HillasReconstructor and for the machine learning models).
While providing an uncertainty would be in any case helpful, I doubt that it directly addresses the problem you mention

To comment on the actual issue here: the ReconstructedGeometryContainer already has fields for uncertainties of all reconstructed values, see:
https://github.com/cta-observatory/ctapipe/blob/7a131ac1cbe2fa92b6e8ab14813f3c74f104a151/ctapipe/containers.py#L747
However, this might not be filled by all reconstructors and indeed, the HillasReconstructor does compute an uncertainty for the h_max prediction.
In general, this is a very hard problem, since it is not straight forward how to compute and propogate the uncertainties from different steps.
For the specific case of the HillasReconstructor and h_max for example:

h_max is calculated as the least squares intersection point  of the "line of sight" of each telescope of the center of gravity hillas parameters. How do we compute uncertainties of the cog estimation to the uncertainty of the least squares intersection in 3d? Is the cog even the correct thing? Shouldn't it be the brightest pixel instead of the cog?

As for your last question, the cog is already an average over pixel coordinates weighted by their charge (if I understood the hillas code), while by using the brightest pixel some images could lead to absurd results that could disrupt the geometric reconstruction (e.g., the brightest pixel in a corner of the ellipse, far away from the cog).
As for the uncertainty, a coarse solution could be to propagate 'brutally' errors on the cog (pixels position could be error-free, the charge is a number of photo-electrons, so maybe Poissonian?) as a 'maximum error' (e.g., compute h_max both for the evaluated cog and for the cog+cog_error (all the telescopes) and take the difference as the error; hopefully telescope pointing directions should have a negligible error, and, if we don't move them and we produce consistent simulations, the uncertainty on their position should not matter).
Maybe somebody has a better idea to evaluate this uncertainty properly.
This is a residual effect of my lab classes ('every measured and evaluated parameter must have a unit and an error'), sorry...

the cog is already an average over pixel coordinates weighted by their charge

Yes, but showers have usually a skewness and in that case the mean is not equal to the mode.

In case of asymmetric distributions (e.g., a Landau or something like this) a weighted mean (or a truncated mean, or a combination of both) will be 'safer' as the mode approximation than using the brightest pixel: a single pixel, in particular in real data, can return a really high charge value (PMTs are 'nice', Silicon detectors can be more annoying) even if it is located in the 'queue' of the distribution, and it could not be removed by 'masking'. But, instead of a single pixel, the brightest pixel cluster (summing the charge on how many pixels?) could be used to 'level out' anomalous peaks


Properly integrate new monitor with Django interface

The new monitor (which can be found and used in the monitor branch of Cuckoo) features a lot of new cool stuff and many, many bugfixes and stability improvements. It also features a summary containing a list of all files created, written, read, etc etc and some more information like this.
All of this has to be integrated with Django so that it properly shows the output of the new monitor.

This and only use Django for web #564 look very good. Good work!

Thanks to @rep this has been done a while ago.


templates: add support for conditional validation using field paths.

jajaja. you are right... finally!!!


showDialog without current route

How do I show dialog from root of the app (the widget that created MaterialApp)?
showGeneralDialog method takes context, and uses it to call Navigator.of. But I already have Navigator (from GlobalKey).
My use case is showing alert after user opened app with URL. It must be globally accessible.

Please consider asking support questions in one of the other channels listed at http://flutter.io/support .

I asked here because it looks like shortcoming of the SDK and there is nothing that stackoverflow can provide aside from a workaround.

I'd suggest to ask on StackOverflow and if it actually turns out to be a valid issue to reopen with a link to the SO question.
I'm pretty sure you'll get a good answer on SO.


feat(prefer-const): add rule

Adds a new rule named prefer-const which:

Overrides the ESLint `prefer-const rule to support Svelte syntax, as discussed
in #818.
~Ports~ Proxies the original prefer-const rule from ESLint, adapting it for Svelte.

~This PR is an updated version of #816, which did not include types. Also, some
opinionated changes were made in terms of code style, not in terms of behavior.~
Avoided re-implemeting the core rule, by using the getCoreRule and proxying the
default implementation.
I found that this rule could be very useful for Svelte, and there could be many
developers who would benefit from it. ~At the same time, I thought that the
initial implementation was a good starting point, and that adding types and
would make the rule more robust to changes.~
However, the rule should not have many changes, as how variables are handled in
JS is not likely to change.

Acknowledgement: this rule is based on the prefer-const rule from ESLint and
the initial work done by @bfanger.

Thanks for working on implementing this rule!
However, could you please implement it using getCoreRule() in the same way as no-inner-declarations?
https://github.com/sveltejs/eslint-plugin-svelte/blob/main/packages/eslint-plugin-svelte/src/rules/no-inner-declarations.ts
I think it just avoids calling listeners on VariableDeclaration that use runes.

Thanks @ota-meshi for pointing this out, my initial idea was to use a proxy for the rule, to avoid having a complete re-write. Should've asked before spending so many hours 😅 🤦🏼
Will look into it. Maybe I'll end up closing this PR in favour of another one.

Hey @ota-meshi, would it be possible to have another review when possible? 🎅🏼


[DISCUSSION] Py3k simple

This contains the commits from https://github.com/QuLogic/ocropy/tree/py3k-simple by @QuLogic. I separate them from the commits for Travis integration and rebase them to current master. Thus, we can discuss this here.

@zuphilip, I suggest breaking this into smaller PRs. Some of them are trivial (replacing tabs by spaces) or easy to review (print function) and could be applied soon. That would reduce the complexity a little.

I just created a new "experimental" branch python3 and changed the base in this PR here, because this might need more work and maintenance is currently focused on Python 2.7. I guess some more step-by-step approach might be easier to review. I am open for any PR if someone want to work on that.

These are easy to review and can be merged right away:
8cac18895da4d9cab4945d9662591cd40a9acacb (new style exceptions)
877891582af55df229d055f7b9ae953bb4795922 (remove tabs)

TBH, I felt that all the commit are small enough that they could be reviewed in the commit view of the PR itself (except for the print function one.)

I just want to mention that there is no way you're going to get models pickled using python 2.7 to deserialize on py3k without writing your very own pickle parser. You can work around most issues but ultimately SeqRecognizer is an old-style class which don't exist anymore on 3.x.

This is meant to be separate branch rather than providing both Py2 & Py3 support. May be we should add a note to readme.


Trading

I have made 3 scripts, and each one of them, the first two inventory slots don't work. The others do. It gives me the item but doesn't take anything.
http://one.denizenscript.com/haste/36425
http://mcmonkey.org/paste/36426

The first one doesn't work because
            - take i@gold_ingot quantity:2 ```

You're checking if they have iron, then trying to take gold

the second one doesn't work because

```- take i@i@iron_ingot_ingot quantity:1````

i@i@iron_iron_ingot does not happen to be a valid item


[store] Improve startup time.

Closing this for now. IIRC this was opened at a time before we had the compactor fully running, which easily meant 2-3 order of magnitude more blocks, which had obvious effects.
Additionally, the store node caches blocks locally (which is optional to preserve across restarts though). With that restarts should be fast as it boils down to reading the meta.json file and the small cache file for the initial index lookup stages from local disk.


Add java Index.{load,view}FromPath(String)

If the index is save()ed to disk we should be able to load it without needing to either correctly guess the
parameters or hope they are ignored/overwritten when the index is loaded.

Thank you for your contributions @mccullocht!
I have a Java question unrelated to this commit. Are there simpler alternatives to using Maven and SonaType. Any chance we can recommend Java developers to use Bazel or some other build tool to fetch sources from GitHub and build on-the-fly?

@ashvardanian not an expert, but my impression is that most folks prefer to use precompiled artifacts rather than source distribution and bazel is unusual unless you have multiple languages in your code base.


Error while database migrating via PostgreSQL

Migrating: 2020_04_10_000000_alter_canvas_tables_user_id_column_type
Illuminate\Database\QueryException  : SQLSTATE[42804]: Datatype mismatch: 7 ERROR:  column "user_id" cannot be cast automatically to type bigint
HINT:  You might need to specify "USING user_id::bigint". (SQL: ALTER TABLE canvas_user_meta ALTER user_id TYPE BIGINT)
at C:\OSPanel\domains\buyownex.main\vendor\laravel\framework\src\Illuminate\Database\Connection.php:669
665|         // If an exception occurs when attempting to run a query, we'll format the error
666|         // message to include the bindings with SQL, which will make this exception a
667|         // lot more helpful to the developer instead of just the database's errors.
668|         catch (Exception $e) {

669|             throw new QueryException(
670|                 $query, $this->prepareBindings($bindings), $e
671|             );
672|         }
673|

Exception trace:
1   Doctrine\DBAL\Driver\PDOException::("SQLSTATE[42804]: Datatype mismatch: 7 ERROR:  column "user_id" cannot be cast automatically to type bigint
HINT:  You might need to specify "USING user_id::bigint".")
C:\OSPanel\domains\buyownex.main\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOStatement.php:129

via MySQL migrating was OK

Thanks for bringing this up. If you've got existing data in PostgreSQL, you'll need to alter the user_id field types from a varchar to an int on these tables:

canvas_user_meta
canvas_posts
canvas_tags
canvas_topics

Apparently PostgreSQL has a hard time altering types like this, so once you've updated the fields, the migration should run properly.

Yes, I`m already do this. But this error must be fixed. Studio was installed from scratch
Or delete from requirements about FOUR supported databases by Laravel

Up to this point however, Canvas was integrating with your app correctly via PostgreSQL, right?
I agree this was an unforeseen issue. So, just so I understand fully, you can't get this to work with PostgreSQL as a fresh install of Canvas/Studio?
I'm tossing around the idea of cleaning up the migrations on the next release. The upgrade path might be a little more involved, but it would save the effort of having to alter tables and columns with all the migrations at this point.

I agree this was an unforeseen issue. So, just so I understand fully, you can't get this to work with PostgreSQL as a fresh install of Canvas/Studio?

Yes. Sorry, that this issue was in cnvs/canvas. It might be in Canvas/Studio repository, I guess

Not a problem, appreciate the info, it makes the project better! Making some adjustments for the next release, let me know if you continue to run into issues or anything else pops up.


Are things in Tests...actually tests?

@Gvilla1000-nasa made me think about this. Namely, in MAPL we have a Tests/ directory. And in there are essentially two programs:

ExtDataDriver.x
pfio_MAPL_demo.x

These don't seem like tests to me. The first is more of a driver for ExtData and the latter a demo I suppose.
That said, I'm not sure where things like this should go. A Demos/ and Driver/ directory? Maybe ExtDataDriver.x should be under gridcomps/ExtData but then...it depends on that, so that's a bit weird.
I'll assign @tclune, @weiyuan-jiang and @bena-nasa for the debate.

My immediate reaction is also splitting this into two better named directories.   And we really need to think about how these are sustained over time.   Ben regularly runs ExtDataDriver.x at the moment, but probably best to put a README file with it.    And I don't know when pfio_MAPL_demo.x was last run, but if we don't have a simple way to verify that it still runs, it is undoubtedly broken by now.

So I had to make a change to pfio_MAPL_demo.F90 as part of my most recent PR and tried running this and this is the result:

Not sure if this is the expected outcome or not.

I mean, ExtDataDriver.x is a driver (which can be used for self consistent testing of History and ExtData, hence the name) but is not the only purpose. Besides the self consisten testing, I use it all the time whenever there is a problem with ExtData or History as a way to reproduce and diagnose problems. I agree that the other executable really is a demo. I would be fine with have a Demo and Driver directory. I can add a readme to the Driver directory for ExtDataDriver.x, if we are moving things around I would like to rename ExtDataDriver.x as it really is both a History and ExtData (or both at once) driver.

Probably the pfio_MAPL_demo.F90 should be in "example" directory? But we need to find a way to make sure it builds and runs.

It looks like these are still in Tests/. I'll mark as "long term". My guess is this is simple for @bena-nasa and @weiyuan-jiang to "fix", just not exactly high-priority!


Implement CoW LKM for Fork

Per https://github.com/Lind-Project/lind_project/issues/67
We've improved Fork performance by 10x but there may be further improvements. One of the first things to try would be making it so we don't have to revalidate files on every fork.

Currently, fork runs at 30x slower than native. This is a significant improvement from the 2000x slower original implementation, but still a far cry from anything terribly usable. Considering I was theoretically doing less copying than the native implementation, I was extremely puzzled as to why our implementation was still so much slower. Looking into the remaining costs, around a third of the time we were spending was in NaClPatchAddr, however the other two thirds was nearly entirely copy time. I went digging into the documentation, which seems to say that process_vm_writev does not actually perform significantly better than a memcpy when transferring memory within a single process, and is primarily useful for transferring memory between processes, and that it doesn't actually do copy on writ. Seeing as to how the documentation for splice seems to say that it explicitly does do copy-on-write, at least in certain cases, I updated my old splice implementation with all the new improvements I made, however it still performed slightly worse than the process_vm_writev. It appeared to be doing copy-on-write from memory to the pipe when vmsplice was called, but appeared not to be doing copy-on-write when splicing from the pipe to our memory backing file. When I looked into the kernel code to see why this was happening, I believe I found out that splice can not do copy-on-write from a pipe to a file unless there is specifically a handler defined for it in the kernel (or perhaps in fuse), as the generic handler just called generic write which essentially performs a memcpy, despite the fact that the documentation explicitly says it can (as far as I can tell, this feature was removed in linux 2.6.something because of a vulnerability found in it). At this point, and after significantly more research, it seems to me that the kernel does not expose any copy-on-write functionality to user space except for fork and kernel samepage merging, the first of which is useless to us because we can't move the pages between processes without incurring copy cost, and the second of which is useless to us because it requires the pages to be created already and then merges them later which is really counterproductive.
After some preliminary discussions with @rennergade , we came to the conclusion that a loadable kernel module was feasible and was probably the only good way to solve this problem. I've been digging through the kernel source to see how I could add copy-on-write functionality in, and it seems eminently doable. We would probably accomplish this by intercepting the process_vm_writev system call and doing our own operation with it if some flag was set (the current API does not allow any flags to be set in the actual syscall) and if not calling the actual syscall. However, I was also thinking that even if we made copy time negligible through an LKM, we would still perform 10x worse than fork, and so our LKM should do 2 things: 1, add COW functionality to some syscall, and 2, hook a new fault handler into the page table entries that we create as COW, which will lazily NaClPatchAddr it when it's copied.
However, I soon realized that this was not possible, as reading or executing from pages would not trigger a CoW fault, and the reading/executing processes would get the incorrect cage bits in their addresses. Last week I tested removing NaClPatchAddr on a whim to see if it would break anything, and it didn't strictly break anything on my simple tests however it was clear that each child cage was executing code from the parent and thus was behaving incorrectly and breaking promises given by NaCl. Therefore, in order to make lind's fork perform in the same order of magnitude as native, I think 2 things would be necessary. 1: to make an LKM with CoW support, and 2: to change nacl-gcc so as to remove the need for NaClPatchAddr. I'm worried about the performance implications of 2, as it's definitely possible that by requiring explicit validation for fixed addresses in the inner loops of files, without intelligently taking them out of the loops, we could be adding significant performance cost that might for many applications outweigh the benefit of faster fork. The only other alternative I could think of is copy-on-read/write I think would be even worse for performance.
I'd like to hear what thoughts @moyix and @JustinCappos have on what the best path forward for all of this is or whether we even should continue trying to improve fork performance for the time being.

However, I soon realized that this was not possible, as reading or executing from pages would not trigger a CoW fault, and the reading/executing processes would get the incorrect cage bits in their addresses.

As I understand it, this only should impact the way the upper bits of the addressed are masked.  The lower order masking should be the same:
and %eax, 0xffffffe0
jmp *%eax
If so, can we change the upper masking to read the cage's address mask from thread local storage (instead of an immediate operand) and then blit it?

It is my understanding of NaCl's SFI mechanism (which may well be incorrect) that this will only work for stack addresses and other addresses in memory, because I believe I read that jumps to fixed addresses in a validated executable are not masked by NaCl's compiler. This is the main thing I'm worried about here, and this is the main reason (I believe) why NaClPatchAddr is necessary for executable regions. This definitely warrants some exploration though. If it turns out that we can get by doing something like this to get rid of NaClPatchAddr, that would be great, I'm just a little worried if my understanding is correct about the cost of changing all those fixed jumps even in the inner loop of a program to masked indirect jumps.
I've been doing some other thinking regarding different ways we can handle this, and one thing that comes to mind for me is that we have one cage for executable memory only and one cage for all the other data. This would require 2 reserved registers for both cage masks, and I think it might create some problems with self-modifying code and mapping executable data and the like but I thought it would be interesting to consider, especially because it might give us a more performant fork than native. The big questions there are what the cost of taking away another register would be, and whether we could handle those PROT_EXEC problems.

Let's look and see if relative jumps are used.  If so, this should still work just fine.  If not, maybe we can see how hard it would be to change NaCl to only emit relative jumps, etc.

Something interesting to note: everything NaClPatchAddr seems to do should be useless as far as I can tell, however that's not quite the case. I've disassembled a multiple fork test file that doesn't work right in order to see how things behave, and everything seems to be done correctly, both in the disassembly and in NaCl itself, despite the fact that changes to a variable in one cage clearly modify local variables in other cages. I have not tested global or static variables yet. Things that are not the culprit through disassembly and NaCl and testing.

The cage bits in r15 are updated for each child
The value of rbp and rsp are updated accordingly for each child based on the child cage bits on fork, so variable accesses on the stack work fine
Popping rbp off the stack involves function epilogues like this:add    $0x28,%esp # why a fixed count is used rather than rbp/ebp I don't know
add    %r15,%rsp
pop    %rbx # just a callee-saved register
pop    %r11
mov    %r11d,%ebp
add    %r15,%rbp

followed by the standard returnpop    %r11
and    $0xffffffe0,%r11d
add    %r15,%r11
jmpq   *%r11

which should have no chance of getting into another cage's address space
all calls are handled correctly with the same kind of masking as returns

At this point, I am unsure of what the root cause of this issue is, and I'm nearly out of guesses. I have been starting to attempt watching memory accesses to the variable location, but it's annoying to do in gdb. It's going to be the next thing I try.
If anyone has any ideas for what might be causing these programs to break cage boundaries, I'd appreciate hearing them. It seems to be particularly caused by multiple forks.
One thing which would almost definitely fix this manifestation of the problem is masking around variable accesses that require rbp or rsp from NaCl-gcc but I'd like to find a different solution, as that is likely not only to be slow, but also to not fix the actual problem.
The following is an example of a small breaking test. The native version prints out 256 (255?) lines of "########" and the no NaClPatchAddr lind version prints out only 2 such lines and sometimes seg-faults in trusted code later, however this is a separate issue which is that the main thread exiting before the other threads may free some resources that are still needed. I'm nearly positive this is not a related issue as the program often doesn't seg fault and still only returns 2 lines of output.
int main() {
    int forkdepth = 8;
    while(forkdepth--) {
        if(fork() == -1) {
          puts("Fork failed");
          return -1;
        } else {
          putchar('#');
        }
    }
    putchar('\n');
}

Something interesting to note: everything NaClPatchAddr seems to do should be useless as far as I can tell, however that's not quite the case. I've disassembled a multiple fork test file that doesn't work right in order to see how things behave, and everything seems to be done correctly, both in the disassembly and in NaCl itself, despite the fact that changes to a variable in one cage clearly modify local variables in other cages. I have not tested global or static variables yet. Things that are not the culprit through disassembly and NaCl and testing.

The cage bits in r15 are updated for each child
The value of rbp and rsp are updated accordingly for each child based on the child cage bits on fork, so variable accesses on the stack work fine
Popping rbp off the stack involves function epilogues like this:add    $0x28,%esp # why a fixed count is used rather than rbp/ebp I don't know
add    %r15,%rsp
pop    %rbx # just a callee-saved register
pop    %r11
mov    %r11d,%ebp
add    %r15,%rbp

followed by the standard returnpop    %r11
and    $0xffffffe0,%r11d
add    %r15,%r11
jmpq   *%r11

which should have no chance of getting into another cage's address space
all calls are handled correctly with the same kind of masking as returns

At this point, I am unsure of what the root cause of this issue is, and I'm nearly out of guesses. I have been starting to attempt watching memory accesses to the variable location, but it's annoying to do in gdb. It's going to be the next thing I try.
If anyone has any ideas for what might be causing these programs to break cage boundaries, I'd appreciate hearing them. It seems to be particularly caused by multiple forks.
One thing which would almost definitely fix this manifestation of the problem is masking around variable accesses that require rbp or rsp from NaCl-gcc but I'd like to find a different solution, as that is likely not only to be slow, but also to not fix the actual problem.
The following is an example of a small breaking test. The native version prints out 256 (255?) lines of "########" and the no NaClPatchAddr lind version prints out only 2 such lines and sometimes seg-faults in trusted code later, however this is a separate issue which is that the main thread exiting before the other threads may free some resources that are still needed. I'm nearly positive this is not a related issue as the program often doesn't seg fault and still only returns 2 lines of output.
int main() {
    int forkdepth = 8;
    while(forkdepth--) {
        if(fork() == -1) {
          puts("Fork failed");
          return -1;
        } else {
          putchar('#');
        }
    }
    putchar('\n');
}

I ran into various issues with trying to load the user program in as a symbol file, so I'm putting that on hold for now. Doing some print debugging, I noticed that the pid of these processes was being reported very incorrectly and the behavior of these programs was very wrong. Simplifying the test program even further, I made this:
#include <unistd.h>
#include <stdio.h>
int main() {
    int forkdepth = 3;
    while(forkdepth--) {
        fork();
        putchar('0' + (forkdepth % 10));
        fflush(stdout);
    }
    return 0;
}

Which in native returns
21210101000000

(2 twos, 4 ones, and 8 zeroes)
which is correct and which in lind returns
221100

Further debugging indicated to me that this may be an error with writing to stdout after forks which does not trigger under certain debug conditions.

I ran into various issues with trying to load the user program in as a symbol file, so I'm putting that on hold for now. Doing some print debugging, I noticed that the pid of these processes was being reported very incorrectly and the behavior of these programs was very wrong. Simplifying the test program even further, I made this:
#include <unistd.h>
#include <stdio.h>
int main() {
    int forkdepth = 3;
    while(forkdepth--) {
        fork();
        putchar('0' + (forkdepth % 10));
        fflush(stdout);
    }
    return 0;
}

Which in native returns
21210101000000

(2 twos, 4 ones, and 8 zeroes)
which is correct and which in lind returns
221100

Further debugging indicated to me that this may be an error with writing to stdout after forks which does not trigger under certain debug conditions.

That error seems not to have been related to NaClPatchAddr removal, but rather NaClPatchAddr removal exacerbated a race condition that was already present and messing things up. This pull request addresses the main bug it was being caused by, and also makes NaClPatchAddr into a no-op, and it looks like everything works correctly when this is done.

That error seems not to have been related to NaClPatchAddr removal, but rather NaClPatchAddr removal exacerbated a race condition that was already present and messing things up. This pull request addresses the main bug it was being caused by, and also makes NaClPatchAddr into a no-op, and it looks like everything works correctly when this is done.

Currently there are two remaining significant sources of overhead related to fork. The first is of course copy time, which we're trying to deal with with the LKM. I'm plodding through work on the LKM, and have managed to access kallsyms_lookup_name using kprobes, but I'm unlikely to get anywhere fast there without some direction, as I really don't know what I'm doing there. The second such source of overhead, which is perhaps half as much as copy time is reloading of the text segment from the executable. This is not only incorrect behavior but also is relatively slow. Copying it without a usable CoW would be a significant further penalty to runtime, as there's a lot of padding around the actual text segment that would be copied. I'll probably try to incur this penalty for now to unify everything such that the implementation of the CoW LKM will just be a drop in thing, however I'm not sure we want to require use of the LKM, and so I still think it might be worth looking at what can be copied there.

Currently there are two remaining significant sources of overhead related to fork. The first is of course copy time, which we're trying to deal with with the LKM. I'm plodding through work on the LKM, and have managed to access kallsyms_lookup_name using kprobes, but I'm unlikely to get anywhere fast there without some direction, as I really don't know what I'm doing there. The second such source of overhead, which is perhaps half as much as copy time is reloading of the text segment from the executable. This is not only incorrect behavior but also is relatively slow. Copying it without a usable CoW would be a significant further penalty to runtime, as there's a lot of padding around the actual text segment that would be copied. I'll probably try to incur this penalty for now to unify everything such that the implementation of the CoW LKM will just be a drop in thing, however I'm not sure we want to require use of the LKM, and so I still think it might be worth looking at what can be copied there.

Maybe it is time to fire off another email to the folks at IBM who do
kernel work and ask if they have expertise here.  It sounds like you'll be
working on other things for a short time and it could both pan out and also
remind them that we're all working together.
Please also let them know I'm grateful for the IBM faculty award.  :)
On Fri, Jan 15, 2021 at 10:16 AM jesings<EMAIL_ADDRESS>wrote:

Currently there are two remaining significant sources of overhead related
to fork. The first is of course copy time, which we're trying to deal with
with the LKM. I'm plodding through work on the LKM, and have managed to
access kallsyms_lookup_name using kprobes, but I'm unlikely to get anywhere
fast there without some direction, as I really don't know what I'm doing
there. The second such source of overhead, which is perhaps half as much as
copy time is reloading of the text segment from the executable. This is not
only incorrect behavior but also is relatively slow. Copying it without a
usable CoW would be a significant further penalty to runtime, as there's a
lot of padding around the actual text segment that would be copied. I'll
probably try to incur this penalty for now to unify everything such that
the implementation of the CoW LKM will just be a drop in thing, however I'm
not sure we want to require use of the LKM, and so I still think it might
be worth looking at what must be copied there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Lind-Project/lind_project/issues/109#issuecomment-760599180,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD4GB6FSHDKRONF6WA3SZ6QPNANCNFSM4S2IRTEA
.

Maybe it is time to fire off another email to the folks at IBM who do
kernel work and ask if they have expertise here.  It sounds like you'll be
working on other things for a short time and it could both pan out and also
remind them that we're all working together.
Please also let them know I'm grateful for the IBM faculty award.  :)
On Fri, Jan 15, 2021 at 10:16 AM jesings<EMAIL_ADDRESS>wrote:

Currently there are two remaining significant sources of overhead related
to fork. The first is of course copy time, which we're trying to deal with
with the LKM. I'm plodding through work on the LKM, and have managed to
access kallsyms_lookup_name using kprobes, but I'm unlikely to get anywhere
fast there without some direction, as I really don't know what I'm doing
there. The second such source of overhead, which is perhaps half as much as
copy time is reloading of the text segment from the executable. This is not
only incorrect behavior but also is relatively slow. Copying it without a
usable CoW would be a significant further penalty to runtime, as there's a
lot of padding around the actual text segment that would be copied. I'll
probably try to incur this penalty for now to unify everything such that
the implementation of the CoW LKM will just be a drop in thing, however I'm
not sure we want to require use of the LKM, and so I still think it might
be worth looking at what must be copied there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Lind-Project/lind_project/issues/109#issuecomment-760599180,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD4GB6FSHDKRONF6WA3SZ6QPNANCNFSM4S2IRTEA
.

It probably makes sense to try contacting the people at IBM again because this does seem right up their alley.
Furthermore, I've gotten pretty stuck working on the LKM. The current problem I'm trying to deal with is a deadlock issue related to the Linux kernel function copy_page_range, which does the brunt of the actual copy-on-write stuff in fork.
This function, in recent kernels, takes two vm_area_structs--the one you want to copy out of (the remote vma), and the one you want to copy into (the local vma), (in older kernels the semantics were different but the issue still remains). Each of these vm_area_structs contain a reference to the memory map of the process they're associated with. These memory maps have a pthread_rwlock read/write lock (in older kernel versions it was just a semaphore with read-write helper functions), which can take unlimited readers but only a single writer, and which is extremely deadlock prone--i.e. if you try to acquire the readlock if the writelock is acquired, you deadlock. This is exactly the situation we get in copy_page_range: a function called by it asserts that the writelock on the local memory map is held so this must be locked before calling copy_page_range, however within copy_page_range (or rather a function called by it), the read lock of the remote memory map is acquired, causing an unavoidable deadlock state in our case where we're copying within the same process It is reasonably dubious at this point whether copy_page_range, or very much pre-existing kernel CoW functionality at all can really be leveraged.
@moyix, if you have any thoughts on this, that would be very helpful.

It probably makes sense to try contacting the people at IBM again because this does seem right up their alley.
Furthermore, I've gotten pretty stuck working on the LKM. The current problem I'm trying to deal with is a deadlock issue related to the Linux kernel function copy_page_range, which does the brunt of the actual copy-on-write stuff in fork.
This function, in recent kernels, takes two vm_area_structs--the one you want to copy out of (the remote vma), and the one you want to copy into (the local vma), (in older kernels the semantics were different but the issue still remains). Each of these vm_area_structs contain a reference to the memory map of the process they're associated with. These memory maps have a pthread_rwlock read/write lock (in older kernel versions it was just a semaphore with read-write helper functions), which can take unlimited readers but only a single writer, and which is extremely deadlock prone--i.e. if you try to acquire the readlock if the writelock is acquired, you deadlock. This is exactly the situation we get in copy_page_range: a function called by it asserts that the writelock on the local memory map is held so this must be locked before calling copy_page_range, however within copy_page_range (or rather a function called by it), the read lock of the remote memory map is acquired, causing an unavoidable deadlock state in our case where we're copying within the same process It is reasonably dubious at this point whether copy_page_range, or very much pre-existing kernel CoW functionality at all can really be leveraged.
@moyix, if you have any thoughts on this, that would be very helpful.

In the end, most of the CoW stuff in the kernel needed to be modified so we needed to copy and modify existing kernel functionality into the LKM. Initial performance results show around a 300x(?!) performance increase for mappings which don't have many pages written to them, and around a 60x performance increase for mappings with every page written. Currently, the LKM is in a state where it's nearly ready for testing, it can handle swapped out pages no problem.
Currently, the only 2 things I want to handle before that gets done is

making sure I haven't introduced some huge vulnerabilities, and
handling memory pressure conditions

Ideally, when the kernel doesn't have enough memory to complete an operation it undoes everything it's done. This is not terribly easy to do cleanly for us, because for example fork handles this case through destroying the whole child memory map which isn't possible for us to do. Munmap is a reasonable solution, however it itself can allocate internal memory for various edge cases which we may or may not need to handle for lind's fork, but which are definitely necessary for more robust CoW functionality when there is significant memory pressure. It seems that a suitable enough solution for wiping our written page table segments can be found unmap_region which we can modify in our LKM, but it probably will take a little more work to get a full solution that for example removes the vmas from the rbtree and completely undoes everything the call did before the kernel ran out of memory.

Is this when there is a lack of physical memory or virtual address space?
On Sat, Feb 27, 2021 at 6:29 AM jesings<EMAIL_ADDRESS>wrote:

In the end, most of the CoW stuff in the kernel needed to be modified so
we needed to copy and modify existing kernel functionality into the LKM.
Initial performance results show around a 300x(?!) performance increase for
mappings which don't have many pages written to them, and around a 60x
performance increase for mappings with every page written. Currently, the
LKM is in a state where it's nearly ready for testing, it can handle
swapped out pages no problem.
Currently, the only 2 things I want to handle before that gets done is

making sure I haven't introduced some huge vulnerabilities, and
handling memory pressure conditions

Ideally, when the kernel doesn't have enough memory to complete an
operation it undoes everything it's done. This is not terribly easy to do
cleanly for us, because for example fork handles this case through
destroying the whole child memory map which isn't possible for us to do.
Munmap is a reasonable solution, however it itself can allocate internal
memory for various edge cases which we may or may not need to handle for
lind's fork, but which are definitely necessary for more robust CoW
functionality when there is significant memory pressure. It seems that a
suitable enough solution for wiping our written page table segments can be
found unmap_region which we can modify in our LKM, but it probably will
take a little more work to get a full solution that for example removes the
vmas from the rbtree and completely undoes everything the call did before
the kernel ran out of memory.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Lind-Project/lind_project/issues/109#issuecomment-786929654,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD2XM6KFAF6OORT7UVTTBAOF5ANCNFSM4S2IRTEA
.

This is when physical memory is starved

It seems that the only case that munmap will allocate memory is if a vma is split. If we avoid merging vmas until afterwards, we can use munmap to unmap without splitting.

That sounds great. Should make this less of a headache.

I have patched the finished CoW fork into NaCl, and gathered some metrics on its performance.
Comparisons
In most cases, fork is not the bottleneck, and in such cases, as expected, we do not see much change in performance.
Comparisons to the previous NaCl implementation
In many bash tests (such as calling factor 100 times or doing other things to make bash fork/exec many times in a rapid interval),  we often gain around a 2x speed increase in overall execution time. Interestingly, calling date that many times yields a 2x speed decrease with the CoW fork, although I'm not sure why, as the executable shouldn't matter as it lies on the other side of an exec.
In the case of just forking with a very small executable (I reprised my previous test which just forks from every process to a fork depth of 8 [meaning 511 times]), we can also get around a 2x speed increase in overall execution time, although some information on the flame graphs seems to suggest that performance is being bottlenecked more by lock contention here (unsurprising given the number of processes active).
In order to test cases where the CoW fork really shines, I modified a test I had used previously which called fork many times, and added a 512MB static array to the file. This test was basically unable to complete in NaCl without CoW as the script kept timing it out after over 10 seconds, whereas with CoW it ran in around a fifth of a second discounting startup time. This test is promising as it is not dissimilar from a large program forking before exec'ing. In the case where we rewrite over the whole array in the child (but with many fewer forks), the CoW implementation is around 1.5 times slower than the previous one (as to be expected because of faulting).
Comparisons to native
In most fork-bound cases, we are still significantly slower than native. As a note, in all these results I discount NaCl startup time.
Largely, the results follow the rule that when non-copy time in fork is mostly amortized (i.e. the 512MB case and similar ones), we're around 10-20x slower in Lind discounting startup time.
In other cases where non-copy time in fork is amortized, such as bash, we're around 20-50x slower in lind, however a great deal of this is spent in exec.
In cases where non-copy time in fork is not amortized (small programs), we're around 100x slower in lind.
In terms of just the fork call, for bash it runs around 5x slower than native in the worst case, and for most cases it runs within 3x of native, often at only around 2x slower. The more disjoint memory regions, the greater the discrepancy. Compared to the previous fork implementation, it runs at around 100x faster if there is any significant amount of memory copying involved.
Upshot
However, except for that last case, fork is not a significant component of the execution time spent, except perhaps for one part, at least as far as flame graphs can show.
This part is the spawning of the worker thread(s) that are used for safeposix RPC, which in many cases makes fork take significantly longer (rather than spawning 1 thread, it spawns 2 or sometimes 3). This will be removed along with safeposix, and likely should make fork about as good as it's going to get with our architecture. Overall, I think at this point that there is not much left to be done with fork in lind, and that we should look elsewhere for further gains at this point, as I am satisfied with the progress I have made on it.

@jesings it seems we're ready to do this now. Can you write down some directions for loading, merging, and testing?
Has the CoW branch been merged with the more recent develop changes?

Good news! After over a half year of mostly inactivity on this front, we have finally implemented CoW fork on the server, and nothing has crashed, and the lind unit tests have all passed with it implemented!
Before merging it to develop however, we will definitely want to implement a fallback codepath for in case the LKM isn't loaded. This should be doable however I'm not sure which of the following approaches better suits our use case: using a preprocessor define to say at compile time whether to use the LKM or not, or testing whether the LKM is present at initialization (by calling the syscall I hooked into with the CoW flag and seeing if it fails) and then setting a global flag to say whether to use the LKM at runtime?
I@JustinCappos and @moyix, what are your thoughts?

I don't really have a strong preference for which one.  Just make sure you have a clear error message if things don't work.  Also, it should always be clear which one you are using.  It should not be possible for you to generate results where you think you are using the LKM but you ended up not doing so.

Can finally close this one with the LKM merge. Congrats @jesings !

I am fine with either, but there should be a way to tell Lind not to use
the LKM even if it is loaded.  It should also produce clear error messages
if it wants to use it and it is not running.  (We don't want to run some
experiments and then realize the module was or wasn't used when we thought
the opposite.)
On Tue, Feb 8, 2022 at 3:37 AM jesings @.***> wrote:

Good news! After over a half year of mostly inactivity on this front, we
have finally implemented CoW fork on the server, and nothing has crashed,
and the lind unit tests have all passed with it implemented!
Before merging it to develop however, we will definitely want to implement
a fallback codepath for in case the LKM isn't loaded. This should be doable
however I'm not sure which of the following approaches better suits our use
case: using a preprocessor define to say at compile time whether to use the
LKM or not, or testing whether the LKM is present at initialization (by
calling the syscall I hooked into with the CoW flag and seeing if it fails)
and then setting a global flag to say whether to use the LKM at runtime?
@.*** and @moyix https://github.com/moyix, what are your
thoughts?
—
Reply to this email directly, view it on GitHub
https://github.com/Lind-Project/lind_project/issues/109#issuecomment-1031844943,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGRODZUHZ25VIP5ITKWGT3U2ANQHANCNFSM4S2IRTEA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>


Clear 'show page' needed for a testing ground

This page would give the user info on:

Original (national) ETM scenario
Name of scaled ETM scenario
Associated topology
Associated profiles
Dates of creation/revisions
Preview options?

I already improved as much as I can in 93ab656.
However, still much is to be gained: first of all, the recorded attributes should be extended to host the (national/local) scenarios, creators, and such.
Furthermore, @antw and I decided I should not touch the logic of the displayed technologies for now.

Assigned to @antw for further improvements.

Fixed the parent scenario id issue with 97a3fda
Also added separators between the 'national scenario' and 'scaled scenario' links, as discussed with @ChaelKruip
Also setted a max-height for the topology; which is now 500px. https://github.com/quintel/etloader/blob/cc3e3861fc2eb2a0b5b49fdf913ed4061e596295/app/assets/javascripts/showTree.js#L34

I think this issue can be closed


Long photonics runs -- WIP, not sure the best way for doing this

Types of changes

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

Motivation and Context / Related issue

How Has This Been Tested (if it applies)

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CLA).
[x] All tests passed, and additional code has been covered with new tests.

Deprecated


TABL: Skip data check for GTTs

fixes #4074
test repo
https://github.com/abapGit-tests/TABL_GTT.gitr

We make an assumption here that there is or won't be other types of tables that would raise this exception as well (that are not gtt and users should confirm deletion).
Standard DD_EXISTS_DATA would also work with cluster and pool tables:
    SELECT SINGLE tabname tabclass sqltab FROM dd02l INTO ls_dd02l
        WHERE tabname = ms_item-obj_name
        AND as4local = 'A'
        AND as4vers = '0000'.
    IF sy-subrc = 0.
      CALL FUNCTION 'DD_EXISTS_DATA'
        EXPORTING
          reftab          = ls_dd02l-sqltab
          tabclass        = ls_dd02l-tabclass
          tabname         = ls_dd02l-tabname
        IMPORTING
          subrc           = lv_subrc
        EXCEPTIONS
          missing_reftab  = 1
          sql_error       = 2
          buffer_overflow = 3
          unknown_error   = 4
          OTHERS          = 5.
      IF sy-subrc = 0 AND lv_subrc = 0.
        lv_no_ask = abap_false.
      ENDIF.
    ENDIF.
`

Yes, that's the far better solution. I updated the PR.

thanks 👍


Build failed with default-features = false

Describe the bug
Juniper failed to build if specified as dependency with default-features = false
Build result:
error[E0433]: failed to resolve: could not find `ContentRefDeserializer` in `de`
   --> ~/juniper/juniper/src/http/mod.rs:232:17
    |
232 | #[derive(Debug, Deserialize, PartialEq)]
    |                 ^^^^^^^^^^^ could not find `ContentRefDeserializer` in `de`
    |
    = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info)

To Reproduce
Steps to reproduce the behavior:

create a new (empty) rust project
set juniper as dependency with default-features = false
execute cargo run in project directory

Expected behavior
Build successful.
Additional context
The cause of the problem is that juniper specifies serde as dependency with no std feature enabled. The serde/std feature implements serialize/deserialize for std's structs like Vec, HashMap, etc... But juniper uses Serialize on a struct which field is a Vec.
At now, juniper can build with default-features = true only because bson dependency uses serde/std feature.

@50U10FCA7 I wonder why the cargo check -p juniper --no-default-features running on CI doesn't reproduce this 😕

Is it because of Cargo workspace? 🤔

@tyranron

Is it because of Cargo workspace? 🤔

Probably one of the workspace dependencies enables serde/std feature, but not sure. Check still pass if remove serde/std feature from all workspace-member crates, but I think the situation is the same when bson dependency hide this error (Compiles because dependency of dependency enables the feature).


Add a demo for ionic2 + angularjs2

+1 :+1:

Satellizer does not support Angular 2 or Ionic 2 at the moment. When, and if, it will get ported to Angular 2, I will update the demo.
Cheers,
Sahat


[Bug] Error creating with fnm

Specs

Leon version:
OS (or browser) version: Mac Monterey 12.5.1 (m1)
Node.js version: 14.20.0 (fnm)
Complete "leon check" (or "npm run check") output:
(if using Docker) Complete "npm run docker:check" output:
(optional) Leon skill version:

Expected Behavior
Actual Behavior
How Do We Reproduce?
leon create birth

✖ Installing packages
Error: Failed to install needed packages
For further information, look at the log file located at<EMAIL_ADDRESS>
viewing error logs
cat<EMAIL_ADDRESS>[Sun Sep 04 2022 13:34:52 GMT-0700 (Pacific Daylight Time)] [leon create birth] Failed to install needed packages
Error: Command failed with ENOENT: /Users/marc/Library/Application<EMAIL_ADDRESS>spawn /Users/marc/Library/Application ENOENT

fnm lives at /Users/marc/Library/Application Support on a mac, and it looks like you're trying to spawn a process at /Users/marc/Library/Application, which is not a directory. Seems like a pathing bug to me
Extra (like a sample repo to reproduce the issue, etc.)

Hi @marclundgren, you need a Node.js version of at least 16 as mentioned in the prerequisites.
Transferring this issue to the Leon CLI repo.

Hello @marclundgren! :wave:
Thanks for your report, as Louis said, please install a newer version of Node.js.
I'm not familiar with fnm, as long as you're able to install Node.js with npm and globally install npm dependencies, it should work.
Yes, it is correct, we're spawning a process to install brew packages to then install Python v3.9.10, you can see the script source code in scripts/dependencies/install_brew_packages.sh.

Closing as this should not be a issue for leon-cli, probably something related to fnmor something else.
Please reopen if you think this is a mistake.


[Bug]: structuredClone is not defined in jsdom

Version
28.0.2
Steps to reproduce
Run a test that calls structuredClone using jsdom.
Expected behavior
structuredClone should be defined.
Actual behavior
Error: Uncaught [ReferenceError: structuredClone is not defined]
Additional context
No response
Environment
System:
  OS: macOS 12.3.1
  CPU: (10) arm64 Apple M1 Pro
Binaries:
  Node: 18.0.0 - /opt/homebrew/bin/node
  npm: 8.7.0 - /opt/homebrew/bin/npm
npmPackages:
  jest: ^28.0.2 => 28.0.2

You should file the issue with jsdom: https://github.com/jsdom/jsdom. We don't add the APIs to the jsdom env in Jest.


Update ConfigureSubnetworkTrace.cpp

@jared-esri please review. Seems like we should return here if no result.

Closing this. I will add this fix to another PR.


Add files via upload

Andrea, what profile is this related to? Is this resource valid by the FHIR Validator tool?

@afourquet what profile is this related to? It is named such that it would be QEDm, but I don't think this topic is part of QEDm.

@afourquet  I need to understand if I should kill this pull request or that it will be adjusted

Given I have not gotten any response to my questions. I am closing this pull-request (without merging)


install ALB ingress controller via Helm chart maintained by EKS

https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/1271#issuecomment-694539132
Use Case

Proposed Solution

Other

[ ] :wave: I may be able to implement this feature request

This is a :rocket: Feature Request

How about https://www.npmjs.com/package/cdk8s-aws-alb-ingress-controller by @guan840912  ?

Pahud, thanks for your propose. Will evaluate the library.
On Wed, Oct 21, 2020 at 4:25 PM Pahud Hsieh<EMAIL_ADDRESS>wrote:

How about https://www.npmjs.com/package/cdk8s-aws-alb-ingress-controller
by @guan840912 https://github.com/guan840912 ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aws-samples/nexus-oss-on-aws/issues/18#issuecomment-713399659,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGN4J63ITFHOU3GOCXBR53SL2LF5ANCNFSM4SZKKWGQ
.


Read provider source and version with ProviderSetup function

Description of your changes
This PR:

Reverts recently introduced workaround to pass provider requirements via env vars.
Extends (and renames as ProviderSetupFn) existing ProviderConfigFn to also pass provider source and version

Fixes #51
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[x] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Tested with https://github.com/crossplane-contrib/provider-tf-aws/pull/20

@muvaf just pushed the latest state after testing. Should be ready for merge.


Add developers-conferences-agenda

https://github.com/scraly/developers-conferences-agenda

That's a useful one, thanks again Florent!


feat: dwarf code address mapping

This is a rebase of the PR at https://github.com/rustwasm/walrus/pull/231 to the current main branch, created by @nokotan.
I didn't want to push over that branch, especially since it seems to be in use in various integration attempts. From the description there -
This is experiment implementation of transforming DWARF debug entries in WebAssembly binaries.
It seems to require more difficult implementation that using intermediate DWARF expression with gimli.rs, does not have direct access DWARF entries to be written.
This PR contains simpler way to transform code address:

Instruction mapped address conversion
Function code range based address conversion

Milestones

[x] Function code range based address conversion
[x] Implement instruction mapped address conversion
[x] Better expression of code address that does not exactly match to instruction

beginning or end of function

[x] Implement test cases

Cc https://github.com/rustwasm/wasm-bindgen/pull/3483#issuecomment-1595741387.
We hit some debug_assert!s in wasm-bindgen when trying out walrus v0.20.

Thanks for the report, I can try and take a look in the next few days.

Hey @daxpedda I had a brief look at this today and can confirm it seems an important offset issue that was also present in the original PR. I've posted https://github.com/rustwasm/walrus/issues/247 from some very initial debugging. My hope in shipping was exactly to find bugs... the next hope is to find contributors interested in solving them! If I have time, I'll definitely investigate further too, but can't guarantee anything soon unfortunately.

My hope in shipping was exactly to find bugs... the next hope is to find contributors interested in solving them!

Unfortunately I already have a tower of things I have to chew through right now, so as much as I would like to contribute I probably won't get to it.

If I have time, I'll definitely investigate further too, but can't guarantee anything soon unfortunately.

Thank you for your amazing work, I appreciate that you have found time for this so far, no guarantees necessary :heart:.


Add ublacklist-anti-ai-art to subscriptions list

Adds a new subscription option for filtering GenAI content to the subscription list.
Most other lists of this kind I could find were relatively small, so I attempted to create a combined one that has all in one place.

This is actually pretty cool!
It sounds like a good idea to add this to the website.


Added link to readme.md

🛠 Fixes Issue
Closes #116

👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers
This is another PR related to #137 and isuue #116

Live page Link

Changes
Added Links to the readme.md file
📷 Screenshots

@XZANATOL this branch is 1 commit behind from the main branch

Ah thanks for pointing this out. It should be in sync now.

This branch is 3 commits ahead, 4 commits behind Rayman-Sodhi:main.

Oho I merged this branch and your comment arrives @Rayman-Sodhi