profile
viewpoint
Ashley Mannix KodrAus @Datalust Brisbane, Australia https://kodraus.github.io ⏰ 1:00am Thursday UTC Weekly: 👀 on @rust-lang PRs!

helm/charts 14828

⚠️(OBSOLETE) Curated applications for Kubernetes

env-logger-rs/env_logger 278

A logging implementation for `log` which is configured via an environment variable.

elastic-rs/elastic 244

An Elasticsearch REST API client for Rust

auto-impl-rs/auto_impl 35

Automatically implement traits for common smart pointers

KodrAus/cargo-nuget 25

A tool for packaging Native Rust libs as Nuget nupkgs

KodrAus/emit 15

An experimental alternative macro implementation for tracing

elahn/rfcs 1

RFCs for changes to Rust

KodrAus/csharp-aot 1

Some examples of compiling C# ahead-of-time

KodrAus/easy-mesos 1

Super simple docker-compose for mesos in dev

startedealush/vest

started time in 3 hours

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

@quininer Interesting. That's quite surprising that you managed to run across this naturally, to be honest.


@puetzp A note in documentation is certainly feasible. Unfortunately docs.rs doesn't allow updating already-published docs, so it's not possible for v0.2 (unless there's another release for some reason).

puetzp

comment created time in 3 hours

created repositoryseanchen1991/TLBoS

The Little Book of Semaphores Exercises in Rust

created time in 4 hours

push eventmicrosoft/verona

Sylvan Clebsch

commit sha fd37fbb0acef86f276a928839bde873ef0faebab

remove Kind::For

view details

push time in 5 hours

push eventmicrosoft/verona

Sylvan Clebsch

commit sha 66bf234d449b52994a431c8c4d8121f574796aac

for-loop sugar during parsing

view details

push time in 5 hours

Pull request review commentrust-lang/compiler-builtins

Overhaul split integer handling and fix numerous issues

 macro_rules! int_impl {     }; } +int_impl!(isize, usize, usize::MAX.count_ones());+int_impl!(i8, u8, 8); int_impl!(i16, u16, 16); int_impl!(i32, u32, 32); int_impl!(i64, u64, 64); int_impl!(i128, u128, 128); -/// Trait to convert an integer to/from smaller parts-pub(crate) trait LargeInt: Int {-    type LowHalf: Int;-    type HighHalf: Int;+/// Trait for integers twice the bit width of another integer. This is implemented for all+/// primitives except for `u8`, because there is not a smaller primitive.+#[doc(hidden)]+pub trait DInt: Int {+    /// Integer that is half the bit width of the integer this trait is implemented for+    type H: HInt<D = Self> + Int;++    /// Returns the low half of `self`+    fn lo(self) -> Self::H;+    /// Returns the high half of `self`+    fn hi(self) -> Self::H;+    /// Returns the low and high halves of `self` as a tuple+    fn lo_hi(self) -> (Self::H, Self::H);+} -    fn low(self) -> Self::LowHalf;-    fn low_as_high(low: Self::LowHalf) -> Self::HighHalf;-    fn high(self) -> Self::HighHalf;-    fn high_as_low(low: Self::HighHalf) -> Self::LowHalf;-    fn from_parts(low: Self::LowHalf, high: Self::HighHalf) -> Self;+/// Trait for integers half the bit width of another integer. This is implemented for all+/// primitives except for `u128`, because it there is not a larger primitive.+#[doc(hidden)]+pub trait HInt: Int {+    /// Integer that is double the bit width of the integer this trait is implemented for+    type D: DInt<H = Self> + Int;++    /// Widens (using default extension) the integer to have double bit width+    fn widen(self) -> Self::D;+    /// Widens (zero extension only) the integer to have double bit width. This is needed to get+    /// around problems with associated type bounds (such as `Int<Othersign: DInt>`) being unstable+    fn zero_widen(self) -> Self::D;+    /// Widens the integer to have double bit width and shifts the integer into the higher bits+    fn widen_hi(self) -> Self::D;+    /// Constructs a double bit width integer using lower and higher parts+    fn from_lo_hi(lo: Self, hi: Self) -> Self::D;

