Zig is an open-source programming language designed for robustness, optimality, and clarity. Zig is aggressively pursuing its goal of overthrowing C as the de facto language for system programming. Zig intends to be so practical that people find themselves using it even if they dislike it.
This is a massive release, featuring 6 months of work and changes from 36 different contributors.
I tried to give credit where credit is due, but it's inevitable I missed some contributions as I had to go through 1,345 commits to type up these release notes. I apologize in advance for any mistakes.
Special thanks to my sponsors who provide financial support. You're making Zig sustainable.
Zig uses LLVM's debug info API to emit native debugging information on all targets. This means that you can use native debugging tools on Zig code, for example:
In addition, Zig's standard library can read its own native debug information. This means that crashes produce stack traces, and errors produce Error Return Traces.
This implementation is able to look at the executable's own memory to find out where the .o files are, which have the DWARF info.
Thanks to Sahnvour for implementing the PE parsing and starting the effort to PDB parsing.
Thanks to Zachary Turner from the LLVM project for helping me understand the PDB format. I still owe LLVM some PDB documentation patches in return.
Similar to MacOS, a Windows executable in memory has location information pointing to a .pdb file which contains debug information.
Linux stack traces worked in 0.2.0. However now {#syntax#}std.debug.dumpStackTrace{#endsyntax#} & friends use {#syntax#}ArenaAllocator{#endsyntax#} backed by
{#syntax#}DirectAllocator{#endsyntax#}. This has the downside of failing to print a stack trace
when the system is out of memory, but for the more common use case when the system is not
out of memory, but the debug info cannot fit in {#syntax#}std.debug.global_allocator{#endsyntax#},
now stack traces will work. This is the case for the self hosted compiler.
There is a proposal to
mmap()
debug info rather than using read()
.
See also Compatibility with Valgrind.
Thanks to Jimmi Holst Christensen's diligent work, the Zig standard library now supports parsing Zig code.
This API is used to implement zig fmt
, a tool that reformats code to fit the
canonical style.
As an example, zig fmt
will change this code:
{#syntax#} test "fmt" { const a = []u8{ 1, 2, // 3, 4, // foo 5, 6, 7 }; switch (0) { 0 => {}, 1 => unreachable, 2, 3 => {}, 4...7 => {}, 1 + 4 * 3 + 22 => {}, else => { const a = 1; const b = a; }, } foo(a, b, c, d, e, f, g,); } {#endsyntax#}
...into this code:
{#syntax#} test "fmt" { const a = []u8{ 1, 2, 3, 4, // foo 5, 6, 7, }; switch (0) { 0 => {}, 1 => unreachable, 2, 3 => {}, 4...7 => {}, 1 + 4 * 3 + 22 => {}, else => { const a = 1; const b = a; }, } foo( a, b, c, d, e, f, g, ); } {#endsyntax#}
It does not make any decisions about line widths. That is left up to the user. However, it follows certain cues about when to line break. For example, it will put the same number of array items in a line as there are in the first one. And it will put a function call all on one line if there is no trailing comma, but break every parameter into its own line if there is a trailing comma.
Thanks to Marc Tiehuis, there are currently two editor plugins that integrate with zig fmt
:
zig fmt
is only implemented in the self-hosted compiler,
which is not finished yet. To use it, one
must follow the README instructions to build the self-hosted compiler from source.
The implementation of the self-hosted parser is an interesting case study of avoiding recursion by using an explicit stack. It is essentially a hand-written recursive descent parser, but with heap allocations instead of recursion. When Jimmi originally implemented the code, we thought that we could not solve the unbounded stack growth problem of recursion. However, since then, I prototyped several solutions that provide the ability to have recursive function calls without giving up statically known upper bound stack growth. See Recursion Status for more details.
Automatic formatting can be disabled in source files with a comment like this:
{#syntax#} // zig fmt: off test "this is left alone" { } // zig fmt: on {#endsyntax#}
zig fmt
is written using the standard library's event-based I/O abstractions and
{#syntax#}async{#endsyntax#}/{#syntax#}await{#endsyntax#} syntax, which means that it is
multi-threaded with non-blocking I/O. A debug build of zig fmt
on my laptop
formats the entire Zig standard library in 2.1 seconds, which is 75,516 lines per second.
See Concurrency Status for more details.
zig run file.zig
can now be used to execute a file directly.
Thanks to Marc Tiehuis for the initial implementation of this feature. Marc writes:
On a POSIX system, a shebang can be used to run a zig file directly. An
example shebang would be #!/usr/bin/zig run
. You may not be able pass
extra compile arguments currently as part of the shebang. Linux for example
treats all arguments after the first as a single argument which will result
in an 'invalid command'.
Note: there is a proposal
to change this to zig file.zig
to match the interface of other languages,
as well as enable the common pattern #!/usr/bin/env zig
.
Zig caches the binary generated by zig run
so that subsequent invocations have low
startup cost. See Build Artifact Caching for more details.
Zig now supports building statically against musl libc.
On every master branch push, the continuous integration server creates a static Linux build of zig
and updates the URL https://ziglang.org/builds/zig-linux-x86_64-master.tar.xz
to redirect to it.
In addition, Zig now looks for libc and the Zig standard library at runtime. This makes static builds the easiest and most reliable way to start using the latest version of Zig immediately.
Windows has automated static builds of master branch via AppVeyor.
MacOS static CI builds are in progress and should be available soon.
During this release cycle, two design flaws were fixed, which led to a chain reaction of changes that I called Pointer Reform, resulting in a more consistent syntax with simpler semantics.
The first design flaw was that the syntax for pointers was ambiguous if the pointed to type was a {#syntax#}type{#endsyntax#}. Consider this 0.2.0 code:
{#syntax#} const assert = @import("std").debug.assert; comptime { var a: i32 = 1; const b = &a; @compileLog(@typeOf(b)); *b = 2; assert(a == 2); } {#endsyntax#}
This works fine. The value printed from the {#syntax#}@compileLog{#endsyntax#} statement is {#syntax#}&i32{#endsyntax#}. This makes sense because {#syntax#}b{#endsyntax#} is a pointer to {#syntax#}a{#endsyntax#}.
Now let's do it with a {#syntax#}type{#endsyntax#}:
{#syntax#} const assert = @import("std").debug.assert; comptime { var a: type = i32; const b = &a; @compileLog(b); *b = f32; assert(a == f32); } {#endsyntax#}
$ zig build-obj test.zig
| &i32
test.zig:6:5: error: found compile log statement
@compileLog(b);
^
test.zig:7:5: error: attempt to dereference non-pointer type 'type'
*b = f32;
^
It doesn't work in 0.2.0, because the {#syntax#}&{#endsyntax#} operator worked differently for {#syntax#}type{#endsyntax#} than other types. Here, {#syntax#}b{#endsyntax#} is the type {#syntax#}&i32{#endsyntax#} instead of a pointer to a type which is how we wanted to use it.
This prevented other things from working too; for example if you had a {#syntax#}[]type{i32, u8, f64}{#endsyntax#} and you tried to use a for loop, it crashed the compiler because internally a for loop uses the {#syntax#}&{#endsyntax#} operator on the array element.
The only reasonable solution to this is to have different syntax for the address-of operator and the pointer operator, rather than them both being {#syntax#}&{#endsyntax#}.
So pointer syntax becomes {#syntax#}*T{#endsyntax#}, matching syntax from most other languages such as C. Address-of syntax remains {#syntax#}&foo{#endsyntax#}, again matching common address-of syntax such as in C. This leaves one problem though.
With this modification, the syntax {#syntax#}*foo{#endsyntax#} becomes ambiguous with the syntax for dereferencing. And so dereferencing syntax is changed to a postfix operator: {#syntax#}foo.*{#endsyntax#}. This matches post-fix indexing syntax: {#syntax#}foo[0]{#endsyntax#}, and in practice ends up harmonizing nicely with other postfix operators.
The other design flaw is a problem that has plagued C since its creation: the pointer type doesn't tell you how many items there are at the address. This is now fixed by having two kinds of pointers in Zig:
Note that this causes pointers to arrays to fall into place, as a single-item pointer to an array acts as a pointer to a compile-time known number of items:
Consider how slices fit into this picture:
This makes Zig pointers significantly less error prone. For example, it fixed issue #386, which demonstrates how a pointer to an array in Zig 0.2.0 is a footgun when passed as a parameter. Meanwhile in 0.3.0, equivalent code is nearly impossible to get wrong.
For consistency with the postfix pointer dereference operator, optional unwrapping syntax is now postfix as well:
0.2.0: ??x
0.3.0: {#syntax#}x.?{#endsyntax#}
And finally, to remove the last inconsistency of optional syntax, the ??
operator
is now the keyword {#syntax#}orelse{#endsyntax#}. This means that Zig now has the property that
all control flow occurs exclusively via keywords.
There is a plan for one more pointer type,
which is a pointer that has a null-terminated
number of items. This would be the type of the parameter to strlen
for example.
Although this will make the language bigger by adding a new type, it allows Zig to delete a feature
in exchange, since it will make
C string literals unnecessary.
String literals will both have a compile-time known length and be null-terminated; therefore they
will implicitly cast to
slices as well as null-terminated pointers.
There is one new issue caused by Pointer Reform. Because C does not have the concept of single-item pointers or unknown-length pointers (or non-null pointers), Zig must translate all C pointers as {#syntax#}?[*]T{#endsyntax#}. That is, a pointer to an unknown number of items that might be null. This can cause some friction when using C APIs, which is unfortunate because Zig's types are perfectly compatible with C's types, but .h files are unable to adequately describe pointers. Although it would be much safer to translate .h files offline and fix their prototypes, there is a proposal to add a C pointer type. This new pointer type should never be used on purpose, but would be used when auto-translating C code. It would simply have C pointer semantics, which means it would be just as much of a footgun as C pointers are. The upside is that it would make interaction with C APIs go back to being perfectly seamless.
In response to an overwhelming consensus, floating point operations use Strict mode by default. Code can use @setFloatMode to override the mode on a per-scope basis.
Thanks to Marc Tiehuis for implementing the change.
this
was always a weird language feature. An identifier which referred to the thing in the
most immediate scope, which could be a module, a type, a function, or even a block of code.
The main use case for it was for anonymous structs to refer to themselves. This use case is solved with a new builtin function, @This(), which always returns the innermost struct or union that the builtin call is inside.
The "block of code" type is removed from Zig, and the first argument of @setFloatMode is removed. {#syntax#}@setFloatMode{#endsyntax#} now always refers to the current scope.
Previously, these two lines would have different meanings:
{#syntax#} export fn foo(x: u32) void { const a: u8 = x; const b = u8(x); } {#endsyntax#}
The assignment to {#syntax#}a{#endsyntax#} would give error: expected type 'u8', found 'u32'
,
because not all values of {#syntax#}u32{#endsyntax#} can fit in a {#syntax#}u8{#endsyntax#}. But the
assignment to {#syntax#}b{#endsyntax#} was "cast harder" syntax, and Zig would truncate bits,
with a safety check to ensure that the mathematical meaning of the integer was preserved.
Now, both lines are identical in semantics. There is no more "cast harder" syntax. Both cause the compile error because implicit casts are only allowed when it is completely unambiguous how to get from one type to another, and the transformation is guaranteed to be safe. For other casts, Zig has builtin functions:
Some are safe; some are not. Some perform language-level assertions; some do not. Some are no-ops at runtime; some are not. Each casting function is documented independently.
Having explicit and fine-grained casting like this is a form of intentional redundancy. Casts are often the source of bugs, and therefore it is worth double-checking a cast to verify that it is still correct when the type of the operand changes. For example, imagine that we have the following code:
{#syntax#} fn foo(x: i32) void { var i = @intCast(usize, x); } {#endsyntax#}
Now consider what happens when the type of {#syntax#}x{#endsyntax#} changes to a pointer:
test.zig:2:29: error: expected integer type, found '*i32'
var i = @intCast(usize, x);
^
Although we technically know how to convert a pointer to an integer,
because we used {#syntax#}@intCast{#endsyntax#}, we are forced to inspect the cast and change
it appropriately. Perhaps that means changing it to {#syntax#}@ptrToInt{#endsyntax#}, or perhaps
the entire function needs to be reworked in response to the type change.
Previously, it was illegal to pass structs and unions by value in non-{#syntax#}extern{#endsyntax#} functions. Instead, one would have to have the function accept a {#syntax#}const{#endsyntax#} pointer parameter. This was to avoid the ambiguity that C programs face - having to make the decision about whether by-value or by-reference was better. However, there were some problems with this. For example, when the parameter type is inferred, Zig would automatically convert to a {#syntax#}const{#endsyntax#} pointer. This caused problems in generic code, which could not distinguish between a type which is a pointer, and a type which has been automatically converted to a pointer.
Now, parameters can be passed directly:
{#syntax#} const assert = @import("std").debug.assert; const Foo = struct { x: i32, y: i32, }; fn callee(foo: Foo) void { assert(foo.y == 2); } test "pass directly" { callee(Foo{ .x = 1, .y = 2 }); } {#endsyntax#}
I have avoided using the term "by-value" because the semantics of this kind of parameter passing are different:
Because of these semantics, there's a clear flow chart for whether to accept a parameter as {#syntax#}T{#endsyntax#} or {#syntax#}*const T{#endsyntax#}:
Now that we have this kind of parameter passing, Zig's implicit cast from {#syntax#}T{#endsyntax#} to {#syntax#}*const T{#endsyntax#} is less important. One might even make the case that such a cast is dangerous. Therefore we have a proposal to remove it.
There is one more area that needs consideration with regards to direct parameter passing, and that is with coroutines. The problem is that if a reference to a stack variable is passed to a coroutine, it may become invalid after the coroutine suspends. This is a design flaw in Zig that will be addressed in a future version. See Concurrency Status for more details.
Note that {#syntax#}extern{#endsyntax#} functions are bound by the C ABI, and therefore none of this applies to them.
Marc Tiehuis writes:
We now use a generic Rand structure which abstracts the core functions from the backing engine.
The old Mersenne Twister engine is removed and replaced instead with three alternatives:
These should provide sufficient coverage for most purposes, including a
CSPRNG using Isaac64. Consumers of the library that do not care about
the actual engine implementation should use DefaultPrng
and DefaultCsprng
.
One of the problems with non-blocking programming is that stack traces and exceptions are less useful, because the actual stack trace points back to the event loop code.
In Zig 0.3.0, Error Return Traces work across suspend points. This means you can use {#syntax#}try{#endsyntax#} as the main error handling strategy, and when an error bubbles up all the way, you'll still be able to find out where it came from:
{#syntax#} const std = @import("std"); const event = std.event; const fs = event.fs; test "unwrap error in async fn" { var da = std.heap.DirectAllocator.init(); defer da.deinit(); const allocator = &da.allocator; var loop: event.Loop = undefined; try loop.initMultiThreaded(allocator); defer loop.deinit(); const handle = try asyncopenTheFile(&loop); defer cancel handle; loop.run(); } async fn openTheFile(loop: *event.Loop) void { const future = (async fs.openRead(loop, "does_not_exist.txt") catch unreachable); const fd = (await future) catch unreachable; } {#endsyntax#}
$ zig test test.zig
Test 1/1 unwrap error in async fn...attempt to unwrap error: FileNotFound
std/event/fs.zig:367:5: 0x22cb15 in ??? (test)
return req_node.data.msg.Open.result;
^
std/event/fs.zig:374:13: 0x22e5fc in ??? (test)
return await (async openPosix(loop, path, flags, os.File.default_mode) catch unreachable);
^
test.zig:22:31: 0x22f34b in ??? (test)
const fd = (await future) catch unreachable;
^
std/event/loop.zig:664:25: 0x20c147 in ??? (test)
resume handle;
^
std/event/loop.zig:543:23: 0x206dee in ??? (test)
self.workerRun();
^
test.zig:17:13: 0x206178 in ??? (test)
loop.run();
^
Tests failed. Use the following command to reproduce the failure:
zig-cache/test
Note that this output contains 3 components:
attempt to unwrap error: FileNotFound
fs.zig:367:5
and then returned at fs.zig:374:13
. You could go look at those source locations
for more information.openRead
, the code tried to
{#syntax#}catch unreachable{#endsyntax#} which caused the panic. You can see that the stack
trace does, in fact, go into the event loop as described above.
It is important to note in this example, that the error return trace survived despite the fact that the event loop is multi-threaded, and any one of those threads could be the worker thread that resumes an async function at the {#syntax#}await{#endsyntax#} point.
This feature is enabled by default for Debug and ReleaseSafe builds, and disabled for ReleaseFast and ReleaseSmall builds.
This is just the beginning of an exploration of what debugging non-blocking behavior could look like in the future of Zig. See Concurrency Status for more details.
Instead of async(allocator) call()
, now it is
async<allocator> call()
.
This fixes syntax ambiguity when leaving off the allocator, and fixes parse failure when call is a field access.
This sets a precedent for using <
>
to pass arguments
to a keyword. This will affect enum
, union
, fn
, and
align
(see #661).
Alexandros Naskos contributed a new build mode.
$ zig build-exe example.zig --release-small
Alexandros Naskos bravely dove head-first into the deepest, darkest parts of the Zig compiler and implemented an incredibly useful builtin function: @typeInfo.
This function accepts a {#syntax#}type{#endsyntax#} as a parameter, and returns a compile-time known value of this type:
{#syntax#} pub const TypeInfo = union(TypeId) { Type: void, Void: void, Bool: void, NoReturn: void, Int: Int, Float: Float, Pointer: Pointer, Array: Array, Struct: Struct, ComptimeFloat: void, ComptimeInt: void, Undefined: void, Null: void, Optional: Optional, ErrorUnion: ErrorUnion, ErrorSet: ErrorSet, Enum: Enum, Union: Union, Fn: Fn, Namespace: void, BoundFn: Fn, ArgTuple: void, Opaque: void, Promise: Promise, pub const Int = struct { is_signed: bool, bits: u8, }; pub const Float = struct { bits: u8, }; pub const Pointer = struct { size: Size, is_const: bool, is_volatile: bool, alignment: u32, child: type, pub const Size = enum { One, Many, Slice, }; }; pub const Array = struct { len: usize, child: type, }; pub const ContainerLayout = enum { Auto, Extern, Packed, }; pub const StructField = struct { name: []const u8, offset: ?usize, field_type: type, }; pub const Struct = struct { layout: ContainerLayout, fields: []StructField, defs: []Definition, }; pub const Optional = struct { child: type, }; pub const ErrorUnion = struct { error_set: type, payload: type, }; pub const Error = struct { name: []const u8, value: usize, }; pub const ErrorSet = struct { errors: []Error, }; pub const EnumField = struct { name: []const u8, value: usize, }; pub const Enum = struct { layout: ContainerLayout, tag_type: type, fields: []EnumField, defs: []Definition, }; pub const UnionField = struct { name: []const u8, enum_field: ?EnumField, field_type: type, }; pub const Union = struct { layout: ContainerLayout, tag_type: ?type, fields: []UnionField, defs: []Definition, }; pub const CallingConvention = enum { Unspecified, C, Cold, Naked, Stdcall, Async, }; pub const FnArg = struct { is_generic: bool, is_noalias: bool, arg_type: ?type, }; pub const Fn = struct { calling_convention: CallingConvention, is_generic: bool, is_var_args: bool, return_type: ?type, async_allocator_type: ?type, args: []FnArg, }; pub const Promise = struct { child: ?type, }; pub const Definition = struct { name: []const u8, is_pub: bool, data: Data, pub const Data = union(enum) { Type: type, Var: type, Fn: FnDef, pub const FnDef = struct { fn_type: type, inline_type: Inline, calling_convention: CallingConvention, is_var_args: bool, is_extern: bool, is_export: bool, lib_name: ?[]const u8, return_type: type, arg_names: [][] const u8, pub const Inline = enum { Auto, Always, Never, }; }; }; }; }; {#endsyntax#}
This kicks open the door for compile-time reflection, especially when combined with the fact that Jimmi Holst Christensen implemented @field, which performs field access with a compile-time known name:
{#syntax#} const std = @import("std"); const assert = std.debug.assert; test "@field" { const Foo = struct { one: i32, two: bool, }; var f = Foo{ .one = 42, .two = true, }; const names = [][]const u8{ "two", "one" }; assert(@field(f, names[0]) == true); assert(@field(f, names[1]) == 42); @field(f, "one") += 1; assert(@field(f, "on" ++ "e") == 43); } {#endsyntax#}
This has the potential to be abused, and so the feature should be used carefully.
After Jimmi implemented {#syntax#}@field{#endsyntax#}, he improved the implementation of {#syntax#}@typeInfo{#endsyntax#} and fixed several bugs. And now, the combination of these builtins is used to implement struct printing in userland:
{#syntax#} const std = @import("std"); const Foo = struct { one: i32, two: *u64, three: bool, }; pub fn main() void { var x: u64 = 1234; var f = Foo{ .one = 42, .two = &x, .three = false, }; std.debug.warn("here it is: {}\n", f); } {#endsyntax#}
Output:
here it is: Foo{ .one = 42, .two = u64@7ffdda208cf0, .three = false }
See std/fmt/index.zig:15 for the implementation.
Now that we have {#syntax#}@typeInfo{#endsyntax#}, there is one more question to answer: should there be a function which accepts a {#syntax#}TypeInfo{#endsyntax#} value, and makes a type out of it?
This hypothetical feature is called @reify
, and it's a
hot topic. Although undeniably powerful and
useful, there is concern that it would be too powerful, leading to complex meta-programming
that goes against the spirit of simplicity that Zig stands for.
@cmpxchg
is removed. @cmpxchgStrong and @cmpxchgWeak are added.
The functions have operand type as the first parameter.
The return type is ?T
where T
is the operand type.
Ben Noordhuis implemented {#syntax#}f16{#endsyntax#}. This is guaranteed to be
IEEE-754-2008 binary16 format, even on systems that have no hardware support,
thanks to the additions to compiler_rt that Ben contributed. He also added support
for {#syntax#}f16{#endsyntax#} to std.math
functions such as isnormal
and fabs
.
Zig 0.2.0 had primitive types for integer bit widths of 2-8, 16, 29, 32, 64, 128. Any number other than that, and you had to use @IntType to create the type. But you would get a compile error if you shadowed one of the above bit widths that already existed, for example with
{#syntax#} const u29 = @IntType(false, 29); // error: u29 shadows primitive type {#endsyntax#}
Needless to say, this situation was unnecessarily troublesome (#745). And so now
arbitrary bit-width integers can be referenced by using an identifier of
i
or u
followed by digits. For example, the identifier
{#syntax#}i7{#endsyntax#} refers to a signed 7-bit integer.
{#syntax#}u0{#endsyntax#} is a 0-bit type, which means:
{#syntax#}i0{#endsyntax#} doesn't make sense and will probably crash the compiler.
Although Zig defines arbitrary integer sizes to support all primitive operations, if you try to use, for example, multiplication on 256-bit integers:
{#syntax#} test "large multiplication" { var x: u256 = 0xabcd; var y: u256 = 0xefef; var z = x * y; } {#endsyntax#}
Then you'll get an error like this:
LLVM ERROR: Unsupported library call operation!
Zig isn't supposed to be letting LLVM leak through here, but that's a separate issue. What's happening is that normally if a primitive operation such as multiplication of integers cannot be lowered to a machine instruction, LLVM will emit a library call to compiler_rt to perform the operation. This works for up to 128-bit multiplication, for example. However compiler_rt does not define an arbitrary precision multiplication library function, and so LLVM is not able to generate code.
It is planned to submit a patch to LLVM which adds the ability to emit a lib call for situations like this, and then Zig will include the arbitrary precision multiplication function in Zig's compiler_rt.
In addition to this, Zig 0.3.0 fixes a bug where {#syntax#}@IntType{#endsyntax#} was silently wrapping the bit count parameter if it was greater than pow(2, 32).
Marc Tiehuis & Ben Noordhuis solved the various issues that prevented f128
from being generally useful.
f128
. -Marc Tiehuis
__floatunditf
__floatunsitf
__floatunsitf
__floatuntitf
__floatuntisf
__trunctfdf2
__trunctfsf2
__floattitf
__floattidf
__floattisf
Zig now supports global build artifact caching. This feature is one of those things that you can generally ignore, because it "just works" without any babysitting.
By default, compilations are not cached. You can enable the global cache for a compilation
by using --cache on
:
andy@xps:~/tmp$ time zig build-exe hello.zig
real 0m0.414s
user 0m0.369s
sys 0m0.049s
andy@xps:~/tmp$ time zig build-exe hello.zig --cache on
/home/andy/.local/share/zig/stage1/artifact/hkGO0PyaOKDrdg2wyhV1vRy0ATyTaT0s0ECa2BiHFJfsb9RDVKK_r3qwHI5gaEfv/hello
real 0m0.412s
user 0m0.377s
sys 0m0.038s
andy@xps:~/tmp$ time zig build-exe hello.zig --cache on
/home/andy/.local/share/zig/stage1/artifact/hkGO0PyaOKDrdg2wyhV1vRy0ATyTaT0s0ECa2BiHFJfsb9RDVKK_r3qwHI5gaEfv/hello
real 0m0.012s
user 0m0.009s
sys 0m0.003s
When the cache is on, the output is not written to the current directory. Instead, the output is kept in the cache directory, and the path to it is printed to stdout.
This is off by default, because this is an uncommon use case. The real benefit of build artifact caching comes in 3 places:
andy@xps:~/tmp$ time zig run hello.zig
Hello, world!
real 0m0.553s
user 0m0.500s
sys 0m0.055s
andy@xps:~/tmp$ time zig run hello.zig
Hello, world!
real 0m0.013s
user 0m0.007s
sys 0m0.006s
compiler_rt.o
and
builtin.o
from source, for the given target. This usually only has to be done
once ever, which is why other compilers such as gcc ship with these components already built.
The problem with that strategy is that you have to build a special version of the compiler for
cross-compiling. With Zig, you can always build for any target, on any target.
The cache is perfect; there are no false positives. You could even fix a bug in memcpy
in the system's libc, and Zig will detect that its own code has (indirectly) been updated,
and invalidate the cache entry.
If you use zig build-exe
, Zig will still create a zig-cache
directory
in the current working directory in order to store an intermediate .o
file.
This is because on MacOS, the intermediate .o file stores the debug information, and therefore
it needs to stick around somewhere sensible for Stack Traces to work.
Likewise, if you use zig test
, Zig will put the test binary in the zig-cache
directory in the current working directory. It's useful to leave the test binary here so that the
programmer can use a debugger on it or otherwise inspect it.
The zig-cache
directory is cleaner than before, however. For example, the
builtin.zig
file is no longer created there. It participates in the global caching system,
just like compiler_rt.o
. You can use zig builtin
to see the contents of
{#syntax#}@import("builtin"){#endsyntax#}.
I noticed that valgrind does not see Zig's debug symbols (#896):
{#syntax#} pub fn main() void { foo().* += 1; } fn foo() *i32 { return @intToPtr(*i32, 10000000); } {#endsyntax#}
==24133== Invalid read of size 4
==24133== at 0x2226D5: ??? (in /home/andy/downloads/zig/build/test)
==24133== by 0x2226A8: ??? (in /home/andy/downloads/zig/build/test)
==24133== by 0x222654: ??? (in /home/andy/downloads/zig/build/test)
==24133== by 0x2224B7: ??? (in /home/andy/downloads/zig/build/test)
==24133== by 0x22236F: ??? (in /home/andy/downloads/zig/build/test)
After digging around, I was able to reproduce the problem using only Clang and LLD:
static int *foo(void) {
return (int *)10000000;
}
int main(void) {
int *x = foo();
*x += 1;
}
If this C code is built with Clang and linked with LLD, Valgrind has the same issue as with the Zig code.
I sent a message to the Valgrind mailing list, and they suggested submitting a bug fix to Valgrind. That's a good idea. I'm a little busy with Zig development though - anybody else want to take a crack at it?
In the meantime, Zig now has a --no-rosegment
flag, which works around the bug.
It should only be used for this purpose; the flag will likely be removed once Valgrind fixes
the issue upstream and enough time passes that the new version becomes generally available.
$ zig build-exe test.zig --no-rosegment
$ valgrind ./test
==24241== Invalid read of size 4
==24241== at 0x221FE5: main (test.zig:2)
Marc Tiehuis added Zig support, and then worked with the Compiler Explorer team to get it merged upstream and deployed.
The command line API that Compiler Explorer uses is covered by Zig's main test suite to ensure that it continues working as the language evolves.
zig init-lib
can be used to initialize a
zig build
project in the current directory which will create a simple library:
$ zig init-lib Created build.zig Created src/main.zig Next, try `zig build --help` or `zig build test` $ zig build test Test 1/1 basic add functionality...OK All tests passed.

The main Zig test suite tests this functionality so that it will not regress as Zig continues to evolve.
Concurrency is now solved. That is, there is a concrete plan for how concurrency will work in Zig, and now it's a matter of implementing all the pieces.
First and foremost, Zig supports low-level control over hardware. That means that it has atomic primitives:
...and it means that you can directly spawn kernel threads using standard library functions:
{#syntax#} const std = @import("std"); const assert = std.debug.assert; const builtin = @import("builtin"); const AtomicRmwOp = builtin.AtomicRmwOp; const AtomicOrder = builtin.AtomicOrder; test "spawn threads" { var shared_ctx: i32 = 1; const thread1 = try std.os.spawnThread({}, start1); const thread2 = try std.os.spawnThread(&shared_ctx, start2); const thread3 = try std.os.spawnThread(&shared_ctx, start2); const thread4 = try std.os.spawnThread(&shared_ctx, start2); thread1.wait(); thread2.wait(); thread3.wait(); thread4.wait(); assert(shared_ctx == 4); } fn start1(ctx: void) u8 { return 0; } fn start2(ctx: *i32) u8 { _ = @atomicRmw(i32, ctx, AtomicRmwOp.Add, 1, AtomicOrder.SeqCst); return 0; } {#endsyntax#}
On POSIX targets, when you link against libc, the standard library uses pthreads; otherwise it uses its own lightweight kernel thread implementation.
You can use mutexes, signals, condition variables, and all those things. Anything you can accomplish in C, you can accomplish in Zig.
However, the standard library provides a higher level concurrency abstraction, designed for optimal performance, debuggability, and structuring code to closely model the problems that concurrency presents.
The abstraction is built on two language features: stackless coroutines and {#syntax#}async{#endsyntax#}/{#syntax#}await{#endsyntax#} syntax. Everything else is implemented in userland.
{#syntax#}std.event.Loop{#endsyntax#} creates a kernel thread pool matching the number of logical CPUs. It can then be used for non-blocking I/O that will be dispatched across the thread pool, using the platform-native API:
This is a competitor to libuv, except multi-threaded.
Once you have an event loop, all of the {#syntax#}std.event{#endsyntax#} API becomes available to use:
All of these abstractions provide convenient APIs based on {#syntax#}async{#endsyntax#}/{#syntax#}await{#endsyntax#} syntax, making it practical for API users to model their code with maximally efficient concurrency. None of these abstractions block or use mutexes; when an API user must suspend, control flow goes to the next coroutine waiting to run, if any. If no coroutines are waiting to run, the application will sit idly, waiting for an event from the respective platform-native API (e.g. epoll on Linux).
As an example, here is a snippet from a test in the standard library:
{#syntax#} async fn testFsWatch(loop: *Loop) !void { const file_path = try os.path.join(loop.allocator, test_tmp_dir, "file.txt"); defer loop.allocator.free(file_path); const contents = \\line 1 \\line 2 ; const line2_offset = 7; // first just write then read the file try await try async fs.writeFile(loop, file_path, contents); const read_contents = try await try async fs.readFile(loop, file_path, 1024 * 1024); assert(mem.eql(u8, read_contents, contents)); // now watch the file var watch = try fs.Watch(void).create(loop, 0); defer watch.destroy(); assert((try await try async watch.addFile(file_path, {})) == null); const ev = try async watch.channel.get(); var ev_consumed = false; defer if (!ev_consumed) cancel ev; // overwrite line 2 const fd = try await try async fs.openReadWrite(loop, file_path, os.File.default_mode); { defer os.close(fd); try await try async fs.pwritev(loop, fd, [][]const u8{"lorem ipsum"}, line2_offset); } ev_consumed = true; switch ((try await ev).id) { WatchEventId.CloseWrite => {}, WatchEventId.Delete => @panic("wrong event"), } const contents_updated = try await try async fs.readFile(loop, file_path, 1024 * 1024); assert(mem.eql(u8, contents_updated, \\line 1 \\lorem ipsum )); } {#endsyntax#}
You can see that even though Zig is a language with manual memory management that insists on handling every possible error, it manages to be quite high level using these event-based APIs.
Now, there are some problems to solve:
And so, the plan is to rework coroutines, without using any of LLVM's coroutines API. Zig will implement coroutines in the frontend, and LLVM will see only functions and structs. This is how Rust does it, and I think it was a strong choice.
The coroutine frame will be in a struct, and so Zig will know the size of it at compile-time, and it will solve the problem of guaranteeing allocation elision - the {#syntax#}async{#endsyntax#} callsite will simply have to provide the coroutine frame pointer in order to create the promise.
This will also be relevant for recursion; stackless function calls do not count against the static stack size upper bound calculation. See Recursion Status for more details.
The self-hosted compiler is well underway. Here's a 1 minute demo of the self-hosted compiler watching source files and rebuilding.
The self-hosted compiler cannot do much more than Hello World at the moment, but it's being constructed from the ground up to fully take advantage of multiple cores and in-memory caching. In addition, Zig's error system and other safety features are making it easy to write reliable, robust code. Between stack traces, error return traces, and runtime safety checks, I barely even need a debugger.
Marc Tiehuis contributed a Big Integer library, which the self-hosted compiler is using for integer literals and compile-time math operations.
Writing the self-hosted compiler code revealed to me how coroutines should work in Zig. All the little details and ergonomics are clear to me now. And so before I continue any further on the self-hosted compiler, I will use this knowledge to rework coroutines and solve the problems with them. See Concurrency Status for more details.
As a reminder, even when the self-hosted compiler is complete, Zig will forever be stuck with the stage1 C++ compiler code. See The Grand Bootstrapping Plan for more details.
The self-hosted compiler is successfully sharing some C++ code with the stage1 compiler. For example the libLLVM C++ API wrapper is built into a static library, which then exports a C API wrapper. The self-hosted compiler links against this static library in order to make libLLVM C++ API calls via the C API wrapper. In addition, the Microsoft Visual Studio detection code requires the Windows COM API, which is also C++, and so a similar strategy is used. I think it's pretty neat that the build system builds a static library once and then ends up linking against it twice - one for each of the two compiler stages!
I've said before that recursion is one of the enemies of perfect software, because it represents a way that a program can fail with no foolproof way of preventing it. With recursion, pick any stack size and I'll give you an input that will crash your program. Embedded developers are all too familiar with this problem.
It's always possible to rewrite code using an explicit stack using heap allocations, and that's exactly what Jimmi did in the self-hosted parser.
On the other hand, when recursion fits the problem, it's significantly more clear and maintainable. It would be a real shame to have to give it up.
I researched different ways that Zig could keep recursion, even when we introduce statically known stack upper bound size. I came up with a proof of concept for @newStackCall, a builtin function that calls a function using an explicitly provided new stack. You can find a usage example in the documentation by following that link.
This works, and it does break call graph cycles, but it would be a little bit awkward to use. Because if you allocate an entire new stack, it has to be big enough for the rest of the stack upper bound size, but in a recursive call, which should be only one stack frame, it would overallocate every time.
So that's why I think that the actual solution to this problem is Zig's stackless coroutines. Because Zig's coroutines are stackless, they are the perfect solution for recursion (direct or indirect). With the reworking of coroutines, it will be possible to put the coroutine frame of an async function anywhere - in a struct, in the stack, in a global variable - as long as it outlives the duration of the coroutine. See Concurrency for more details.
Although recursion is not yet solved, we know enough to know that recursion is OK to use in Zig. It does suffer from the stack overflow issue today, but in the future we will have a compile error to prevent call graph cycles. And then this hypothetical compile error will be solved by using {#syntax#}@newStackCall{#endsyntax#} or stackless functions (but probably stackless functions). Once recursion is solved, if stackless functions turn out to be the better solution, Zig will remove {#syntax#}@newStackCall{#endsyntax#} from the language, unless someone demonstrates a compelling use case for it.
For now, use recursion whenever you want; you'll know when it's time to update your code.
The pieces for web assembly are starting to come together.
Ben Noordhuis fixed support for --target-arch wasm32
(#1094).
LLVM merged my patch to make WebAssembly a normal (non-experimental) target. But they didn't do it before the LLVM 7 release. So Zig 0.3.0 will not have WebAssembly support by default, but 0.4.0 will.
That being said, the static builds of Zig provided by ziglang.org have the WebAssembly target enabled.
Apart from this, there appears to be an issue with Zig's WebAssembly linker. Once this is solved, all that is left is to use WebAssembly in real life use cases, to work out the ergonomics, and solve the inevitable issues that arise.
The language reference documentation now contains no JavaScript. The code blocks
are pre-formatted with std.zig.Tokenizer
. The same is true for these
release notes.
The builtin.zig
example code in the documentation is now automatically updated from
the output of Zig, so the docs can't get out of date for this.
In addition to the above, the following improvements were made to the documentation:
std.mem.Allocator
functions.std.mem.SplitIterator
is now publicstd.math.atan2
is now publicstd.os.linux
now makes public all the syscall numbers and syscall functionsstd.math.cast
handles signed integersstd.zig.parse
std.zig.parseStringLiteral
std.zig.render
std.zig.ast
std.zig.Token
std.zig.Tokenizer
std.io.readLine
File.exists
with File.access
. -Marc Tiehuisstd.rand.Rand
to std.rand.Random
std.os.time.sleep
std.os.time.posixSleep
std.os.time.timestamp
std.os.time.miliTimestamp
std.os.time.Timer
std.math.complex.Complex
std.math.complex.abs
std.math.complex.acos
std.math.complex.acosh
std.math.complex.arg
std.math.complex.asin
std.math.complex.asinh
std.math.complex.atan
std.math.complex.atanh
std.math.complex.conj
std.math.complex.cos
std.math.complex.cosh
std.math.complex.exp
std.math.complex.log
std.math.complex.pow
std.math.complex.proj
std.math.complex.sinh
std.math.complex.sin
std.math.complex.sqrt
std.math.complex.tanh
std.math.complex.tan
std.math.complex.ldexp_cexp
std.mem.trimLeft
std.mem.trimRight
std.mem.trimRight
std.mem.lastIndexOfScalar
std.mem.lastIndexOfAny
std.mem.lastIndexOf
std.mem.endsWith
std.atomic.Stack
std.atomic.Queue
std.os.spawnThread
. It works on all targets. On Linux, when linking libc, it uses pthreads, and when not linking libc, it makes syscalls directly.std.json.Token
std.json.StreamingParser
std.json.TokenStream
std.json.validate
std.json.ValueTree
std.json.ObjectMap
std.json.Value
std.json.Parser
- A non-stream JSON parser which constructs a tree of Value's.std.SegmentedList
std.Buffer
. Instead users should use std.io.BufferOutStream
.
std.Buffer.appendFormat
std.Buffer.appendByte
std.Buffer.appendByteNTimes
std.math.big.Int
std.math.big.Limb
std.math.big.DoubleLimb
std.math.big.Log2Limb
std.os.Dir
gains Windows support.std.os.File.access
no longer depends on shlwapi.dll on Windows.std.os.path.dirname
returns null instead of empty slice when there
is no directory component. This makes it harder to write bugs. (#1017)
error.IsDir
.std.math.floatMantissaBits
and std.math.floatExponentBits
-Marc Tiehuisstd.mem.Allocator
allows allocation of any 0 sized type, not just void
. -Jimmi Holst Christensen.std.os.cpuCount
std.sort.asc
and std.sort.desc
-Marc Tiehuisstd.fmt.format
add *
for formatting things as pointers. (#1285)std.fmt.format
add integer binary output format. -Marc Tiehuis (#1313)std.mem.secureZero
. -Marc Tiehuis
mem.set(u8, slice, 0)
except that it will never
be optimized out by the compiler. Intended usage is for clearing
secret data.
@intToPtr
, @ptrToInt
to get around
known data dependencies but I could not work it out right now.
std.fmt.format
handles non-pointer struct/union/enums. Adds support for printing structs
via reflection. (#1380)std.os
file functions no longer require an allocator. They rely on
PATH_MAX
, because even Windows, Linux, and MacOS syscalls will fail for paths longer
than PATH_MAX
.std.crypto.chaCha20IETF
and std.crypto.chaCha20With64BitNonce
. -Shawn Landden & Marc TiehuisZig: Poly1305: 1423 MiB/s X25519: 8671 exchanges per second Monocypher: Poly1305: 1567 MiB/s X25519: 10539 exchanges per secondThere is room for improvement and no real effort has been made at all in optimization beyond a direct translation.
std.os.windows.CryptAcquireContextA
std.os.windows.CryptReleaseContext
std.os.windows.CryptGenRandom
std.ArrayList
and std.HashMap
APIs regarding iteration. (#981)std.fmt.format
.
std.Buffer.replaceContents
method (#1065)std.Buffer.fromOwnedSlice
. (#1082)std.ArrayList.setOrError
so you can set a value without growing the underlying buffer, with range safety checks.{s}
. (#1092)zig version
compliant with SemVer with regards
to the git revision metadata.-1
.std.ArrayList.insert
and added tests. (#1232)std.ArrayList.swapRemove
. (#1230)std.ArrayList.swapRemoveOrError
. (#1254)std.os.posix
constants.error.SkipZigTest
std.io.PeekStream
and std.io.Slicestream
.
*[N]T
to ?[*]T
(#1398)std.fmt.format
(#1432)*T
and [*]T
to ?*c_void
@floatToInt
@byteOffsetOf
and @bitOffsetOf
.clock_gettime
uses the VDSO optimization, even
for static builds.f32
values. Various
changes to better match libc.std.os.time
module. -Marc Tiehuisconst
, const
. -Jimmi Holst Christensenstd.fmt.format
supports {B}
for human readable bytes using SI prefixes.comptime_int
and comptime_float
. -Jimmi Holst Christensenarray.len
through a pointer. -Jimmi Holst Christensen*T -> ?*T
cast
is allowed implicitly, even when it occurs deep inside the type, and the cast
is a no-op at runtime.
__extenddftf2
and __extendsftf2
to zig's compiler-rt.--emit
in test
command. -Ben Noordhuis (#1175)builder.addBuildOption
API. -Josh Wolfe-Dskip-release
option to test faster. -Andrew Kelley & Jimmi Holst Christensen==
for comparing optional pointers. #658--enable-timing-info
to -ftime-report
to match clang, and
have it print llvm's internal timing info.promise->T
syntax not parsed #857memmove
to builtin.o. LLVM occasionally generates a dependency on this function.std.BufMap
logic. -Ben Noordhuis.ReturnType
and @ArgType on unresolved types. -Jimmi Holst Christensen (#846)type
. -Jimmi Holst Christensentype
, then the struct is marked as requiring
comptime as well. Same goes for unions.
type
.
@tagName
crashing sometimes. (#1118)@ptrToInt
of a *void
(#1192)@setEvalBranchQuota
not respected in generic fn calls. #1257@typeInfo
unable to distinguish compile error vs no-payload (#1421, #1426)@ptrCast
to *void
. (#960)@intToPtr
of function@ptrCast
0 bit type to non-0 bit type@intCast
to u0
Buf *
directly rather
than an array of ConstExprValues for the elements,
and then similar to array of undefined, it is
expanded into the canonical form when necessary.
However many operations can happen directly on the
Buf *
, which is faster.
std.fmt.formatInt
to handle upcasting to base int sizeZig has known bugs.
The first release that will ship with no known bugs will be 1.0.0.
Special thanks to those who donate monthly. We're now at $1,349 of the $3,000 goal. I hope this release helps to show how much time I've been able to dedicate to the project thanks to your support.


Defines the ActualWork property.
Defines the AssignedTime property.
Defines the BillingInformation property.
Defines the ChangeCount property.
Defines the Companies property.
Defines the CompleteDate property.
Defines the Contacts property.
Defines the DelegationState property.
Defines the Delegator property.
Defines the DueDate property.
Defines the IsComplete property.
Defines the IsRecurring property.
Defines the IsTeamTask property.
Defines the Mileage property.
Defines the Mode property.
Defines the Owner property.
Defines the PercentComplete property.
Defines the Recurrence property.
Defines the StartDate property.
Defines the Status property.
Defines the StatusDescription property.
Defines the TotalWork property.
Defines the ActualWork property.
Defines the AllowedResponseActions property.
Defines the ArchiveTag property.
Defines the AssignedTime property.
Defines the Attachments property.
Defines the BillingInformation property.
Defines the Body property.
Defines the Categories property.
Defines the ChangeCount property.
Defines the Companies property.
Defines the CompleteDate property.
Defines the Contacts property.
Defines the ConversationId property.
Defines the Culture property.
Defines the DateTimeCreated property.
Defines the DateTimeReceived property.
Defines the DateTimeSent property.
Defines the DelegationState property.
Defines the Delegator property.
Defines the DisplayCc property.
Defines the DisplayTo property.
Defines the DueDate property.
Defines the EffectiveRights property.
Defines the EntityExtractionResult property.
Defines the ExtendedProperties property.
Defines the Flag property.
Defines the HasAttachments property.
Defines the IconIndex property.
Defines the Id property.
Defines the Importance property.
Defines the InReplyTo property.
Defines the InstanceKey property.
Defines the InternetMessageHeaders property.
Defines the IsAssociated property.
Defines the IsComplete property.
Defines the IsDraft property.
Defines the IsFromMe property.
Defines the IsRecurring property.
Defines the IsReminderSet property.
Defines the IsResend property.
Defines the IsSubmitted property.
Defines the IsTeamTask property.
Defines the IsUnmodified property.
Defines the ItemClass property.
Defines the LastModifiedName property.
Defines the LastModifiedTime property.
Defines the Mileage property.
Defines the MimeContent property.
Defines the Mode property.
Defines the NormalizedBody property.
Defines the Owner property.
Defines the ParentFolderId property.
Defines the PercentComplete property.
Defines the PolicyTag property.
Defines the Preview property.
Defines the Recurrence property.
Defines the ReminderDueBy property.
Defines the ReminderMinutesBeforeStart property.
Defines the RetentionDate property.
Defines the Sensitivity property.
Defines the Size property.
Defines the StartDate property.
Defines the Status property.
Defines the StatusDescription property.
Defines the StoreEntryId property.
Defines the Subject property.
Defines the TextBody property.
Defines the TotalWork property.
Defines the UniqueBody property.
Defines the WebClientEditFormQueryString property.
Defines the WebClientReadFormQueryString property.
The indexed property to register.
SchemaClass calling this method - workaround for fieldUri registration oterhwise it registers super/parent class static properties as well. TypeScript does not provide a way to detect inherited property, hasOwnProperty returns true for parent static property
The property to register.
Registers properties.
SchemaClass calling this method - workaround for fieldUri registration oterhwise it registers super/parent class static properties as well. TypeScript does not provide a way to detect inherited property, hasOwnProperty returns true for parent static property
The property to register.
SchemaClass calling this method - workaround for fieldUri registration oterhwise it registers super/parent class static properties as well. TypeScript does not provide a way to detect inherited property, hasOwnProperty returns true for parent static property
The property to register.
Indicates whether the property is internal or should be visible to developers.
Name of the XML element.
The property definition.
True if property definition exists.
The URI.
Property definition.
Generated using TypeDoc
Represents the schema for task items.


This is a site created and maintained by Igor. It contains blog posts on various subjects that are studied in Phase 0 of DBC
Plase see full list on the left


Chats
{{grp.name|title}}
{{grp.description|title}}
{% include 'chat/room_message.html' %}
{% include 'chat/room_preview_image.html' %}


resource mysql_query ( string $query [, resource $link_identifier ] )
mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier.
For SELECT, SHOW, DESCRIBE, EXPLAIN and other statements returning resultset, mysql_query() returns a resource on success, or FALSE on error. For other type of SQL statements, INSERT, UPDATE, DELETE, DROP, etc, mysql_query() returns TRUE on success or FALSE on error. The returned result resource should be passed to mysql_fetch_array(), and other functions for dealing with result tables, to access the returned data. Use mysql_num_rows() to find out how many rows were returned for a SELECT statement or mysql_affected_rows() to find out how many rows were affected by a DELETE, INSERT, REPLACE, or UPDATE statement. mysql_query() will also fail and return FALSE if the user does not have permission to access the table(s) referenced by the query.


Up For A Drink?
Check where your friends are at tonight!
Don't forget two things: tipping your bartenders — and bringing along your DD!
-
O'Brien Sports Pub & Restaurant
The quintessential Irish pub. It's a great place to hang out, eat dinner, have some drinks, listen to live music, or watch something on TV.
-
O'Brien Sports Pub & Restaurant
The quintessential Irish pub. It's a great place to hang out, eat dinner, have some drinks, listen to live music, or watch something on TV.
-
O'Brien Sports Pub & Restaurant
The quintessential Irish pub. It's a great place to hang out, eat dinner, have some drinks, listen to live music, or watch something on TV.


Hardware Features
EPOC Package
Video Tutorial
Specifications
Sensor Layout
Light Indicators
Device Setup
Device Usage
Sensor Repair or Troubleshooting
Device Design
(Left Enclosure)
(Right Enclosure)


The Bayes Way
The Bayes Way - this page - is a small subset of the best articles, papers, videos and books to learn Probability and Statistics. It is a way to reduce the signal-noise ratio for beginners.
A Whirlwind Tour of Python - Jake VanderPlas
Python Data Science Handbook - Jake VanderPlas
From Python to Numpy - Nicolas P. Rougier
100 numpy exercises - Nicolas P. Rougier
A Concrete Introduction to Probability (using Python) - Peter Norvig
Khan Academy’s statistics and probability course
Bayesian Statistics the Fun Way - Will Kurt
Think Stats - Allen B. Downey
Think Bayes - Allen B. Downey
The Art of Data Science: A Guide for Anyone Who Works with Data - Roger D. Peng, Elizabeth Matsui
Probabilistic Programming & Bayesian Methods for Hackers - Cam Davidson-Pilon
Bayesian Analysis with Python - Osvaldo Martin
Harvard’s Statistics 110: Probability
Duke’s Statistics with R Specialization
MITx’s Statistics and Data Science MicroMasters
Introduction to Probability - Joseph K. Blitzstein, Jessica Hwang
Doing Bayesian Data Analysis: A Tutorial Introduction with R - John K. Kruschke
Statistical Rethinking - Richard McElreath
Probability Theory: The Logic of Science - E.T. Jaynes
Aubrey Clayton lectures on the key chapters of Probability Theory The Logic of Science
Bayesian Data Analysis - Andrew Gelman
Automating Inference, Learning, and Design using Probabilistic Programming - Tom Rainforth
A Conceptual Introduction to Hamiltonian Monte Carlo
The Markov Chain Monte Carlo Revolution


|
Team 302 Robot
|
This is the interface for mechanisms regardless of what control items are available. More...
#include <IMech.h>
Public Member Functions | |
| virtual MechanismTypes::MECHANISM_TYPE | GetType () const =0 |
| Indicates the type of mechanism this is. More... | |
| virtual std::string | GetControlFileName () const =0 |
| indicate the file used to get the control parameters from More... | |
| virtual std::string | GetNetworkTableName () const =0 |
| indicate the Network Table name used to setting tracking parameters More... | |
| IMech ()=default | |
| virtual | ~IMech ()=default |
| virtual void | ActivateLogging (units::second_t millisecondsBetweenLogging)=0 |
| Activates logging key values to network table. More... | |
| virtual void | DeactivateLogging ()=0 |
| Stop updating the key values to network table. More... | |
| virtual void | LogData ()=0 |
| log data to the network table if it is activated and time period has past More... | |
This is the interface for mechanisms regardless of what control items are available.
Interface for subsystems.
|
default |
|
virtualdefault |
|
pure virtual |
Activates logging key values to network table.
| [in] | int | indicate how many millisecondsBetweenLogging updates to the network table |
Implemented in Mech2IndMotors, Mech1IndMotor, and Mech.
|
pure virtual |
Stop updating the key values to network table.
Implemented in Mech2IndMotors, Mech1IndMotor, and Mech.
|
pure virtual |
indicate the file used to get the control parameters from
Implemented in Mech2IndMotors, Mech1IndMotor, and Mech.
|
pure virtual |
indicate the Network Table name used to setting tracking parameters
Implemented in Mech2IndMotors, Mech1IndMotor, and Mech.
|
pure virtual |
Indicates the type of mechanism this is.
Implemented in Mech2IndMotors, Mech1IndMotor, Mech, and DriveTrainSide.
|
pure virtual |
log data to the network table if it is activated and time period has past
Implemented in Mech2IndMotors, Mech1IndMotor, and Mech.


Creating a website takes a lot of time and effort.
You need to find a reliable hosting provider, then make sure you choose the right hosting plan,
then actually design the website (which is almost impossible to do if you don't already know
how to code, especially if you are busy running your business), and then deploying it.
And that's ignoring the fact that your website might need to be hosted along side a database,
that you will need to be able to query and read/write information to.
If you choose to hire me, I will take away those worries.
When you choose to hire me, I will keep things simple and make sure that you have as much control over the development proccess as you want, whether that means you want full control or to leave it up to me.
Congratulations, after all our hard work together, you are finally the proud owner of your business website. It's time for a celebration...
Your website will be available at the domain of your choosing, and will over time become indexed by a search engine like Google.
Lets get through this process together
Get your free consultation and home page demo


| Date: | 2020/5/2 | |
| Time: | 16:39:59 | |
| Elapsed Time: | 00:00:00 | |
| Filename: | D:\projs\UCSD\UCSD2020\200428_YangzhiPCB\EMGV1\EMGV1.PcbDoc | |
| Units: |
| Nets | Layer | Length |
|---|---|---|
| AIN2_A1 | Signal Layers Only | 6.3276mm |
| AIN3_A0 | Signal Layers Only | 9.1757mm |
| DEC1 | Signal Layers Only | 2.1816mm |
| GND | Signal Layers Only | 37.9738mm |
| LED_G | Signal Layers Only | 0.3556mm |
| NetA1_1 | Signal Layers Only | 1.35mm |
| NetC13_1 | Signal Layers Only | 1.1919mm |
| NetC13_2 | Signal Layers Only | 1.3041mm |
| NetC15_2 | Signal Layers Only | 7.9542mm |
| NetC1_1 | Signal Layers Only | 4.2658mm |
| NetC20_1 | Signal Layers Only | 1.3801mm |
| NetC2_1 | Signal Layers Only | 6.9367mm |
| NetC3_2 | Signal Layers Only | 1.5211mm |
| NetC9_1 | Signal Layers Only | 0.3556mm |
| NetCard1_1 | Signal Layers Only | 3.8013mm |
| NetCard1_2 | Signal Layers Only | 3.7323mm |
| NetChigh_1 | Signal Layers Only | 5.8647mm |
| NetChigh_2 | Signal Layers Only | 7.4746mm |
| NetD1_2 | Signal Layers Only | 20.4031mm |
| NetD1_3 | Signal Layers Only | 26.0703mm |
| NetFB2_1 | Signal Layers Only | 5.7947mm |
| NetL2_1 | Signal Layers Only | 1.752mm |
| NetL2_2 | Signal Layers Only | 2.4891mm |
| NetL4_2 | Signal Layers Only | 3.5594mm |
| NetLD1_2 | Signal Layers Only | 5.7513mm |
| NetLD2_2 | Signal Layers Only | 3.4914mm |
| NetR1_1 | Signal Layers Only | 6.861mm |
| NetR1_2 | Signal Layers Only | 3.4196mm |
| NetR2_1 | Signal Layers Only | 3.0157mm |
| NetR2_2 | Signal Layers Only | 3.4196mm |
| NetR4_2 | Signal Layers Only | 3.6557mm |
| NetR7_1 | Signal Layers Only | 11.6302mm |
| NetR8_1 | Signal Layers Only | 12.5765mm |
| NetR8_2 | Signal Layers Only | 2.8688mm |
| P0.00/XL1 | Signal Layers Only | 4.8033mm |
| P0.01/XL2 | Signal Layers Only | 4.2358mm |
| P1.12_D3~ | Signal Layers Only | 9.6575mm |
| P1.13_D5~ | Signal Layers Only | 6.5958mm |
| RESET | Signal Layers Only | 7.6935mm |
| SCK | Signal Layers Only | 0.3556mm |
| SWDCLK | Signal Layers Only | 0mm |
| VBUS | Signal Layers Only | 32.3311mm |
| VBUS_nRF | Signal Layers Only | 14.4807mm |
| VDD_nRF | Signal Layers Only | 30.14mm |
| VEE | Signal Layers Only | 16.1315mm |


| GTK+ 2.0 Tutorial using Ocaml | ||
|---|---|---|
| <<< Previous | Container Widgets | Next >>> |
The paned window widgets are useful when you want to divide an area into two parts, with the relative size of the two parts controlled by the user. A groove is drawn between the two portions with a handle that the user can drag to change the ratio. The division can either be horizontal (`HORIZONTAL) or vertical (`VERTICAL).
To create a new paned window, call GPack.paned with orientation(`HORIZONTAL or `VERTICAL):
val GPack.paned : Gtk.Tags.orientation -> ?border_width:int -> ?width:int -> ?height:int -> ?packing:(GObj.widget -> unit) -> ?show:bool -> unit -> paned |
After creating the paned window widget, you need to add child widgets to its two halves. To do this, use the functions:
method add1 : GObj.widget -> unit method add2 : GObj.widget -> unit |
add1 method adds the child widget to the left or top half of the paned window. add2 method adds the child widget to the right or bottom half of the paned window.
As an example, we will create part of the user interface of an imaginary email program. A window is divided into two portions vertically, with the top portion being a list of email messages and the bottom portion the text of the email message. Most of the program is pretty straightforward. A couple of points to note: text can't be added to a Text widget until it is realized. This could be done by calling #misc#realize method, but as a demonstration of an alternate technique, we connect a handler to the "realize" signal to add the text. Also, we need to add the GTK_SHRINK option to some of the items in the table containing the text window and its scrollbars, so that when the bottom portion is made smaller, the correct portions shrink instead of being pushed off the bottom of the window.
(* file: paned.ml *) let cols = new GTree.column_list let str_col = cols#add Gobject.Data.string (* Create the list of "messages" *) let create_list () = (* Create a new scrolled window, with scrollbars only if needed *) let scrolled_window = GBin.scrolled_window ~hpolicy:`AUTOMATIC ~vpolicy:`AUTOMATIC () in let model = GTree.list_store cols in let treeview = GTree.view ~model ~packing:(scrolled_window#add_with_viewport) () in for i = 0 to 10 do let iter = model#append () in model#set ~row:iter ~column:str_col (Printf.sprintf "Message #%d" i) done; let renderer = GTree.cell_renderer_text [] in let column = GTree.view_column ~title:"Messages" ~renderer:(renderer, ["text", str_col]) () in treeview#append_column column; scrolled_window#coerce (* Add some text to our text widget - this is a callback that is invoked * when our window is realized. We could also force our window to be * realized with #misc#realize, but it would have to be part of * a hierarchy first *) let insert_text (buffer: GText.buffer) = let iter = buffer#get_iter `START in buffer#insert ~iter ( "From<EMAIL_ADDRESS>^ "To<EMAIL_ADDRESS>^ "Subject: Made it!\n" ^ "\n" ^ "We just got in this morning. The weather has been\n" ^ "great - clear but cold, and there are lots of fun sights.\n" ^ "Sojourner says hi. See you soon.\n" ^ " -Path\n") (* Create a scrolled text area that displays a "message" *) let create_text () = let scrolled_window = GBin.scrolled_window ~hpolicy:`AUTOMATIC ~vpolicy:`AUTOMATIC () in let view = GText.view ~packing:scrolled_window#add () in let buffer = view#buffer in insert_text buffer; scrolled_window#coerce let main () = (* Create a new window; set title and border width *) let window = GWindow.window ~title:"Paned Windows" ~border_width:10 ~width:450 ~height:400 () in (* Set a handler for destroy event that immediately exits GTK. *) window#connect#destroy ~callback:GMain.Main.quit; (* create a vpaned widget and add it to our toplevel window *) let vpaned = GPack.paned `VERTICAL ~packing:window#add () in (* Now create the contents of the two halves of the window *) let list = create_list () in vpaned#add1 list; let text = create_text () in vpaned#add2 text; window#show (); GMain.Main.main () let _ = Printexc.print main () |
| <<< Previous | Home | Next >>> |
| Aspect Frames | Up | Viewports |


Project DTC
Home
Play
Information
Donate
Login
Coming Soon!
Staff
Administrators
_DTC
Caamflyer64
Developers
No Developers Yet!
Moderators
No Moderators Yet!
Media Directors
No Media Directors Yet!


My name is Popoola Ayodeji Emmanuel , I'm a student 200L of Kwara State University Malete. I am a visionalist who loves to try out new discoveries. You can reach out to me via my mail<EMAIL_ADDRESS>or my phone number +2347010190885.
<-- Go to homepage
Emmanuel - © Copyright 2021


Why The Colts Will Score More Than The Other Guys - Jaguars Edition
by jgerbigWho: The Jacksonville Jaguars vs. the Indianapolis Colts.
What: Week 11 of the 2019 NFL season.
Where: Lucas Oil Stadium, Indianapolis, IN.
When: 1 PM Eastern, Sunday, November 17th. TV: CBS. We get the awesome duo of Andrew Catalon and HoF WR James Lofton, and by “awesome” I mean “average.”
Why the Colts will score more than the other guys:
1. Luck
No, no, no, no that guy. Stop it already. You people are reaching for something that simply isn’t there.
Last Sunday was an absolute embarrassment for the entire organization. The offense scored ZERO points in the first half against statistically THE WORST DEFENSE IN THE NFL. Read that again. I know Frank Reich knows a hell of a lot more about football than I ever will, but if he can come up with a legitimate excuse for what happened with the play calling at the end of the game, then I’m ready to listen. Disgusting.
Coming into Miami, the Colts were looking at a follow stretch of three straight division games. I can’t pretend to know what Reich was thinking, but one of two things happened: 1) Brisket is hurt worse than they’re saying or 2) they legit thought they could beat Miami with Hoyer.  It was on full display Sunday, and the display ends with one of the most embarrassing losses in recent Colts history.
*exhales*
Now the Hags are in town with a defense minus Jalen “I got blown up by Mark Glowinski” Ramsey, but still good. Remember last season when Andrew Luck & company went down to Florida and didn’t score a point?
UPDATE:
The game is over. It’s been over for 6 hours. Yes, I am finishing the article anyway. That’s the type of commitment that demands your respect, or something. Truth is, I had an idea in mind, but was summoned to hang out with my beloved QC. One thing led to another, and next thing ya know it’s 2 in the morning and everyone’s ready for bed. I do not apologize and can’t wait to do it again.
But this is how I saw it going down:
The Colts start slowly, still on that Miami hangover. The offense looks sluggish, and the defense allows the noodle-armed Nick Foles to pick them apart for an easy touchdown. Here we go again…
But wait! The offense begins to bludgeon the Hags on the ground, the defense steps up, and soon the game is right there for the taking…
It’s 3rd and goal from the 1. Quenton Nelson is announced as eligible, and he lines up at fullback. Here’s the snap, the give is to Big Q, and…they rule it a touchdown, but it looks like he’s short. Nelson’s keg stand TD celebration is the greatest thing we’ve ever seen. CBS cuts to commercial while Referee Shawn Hoculi heads off to the monitor to review the play.
As Hoculi approaches the replay camera, he is met by a disheveled looking man with a thick beard, and wearing…an officials uniform, duh. The two men have a brief conversation which ends with a handshake, and Hoculi smiling and stuffing his hand in his pocket.
When CBS returns from the break, no one notices Hoculi is missing. The disheveled looking man flips on the mic and gives the call: “After review, the runner was short of the line to gain, but you never overturn a f***ing TD that ends with a keg stand TD dance. The ruling on the field is confirmed.”
With that, the disheveled looking man throws a penalty flag, eludes security, and races down the tunnel, never to be seen again. When security finds the flag, they discover it reads “I gave my heart to this team!”
2. Jess
When I asked why the Colts will score more than the other guys, this is what she had to say:
“Because Florida has too many football teams. Share with Montana and the Dakotas. Those guys got nothing going for them in the winter.”
Me: “Sharing is caring?”
Jess: “But seriously. 3 teams. In a sinking state. Makes no sense.”
Hey, no argument here. Can’t wait for the NFL to keep the North Dakota Bucaneers in the NFC South “to preserve rivalries.”
3. Colts cheerleader Rachel J
Rachel is my favorite Colts CC. She’s an awesome lady who will do great things in life. This is her in the middle:
Now flying solo for these next two
Look at that smile and those eyes.
Colts 33, Hags 13


6502
6502 Toolchain written by
swissChili
Git
Docs
Basic usage
Example programs
Building from source
Debugger commands
${body}


{#Render#}
Tip: Move cursor over the icons to get extra information...
{%if not d3_nodes %}
Nothing to show yet. Add Aggregates to the slice.
{% endif %}


| body |
Yes |
'' |
String |
This is the body of the notification. |
| parent |
No |
document.body |
HTMLElement |
This is the element you would like the notification to be appended to. |
| color |
No |
'' |
String |
This is the color modifer to add to the notification. For example for is-info you would set color to info . |
| dismissInterval |
No |
null |
Integer |
This is the time in milliseconds the notification is visible. |
| isDismissable |
No |
false |
Boolean |
Would you like the notification to be dismissable, we will also add the delete button to the rendered HTML. |
| destroyOnDismiss |
No |
true |
Boolean |
Would you like the notification to be destroyed when dismissed? This will remove the HTML and also unregister events. |
| element |
No |
true |
HTMLElement |
This is a reference to a .notification element. Generally you do not need to include this value, it is primarily used for the automatic DOM parsing. |
| closeButton |
No |
<button class="delete"></button> |
HTMLElement |
This is the element you would like to be used when dismissing the notification. |


The Infopoint HTML Viewer has been successfully installed!
However, you have not given any URL to display. This is the default page.
You can give a URL on the command line, or you can configure a default URL by editing the file /etc/default/infopoint-html
.


FOOD CENT
Menu
Login
Reset password link sent
An email is sent to your email address that contains the link to reset the password.


--- layout: post title: A millionaire real-estate magnate and art dealer from Setesdal in southern Norway has been fined NOK 425,000 (USD 85,000) for drunk driving, and been further required to chop wood for 30 days. date: '2008-01-17T15:52:59+00:00' tags: [] tumblr_url: http://backlog.robbevan.com/post/23995159/a-millionaire-real-estate-magnate-and-art-dealer ---
A millionaire real-estate magnate and art dealer from Setesdal in southern Norway has been fined NOK 425,000 (USD 85,000) for drunk driving, and been further required to chop wood for 30 days.—Hangover hits rich man hard - Aftenposten.no


I'm Lam Pham.
Software Engineer, Web Developer, JavaScript Lover & Blogger @completejavascript
Portfolio
Check out my lastest work below.
About
A little bit about me.
Hi, My name is Lam Pham from Vietnam. I am a Software Engineer with a focus on C/C++. Beside, I am really passionate about JavaScript and Web Development. I got a bachelor of Electronics and Telecommunication Engineering at Ha Noi Uninversity of Science and Technology (2011 - 2016). And 2016 - present, I work for Samsung Vietnam Mobile R&D Center (SVMC) as a C/C++ Software Engineer.
As you can see, this website is my personal portfolio webpage, which I created while learning Web Development from freeCodeCamp in my spare time. And from now on, I am going to share my latest work consistently. Each project consists of its link for preview on Github and how-to, which I explain how I created it. In fact, before digging deeper into freeCodeCamp or Web Development, I self-learned JavaScript, HTML5 & CSS3, Bootstrap & jQuery, AngularJS and NodeJS & ExpressJS... So, below are some informations about my skills that I self-evaluate honestly:
Besides, I love coding and blogging. I try to code everyday and write blogs to share my experiences to people. Here are my blogs (in Vietnamese): Complete JavaScript · Algorithm · Personal Blog.
I enjoy instrument musical. In my free time, I usually play Ukulele. And, I like Street Workout. I am training it four times a week to get fit and healthy. Thanks for visiting my website!
Contact
If you would like to get in touch with me, please visit my social networks or send me a message. Thanks a lot!


Santa monica bullevard
Mon to Fri 9am to 6 pm
Send us your query anytime!
Your message is successfully sent...
Something went wrong


{% extends 'base.html' %}
{% load static %}
{% block head %}
{% endblock %}
{% block main_content %}
| Block No. |
{{this_block.id}} |
| Previous Hash |
{{this_block.prev_hash}} |
| Block Hash |
{{this_block.this_hash}} |
| Merkle Hash |
{{this_block.merkle_hash}} |
| Nonce |
{{this_block.nonce}} |
| Timestamp |
{{this_block.timestamp|date:"Y-m-d"}} {{this_block.timestamp|time:"H:i:s"}} |
| Confirmations |
{{confirmed_by}} confirmations |
Recalculated Merkle Root Hash: {{re_merkle_hash}}
{% if isTampered %}
Vote transaction(s) in this block is(are) tampered.
Sync Block
{% else %}
All the vote transactions in this block are intact. (Not Tampered)
{% endif %}
| Vote No. |
Voter ID |
Timestamp |
Vote Hash |
{% for vote, hash in votes %}
| {{forloop.counter}} |
{{vote.uuid}} |
{{ vote.timestamp|date:"Y-m-d" }} {{ vote.timestamp|time:"H:i:s" }} |
{{hash}} |
{% endfor %}
{% endblock %}


My Summer 2020 Class Schedule
| CIS3526 |
IT Project Management |
Monday through Thursday |
2:30 PM to 4:10 PM |
| COP4813 |
Internet Programming |
Online |
Important Events
- May
- Star Wars Day
- First Day of Internet Programming
- Memorial Day
- June
- Flag Day
- Father's Day
- July
- Independence Day
- Deadline to withdraw from Internet Programming Day
- August
- Last Day of Class
Personal
ePortfolio


TELDRIN ALLERGY RELIEF- chlorpheniramine maleate tablet
Gemini Pharmaceuticals, Inc.
Disclaimer: Most OTC drugs are not reviewed and approved by FDA, however they may be marketed if they comply with applicable regulations and policies. FDA has not evaluated whether this product complies.
Active Ingredients (in each tablet)
Chlorpheniramine Maleate 4mg
Uses
For temporary relief of:
- runny nose
- sneezing
- itching of the nose and throat
- itchy, watery eyes due to hay fever or other upper respiratory allergies.
Warnings
Ask a doctor before use if you have
- a breathing problem such as emphysema or chronic bronchitis
- glaucoma
- difficulty in urination due to enlargement of the prostrate gland
Ask a doctor or pharmacist before use if you are taking sedatives or tranquilizers
When using this product
- excitability may occur, especially in children
- drowsiness may occur
- avoid alcoholic drinks
- alcohol, sedatives, and tranquilizers may increase the drowsiness effect
- use caution when driving a motor vehicle or operating machinery.
If Pregnant or breast-feeding, ask a health professional before use.
Keep out of reach of children.
In case of
overdose, get medical help or contact a Poison Control Center right away. (1-800-222-1222)
Directions
| Adults and children 12 years of age and over |
Take 1 tablet every 4 to 6 hours, not to exceed 6 tablets in 24 hours, or as directed by a doctor
|
| Children 6 to under 12 years of age |
take 1/2 tablet every 4-6 hours, not to exceed 3 tablets in 24 hours, or as directed by a doctor
|
| Children under 6 years of age |
consult a doctor
|
Other information
- Store at room temperature
- Retain carton for complete product information
Inactive ingredients
Dicalcium Phosphate Dihydrate, D&C Yellow # 10, Lactose Monohydrate, Magnesium Stearate, Microcrystalline Cellulose, Pregelatinized Corn Starch, Silicon Dioxide, Stearic Acid
Questions or comments?
If you have any questions or comments, or to report an adverse event, please contact 1-888-876-6898
Package label Sine Off Maximum Strength
Teldrin ®
Decongestant - Free
Allergy Relief
HBP
for people with High Blood Pressure
Chlorpheniramine Maleate 4 mg Each
Antihistamine
24
Tablet
Gemini Pharmaceuticals, Inc.


This shows that the sphere can be divided into spherical triangles
in an octahedral pattern (slide to the left) or an icosahedral
pattern (slide to the right). The triangles can then be flattened
out to make an actual regular polyhedron. We will need a
framework of definitions to capture these phenomena, and we will
need to prove that the answers to certain question do not change
depending on which pattern we use.


| Course | Degree | University | Period |
|---|---|---|---|
| Software Engineering for Secure Cloud Systems | MSc | University of Salerno | Spring 2024 (course holder: C. Gravino) |
| Funding and Management of Research Projects | PhD | University of Salerno | Winter 2023 (course holder: A. De Lucia) |
| Software Dependability | MSc | University of Salerno | Fall 2023 (course holder) Spring 2023 (course holder) Spring 2022 (course holder: F. Palomba) |
| Object Oriented Programming | BSc | University of Salerno | Fall 2023 (course holder: V. Deufemia) Fall 2022 (course holder: V. Deufemia) |
| Course | Degree | University | Period |
|---|---|---|---|
| Empirical Research Methods | PhD | University of Salerno | Summer 2023 (course holder - co-lectured with F. Palomba) |
| Software Engineering, Management, and Evolution | MSc | University of Salerno | Spring 2022 (course holder: A. De Lucia) |
| Data Engineering | MSc | Jheronimus Academy of Data Science | Fall 2021 (course holder: W.J. van den Heuvel)
Fall 2020 (course holder: W.J. van den Heuvel) |
| Introduction to Machine Learning | Pre-MSc | Jheronimus Academy of Data Science | Spring 2021 (course holder) Spring 2020 (course holder: D.A. Tamburri) |
| Capita Selecta of Software Engineering | MSc | Vrije Universiteit Brussel | 2019/20 (yearly course, course holder: C. De
Roover)
2018/19 (yearly course, course holder: C. De Roover) |
| Data Statistics | BSc | Tilburg University | Fall 2019 (course holder: M.C. Kaptein) |


SpecIF to OXML Converter
Please pick a file of type specif or specifz:
Read SpecIF file and in transform to OXML:
Start


compareTo()
methods and methods implementing java.util.Comparator.compare()
. While it is a common idiom to
use the results of integer subtraction as the result of a compareTo()
method, this construct may cause subtle and difficult bugs in cases of integer overflow.
Comparing the integer values directly and returning -1
, 0
, or 1
is better practice in most cases.
The subtraction on floating point values which is immediately cast to integral type is also warned as precision loss is possible due to rounding.
A warning is not issued when it's statically determined that value ranges are limited, and overflow never occurs.
Additionally, subtraction on int
numbers greater than or equal to 0
will never overflow.
Therefore, this inspection tries not to warn in those cases.
Methods that always return zero or greater can be specified in this inspection's settings.
Example:
class DoubleHolder implements Comparable<DoubleHolder> {
double d;
public int compareTo(DoubleHolder that) {
return (int)(this.d - that.d);
}
}
A no-warning example because String.length()
is known to be non-negative:
class A implements Comparable<A> {
final String s = "";
public int compareTo(A a) {
return s.length() - a.s.length();
}
}
Use the table below to specify methods which are safe to use inside a subtraction.
Methods are safe when they return an int
value that is always greater than or equal to 0
.
Alternatively you may use javax.annotation.Nonnegative
annotation on such methods.


Ma(s)k a Differencetogether!
This is a great way to earn recognition for all the hard work and hours you are putting into helping the heroes and the vulnerable during these tough times. This would be an example of an award to include in college apps, resumes, etc. You will be receiving a certificate for your hours (award type and the number of hours vary). For more information please click on the Learn More
button.
Your donations will help us do what we do! The funds will be used for: Masks, 100% cotton fabric (recommended fabric by the CDC), elastics, basic sewing supplies such as needles and thread.
We are also accepting donations of materials. They would be greatly appreciated.
Donate Funds Donate MaterialsThis role is hands-on and very crucial in achieving our goal. Sewing machines are recommended for more efficient production, but hand-sewing is fine as well. We expect at least 10 masks from our volunteers, and those that meet 25, 50, 100, etc. will receive recognition and a reward. All volunteers will have the chance to be featured on our website and social media pages if they are willing.
To begin, you can fill out the sign-up form below or contact me or my team personally. Cotton fabric and elastics will be provided by me (pick-up from my house) OR you can use your own materials (would help a lot).
Sign up to StartUse your art and your creativity to help your community! Making cards is a simple yet effective way to show people your appreciation. The various members that will be receiving your cards include nurses, doctors, firefighters, homeless, veterans, and the elderly. After you complete your cards, please fill out the form below so we can contact you and arrange a time to collect the cards.
Sign-up hereThis role is for individuals that can help our program grow by accumulating more donations and finding sources of money as contributions to our program. Selected members will be considered a part of the Executive Team.
Organizing fundraisers (such as sticker fundraisers, baking fundraisers, etc.)
Joining the fundraising team on GoFundMe and advertising the link to donate
Reaching out to local businesses for potential donations/ corporate matches for our program
It is recommended to have connections with adults/businesses, experience with communicating and writing formal emails, and skills with handling finances.
Sign-up hereSome of our volunteers are masters at sewing by hand or know how to use a sewing machine but they do not have one or it is broken! Lending materials would be amazing.
Here are the following materials you can lend to us: A sewing machine, fabric cutter/scissors, an iron
Sign-up hereThis role has 3 available positions (subject to change) and the volunteers fulfilling this role will be considered a part of the Executive Team.
It is recommended to have artistic skills, familiarity with social media/ web design, or experience in video editing.
Sign-up hereWith the emergence of COVID-19, lots of people have stepped up to assist in their own way. A common theme around the world has been making homemade masks and donating to a local area in need. However, everyone has their time constraints and may not be consistent in their donations. Our goal is to consistently donate to the areas we have partnered with while bringing together individual efforts in donating masks. Additionally, some citizens may be discouraged to make masks because of the necessity to go outside and purchase materials. We will be providing all of our volunteers with the necessary materials! Healthcare professionals are seeking donations of items called PPE (personal protective equipment), and essentially that is what we want to provide. We also hope to reach the associations that are requesting donations for PPE, such as homeless shelters and nursing homes.


In this example we are carrying out the task of setting heights of four divs on the page based on their width. We've solved the problem in two ways:
The first is less performant because it causes the DOM to reflow 4 times by reading and writing in quick succession.
The second makes use of requestAnimationFrame to schedule all DOM writes for the next frame. This means that all the reads happen together, followed by all the writes, and our layout doesn't get 'thrashed' :)
Run timeline in DevTools and observe the number of layouts event that occur for each solution.