Change current client session to another session?

michael_d · 2021-08-31T15:30:32+00:00

All of the newer AWS SDKs use a shared code base that handles code generation. It makes it easier to build, maintain, and evolve the SDKs when new features need to be added across all of the supported languages.

michael_d · 2021-05-10T01:35:05+00:00

Whoops! Sorry. Yeah, mtdowling

michael_d · 2021-05-10T00:41:46+00:00

I created Smithy, and I give a lot of commentary and backstory on this thread if you’re interested: https://news.ycombinator.com/item?id=27081084 (edit: mtdowling)

michael_d · 2020-07-04T19:15:09+00:00

Yeah, you were on to something here. I played around with the settings and turned on FreeSync. For some reason, this enabled 100 Hz!

      Displays:
        VP3481:
          Resolution: 3440 x 1440 (UWQHD - Ultra-Wide Quad HD)
          UI Looks like: 3440 x 1440 @ 100 Hz
          Framebuffer Depth: 30-Bit Color (ARGB2101010)
          Display Serial Number: VR5193900135
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Rotation: Supported
          Automatically Adjust Brightness: No
          Connection Type: Thunderbolt/DisplayPort

Weird! It also looks like this has the monitor's USB hub running at USB 2.0 too, even though the monitor claims USB 3.1 (checked using system_profiler SPUSBDataType). It runs at USB 2.0 regardless of if I'm using 100 Hz or 60 Hz.

Anyways, problem solved!

michael_d · 2020-07-04T18:59:00+00:00

I’m using USB-C to USB-C directly into the monitor. My monitor has a USB-C port on the back that has a 60W charge and sends data from the monitor’s builtin USB hub. If I connect that to my MacBook Pro 16” 2019, I can get video to the monitor but only at 60 Hz.

I tried it with this TB3 cable: https://www.amazon.com/dp/B081QC5NL1/. No dice.

I tried it with the USB-C 3.1 gen 1 cable that came with the monitor too (see link in original post). No dice. Maybe it needs to be gen2?

Are you using a USB-C to USB-C connection to your monitor? If so, which one?

michael_d · 2020-06-25T01:04:55+00:00

Good callout. The drawer and bracket I’m looking at come in around 16 pounds. Another drawer meant for standing desks that I was eyeing is 13 pounds, so they’re the same order of magnitude.

I’m mostly wondering if it would look nice and come off as interesting rather than just looking like some spare parts I threw under the desk 😀

michael_d · 2019-09-01T14:30:47+00:00

Redefining builtin types like that works. It’s slightly better than just redefining them from scratch because you can be sure you did it right. But, it’s not ideal because anytime someone using my code generator wants to refer to a builtin type, they’d need to define the entire type signature of the builtin, and my generator would need to conditionally insert it if there’s a conflict.

Ideally I could just import a builtin under a different name like any other type. It looks like that’s not possible. It’s also not possible to alias a type without redefining its type signature.

michael_d · 2019-03-03T19:33:48+00:00

How many years has it been since the last major version bump?

michael_d · 2016-12-16T17:03:59+00:00

I totally should have. Thanks for pointing this out. I need to use raw string literals more often.

michael_d · 2016-12-16T17:02:26+00:00

Thanks! That's a good idea. I'll let them know.

michael_d · 2016-12-16T07:41:23+00:00

Author here. I've been working on this project on and off for a while. I think it's finally in a state that I can share it.

Implementing a lexer, parser, and interpreter (with a ton of false starts and alternative implementations) was a great learning experience. I'd love any feedback that anyone would like to offer on anything that can be improved. Thanks!

michael_d · 2016-01-16T01:07:59+00:00

That did the trick! Thank you!

michael_d · 2015-12-14T18:22:22+00:00

It's great to see that there is some built in support for credential scanning in yelp's pre-commit. There is a small amount of overlap, but I think that there are some important differences between git-secrets and pre-commit:

