Global hotkeys

tests for <GlobalHotKeys> would be good and also require some shuffling to make it testable, hm

On master, I'm running into errors trying to add notes in the editor – at https://github.com/thomasboyt/bipp/blob/master/app/views/Editor/Handler.js#L183, "colMap" is a mapping of JS keyCodes -> column numbers (charCodes?), but the "key" variable contains a string representation of the key pressed from Mousetrap (e.g. "s"). As a result, the "col" property on the resulting note is undefined, which naturally causes all sorts of errors. (I also don't quite understand why the keys in colMap appear to be uppercase keys rather than lowercase, but that's a separate question).
Before I spend too much time going down this rabbithole on my own, is the revamping of that code in this PR expected to fix those errors?

whoops, looks like I wasn't paying attention during this commit and didn't notice that colMap inside Editor/Handler.js was different: https://github.com/thomasboyt/bipp/commit/f4301506d7558480f6237584906e685bf36db024
pushed a fix on master for that which should fix it

:+1:


Faceted plot implementation proposal

Here is a web-components-only approach to implementing faceting that I would like feedback and suggestions for
overview

Look at the last story in PiePlot.stories.tsx to see how faceted data looks (very simple version for now), and is passed to the regular PiePlot component.
PiePlot has a isFaceted switch and passes data and props to FacetedPlot if needed

remaining issues

It assumes all plots using PlotlyPlot as a base will have the if (isFaceted<XyzData>()) return <FacetedPlot .../>
Though I guess these could return <NotImplemented ... /> for safety if we are not planning to allow faceting.
Legend not done yet

we could take one of the facet's facetData and pass it to the plot component with a new showPlot: false prop? (and of course showLegend: true (or is it displayLegend lol...)

Presumably we want automatic sizing of the subplots
There's an as React.ElementType casting in FacetedPlot that I don't like
Perhaps the generics/templating can be streamlined so that you don't have to pass both PiePlotData and PiePlotProps types?
Is there a way to automagically do the isFaceted() test without those lines of code repeated in every plot implementation?

Do not be afraid of the failed checks.  Just go to the Pie plot stories to test this out.
I have looked into plotless plots (with just the legend) and I didn't find anything promising.  We may have to implement our own.  This should be tied to the colour scheme/palette management.

Hey Bob, I'm just reviewing the code (not testing anything). This looks great. I'm not seeing a strong reason for FacetedPlot to accept non-faceted data. That would reduce some of the branching code. Thoughts?

I don't know. Don't we want to avoid code like this in the viz components? (Which adds a branch.)
  { isFaceted(data)
    ? (<FacetedPlot data={data} component={FooComponent} props={plotProps} />)
    : (<FooComponent data={data} {...plotProps})
  }

I guess it's OK if all the plotProps are bundled up into a variable as I've done above.

I would like to merge this and the sibling components PR ASAP but this will require some basic wiring of ALL the visualizations the same as I already did for Barplot.  Could take an hour for each.


UnicodeEncodeError when passing a non-ascii string in "data"

