profile
viewpoint
Brandon W Maister quodlibetor Materialize, Inc New York, NY https://quodlibetor.github.io

quodlibetor/diesel-derive-newtype 22

derive newtype for diesel traits

n8han/shouty 20

Ad hoc broadcasting on Android

quodlibetor/dedupe 3

de-duplicate your music folders.

quodlibetor/diesel-derive-intermediate 3

Derive intermediate structs for Diesel

JohnMealy23/clinicjs 2

A semi-opinionated JavaScript framework

MaterializeInc/mzcli 2

materialize command line interface with autocompletion

quodlibetor/chef_attributes_dots_vs_spaces 1

Demonstrates the difference in attribute access between node.attr vs node['attr']

quodlibetor/django-piston 1

Fork of Django Piston

quodlibetor/action-shellcheck 0

GitHub action for ShellCheck.

pull request commentrust-lang/rfcs

RFC: Delegation

Since the original author of the RFC doesn't seem to be involved anymore and there were still open concerns from the Rust team members in the comment from 2 years ago (and not a lot discussion has happened since), I don't see this RFC getting merged.

It seems like someone new would need to come up with a proposal that addresses the existing concerns, write a new(/amended) RFC and bring it through the process.


While I'm obviously very fond of the feature personally, given that it's a non-trivial feature in what it adds to the language in terms of keywords, syntax, etc. and it's implementable in large parts with the macro system now, I'm not sure if it's really worth it to have as a builtin language feature.

While it might possibly due to the quality of the crate 🙃, I think it should also be noted that there has been little actual usage of ambassador (only one of those is not written by me, and there are just a handful more dependents that are on Github but not published to crates.io). The level of interested contributors and/or alternate implementations of proposals has also been similarly low for a possible language feature.

elahn

comment created time in 30 minutes

pull request commentrust-lang/rfcs

RFC: Delegation

@ibraheemdev my understanding is that people are bikeshedding the syntax. I personally like the syntax proposed in RFC and would love seeing this merged. I guess we could bikeshed along the way. Merging RFC doesn't say anything about stabilization.

elahn

comment created time in 35 minutes

issue commentrust-lang/rfcs

Crates should allow private impl of external traits for external structs

So in conclusion, this is not possible?

rust-highfive

comment created time in an hour

pull request commentrust-lang/rfcs

RFC: Delegation

Is there any update on this, or anything blocking it from being merged?

elahn

comment created time in an hour

push eventMaterializeInc/materialize

Nikhil Benesch

commit sha 4a5b72ad8d5d127bf6048e6d538c9b6f8ad115a2

sql-parser: fix regression in parsing of field accesses We previously supported field accesses like: ((col).field1).field2 but recent SQL parser refactors broke this. Restore support for this syntax. The SQL parser now treats both field accesses and subscripting as a maximum-precedence infix operation. This is at variance with PostgreSQL, which severly limits where field accesses and subscripting can occur, but matching PostgreSQL here is more trouble than it's worth. Their restrictions seem to be mostly a result of Yacc limitations rather than an intentional design.

view details

Nikhil Benesch

commit sha 1675c76a9109de2d899f8d3eda61704c1e04584c

doc/user: format GH links consistently Conventionally we place the GH links inside of the main sentence of the release note.

view details

Nikhil Benesch

commit sha 29efdc9d7f50891c461ffdd2727ab5d748c2a2a7

Merge pull request #4827 from MaterializeInc/fix-dot-access-regression sql-parser: fix regression in parsing of field accesses

view details

push time in 2 hours

delete branch MaterializeInc/materialize

delete branch : fix-dot-access-regression

delete time in 2 hours

PR merged MaterializeInc/materialize

sql-parser: fix regression in parsing of field accesses

We previously supported field accesses like:

 ((col).field1).field2

but recent SQL parser refactors broke this. Restore support for this syntax. The SQL parser now treats both field accesses and subscripting as a maximum-precedence infix operation.

This is at variance with PostgreSQL, which severly limits where field accesses and subscripting can occur, but matching PostgreSQL here is more trouble than it's worth. Their restrictions seem to be mostly a result of Yacc limitations rather than an intentional design.

<!-- Reviewable:start -->

This change is <img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/> <!-- Reviewable:end -->

+73 -30

0 comment

4 changed files

benesch

pr closed time in 2 hours

pull request commentMaterializeInc/materialize

wip: start pushing down projections

Ok, here's an updated version! Needs a rebase but I think this version preserves all the delta joins we have right now, but is a bit weird. Needs a bit more cleanup/comments but wanted to get this out. I also tried removing the demand analysis and it didn't seem to make things too much worse but I need to take a closer look.

