Error when replacing text quickly

VSCode Version: 1.6.1
OS Version: Windows 10 Enterprise version 1607

Steps to Reproduce:

Open a new file.
Write "I like fine wine."
Open search.

Search for "i".
Replace with "aye".
Leave other options blank.

Hit enter.
Open the "foo.txt" section that appears below.
Click on the first result. (There are 4, one for each "i" in the source text.)
Hover over the "replace" button that appears.
Click twice quickly.

Expected: "aye layeke fine wine."; got: "ayeayelike fine wine."
The error does not happen if clicking slowly.

So it did the replace twice on one entry? I can't repro this, clicking very quickly.

I forgot to mention: Open search in the left pane. Meaning, ctrl-shift-f, not just ctrl-f.

Right, I was trying that

Actually @sandy081 I can repro by pressing ctrl+shift+1 quickly. And if I press it several times, I get more 'aye's inserted in the wrong places.

@andy-ms, @roblourens good catch.

Root cause of the problem is that Search results are not getting updated immediately after replace. There is a time delay between replacing and updating model. I am also removing the current search result (that is replaced) immediately before updating the model. This is giving the user a time frame to do replace on a next result which is not updated after replace that is causing this erroneous results.
There are multiple parts to the fix:

Do not remove the search result that is asked to replace. Model update does that anyway.
Trigger the model update immediately
Disable the replace action on the selected result once it is invoked.

There is also another corner case issue which was seen with this issue: Navigating (keyboard) the results while replacing does not focus the next element (if next match is in the same line). Focus gets lost to root of the Tree. I will fix this as a separate commit in this issue.


Make hashing of a basic_string_view constexpr

please apply this change to all other instances of hash as well so it's consistent


Go back in Safari without leaving warning

Go back in Safari does not trigger the leaving warning; the good thing is that we can press go forward to return to the previous state, with all data remained. The bad thing is, if we press go back in Safari, then open a new webpage, the data stored in homotopy.io will go, without a leaving warning.

related to #47

@calintat Can you check if this is still an issue?

Yeah it's still an issue.


[Bug]: "getboundingbox: Expected 2 arguments, got 3"

Preflight Checklist

[X] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Fabrication Toolkit Version
4.1.1
What operating system are you using?
Windows
Operating System Version
Win11
What arch are you using?
x64
Last Known Working Fabrication Toolkit version
No response
Expected Behavior
Normal
Actual Behavior
When creating the files, I get an error stating, "FOOTPRINT_Getboundingbox expected 2 arguments, got 3. Wrong number of arguments."
I am using the latest nightly of kicad, which I should not be doing and I am now stuck with this issue, unfortunately. Other projects work fine in the nightly still, but I did something in this project that your plugin doesn't like. Any ideas?

Additional Information
No response

you have to many comma's


Make test for public API more strict

There were a couple APIs that we were exposing that didn't have tests to validate them.
This changes the init.spec.lua API to require that everything we expose is explicit and intentionally exposed.

Coverage remained the same at 88.689% when pulling bf817d7e57509ac6e8ca4d2597be2caea02be6cb on public-api-tests into 882ab367a0b703c2e60b6c286f8e11bbc93368c6 on master.

WRT unstable parts of the API: would the idea be to have a something like an UNSTABLE child of the main Roact object?  Then just set to UNSTABLE = true in the public api object?

That would work, yeah.


Crash on PDFThumbnailCollectionViewController

When I try to swipe left on the last page of the book I have opened via this library, the app got crashed and I am attaching the screenshots.

@stuffmc @benbahrenburg @MarcoFilosi @le4ker @ranunez please check that issue

@stuffmc @benbahrenburg @MarcoFilosi @le4ker @ranunez please respond asap

Totally not into PDFs anymore for my current job so I hope the others can have a look.


Unable to unzip systemT extractors after exporting from NLP Editor

I am unable to unzip the exported systemT extractor from NLP Editor.
Note: I am using latest UI and backend container (01-ibm_watson_discovery_nlp_web_tool_backend_v0.5.0-06Dec2022.tar)
backend_logs.txt
ui_logs.txt
Simple_Flow.json.zip
NLP_Canvas_Export(8).zip

Hi @avinashreddy07

You had exported zip files before and tested them just fine. Do you now see this failure every time you export or only at certain times?

We have tested with Safari, Chrome and Firefox on Mac. It worked fine. By any chance, are you seeing this error on a browser running on Windows or Linux machine?

I am able to export on MacOS Monterrey 12.6 and the following browser:

Firefox 107.0.1 (64-bit) and 108.0 (64-bit) - export works well.

I do see the error on these browsers:

Chrome Version 108.0.5359.98 (Official Build) (x86_64); An older version of Chrome did work for me, so this is something that started happening only recently.
On Safari Version 16.0 (176<IP_ADDRESS>.10, 17614)

I tested the Export feature on my Mac (v12.6 Monterey)  with the following browsers.
Firefox: v108.0 (64-bit)
Safari Version 16.0 (176<IP_ADDRESS>.10, 17614)
Chrome: Version 108.0.5359.124
On Firefox and Safari on my Mac, it gets the exported zip file just fine with its expected file size. I'm able to unzip the downloaded zip file.
On Chrome, it downloads the exported zip file only partially. That will obviously cause error while unzipping.
@marthacryan Could you please check the frontend code logic where it does the download of the exported zip file to see why it is downloading only a partial zip file? You can print the size of the exported zip file that you find in the run-aql-result shared directory just before the file download logic is executed. It will give us an idea about the size of the zip file written by the backend and the size of the zip file that gets downloaded by the chosen browser. Thank you.

Hi @nysenthil , NLP Editor is hosted on Ubuntu 22.04.
I tried exporting zip from -

Chrome Version 108.0.5359.98
Firefox Version 108.0
Safari Version 16.2 (186<IP_ADDRESS>.5)

I faced the same issue while unzipping the exported zip.
My Mac OS version is macOS Ventura 13.1 (22C65)

@nysenthil / @marthacryan .. Can we prioritize this issue? Looks like we can't yet use the built extractors in our product. Thanks.

Hi @praveenmidde All the new versions of the browsers (Firefox, Chrome, Safari) seem to have problem exporting the flow. We are going to look into it this week.

@nysenthil @avinashreddy07 @praveenmidde Sorry for the slow reply over the holidays - I just tried this out and wasn't able to reproduce it on either Chrome or Firefox. The inconsistency with this is making me wonder if there's some browser caching happening? I could also see it happening inconsistently if there's an issue with the streaming of the zip file contents but unfortunately if I can't reproduce it locally I won't be able to debug

@avinashreddy07 this was fixed. Please let us know if you still encounter issues.

@laurachiticariu, now I could download the zip. Thank you for fixing this issue.


scribusUnstable not building

Describe the bug
Just switched to channel 21.11 however I had to disable scribusUnstable for it to work.
Steps To Reproduce
Steps to reproduce the behavior:

switch to 21.11
install pkgs.scribusUnstable
view error during build