You're right, I don't know why I didn't see this before. It eliminates some code size in practice also

AaronKutch

comment created time in 5 hours

issue commentdatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

Very good, I'll get it updated.

CrossBound

comment created time in 6 hours

issue closeddatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

Describe the bug Dashboard widgets of type 'Value' seem to get a faded appearance after a refresh of the dashboard occurs.

To Reproduce Steps to reproduce the behavior:

  1. Setup a dashboard widget of type 'Value'
  2. Refresh the dashboard

Expected behavior It maintains full color after a refresh.

Screenshots Before: image

After: image

Environment (please complete the following information):

  • Client OS: Windows 10 Enterprise x64 Version 1809
  • Browser: Firefox Developer 84.0b2 x64
  • Seq Version: 2020.4.5089
  • Using Docker? No

Additional context n/a

closed time in 6 hours

CrossBound

issue commentdatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

Thanks for the report, @CrossBound ! This is a duplicate of https://github.com/datalust/seq-tickets/issues/1063, which is fixed in 2020.4.5119 (now published).

CrossBound

comment created time in 6 hours

issue commentrust-lang/stdarch

AVX-512f intrinsics fail to compile with MemorySanitizer

First I cherry-picked the fix for the cvt functions from upstream llvm (and committed the llvm submodule in the rust repo), ran my "build core with instrumentation" test, which proved that _mm512_shuffle_ps needs an independent fix.

For more in-depth tests, and hopefully a reduction, I tried to get clang built from a rust checkout using

RUSTBUILD_FORCE_CLANG_BASED_TESTS=1 ./x.py build --stage 1

but ld kept getting killed by the OOM killer, and using LLD failed in a different way (ld.lld: error: asan_malloc_linux.cpp:(.debug_loc+0x222F70): has non-ABS relocation R_386_GOTOFF against symbol 'alloc_memory_for_dlsym').

g2p

comment created time in 8 hours

push eventmicrosoft/verona

Sylvan Clebsch

commit sha e31c67a5c21135d4ccbfcc87a58db9051ad5dc8c

declarations

view details

push time in 8 hours

issue commentrust-lang/stdarch

AVX-512f intrinsics fail to compile with MemorySanitizer

Which clang version did you build? The one in https://github.com/rust-lang/llvm-project?

I however get _mm512_shuffle_ps code generation errors with this overall test in a rust checkout:

RUSTFLAGS_NOT_BOOTSTRAP="-Cpasses=sancov -Clink-dead-code -Zsanitizer=memory -C codegen-units=1" ./x.py build -i library/core 

That command builds the standard library with the bootstrap compiler, which I think currently uses an older version than master. You should try RUSTFLAGS="-Cpasses=sancov -Clink-dead-code -Zsanitizer=memory -C codegen-units=1" cargo +nightly build -Zbuild-std --target x86_64-unknown-linux-gnu I think. (assuming that you use x86_64-unknown-linux-gnu and have the rust-src component installed)

g2p

comment created time in 8 hours

issue commentdatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

FYI, this did not occur in 2020.3

CrossBound

comment created time in 8 hours

issue commentdatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

I have confirmed this also occurs on MS Edge 86.0.622.69 (Official build) (64-bit)

CrossBound

comment created time in 8 hours

issue openeddatalust/seq-tickets

Value type dashboard widget fades out after dashboard refresh

Describe the bug Dashboard widgets of type 'Value' seem to get a faded appearance after a refresh of the dashboard occurs.

To Reproduce Steps to reproduce the behavior:

  1. Setup a dashboard widget of type 'Value'
  2. Refresh the dashboard

Expected behavior It maintains full color after a refresh.

Screenshots Before: image

After: image

Environment (please complete the following information):

  • Client OS: Windows 10 Enterprise x64 Version 1809
  • Browser: Firefox Developer 84.0b2 x64
  • Seq Version: 2020.4.5089
  • Using Docker? No

Additional context n/a

created time in 8 hours

issue commentrust-lang/stdarch

AVX-512f intrinsics fail to compile with MemorySanitizer