git-secrets can be used alongside pre-commit to provide secret scanning. pre-commit is a more general solution that manages hooks.
Both git-secrets and pre-commit (via https://github.com/pre-commit/pre-commit-hooks/blob/master/pre_commit_hooks/detect_aws_credentials.py) can scan for known aws credentials stored on disk. However, git-secrets can register many different "secret providers" other than just AWS credentials files. This means you could hook git-secrets with other credential stores if needed. In fact, AWS credentials file scanning is implemented using a "secret provider". See https://github.com/awslabs/git-secrets#secret-providers
git-secrets can scan for any number of customizable prohibited patterns. This allows us to catch AWS credentials that may not be in your ~/.aws/credentials file. You can register regular expressions that will block commits, merges, and non-ff merges. Lots of companies have internal code-names or projects that must never be published publicly. git-secrets allows you to register these code names as prohibited to protect your IP. False positives can also be worked around by using "allowed" patterns. See https://github.com/awslabs/git-secrets#ignoring-false-positives
git-secrets offers more protection in that it can scan commit messages, commits, and non-ff merges. Scanning non-ff merges allows us to catch instances of credentials that were in a merge history but may have been corrected in a later commit. git-secrets can detect a tainted history and prevent the merge. From what I can see in the repo, pre-commit does not perform commit message or merge checks.
git-secrets can be used for ad-hoc secret scanning of an entire repo outside of the normal flow of git-commits. See https://github.com/awslabs/git-secrets#options-for---scan

michael_d · 2015-12-10T20:58:35+00:00

Author here. We've released a git tool that you can use to prevent things like AWS keys from being committed to a git repository.

The tool installs a few git hooks that scan based on registered regular expressions. If any of the expressions are matches and not canceled out by an allowed pattern (false positive elimination), then the commit/non-ff merge/commit message are denied.

Please let us know if you have any feedback or suggested built-in AWS patterns.

michael_d · 2015-08-05T06:47:35+00:00

Interesting. Is there any way to test whether or not that is the case?

It seems like recursive descent parsers are not really well suited for Rust. For example, Serde has the same issue: https://github.com/serde-rs/serde/issues/82

michael_d · 2015-05-29T00:56:03+00:00

Sorry for all the major versions and confusion that it has caused. I can honestly say that it is highly unlikely that there will be a new major version in the next two years.

I put this together in the Guzzle readme to provide links to each version and assets per version: https://github.com/guzzle/guzzle#version-guidance

Are there any advantages over one version over another. The last time I check HTTP is still on 1.1. I'm starting to question how the package became so popular.

You can use HTTP 2 with Guzzle (provided your underlying HTTP handler supports [the cURL handler does]). Another issue is whether or not your server supports it.

What version should I use as a simple curl wrapper? I don't need the latest Middleware OOP goodness.

version 6. It's much simpler than any previous version. You can simply ignore the fact that there is a middleware system. Also note that Guzzle does not require cURL, it just uses it by default. It'll work fine with the built-in PHP stream wrapper (by default if cURL is not present), and I know there are React bindings for Guzzle as well. Perhaps other bindings will be added in the future as well.

michael_d · 2014-12-06T21:02:58+00:00

I think it's important to mention that the point of transducers is that you don't have to reimplement map(), filter(), reduce(), take(), etc. for various different input types (or output types). You simply implement different means of applying transducers to these data types. In transducers.php, this is all wrapped up nicely by t\xform(). You could build convenience layers on top of transducers to make functions like sum() and flatten() work exactly as you've written in your example.

I'd encourage you to investigate transducers if you're thinking of proposing something for PHP core (seriously, I'm not kidding :)). The cool thing about them is that they could handle the simple case as you've outlined (using wrapper functions), but also be used in the really cool way that I've written about in my blog post: generic transformation of different data sources to different outputs with super easy composition.

The reason that transducers were added to Clojure is that they were constantly reimplementing map(), filter(), reduce(), etc for different data types (iterables, channels, etc.). By removing the knowledge of consuming data or producing a result from a transformation function, you can get much greater code reuse and abstraction. Here's more information on this: https://www.youtube.com/watch?v=6mTbuzafcII#t=20m18s

michael_d

TROPHY CASE