Sending a non-ascii request body using Python 2.7 fails when using requests-aws4auth. I thought it was a general requests bug at first (https://github.com/kennethreitz/requests/issues/3875) but it only happens with requests-aws4auth. I'm seeing this on Python 2.7.5 on centos 7.2 and macOS.
After some debugging, it seems to be triggered by string literals being forced to "unicode" in /usr/lib/python2.7/site-packages/requests_aws4auth/aws4auth.py.
from __future__ import unicode_literals

FIX/WORKAROUND: comment out that line.

The problem is requests doesn't seem to expect the HTTP request headers to contain unicode strings. Python 2.7 "unicode+str" weirdness causes request_headers + request_body to fail because request_body is already a binary(?) string.
Btw I don't think aws4auth should be doing an .encode('utf-8') -- it should already be "bytes", right? At least HTTPBasicAuth and S3Auth expect the client calling requests.put() to pass data already encoded to utf-8 bytes.
Finally, maybe this is still a bug in requests or python httplib.py? Should it allow unicode string headers, containing only ascii (or iso-8859-1?), and /usr/lib64/python2.7/httplib.py _send_output() should force msg to str before appending the request body?

Reproduction:
>>> import requests
>>> requests.__version__
'2.13.0'
>>> import requests_aws4auth
>>> requests_aws4auth.__version__
'0.9'
>>> AUTH=requests_aws4auth.AWS4Auth('testkey', 'secret', 'eu-west-1', 's3')
>>> requests.put('http://example.com/',headers={'Content-type':'text/plain; charset="UTF-8"'}, data=u'\u24B6\u24B7\u24B8\u24B9'.encode('utf-8'),auth=AUTH)

That should work, and it does when using requests.auth.HTTPBasicAuth or S3 V2 signature package awsauth.S3Auth. But requests-aws4auth gets exception:
>>> requests.put('http://example.com/',headers={'Content-type':'text/plain; charset="UTF-8"'}, data=u'\u24B6\u24B7\u24B8\u24B9'.encode('utf-8'),auth=AUTH)
!!!1 u'PUT / HTTP/1.1\r\nHost: example.com\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.13.0\r\nContent-type: text/plain; charset="UTF-8"\r\nContent-Length: 12\r\nx-amz-date: 20170215T040027Z\r\nx-amz-content-sha256: 7ec37a06579472c0743b58bd45af589cca817f65bbd8c6e528bc5e3092166396\r\nAuthorization: AWS4-HMAC-SHA256 Credential=john/20170215/eu-west-1/s3/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date, Signature=833120dd7cbe023d12c8bd24c6a746ba8ebcf8279346c0e58485e56c1a9ab5a5\r\n\r\n'
!!!2 '\xe2\x92\xb6\xe2\x92\xb7\xe2\x92\xb8\xe2\x92\xb9'
!!!3 u'PUT / HTTP/1.1\r\nHost: example.com\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.13.0\r\nContent-type: text/plain; charset="UTF-8"\r\nContent-Length: 12\r\nx-amz-date: 20170215T040027Z\r\nx-amz-content-sha256: 7ec37a06579472c0743b58bd45af589cca817f65bbd8c6e528bc5e3092166396\r\nAuthorization: AWS4-HMAC-SHA256 Credential=john/20170215/eu-west-1/s3/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date, Signature=833120dd7cbe023d12c8bd24c6a746ba8ebcf8279346c0e58485e56c1a9ab5a5\r\n\r\n\u24b6\u24b7\u24b8\u24b9'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 124, in put
    return request('put', url, data=data, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 600, in urlopen
    chunked=chunked)
  File "/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 356, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib64/python2.7/httplib.py", line 1020, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python2.7/httplib.py", line 1054, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python2.7/httplib.py", line 1016, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 865, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal not in range(128)

The "!!!" lines are debugging output I added to /usr/lib64/python2.7/httplib.py _send_output()
        if isinstance(message_body, str):
            print('!!!1 '+repr(msg))
            print('!!!2 '+repr(message_body))
            print('!!!3 '+repr(msg + message_body.decode('utf-8')))
            msg += message_body

Here's a workaround that doesn't involved modifying the requests-aws4auth source code. Use the following wrapper class in place of the AWS4Auth class. It encodes the headers created by AWS4Auth into byte strings thus avoiding the UnicodeDecodeError downstream.
from requests_aws4auth import AWS4Auth

class AWS4AuthEncodingFix(AWS4Auth):
    def __call__(self, request):
        request = super(AWS4AuthEncodingFix, self).__call__(request)

        for header_name in request.headers:
            self._encode_header_to_utf8(request, header_name)

        return request

    def _encode_header_to_utf8(self, request, header_name):
        value = request.headers[header_name]

        if isinstance(value, unicode):
            value = value.encode('utf-8')

        if isinstance(header_name, unicode):
            del request.headers[header_name]
            header_name = header_name.encode('utf-8')

        request.headers[header_name] = value

I'm also seeing this bug with requests 2.18.4 (the latest as of today) and requests-aws4auth 0.9 on Python 2.7, when the body of the HTTP request isn't 7-bit-clean ASCII. It looks like requests doesn't expect header names to be Unicode, and at some point it ends up combining the Unicode headers with a UTF-8 encoded body, failing to decode the body with the default 'ascii' encoding.
Another fix would be to remove the from __future__ import unicode_literals declaration, but that's farther-reaching than just encoding the header keys and values.


pred_c for confidence if object is present on scene

Hi, I have trained DenseFusion on custom dataset. The model works really well and average distance is just 2.5 mm. But how_max variable is in range [0.5, 0.7] and does not really show whether object is found on image. If object is not present, network glues 3D model to random position on background and shows confidence [0.5, 0.7]. My dataset contains images where object is present on every one of them and I was wondering if that is the problem or maybe I have set w or w_rate parameter to wrong values. (Their values are w=0.015 and w_rate=0.3)
Also is it OK for confidence to be close to 1.0 for every example? Because if I got it right, pred_c and how_max variables should show which point has the highest prediction to be correct. And if this how_max value is low, object is not present on image.
If I am wrong please explain to me how to detect if object is on scene or not from estimator output.
Thanks

Hi, have you got any updates on this?

No. I am doing detection with information about mask provided by segmentation network. If object is detected (after some blurring and erosion if any of object mask pixels are left), data is propagated through DenseFusion pipeline, else object is not found. It is a simple workaround and good enough for project I am working on

@mateoKutnjak great to find your post here, may ask how much data per object do you use for training and testing? In NDDS do you use real background or synthetic background?

500 examples per object (depth, RGB, semantic masks), 80 percent of that is training data.
Background is randomized in depth and texture. Additional objects are also added (distractors). Objects have random translation inside some bounding box and rotation XYZ in some range.
Depending on your project you have to adjust these hyperparameters and you have dataset in Linemod or YCB quality.

For me how_max variable is in range [0.1, 0.4] even though the object is there and the pose is estimated quite well.

If you want larger value of how max, you should change w and w_rate hyperparams and try training with that

Hi @mateoKutnjak, will it also improve the estimation result in the end? How should I change w and w_rate? increase/decrease?

Honestly, I tried to increase and decrease it and eventually I return it to the value from the paper.
My results are good with paper values. Only thing I changed is iterations=4.
Why does low how_max bother you?

Same, I just slightly change the w to 0.017 and iteration to 5.
My application is running real-time and for some angles (perspectives) the orientation of object is estimated mostly wrong. So my idea is to use the pred_c as a threshold to get rid of bad estimation. But I just notice that pred_c is output before refinement, so it's not really helpful, don't you think?
And for the title of your question :" how to detect if object is on scene or not from estimator output.", I think if we use semantic segmentation, it always (or at least always for me) outputs some masks even though the object is not in the scene. So one idea could be use something like MaskRCNN in which both Object Detection and Segmentation are included.

I think it is not. I suggest using some instance segmentation as segnet for getting labels and detections. Use instance segmentation for detection.

Yeah the MaskRCNN  basically cover both instance and semantic segmentation

Hi @mateoKutnjak, @TrinhNC, @j96wm,
Was your camera scale set to 100 for your data from NDDS? I read here  that  units are in cm.
I am trying to train on sythentic data but I think I have an issue with scaling as my loss values start high and drop to about ~32m after several epochs. I inputed my camera intrinsics into NDDS (ZED camera).
Thanks!
    self.cam_cx_1 =<PHONE_NUMBER>914062
    self.cam_cy_1 =<PHONE_NUMBER>1875
    self.cam_fx_1 =<PHONE_NUMBER>890625
    self.cam_fy_1 =<PHONE_NUMBER>890625

    img_width = 720
    img_length = 1280

    cam_scale = 100
    pt2 = depth_masked / cam_scale
    pt0 = (ymap_masked - cam_cx) * pt2 / cam_fx
    pt1 = (xmap_masked - cam_cy) * pt2 / cam_fy
    cloud = np.concatenate((pt0, pt1, pt2), axis=1)

Hi @mateoKutnjak, @TrinhNC, @j96w ,
Was your camera scale set to 100 for your data from NDDS? I read here  that units are in cm.
I am trying to train on sythentic data but I think I have an issue with scaling as my loss values start high and drop to about ~32m after several epochs. I inputed my camera intrinsics into NDDS (ZED camera).
Thanks!
    self.cam_cx_1 =<PHONE_NUMBER>914062
    self.cam_cy_1 =<PHONE_NUMBER>1875
    self.cam_fx_1 =<PHONE_NUMBER>890625
    self.cam_fy_1 =<PHONE_NUMBER>890625

    img_width = 720
    img_length = 1280

    cam_scale = 100
    pt2 = depth_masked / cam_scale
    pt0 = (ymap_masked - cam_cx) * pt2 / cam_fx
    pt1 = (xmap_masked - cam_cy) * pt2 / cam_fy
    cloud = np.concatenate((pt0, pt1, pt2), axis=1)

In my code (I stopped using if few months ago) cam_scale is set to 1.0 but maybe I made some changes in NDDS to reflect that. I do not have my NDDS project any more.
I suggest you visualize this pointcloud your DenseFusion dataset.py is creating. You get points in 3D space with camera as the origin of coordinate system. You have to project those points to image. See openCV function projectPoints or try to write one yourself.
Here is snippet to project 3D points to 2D pixel coordinate system. Do that and change scale to fit the points to RGB image object.
def project_points_to_screen(points, intrinsics, translation, rotation, confidence=None):
    extrinsics = np.hstack((rotation, translation.reshape(3, -1)))

    _points = np.hstack((points, np.ones((points.shape[0], 1))))
    screen_points = np.dot(np.dot(intrinsics, extrinsics), _points.T).T

    screen_points /= np.repeat(screen_points[:, 2].reshape(points.shape[0], -1), 3, axis=1)
    return screen_points

Thank you @mateoKutnjak for getting back.
I can display the point cloud on the 2D rgb images using projectpoints. My model or target seem to be ok some of the time but my cloud is off.
I am also using the R and T from NDDS' json files. I'm not sure how to use the outputted R and T during training. I've read this  explanation from @j96w
target_r = meta['poses'][:, 0:3],  target_t = np.array([meta['poses'][:, 3:4].flatten()])

target
imgpts, jac = cv2.projectPoints(target, np.eye(3), np.zeros(shape=target_t.shape), cam_mat, dist)         cv2_img = Image.open('{0}/{1}.png'.format(self.root, self.list[index]))         cv2_img = cv2.polylines(np.array(cv2_img), np.int32([np.squeeze(imgpts)]), True, (0, 255, 255))
model (read directly in from .xyz file)
         imgpts, jac = cv2.projectPoints(model, target_r, target_t, cam_mat, dist)
cloud
imgpts, jac = cv2.projectPoints(cloud, target_r, target_t, cam_mat, dist)

lay the point cloud on the 2D rgb images using projectpoints. My model or target seem to be ok some of the time but my cloud is off

It shouldn't be off if you have NDDS output (RGB, depth, mask and .ply model). Maybe your camera intrinsics are different when generating NDDS data and visualizing it. Try to find pattern of errors in projected pointclouds.
What I did: I added visualization call in dataset.py right before getitem returns bunch of values. I called it like this (this function draw_df_result calls one i posted above). This is how to check whether data send to DenseFusion networks are correct.
cam_scale = 1.0
        pt2 = depth_masked / cam_scale  # TODO depth, distance from camera
        pt0 = (ymap_masked - self.cam_params['cx']) * pt2 / self.cam_params['fx']  # TODO cx is principal
        pt1 = (xmap_masked - self.cam_params['cy']) * pt2 / self.cam_params['fy']

        cloud = np.concatenate((pt0, pt1, pt2), axis=1)
        cloud = np.add(cloud, -1.0 * cam_translation) / 1000.0
        cloud = np.add(cloud, cam_translation / 1000.0)

        if self.add_noise:
            cloud = np.add(cloud, translation_noise)

        model_points = self.pt[object_index]
        dellist = [j for j in range(0, len(model_points))]
        dellist = random.sample(dellist, len(model_points) - self.num_pt_mesh_small)
        model_points = np.delete(model_points, dellist, axis=0)

        extrinsics = np.hstack((cam_rotation, cam_translation.reshape(3, -1) / 1000.0  + (translation_noise.reshape(3, -1) if self.add_noise else np.array([[0], [0], [0]]))))
        model_points_with_1 = np.hstack((model_points, np.ones((model_points.shape[0], 1))))
        model_points_transformed = np.dot(extrinsics, model_points_with_1.T).T

        visualization.draw_df_result(
              model_points,
              np.transpose(original_image, (1, 2, 0)),
              config.intrinsics_for_camera('realsense_d415_1280x720'),
              (cam_translation, cam_rotation),
              None
        )

draw_df_result internally calls function for projecting points that i posted above. The rest of the code is up to you.
Do not visualize DenseFusion output during training. If you do that just be sure to set number of workers to zero. I suggest that you visualize when performing a zero-worker evaluation on trained models.

The rotation matrix you got from .json file needs some transformations to be correct.

If I remember correctly, coordinate systems of Unreal Engine (and NDDS) is of left-handed.So maybe you will have to do transformations of mirroring.
Following code is processing of NDDS file to fit Linemod format
with open(os.path.join(src_data_folder, src_file)) as jsonfile:
            object_data = json.load(jsonfile)

        bbox = object_data['objects'][0]['bounding_box']

        bbox_x = round(bbox['top_left'][0])
        bbox_y = round(bbox['top_left'][1])
        bbox_w = round(bbox['bottom_right'][0]) - bbox_x
        bbox_h = round(bbox['bottom_right'][1]) - bbox_y

        yaml_out = {}

        translation = numpy.array(object_data['objects'][0]['location']) * 10   # NDDS gives units in centimeters

        quaternion_obj2cam = R.from_quat(numpy.array(object_data['objects'][0]['quaternion_xyzw']))
        quaternion_cam2world = R.from_quat(numpy.array(object_data['camera_data']['quaternion_xyzw_worldframe']))
        quaternion_obj2world = quaternion_obj2cam * quaternion_cam2world

        mirrored_y_axis = numpy.dot(quaternion_obj2world.as_dcm(), numpy.array([[-1, 0, 0], [0, -1, 0], [0, 0, 1]]))

Thanks @mateoKutnjak, @TrinhNC I wasn't 100% of the coordinate system used in NDDS. I'm able to get the correct transformations now. The left image is the generate point cloud and right is the target model.

But my loss still starts at ~150m. I set the obj[idx] to 1 for my single object which is different from the mask ID (output from NDDS which is 4).
I noticed the dataset.py returns torch.LongTensor([int(obj[idx]) - 1]) which is always zero for my single object.
I also noticed my values for c, how_max, are very small ~ 2.3854e-07. I've seen @BarbeBleue mention this issue here

You probably have input error. I think you should download linemod dataset and run DenseFusion with it. See what it returns from getitem of dataset.py and compare to your return values.

Cheers! After comparing the two I had to divide values from getitem by 1000.. I've included a plot of my training. I believe it did not go lower than ~0.028 becuase I only used 500 images. I am going to repeat training with 15k images.
Now, I'm having problems with projecting points to the image plane. I'm still able to do this correctly with ground truth values.
I've read that poses are defined w.r.t the camera coordinate frame in the paper.
I've looked at @MyungHaSong's script for predicted R and T values.
I've tried this cv2.projectPoints(cld[itemid], quat2mat(quaternion), my_t, cam_mat, dist)
I've also noticed that using quaternion_matrix gives me a different rotation matrix using data from the json file. (e.g. quaternion_matrix(meta['quaternion'].flatten())[0:3, 0:3]).

Lower than 0.028 meters? It must be better than that.
Make sure your segmentation mask is ok. I suspect you are giving wrong mask or depth to DenseFusion network. Maybe your depth convesion is wrong (predicted distance should be correlated with depth pixels inside segmentation mask)

@mateoKutnjak, @TrinhNC, do you know which format you used for the depth image?
e.g. [microns or mm or cm or quantized] & [8, 16 or 32 bits]
I tried a few settings and able to get better results, loss less than 0.01m, with depth.cm.8.

I used "mm.16" but I don't think it matters. Try training your dataset with other algorithms instead of DenseFusion. In my experience, DF is slow and not very robust.

Would you have any recommendations?
I've tried DOPE but shifted my focus to RGB-D frameworks like DenseFusion and my aim is to improve proposal generations by adding context to object parts. I didn't consider PoseCNN as it's slower than DenseFusion.

@akeaveny Could you solve the problem with wrong gt pose from the .json file?
I also synthesized a dataset with NDDS and try to use it for pose estimation (with PVNet).
I used the following input as pose:

translation from "location"
rotation from "quaternion_xyzw" and transormed it to rotationmatrix with R.from_quat
then I mirrored the y-axis of rotationmatrix as mentioned above

But my pose is still incorrect if I plot the computed BBox into my rgb-image.
Can you tell me, which parts of the annotations you used for the pose? (e.g. rotationmatrix from "pose_transform" or "quaterion_xyzw"?)
My other question is, whether you used explicit camera intrinsics or not? I got the same values like in this issue and my images are 512x512. Maybe my mistake is a wrong matrix for transformation.

I did!
I first created a .mat from each json using the R or 'pose_transform':
rot = np.asarray(object['pose_transform'])[0:3, 0:3]
output['rot' + np.str(affordance_id)] = rot

translation = np.array(object['location'])
output['cam_translation' + np.str(affordance_id)] = translation

Then I checked my .mat file by projecting the model to the 2d image plane following the above advice.
cam_rotation4 = np.dot(np.array(meta['rot' + meta_idx]), np.array([[-1, 0, 0], [0, -1, 0], [0, 0, -1]]))
cam_rotation4 = np.dot(cam_rotation4.T, np.array([[0, 1, 0], [1, 0, 0], [0, 0, -1]]))

cam_translation = np.array(meta['cam_translation' + meta_idx][0]) / 1e3

imgpts, jac = cv2.projectPoints(self.cld[idx]*1e3, cam_rotation4, cam_translation* 1e3, cam_mat, dist)
cv2_img = cv2.polylines(np.array(cv2_img), np.int32([np.squeeze(imgpts)]), True, (0, 255, 255))

I also used three different virtual cameras in my dataset, all with different intrinsics (e.g. Kinect or ASUS Xtion) and different resolutions (640x480 or 1280x720). I verified that it worked for each.

Thank you very much vor sharing this. It worked fine with PVNet, but that architecture doesn't contain depth-information.
So I also try to use DenseFusion. But I am a little bit confused about rmin, rmax, cmin and cmax (values for the bounding box). In the code above bbox_x, bbox_y, bbox_w and bbox_h are calculated from the annotations in "bounding_box". I understand why we take these values. But I am unsure about how to transform it to rmin, rmax, cmin and cmax.
If I understand the code from linemod dataset correctly, we use rmin, rmax, cmin, cmax to cut an interesting region (the bounding box around an object) out of an image. So I would need something like x_min, x_max, y_min and y_max, right? But in the annotation in gt.yml (from linemod dataset) it looks like cmin and cmax are the height and width of the bounding box.
I don't know how to match these variables. Can you help me?

No prob! Heres the code I used to visualize the two different bounding boxes.
As we train on gt masks from NDDS I believe it's ok to train with gt bbox's.
get_bbox
rmin, rmax, cmin, cmax = get_bbox(label, idx, width, height, border_list)

img_bbox = np.array(img.copy())
img_name = test_folder + '1.bbox.png'
cv2.rectangle(img_bbox, (cmin, rmin), (cmax, rmax), (255, 0, 0), 2)
cv2.imwrite(img_name, img_bbox)

NDDS bbox
rmin1, rmax1, cmin1, cmax1 = meta['bbox' + meta_idx].flatten().astype(np.int32)
rmin, rmax, cmin, cmax = rmax1, rmin1, cmax1, cmin1
print("ground truth: ", rmin1, rmax1, cmin1, cmax1)

img_gt = np.array(img.copy())
img_name = test_folder + '1.bbox.gt_test.png'
cv2.rectangle(img_gt, (cmin1, rmin1), (cmax1, rmax1), (255, 0, 0), 2)
cv2.imwrite(img_name, img_gt)

Thank you very much. I could also visualize my images with correct bboxes and train my model

Hey @KatharinaSchmidt , sorry that I bother you again! I would also like to test this paper with my costum dataset created with NDDS, but I am really not that good with understanding the full code and finding all the stuff to adjust. Could you be that nice and upload your changes on github? I would be really thankful

I still have some issues with the pose prediction, my average distance dosn't drop to small values after some trainings eopchs.

What is your achieved average distance?

I fixed the rotation error and also the metric errors. But now I have a new problem, for which I opened a new issue.

Hey @akeaveny I have problems to train on my own dataset that I have created with NDDS, I also have created an issue about it.
The training session simply does not start. Do you have any idea why? Did you change some of the densefusion code , besides the adjustment of the folders.
Greetings

Hey @TrinhNC  , @akeaveny  , @mateoKutnjak  and  @KatharinaSchmidt  I hope someone can help me aswell.
I get the ground truth values from this code :
        rotation = np.array(p['pose_transform'])[0:3,0:3]         realrotation = np.dot(rotation.T , np.array([[1 , 0 , 0], [0 ,-1 , 0] , [0 , 0 , 1]])) and get these Images with projectPoints of the points.xyz

What is wrong with the plate? Why is it so far off? I already checked the target_t, it has no mistake.
When I experimented with your codes from above and started training, I also used projectPoints to project the model_points

Also here the mistake with the plate is still large. Then I used projectPoints to project the target and got larger deviation.  Is there something wrong or is that just the random noise that get added?

And at the end i used projectPoints to project the cloud with projectPoints(cloud , target_r , target_t, cam_mat, dist) and on the most plots the cloud isnt even there. And the rest looks like these

Does somebody has an idea what is wrong here? I would be really thankful, if someone could help me.
Greetings Ixion

I had a similar problem with an offset in my position. The solution was to relocate my objects in model.ply. The center of the object has to be in the coordinate origin.

Okay thanks Katharina, I gonna try that

The ground truth poses are correct now, but the avg distance is still not decreasing and stays at around 5 cm. Has it maybe something to do with the offset of the target?

Dear @TrinhNC , @akeaveny , @mateoKutnjak  and @KatharinaSchmidt  the ground truth poses and also the target is correct now. But I still got weird results when i plot the cloud with cv2.projectPoints(cloud , target_r , target_t, cam_mat, dist) . But I have also tested to plot the cloud on the original ycb with this method and also got weird results. I dont know why my avg distance still is not dropping below 5 cm. Did you made other changes to the train-files or changed something in the depth images?

Hi, I also cannot get my loss below 0.0465cm.
I'm currently training on 120k synthetic images and have verified that my w is in the range of 0.23 to 0.57. I've changed opt.w from 0.01 to 0.02, refine margin to 0.0475 and also tested with opt.noise_trans = 0.

Hey okay thanks, but this seems also too large. When you plot the cloud after some epochs , how are the results? Do you think that maybe the depth images of NDDS are "wrong" for the use in Densefusion?

I use the same code for training and inference for depth images. My projection seems OK but rarely passes ADD < 2cm.
cam_scale = 1.0
pt2 = depth_masked / cam_scale
pt0 = (ymap_masked - cam_cx) * pt2 / cam_fx
pt1 = (xmap_masked - cam_cy) * pt2 / cam_fy
cloud = np.concatenate((pt0, pt1, pt2), axis=1)
cloud /= 100

Thanks for your help, i gonna try it with maybe less training images. I just really have no idea anymore why i cant get results below 5cm

I did!
I first created a .mat from each json using the R or 'pose_transform':
rot = np.asarray(object['pose_transform'])[0:3, 0:3]
output['rot' + np.str(affordance_id)] = rot

translation = np.array(object['location'])
output['cam_translation' + np.str(affordance_id)] = translation

Then I checked my .mat file by projecting the model to the 2d image plane following the above advice.
cam_rotation4 = np.dot(np.array(meta['rot' + meta_idx]), np.array([[-1, 0, 0], [0, -1, 0], [0, 0, -1]]))
cam_rotation4 = np.dot(cam_rotation4.T, np.array([[0, 1, 0], [1, 0, 0], [0, 0, -1]]))

cam_translation = np.array(meta['cam_translation' + meta_idx][0]) / 1e3

imgpts, jac = cv2.projectPoints(self.cld[idx]*1e3, cam_rotation4, cam_translation* 1e3, cam_mat, dist)
cv2_img = cv2.polylines(np.array(cv2_img), np.int32([np.squeeze(imgpts)]), True, (0, 255, 255))

I also used three different virtual cameras in my dataset, all with different intrinsics (e.g. Kinect or ASUS Xtion) and different resolutions (640x480 or 1280x720). I verified that it worked for each.

@akeaveny Hi, I am also working with genrating data from NDDS for densefusion. Could you please show me the meaning of 1e3 in your code. How can I find that value? Thank you in andvance!

Hi @tdt98, it was to convert between [mm] to [m].


Error when Changing tags in Hosts

Error when Changing tags in Hosts to mark them as Conversion Hosts.
Error appears when accessing page through httpd reverse proxy, but not when using port 3000 directly.

Fixed in the nightly build.


[Event Request] codeunit 6620 "Copy Document Mgt." - TransferOldExtLines as parameter

Can you add TransferOldExtLines as parameter to the following events?
            end;

        if CopyThisLine then begin
            // >>>>>>>>>>>>>>>>>>>>>>>
            //OnCopyArchSalesLineOnBeforeToSalesLineInsert(ToSalesLine, FromSalesLineArchive, RecalculateLines, NextLineNo);
            OnCopyArchSalesLineOnBeforeToSalesLineInsert(ToSalesLine, FromSalesLineArchive, RecalculateLines, NextLineNo, TransferOldExtLines);
            // <<<<<<<<<<<<<<<<<<<<<<<
            ToSalesLine.Insert();
            OnCopyArchSalesLineOnAfterToSalesLineInsert(ToSalesLine, FromSalesLineArchive, RecalculateLines);
        end else

    [IntegrationEvent(false, false)]
    local procedure OnCopyArchSalesLineOnBeforeToSalesLineInsert(var ToSalesLine: Record "Sales Line"; FromSalesLineArchive: Record "Sales Line Archive"; RecalculateLines: Boolean; var NextLineNo: Integer; var TransferOldExtLines: Codeunit "Transfer Old Ext. Text Lines")
    begin
    end;

            end;

        if CopyThisLine then begin
            // >>>>>>>>>>>>>>>>
            //OnCopyArchPurchLineOnBeforeToPurchLineInsert(ToPurchLine, FromPurchLineArchive, RecalculateLines, NextLineNo);
            OnCopyArchPurchLineOnBeforeToPurchLineInsert(ToPurchLine, FromPurchLineArchive, RecalculateLines, NextLineNo, TransferOldExtLines);
            // <<<<<<<<<<<<<<<<
            ToPurchLine.Insert();
            OnCopyArchPurchLineOnAfterToPurchLineInsert(ToPurchLine, FromPurchLineArchive, RecalculateLines);
        end else

    [IntegrationEvent(false, false)]
    local procedure OnCopyArchPurchLineOnBeforeToPurchLineInsert(var ToPurchLine: Record "Purchase Line"; FromPurchLineArchive: Record "Purchase Line Archive"; RecalculateLines: Boolean; var NextLineNo: Integer; var TransferOldExtLines: Codeunit "Transfer Old Ext. Text Lines")
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


refactor Context path plugin

// Describe your PR here; eg. Fixes #issueNo

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #1362 (5435075) into master (873e8c5) will decrease coverage by 0.54%.
The diff coverage is 71.42%.

@@             Coverage Diff              @@
##             master    #1362      +/-   ##
============================================
- Coverage     67.30%   66.75%   -0.55%
+ Complexity     2105     2099       -6
============================================
  Files           401      401
  Lines          8566     8569       +3
  Branches        863      865       +2
============================================
- Hits           5765     5720      -45
- Misses         2375     2418      +43
- Partials        426      431       +5

Impacted Files
Coverage Δ
Complexity Δ

...on/dto/convert/rule/impl/ContextMappingHandle.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

...h/handler/ContextPathMappingPluginDataHandler.java
8.33% <0.00%> (ø)
1.00 <0.00> (ø)

...l/plugin/contextpath/ContextPathMappingPlugin.java
69.23% <76.92%> (-9.04%)
8.00 <4.00> (ø)

...soul/client/tars/TarsServiceBeanPostProcessor.java
31.70% <0.00%> (-51.22%)
8.00% <0.00%> (-6.00%)

.../soul/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
10.00% <0.00%> (ø%)

...omara/soul/sync/data/http/HttpSyncDataService.java
70.58% <0.00%> (-1.97%)
12.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 873e8c5...5435075. Read the comment docs.


fixed bug that non CONNECT request triggers segfault without location

Test Case

Tested-by: Xiaochen Wang<EMAIL_ADDRESS>Date: Mon Mar 18 14:55:21 CST 2019
hostname: e100069206110.zmf
pwd: /home/xiaochen.wxc/work/github/ngx_http_proxy_connect_module
cases: t
git log:

commit 5a4e210a47b9b3b80930e63de3efc862b18b77ae (HEAD -> for_pull_request, origin/for_pull_request)
Author: Xiaochen Wang<EMAIL_ADDRESS>Date:   Mon Mar 18 14:52:26 2019 +0800

    fixed bug that non CONNECT request triggers segfault without location

case result:

$ TEST_NGINX_BINARY=/home/xiaochen.wxc/work/github/nginx-1.15.9/objs/nginx prove -v -I /home/xiaochen.wxc/work/github/nginx-tests/lib t
t/http_proxy_connect.t ..........
+ test_enable_rewrite_phase: 1
+ DNS server: try to bind server port: 18085
+ DNS server: daemon pid: 32581
+ DNS server: working
ok 1 - 200 Connection Established
ok 2 - 200 Connection Established server name
ok 3 - 200 Connection Established server name
ok 4 - 200 Connection Established server name
ok 5 - 200 Connection Established not allowed port
ok 6 - Get method: proxy_pass
ok 7 - Get method: return 200
ok 8 - forbid CONNECT request without proxy_connect command enabled
ok 9 - set remote address
ok 10 - set local address and remote address
ok 11 - $connect_host, $connect_port, $connect_addr
ok 12 - dns resolver fail
ok 13 - skip proxy connect module without rewrite phase enabled
ok 14 - skip proxy connect module without rewrite phase enabled: if/return
ok 15 - 200 for default root directive without location {}
ok 16 - 404 for default root directive without location {}
+ DNS server: stop
1..16
ok 17 - no alerts
ok 18 - no sanitizer errors
All 16 subtests passed
t/http_proxy_connect_timeout.t ..
+ test_enable_rewrite_phase: 1
+ DNS server: try to bind server port: 18085
+ DNS server: daemon pid: 32642
+ DNS server: working
ok 1 - connect timed out: set $var # TODO # This case will pass, if connecting <IP_ADDRESS> timed out.
ok 2 - connect timed out log: get $var & status=504 # TODO # This case will pass, if connecting <IP_ADDRESS> timed out.
ok 3 - connect timed out log: get $var
ok 4 - connect/send/read timed out log: get $var
+ DNS server: stop
1..4
ok 5 - no alerts
ok 6 - no sanitizer errors
All 4 subtests passed
        (2 TODO tests unexpectedly succeeded)

Report-generated-by: http://wxc.oss.aliyuncs.com/dtest.sh


[TextMesh, 3.x] Fix auto-translation and ignore control chars.

Fixes TextMesh not receiving locale change notification (propagate it for MeshInstance).
Removes control characters from the mesh.

Thanks!


Implement Issue Reminder Workflow🚀

Description: Create a GitHub Actions workflow that sends reminders on open issues without updates . The workflow should post a comment prompting assignees to take action.
please @vanshchauhan21  assign me with level3 label

Description: Create a GitHub Actions workflow that sends reminders on open issues without updates . The workflow should post a comment prompting assignees to take action.
please @vanshchauhan21 assign me with level3 label

I open the new issue can you resolve?
Actually when we click on any coin we don't get any information


Support attaching EnvoyProxy resource to Gateways

Description:

Describe the desired behavior, what scenario it enables and how it
would be used.

With https://gateway-api.sigs.k8s.io/geps/gep-1867/, we can now attach the EnvoyProxy resource to the Gateway using the infrastructure.parametersRef field
[optional Relevant Links:]

Any extra documentation required to understand the issue.

blocked on https://github.com/envoyproxy/gateway/issues/3265


Any input about WASM?

It seems based on Node.js currently, but there's WASM around the corner:
Any input on it w.r.t. to this project?

Hey @mavavilj! Currently this uses Tensorflow.js, which supports CPU, WASM, WebGL, and WebGPU under the hood. If you wish to use the WASM backend, just set that backend like
tf.setBackend('wasm').then(() => {...});
Lemme know if that doesn't make sense, and we can chat more about it.


[Llama 3.2 1B] Support for reshape op (unhandled attribute type)

When reshaping to 3D tensor, instead of casting shape to vector, shape gets cast to tuple<int,int,int> which is not handled.
Example: shapes: ((1, 11, 2048), (1, 11, 2048))
Repro: pytest forge/test/mlir/llama/tests/test_specific_ops_llama32.py::test_reshape

This issue is resolved in PR #681


  Appears to behave as expected when running exe, just calling DLL via PS1 script causes the exception.

Updated with output from EXE in debug.  Appears to behave as expected when running exe, just calling DLL via PS1 script causes the exception.

Use this script instead: https://github.com/rodneyviana/ODSyncUtil/blob/master/ODSyncUtil/Get-ODStatus.ps1


Proposal: Auto-propagated function parameters

I've never created an RFC or proposal before, some mentoring would be appreciated!
Summary
The purpose of this proposal is to provide an ergonomic yet explicit way to get access to a set of variables deep in the call stack, or for a lot of sibling calls which need the same value. You may even call this feature, "compile time, strongly typed, dependency injection", or "context variables". This particular proposal is about an implementation based on the addition of an AST transform to give Rust some syntax sugar to achieve this.
Motivation
There are a lot of times you want to propagate a function parameter deep into the call stack or to a lot of child calls at the same level in the stack.

Recursive functions with a result accumulator (example below)
Request scoped structs in a web application, eg. Request, User, Metrics, Tracer (example below)

i.e. Structs which are used by basically every method

Possibly in Future's Context as an explicit param to poll

The goal of this proposal is to provide Rust as it is today, with some ergonomic wins. There should be minimal/zero drawbacks to this syntax sugar. Ideally the syntax would be extremely intuitive, if not, less than a page of documentation should be needed.
Ergonomic Goals
There are two places this feature can effect readability, a function's signature, and a function's implementation.
Function signatures:
These change marginally, as such I don't think there is an ergonomic win or loss while reading function signatures.
Function implementations:

Perspective of the writer:

Goal: None
Currently: This proposal happens to improve ergonomics

Perspective of the reader:

Goal: Improve ergonomics
Currently:

This proposal makes it harder to read a code sample for the first time in that domain.
This proposal makes it easier to re-read code samples in familiar domains.

Detailing the intents of the function rather than how the function is implemented.
Eliminating variables which are not valuable to improving the readers understanding of the purpose of the function.

i.e. This feature reduces noise, and improves signal, for all future re-reads.

A common starting point: I think we can all agree,for x in ... (vs it's legacy counterpart) is far more signal (i.e. more readable), even tho how we accomplish the iteration is no longer readable. This is because the purpose was to iterate, not to increment registers and dereference arrays.
Similarly, in some problem domains, while reading over the implementation of a particular function, certain variables are noise, not signal. Reading parameters which are mechanically passed over and over doesn't help me grok the purpose of the function.
Additionally, if you asked me, "In a web service, whats the purpose of the request variable if you can't see where it is used?"

I would likely be able to guess without looking at any part of the implementation.

I know from years of experience what a request variable does.

If it was relatively new to me (i.e. first ever read), it is very obvious where to find that answer: the function's signature/docs.

Having read the docs, the fact that it is used to call dependent services and construct a response becomes a given.

Current solutions

Utilize global variables

Current usage: e.g. env::var, or stdout.
Limitation: Read only / synchronization overheads

Utilize thread local storage (TLS)

Current usage:

e.g. futures: 0.1 (I think removed in 0.2); tokio's implicit core.
This solution has been extended in other languages e.g. Java with request scoped dependency injection, aspect oriented programming, and them together as aop-scoped-proxies.

Drawbacks:

Request scopes were built to ensure appropriate cleanup.
With manual TLS, there is no mechanism which enforces cleanup.

I've personally seen User objects stored in TLS and then not cleaned up before the next request
This results in "leaking" private data to a different user!
"This is a bad engineer", "better code reviews", Yes I agree!
That said, aren't we all using Rust because we believe the best engineers and the best process are still fallible? That as much as we can, we should explore how to get our tools to help fix today's problems?

Appropriate use:

e.g. Logging: where a thread should do lock free batching of log messages before performing disc io.

Inappropriate use: As a crutch for not wanting to pass around a few arguments.

If this is a problem, lets give Rust an alternative, so we avoid abusing TLS.

Utilize Context objects which encapsulate all the state needed

This forces all functions to take the whole context. It would be nice to write idiomatic functions, which only take the data they need.
A single Context object, needs to know about application specific types. Therefore it cannot improve the ergo for functions defined in a different crate (e.g. framework, plugin or middleware).

Workaround: You would need one context per crate, and nest them

Obfuscates parameters. i.e. Neither the caller nor the callee's function signature defines the used values.

Explanation
Note: Good syntax is very important, but for this iteration, I am going to use placeholder syntax. We can discuss syntax after, if the general concepts of this proposal are more or less discussed and well received.
Functions will have special syntax to define auto-propagated params and with it an auto-propagation scope. Auto-propagated params with identical names and types will be automatically propagated by the compiler to any sub-call within scope. Functions within an auto-propagation scope, can have any or all of their auto-propagated params overridden. When called without an auto-propagation scope (usually at the top of the call stack) overrides can be used to set the initial auto-propagation scope.
The best way to explain this is with example sugar/de-sugar variants.
// Imagine the database client is a plugin to a web framework.
// It only knows about `database::Query`s and `io::Metrics`, not about `jwt::User` or `framework::Request`.
// A single struct would not be known to the database client implementor.

// Imagine that you're using JWT auth to extract user information.
// I'm going to ignore that this would probably be middleware for the moment,
// but the problem is the same.

// Framework/Library author implemented
// `database.call` = fn call(query: database::Query, context { metrics: io::Metrics })

// Service owner implemented
// fn query_builder1(context { user: jwt::User })
// fn query_builder2(context { user: jwt::User, request: framework::Request })
// fn build_response(result1: ..., result2: ..., with { user: jwt::User, request: framework::Request })

// With sugar
fn handle_request(context { request: framework::Request, metrics: io::Metrics }) {
    // let's override the context to have a `user` parameter
    let context user = jwt::User::from_bearer(request.auth_header());

    let result1 = database.call(query_builder1());
    let result2 = database.call(query_builder2());

    ...

    return build_response(result1, result2);
}

// Without sugar
fn handle_request(request: framework::Request, metrics: io::Metrics) {
    let context user = jwt::User::from_bearer(request.auth_header());

    let result1 = database.call(query_builder1(user), metrics);
    let result2 = database.call(query_builder2(user, request), metrics);

    ...

    return build_response(user, request, result1, result2);
}

// With Sugar
fn find_goal_nodes(
    root: &TreeNode,
    context {
        // This function expects these parameters, but understands
        // they are generally passed down deep in the call stack, without modification.
        goal: Predicate<...>,
        results: &mut Vec<&TreeNode>,
    }
) {
    if (goal.evaluate(root)) {
        results.push(root);
    }
    for child in root.children() {
        // All parameters which share the same name, are auto-propagated to the sub-function.
        // i.e. The parameters `goal`, and `results` are automatically propagated.
        find_goal_nodes(child);

        // Also possible to override some params, but still inherit others.
        // i.e. `goal` is being overridden, but `results` is still auto-propagated.
        // Note: This is just like shadowing any other variable, and the override to the context dies at the end of the scope.
        let context goal = goal.negate();
        find_goal_nodes(child);

        // Disclaimer: Frequently overriding an auto-propagated param, would be bad practice.
        // The line above overriding `goal`, would be a good "hint" that this feature is being abused on this param.
    }
}

fn main() {
    let root: TreeNode = ...;
    let context goal: Predicate<...> = ...;
    let context mut results: Vec<&TreeNode> = Vec::new();

    // Initial call
    find_goal_nodes(&root);
}

// De-Sugar the above example
fn find_goal_nodes(
    root: &TreeNode,
    goal: Predicate<...>,
    results: &mut Vec<&TreeNode>,
) {
    if (goal.evaluate(root)) {
        results.push(root);
    }
    for child in root.children() {
        find_goal_nodes(child, goal, results);
        find_goal_nodes(child, goal.negate(), results);
    }
}

fn main() {
    let root: TreeNode = ...;
    let goal: Predicate<...> = ...;
    let mut results: Vec<&TreeNode> = Vec::new();

    find_goal_nodes(&root, goal, results);
}

The real ergonomic wins start showing in large code bases. As such no example can really do it justice.
Open Questions

Requiring that the names match makes the feature less flexible and useful (because everyone has to agree on using the same names). There are also questions around how to handle name/type collisions.

Drawbacks

At initial glance the syntax sugar seems like magic. However, a single page of documentation would highlight a de-sugared example, and it will be very straight forward / intuitive for all. This is similar to a first encounter with ? or Into or self.___().

However, unlike those there is no marker at the call site indicating implicitness.

We could add a marker:

database.call(query_builder(_), _);
database.call(query_builder(...), ...);

New syntax for "special" parameters. Users could be overwhelmed.

Possibly, but seems unlikely, the mental overhead is far less than generics or lifetimes.

Excessive use of generics can be an issue regardless of parameters being implicit, but this issue gets more-likely as we create more parameters for functions.

This particular syntax (we can fix this when we discuss syntax):

Basically introduces named params.
The initial call is less ergonomic. But perhaps that is ok.
Doesn't improve ergonomics for many sibling calls at the top level.

FAQ

Will this block any future features?

The concept in general is just syntax sugar, and as such should not block any future features
The syntax possibly could, but should be such that it doesn't block future enhancements to method signatures. We can discuss when we open up discussion about syntax.

Alternatives
@burdges suggested that we could possibly use something similar to dependent types and type inference. I'm happy to explore this route if everyone prefers it. Although it likely will limit the context to have unique types.
@burdges has also suggested a possible State monad with the possible inclusion of do notation.
@mitsuhiko has a suggestion, which I understood as TLS with a tighter scope. Basically instead of "thread local storage", it could be "call stack local storage" (my name). His proposal seems to suggest access through a global like function e.g. env::var. I would still like to put the function's dependencies into the function signature somehow. And ideally, get some compile time checks, but without adding the context to all function's signatures, this is compile time check is impossible because of "no global inference".
Conclusion
Adding a relatively simple AST transform would open Rust up to some pretty nice and easy ergonomic wins. The syntax would need to be discussed and could bring in more drawback, but at least for now the drawbacks seem minimal and within acceptable bounds.
I'd love to hear other people's thoughts:

Do you like it? (+1s will do)

What might your usecase be?

Drawbacks

Any of the drawbacks show-stoppers for you?
Any drawbacks I didn't forsee?

Compile/Lang teams

Is this even feasible? I have no idea if this can actually be an AST transform.

Scala is the only language I know of with this feature set. It's generally (ab)used to provide things like FromIterator to functions like collect. They also seem to result in code being really hard to understand and seem magical, especially when combined with the other features which use the implicit keyword.
The only scenario where this even initially seemed fine in one of the codebases I maintain was to pass a logging parameter through the callstack, but even when doing that it's occasionally confusing to get weird error messages about it being missing or not being found.
Besides, I don't think there's enough research and language design experience that suggests that this is consistently beneficial to implement it in a language with a production focus.

If I understand the example correctly, you still have to write with { } everywhere the arguments are getting passed, so it seems like this is already easy to do with an "options object".
struct FindGoalAccumulator {
    goal: Predicate<...>,
    results: &mut Vec<&TreeNode>,
}
impl FindGoalAccumulator { ... }

fn find_goal_nodes(
    root: &TreeNode,
    acc: &FindGoalAccumulator
) {
    ...
    find_goal_nodes(root, acc.negateGoal());
}

Which to me at least looks almost identical in readability and ergonomics. Perhaps writing the negateGoal method is a nuisance since Predicate already had a negate() method, and you do need to invent a name for this options object you're passing, but those seem like really tiny improvements compared to the downsides of having an entirely new language feature just for this pattern.
In other words, I'm just not seeing the motivation for this.

It's generally (ab)used to provide things like FromIterator to functions like collect.

@ahmedcharles I apologize for my lack of experience with Scala, I only know it at a basic level. Briefly looking at the Scala docs, there are two similar features around implicit.

Implicit Parameters

Looking at the docs, while close in spirit, I'm not sure this feature is identical in practice.
Although, looking at the docs' examples, I do see how this could be abused with excessive generics

That said, I'm not sure this feature increases the chances a library implementer would abuse generics in their function signatures.

Implicit Conversions

It seems like the feature which you describe is abusive.
I am not advocating for this.

Besides, I don't think there's enough research and language design experience that suggests that this is consistently beneficial to implement it in a language with a production focus.

@ahmedcharles I'm not exactly making up this problem. The java webservices I've built for production uses has this pattern (issue?) all over the place. I don't like these options, but a lot of people today (over the last decade) end up using either thread local storage or "request scoped" Dependency Injection (DI), which internally uses thread local storage, to "improve ergonomics". In java they even try building "method interceptors" called aspects (I'm not a fan), again using thread local storage. All of these are intricate and nuanced workarounds for this relatively simple, missing compile time feature.
You might even call this feature "compile time, strongly typed, dependency injection". Hopefully this helps alleviate your concerns around "enough research"?
@Ixrec yeah an "options" struct is a great alternative, thanks I'll add it to my proposal for visibility. However, while it can help improve the ergonomics, it does end up being kind of awkward and also limiting.
I blame myself for being lazy and only adding one example. Not all calls will need all of the information. Passing around an options struct, doesn't allow you to write functions idiomatically (i.e. limit variable scope as much as possible). Keep in mind middleware might be written in different crates, not exactly able to share a common options struct.
For example:
// Imagine the database client is a plugin to a web framework.
// It only knows about `Query`s and `Metrics`, not about `User` or `Request`.
// A single struct would not be known to the database client implementor.

// Framework/Library author implemented
// `database.call` = fn call(query: Query, with { metrics: Metrics })

// Service owner implemented
// fn query_builder1(with { user: User })
// fn query_builder2(with { user: User, request: Request })
// fn build_response(result1: ..., result2: ..., with { user: User, request: Request })

fn handle_request(with { request: Request, user: User, metrics: Metrics }) {
    let result1 = database.call(query_builder1());
    let result2 = database.call(query_builder2());

    ...

    return build_response(result1, result2);
}

You could just take my word for it, or look at most web applications, these query_builders and build_response methods usually end up going a few layers deep, passing the same object over and over. Per request handler methods, there are usually only 2-5 remote calls which end up needing metrics passed over and over, but I've seen implementations with remote calls in the teens. Overall a single (simple) service will end up passing metrics and sometimes a tracer down the call stack in 50+ locations.
Maybe this showcases the benefits of this proposal more? If so, I'll update my original post with these examples / motivations.

@Ixrec thinking about it a little more, I do think you could use an options struct, with a lot of impl From ..., and pass the options everywhere. But I hope you'd agree this wouldn't be an on-par ergonomic win. Or maybe you're thinking about it differently than I did. If so, I'd love to see the handle_request example ported with your suggestion.

If you look at the Scala example for implicit parameters, you'll note that the value of the implicit is purely based on matching types. I actually don't know what happens if there are two implicits declared in scope with the same type, though I hope it results in an ambiguity error. Basically, the names of the parameters are irrelevant.
You seem to be proposing that the names are important, but that basically results in adding named parameters to the language, which hasn't been done so far due to complexity. Requiring that the names match makes the feature less flexible and useful (because everyone has to agree on using the same names, or it ends up being more verbose than the current syntax). But alternatively, basing it purely on type results in the chaos (my word) seen in Scala.
Let's take your handle request example and make it more complete.
// Imagine the database client is a plugin to a web framework.
// It only knows about `Query`s and `Metrics`, not about `User` or `Request`.
// A single struct would not be known to the database client implementor.

// Imagine that you're using JWT auth to extract user information.
// I'm going to ignore that this would probably be middleware for the moment,
// but the problem is the same.

// Framework/Library author implemented
// `database.call` = fn call(query: Query, with { metrics: Metrics })

// Service owner implemented
// fn query_builder1(with { user: User })
// fn query_builder2(with { user: User, request: Request })
// fn build_response(result1: ..., result2: ..., with { user: User, request: Request })

fn handle_request(with { request: Request, metrics: Metrics }) {
    // let's pretend we have a way to make user act like it was a with parameter
    let with { user } = jwt::User::from_bearer(request.auth_header());
    let result1 = database.call(query_builder1());
    let result2 = database.call(query_builder2());

    ...

    return build_response(result1, result2);
}

This is all nice and fancy, but now the User object used by the JWT library has to match the one used by the database library. And well, lets assume that the JWT library also does metrics, perhaps you get lucky and it even uses the same library for metrics as the database library, but it calls the parameter metrics_client instead, since the dev figured that was clearer, cause metrics get reported to a server.
I suppose it's obvious now why Scala ignores parameter names. But it still requires the same types. In an ecosystem like Rust's where there are lots of small crates that integrate with each other, primarily using traits, I don't really see this feature being beneficial. As soon as you start mixing libraries, passing variables is the clearest solution and other than being verbose, I don't really see the problem.

Haskell supports a feature like this under -XImplicitParams so there's certainly prior art and research around this subject. My opinion of that language pragma has always been that it is a misfeature that optimizes for writing ergonomics to the detriment of reading ergonomics. As reading code happens more frequently than writing, I believe we should default to favoring the ergonomics of reading over writing whenever there is a conflict, unless there is a strong argument for an exception in the particular case. To me, the legibility of code will be the major drawback of this proposal should it come to fruition.

@Centril I'm entirely in agreement. My preference is always to optimize for readability.
I'm not familiar with this features' implementation in Haskel or why it might be a miss feature there. I think wether this feature is a misfeature is highly dependent on what you believe is signal and what is noise.
There are two places this feature can effect readability, a function's signature, and a function's implementation.
The feature I'm requesting only changes the function signature marginally, as such I don't think there is an ergonomic win or loss while reading function signatures. The rest of my comment will cover the readability impact of this feature in function implementations.
A common starting point: I think we can both agree, for x in ... (vs it's legacy counterpart) is far more signal (i.e. more readable), even tho how we accomplish the iteration is no longer readable. This is because the purpose was to iterate, not to increment registers and dereference arrays.
Similarly, in some problem domains, while reading over the implementation of a particular function, certain variables are noise, not signal. Reading them over and over doesn't tell me more about the purpose of the function.
I'll de-sugar my earlier example:
fn handle_request(with { request: Request, user: User, metrics: Metrics }) {
    let result1 = database.call(query_builder1());
    let result2 = database.call(query_builder2());

    ...

    return build_response(result1, result2);
}

vs
fn handle_request(request: Request, user: User, metrics: Metrics) {
    let result1 = database.call(query_builder1(user), metrics);
    let result2 = database.call(query_builder2(user, request), metrics);

    ...

    return build_response(user, request, result1, result2);
}

I'm not able to contrive an adequately involved example, but note that user, request, and metrics end up getting mechanically passed to almost all methods (regardless of the number of methods), without adding any value to my understanding of the purpose of this function.
Additionally, if you asked me, whats the purpose of the request variable?

I would likely be able to guess without looking at any part of the implementation.
I would be able to answer that question after only looking at the function's signature.

The fact that it is used to call dependent services and construct a response is a given.

When it comes to groking a function for the 1st, and especially 10th time, I would call these types of parameters which have repetitive, predetermined usage patterns noise.
I'd postulate, that while I'm not familiar with them, there exists a similar set of "mechanically passed" parameters in every codebase which shares a problem domain (i.e. anywhere you'd build and share a framework).

As an overly broad rule, syntax-level tricks bring confusion while type-level tricks bring power and clarity.
I think a measure of type inference plus dependent types provides a much better route to this :
fn find_goal_nodes<const goal: Predicate<...>>(
    root: &TreeNode,
    results: &mut Vec<&TreeNode>
) { ...

We'll only have const dependent types in near future, but one could imaging improving that to constant-relativet-to-the-local-call-stack, no-interior-mutability, etc. dependent types or whatever.
In practice, you actually find yourself reaching for implicit parameters not to avoid typing, but so that people cannot pass the wrong thing as easily, so dependent types provide one stronger solution, but so do other type system extensions:
Improving ephemeral types ala structural records aka anonymous structs permits doing things like
fn find_goal_nodes(args: struct {
    root: &TreeNode,
    goal: Predicate<...>,
    results: &mut Vec<&TreeNode>,
}) {
    ...
        find_goal_nodes({ root: child, ..args });

You can actually enforce invariants with design by contract or other verification tools, which frequently sounds better.  In this vein, your find_goal_nodes(child, with { goal: goal.negate() }); is likely an anti-pattern unless based on something like structural records or design by contract.

@burdges I do not mind if we use the type system over an AST transform.

constant-relativet-to-the-local-call-stack, no-interior-mutability, etc. dependent types

I think we would have to be able to pass &muts.
I think the type inference would be the blocker, but if the lang/compiler team feels its the better route, and can achieve the same effect, I'm happy to change this to go with that solution instead.

As for my thought with the RFC, I personally would like to get some runtime on seanmonstar's idea before deciding we need to extend the language and in what way.  Granted, I'm always a bit conservative about adding language features due to concern with bloating the language (one of the things that turned me off from D).
For background, my use case of a "Context" is I maintain the Rust implementation of the Liquid templating language.  It has "global" state in both the parser and the renderer and it'd be nice to find better ways to express that rather than passing those structs up and down the call stack.
Things I think this RFC could use

Pitfalls a user run into with this and how can we help them debug them
Some prior art has been mentioned.  In addition, this sounds similar to the failed(?) area of Aspect Oriented Programming (just never hear it talked about anymore).  I think it'd be good to analyze these to see how they differ, what works well for them, and what doesn't work well for the,

Auto-propagated params with identical names or types will be automatically propagated by the compiler to any sub-call within scope

I assume we can't auto-wire by name alone because then the types might be invalid.  Do we need auto-wiring to match name and type to ensure we don't miswire things?

I think the example shown here has moved the conversation into an area that I personally don't find that useful where @seanmonstar's proposal can also fit. However the place that I find most interesting is context variables that can appear out of thin air by a previously unknown piece of code. eg: think of it more as env::var that is scoped locally to a task but might or might not be inherited to another task.
Because of asyncio Python recently gained context variables which are variables that are just generally available but can have different values per task: https://www.python.org/dev/peps/pep-0567/
There are a lot of uses for this:

For instance i18n utilities can discover the current language from anywhere. This means no matter how deep down a calls tack you are you can always get the appropriate language.
Auditing functionality can always discover the relevant information for logging (current security context, current user, current ip etc.). This means even the most remote utility function can issue a audit record without all callers having to be updated.
Security contexts. This is the one I care about the most. Our business is to write a multi tenant application and being able to know which is the current tenant at all times lets us write much more secure code. For instance if we know what the current tenant is we can automatically add constraints to the current tenant to all queries in a database. Or we can run assertions on result sets that if data for a different tenant is returned we filter it out or error instead of leaking information.
Systems such a sentry's raven clients can collect breadcrumbs of the current execution and scope it to the most relevant unit of work (for instance current http request etc.) to aid debugging later.

Such a system can also come in useful when tests are used. For instance right now println! can be redirected temporarily for the test runner alone on a per-thread basis through an undocumented and unstable API. With a context system one could imagine a world where global default streams can be tapped in on a per task basis.
I made an earlier proposal to Python where I imagined a system where the context variable can define what happens if a new task is spawned out of a task (does the value get copied, cleared etc.). I figured this is useful as there are typically two ways to spawn a task: a task that aids another task (http fetch / db query during web api http request handling) or a task that spawns a whole context by itself (http request for instance). There needs to be a generally well understood API to spawn such things differently or the contexts will all get messed up. There is an almost neverending list of complexities for this and I can see if I can find some of the notes I wrote. I also know that the node community didn't manage to settle on a new system yet but did leave some notes behind as well about how such a system could work.
In the process of working on this I noticed that there are quite a few systems that can be used for inspiration (.NET's logical call contexts and nodejs' domains and various libraries working with the async hooks and now Python 3's context variables).

What happened to "explicit over implicit"? Are we not doing that any more?

@sandeep-datta Type inference makes things implicit, lifetime elision also. I think the key is to be explicit where it matters most for clarity and implicit where it reduces pain the most... You might be interested to read: @withoutboats's excellent blog post on this subject.

@Centril Lifetime elision isn't really implicit. The compiler isn't allowed to make a choice based on information that isn't local to the function definition and there's only one possibility. Granted, people may not know what that is in terms of having the lifetimes in the source, but then again, those same people wouldn't be likely to understand the lifetimes if they were visible in the source either.
This feature results in any function call within the definition of a function with N implicit parameters having 2^N possible ways of being called, ignoring the order of the parameters. I don't want to do the math with ordering being a consideration. 1 vs 2^N isn't really comparable, unless N is 0.

What happened to "explicit over implicit"? Are we not doing that any more?

I think that's the wrong way to think about it. Well implemented context variables are just a superior version of env::vars.

I strongly disagree with any kind of implicit argument passing in any form or fashion. What is wrong with passing the damn arguments around? I cannot imagine any code review going faster thanks to implicit parameters.

At initial glance the syntax sugar seems like magic. However, a single page of documentation would highlight a de-sugared example, and it will be very straight forward / intuitive for all. This is similar to a first encounter with ? or Into or self.___().

I disagree with that. All three existing features you mentioned require something to be written where the code is impacted, be it a question mark or a method call. Implicitly passing arguments means I need to always remember what even was the function signature and what were its implicit arguments. Furthermore, it can make code way more confusing, if there is a function with implicit params which is named the same thing as a trait method with a different arity.

I think that's the wrong way to think about it. Well implemented context variables are just a superior version of env::vars.

Accessing environment variables from the middle of code is asking for problems, just like rampant use of global variables.

To provide another piece of terminology that might help people understand this proposal: Essentially we are proposing adding dynamic scope. Scala implicits are a syntactically different but semantically identical example of dynamic scope. Environment variables are another example of dynamic scope. Exception handlers are typically dynamically scoped.
Dynamic scope is very useful - many languages have exceptions/exception handlers, and environment variables are widely used for configuration. Dynamic scope can be used to implement thread-locals/coroutine-locals in an elegant, unified way. But: dynamic scope can be easily abused, and probably should not be used outside of foundational libraries. So it's a bit of a toss-up.

I strongly disagree with any kind of implicit argument passing in any form or fashion. What is wrong with passing the damn arguments around?

See my comment above but the simple answer is that it's impossible. The goal of a context system is to make things which are currently global state (think of things like stdout, environment variables, execution flags such a if tracebacks should be shown etc.) slightly more local. Traditionally TLS is used for this, but this cannot work with async systems.
More importantly though we need to be able to compose code. Different systems will allow you to pass different data through. Even the best designed system will require TLS sooner or later to capture vital state. Security contexts in multi tenant systems for auditing are a really good example of something which is just too important to pass around. Same thing with logging integrations in general. I encourage you to look at how logical call contexts in .NET work to get an idea what they are used for. Likewise why the node community has domains and similar systems. They are vital for the operation of the raven-node client for instance.

@nox I'm thinking that this RFC isn't discussing the underlying motivations for the feature--to its detriment. @mitsuhiko described them a while up:
How do we make a new cross-cutting feature, like logging, auditing, collecting metrics, etc work with an existing library without needing to update the function signatures of the entire library for each feature?

Also, after thinking about it, would a feasible solution be using a builder pattern that constructs a  context , and move all of the functionality of the api to methods on the context? (And then wrap this for cross-cutting needs?)

How do we make a new cross-cutting feature, like logging, auditing, collecting metrics, etc work with an existing library without needing to update the function signatures of the entire library for each feature?

By updating the function signatures of the entire library, such that you can see the code flow and not be completely lost 3 months in the future.

similar to the failed(?) area of Aspect Oriented Programming

@epage I brought up aspects and my dislike for them in my second post. I'm just trying to batch a bunch of ideas, and I'll update the proposal.
Basically, regarding aspects. I do not like aspects because they end up needing TLS, and while I don't have a problem with TLS in general, I do have an issue when it is used as a crutch for a missing feature, and is possibly misused. I'll update the proposal with my thoughts.
@mitsuhiko I don't mind if we use env::var type syntax to achieve this (or any syntax). However, I would want to make sure these are not scoped to the thread, and instead these contexts cannot exceed the lifetime of the current call stack (CSLS - "call-stack local storage" if you will). I'd likely go so far as to say, they should be "owned" by the call stack.
Also, I do prefer if every function in the call stack (even if it doesn't need the context) have to declare the existence of the context. This is purely for compile time correctness, and based on Rust's rule of not doing global checking. But I could be convinced otherwise.

I strongly disagree with any kind of implicit argument passing in any form or fashion.  I would prefer if it was more ergonomic :), but I end up using this "passing arguments" style in all of my production Java projects. That said, this isn't about you or me, I know that other people view this "passing ... around" as a code smell, and the conversations not only get contentious, but most developers go looking for any solution which might help (i.e. request scoped DI, AOP, manual TLS), and I've had to fix unforeseen consequences of this type of code.
I don't love it, but I could be convinced to introduced something like JavaScript's spread operator, ...args, as a marker to make this implicit passing more explicit at the call sites, but still improve ergonomics? Like I said, I'm not in love with the idea, but I am curious about people's thoughts on that?

@yazaddaruvala The damning was unnecessary, sorry for that. For what it's worth it was about them plain old arguments and not the people wanting to omit them. :)
In my experience on Servo, at no point we ever wished for implicit argument passing, but we did just group around a bunch of arguments multiple time in some sort of Context structure in different parts of the system. This also helped documenting what was going on and grepping through the code base etc.
A small thing I often do is select an identifier in my editor and let it highlight all other occurrences to see where it's defined and used. This is also one of the key features of searchfox.org. Implicit argument passing breaks that.

In my experience on Servo, at no point we ever wished for implicit argument passing

This makes a lot of sense to me, and I see more why you guys are pushing back. If you're not dealing with frameworks, you wouldn't run into this pain.
The work you've done for the Context in Servo was done once and won't be done again by those engineers. When you're working with web services framework, and building as per normal building many web services, and the same patterns need to be repeated again and again, it is felt as pain, undifferentiated "boilerplate".
Additionally, within a single application its relatively easy to build a single Context struct shared by all. However, with a framework, you use types from the framework (i.e. not controlled by you), plus types you've made (i.e. not controlled by the framework author), plus types from middleware (i.e. types not controlled by either the framework author or you).
Creating a single Context over and over gets tedious, but also doesn't work well. Your custom methods can take this new consolidated `Context, but middleware will still only take middleware + framework types, and framework functions will still only take framework types. And you end up with less, but similar noise.

The work you've done for the Context in Servo was done once and won't be done again by those engineers. When you're working with web services framework, and as per normal, building many web services, and the same patterns need to be repeated again and again, it is felt as pain, undifferentiated "boilerplate".

I worked 6 years for a dating website before I worked on Servo, I did not feel pain because I was missing implicit argument passing.

Additionally, within a single application its relatively easy to build a single Context struct shared by all. However, with a framework, you use types from the framework (i.e. not controlled by you), plus types you've made (i.e. not controlled by the framework author), plus types from middleware (i.e. types not controlled by either the framework author or you).

This applies to Servo, you would be surprised by how many independent parts there are in it.

Creating a single Context over and over gets tedious, but also doesn't work well. Your custom methods can take this new consolidated Context, but middleware will still only take middleware + framework types, and framework functions will still only take framework types. And you end up with less, but similar noise.

Again, this is entirely the same with implicit argument passing except that you can't track the code flow just by reading it. There is nothing that implicit argument passing can do that explicit argument passing can't, as per the topic discussed in this topic.
If you are actually arguing about something else, you should probably open a different issue.

Rocket uses function decorators to validate the user when  handling a HTTP request.  Perhaps Yazaddaruvala can use a similar approach to solve the issue in the RFC - But it may only compile on nightly.
https://rocket.rs/guide/requests/#request-guards

I worked 6 years for a dating website before I worked on Servo, I did not feel pain because I was missing implicit argument passing.

And that website / service did not use thread local data? I find that hard to believe. In PHP effectively everything is thread local. Node uses domain information excessively behind the scenes. Django and Flask in the Python world are using TLS behind the scenes. Ruby on Rails uses TLS as well.

And that website / service did not use thread local data? I find that hard to believe. In PHP effectively everything is thread local. Node uses domain information excessively behind the scenes. Django and Flask in the Python world are using TLS behind the scenes. Ruby on Rails uses TLS as well.

The thing you cited correspond to code using globals, which, yet again, don't correspond to implicit argument passing. Could we focus on the merit of implicit argument passing, which by definition is syntactic sugar for something that corresponds exactly to implicit argument passing, and not talk about similar-yet-unrelated features which should go in their own RFC or issue?

Could we focus on the merit of implicit argument passing

So to avoid us talking about different things:

implicit argument parsing: some data available in the current stack is passed implicitly onwards to a direct caller
context variables: TLS that can be explicitly switched with other forms of concurrency (like tasks, greenlets etc.). More importantly multiple tasks within one thread might share the same context variable.

You replied to a comment about me arguing that implied function argument passing is not a sufficient solution for actual problems (need for context variables) but in a way that I was assuming you are arguing against the need of context variables / TLS supporting async tasks altogether. If that's not the case then please ignore my comments.

As an aside, you can always do mutable implicit parameters with a state monad anyways, except maybe not your missfeature find_goal_nodes(child, with { goal: goal.negate() }); that I complained about upthread.
struct State<S,T>(FnMut(S) -> (T,S));
... // impl bind, etc. to make it monad-like and provide a do notation

fn find_goal_nodes(root: &TreeNode)
  -> State<(Predicate<...>, &mut Vec<&TreeNode>),()>
{ State(|(goal, results)| {
    ...
} } // State

You'll want a do notation to give this monad more implicit feeling parameters.  Right now, there are two do notations in Rust created by the Try RFC #1859 and the generators eRFC #2033.  I suspect either work actually but ? might require too strict a bind and maybe #[async] might permit hiding the closure.
In other words, you should attempt to do this using coroutines, almost as if it were an Iterator, maybe it'll actually look okay.

At minimum, actually doing this via a state monad with coroutines/generators providing the do notation should be informative for coroutines/generators, like if anything does not work then certain iterators must be unnecessarily tricky to write as coroutines/generators.

Either I'm hopelessly confused, or most of this discussion is about hypothetical ideas that have very little in common with what originally was or currently is in the proposal at the top of the thread. Unfortunately this design space is one where it's almost impossible to fairly evaluate an idea without some concrete code samples, and all the samples presented here so far are only convincing me that most of these ideas are either not even a net win for write ergonomics, or are making a small win write ergonomics at a substantial cost in read ergonomics.
I say "most" because there's a handful of comments that, at least to me (I've never looked into AOP), are so vague I can't even form enough of a strawman proposal in my mind to ask specific questions about them. In particular:

The goal of a context system is to make things which are currently global state ... slightly more local. Traditionally TLS is used for this, but this cannot work with async systems.

What is a "context system" that's not just using a bunch of globals or passing a context argument around? I can imagine helpful sugars or conventions on top of those two options, but nothing that changes the fundamental trade-offs.

I've compiled all of the feedback, and updated the original proposal.
Changed the motivation, extended it to show the current solutions, why they are not adequate. I've added extra example and alternate proposed solutions to achieve the same end result, without using the same mechanism.

There are two places this feature can effect readability, a function's signature, and a function's implementation.

What about function call sites? You don't always need to read the function signature if you can infer it from the function name and arguments used at the call site. If I had to read the signature for each function in a body of code it will soon get very irritating.
Please stop pushing this misguided "ergonomic" improvement. If anything it is an ergonomic setback for readability.

There are two places this feature can effect readability, a function's signature, and a function's implementation.

What about function call sites? You don't always need to read the function signature if you can infer it from the function name and arguments used at the call site. If I had to read the signature for each function in a body of code it will soon get very irritating.
Please stop pushing this misguided "ergonomic" improvement. If anything it is an ergonomic setback for readability.

Please stop pushing this misguided "ergonomic" improvement.

Please consider your tone here. This is not very cordial.
I assume @yazaddaruvala has legitimate reasons for pursuing this and considers this to be an improvement even if only for writing. Reasonable people can disagree over what the trade-offs are and where we land on scale. I believe if nothing else some interesting ideas have been spread here and discussed in this topic and we are all richer for it as people.

I am sorry that came off a little harsh.

"Whenever there is a difference of opinion between [the writers of code and the reader of code], the readers are always right and the writers are always wrong." - 10min into Yaron Minsky's Effective ML lecture
Said differently, any utility derived from making code shorter actually comes entirely from making the code more comprehensible, i.e. more readable, even say fn as opposed to function works due to improving visual tokenization.
Implicit parameters can only make code more readable when used in constrained ways, like DSLs or @mitsuhiko list.  It's not the implicitness per se that makes implicit parameters a missfeature but lack of constraints that tell the reader what is going on.
There are however several type system approaches like do-notation for state monads, dependent types, and structural records that afaik provide any readability improvement you might gain through implicit parameters.  I only named fancy ones so far, but simply using self more aggressively works too:
struct FindGoalNodes {
    goal: Predicate<...>,
    results: &mut Vec<&TreeNode>)
}
impl FindGoalNodes {
    fn go(&mut self, root: &TreeNode) {
        if (self.goal.evaluate(root)) {
            self.results.push(root);
        }
        let goal = self.goal.negate();
        for child in root.children() {
            self.go(child);
            FindGoalNodes { goal, ..self }.go(child);
        }
    }
}

After writing that, I now realize you're likely fighting the borrow checker here, so actually NLL will largely solve your problems:
impl FindGoalNodes {
    fn go(&mut self, root: &TreeNode) {
        let FindGoalNodes { goal, ref mut results } = *self;
        if (goal.evaluate(root)) {
            results.push(root);
        }
        let goal = goal.negate();
        // our borrow of self.results ends here under NLL so self becomes usable again
        for child in root.children() {
            self.go(child);
            FindGoalNodes { goal, ..self }.go(child);
        }
    }
}

I'll point out that Haskell's FRUs are more terse so that last line becomes self { goal }.go(child); there. I've no opinion on Rust vs Haskell FRUs myself, like maybe Rust's more explicit FRUs are better, and Haskell just needs terse ones to make up for lacking mutability.
Also, I'll point out that if you wanted another self parameter then you can always do impl<'a> (&'a mut FindGoalNodes, &'a mut MyOtherSelf) { ... } or whatever.  We might ask for @ to play nice with NLL so that let (fgn @ &mut FindGoalNodes { goal, ref mut results }, selfy) = self; permitted you to abandon results to get pack to fgn.

You might also ask if there is much sense in destructuring self in fn declarations ala
impl<'a> (&'a mut FindGoalNodes, MyOtherSelf) {
    fn go(self: (fgn, selfy), root: &TreeNode)

I just noticed the WithContext proposal for Futures which handles augmenting self nicely:  https://github.com/rust-lang-nursery/futures-rfcs/pull/2#issuecomment-363923477 (https://aturon.github.io/2018/02/09/amazing-week/)

I just noticed the WithContext proposal for Futures which handles augmenting self nicely: https://github.com/rust-lang-nursery/futures-rfcs/pull/2#issuecomment-363923477  via https://aturon.github.io/2018/02/09/amazing-week/

@burdges this thread is pretty massive, but you (and others) might be interested in jumping back to this comment which discusses that approach.

@yazaddaruvala Just a note on the RFC procedure: If you want to file a formal RFC to be considered by the language team for inclusion into Rust, this needs to be done as a pull request to this repository. Check out some merged and closed RFC to get a sense of what the process will look like.

This is a really old RFC and a lot has changed in the Scala world which a lot of the implicit talk above references. Scala 3 is moving away from implicit in favor of something a little less magical. In particular given and using I think are the features most relevant to this RFC is the Scala 3 .
Taking a Scala 3 example and pseudo translating to Rust:
given globalEc: ExecutionContext = ForkJoinPool()

fn whatever(value: i32)(using ec: ExecutionContext) { /* ... */ }

whatever(42)


feature Add memory limit for pip_scanner_context

Proposed changes
#18125
pip_scanner_context's memory usage should be limited. Because:
1 It can reduce memory usage and reduce allocating new blocks when executing.
2 When the memory is limited, the schedule times of scanner_ctx and scanner can be limited.
Co-authored-by: wangbo<EMAIL_ADDRESS>Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Conntrack parsing issue "/proc/net/stat/nf_conntrack" does not exist

I'm running a full ipv6 linux host with nftables (iptables replacement)
I'm notice that conntrack node-exporter collector is failing on all hosts because "conntrack probably not loaded"
I've followed the source code until line https://github.com/prometheus/node_exporter/blob/4d0c1650b5a8f9c653188a18c8d36354365b4720/collector/conntrack_linux.go#L130
A little strace show this failure in opening a folder to fetch stats from procfs
openat(AT_FDCWD, "/proc/sys/net/netfilter/nf_conntrack_count", O_RDONLY|O_CLOEXEC) = 8
epoll_ctl(4, EPOLL_CTL_ADD, 8, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2864231944, u64=140315150824968}}) = 0
fcntl(8, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(8, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
fstat(8, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(8, "385\n", 512)                   = 4
read(8, "", 508)                        = 0
epoll_ctl(4, EPOLL_CTL_DEL, 8, 0xc000204b2c) = 0
close(8)                                = 0
openat(AT_FDCWD, "/proc/sys/net/netfilter/nf_conntrack_max", O_RDONLY|O_CLOEXEC) = 8
epoll_ctl(4, EPOLL_CTL_ADD, 8, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2864231944, u64=140315150824968}}) = 0
fcntl(8, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(8, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(8, "32768\n", 512)                 = 6
read(8, "", 506)                        = 0
epoll_ctl(4, EPOLL_CTL_DEL, 8, 0xc000204b2c) = 0
close(8)                                = 0
newfstatat(AT_FDCWD, "/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}, 0) = 0
openat(AT_FDCWD, "/proc/net/stat/nf_conntrack", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "level=debug ts=2021-08-08T22:01:"..., 126level=debug ts=2021-08-08T22:01:14.597Z caller=conntrack_linux.go:156 collector=conntrack msg="conntrack probably not loaded"
) = 126
write(2, "level=debug ts=2021-08-08T22:01:"..., 174level=debug ts=2021-08-08T22:01:14.597Z caller=collector.go:167 msg="collector returned no data" name=conntrack duration_seconds=0.001267422 err="collector returned no data"
) = 174

It's seam that file /proc/net/stat/nf_conntrack does not exist and procfs project try to open it https://github.com/prometheus/procfs/blob/5162bec877a860b5ff140b5d13db31ebb0643dd3/net_conntrackstat.go#L43
It's strange because, nftables seems to use the netfilter conntrack module
root@app1:~# lsmod | grep conn
nf_conntrack_netlink    32768  0
nf_conntrack           86016  3 nf_nat,nft_ct,nf_conntrack_netlink
nf_defrag_ipv6         12288  1 nf_conntrack
nf_defrag_ipv4         12288  1 nf_conntrack
libcrc32c              12288  2 nf_conntrack,nf_nat
root@app:~# cat /proc/sys/net/netfilter/nf_conntrack_count
385

But without producing the same proc/ pseudo file at /proc/net/stat/nf_conntrack
I'm running linux version Linux 5.4.0-1044-kvm #46-Ubuntu SMP Wed Jul 14 21:36:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
https://github.com/prometheus/procfs/blob/5162bec877a860b5ff140b5d13db31ebb0643dd3/net_conntrackstat.go#L83

Nothing here seems to replace the missing counters file https://www.kernel.org/doc/html/latest/networking/nf_conntrack-sysctl.html

I've found this old kernel patch https://patchwork.ozlabs.org/project/netfilter-devel/patch/20120627110147.GA25605@1984/ related to how "/proc/net/stat/nf_conntrack" is produced nowadays. I can understand that the module nfnetlink_conntrack is responsible to produce theses counters, but according to my previous "lsmod" It seems to be required by nftables as for netfilter so it is also enabled.

I don't think there is an issue with procfs or node-exporter. If stat file is missing the node exported will print debug message "conntrack probably not loaded" but maybe the message is slightly misdealing, because some metrics exists and module nf_conntrack is loaded. But if stat file is here it will return it as well. Also it's not clear to me how to turn on/off stat file presence,  looks like nf_conntrack module is not enough.
# HELP node_nf_conntrack_entries Number of currently allocated flow entries for connection tracking.
# TYPE node_nf_conntrack_entries gauge
node_nf_conntrack_entries 45
# HELP node_nf_conntrack_entries_limit Maximum size of connection tracking table.
# TYPE node_nf_conntrack_entries_limit gauge
node_nf_conntrack_entries_limit 262144

I discovered a related issue recently (no errors but stats not being exposed) and found this link https://serverfault.com/questions/1080112/statistics-proc-net-stat-nf-conntrack-is-missing-on-linux-server.  It seems the proc nf_conntrack file is disabled by default on a lot of newer kernels and the replacement is userspace conntrack binary.
I would love to see this functionality, but it looks like we would have to execute and parse the output of this application from what I can tell.  Any thoughts?

We don't allow executing other binaries in the node-exporter. If there is no e.g kernel interface to it, this would need to be a separate exporter or use the textfile collector.

We could probably get the conntrack stats via https://github.com/ti-mo/conntrack in the node-exporter if someone wants to take a stab at that.

What about the fact that when the stat file is missing the collector_success{collector="conntrack"} metrics is set to 0 ( failed ) ?
in my case this is of course triggering alerts, since on nftables we don't expect this stat file to be available should we avoid failing the whole collector when only https://github.com/prometheus/node_exporter/blob/6a0598e563213ae95edb6f5152ffc8156abd0932/collector/conntrack_linux.go#L131 fails ?

You can disable the collector explicitly. But right, we might consider not setting collector_success = 0 but that would be an issue for the node-exporter if someone wants to fill it. I don't think there is anything in procfs to do, so closing the issue.


ERROR for class transition in utils.py

https://github.com/Kari-Genomics-Lab/iDeLUCS/blob/4c8df59a3d9e0fa2a1171a96afd5de7e1bbacc29/idelucs/utils.py#L75
seq[i] = mutations[mutations.get(seq[i], N)]
u use mutions twice，which means no mutations is used.
It is a apprent logical error. And the result is call for transition method would't work at all!!!
u can test the error with
`        seq = bytearray(b'ACGTACGTACGTACGTACGTNNNN')
A, C, G, T, N = ord('A'), ord('C'), ord('G'), ord('T'), ord('N')
mutations = {A:G, G:A, T:C, C:T, N:N}
seq[1] = mutations[mutations.get(seq[1], N)]
print(seq)`

Thank you, you are right