Expected behavior
scribusUnstable should build without any problems
Additional context
here some output from the build
/build/scribus-1.5.7/scribus/fonts/sfnt.cpp: In function 'QByteArray sfnt::subsetFaceWithHB(const QByteArray&, QList<unsigned int>, int, QMap<unsigned int, unsigned int>&)':
/build/scribus-1.5.7/scribus/fonts/sfnt.cpp:1260:3: error: 'hb_subset_input_set_retain_gids' was not declared in this scope; did you mean 'hb_subset_input_set_flags'?
1260 |   hb_subset_input_set_retain_gids(hbSubsetInput.get(), true);
|   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|   hb_subset_input_set_flags
/build/scribus-1.5.7/scribus/fonts/sfnt.cpp:1261:3: error: 'hb_subset_input_set_drop_hints' was not declared in this scope;did you mean 'hb_subset_input_set_user_data'?
1261 |   hb_subset_input_set_drop_hints(hbSubsetInput.get(), false);
|   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|   hb_subset_input_set_user_data
/build/scribus-1.5.7/scribus/fonts/sfnt.cpp:1263:3: error: 'hb_subset_input_set_name_legacy' was not declared in this scope; did you mean 'hb_subset_input_set_flags'?
1263 |   hb_subset_input_set_name_legacy(hbSubsetInput.get(), true);
|   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|   hb_subset_input_set_flags
/build/scribus-1.5.7/scribus/fonts/sfnt.cpp:1266:57: error: 'hb_subset' was not declared in this scope; did you mean 'hb_set_set'?
1266 |   QScopedPointer<hb_face_t, HbFaceDeleter> hbSubsetFace(hb_subset(hbFullFace.get(), hbSubsetInput.get()));
|                                                         ^~~~~~~~~
|                                                         hb_set_set
make[2]: *** [scribus/CMakeFiles/scribus.dir/build.make:7199: scribus/CMakeFiles/scribus.dir/fonts/sfnt.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2177: scribus/CMakeFiles/scribus.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
builder for '/nix/store/fj357q3nxqkz3yscrkr73vzxvy0h9x9m-scribus-1.5.7.drv' failed with exit code 2
cannot build derivation '/nix/store/lfxxd42ip5g9p7jh1wi8spsdh5kg70ji-system-path.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/l5g12ghfbkfgrrhdyp1gdsk2slgli7c1-nixos-system-gram17-21.11.333823.96b4157790f.drv': 1 dependencies couldn't be built
error: build of '/nix/store/l5g12ghfbkfgrrhdyp1gdsk2slgli7c1-nixos-system-gram17-21.11.333823.96b4157790f.drv' failed

Notify maintainers
@erictapen @Kiwi
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
- host os: `Linux 5.14.10, NixOS, 21.11 (Porcupine)`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.3.16`
- channels(root): `"nixos-21.11.333823.96b4157790f"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

This was fixed in 35d624300b259b5508eea97ed346599f38bcfee5. Unfortunately the backport came a bit close to the release, so you might need to wait a few days until it hits the nixos-21.11 channel.

It just got published, so updating your nixos-21.11 channel should produce a building scribusUnstable from now on.

worked - awesome!


AU should be a special case with queue size 1

AU is by far the most spammed site outside of SO. It was also hit by a troll recently. There is enough spare API calls to use queue size 1 for AU (doubling the number of requests to it).
Also: since "time sensitive" category means that queue size drops to 1 between UTC 4 and UTC 12, the sites that have queue size 1 already need not be in that category, it's redundant.
Finally, writers.SE is now writing.SE, the old name still works for the API but will not match the new site name provided by websocket connections.

Coverage remained the same at 65.199% when pulling dcacea48203b27ad2567c9648fcba0943f19ceec on normalhuman:patch-2 into 617917bfe9e372891e49028431b054f1d38f2acc on Charcoal-SE:master.


LDC screen clones to an HDMI but not able to interact with the RPi anymore

I have installed raspi2raspi without error as per the instructions. I do get a clone of the RPi LCD touchscreen onto an HDMI connected screen. However, I am not able to interact with the system afterwards. There is no way to move the mouse pointer or enter any text, and because 'raspi2raspi' has been set to run at Boot, I cannot do anything with the Raspberry Pi at the moment. Any advice?

You will need to find another way to log into your Pi. For example you can use ssh to remotely, then follow the uninstall instructions. It would be best to ask a question on the Raspberry Pi forum to get some help to remove the raspi2raspi service.

Thank you Andrew, I was hoping if you would have an idea of what could cause that type of behaviour using 'raspi2raspi' as it is a functionality I really would like to use.


Error accessing prometheus server  for cdk-erigon-node-001 and pprof metrics profile.

System information
Ubuntu-22.04.4, x86_64, 12th Gen Intel i5-12450H (12) @ 4.400GHz
Commit id
abc7d5dd6392ad1bdf1ea4eb270cd966532253df
Tools versions
Don't have any such script.
Description & steps to reproduce

Cloned the repo as is with the provided commit hash
Followed the README and installed all the dependencies listed
jq
yq (v3)
cast
polycli
Docker
Ran the following commands to spin up the containers

kurtosis clean --all
kurtosis run --enclave cdk-v1 --args-file params.yml .

And the chain is running successfully with the following output:

The node's rpc is also responding correctly and tx are being submitted and processing correctly.
Firstly, there was no url to open up the grafana dashboard for the L2 so i decided to create my own by feeding it the prometheus logs of the node.
But when i query the prometheus metrics at http://<IP_ADDRESS>:32790 it returns this
➜  ~ curl localhost:32790
curl: (56) Recv failure: Connection reset by peer

And when i query pprof I get 404 not found
When i try to point my grafana data source to prometheus's url , it returns
Get "http://<IP_ADDRESS>:32790/api/v1/query?query=1%2B1&time=4": dial tcp <IP_ADDRESS>:32790: connect: connection refused - There was an error returned querying the Prometheus API.

Desired behavior
Ideally I should be able to gracefully add prometheus metrics as a data source to build my grafana dashboard and acceess it locally.
Ideally i should also be able to access the ui_dashboard of pprof.
As an improvement i should also be able to have my grafana dashboard already configured with the node's prometheus logs so I don't have to set them up manually.
What is the severity of this bug?
Painful; This is causing significant friction in my workflow.

@EggsyOnCode What does your params.yml look like? The prometheus_grafana services are disabled by default:
  # Additional services to run alongside the network.
  # Options:
  # - arpeggio
  # - blockscout
  # - blutgang
  # - erpc
  # - pless_zkevm_node
  # - prometheus_grafana
  # - tx_spammer
  additional_services:
    - prometheus_grafana

@EggsyOnCode yup! that should do it, I'm taking a look to figure out your pprof issue. So let me know if that works.

@EggsyOnCode ah so for pprof, there's just nothing that exists on the base url. Try something like $PPROF_ADDR/debug/pprof/ and you should see something more meaningful 😄

Hey, I added  additional_services: [prometheus_grafana, blockscout] as you suggested but these services didn't start as expected.
I can share my terminal log for kurtosis run --enclave cdk-v1 --args-file params.yml .  and params.yml if you like
@minhd-vu

Yup please share your terminal log. If you haven't already make sure you do a kurtosis clean --all before the kurotsis run

terminal.log
You can start reading from line 15 ; and search for "prometheus_grafana"

Ah okay, because the additional services are run closer to the end, sometimes if something earlier breaks, it will short circuit and prevent those services from being deployed. In your instance it looks like the bridge-ui failed to start.
Sometimes successful runs are not deterministic so here's some of the steps I go through in order to get them working:

Restart docker
Clear all containers and images in docker
Pull main
kurtosis clean --all && kurtosis run --enclave cdk-v1 --args-file params.yml .

Let me know if anything changes.


Validator proposal creation should fail when description is empty

At the moment the proposal is created successfully when description is empty but it fails during execution.

Solved by #163.


Implement Control.Concurrent.Counter.Unlifted in CMM

Just an experiment to avoid any overhead for MutableByteArray inspired by @TerrorJack's https://gist.github.com/TerrorJack/4a48ed790155cc79619fffe9f5844521.
Caveats:

Does not work in GHC JavaScript backend, which should probably retain the previous, pure Haskell implementation.

Needs more care on 32-bit machines, current code is 64 bit only.

ccall hs_atomic_add64 is suboptimal on x86_64, but at the moment hand-written CMM cannot access call MO_AtomicRMW W64 AMO_Add, see https://gitlab.haskell.org/ghc/ghc/-/issues/23206.

Hmm, tests are failing on GHC 9.4.4, macOS x86_64:
 All
  Correctness:            OK (9.99s)
    +++ OK, passed 500 tests.
  Correctness, no delays: FAIL (0.27s)
    *** Failed! Falsified (after 3479 tests):
    Threads {unThreads = Thread {tDelay = Delay {unDelay = 6}, tIncrement = -950, tIterations = Iterations {unIterations = 7}} :| [Thread {tDelay = Delay {unDelay = 8}, tIncrement = -441, tIterations = Iterations {unIterations = 37}},Thread {tDelay = Delay {unDelay = 6}, tIncrement = -452, tIterations = Iterations {unIterations = 0}},Thread {tDelay = Delay {unDelay = 4}, tIncrement = -389, tIterations = Iterations {unIterations = 49}},Thread {tDelay = Delay {unDelay = 0}, tIncrement = -294, tIterations = Iterations {unIterations = 40}}]}
    -110710340 /= -53788
    Use --quickcheck-replay=512982 to reproduce.
    Use -p '/Correctness, no delays/' to rerun this test only.

Whatever the sequence of updates, the result must have been below five digits, so -110710340 suggests memory corruption.
@TerrorJack, any idea where I messed up?

Great! I was just thinking about this too. Thanks @Bodigrim

Pong, will take a closer look next week.

I'm also interested in seeing this work, don't mind my second ping @TerrorJack

Would you give https://gist.github.com/TerrorJack/e3f1231fa65b3d1f5ea63065dd33a87f a try and see if it fixes the issue? Honestly I'm no less puzzled than you why the original version has this memory issue, but this diff seems to help.

Thanks @TerrorJack, this seems to work.
I think this is ready for review now.

FWIW LGTM

Benchmarks:

Name
07f4b51
3dd86a3
Ratio

10 iterations and 1 threads
626901
650901
1.03828

100 iterations and 1 threads
1057955
1065232
1.00688

1000 iterations and 1 threads
4767930
4846413
1.01646

10000 iterations and 1 threads
40603875
40717926
1.00281

10 iterations and 2 threads
6199483
6215062
1.00251

100 iterations and 2 threads
6786286
6637318
0.978049

1000 iterations and 2 threads
36046876
37277081
1.03413

10000 iterations and 2 threads
466461621
459297509
0.984642

10 iterations and 4 threads
14304393
14116542
0.986868

100 iterations and 4 threads
22378799
21837321
0.975804

1000 iterations and 4 threads
241044897
221475244
0.918813

10000 iterations and 4 threads
2411656445
2126885546
0.881919

10 iterations and 6 threads
29380970
31528617
1.0731

100 iterations and 6 threads
51806632
49229728
0.950259

1000 iterations and 6 threads
421304931
389744873
0.92509

10000 iterations and 6 threads
10803454687
10544148437
0.975998

10 iterations and 8 threads
33264868
33220318
0.998661

100 iterations and 8 threads
70489263
68710925
0.974772

1000 iterations and 8 threads
751835473
614695391
0.817593

10000 iterations and 8 threads
18112116015
17322731250
0.956417

10 iterations and 12 threads
37138810
37928328
1.02126

100 iterations and 12 threads
111093969
99659307
0.897072

1000 iterations and 12 threads
2238697705
1766967041
0.789283

10000 iterations and 12 threads
24245685546
23640137500
0.975025

10 iterations and 16 threads
43222968
43582453
1.00832

100 iterations and 16 threads
145973196
137985633
0.945281

1000 iterations and 16 threads
3376071093
2974715039
0.881117

10000 iterations and 16 threads
35231724609
34480696093
0.978683

10 iterations and 20 threads
62185274
62320446
1.00217

100 iterations and 20 threads
183011389
173122430
0.945965

1000 iterations and 20 threads
4215415478
3965037304
0.940604

10000 iterations and 20 threads
42896585937
42560037500
0.992154

10 iterations and 32 threads
97156437
99794003
1.02715

100 iterations and 32 threads
260610671
260671594
1.00023

1000 iterations and 32 threads
7016384375
6485634765
0.924356

10000 iterations and 32 threads
73145804687
69175517187
0.945721

10 iterations and 64 threads
172624707
178914562
1.03644

100 iterations and 64 threads
610634515
591822558
0.969193

1000 iterations and 64 threads
14407456250
13955856250
0.968655

10000 iterations and 64 threads
151388475000
148245268750
0.979237

10 iterations and 128 threads
294979428
300389105
1.01834

100 iterations and 128 threads
1733554345
1293563940
0.746192

1000 iterations and 128 threads
29561675000
27645350000
0.935175

10000 iterations and 128 threads
303322475000
296239175000
0.976648

Geometric mean

0.96143

Interestingly the biggest speed up, up to 25%, is observed for 1000 iterations, while measurements for 10000 iterations are consistently better, but less impressive, up to 11%.

Impressive, thanks a lot!

NB for comparison of CMM against mutable prim array one can compare against Addr row in the benchmarks - it was on par with singleton array previously.

Released as 0.1.1.


How come is it possible to exceed 1 when you scaling down stock market data when Neural Network only know -1, 1?

On your stock market example, I see the ScaleDown function outputs for instance say 1.02 and I believe it exceed the 1 thing
I'm sorry but new to whole this world.

You'd have to reproduce this for us to try and help.  Closing due to inactivity.


v2: Maintain Minimum Y value after added data point and .update() call

I'm combing through the codebase trying to find where the call is to reset the min for the scale, can someone point me to the right lines to modify? Also I feel this should be a feature add to development, to prevent reset of the min and max of the Y axis.

@rashardhinds for a linear scale this code is in https://github.com/nnnick/Chart.js/blob/v2.0-dev/src/scales/scale.linear.js#L38-L151
If you don't want to have the min/max change, you can hard-code those values in the config.
options: {
    scales: {
        yAxes: [{
            ticks: {
                min: /* your minimum value here */,
                max: /* your maximum value here */
            }
        }]
    }
}

@etimberg Thanks! That looks exactly like what I'm looking for.  I do currently have them hard coded in the config, yet whenever I update a data point and update the changes, the hard coded values are ignored. But looking at the code you linked me to, I think I see why.

@rashardhinds sorry this is delayed. If the min and max are set they should always be used and override the min and max of the data.

Closing as resolved.


V3.0 doesn’t work.

The branch V3.0-beta doesn’t work at all with me. After flashing the keyboard, the middle left LED on the left half would keep blinking, white the right half doesn’t have any blinking LEDs, at all.
I reverted back to the V2.0 branch.

Did you perform a settings reset prior to upgrading? The lights on the right side should slow flash red until connecting. Middle led on left side flashing is normal behaviour. Did you try pressing the mod key (top left key on right side board)? This should illuminate an led green on both sides

Yes, I did all of that.

Does the green led illuminate on both sides when you hold the mod key down?

Prior to flashing, yes. After flashing, not anymore.
The procedure that I used was the same one that I have been using with V2.0.

If you connect the left side to the computer over USB do keys work?

They don’t completely work. So, what I did to reflash it back to V2.0 was to use the pins.

Are you using the default keymap? Did you use the settings reset file in the V3.0 beta branch as it was updated as part of the upgrade?

I had @ebzzry's experience until I used the reset file.

Let me do that.

Just following up, @ebzzry have you had the opportunity to do this yet?

Has resetting with the correct file yielded any change?


Error of submission to 3D Segmentation: INVALID_ARGUMENT: Prediction and Groudtruth length do not match

Hi,
I got some issues when I try to submit results to 3D segmentation evaluation server.
1. The entries of validation set and test set may be oppisite:
I use tutorial_3d_semseg.ipynb to generate a dummy validation set file and try to submit to server. I got the error as following:
INVALID_ARGUMENT: Prediction and Groudtruth length do not match
Then I try to submit the val set file to test set leaderboard that has button "Publish to leaderboard". Then I got the result which are all zeros.
It seems to be very strange. So I try to submit dummy test set file and got the similar error.
2. The results of the dummy file are zero. Is this corrct?
Best regards

Fixed.

So I try to submit dummy test set file and got the similar error.

Hi, I met the same problem. The entries of validation set and test set seem to be oppisite. How did you fix this problem?
Thanks for your time.


nixos/tests/installer: increase /boot sizes to 100MB

Motivation for this change
https://github.com/NixOS/nixpkgs/pull/147560#issuecomment-982191042
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

built all the tests and only grub1 fails
vm-test-run-installer-grub1> machine: must succeed: mkswap /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1-part1 -L swap
vm-test-run-installer-grub1> machine # [   10.064746] systemd[1]: Finished Networking Setup.
vm-test-run-installer-grub1> machine # [   10.066487] systemd[1]: Starting Extra networking commands....
vm-test-run-installer-grub1> machine # [   10.073307] systemd[1]: Finished Extra networking commands..
vm-test-run-installer-grub1> machine # [   10.073948] systemd[1]: Reached target Network.
vm-test-run-installer-grub1> machine # mkswap: cannot open /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1-part1: No such file or directory

but it succeeded after i tried it again ~2 times


RegisterMultiple and ResolveAll

Does Swinject support (or plans to support) ResolveAll and RegisterMultiple as in TinyIoC?
Thanks!

Hi @mennahmostafa😀 Swinject does not support and have plan to support them (though they are technically interesting👍)
I might change my mind if iOS apps have good use cases taking advantage of them.


Wrong use of _rename in BeamBeam3d

I found in the source:
    _rename = {'flag_beamstrahlung': '_flag_beamstrahlung'}
    _rename = {'flag_bhabha': '_flag_bhabha'}

The first has no effect. The correct syntax is:
    _rename = {'flag_beamstrahlung': '_flag_beamstrahlung', 'flag_bhabha': '_flag_bhabha'}

Fixed in https://github.com/pkicsiny/xfields. Thanks for pointing out!

Thanks. Is it understood why this was not cought by the tests? Are the tests passing now?

When this is ready for merge please open a PR

done


App crashes on some videos on iOS

EDIT TWO:
This might be the fix: https://github.com/rurico/flutter_video_compress/pull/61/files I created a pull request based on this
Description
On iOS (possibly on Android too, but not tested extensively enough), with certain video files the app crashes. Is this the behavior if it finds a file it can not compress? If so, would it be possible to share a list with the video types that are supported?
EDIT: Just tested on Android the problem does not persist.

@Martibis I also encountered this problem, I tried your PR, but I don’t have permission to merge your PR.

That makes the two of us I hope @jonataslaw will find some time to take a look at it, and if it's all good hopefully merge and update the package accordingly.

@Martibis  @jonataslaw  This PR is effective and solved my crash.

@jonataslaw can you update in pub.dev too?

i have this issued. please drop new version for solved it.


Keydb show high cpu usage every nights

Hi, I've a keydb cluster in k8s and I've seen high cpu consume during the night.
From 20:00h to 08:00h (GMT+2).
I don't know why happens this. My clients use the system from 8.00h-9.00h more or less to about 20.00h.
Anyone can help me or tell me anything about this fact?
This process repeats everyday.
Thank you!
PD: Add a capture of cpu usage.

Ping!
Are there anybody?
The mistery still...
Anyone can tell anything about this? It's very strange, 20.00h o'clock and 8.00h o'clock, I haven't got any schedule process.

I resolved this issue by myself :)