Thanks, glad it got fixed already! I was not able to get a similar minimal reduction for _mm512_shuffle_ps. Because clang is a beast to build (the linker runs out of memory), I don't have a clang build with assertions enabled. The above commands seem to work with this in a.c

#include <immintrin.h>

__m512 test_mm512_shuffle_ps(__m512 __M, __m512 __V) {
  return _mm512_shuffle_ps(__M, __V, 8); 
}

I however get _mm512_shuffle_ps code generation errors with this overall test in a rust checkout:

RUSTFLAGS_NOT_BOOTSTRAP="-Cpasses=sancov -Clink-dead-code -Zsanitizer=memory -C codegen-units=1" ./x.py build -i library/core 
g2p

comment created time in 8 hours

Pull request review commentmicrosoft/verona

Document the IR.

 This could be refined by considering, which classes could reach `i`.  For instan  # Region Tracking -[TODO]+We need the provenance of each mutable reference to an object to its +region to be represented in the code.  +This is only required for variable that can contain a mutable reference into region tree.+We need this because we support certain operations on a region that can be done by having+a reference to any particular object in that region.++An `iso` reference is both a handle on an object, and can cheaply access its region+information.++A `mut` reference does not cheaply know its owning region, +so we need the compiler to have a second+reference associate with each `mut` that refers to its region.++To maintain this data, for an aliasing field read+```+y = x.f+``` +we need translate this to+```+y = // Read field described below.+if (y->rt::Object::get_class() == RegionMD::ISO)+  y_region = y+else +  y_region = x_region+```++And for extracting field read:+```+y = (x.f = z)+``` +similarly has+```+if (y->rt::Object::get_class() == RegionMD::ISO && y != x_region)+  // Extracted iso, so the region pointer is not required.+  //  By using null, we enable pattern matching on extracted isos.+  y_region = null+else+  y_region = x_region+```+This differs slightly as it also keeps enough information to determine+if a reference is an `iso` capability.  The `y != x_region` check is+required because `mut` can reference the entry point of its current+region, and that should not be treated like an `iso`.++The introduced sequences are good candidates for MLIR optimisations as type information+can be used to simplify them.++This can be used in object construction as follows+```+  x = new C in y+```+should use `y_region` to call the runtime for the allocation.++Also, this can be used to pattern match to resolve `iso | mut` capabilities:+```+y = (x.f = z)+match y with+  iso => C1+  mut => C2+```+Would become+```+y = x->f;+x->f = z;+if (y->rt::Object::get_class() == RegionMD::ISO && y != x_region)+  // Extracted iso, so the region pointer is not required.+  y_region = nullptr+else+  y_region = x_region+if (y_region == nullptr)+{+  [[C1]]  // Lowering of C1+}+else+{+  [[C2]]  // Lowering of C2+}+```++This is particularly important for commands like `drop` that deallocate a region, where the parameter+may or may not be a region:+```+// x : (mut|iso) & ...+drop(x)+```+would be translated to+```+if (x_region == nullptr)+  // call into runtime to deallocate `x`+```++The region assoicated with each `mut` also affects the calling convention.+Each argument that can contain a reference of type `mut`+needs to be made into two arguments, the region entry point and the object itself.  Similarly,+return types that can contain `mut` must be double width to encode the region entry point+of the returned values.++Many places the region associated with a variable will not be required, and dead code elimination +can be used.+A global analysis could also be implemented to remove unneeded region parameter and returns for functions/methods.+++Aside:  We do not have to worry about allocating on a null region+variable. The front-end will perform sufficient work such that+```+  x = new C in y+```+will guarantee that `y` is not an `iso` by adding coercions to+`mut` such that all accesses in a function will determine they +are part of the same region

Yeah, sorry that was more how I was thinking it should be, not how it is.

plietar

comment created time in 9 hours

Pull request review commentmicrosoft/verona