justinj

comment created time in 2 hours

delete branch MaterializeInc/materialize

delete branch : chris/topic-replay-test

delete time in 2 hours

create barnchMaterializeInc/materialize

branch : chris/topic-replay-test

created branch time in 2 hours

Pull request review commentMaterializeInc/materialize

sql-parser: fix regression in parsing of field accesses

 parse-scalar 1</*embedded comment*/2 ---- Op { op: "<", expr1: Value(Number("1")), expr2: Some(Value(Number("2"))) }++parse-scalar+(x).a+----+FieldAccess { expr: Nested(Identifier([Ident("x")])), field: Ident("a") }++parse-scalar+(x).a.b.c+----+FieldAccess { expr: FieldAccess { expr: FieldAccess { expr: Nested(Identifier([Ident("x")])), field: Ident("a") }, field: Ident("b") }, field: Ident("c") }++parse-scalar+((x).a.b.c)+----+Nested(FieldAccess { expr: FieldAccess { expr: FieldAccess { expr: Nested(Identifier([Ident("x")])), field: Ident("a") }, field: Ident("b") }, field: Ident("c") })++parse-scalar+(((x).a.b).c)+----+Nested(FieldAccess { expr: Nested(FieldAccess { expr: FieldAccess { expr: Nested(Identifier([Ident("x")])), field: Ident("a") }, field: Ident("b") }), field: Ident("c") })++parse-scalar+(((x).a.b)[1].c)+----+Nested(FieldAccess { expr: SubscriptIndex { expr: Nested(FieldAccess { expr: FieldAccess { expr: Nested(Identifier([Ident("x")])), field: Ident("a") }, field: Ident("b") }), subscript: Value(Number("1")) }, field: Ident("c") })++parse-scalar roundtrip+(((x).a.b)[1].c)+----+(((x).a.b)[1].c)++parse-scalar+(1.a)+----+error: Expected right parenthesis, found identifier+(1.a)+   ^

👍

benesch

comment created time in 3 hours

push eventMaterializeInc/materialize

Sean Loiselle

commit sha dff5a83fa03be50bd3e73292ec7e51b27d0bc913

sql: improve maybe_rename_column error copy

view details

Brandon W Maister

commit sha 6f7d8962f58e1449833fb5008e09813a2f195b94

prometheus: Import raw upstream process collector This is the upstream process collector, unchanged except for the copyright comment.

view details

Brandon W Maister

commit sha 9a81a32de611a538084e2a0e858af2f3df31e13f

prometheus: Import our changes from the process collector This adds the per-thread metrics from https://github.com/MaterializeInc/rust-prometheus/tree/a6a57ce533811e5fba559aebe4adf38ed7d677b9

view details

Brandon W Maister

commit sha 23ae47f05b1c9d895d0f9134a2f7d5bc280baeb8

Make mz-process-collector work correctly after import

view details

Brandon W Maister

commit sha 5d8c1b43fb1dccdcc0e13f7a895eee6e2b0bda57

Use new mz-process-collector everywhere we were using the built-in

view details

Brandon W Maister

commit sha fd3df9a8adbc806548e2753d905b9b83a8b50584

Merge pull request #4820 from quodlibetor/vendor-process-collector Vendor our customized Prometheus process collector

view details

Nikhil Benesch

commit sha 035f788369003aeb8a362825f6204917b9c9d86d

doc/user: link to newly-published list docs in array docs

view details

Nikhil Benesch

commit sha 87abf3d789c0eda0b97d1af93236576f202eaae9

Merge pull request #4826 from MaterializeInc/list-docs doc/user: link to newly-published list docs in array docs

view details

Jessica Laughlin

commit sha 3de7c17d3d1b85bcc8c9440d6d5ea6821d158812