Make DDC versions more obvious

Deploy preview ready!
Built with commit ee316885c7a86a8b6f5fb7923df488a2334ae3eb
https://deploy-preview-833--docker-docs.netlify.com


Code Error

SQL Error
INSERT INTO DEPARTMENT
VALUES(BSCS,BS Computer Science,WASHU)

Fixed the code. You were just missing quotes
INSERT INTO DEPARTMENT
VALUES ('BSCS', 'BS Computer Science', 'WASHU');


doc: state that only the latest stable toolchain is supported

This closes #11226. The content seemed to make more sense in the
installation section as opposed to the Troubleshooting section.

See https://github.com/rust-analyzer/rust-analyzer/pull/10457#issuecomment-1030917741 for more context.

bors r+


Auto-approve subsequent workflow runs

What
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested demo.rerun.io (if applicable)
[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

Test comment
+approve

🥇 @rerun-bot approve


Major Vulnerability

Your mod has a vulnerability, it affects versions 1.8.9-1.12.2 (according to serialization is bad), because your mod is included in MANY modpacks this is a huge major vulnerability. I advise you fix it immediately
https://github.com/dogboy21/serializationisbad
https://blog.mmpa.info/posts/bleeding-pipe/

Ref: #57
Is there any known workaround to fix this problem?
For 1.7.10, we can use GTNewHorizons' fork. But for 1.12.2, I don't know any solution yet.

Bad code at https://github.com/bdew-minecraft/bdlib/blob/mc1.12/src/net/bdew/lib/network/SerializedMessageCodec.scala#L36
this allows instantiation of arbitrary classes which can be escalated to RCE
it should use an input stream that limits which classes can be instantiated
see https://github.com/dogboy21/serializationisbad/blob/master/core/src/main/java/io/dogboy/serializationisbad/core/ClassFilteringObjectInputStream.java

Just so this thread has some actionable advice
Preventative:

Forge 1.7 to 1.19 - On both server and client, add this mod https://github.com/dogboy21/serializationisbad/releases to your modpack instance. It will auto patch the affected mods. This file has proof that it contains support specifically for bdlib.
Forge 1.6 or below - Use the Java Agent described in this README - https://github.com/dogboy21/serializationisbad#any-other-instances
PipeBlocker may also be able to mitigate some of the problems, but I haven't checked it.

Cleanup:
It is currently unknown which anti-malware vendors target some of the malware that has spread through this route. Right now, exercise caution, enable 2fa on your accounts, practice good security, and don't fall for alarmism.

Closing this in favor of #57 which has more information


snapshot:generate yields inconsistent whitespace

Summary
When I run ./bin/dev snapshot:generate, I get a command-snapshot.json that has extra whitespace compared to other folks. Here's an example: https://github.com/salesforcecli/cli/pull/240/commits/63303be11fe8206a77ba3ffc7e589487000bd128
Steps To Reproduce:
Repository to reproduce: salesforcecli/cli

./bin/dev snapshot:generate
git diff shows a bunch of changes

Expected result
git diff should not show any changes with no code changes.
Actual result
git diff shows a large diff, and it's all whitespace.
System Information
▹ ./bin/dev version --verbose --json
@salesforce/cli/1.33.0 darwin-x64 node-v18.2.0

▹ ./bin/dev plugins --core
@oclif/plugin-autocomplete 1.3.0 (core)
@oclif/plugin-command-snapshot 3.1.3 (dev)
@oclif/plugin-help 5.1.12 (core)
@oclif/plugin-not-found 2.3.1 (core)
@oclif/plugin-plugins 2.1.0 (core)
@oclif/plugin-update 3.0.0 (core)
@oclif/plugin-version 1.0.4 (core)
@salesforce/cli 1.33.0 (core)
config 2.3.2 (core)
deploy-retrieve 1.4.3 (core)
env 1.3.2 (core)
functions 1.7.1 (prerelease)
generate 1.0.14 (core)
info 2.0.1 (core)
login 1.0.9 (core)
release-management 2.12.5 (dev)
└─ trust 1.1.0 (dev)
telemetry 2.0.0 (core)

Further info on this:
bin/dev snapshot:generate does not run prettier on the command-snapshot.json. However, it looks like there is a git commit hook that runs prettier on this file:
$ /Users/josh.lewis/code/cli/node_modules/.bin/pretty-quick --staged
🔍  Finding changed files since git revision 9fb3b64.
🎯  Found 1 changed file.
✍  Fixing up command-snapshot.json.

Since the snapshot on the main branch is not prettified, it looks like there is a pattern of developers bypassing the git commit hooks on salesforcecli/cli. The solution to my problem is to also bypass the commit hooks after regenerating the snapshot. For example:
$ bin/dev generate:snapshot
$ git add -A
$ git commit -m "chore: regenerate snapshot" --no-verify

@joshwlewis are you ok if we close this now that https://github.com/salesforcecli/cli/pull/258 has been merged?
It doesn't make it so that /bin/dev snapshot generate uses prettify but as long as we're diligent about not allowing PRs that check in unprettified command snapshots this shouldn't be a problem again.
And also, running yarn format on sf's repo will also format the command snapshot.

Works for me =)


Support YOLOv2 from TensorFlow to Caffe?

Thanks in advance. I found no YOLOv2 info. in readme.

@ahkarami  ,We have implemented the darknet -> IR part.Try the newest code,Thanks!


add support for resolvers written with es6 classes

Improvement for this issue: https://github.com/dotansimha/graphql-code-generator/issues/4623
yarn build, yarn test passed.
This pr include these changes:
when supportES6Classes === 'true'(default is false):

change type Resolver into 3 arguments(args, context, info), because ES6 class resolvers methods only contain 3 argument . see https://github.com/apollographql/apollo-server/issues/1996
change resolvers output from type to interface, cause to flow type a ES6 class, we need interface. see https://flow.org/en/docs/types/interfaces/

Hi @dotansimha, as we discussed in https://github.com/dotansimha/graphql-code-generator/issues/4623, I would like to add a Flow config to support resolvers written with ES6 classes. Not sure how to assign reviewers here, could you take a look when you have time? Or do you know whom else I should reach out to? Thanks!

@gyDBD This is an awesome initiative, thanks for starting this, this is looking very exciting!!!
I'm wondering if this could be configured on a per type basis - similar to mappers? I'm wondering what happens for when a codebase has a mix of ES6 classes and object literals. (I could imagine using object literals for smaller, less complex types)

Thank you @gyDBD and @magicmark !
I'll review this during this week :)

@dotansimha Hi Dotan, would you mind take a look at this pr when you have time? Thanks!

no longer need this feature


Fix: Allow recorders to define including global resources

what

Create a variable that allows to manually turn on/off including global
resources for a recorder resources

why