Document the IR.

 This could be refined by considering, which classes could reach `i`.  For instan  # Region Tracking -[TODO]+We need the provenance of each mutable reference to an object to its +region to be represented in the code.  +This is only required for variable that can contain a mutable reference into region tree.+We need this because we support certain operations on a region that can be done by having+a reference to any particular object in that region.++An `iso` reference is both a handle on an object, and can cheaply access its region+information.++A `mut` reference does not cheaply know its owning region, +so we need the compiler to have a second+reference associate with each `mut` that refers to its region.++To maintain this data, for an aliasing field read+```+y = x.f+``` +we need translate this to+```+y = // Read field described below.+if (y->rt::Object::get_class() == RegionMD::ISO)+  y_region = y+else +  y_region = x_region

I like the idea of using the front-end to separate out allocation on an iso reference from mut, and then this seemed cleaner.

We can put the alternative in.

plietar

comment created time in 9 hours

Pull request review commentmicrosoft/verona

Document the IR.

 This could be refined by considering, which classes could reach `i`.  For instan  # Region Tracking -[TODO]+We need the provenance of each mutable reference to an object to its +region to be represented in the code.  +This is only required for variable that can contain a mutable reference into region tree.+We need this because we support certain operations on a region that can be done by having+a reference to any particular object in that region.++An `iso` reference is both a handle on an object, and can cheaply access its region+information.++A `mut` reference does not cheaply know its owning region, +so we need the compiler to have a second+reference associate with each `mut` that refers to its region.++To maintain this data, for an aliasing field read+```+y = x.f+``` +we need translate this to+```+y = // Read field described below.+if (y->rt::Object::get_class() == RegionMD::ISO)+  y_region = y+else +  y_region = x_region+```++And for extracting field read:+```+y = (x.f = z)+``` +similarly has+```+if (y->rt::Object::get_class() == RegionMD::ISO && y != x_region)+  // Extracted iso, so the region pointer is not required.+  //  By using null, we enable pattern matching on extracted isos.+  y_region = null+else+  y_region = x_region+```+This differs slightly as it also keeps enough information to determine+if a reference is an `iso` capability.  The `y != x_region` check is+required because `mut` can reference the entry point of its current+region, and that should not be treated like an `iso`.++The introduced sequences are good candidates for MLIR optimisations as type information+can be used to simplify them.++This can be used in object construction as follows+```+  x = new C in y+```+should use `y_region` to call the runtime for the allocation.++Also, this can be used to pattern match to resolve `iso | mut` capabilities:+```+y = (x.f = z)+match y with+  iso => C1+  mut => C2+```+Would become+```+y = x->f;+x->f = z;+if (y->rt::Object::get_class() == RegionMD::ISO && y != x_region)+  // Extracted iso, so the region pointer is not required.+  y_region = nullptr+else+  y_region = x_region+if (y_region == nullptr)+{+  [[C1]]  // Lowering of C1+}+else+{+  [[C2]]  // Lowering of C2+}+```++This is particularly important for commands like `drop` that deallocate a region, where the parameter+may or may not be a region:+```+// x : (mut|iso) & ...+drop(x)+```+would be translated to+```+if (x_region == nullptr)+  // call into runtime to deallocate `x`+```++The region assoicated with each `mut` also affects the calling convention.+Each argument that can contain a reference of type `mut`+needs to be made into two arguments, the region entry point and the object itself.  Similarly,+return types that can contain `mut` must be double width to encode the region entry point+of the returned values.++Many places the region associated with a variable will not be required, and dead code elimination +can be used.+A global analysis could also be implemented to remove unneeded region parameter and returns for functions/methods.+++Aside:  We do not have to worry about allocating on a null region+variable. The front-end will perform sufficient work such that+```+  x = new C in y+```+will guarantee that `y` is not an `iso` by adding coercions to+`mut` such that all accesses in a function will determine they +are part of the same region

This isn’t actually true today. That code, with y: iso will pass the typechecker. Of course we can change that in the future.

plietar

comment created time in 9 hours

Pull request review commentmicrosoft/verona

