profile
viewpoint
Alex Burka durka University of Pennsylvania http://alexburka.com Robotics researcher graduating from Penn. Looking for a job making the world a better place to live.

durka/closet 6

Rust crate: CLOSure-Enhancing Toolbox (CLOSET) provides some questionably-useful macro utilities for closures, including clone_army!, which reduces boilerplate for clone-capturing closures, and vindaloo!, which does automatic currying.

durka/brainmunch 4

Brainfuck interpreter using the Rust macro system

astromme/KS0108-for-MSP430 3

KS0108 Display Driver for MSP430

durka/clj 2

My clojure projects.

durka/cellsplit 1

Utility for splitting a Matlab cell mode script into files

durka/alacritty 0

A cross-platform, GPU enhanced terminal emulator

durka/alexburka.com 0

My website, hosted at SCCS and accessible at alexburka.com

durka/Android-Password-Store 0

Android application compatible with ZX2C4's Pass command line application

issue openedred-rocket-computing/backtrace

multiple definitions compilation errors

The functions __aeabi_unwind_cpp_pr0 etc in backtrace.c have a comment saying they prevent the linking of the same functions in libgcc, but I just get errors about that:

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/thumb/v7e-m/fpv4-sp/hard/libgcc.a(unwind-arm.o): In function `__aeabi_unwind_cpp_pr0':
unwind-arm.c:(.text+0x760): multiple definition of `__aeabi_unwind_cpp_pr0'
build/backtrace_backtrace.c.o:backtrace.c:(.text.__aeabi_unwind_cpp_pr0+0x0): first defined here
collect2: error: ld returned 1 exit status

created time in 3 days

startedpinax/django-user-accounts

started time in 6 days

pull request commentrust-lang/rfcs

Edition 2021 and beyond

I would advocate for the "skipping editions" or more preferably "feature-based editions" model. I think having a cadence for editions will make breaking changes more common[1]. If something is going to be an edition-level change, then you can always use the refrain "OK, let's just wait for the next edition and we can do it anyway".

"But if we accept this, that'll be the only reason to have an edition, and it doesn't seem worth it."

I think this is exactly the consideration that should be made for large RFCs.

[1]: I know the argument is that they aren't really breaking changes because of the opt-in Cargo.toml attribute and automated migration tooling. These are indeed great features of the Rust ecosystem. But it still means that Rust code looks different and means something different to humans, which is a form of breakage.

nikomatsakis

comment created time in 11 days

startedcontinental/ecal

started time in 14 days

pull request commentmadcowswe/ODrive

Fix protocol bugs

I think this addresses my concerns from #438. Added one other semi-related question above.

samuelsadok

comment created time in 22 days

Pull request review commentmadcowswe/ODrive