If aggregation is configured for Multi-Account / Multi-Region and
the "security" account is configured in one region (e.g. us-west-2)
and an aggregator is configured in a different region (e.g. us-east-1),
then recording global resources can not be turned on. You would have
to recreate the config resource in the same region in the aggregator
account to enable it (even if you aren't actively using that region).

Fixed by #87
Please reopen if we're incorrect in that assumption.


Not able to connect to Azure Storage with client id/secret

deltalake >= v0.6.2
Since deltalake version v0.6.2 I am no longer able to load Delta Lake tables from an Azure Data Lake Storage Gen2 via Azure client id/secret.
import pandas as pd
import pyarrow.dataset as ds
from deltalake.table import DeltaTable

azure_container = "CONTAINER"
delta_table_path = "PATH/TO/TABLE.delta"

storage_options = {
    "AZURE_STORAGE_TENANT_ID": azure_storage_tenant_id,
    "AZURE_STORAGE_CLIENT_ID": azure_storage_client_id,
    "AZURE_STORAGE_CLIENT_SECRET": azure_storage_client_secret,
    "AZURE_STORAGE_ACCOUNT_NAME": azure_storage_account_name
}

delta = DeltaTable(f"az://{azure_container}/{delta_table_path}", storage_options=storage_options)

Error log:
---------------------------------------------------------------------------
PyDeltaTableError                         Traceback (most recent call last)
Input In [9], in <cell line: 1>()
----> 1 delta = DeltaTable(f"az://{azure_container}/{delta_table_path}", storage_options=storage_options)

File /opt/conda/lib/python3.9/site-packages/deltalake/table.py:103, in DeltaTable.__init__(self, table_uri, version, storage_options, without_files)
     90 """
     91 Create the Delta Table from a path with an optional version.
     92 Multiple StorageBackends are currently supported: AWS S3, Azure Data Lake Storage Gen2, Google Cloud Storage (GCS) and local URI.
   (...)
    100                       DeltaTable will be loaded with a significant memory reduction.
    101 """
    102 self._storage_options = storage_options
--> 103 self._table = RawDeltaTable(
    104     table_uri,
    105     version=version,
    106     storage_options=storage_options,
    107     without_files=without_files,
    108 )
    109 self._metadata = Metadata(self._table)

PyDeltaTableError: Generic DeltaTable error: Failed to find valid credential.

As far as I have understood, the following mappings for the client_secret azure configuration are missing in ALIAS_MAP in rust/src/builder/azure.rs. Before v0.6.2 the file rust/src/builder.rs had the config AZURE_STORAGE_CLIENT_SECRET.
        // client secret
        ("azure_storage_client_secret", AzureConfigKey::ClientSecret),
        ("azure_client_secret", AzureConfigKey::ClientSecret),
        ("client_secret", AzureConfigKey::ClientSecret),

@rgelsi - thanks for the report - will have a look into this.

reopening to await confirmation.

Hi @roeap , we ran into this issue and have verified that the version in the main branch fixes the issue. We are eagerly awaiting a new release with this functionality. Do you by chance have an indication of when the next release will be?
We know we can build manually, but we try to avoid doing so on our production systems whenever possible.

@stinodego - a new release is not far away. Best guess we can get it released within roughly a week.

@rgelsi @stinodego has the issue been solved for you with the latest release v0.6.4?

@rgelsi @stinodego has the issue been solved for you with the latest release v0.6.4?

@NilsHahnBayer No, this issue was introduced in v0.6.2 and the fix has been merged after v0.6.4 was released. We are eagerly awaiting the v0.6.5 release, as we're currently limited to using v0.6.1, but we would like to use some of the features introduced more recently.

@rgelsi @stinodego has the issue been solved for you with the latest release v0.6.4?

@NilsHahnBayer No, this issue was introduced in v0.6.2 and the fix has been merged after v0.6.4 was released. We are eagerly awaiting the v0.6.5 release, as we're currently limited to using v0.6.1, but we would like to use some of the features introduced more recently.

@NilsHahnBayer, I am also still waiting for the release of python-0.6.5

@roeap Sorry to ping you - is there any chance for a 0.6.5 release soon? If not, what is the blocker? I might be able to help out.

@stinodego - no worries, a new release is overdue since there are a bunch of unreleased fixes on main. I opened #1073 to track if we are missing something.

@NilsHahnBayer the issue has been solved with the release python-v0.7.0.
Thanks a lot, @roeap


[Test Question]

How to restore(test or inference) a image under multi-degradations uisng GDP? How to use the test scripts?

HI, you can use the following script to have a try! The usage of this script can be found in README
scripts/sample_x0_enhancement_HDR.py

HI, you can use the following script to have a try! The usage of this script can be found in README scripts/sample_x0_enhancement_HDR.py

Thanks for the answering! By th way, it seems need 3 LDR reference imgs as contidion?

Yes, for HDR recovery, we need three LDR reference images as conditions, including LDR-short, LDR-medium, and LDR-long.

Since there are no more questions, I'll mark it closed. If you still have some questions, please feel free to ask. Thanks!

Hello
I would like to ask how to directly test the LOL dataset using the pre-trained model. The image generation time is quite long when following the steps in the README... I would like to know the time required if testing directly.
Looking forward to ur reply.

Hello I would like to ask how to directly test the LOL dataset using the pre-trained model. The image generation time is quite long when following the steps in the README... I would like to know the time required if testing directly. Looking forward to ur reply.

low-light image enhancement task


FLAKE: Kokoro - cloud_to_prod_auth:default:php7:per_rpc_creds

Also looks similar to https://github.com/grpc/grpc/issues/11967, in that the failure is unavailable - filing specific for php though.
2017-07-28 17:47:29,353 Running test case per_rpc_creds
Call did not complete successfully. Status object:
object(stdClass)#7 (3) {
  ["metadata"]=>
  array(0) {
  }
  ["code"]=>
  int(14)
  ["details"]=>
  string(20) "Endpoint read failed"
}

2017-07-28 17:47:29,353 FAILED: cloud_to_prod_auth:default:php7:per_rpc_creds [ret=1, pid=22811]

Please post the link to the Internal CI result if you still have it.

sponge log is that same is in
build page in https://kokoro.corp.google.com/job/grpc/job/ubuntu/job/pull_request/job/grpc_interop_toprod/194/https://kokoro.corp.google.com/job/grpc/job/ubuntu/job/pull_request/job/grpc_interop_toprod/194/
sponge failure log in https://sponge.corp.google.com/target?id=4134491f-6fad-4e3b-8273-a00062fdbd18&target=grpc/ubuntu/pull_request/grpc_interop_toprod&searchFor=&show=ALL&sortBy=STATUS

Dupe of #10763


Add Github topics to the repository

Hi, can you add the following topics to this repository?

https://github.com/topics/smartbroker
https://github.com/topics/dab-bnp

Thanks!

Done. Thanks for the suggestion!

Sure!


Add PP ampacity reading interface

I will add real support to Yeti driver later on, currently yeti HW does not support a connector anyway.


fix: update to eye v10.24.10

fix: update to eye v10.24.10

:tada: This PR is included in version 16.28.10 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v16.28.10

Your semantic-release bot :package::rocket:


Fill out All Columns in Product Backlog

Product Backlog ( /2.5)
Use this template.
Example: Team C 2022
Product backlog and sprint backlog should match i.e. product backlog items in the sprint backlog need to have the same IDs etc. If they do not match deduct -2 points.
Make sure that all of your user stories are in the product backlog. For any missing user story deduct -1 point.
All columns based on the projects’ details document should be in the product backlog and must be filled out. For any missing column or missing information deduct -2 points.

Yes, all columns are filled out


ISO_8601 and parsing YYYY-MMTHH:mm

I'm hoping for clarification; this isn't necessarily an issue.  Wikipedia (yes yes, not necessarily the best source, please point me at a better one) appears to imply that the following is true:

YYYY-MM is a valid "calendar date"
any "complete" <date>T<time> is a valid combined date time, where the date part is calendar, ordinal, or week

.. am I misreading this?  moment doesn't appear to treat, e.g., 2016-01T12:34 as strictly valid:
> moment('2016-01T12:34', moment.ISO_8601, true).isValid();
false
> moment('2016-01-12T12:34', moment.ISO_8601, true).isValid();
true

I'm happy to provide a patch, assuming this isn't a misreading on my part.

Let me whip out the ancient sacred texts....  (yes, I have a legal copy of the ISO 8601 spec)

<IP_ADDRESS> Representations with reduced accuracy
...
a) A specific month
Basic format:   YYYY-MM   Example: 1985-04

So yes, that part is acceptable, but later...

4.3.3 Representations other than complete
For reduced accuracy, decimal or expanded representations of date and time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3 (ordinal dates) or 4.1.4 (week dates) followed immediately by the time designator [T] may be combined with any of the representations in <IP_ADDRESS> through <IP_ADDRESS> (local time), 4.2.4 (UTC of day) or <IP_ADDRESS> (local time and the difference from UTC) provided that
...
c) the date component shall not be represented with reduced accuracy;
...

So, by 4.3.3(c), the combined representation of 2016-01T12:34 is not valid, because the date component has reduced accuracy.

Sweet!  Ancient sacred texts FTW.


Adding info to CG and BICGSTAB

I reviewed and merged this PR prior to recalling that we had some discussion (and draft PRs) on this topic in the past, involving @shoyer @jakevdp @PhilipVinc @nicholasjng and others. Some related threads: #6490, #7825, #7909.

Also tagging #14249, which seems to be a bug revealed by this change in combination with jaxopt.

I reviewed and merged this PR prior to recalling that we had some discussion (and draft PRs) on this topic in the past, involving @shoyer @jakevdp @PhilipVinc @nicholasjng and others. Some related threads: #6490, #7825, #7909.

Thanks for the tag! I think I'm pretty sure I wrote the code for aux support in the custom_linear_solve batching rule that was mentioned in #14249, let me know if you need anything from my end.


cv: image opti

[ ] I have added tests to tests to cover my changes.
[ ] I have updated docs/, if necessary.
[ ] I have updated the README.md, if necessary.

What existing issue does this pull request close?
No issue. This uploads images to minio and retrieves them via presigned url.
How are these changes tested?
Locally!
Demonstration

the text field will be project_id/image_id.image_extension we still need project_id for authorization.


small toc update

Aligning ToC title with doc title

There is an issue with conventionalcommits.org - I can fix this now.

This is just an SSL issue on the endpoint.
They also have a GitHub repo, so using that for now.


Patch: improve openai.ChatCompletion getter

This needs to be updated as openai.ChatCompletion is no longer supported in openai v1. Will re-open if needed.


[Enhancement] Implement Cypress 13 frame work to security dashboard plugin

Description
Implement Cypress 13 frame work to security dashboard plugin
Related PR: https://github.com/opensearch-project/security-dashboards-plugin/pull/1579
Exit Criteria

[ ] Setup the Cypress 13 env in security frontend
[ ] Setup the E2E OIDC functional test workflow

[Grooming] This does not include Windows runner work, to be split off in its own issue by @RyanL1997


OSX support tracking issue

This is a tracking issue for OSX support on tarpaulin

[x] Figure out why my OSX tests don't have the __debug_info section
[x] Update nix and libc to add ptrace support
[x] Update tarpaulin to use updated nix
[x] Fix other compile issues
[x] Refactor ASLR disabling in OSX (not done via personality ffi call)

[ ] Figure out if this has worked (GDB uses same method so it should)

[ ] Look into the IPC ports that are used to send things like termination signals. They are necessary - ptrace on mac isn't fit for purpose
[x] Investigate and update PTRACE_EVENT based code. OSX doesn't support PTRACE_EVENT

I've stuck in ptrace event currently but returns -1 so probably doing nothing

[x] Look at how poke/peek differs with the user struct in OSX vs linux and update code if needed
[ ] General tidy up and refactor
[ ] Tracing working on ARM (for future apple devices)

Resources/links

Abusing Mach on Mac OS X - http://www.uninformed.org/?v=4&a=3&t=pdf

2018/12/05 - gets into initialising the breakpoints to track coverage but none are ever hit and no exit signal.
Original issue text