Continue v0.5.3 dev (#4824) * release: v0.5.2 * Prepare next phase of development: v0.5.3-dev

view details

Brandon W Maister

commit sha 531ebdd7345029fe45f8cc189fa3d14545b99790

Upgrade cargo-deny While I don't see it in their changelog[1], this upgrade causes cargo-deny to no longer spew out dozens of warnings for all of our internal `{ path = "../here" }` dependencies. $ cat ci/builder/stable.stamp >&2 ; \ bin/ci-builder run stable cargo --locked deny check licenses bans sources 2>&1 | wc -l 1.47.0-20201014-132433 1017 $ cat ci/builder/stable.stamp >&2 ; \ bin/ci-builder run stable cargo --locked deny check licenses bans sources 2>&1 | wc -l 1.47.0-20201118-152440 1 [1]: https://github.com/EmbarkStudios/cargo-deny/blob/main/CHANGELOG.md

view details

Brandon W Maister

commit sha fea353048173ac5e8354b0747b4a1aae6d149e1d

Remove requirements-ci.txt from ci/builder Dockerfile The file doesn't exist, so it causes the Docker build to break.

view details

Brandon W Maister

commit sha bb55eabb74426af1d2f21e7e41f4f1e68b640f0e

ci-builder: Tag and update stamp file when building, as well This makes the build and test workflow more pleasant.

view details

Eli Lindsey

commit sha 71ce650fba7c0fc5a2d46b87f7a250c360d8b230

periodically flush source_info metrics Updates to the source_info are written once we are caught up with the source to avoid incurring overhead on every source message. However, during bootstrap it can take a long time until we're caught up with the source, and that's exactly when a customer likely wants to view progress. Source will now flush source_info metrics every N messages to still show progress in such cases.

view details

Sean Loiselle

commit sha d6fe8cf3e115e122e27945cafae87bac49305b34

sql: plan CTEs

view details

Sean Loiselle

commit sha 068d7548fcf2af8d45956a018f5c9b2b14bbcc6d

Merge pull request #4825 from sploiselle/cte-in-planner sql: CTEs

view details

Jessica Laughlin

commit sha 27d4e6df6125c1a4f762a93358c1349566d8fdf6

docs: update user-facing docs with release information (#4830)

view details

Brennan Vincent

commit sha e36e21d213aabd1b309626eb908173a5d1632b2d

update time to v0.2.23 (#4835) * update time to v0.2.23 * update version_check; necessary for time to build

view details

Andi Wang

commit sha 8e9c2b47ed5e761e3a919ac826089c1472d58521

Support the reset event. Do 10 retries instead of checking to see if the log has lengthened since the last read, which empirically results in less corrupted data.

view details

Andi Wang

commit sha cdd4096a95306e59265984dfd2730bfceae94ffe

Add missing streams for the Mattapan High-Speed Rail.

view details

Andi Wang

commit sha ebc4e6f3dc1232365c3d27a9fc5b446ea0b946c7

Make archiving at shutdown optional for docker runs. Also, allow Materialize to start out with thread number correlating to available CPUs.

view details

push time in 3 hours

issue commentrust-lang/rfcs

Range types for integers (or refinement types?)

Yeah, there will be some explicit .try_into() calls needed for sure. For all I know this could go absolutely nowhere. I'm just interested in the feasibility of it for the time crate, honestly.

steveklabnik

comment created time in 3 hours

issue commentrust-lang/rfcs

Range types for integers (or refinement types?)

@jhpratt Great to hear it! I look forward to seeing how it goes.

The piece I keep looking forward to, though -- Integer<A,B> + Integer<C,D> => Integer<{A+C},{B+D}> -- isn't in min_, sadly.

steveklabnik

comment created time in 4 hours

pull request commentrust-lang/rfcs

Allow Eager Drops

Would it be feasible to let programmers opt into this behaviour by using some syntax to create blocks (possibly around their entire programme) in which eager drops are permitted?

rkjnsn

comment created time in 4 hours

issue commentMaterializeInc/materialize

Support User-defined Functions

It would be really great to be able to write transform/reduce functions using WASM.

Just an idea and I'm not sure whether it's practical: There could an opportunity for Materialize to provide some kind of composition-based SDK, that would allow for further optimization in some cases.

awang

comment created time in 5 hours

startedVerbalExpressions/JavaVerbalExpressions

started time in 5 hours

pull request commentMaterializeInc/materialize

repr: handle invalid dates using chrono's checks

if you request review from me that will help me see your PRs faster

Thanks, I'll do that for my next ones

Can you verify that you can see the failure in buildkite? https://buildkite.com/materialize/tests/builds/12258#_

Yep, I can see it. I just sent a fix and will make sure to run those checks locally :facepalm:

petrosagg

comment created time in 6 hours

pull request commentMaterializeInc/materialize

repr: handle invalid dates using chrono's checks

Maybe a race condition between the build starting and signing the CLA? It's my first PR here :)

petrosagg

comment created time in 7 hours

startedTheFrett/msfs_g36_project

started time in 8 hours

pull request commentrust-lang/rfcs

RFC: -C export-executable-symbols

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

MaulingMonkey

comment created time in 9 hours

pull request commentMaterializeInc/materialize

repr: handle invalid dates using chrono's checks

CLA assistant check <br/>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

petrosagg

comment created time in 9 hours

PR opened MaterializeInc/materialize

repr: handle invalid dates using chrono's checks

The current code does some rudimentary checks before passing the data to chrono's from_ymd function but invalid combinations can still be constructed, causing a panic.

Switch to using from_ymd_opt() to handle all leap year, and per month limit edge cases

Fixes #4880

+10 -2

0 comment

2 changed files

pr created time in 9 hours

issue openedMaterializeInc/materialize

Invalid input can cause panic during date parsing

<!-- Thanks for your feedback on Materialize! Please include the following information in your bug report. -->

What version of Materialize are you using?

$ materialized -v
materialized v0.5.2-dev (9a66d82a2c85246af2d04465cac03770f73593c4)

How did you install Materialize?

<!-- Choose one. -->

  • [ ] Docker image
  • [ ] Linux release tarball
  • [ ] APT package
  • [ ] macOS release tarball
  • [ ] Homebrew tap
  • [x] Built from source

What was the issue?

Server crashes if presented with an out of range date like 2020-02-30.

Is the issue reproducible? If so, please provide reproduction instructions.

Simply run SELECT '2019-02-30'::timestamp;

Please attach any applicable log files.

Relevant part of crash log:

materialized v0.5.2-dev (9a66d82a2) listening on 0.0.0.0:6875...
Nov 25 13:30:59.584 ERROR panic: <unnamed>: invalid or out-of-range date
   0: materialized::handle_panic
             at materialized/src/bin/materialized/main.rs:540:65
   1: core::ops::function::Fn::call
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:70:5
   2: std::panicking::rust_panic_with_hook
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:573:17
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:476:9
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153:18
   5: rust_begin_unwind
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475:5
   6: core::panicking::panic_fmt
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85:14
   7: core::option::expect_failed
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1213:5
   8: core::option::Option<T>::expect
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:333:21
   9: chrono::naive::date::NaiveDate::from_ymd
             at /home/petrosagg/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/naive/date.rs:173:9
  10: repr::adt::datetime::ParsedDateTime::compute_date
             at repr/src/adt/datetime.rs:465:20
  11: repr::strconv::parse_timestamp_string
             at repr/src/strconv.rs:220:24
  12: repr::strconv::parse_timestamp
             at repr/src/strconv.rs:268:11
  13: expr::scalar::func::cast_string_to_timestamp
             at expr/src/scalar/func.rs:382:5
  14: expr::scalar::func::UnaryFunc::eval
             at expr/src/scalar/func.rs:2538:49
  15: expr::scalar::ScalarExpr::eval
             at expr/src/scalar/mod.rs:554:53
  16: expr::scalar::ScalarExpr::reduce::{{closure}}
             at expr/src/scalar/mod.rs:279:50
  17: expr::scalar::ScalarExpr::reduce::{{closure}}
             at expr/src/scalar/mod.rs:284:26
  18: expr::scalar::ScalarExpr::visit_mut
             at expr/src/scalar/mod.rs:180:9

created time in 9 hours

pull request commentrust-lang/rfcs

Calling methods on generic parameters of const fns

@oli-obk Nice, it's even merged already!

oli-obk

comment created time in 11 hours

issue commentrust-lang/rfcs

Range types for integers (or refinement types?)

Just for anyone that may be thinking of doing the same thing — I intend to begin work on a basic implementation of ranged integers on nightly. With min_const_generics looking likely to stabilize in February 2021, it's probably best to get out ahead of it.

steveklabnik

comment created time in 12 hours

issue commentchronotope/chrono

format a Duration

I'd suggest at least adding this example to the docs (from the Reddit link posted earlier): https://play.rust-lang.org/?gist=f8b913eb26a2929ab2adfb4c8a2b6139&version=stable

Eh2406

comment created time in 18 hours

push eventMaterializeInc/materialize

Jessica Laughlin

commit sha ab69a179150fd3facb333e71e2e514e6eec6a511

sql: support empty maps (#4874)

view details

push time in 21 hours

PR opened chronotope/chrono

Add Default implementation for naive date types

This PR aims to add some Default implementations for some of the naive types. The currently added defaults are the following:

  • Default NaiveDateTime has been set to 1970-01-01 00:00:00
  • Default NaiveDate has been set to 1970-01-01
  • Default NaiveTime has been set to 00:00:00

The main reason for the PR is to help in struct definitions that wish to simply #derive[Default] but currently are not able to because on of their attributes is of the previously mentioned types, adding this change would help simplify the code in that particular scenario.

+43 -0

0 comment

3 changed files

pr created time in a day

more