Fix protocol bugs

 static Introspectable root_obj = ODriveTypeInfo<ODrive>::make_introspectable(odr // @brief Sends a line on the specified output. template<typename ... TArgs> void respond(StreamSink& output, bool include_checksum, const char * fmt, TArgs&& ... args) {-    char response[64];+    char response[64]; // Hardcoded max buffer size. We silently truncate the output if it's too long for the buffer.     size_t len = snprintf(response, sizeof(response), fmt, std::forward<TArgs>(args)...);+    len = std::min(len, sizeof(response));     output.process_bytes((uint8_t*)response, len, nullptr); // TODO: use process_all instead     if (include_checksum) {         uint8_t checksum = 0;         for (size_t i = 0; i < len; ++i)             checksum ^= response[i];         len = snprintf(response, sizeof(response), "*%u", checksum);+        len = std::min(len, sizeof(response));         output.process_bytes((uint8_t*)response, len, nullptr);

I'm not entirely clear on the USB middleware so this is kind of theoretical. But does sending stuff in three separate process_bytes calls slow things down? I was analyzing some data dumps and found many cases where checksums and line breaks showed up in separate USB reads.

samuelsadok

comment created time in 22 days

issue openedmadcowswe/ODrive

USB responses over 64 bytes are silently dropped or cause buffer over-read

This bug has multiple layers which hide each other, but I am fairly confident it's a real bug.

A loop in interface_usb.cpp attempts to send everything passed to it, even if the passed-in buffer is larger than a USB packet: https://github.com/madcowswe/ODrive/blob/306000f46e5d04f21177ee05fcd11469e5282295/Firmware/communication/interface_usb.cpp#L60-L71

However, because the original length is passed through on line 63 instead of the newly calculated chunk, the loop fails in its stated purpose.

The inner type, USBSender, simply returns -1 if asked to send more than 64 bytes, so the loop would exit on the first iteration if length > 64. (If length is precisely 64, we get through, but I think that's not really intended and the comparison on line 62 ought to be <=.)

As it is, the respond function in ascii_protocol.cpp tries not to send more than 64 bytes anyway, so the bug probably won't come up. But, that's not airtight for two reasons:

  1. The buffer in respond is declared as size 64, but not using the USB_TX_DATA_SIZE definition, so could easily get out of sync with that
  2. I say tried because respond uses snprintf incorrectly. From the man page:

The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')). If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated.

So if one of the snprintfs in respond would write more than 64 bytes, it does not, but len is incremented anyway. Then a subsequent snprintf or the USB sending code will read past the end of the buffer.

created time in a month

PublicEvent

issue openedinteger32llc/rust-playground

Passing `gist` URL parameter twice breaks playground

Normally, if you pass something invalid for the gist, the playground just opens with an empty textarea. But if you pass it twice, the page doesn't load at all. (Q: How could that happen / why would you do that? A: by mistake)

This link shows a completely blank page for me in Firefox and Chrome (macOS): https://play.rust-lang.org/?gist=break&gist=rust

The error console shows:

TypeError: "Parameter 'url' must be a string, not object"
    parse https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:1
    b https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:1
    resolve https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:1
    resolve https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:1
    Bt https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    r https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:6
    dispatch https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:1
    Ut https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    r https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:6
    l https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    router https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    Rr https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    gi https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    La https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    yu https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    sl https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    ul https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    Ju https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    Ku https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    Fl https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    l https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    tl https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    $l https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    render https://play.rust-lang.org/assets/13f807a13f5fc9461372.js:22
    511 https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:13
    c https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
    239 https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
    c https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
    a https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
    <anonymous> https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
    <anonymous> https://play.rust-lang.org/assets/c6dbac6de476402e0d00.js:1
13f807a13f5fc9461372.js:22:82385

created time in a month

starteditchyny/calendar.vim

started time in a month

startedn0v1c3/vira

started time in a month

startedsamtay/so

started time in a month

startedcsb6/html-plus-plus

started time in a month

issue commentrust-lang/rustup

PATH not set post installation on OS X 10.11.4

Can you clarify "new" and "old" versions of OSX? How long ago did the behavior change?

On Thu, Jun 25, 2020 at 10:55 PM Jubilee notifications@github.com wrote:

So, #2387 https://github.com/rust-lang/rustup/pull/2387 fixes this... sortof. You see, it fixes it on new versions of Mac, and most versions of Linux and FreeBSD as well. .bash_profile was never really the intended home for environment variables, especially not on GUIs, for bash. Mostly that is what .bashrc is for.

Old versions of Mac OSX have an aberrant behavior regarding this, compared to other versions of bash. Newer versions, I think at least since Catalina, have a more normal behavior, partly because they use zsh as their default (which favors .zshenv), but I am given to understand that new bashes for Mac are also fixed, and just in general I am not aware of anything actually stopping you from installing a new bash on an older Mac.

So, two ways forward:

  1. If rustup wishes to support older versions of Mac's bash, even though they use an aberrant behavior, that will increase the code complexity. However, I would consider it reasonable to author such a fix, except that I don't have spare old Macs lying around so I am suspicious of testing it. If anyone wishes guidance in implementing this patch, I can pair with them on this. @ me on Discord or something.
  2. rustup can decide that, since everyone involved admitted it was a mistake, essentially, and that this is fixable, that this is Clearly Not Their Problem.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rustup/issues/371#issuecomment-649925009, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALPH7THBNUWI2VHUHWJQLRYQE2VANCNFSM4CCIDAKA .

slayerjain

comment created time in 2 months

startedHirrolot/poica

started time in 2 months

push eventdurka/dotfiles

Alex Burka

commit sha 34b7cd96cfd228b21c36b5270247992e84d38977

autohotkey version for windows

view details

push time in 3 months

push eventdurka/owned-chars

Nick Torres

commit sha e149768428a62063018bc9426bd56f04447e25ed

Add example use to README.md

view details

Alex Burka

commit sha 6866da12f831176de20d0c19949cd9a3a768ffff

Merge pull request #8 from nickrtorres/readme-example Add example use to README.md

view details

push time in 3 months

pull request commentdurka/owned-chars

Add example use to README.md

Thanks!

nickrtorres

comment created time in 3 months

PR merged durka/owned-chars

Add example use to README.md

Thanks for this crate! It's been very helpful in a project I'm working on.

This PR contains a commit that adds simple example program showing the use of OwnedChars::from_string.

Rendered

+28 -0

0 comment

1 changed file

nickrtorres

pr closed time in 3 months

issue commentWinetricks/winetricks

Unable to install vcrun2015 on Ubuntu 20.04 (Focal)

Has anyone made headway on this issue? For me the error is on rgb9rast_2._x86, though if I run the installer again it errors on a different file. Works perfectly outside of docker which is very perplexing and frustrating.

bandi13

comment created time in 3 months

more