profile
viewpoint
Jacob Rosenthal jacobrosenthal #d#i#g#i#t#a#l#n#o#m#a#d http://citizengadget.com

garrows/browser-serialport 191

Robots in the browser. Just like node-serialport but for browser/chrome apps.

guanix/arduino-nrf8001 82

Arduino library for the Nordic nRF8001 Bluetooth Low Energy chip

jacobrosenthal/arduino-cli 21

Arduino Build System for Sublime Text 3

jacobrosenthal/arduino 10

firmata firmware for arduino

azdevs/desert-rustaceans 9

Desert Rust

jacobrosenthal/AgentTracker 2

BLE HeartRate monitor to Skynet.im over Phonegap iOS and Android tested

jacobrosenthal/arduino-nRF5 2

Arduino Core for Nordic Semiconductor nRF5 based boards

jacobrosenthal/arduino-server 1

Arduino build server backed by hapi and the official arduino toolchain. Dockerfile included.

jacobrosenthal/AVCapture 1

Cocoapod for av capture on OSX

push eventfrida/frida-website

Ole André Vadla Ravnås

commit sha d4e5df072fbcce83ca2aa1752f9c9e49a7b9a346

Document FFI support for size_t and ssize_t Added in Frida 14.1 thanks to @mame82.

view details

push time in 7 minutes

PR opened rust-lang/project-error-handling

misc-- oliver

items added:

  • (legacy) issues review
  • meeting notes for last
  • dir for doc references
+216 -0

0 comment

4 changed files

pr created time in 8 minutes

issue closedakiles/nrf-softdevice

L2CAP

This is not a very high priority because it seems L2CAP CoC channels are not very widely used. If you do find them useful for your project, please do reach out!

closed time in 9 minutes

Dirbaio

issue commentakiles/nrf-softdevice

L2CAP

done!

Dirbaio

comment created time in 9 minutes

push eventWebAssembly/WASI

Lin Clark

commit sha 4cd609bc27d3383a9aa409060b5668de435ceaf7