localhost:src b$ rustc --version
rustc 1.30.0-nightly (721913067 2018-08-26)
localhost:src b$ RUSTFLAGS="--cfg procmacro2_semver_exempt" cargo install cargo-tarpaulin
Updating registry https://github.com/rust-lang/crates.io-index
Installing cargo-tarpaulin v0.6.7
Compiling serde v1.0.78
Compiling semver-parser v0.7.0
Compiling proc-macro2 v0.4.19
Compiling version_check v0.1.4
Compiling pkg-config v0.3.14
Compiling cc v1.0.24
Compiling unicode-xid v0.1.0
Compiling num-traits v0.2.5
Compiling void v1.0.2
Compiling build_const v0.2.1
Compiling matches v0.1.8
Compiling libc v0.2.43
Compiling stable_deref_trait v1.1.1
Compiling rand_core v0.2.1
Compiling scopeguard v0.3.3
Compiling ryu v0.2.6
Compiling unicode-normalization v0.1.7
Compiling failure_derive v0.1.2
Compiling ucd-util v0.1.1
Compiling regex v1.0.5
Compiling nodrop v0.1.12
Compiling memoffset v0.2.1
Compiling percent-encoding v1.0.1
Compiling utf8-ranges v1.0.1
Compiling core-foundation-sys v0.6.1
Compiling crossbeam-utils v0.5.0
Compiling rustc-demangle v0.1.9
Compiling cfg-if v0.1.5
Compiling itoa v0.4.3
Compiling unicode-width v0.1.5
Compiling fnv v1.0.6
Compiling bitflags v1.0.4
Compiling quick-error v1.2.2
Compiling same-file v1.0.3
Compiling byteorder v1.2.6
Compiling adler32 v1.0.3
Compiling nix v0.11.0
Compiling strsim v0.7.0
Compiling termcolor v1.0.3
Compiling remove_dir_all v0.5.1
Compiling hex v0.3.2
Compiling vec_map v0.8.1
Compiling plain v0.2.3
Compiling ansi_term v0.11.0
Compiling glob v0.2.11
Compiling md5 v0.3.8
Compiling termcolor v0.3.6
Compiling shell-escape v0.1.4
Compiling fallible-iterator v0.1.5
Compiling lazycell v0.6.0
Compiling crossbeam v0.3.2
Compiling home v0.3.3
Compiling unreachable v1.0.0
Compiling unicode-bidi v0.3.4
Compiling crc v1.8.1
Compiling owning_ref v0.3.3
Compiling lazy_static v1.1.0
Compiling rand v0.5.5
Compiling memchr v2.0.2
Compiling commoncrypto-sys v0.2.0
Compiling atty v0.2.11
Compiling fs2 v0.4.3
Compiling num_cpus v1.8.0
Compiling memmap v0.6.2
Compiling arrayvec v0.4.7
Compiling regex-syntax v0.6.2
Compiling socket2 v0.3.8
Compiling log v0.4.5
Compiling filetime v0.2.1
Compiling encoding_rs v0.8.6
Compiling uuid v0.6.5
Compiling textwrap v0.10.0
Compiling humantime v1.1.1
Compiling walkdir v2.2.5
Compiling parity-wasm v0.31.3
Compiling backtrace v0.3.9
Compiling smallvec v0.6.5
Compiling cmake v0.1.33
Compiling libz-sys v1.0.20
Compiling openssl-sys v0.9.35
Compiling curl-sys v0.4.8
Compiling miniz-sys v0.1.10
Compiling lock_api v0.1.3
Compiling aho-corasick v0.6.8
Compiling commoncrypto v0.2.0
Compiling gimli v0.16.1
Compiling jobserver v0.1.11
Compiling tar v0.4.16
Compiling clap v2.32.0
Compiling tempfile v3.0.3
Compiling libssh2-sys v0.2.10
Compiling libgit2-sys v0.7.7
Compiling num-traits v0.1.43
Compiling quote v0.6.8
Compiling crypto-hash v0.3.1
Compiling core-foundation v0.6.1
Compiling thread_local v0.3.6
Compiling crossbeam-epoch v0.6.0
Compiling enum_primitive v0.1.1
Compiling semver v0.9.0
Compiling serde_json v1.0.27
Compiling toml v0.4.6
Compiling serde_ignored v0.0.4
Compiling syn v0.14.9
Compiling syn v0.15.3
Compiling gzip-header v0.1.2
Compiling flate2 v1.0.2
Compiling curl v0.4.14
Compiling rustc_version v0.2.3
Compiling idna v0.1.5
Compiling deflate v0.7.18
Compiling parking_lot_core v0.3.1
Compiling url v1.7.1
Compiling synstructure v0.9.0
Compiling scroll_derive v0.9.4
Compiling parking_lot v0.6.4
Compiling globset v0.4.2
Compiling env_logger v0.5.13
Compiling serde_derive v1.0.78
Compiling crossbeam-channel v0.2.5
Compiling scroll v0.9.0
Compiling goblin v0.0.17
Compiling ignore v0.4.4
Compiling git2 v0.7.5
Compiling failure v0.1.2
Compiling quick-xml v0.12.3
Compiling git2-curl v0.8.1
Compiling object v0.10.0
Compiling crates-io v0.17.0
Compiling coveralls-api v0.3.3
Compiling cargo v0.29.0
Compiling cargo-tarpaulin v0.6.7
error[E0432]: unresolved import nix::sys::ptrace
--> src/ptrace_control.rs:3:15
|
3 | use nix::sys::ptrace::*;
|               ^^^^^^ Could not find ptrace in sys
error[E0408]: variable PTRACE_EVENT_FORK is not bound in all patterns
--> src/statemachine.rs:356:37
|
356 |                 PTRACE_EVENT_FORK | PTRACE_EVENT_VFORK => {
|                 -----------------   ^^^^^^^^^^^^^^^^^^ pattern doesn't bind PTRACE_EVENT_FORK
|                 |
|                 variable not in all patterns
error[E0408]: variable PTRACE_EVENT_VFORK is not bound in all patterns
--> src/statemachine.rs:356:17
|
356 |                 PTRACE_EVENT_FORK | PTRACE_EVENT_VFORK => {
|                 ^^^^^^^^^^^^^^^^^   ------------------ variable not in all patterns
|                 |
|                 pattern doesn't bind PTRACE_EVENT_VFORK
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:13:28
|
13 |     let options: Options = Options::PTRACE_O_TRACESYSGOOD |
|                            ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:14:9
|
14 |         Options::PTRACE_O_TRACEEXEC | Options::PTRACE_O_TRACEEXIT |
|         ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:14:39
|
14 |         Options::PTRACE_O_TRACEEXEC | Options::PTRACE_O_TRACEEXIT |
|                                       ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:15:9
|
15 |         Options::PTRACE_O_TRACECLONE | Options::PTRACE_O_TRACEFORK |
|         ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:15:40
|
15 |         Options::PTRACE_O_TRACECLONE | Options::PTRACE_O_TRACEFORK |
|                                        ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Options
--> src/ptrace_control.rs:16:9
|
16 |         Options::PTRACE_O_TRACEVFORK;
|         ^^^^^^^ Use of undeclared type or module Options
error[E0433]: failed to resolve. Use of undeclared type or module Request
--> src/ptrace_control.rs:31:16
|
31 |         ptrace(Request::PTRACE_SINGLESTEP, pid, ptr::null_mut(), ptr::null_mut())
|                ^^^^^^^ Use of undeclared type or module Request
error[E0433]: failed to resolve. Use of undeclared type or module Request
--> src/ptrace_control.rs:38:16
|
38 |         ptrace(Request::PTRACE_PEEKDATA, pid, address as * mut c_void, ptr::null_mut())
|                ^^^^^^^ Use of undeclared type or module Request
error[E0433]: failed to resolve. Use of undeclared type or module Request
--> src/ptrace_control.rs:47:16
|
47 |         ptrace(Request::PTRACE_POKEDATA, pid, address as * mut c_void, data as * mut c_void)
|                ^^^^^^^ Use of undeclared type or module Request
error[E0433]: failed to resolve. Use of undeclared type or module Request
--> src/ptrace_control.rs:54:16
|
54 |         ptrace(Request::PTRACE_PEEKUSER, pid, RIP as * mut c_void, ptr::null_mut())
|                ^^^^^^^ Use of undeclared type or module Request
error[E0433]: failed to resolve. Use of undeclared type or module Request
--> src/ptrace_control.rs:61:16
|
61 |         ptrace(Request::PTRACE_POKEUSER, pid, RIP as * mut c_void, pc as * mut c_void)
|                ^^^^^^^ Use of undeclared type or module Request
error[E0412]: cannot find type Persona in this scope
--> src/personality.rs:12:26
|
12 | const ADDR_NO_RANDOMIZE: Persona = 0x004_0000;
|                          ^^^^^^^ not found in this scope
error[E0412]: cannot find type Persona in this scope
--> src/personality.rs:13:20
|
13 | const GET_PERSONA: Persona = 0xFFFF_FFFF;
|                    ^^^^^^^ not found in this scope
error[E0412]: cannot find type Persona in this scope
--> src/personality.rs:24:25
|
24 | fn personality(persona: Persona) -> Result<c_int> {
|                         ^^^^^^^ not found in this scope
error[E0412]: cannot find type Options in this scope
--> src/ptrace_control.rs:13:18
|
13 |     let options: Options = Options::PTRACE_O_TRACESYSGOOD |
|                  ^^^^^^^ did you mean Option?
error[E0425]: cannot find function setoptions in this scope
--> src/ptrace_control.rs:17:5
|
17 |     setoptions(pid, options)
|     ^^^^^^^^^^ did you mean options?
error[E0425]: cannot find function detach in this scope
--> src/ptrace_control.rs:21:5
|
21 |     detach(pid)
|     ^^^^^^ not found in this scope
error[E0425]: cannot find function cont in this scope
--> src/ptrace_control.rs:25:5
|
25 |     cont(pid, sig)
|     ^^^^ not found in this scope
error[E0425]: cannot find function ptrace in this scope
--> src/ptrace_control.rs:31:9
|
31 |         ptrace(Request::PTRACE_SINGLESTEP, pid, ptr::null_mut(), ptr::null_mut())
|         ^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
|
1  | use nix::libc::ptrace;
|
error[E0425]: cannot find function ptrace in this scope
--> src/ptrace_control.rs:38:9
|
38 |         ptrace(Request::PTRACE_PEEKDATA, pid, address as * mut c_void, ptr::null_mut())
|         ^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
|
1  | use nix::libc::ptrace;
|
error[E0425]: cannot find function ptrace in this scope
--> src/ptrace_control.rs:47:9
|
47 |         ptrace(Request::PTRACE_POKEDATA, pid, address as * mut c_void, data as * mut c_void)
|         ^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
|
1  | use nix::libc::ptrace;
|
error[E0425]: cannot find function ptrace in this scope
--> src/ptrace_control.rs:54:9
|
54 |         ptrace(Request::PTRACE_PEEKUSER, pid, RIP as * mut c_void, ptr::null_mut())
|         ^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
|
1  | use nix::libc::ptrace;
|
error[E0425]: cannot find function ptrace in this scope
--> src/ptrace_control.rs:61:9
|
61 |         ptrace(Request::PTRACE_POKEUSER, pid, RIP as * mut c_void, pc as * mut c_void)
|         ^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
|
1  | use nix::libc::ptrace;
|
error[E0425]: cannot find function traceme in this scope
--> src/ptrace_control.rs:66:5
|
66 |     traceme()
|     ^^^^^^^ not found in this scope
error[E0425]: cannot find function getevent in this scope
--> src/ptrace_control.rs:70:5
|
70 |     getevent(pid)
|     ^^^^^^^^ not found in this scope
error[E0599]: no associated item named __WALL found for type nix::sys::wait::WaitPidFlag in the current scope
--> src/statemachine.rs:231:75
|
231 |         let wait = waitpid(Pid::from_raw(-1), Some(WaitPidFlag::WNOHANG | WaitPidFlag::__WALL));
|                                                                           ^^^^^^^^^^^^^^^^^^^ associated item not found in nix::sys::wait::WaitPidFlag
error[E0599]: no variant named PtraceEvent found for type nix::sys::wait::WaitStatus in the current scope
--> src/statemachine.rs:251:13
|
251 |             WaitStatus::PtraceEvent(c,s,e) => {
|             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ variant not found in nix::sys::wait::WaitStatus
error: aborting due to 30 previous errors
Some errors occurred: E0408, E0412, E0425, E0432, E0433, E0599.
For more information about an error, try rustc --explain E0408.
error: failed to compile cargo-tarpaulin v0.6.7, intermediate artifacts can be found at /var/folders/26/ghqp1zl50yq3bp47zljpksk80000gn/T/cargo-install5pqpq9
Caused by:
Could not compile cargo-tarpaulin.
To learn more, run the command again with --verbose.

So tarpaulin currently only supports linux, if anything else works it's more luck that intent. OSX compared to linux doesn't have a complete ptrace implementation so the nix crate doesn't expose the ptrace bindings.
If anyone was interested in adding OSX support they'd need to either replace ptrace with appropriate mac system calls or contribute to nix to add the parts of ptrace mac exports and for the rest of it add the appropriate system calls.
I don't have any Macs so while I'm open to more OS support this is something I'd appreciate help on.

Do you know of any tools that can be used on OSX for coverage reports?,
Also, I have a mac and can help test whatever you guys code, but I'm not smart enough to do the syscalls on OSX, I need to know more about that, first.
I can also provide ssh access I guess, via Hamachi, if somebody wants to   to connect to my machine and work remotely on it, but I assume that wouldn't work out, since the people who are experts on osx syscalls and stuff like that probably already have and love a mac.
would a donation to the project help?

You might be able to get it working with docker on mac - though I'm not really that familiar with docker so maybe not... A good start if you wanted to help for the ptrace calls on mac. It should just be a case of looking at the ptrace docs for OSX finding what's supported and changing the cfgs in https://github.com/nix-rust/nix/ to match. Once that's done and merged in it we can see what fails to compile and go from there.
As for donations I hadn't considered project donations before, though I'm probably going to be rather busy with my day job till the end of the year so that probably won't change anything in reality.

Oh realised I missed your first question on tools that can be used for coverage, there is https://github.com/SimonKagstrom/kcov which works on linux, freebsd and OSX.
I've just opened a PR on rust-nix/nix https://github.com/nix-rust/nix/pull/949 for ptrace support in OSX and BSD. So once that's done, released and I update tarpaulin for the new nix version tarpaulin might work on OSX or there might be other things that need adapting. I'll ping you when there' something to test though!

@dataf3l could you clone https://github.com/xd009642/nix/ checkout the branch issue-947 and let me know the output of the following tests sys::test_ptrace::test_ptrace sys::test_ptrace::test_ptrace_cont? This is part of adding OSX support to some of my dependencies and the travis runs are failing so we're trying to figure out if it's a travis qemu issue or an actual apple issue

@xd009642 Unfortunately, it looks like it some of the tests didn't pass...
localhost:~ b$ cd work/
localhost:work b$ git clone https://github.com/xd009642/nix.git -b issue-947
Cloning into 'nix'...
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 7722 (delta 4), reused 6 (delta 3), pack-reused 7706
Receiving objects: 100% (7722/7722), 2.02 MiB | 990.00 KiB/s, done.
Resolving deltas: 100% (5583/5583), done.
localhost:work b$ cd nix/
localhost:nix b$ ls
bors.toml  build.rs  Cargo.toml  CHANGELOG.md  ci  CONTRIBUTING.md CONVENTIONS.md  Cross.toml  LICENSE  README.md  RELEASE_PROCEDURE.md  src  test
localhost:nix b$ git status .
On branch issue-947
Your branch is up to date with 'origin/issue-947'.
nothing to commit, working tree clean
localhost:nix b$ cargo build
Updating registry https://github.com/rust-lang/crates.io-index
Updating git repository https://github.com/rust-lang/libc
Compiling libc v0.2.43 (https://github.com/rust-lang/libc#41944d5c)
Compiling nix v0.11.0 (file:///Users/b/work/nix)
Compiling cfg-if v0.1.5
Compiling void v1.0.2
Compiling bitflags v1.0.4
Finished dev [unoptimized + debuginfo] target(s) in 23.98s
localhost:nix b$ cargo test
Downloading rand_core v0.2.2
Downloading rand_core v0.3.0
Compiling rand_core v0.3.0
Compiling version_check v0.1.5
Compiling libc v0.2.43
Compiling remove_dir_all v0.5.1
Compiling byteorder v1.2.6
Compiling rand_core v0.2.2
Compiling lazy_static v1.1.0
Compiling iovec v0.1.2
Compiling rand v0.5.5
Compiling bytes v0.4.10
Compiling tempfile v3.0.4
Compiling nix v0.11.0 (file:///Users/b/work/nix)
warning: unused macro definition
--> test/test_mount.rs:209:1
|
209 | / macro_rules! run_tests {
210 | |     ( $($test_fn:ident),* ) => {{
211 | |         println!();
212 | |
...   |
220 | |     }}
221 | | }
| |_^
|
= note: #[warn(unused_macros)] on by default
warning: unused macro definition
--> test/test.rs:12:1
|
12 | / macro_rules! skip_if_not_root {
13 | |     ($name:expr) => {
14 | |         use nix::unistd::Uid;
15 | |         use std;
...  |
24 | |     };
25 | | }
| |_^
|
= note: #[warn(unused_macros)] on by default
warning: unused import: std::mem
--> test/sys/test_ptrace.rs:8:5
|
8 | use std::mem;
|     ^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: nix::sys::signal::SigSet
--> test/test_poll.rs:2:5
|
2 | use nix::sys::signal::SigSet;
|     ^^^^^^^^^^^^^^^^^^^^^^^^
warning: unused imports: TimeSpec, TimeValLike
--> test/test_poll.rs:3:22
|
3 | use nix::sys::time::{TimeSpec, TimeValLike};
|                      ^^^^^^^^  ^^^^^^^^^^^
warning: use of deprecated item 'nix::unistd::pipe2': pipe2(2) is not actually atomic on these platforms.  Use pipe(2) and fcntl(2) instead
--> test/test_unistd.rs:386:22
|
386 |     let (fd0, fd1) = pipe2(OFlag::O_CLOEXEC).unwrap();
|                      ^^^^^
|
= note: #[warn(deprecated)] on by default
warning: unused std::result::Result which must be used
--> test/test_stat.rs:177:5
|
177 |     utimes(&fullpath, &TimeVal::seconds(9990), &TimeVal::seconds(5550));
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this Result may be an Err variant, which should be handled
Finished dev [unoptimized + debuginfo] target(s) in 13.20s
 Running target/debug/deps/nix-f5796617f4709c01

running 35 tests
test sys::event::test_struct_kevent ... ok
test ifaddrs::tests::test_getifaddrs ... ok
test sys::select::tests::fdset_clear ... ok
test sys::select::tests::fdset_insert ... ok
test sys::select::tests::fdset_remove ... ok
test sys::select::tests::test_select ... ok
test sys::select::tests::test_select_nfds ... ok
test sys::select::tests::test_select_nfds2 ... ok
test sys::signal::tests::test_clear ... ok
test sys::select::tests::fdset_highest ... ok
test sys::signal::tests::test_contains ... ok
test sys::signal::tests::test_extend ... ok
test sys::signal::tests::test_from_str_invalid_value ... ok
test sys::signal::tests::test_sigaction ... ok
test sys::signal::tests::test_thread_signal_block ... ok
test sys::signal::tests::test_thread_signal_get_mask ... ok
test sys::signal::tests::test_from_str_round_trips ... ok
test sys::signal::tests::test_thread_signal_set_mask ... ok
test sys::signal::tests::test_thread_signal_swap ... ok
test sys::signal::tests::test_thread_signal_unblock ... ok
test sys::socket::addr::tests::test_macos_loopback_datalink_addr ... ok
test sys::socket::addr::tests::test_macos_tap_datalink_addr ... ok
test sys::socket::sockopt::test::is_socket_type_dgram ... ok
test sys::statvfs::test::fstatvfs_call ... ok
test sys::statvfs::test::statvfs_call ... ok
test sys::socket::sockopt::test::is_socket_type_unix ... ok
test sys::time::test::test_timespec ... ok
test sys::time::test::test_timespec_neg ... ok
test sys::time::test::test_timespec_fmt ... ok
test sys::time::test::test_timespec_ord ... ok
test sys::time::test::test_timeval ... ok
test sys::time::test::test_timeval_neg ... ok
test sys::time::test::test_timeval_fmt ... ok
test sys::time::test::test_timeval_ord ... ok
test sys::utsname::test::test_uname_darwin ... ok
test result: ok. 35 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
 Running target/debug/deps/test-fc2b5d0af9911a3b

running 98 tests
test sys::test_aio::test_accessors ... ok
test sys::test_aio::test_aio_suspend ... ok
test sys::test_aio::test_read_bytes_mut_small ... ok
test sys::test_aio::test_aio_cancel_all ... ok
test sys::test_aio::test_fsync_error ... ok
test sys::test_aio::test_read_error ... ok
test sys::test_aio::test_read_immutable_buffer ... ok
test sys::test_aio::test_write_error ... ok
test sys::test_aio::test_fsync ... ok
test sys::test_aio::test_cancel ... ok
test sys::test_ioctl::bsd::test_op_none ... ok
test sys::test_ioctl::bsd::test_op_read ... ok
test sys::test_ioctl::bsd::test_op_read_64 ... ok
test sys::test_ioctl::bsd::test_op_read_write ... ok
test sys::test_ioctl::bsd::test_op_read_write_64 ... ok
test sys::test_ioctl::bsd::test_op_write ... ok
test sys::test_ioctl::bsd::test_op_write_64 ... ok
test sys::test_pthread::test_pthread_self ... ok
test sys::test_aio::test_read_into_mut_slice ... ok
test sys::test_aio::test_read ... ok
test sys::test_ptrace::test_ptrace ... FAILED
test sys::test_aio::test_write_bytes ... ok
test sys::test_aio::test_read_into_pointer ... ok
test sys::test_aio::test_write_from_pointer ... ok
test sys::test_aio::test_write ... ok
test sys::test_select::test_pselect_nfds2 ... ok
test sys::test_ptrace::test_ptrace_cont ... FAILED
test sys::test_signal::test_kill_none ... ok
test sys::test_signal::test_old_sigaction_flags ... ok
test sys::test_signal::test_sigprocmask_noop ... ok
test sys::test_socket::test_inetv4_addr_to_sock_addr ... ok
test sys::test_socket::test_inetv6_addr_to_sock_addr ... ok
test sys::test_socket::test_getsockname ... ok
test sys::test_socket::test_path_to_sock_addr ... ok
test sys::test_socket::test_scm_rights ... ok
test sys::test_socket::test_socketpair ... ok
test sys::test_socket::test_scm_rights_single_cmsg_multiple_fds ... ok
test sys::test_socket::test_sendmsg_empty_cmsgs ... ok
test sys::test_socket::test_syscontrol ... ok
test sys::test_termios::test_cfmakeraw ... ok
test sys::test_termios::test_tcgetattr_ebadf ... ok
test sys::test_termios::test_local_flags ... ok
test sys::test_sockopt::test_so_buf ... ok
test sys::test_termios::test_output_flags ... ok
test sys::test_socket::test_unixdomain ... ok
test sys::test_aio::test_write_sigev_signal ... ok
test sys::test_select::test_pselect ... ok
test sys::test_signal::test_sigprocmask ... ok
test sys::test_termios::test_tcgetattr_pty ... ok
test sys::test_termios::test_tcgetattr_enotty ... ok
test sys::test_uio::test_pwrite ... ok
test sys::test_wait::test_waitstatus_from_raw ... ok
test sys::test_uio::test_readv ... ok
test test_dir::ebadf ... ok
test sys::test_wait::test_wait_exit ... ok
test sys::test_uio::test_pread ... ok
test sys::test_wait::test_wait_signal ... ok
test sys::test_uio::test_writev ... ok
test sys::test_wait::test_waitstatus_pid ... ok
test test_dir::rewind ... ok
test test_net::test_if_nametoindex ... ok
test test_poll::test_poll_debug ... ok
test test_dir::read ... ok
test test_fcntl::test_openat ... ok
test test_pty::test_open_ptty_pair ... ok
test test_pty::test_openpty ... ok
test test_fcntl::test_readlink ... ok
test test_pty::test_openpty_with_termios ... ok
test test_pty::test_explicit_close ... ok
test test_sendfile::test_sendfile_darwin ... ok
test test_stat::test_fchmod ... ok
test test_stat::test_fchmodat ... ok
test test_stat::test_fstatat ... ok
test test_stat::test_futimens ... ok
test test_stat::test_stat_and_fstat ... ok
test test_stat::test_utimes ... ok
test test_stat::test_utimensat ... ok
test test_stat::test_stat_fstat_lstat ... ok
test test_unistd::test_fchdir ... ok
test test_unistd::test_fpathconf_limited ... ok
test test_unistd::test_getpid ... ok
test test_unistd::test_getsid ... ok
test test_unistd::test_lseek ... ok
test test_unistd::test_mkfifo_directory ... ok
test test_unistd::test_mkfifo ... ok
test test_unistd::test_mkstemp_directory ... ok
test test_unistd::test_mkstemp ... ok
test test_unistd::test_pathconf_limited ... ok
test test_unistd::test_pipe ... ok
test test_unistd::test_pipe2 ... ok
test test_unistd::test_sysconf_limited ... ok
test test_unistd::test_getcwd ... ok
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
test test_unistd::test_execve ... ok
test test_unistd::test_fork_and_waitpid ... ok
test test_unistd::test_wait ... ok
test test_poll::test_poll ... ok
test test_unistd::test_alarm ... ok
test test_unistd::test_canceling_alarm ... ok
failures:
---- sys::test_ptrace::test_ptrace stdout ----
thread 'sys::test_ptrace::test_ptrace' panicked at 'assertion failed: err == Error::Sys(Errno::EPERM) || err == Error::Sys(Errno::ENOSYS)', test/sys/test_ptrace.rs:15:5
---- sys::test_ptrace::test_ptrace_cont stdout ----
thread 'sys::test_ptrace::test_ptrace_cont' panicked at 'called Result::unwrap() on an Err value: Sys(ENOTSUP)', libcore/result.rs:983:5
failures:
sys::test_ptrace::test_ptrace
sys::test_ptrace::test_ptrace_cont
test result: FAILED. 96 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out
error: test failed, to rerun pass '--test test'
localhost:nix b$

Okay in src/sys/ptrace/bsd.rs in the function attach could you replace Request::PT_ATTACH with Request::PT_ATTACHEXC?

Still no dice:
localhost:nix b$ vi src/sys/ptrace/bsd.rs
localhost:nix b$ cargo clean
localhost:nix b$ cargo build
Compiling libc v0.2.43 (https://github.com/rust-lang/libc#41944d5c)
Compiling nix v0.11.0 (file:///Users/b/work/nix)
Compiling bitflags v1.0.4
Compiling cfg-if v0.1.5
Compiling void v1.0.2
Finished dev [unoptimized + debuginfo] target(s) in 8.92s
localhost:nix b$
localhost:nix b$
localhost:nix b$ brew install sphinx-doc
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core and homebrew/cask).
==> Updated Formulae
aws-elasticbeanstalk              futhark                           jhipster                          php-code-sniffer                  swiftgen                          terragrunt
==> Downloading https://homebrew.bintray.com/bottles/sphinx-doc-1.8.1.high_sierra.bottle.tar.gz
######################################################################## 100.0%
==> Pouring sphinx-doc-1.8.1.high_sierra.bottle.tar.gz
==> Caveats
sphinx-doc is keg-only, which means it was not symlinked into /usr/local,
because this formula is mainly used internally by other formulae.
Users are advised to use pip to install sphinx-doc.
If you need to have sphinx-doc first in your PATH run:
echo 'export PATH="/usr/local/opt/sphinx-doc/bin:$PATH"' >> ~/.bash_profile
==> Summary
🍺  /usr/local/Cellar/sphinx-doc/1.8.1: 2,695 files, 46.3MB
localhost:nix b$ cargo test
Compiling version_check v0.1.5
Compiling rand_core v0.3.0
Compiling libc v0.2.43
Compiling byteorder v1.2.6
Compiling remove_dir_all v0.5.1
Compiling rand_core v0.2.2
Compiling lazy_static v1.1.0
Compiling rand v0.5.5
Compiling iovec v0.1.2
Compiling bytes v0.4.10
Compiling tempfile v3.0.4
Compiling nix v0.11.0 (file:///Users/b/work/nix)
warning: unused macro definition
--> test/test_mount.rs:209:1
|
209 | / macro_rules! run_tests {
210 | |     ( $($test_fn:ident),* ) => {{
211 | |         println!();
212 | |
...   |
220 | |     }}
221 | | }
| |_^
|
= note: #[warn(unused_macros)] on by default
warning: unused macro definition
--> test/test.rs:12:1
|
12 | / macro_rules! skip_if_not_root {
13 | |     ($name:expr) => {
14 | |         use nix::unistd::Uid;
15 | |         use std;
...  |
24 | |     };
25 | | }
| |_^
|
= note: #[warn(unused_macros)] on by default
warning: unused import: std::mem
--> test/sys/test_ptrace.rs:8:5
|
8 | use std::mem;
|     ^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: nix::sys::signal::SigSet
--> test/test_poll.rs:2:5
|
2 | use nix::sys::signal::SigSet;
|     ^^^^^^^^^^^^^^^^^^^^^^^^
warning: unused imports: TimeSpec, TimeValLike
--> test/test_poll.rs:3:22
|
3 | use nix::sys::time::{TimeSpec, TimeValLike};
|                      ^^^^^^^^  ^^^^^^^^^^^
warning: use of deprecated item 'nix::unistd::pipe2': pipe2(2) is not actually atomic on these platforms.  Use pipe(2) and fcntl(2) instead
--> test/test_unistd.rs:386:22
|
386 |     let (fd0, fd1) = pipe2(OFlag::O_CLOEXEC).unwrap();
|                      ^^^^^
|
= note: #[warn(deprecated)] on by default
warning: unused std::result::Result which must be used
--> test/test_stat.rs:177:5
|
177 |     utimes(&fullpath, &TimeVal::seconds(9990), &TimeVal::seconds(5550));
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this Result may be an Err variant, which should be handled
Finished dev [unoptimized + debuginfo] target(s) in 10.49s
 Running target/debug/deps/nix-f5796617f4709c01

running 35 tests
test sys::event::test_struct_kevent ... ok
test sys::select::tests::fdset_insert ... ok
test sys::select::tests::fdset_clear ... ok
test sys::select::tests::test_select ... ok
test sys::select::tests::test_select_nfds2 ... ok
test ifaddrs::tests::test_getifaddrs ... ok
test sys::select::tests::test_select_nfds ... ok
test sys::select::tests::fdset_remove ... ok
test sys::signal::tests::test_clear ... ok
test sys::signal::tests::test_contains ... ok
test sys::signal::tests::test_extend ... ok
test sys::signal::tests::test_from_str_invalid_value ... ok
test sys::select::tests::fdset_highest ... ok
test sys::signal::tests::test_sigaction ... ok
test sys::signal::tests::test_thread_signal_block ... ok
test sys::signal::tests::test_thread_signal_get_mask ... ok
test sys::signal::tests::test_from_str_round_trips ... ok
test sys::signal::tests::test_thread_signal_set_mask ... ok
test sys::signal::tests::test_thread_signal_swap ... ok
test sys::signal::tests::test_thread_signal_unblock ... ok
test sys::socket::addr::tests::test_macos_loopback_datalink_addr ... ok
test sys::socket::addr::tests::test_macos_tap_datalink_addr ... ok
test sys::socket::sockopt::test::is_socket_type_dgram ... ok
test sys::statvfs::test::fstatvfs_call ... ok
test sys::statvfs::test::statvfs_call ... ok
test sys::time::test::test_timespec ... ok
test sys::time::test::test_timespec_neg ... ok
test sys::time::test::test_timespec_ord ... ok
test sys::time::test::test_timespec_fmt ... ok
test sys::socket::sockopt::test::is_socket_type_unix ... ok
test sys::time::test::test_timeval ... ok
test sys::time::test::test_timeval_fmt ... ok
test sys::time::test::test_timeval_neg ... ok
test sys::time::test::test_timeval_ord ... ok
test sys::utsname::test::test_uname_darwin ... ok
test result: ok. 35 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
 Running target/debug/deps/test-fc2b5d0af9911a3b

running 98 tests
test sys::test_aio::test_accessors ... ok
test sys::test_aio::test_aio_suspend ... ok
test sys::test_aio::test_fsync_error ... ok
test sys::test_aio::test_read_error ... ok
test sys::test_aio::test_read_immutable_buffer ... ok
test sys::test_aio::test_cancel ... ok
test sys::test_aio::test_aio_cancel_all ... ok
test sys::test_aio::test_read_bytes_mut_small ... ok
test sys::test_aio::test_read ... ok
test sys::test_aio::test_fsync ... ok
test sys::test_aio::test_write_error ... ok
test sys::test_ioctl::bsd::test_op_none ... ok
test sys::test_ioctl::bsd::test_op_read ... ok
test sys::test_aio::test_read_into_mut_slice ... ok
test sys::test_aio::test_read_into_pointer ... ok
test sys::test_ioctl::bsd::test_op_read_64 ... ok
test sys::test_ioctl::bsd::test_op_read_write ... ok
test sys::test_ioctl::bsd::test_op_read_write_64 ... ok
test sys::test_ioctl::bsd::test_op_write ... ok
test sys::test_aio::test_write ... ok
test sys::test_ioctl::bsd::test_op_write_64 ... ok
test sys::test_pthread::test_pthread_self ... ok
test sys::test_ptrace::test_ptrace ... FAILED
test sys::test_signal::test_old_sigaction_flags ... ok
test sys::test_select::test_pselect_nfds2 ... ok
test sys::test_signal::test_kill_none ... ok
test sys::test_signal::test_sigprocmask_noop ... ok
test sys::test_ptrace::test_ptrace_cont ... FAILED
test sys::test_socket::test_inetv4_addr_to_sock_addr ... ok
test sys::test_socket::test_inetv6_addr_to_sock_addr ... ok
test sys::test_socket::test_path_to_sock_addr ... ok
test sys::test_socket::test_scm_rights ... ok
test sys::test_socket::test_scm_rights_single_cmsg_multiple_fds ... ok
test sys::test_socket::test_sendmsg_empty_cmsgs ... ok
test sys::test_socket::test_socketpair ... ok
test sys::test_socket::test_syscontrol ... ok
test sys::test_socket::test_getsockname ... ok
test sys::test_termios::test_cfmakeraw ... ok
test sys::test_sockopt::test_so_buf ... ok
test sys::test_termios::test_local_flags ... ok
test sys::test_termios::test_tcgetattr_ebadf ... ok
test sys::test_socket::test_unixdomain ... ok
test sys::test_termios::test_output_flags ... ok
test sys::test_termios::test_tcgetattr_pty ... ok
test sys::test_termios::test_tcgetattr_enotty ... ok
test sys::test_uio::test_pwrite ... ok
test sys::test_uio::test_pread ... ok
test sys::test_uio::test_readv ... ok
test sys::test_wait::test_wait_exit ... ok
test sys::test_wait::test_waitstatus_from_raw ... ok
test sys::test_wait::test_wait_signal ... ok
test sys::test_uio::test_writev ... ok
test test_dir::ebadf ... ok
test sys::test_aio::test_write_bytes ... ok
test sys::test_aio::test_write_from_pointer ... ok
test sys::test_wait::test_waitstatus_pid ... ok
test test_net::test_if_nametoindex ... ok
test sys::test_aio::test_write_sigev_signal ... ok
test sys::test_select::test_pselect ... ok
test test_dir::rewind ... ok
test test_fcntl::test_openat ... ok
test sys::test_signal::test_sigprocmask ... ok
test test_poll::test_poll_debug ... ok
test test_pty::test_open_ptty_pair ... ok
test test_fcntl::test_readlink ... ok
test test_pty::test_openpty ... ok
test test_dir::read ... ok
test test_pty::test_openpty_with_termios ... ok
test test_pty::test_explicit_close ... ok
test test_sendfile::test_sendfile_darwin ... ok
test test_stat::test_fchmodat ... ok
test test_stat::test_fstatat ... ok
test test_stat::test_fchmod ... ok
test test_stat::test_stat_and_fstat ... ok
test test_stat::test_futimens ... ok
test test_stat::test_stat_fstat_lstat ... ok
test test_stat::test_utimes ... ok
test test_stat::test_utimensat ... ok
test test_unistd::test_fchdir ... ok
test test_unistd::test_getpid ... ok
test test_unistd::test_fpathconf_limited ... ok
test test_unistd::test_getsid ... ok
test test_unistd::test_lseek ... ok
test test_unistd::test_mkfifo_directory ... ok
test test_unistd::test_mkfifo ... ok
test test_unistd::test_mkstemp_directory ... ok
test test_unistd::test_mkstemp ... ok
test test_unistd::test_pathconf_limited ... ok
test test_unistd::test_pipe ... ok
test test_unistd::test_pipe2 ... ok
test test_unistd::test_sysconf_limited ... ok
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
test test_unistd::test_getcwd ... ok
test test_unistd::test_execve ... ok
test test_unistd::test_fork_and_waitpid ... ok
test test_unistd::test_wait ... ok
test test_poll::test_poll ... ok
test test_unistd::test_alarm ... ok
test test_unistd::test_canceling_alarm ... ok
failures:
---- sys::test_ptrace::test_ptrace stdout ----
thread 'sys::test_ptrace::test_ptrace' panicked at 'assertion failed: err == Error::Sys(Errno::EPERM) || err == Error::Sys(Errno::ENOSYS)', test/sys/test_ptrace.rs:15:5
---- sys::test_ptrace::test_ptrace_cont stdout ----
thread 'sys::test_ptrace::test_ptrace_cont' panicked at 'called Result::unwrap() on an Err value: Sys(ENOTSUP)', libcore/result.rs:983:5
failures:
sys::test_ptrace::test_ptrace
sys::test_ptrace::test_ptrace_cont
test result: FAILED. 96 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out
error: test failed, to rerun pass '--test test'
localhost:nix b$ git diff
diff --git a/src/sys/ptrace/bsd.rs b/src/sys/ptrace/bsd.rs
index ee9b6eb..45c8fa2 100644
--- a/src/sys/ptrace/bsd.rs
+++ b/src/sys/ptrace/bsd.rs
@@ -77,7 +77,7 @@ pub fn traceme() -> Result<()> {
///
/// Attaches to the process specified in pid, making it a tracee of the calling process.
pub fn attach(pid: Pid) -> Result<()> {

unsafe { ptrace_other(Request::PT_ATTACH, pid, ptr::null_mut(), 0).map(|_| ()) }

unsafe { ptrace_other(Request::PT_ATTACHEXC, pid, ptr::null_mut(), 0).map(|_| ()) }
}

/// Detaches the current running process, as with ptrace(PT_DETACH, ...)
localhost:nix b$

I guess I could setup a cron job to clone the repo and run the tests on this machine, like daily, if that is something you guys would find useful.

No that's alright I got it more working some point last night and affirmed that travis is fine for testing. Thanks for offering though! Once this is in and released I'll be able to apply some changes to tarpaulin and may ask you to test them

Just put them here I guess
On Tue, Oct 9, 2018 at 12:09 PM xd009642<EMAIL_ADDRESS>wrote:

No that's alright I got it more working some point last night and affirmed
that travis is fine for testing. Thanks for offering though! Once this is
in and released I'll be able to apply some changes to tarpaulin and may ask
you to test them
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xd009642/tarpaulin/issues/152#issuecomment-428273567,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADXWcNFIBv_nMxe6Dczdk9qo1oQU3NROks5ujNhJgaJpZM4XGjL-
.

There's now a tracking branch for this. https://github.com/xd009642/tarpaulin/tree/osx-support I don't yet expect it to work but the ptrace compiler errors should be gone (in theory)

I like it because it makes my comment look more professional.
Screw the past, bring on the future! :)

So as an update since I've been working on this issue this week. I appear to have ported over most of the ptrace stuff launch a test add the breakpoints to instrument it but after initialising the test it times out.
This makes me think the trace isn't being passed down to the child threads and rustc_test does spawn a thread for each test so it can kill it if it runs too long. Hopefully, once I solve this issue I might see some coverage results come out (if I'm really lucky and everything else works to some degree).

@dataf3l it would be helpful if you could take the latest build off the osx-support branch and create the default lib project cargo new osxtest --lib run tarpaulin with verbose and then use ddbug on the test binary it attempts to process. After Launching test in the tarpaulin verbose printout it prints the path to the test binary.

@xd009642  I've just wandered in from "This Week in Rust" and have zero context for this issue, but  I gave it a go:
$ ddbug osxtest-21111c0e5489441f
ERROR 2018-12-13T00:24:24Z: ddbug: osxtest-21111c0e5489441f: unable to locate debug file: dSYM not found

osxtest-21111c0e5489441f.dSYM exists in that folder for whatever it's worth.

Oh that's actually super useful! Could you run ddbug on the dsym file?

Awesome that's what I expected to see! I've been trying to debug and develop this via travis and apples online docs which has been a bit of a mare. I've pushed a change to the osx-support branch and if results come out we should have the first beta of OSX support.
If more work is needed (I have a feeling there is more) and you're interested in working on the tarpaulin code I've got a developer wiki that explains some of how the project works https://github.com/xd009642/tarpaulin/wiki/Developers if there are any missing parts or issues I do also have a tracking issue for the wiki since it's relatively new :+1:

That overview's given me the gist of how this is supposed to work 👍. At the minute osx-support fails at the mmap call because the path it's provided is a bundle (folder). With the change below to test_loader::open_symbols_file the mmap call succeeds:
 #[cfg(target_os = "macos")]
 fn open_symbols_file(test: &Path) -> io::Result<File> {
-    let d_sym = test.with_extension("dSYM");
+    let mut d_sym = test.with_extension("dSYM");
+    d_sym.push("Contents/Resources/DWARF");
+    d_sym.push(test.file_stem().unwrap());
     println!("Test file {}", d_sym.display());
     File::open(&d_sym)
 }

Which leads to:
[...]
Processing compilation units
Getting the entry points
Processed all compilation units
trace children -1
Failed to trace child threads
Number of traces 6
Finished instrumenting code

I guess this could be a privilege issue (codesigning/entitlements) or some macOS API deviation. I've got to shelf this for the moment but I'll try and circle back to this in the next few days.

So the mach-o loading side of thing looks like it's working with that change as it's found the traces from the DWARF tables. This is in the update loop actually attempting to trace. I think this is a case of src/process_handling/bsd.rs the trace_children function being incorrect as ptrace isn't tracing spawned threads.
Apple doesn't expose the constants but provides more ptrace functionality than they advertise so I hard coded it myself to see if it would work. So looks like back to the apple ptrace drawing board for that

@nathanwhit sorry for the random tag but I saw you tried some stuff with OSX support in a fork, did you make any progress or have any insights? I'm going to be borrowing a mac from a friend this week so might be able to make some real progress once I can run the code locally

@xd009642 No worries! I did make some progress. The main issue is that (as you noticed) ptrace on macOS doesn't have the right capabilities so you have to work through other means. More specifically you have to go through the kernel's mach interface. I have two branches with my progress, I'll go through the progress and problems with each.
My first attempt was the macos branch, which implements most of the functionality required in the ptrace_control and process_handling modules. If you run one of simple coverage tests it usually passes, but not always, which leads into the problem. I didn't modify the state machine much, and so it performs most actions using the pid to identify threads. In the mach interface, however, you don't operate on things by pid, instead you work on mach tasks and mach threads which are a different abstraction. For instance, to modify the instruction pointer or write to the thread's memory as in the write_to_address fn you operate on a mach thread, not a Unix/POSIX thread. There's a mapping from pid to the mach task responsible for it, which then contains info about the mach threads in the task. However, there's no mapping from pid to mach thread. So currently functions like write_to_address take a pid, lookup the mach task associated with it, then have no way of knowing which mach thread the pid refers to, so it just chooses the first thread it finds (which is wrong a good portion of the time).
In essence the problem is that the state machine and actual operations operate on different abstractions and there's not a clean way to map between them (AFAIK).
My second attempt is in the macos-v2 branch. In this I wrote up wrappers/abstractions for the relevant mach structures, and figured out how to receive the signals we would usually get from waitpid in a mach message form. This way the state machine could operate on the mach structures instead of on the Unix/POSIX architecture. The basic structure is there, and the mach messages are properly received. The problem is I didn't update the state machine to use the new structures, and was becoming frustrated with working on the mach end of things (as it lacks documentation badly and is fairly opaque) which was demotivating. As it stands then, this branch doesn't pass any tests and doesn't run properly due to not adjusting the state machines. I think this branch has more potential though, as it seems like a more "correct" approach.
I've pushed my latest changes to both branches, you're welcome to continue where I left off.

One important note is that for any of it to work you have to run with sudo (i.e. sudo cargo test), as macOS requires elevated privileges for the useful mach interfaces.
Also, if you want to work/mess around with just the mach side of things I have a repo with some basic tests I used for debugging/developing the mach interface. Just build a binary with the name a.out and sudo cargo run. As it is, it just prints out the signals received and some debugging info about the mach task/threads. It may or may not be useful for you, but it was definitely helpful for me to reason about the mach side without worrying too much about tarpaulin's specific structure.
Feel free to ping me if you have any questions/thoughts. I'm still open to working on this, just right now I don't have enough bandwidth to continue.

I am happy to see some progress on this. I would love to help, but I am swamped with a lot of other projects.

@nathanwhit could you explain a bit what the build.rs is doing in the macos-v2 branch?

@xd009642 Ah yeah sure, forgot about that. The following is what I've gathered from a few sources: the lldb source code for macOS, this ebook and Apple's barebones explanations.
The mach messaging/RPC interface (headers, etc.) is actually generated by a program on the system (called mig) and then linked against. In essence, some details of the interface to the mach messaging server/client is dependent on the kernel version and some other system-specific parameters (I believe, it's not well explained) and so it has to be generated on the machine which the mach messaging server/client will run. The build script just calls the mig program to generate the interface, then compiles the generated code in order to link the rust code against it.

Awesome, and I've never looked at the lldb code only gdb but that seemed extra opaque with mac stuff. I'll start looking to lldb for reference when gdb is too much :sweat_smile:

So few issues so far, I'm working with Darwin and the Mac system headers moved but I've updated the build script. Now my current roadblock is task_for_pid always returns with a kernel error even when I run in sudo so I'm wondering if I need to sign the binary a la https://attilathedud.me/mac-os-x-el-capitan-10-11-and-task_for_pid/ so just trying to figure out how to sign the application.

https://timnash.co.uk/getting-gdb-to-semi-reliably-work-on-mojave-macos/
wish it helps!

just found this https://github.com/kattrali/rust-mac-app-examples/tree/master/3-packaging-a-mac-app which I think shows me how to handle the permissions for an app :tada: I'll have another play with this at the weekend

Hi! Do you have any updates of plan for this? I've been using Docker to run Tarpaulin, but it takes much longer and forces me to have Docker up and running.
Having Tarpaulin working natively on Mac would be awesome.

So mac has deviated from windows and I get a "permission denied" error on doc test coverage using the llvm coverage on CI. If anyone has a mac I'd appreciate some help :pray:

I think it's working fine for me! Here's the output from cargo tarpaulin --engine llvm --debug run on the crate heapless:
heapless-tarpaulin-run.log
I'm on an M1 MacBook Pro

Great to hear it works on heapless :tada:. It should work on majority of crates given number of CI tests passing, there are some failures still on Mac CI which lives in #549 . Notable ones are doc-test coverage and following spawned programs (though that's not working on linux so I can fix that).

In MacOS 12.5 in a MacBook with M1, running it in a private project with --engine llvm I got this panic (last commit in the branch:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', ~/.cargo/git/checkouts/llvm-profparser-af6f90331795d017/9d23f33/src/instrumentation_profile/types.rs:112:32
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:48:5
   3: llvm_profparser::coverage::coverage_mapping::CoverageMapping::new
   4: <cargo_tarpaulin::statemachine::instrumented::LlvmInstrumentedData as cargo_tarpaulin::statemachine::StateData>::wait
   5: cargo_tarpaulin::statemachine::TestState::step
   6: cargo_tarpaulin::process_handling::get_test_coverage
   7: cargo_tarpaulin::launch_tarpaulin
   8: cargo_tarpaulin::trace
   9: cargo_tarpaulin::run
  10: cargo_tarpaulin::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

So this is now merged and some point this week there shall be a new release on crates.io (probably tomorrow). closing this issue in favour of #549 I did spend all the time from around July till now fixing edge cases and panics I found on different projects so hopefully your issue is now fixed @Razican . If not head over to #549 :pray:


[SPARK-14060][SQL] Move StringToColumn implicit class into SQLImplicits

What changes were proposed in this pull request?
This patch moves StringToColumn implicit class into SQLImplicits. This was kept in SQLContext.implicits object for binary backward compatibility, in the Spark 1.x series. It makes more sense for this API to be in SQLImplicits since that's the single class that defines all the SQL implicits.
How was this patch tested?
Should be covered by existing unit tests.

Test build #53749 has started for PR 11878 at commit a4e9f4a.

Test build #53749 has finished for PR 11878 at commit a4e9f4a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 implicit class StringToColumn(val sc: StringContext)

Merged build finished. Test FAILed.

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

I have sent you a PR to fix it: https://github.com/rxin/spark/pull/19

Test build #53801 has started for PR 11878 at commit 8270086.

Test build #53801 has finished for PR 11878 at commit 8270086.

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

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

Merged build finished. Test PASSed.

Thanks @cloud-fan. Merging in master.