Document the IR.

 This could be refined by considering, which classes could reach `i`.  For instan  # Region Tracking -[TODO]+We need the provenance of each mutable reference to an object to its +region to be represented in the code.  +This is only required for variable that can contain a mutable reference into region tree.+We need this because we support certain operations on a region that can be done by having+a reference to any particular object in that region.++An `iso` reference is both a handle on an object, and can cheaply access its region+information.++A `mut` reference does not cheaply know its owning region, +so we need the compiler to have a second+reference associate with each `mut` that refers to its region.++To maintain this data, for an aliasing field read+```+y = x.f+``` +we need translate this to+```+y = // Read field described below.+if (y->rt::Object::get_class() == RegionMD::ISO)+  y_region = y+else +  y_region = x_region

This needs x_region to not be null as well, just like the allocation stuff further down.

Why did you go with the region is null, rather than tagging the low bits as you’d mention previously?

plietar

comment created time in 9 hours

push eventmicrosoft/verona

Sylvan Clebsch

commit sha bffd0c0f9af6b0726548f0f573b999bd65d36d82

lambda parsing

view details

push time in 10 hours

issue commenttime-rs/time

Time v0.3 tracking issue

I'm not sure if you ran across this, but PrimitiveDateTime is an OffsetDateTime without the UtcOffset. There is the ability to assume an offset on the former, which returns the latter. A PrimitiveDateTime has no way to directly get the "current" time, as doing so inherently requires an offset (which isn't present).

The PrimitiveDateTime::assume_* methods make indeed more sense now. So, OffsetDateTime are created from the "current" time and if the system does not support retrieving the local time it will return an error on the local methods. Is that correct?

For the top level documentation short lists for features, goals, non-goals, roadmap etc. could help without writing too much. Otherwise, I think the corrections you made to my comment could be a good starting point for documentation.

jhpratt

comment created time in 10 hours

Pull request review commentmicrosoft/verona

Relaxed semantics for message send and deallocation