Add agenda items for 12-03 meeting (#361)

view details

push time in 12 minutes

PR merged WebAssembly/WASI

Add agenda items for 12-03 meeting
+3 -2

0 comment

1 changed file

linclark

pr closed time in 12 minutes

issue commentWebAssembly/WASI

WASI Logo

Following up from the last meeting:

As @sunfishcode said, he has spent some time looking into the potential legal issues that I mentioned above, but still has unanswered questions. I’m taking this over to allow him to focus on other important issues.

I have reached out to a colleague who has relevant experience. I expect that he'll be able to give me a clearer understanding of any nuances in the law as pertains to this. I will report back here once we’ve had a chance to get final confirmation that there are no potential issues.

lachlansneff

comment created time in 13 minutes

issue commentjonas-schievink/rubble

Writeable attributes & attribute permissions

What's the best way to go about testing this? I don't see any existing tests for the att/gatt modules (I imagine because the API surface is still changing) or any mention in CONTRIBUTING.md. I can put together a demo of writeable attributes (which would double as both a test and an example), but I don't have a UART/USB adapter to test with logging (the hardware I have access to does have a JTAG connection so I can use RTT).

Also, is it all right to leave PrepareWriteReq/ExecuteWriteReq unimplemented for now? My understanding is that prepare write puts a chunk of a write into a queue to then be atomically executed upon seeing an execute command; since ReadBlob/ReadMultiple aren't yet implemented either it makes sense to me to hold off on the grouped writes as well.

Sorry for all the questions! I'm still fairly new to BLE, and I'd like to make sure I'm doing things right.

daboross

comment created time in 16 minutes

PR opened WebAssembly/WASI

Add agenda items for 12-03 meeting
+3 -2

0 comment

1 changed file

pr created time in 19 minutes

create barnchWebAssembly/WASI

branch : linclark-patch-1

created branch time in 19 minutes

push eventakiles/nrf-softdevice

Dario Nieuwenhuis

commit sha 61176d7022433a1da60e66026d165cd1ebe2276a

Update README

view details

push time in 21 minutes

push eventakiles/nrf-softdevice

Dario Nieuwenhuis

commit sha b84ee960edbcdd035ee8c95a0e2d64fdbce9f300

Remove useless file

view details

Dario Nieuwenhuis

commit sha 25280ed723bea3ff0afd843d8d4fc18ffd9e0153

Add write_without_response to gatt client macros

view details

Dario Nieuwenhuis

commit sha 2093f31378b7c51260dc830752ad5befb628441e

Better conn params and mtu configuration.

view details

Dario Nieuwenhuis

commit sha 0bac886604bf82bd0fdd8c9a17c21f4be928899d

Add get/set address

view details

Dario Nieuwenhuis

commit sha 0d60c67cb1d83a9fbbf65b06f00f76d5849216d8

Add l2cap API

view details

push time in 24 minutes

PR opened atsamd-rs/atsamd

Use vcell v0.1.2

The register.rs file included in the output of svd2rust uses as_ptr(), which was only added in vcell v0.1.1 (now yanked).

See https://github.com/rust-embedded/svd2rust/pull/484 (maybe wait until it's looked at/merged)

This was found while doing #355 with a very old existing clone & running into weird compile errors:

error[E0599]: no method named `as_ptr` found for struct `VolatileCell<U>` in the current scope
  --> /[..]/atsamd/pac/atsamd21e/src/generic.rs:39:23
   |
39 |         self.register.as_ptr()
   |                       ^^^^^^ method not found in `VolatileCell<U>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `atsamd21e`

To learn more, run the command again with --verbose.
+15 -15

0 comment

15 changed files

pr created time in 32 minutes

push eventakiles/nrf-softdevice

Dario Nieuwenhuis

commit sha 7406f3d320dd138fd2eb763899701cdf7ff913b5

Fix missing cfg

view details

push time in 33 minutes

push eventatsamd-rs/atsamd

david-sawatzke

commit sha e4ff52822da2ad76811428f4cdeb6b38edff87b0

Use `wrapping_add` in dotstar examples (#355) The previous solution is hacky & `wrapping_add` exists for exactly this reason

view details

push time in 33 minutes

PR merged atsamd-rs/atsamd

Use `wrapping_add` in dotstar examples

The previous solution is hacky & wrapping_add exists for exactly this reason

+4 -12

0 comment

2 changed files

david-sawatzke

pr closed time in 33 minutes

PR opened atsamd-rs/atsamd

Use `wrapping_add` in dotstart examples

The previous solution is hacky & wrapping_add exists exactly for this reason

+4 -12

0 comment

2 changed files

pr created time in an hour

pull request commentrust-lang/rfcs

Let Cargo put data into platform-specific directories

One of the issues brought up was that there was no XDG spec for binaries. That's resolved now. That is all.

On Wed, Dec 2, 2020 at 3:48 PM soc notifications@github.com wrote:

The only activity was a text update to the spec acknowledging that .local/bin is a thing, I don't think this is has any impact on the ticket itself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rfcs/pull/1615#issuecomment-737486471, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS4PT2263JSLYTBE3BHCUTSS2R2RANCNFSM4CD2S7MQ .

tbu-

comment created time in an hour

pull request commentrust-embedded/svd2rust

Update the min `vcell` version to v0.1.2

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

david-sawatzke

comment created time in an hour

PR opened rust-embedded/svd2rust

Update the min `vcell` version to v0.1.2

src/generate/generic.rs:53 contains an as_ptr() call on a vcell. This was only added in vcell v0.1.1 (since yanked).

Thus, the generated crates only build with vcell v0.1.2

+4 -4

0 comment

3 changed files

pr created time in an hour

issue commentWebAssembly/WASI

Repository organization

Oh see, you are both talking about compatibility between versions. That issue I think should be considered separately. There has been fair amount of discussion on that issue in past: See https://github.com/WebAssembly/WASI/issues/2.

sunfishcode

comment created time in an hour

issue commentWebAssembly/WASI

Repository organization

Date-based versions are useful for communicating the WASI snapshots with toolchains and libraries without confusing it for the actual version of that toolchain or library.

Another closely related problem it solves is the stagnation of snapshots. We have had snapshot 1 out for a year now without committing to a date to release the next one, because we don't have tooling that can handle ephemeral right now. We need to get unstuck from this situation by putting time into the tooling, but to prevent this from happening in the future, a release train schedule will keep everyone honest on only merging changes once the tools actually support them. Its possible for a release train to use monotonic integers, but if the goal of those integers is just to communicate a snapshot in time and not a semantic version it makes more sense to just use a date.

According to semver, every change we have made in WASI so far is a major version breaking change, and nearly every change I can think of for the future is one as well. So, using semver is the same as sticking to the current monotonic integer scheme.

We have put a lot of thought into describing the differences and compatibility between versions in mechanical ways, but one big problem is that both the WASI interfaces themselves, and the technology used to specify those interfaces (witx, proposals like reference imports, interface types, etc) are both in flux. Therefore, we decided that the best we should do, until the technology to specify WASI is stable, is provide human-readable changelogs and use doc comments to describe similarities and differences to prior versions.

Since we don't yet know what the end state of this process will look like, lets defer figuring out how to describe the semantic differences to a machine (via semver, and other mechanisms) until we're on more stable ground. It will be at least a year, probably 2, before WASI is based on top of a stage 4 interface types proposal. At that point, semantic differences become a lot more meaningful and useful.

sunfishcode

comment created time in an hour

issue commentWebAssembly/WASI

Repository organization

What extra meaning might we want to covey with out snapshot releases versions? At least date-based scheme is strictly more meaningful than monotonic integers.

It's a bit easier to assess (breaking) changes on v1/v1.1/v2 vs 20.4/20.8/20.12

sunfishcode

comment created time in an hour

issue commentWebAssembly/design

Please Support Arbitrary Labels and Gotos.

If goto is to be so readily dropped from consideration, should the hundreds of uses of goto within emscripten's source be reconsidered as well?

  1. Note how much of that is present in musl libc, not directly in emscripten. (Second most used is tests/third_party)
  2. Source level constructs are not the same as bytecode instructions
  3. Emscripten is not at the same level of abstraction as the wasm standard, so, no it shouldn't be reconsidered on that basis.

Specifically, it might be useful today to rewrite the gotos out of libc, because then we'd have more control over the resulting cfg than trusting relooper/cfgstackify to handle it well. We haven't because it's a nontrivial amount of work to wind up with wildly divergent code from upstream musl.

Emscripten developers (last I checked) tend to be of the opinion that a goto-like structure would be really nice, for those obvious reasons, so are unlikely to drop it from consideration, even if it takes years to reach an acceptable compromise.

such a stance from the standardization body that greenlit <marquee> is beyond the pale.

This is a particularly asinine statement.

  1. We-the-broader-Internet are over a decade away from having made that decision
  2. We-the-wasm-CG are an entirely (nearly?) separate group of people from that tag, and are probably individually annoyed by obvious past mistakes as well.

without all the wasted pontificating, without the hipster landing page and shiny logo.

This could have been reworded to "I am frustrated" without running into tone issues.

As this thread shows, these conversations are difficult enough as it is.

oridb

comment created time in an hour

issue openedMarus/cortex-debug

How to set focus on Adapter Output

Tried to use vscode.commands.executeCommand('workbench.panel.output.focus', 'Adapter Output'); without success.

created time in an hour

issue commentWebAssembly/WASI

Repository organization

All these changes would greatly improve the directory structure and scale better than the current organization.

Y-m-d dates have the advantage of being immediately lexically sorted, but they don't convey anything about the difference and compatibility between two versions. Was semver ruled out?

sunfishcode

comment created time in an hour

issue openedrust-embedded/book

Confusing claim about HashMap in no_std

This section claims the existence of a collections crate which can provide Vec and HashMap implementations.

I don't believe such a crate exists. Nothing comes up in crates.io. Vec is provided by alloc crate, but HashMap is not.

created time in an hour

pull request commentrust-lang/stdarch

Add AVX512BITALG

r? @Amanieu

(rust-highfive has picked a reviewer for you, use r? to override)

DevJPM

comment created time in an hour

PR opened rust-lang/stdarch

Add AVX512BITALG

This adds the AVX512BITALG intrinsics. It also patches the verification against the Intel Intrinsic Guide because Rust uses a different naming. Added intrinsics match _mm(256|512)?(_maskz?)?_popcnt_epi(8|16) for the popcount ones and _mm(256|512)?(_mask)?_bitshuffle_epi64_mask

+766 -0

0 comment

3 changed files

pr created time in an hour

issue commentWebAssembly/WASI

Repository organization

One good thing about 2020-12 it sorts. I prefer it over Dec2018 but maybe I'm biased because I'm very used to ubuntu's naming scheme of 16.4 which is very similar to 2016-12.

What extra meaning might we want to covey with out snapshot releases versions? At least date-based scheme is strictly more meaningful than monotonic integers.

sunfishcode

comment created time in an hour

more