+# Alternative semantics for Verona.
+
+## Abstract
+
+This document is a thought experiment in how runtime support can reduce the complexity of the type system.  The key insight is to delay certain operations to a point where we can trivially know that there is no aliasing.  Aliases into a region are difficult to track accurately at compile time.  We propose relaxing the semantics of when a programmer can assume an event occurs, which allows for a simpler type system.
+
+## Motivation
+
+The current design of Verona requires accurate tracking of the 
+subregion relationship to enable the invalidation of references for safety.
+For instance, if we have a class
+```
+class Foo
+{
+    f: iso & Bar;
+    ...
+}
+```
+and an access to its `f` field such as
+```
+// x: Foo & mut
+var y = x.f;
+```
+then we need to track that `y` has come from a subregion of `x`.
+Certain operations on `x`'s region must also invalidate `y`.
+If we drop the region containing `x`, then that will also deallocate the subregion, and thus `y` would be dangling if we did not invalidate it.
+
+The same is true for a `when` that captures a region in its closure:
+```
+var a = new C
+a.next = new D
+// a : iso & C
+var b = a.next;
+// a : iso & C, b : mut & D
+when (c) {
+    //do something with a 
+}
+// Use b
+```
+Here `a` is sent to the `cown` `c` by the runtime.  Once that message is sent, we must also invalidate the references into subregions. The `use b` after the
+`when` is invalid as it could be in parallel with the `do something with a`.
+This leads to us having to track subregion information precisely, so that we know that `a` being captured by the `when` invalidates `b`.
+
+We have explored various restrictions to reduce the required precision, but not found a solution that we can agree upon.  A key requirement is any subregion information must be expressible as a method signature otherwise we will not be able to outline code.  This however makes the design visible and constrains future extensions.
+
+The core reason for tracking this information precisely is that dropping a region, or sending a message, happens immediately.  If we alter the semantics to dropping a region or sending a message to happen once there are no interior pointers into the region or subregions of that region, then we have a different programming model.
+
+We know that once a behaviour completes then it will have no interior references and thus it can send all its messages, and deallocate all the dropped regions, thus it will be safe to deallocate the regions and send the messages. 
+Delaying message send and deallocation until the behaviour completes may reduce concurrency and increase memory pressure.
+However, this does not require any clever type system or analysis to make this work, and we would not have to track subregion information.
+We could specify the semantics as messages are only sent at the end of a behaviour, but that would constrain future optimisations.
+If the semantics simply states that messages can be sent once a behaviour is guaranteed not to access the region (and subregions), then we open the possibility of adding a better static type system, or compiler optimisation passes at a future point.
+
+## Proposal
+
+We change the semantics of the language in the following two ways:
+
+>  Message send happens after all the internal references to the region tree have been removed.
+
+and
+
+> Deallocation of a region happens after all internal references to the region have been removed.
+
+The slight difference allows for a region to be deallocated, but for the sub-regions deallocation to be delayed longer.
+
+**[Luke, Paul, This might lead to an interesting formal semantics. I think it breaks the current thinking on keeping the region structure and the cown concurrency separate.]**
+
+## Type system
+
+```
+   Capabilities ::= iso | mut | imm
+   tau : Types ::= iso  |  mut  |  imm  |  tau|tau  |  tau&tau  |  r  |  I  |  C
+     |  tau ~>_r tau  |  tau <~_r tau  |  X
+```
+where 
+   `C` are class names
+   `I` are interfaces
+   `r` are region variables
+   `X` are type variables
+
+Most of the syntax of types is standard, but  `tau ~>_r tau` and `tau <~_r tau` are special region operations, known as "view point adapation"s.  There are two types aliasing, `~>`, and extracting `<~`.
+
+We restrict types on fields and generic parameters to not mention `r`, i.e. they cannot contain `r`, `tau ~>_r tau` and `tau <~_r tau`.
+
+**[Sylvan is this too restrictive]**
+
+We interpret the semantics of types with 
+```
+[[ _ ]] : 
+    (region var -> region) 
+        -> (type var -> P(C, region, cap)) 
+            -> P(C, region, cap)
+```
+where
+```
+  [[ iso ]](R,T) = { C,r,iso | C \in Class, r \in region}
+  [[ r ]](R,T) = { C,R(r),cap | C \in Class, cap \in Caps }
+  [[ C ]](R,T) = { C,r,cap | r \in region, cap \in Caps }
+  [[ X ]](R,T) = T(X)
+  [[ tau ~>_r tau ]](R, T) = 
+    { V1 ~>_R(r) V2 | V1 \in [[tau1]](R,T) /\ V2 \in [[tau2]](R,T)}
+  [[ tau <~_r tau ]](R, T) = 
+    { V1 <~_R(r) V2 | V1 \in [[tau1]](R,T) /\ V2 \in [[tau2]](R,T)}
+```
+
+Aliasing viewpoint adaptation
+```
+C1,r1,mut ~>_r C2,_,mut = C2,r1,mut
+C1,r1,iso ~>_r C2,_,mut = C2,r1,mut
+C1,r1,imm ~>_r C2,_,mut = C2,r1,imm
+C1,r1,mut ~>_r C2,_,iso = C2,r,mut
+C1,r1,iso ~>_r C2,_,iso = C2,r,mut
+C1,r1,imm ~>_r C2,_,iso = C2,r1,imm
+C1,r1,mut ~>_r C2,_,imm = C2,r1,imm
+C1,r1,iso ~>_r C2,_,imm = C2,r1,imm
+C1,r1,imm ~>_r C2,_,imm = C2,r1,imm
+```
+**[Could be a relational definition to allow for unrestricted r on the right hand side.]**
+
+Extracting viewpoint adaptation
+```
+C1,r1,mut <~_r C2,_,mut = C2,r1,mut
+C1,r1,iso <~_r C2,_,mut = C2,r1,mut
+C1,r1,imm <~_r C2,_,mut = C2,r1,imm
+C1,r1,mut <~_r C2,_,iso = C2,r,iso
+C1,r1,iso <~_r C2,_,iso = C2,r,iso
+C1,r1,imm <~_r C2,_,iso = C2,r1,imm
+C1,r1,mut <~_r C2,_,imm = C2,r1,imm
+C1,r1,iso <~_r C2,_,imm = C2,r1,imm
+C1,r1,imm <~_r C2,_,imm = C2,r1,imm
+```
+
+The most important difference between extracting and aliasing
+viewpoint adaption is how they behave on `iso` fields. Extracting provides an `iso` in the supplied region, and aliasing provides a `mut` in the supplied region.
+
+The definitions take a region parameter so that "freshness" can be suitably defined. 
+
+### Type Rules
+
+### Read versus Write types for a field
+```
+   field_read(tau1 | tau2, f) = field_read(tau1, f) | field_read(tau2, f)
+   field_read(tau1 & tau2, f) = field_read(tau1, f) & field_read(tau2, f)
+   field_write(tau1 | tau2, f) = field_write(tau1, f) & field_write(tau2, f)
+   field_write(tau1 & tau2, f) = field_write(tau1, f) | field_write(tau2, f)   // Need to think about this.
+
+   field_write(tau1 & tau2, f) = field_write(tau1, f) & field_write(tau2, f)   // Need to think about this.
+```
+]
+
+
+
+### Aliasing assignment generates a fresh region
+if it follows an `iso`. If it follows an `imm` then it is in the immutable space, otherwise it is in the same region. 
+
+```
+field_read(f, tau_x) = tau_f
+fresh r
+-------------------------------------
+G |- z = x.f -| G, z: tau_x ->r tau_f
+```
+
+### Extraction uses a fresh region
+```
+G(x) : tau_x
+G(y) : tau_y
+field_write(f, tau_x) = tau_f_w
+field_read(f, tau_x) = tau_f_r
+exists r'. tau_y <: tau_x <~r' tau_f_w
+fresh r
+--------------------------------------
+G |- z = (x.f = y) -| G, z: tau_x <~r tau_f_r
+```
+Is y still accessible?  If it was an iso, then no.  But otherwise, yes.  So remove y, if we can prove it was not an iso?
+
+
+### Method call?
+
+No longer has to invalidate any regions, may consume locals of type `iso`.
+```
+  foo (x: iso&C) {...}
+
+  var y = new C
+  foo (y)
+  foo (y) /// Error `y` was invalidate by previous line.
+```
+
+**[Type rule goes here]**
+
+##  Work required
+
+* Runtime support for delaying reclaimation
+* Runtime support for delaying message send
+* Feasability work for optimisations 
+    - What can we optimise?
+    - What user annotation might we provide?
+    - 
+* Type system implementation 
+* Optimisation
+
+## Concerns
+
+### Additional root sets
+
+Not tracking regions and subregions precisely means we may need to be more careful with codegen for the additional root set.  For instance, we can use have the same region multiple times, which means we use the region additional roots in a globally stack based way.  I.e.
+```
+  r1.add_root(a)
+  r2.add_root(b)
+  ...
+  r1.remove_root(a)
+  ...
+  r2.remove_root(b)
+```
+Is not allowed as if r1 and r2 are the same region, then we will not be following the stack discipline.
+
+**[This may already be the case with cown aliasing, where we don't know if two cowns are the same or different.]**
+
+### Performance
+
+This approach can cause higher memory usage and less concurrency of messages.  This may be bad for performance.
+
+Using compiler optimisations and global analysis could mitigate the default performance by finding cases where messages can be sent promptly.
+
+This however leads to hard to predict performance for the programmer.  We can mitigate this by providing annotations the programmer provides to guarantee certain properties must be true for optimisation, but then we are effectively implementing the complex type system.  This may still be acceptable as the barrier to entry is lower, and the performance work will require a more specialist view.  We can also potentially forbid more in the perf setting, allowing programmers to trade off flexibity of implementation with performance.
+
+A correct design here will take time and experience.
+This proposal can be adopted without resolving this design, but we should be careful not to restrict future optimisations and annotations.
+
+## Optimisations
+
+For this proposal to be successful, it must be possible to optimise code predictably. There are different constraints on optimising deallocation of regions to allowing early message sends.
+
+### Deallocation of regions
+
+Deallocation of regions is easier to optimise, as we can make the semantics less deterministic in the order that regions are deallocated. Consider the following code that creates to regions:
+```
+  var a = new C
+  var b = new C
+  a.f = new D in a
+  b.f = new D in b
+  var y = a.f;
+  drop a
+  drop b
+  // do something with y.
+```
+Now, the `drop a` will need to be delayed as `y` is keeping the region live, but `b` can be dropped instantly.  We can specify in the semantics that no particular order is guaranteed.  We could even extend systematic testing to delay non-deterministically deallocation any time it is valid to do so.
+
+#### Mechanisms for deciding.
+
+* Track potential internal pointers statically through abstract interpretation.
+  *  Keep set of pointers that may point into a particular region, and once that set is empty, can deallocate the region.
+  *  Taint regions, if we ever lose precision on if a region is still live, then mark region to be deallocated at the end of the scope/behaviour.
+* Track internal pointers dynamically.  We already have an additional root set that is used to enable tidy.  This set can be used to specify that there is an internal reference into the region associated to `a`, and once `y` goes away that could be removed.  This set is not expected to track references into sub-regions, but we could delay subregion deallocation further using the same mechanism.
+
+### Message Send
+
+Message send is much more complex as we are not allowed to reorder behaviours
+```
+when (a)
+{
+   // Captures something that is still live due to sub-reference
+}
+when (a)
+{
+  // Does not capture anything.
+}
+```
+It is tempting to immediately dispatch the second `when`, and only dispatch the first once it is safe to do so.  However, this breaks the causality guarantees of the language.
+
+Once we have delayed one `when`, then all subsequent `when`s must be delayed until we can dispatch the first.
+
+We could potentially attempt to track if we are break causality, but that requires us to be able to accurately determine may not alias on cowns:
+```
+when (a)
+{
+   // Captures something that is still live due to sub-reference
+}
+when (b)
+{
+  // Does not capture anything.
+}
+```
+It is sound to dispatch the second before the first, if `a` and `b` are different cowns, but otherwise it is not.
+
+The runtime if any message has been delayed, and if so, all subsequent messages in the behaviour are delayed until the end of the behaviour.  This is the simplist solution, and would probably work well in practice.

That would be an approach but would probably be too expensive to maintain.

mjp41

comment created time in 10 hours

PR closed async-rs/async-log

async stdify

This removes the with clause, making the crate work with async-std out of the box. This should make it substantially easier to setup, and with https://github.com/yoshuawuyts/kv-log-macro it can be used to easily capture rich logs in async environments.

Thanks heaps!

+33 -45

0 comment

4 changed files

yoshuawuyts

pr closed time in 11 hours

startedjlerche/crdt-rs

started time in 11 hours

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

I can understand @jhpratt unwillingness to introduce an unsafe block into the code and thereby unnecessarily affect other platforms than *nix. I personally have been bitten by this issue in production, because, as surmised, I did not handle the error correctly. I would also say however, that it took me by surprise that a patch release would introduce said behaviour for *nix targets (effectively disabling the possibility to obtain the local offset).

Perhaps an update of the documentation that marks the function in question as basically "non-functional" on *nix targets would prevent other users to run into this issue until a fix is found?

puetzp

comment created time in 11 hours

pull request commentrust-lang/stdarch

Avx512bw

r? @Amanieu

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

minybot

comment created time in 12 hours

PR opened rust-lang/stdarch

Avx512bw

shuffle: epi8; test_mask: epi16,epi8; testn_mask: epi16, epi8 store_mask64; store_mask32 _mm512_sad_epu8 movepi16_mask; movepi8_mask; movm: epi8,epi16 load_mask64; load_mask32 kand: mask32,mask64; knot: mask32,mask64; kadd: mask32,mask64 kandn: mask32,mask64; kor: mask32,mask64; kxor: mask32,mask64; kxnor:… dbsad: epu8 cvtepi16_epi8; cvtsepi16_epi8 cvtusepi16_epi8; cvtepi8_epi16; cvtepu8_epi16 bslli_epi128; bsrli_epi128 alignr: epi8

+3493 -1855

0 comment

3 changed files

pr created time in 12 hours

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

Realistically? The odds are damn near zero.

No, we ran into this problem in production environment, but we used chrono instead of time.

puetzp

comment created time in 14 hours

startedAmanieu/parking_lot

started time in 17 hours

more