<_Vi>
Why arm 32-bit / Linux is listed as "Tier 2" in the table, yet `zig/std/os/linux.zig` throws "unsupported arch" for anything besides x86_64, i386 and aarch64? Is the table valid for last released version (0.4.0) or for master?
<errpr>
the godbolt example works in 0.4.0
<Aransentin>
Curious... :)
<Tetralux>
_Vi: I think 32-bit ARM is different from Linux, no?
<_Vi>
Tetralux, I mean intersection of "arm 32-bit" row and "Linux 3.16+" column.
<Tetralux>
Also, I'm not sure what the table is specific to, but there's a decent chance it's master.
<_Vi>
Tetralux, Unreleased Tier 2 does not look like a real Tier 2...
* Tetralux
shrugs
<andrewrk>
_Vi, I'm not sure why unused symbols are getting included when linking musl statically. that's worth looking into
<_Vi>
With zig from master instead of 0.4.0 the difference is much less drastic: 16104 vs 10256 bytes.
<andrewrk>
_Vi, where do you see 32-bit / linux in the support table?
<andrewrk>
"There may be some standard library implementations, but many abstractions will give an "Unsupported OS" compile error. One can link with libc or other libraries to fill in the gaps in the standard library."
<_Vi>
andrewrk, For 0.4.0 it's not even Tier 4, as it flatly refuses to compile anything.
<_Vi>
Maybe it's just the time for 0.5.0?
<fengb>
That’s in like 2 weeks
<andrewrk>
0.5.0 is scheduled for sept 30
<_Vi>
Are releases on schedule?
<andrewrk>
prior to 1.0, they are approximately 1 week after LLVM releases, which are every 6 months
<_Vi>
And after 1.0 is what?
<andrewrk>
unknown
<_Vi>
6 months look rather rare for an actively developed pre-1.0 project... How many zig developers use non-master zig?
<scientes>
_Vi, everybody is using master
<scientes>
_Vi, its because it is tied to the llvm release schedule
<_Vi>
Why tied to LLVM? Are minor releses like 0.4.(x+1) planned?
<fengb>
The nightly builds are generally pretty stable
<mikdusan>
_Vi: the offset is... master is released with via continuous integration builds/testing. there's a ton of stability to master because of that. other "pre-1.0 projects" imo, anecdotally, are no where near as stable for master builds
<_Vi>
Are releases needed at all for pre-1.0?
<_Vi>
Or are they supposed to be used mostly for comparisons?
<mikdusan>
use master. if master has an LLVM requirement too new for you, use the most recent "Release" that has a lower LLVM match for you.
<fengb>
It gives andrewrk a nice schedule and a chance to catch up on documentation
<stratact>
andrewrk: scientes is right, 8192 is a good size for the dir entry buffer. I've noticed dirread implementations from NetBSD and Suckless.org use a 8192 sized buffer when inserting into getdentries. However from peeling the onion in the std library, it seems that eventually there is a buffer of [4096]u8 is used, but that's because of MAX_PATH constant from glibc and musl. So I think doing MAX_PATH * 2 or 8192 is a good size for the buffer to ensure
<stratact>
no problems and better performance, like scientes said.
<scientes>
yeah master has to past the test suite
<scientes>
so it is no less stable than the releases
<fengb>
This is quite a monster release though. Async, elision, and SIMD 🤞
<companion_cube>
what'll be missing after that? bootstrapping?
<daurnimator>
_Vi: I tend to use the releases for about 3 months... and then use master again as things get too out of sync
<_Vi>
daurnimator, That's a sign of too rare releases.
<scientes>
no really, we don't really have that many users yet
<scientes>
*not
<andrewrk>
result location (aka copy elision) has been rough. I'm not happy with the quality of implementation, and it's definitely introduced bugs
<scientes>
yes, I've seen some of those bugs
<andrewrk>
I hope that when implementing it with a fresh start in self-hosted, a better way to implement it will reveal itself, which can potentially be backported to stage1 if necessary
<mikdusan>
yeah the money question: spend time fixing it or "good enough" and full-ahead on self-hosting?
<andrewrk>
I agree that is the money question
<scientes>
IMHO as always, the only way to find out better ways it to re-write things, you can't "fix" anything until you discover the new method
<andrewrk>
and then stuff like https://github.com/ziglang/zig/issues/3234, it would have been good to consider this upfront. at least now we can make a decision before the new implementation
<scientes>
I also got ticked as this habit of allocating everything on the stack in LLVM so that the debug info works, and then having the compiler optimize to registers
<scientes>
because it means not really using LLVM as SSA that it was designed as
<scientes>
but that is kinda minor
<mikdusan>
i'm not convinced zig-ir should be ssa. maybe it could get lowered into a zig-ir2 that is ssa before llvm
<scientes>
what i'm saying is that the llvm-ir that zig produces isn't ssa either
<andrewrk>
I do think that having our own backend independent from llvm will be instructive into how zig-ir should be
<mikdusan>
i don't ask because of preference, only curiousity. has it been considered to codegen to '.llvm' as opposed to LLVM API? there are decoupling pros. cons i guess { slower? and illegal codegen slips through? }
<scientes>
illegal code gen is already hard to debug, I think you can get better debug with a asserts-enabled llvm
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<andrewrk>
mikdusan, we have that with --emit llvm-ir
<andrewrk>
generally though, zig the language is not supposed to depend on LLVM
<scientes>
I think he is talking about generating llvm-ir without using libllvm
<andrewrk>
even though the "reference implementation" very much does
<scientes>
supporting gcc as a backend would be cool
<_Vi>
Is pure infinite loop an undefined behaviour in Zig?
<mikdusan>
i mean avoid LLVM-API bindings altogether and emit .llvm or .bc and feed that into llvm
<scientes>
no. But I've talked in sopport of that without really pushing it.
<scientes>
it would require some sort of infinite loop intrinsic
<scientes>
@halt()
<scientes>
or @sleep(-1)
<scientes>
mikdusan, i really don't see that that gains us anything
<mikdusan>
scientes: my understanding is that zig uses c compatibility to get to all that is LLVM-API. when LLVM C-API is insufficient, C++ is wrapped in C to bring it to zig,
<scientes>
correct
<mikdusan>
this needs to continue if self-hosting will use LLVM C-API
<andrewrk>
_Vi, ultimately, at this point in time, zig's development process is optimized for productivity & progress of the language to get towards maturity and stability as soon as possible
<scientes>
llvm-c bindings can probably be fixed
<andrewrk>
at some point, priorities will shift
<scientes>
^
<scientes>
that model worked well for go
<_Vi>
andrewrk, Is it reply to comment about release schedule or to question about infinite loops?
<mikdusan>
so in a self-hosted compiler, there is going to be C wrapper for C++ "support" library. no getting around that until as you say llvm-c can be "fixed".
<scientes>
mikdusan, well libclang really is c++ only
<andrewrk>
_Vi, release schedule. I think there is an issue open to deal with the infinite loop thing
<scientes>
so we kind of have a problem anyways, but that is quite a ways down the road
<stratact>
Why can something of type `*[N]T` be passed as `[]T`?
<andrewrk>
stratact, *[N]T represents a pointer to a bunch of contiguous items in memory, and the length is known as part of the type (N). A []T represents a pointer to a bunch of contiguous items in memory, and the length is runtime known (the .len field of the slice)
<andrewrk>
so it's very straightforward and safe to convert *[N]T to []T
<scientes>
.*[0..]
<stratact>
Oh, gotcha
<andrewrk>
scientes, there's an implicit cast for it
<andrewrk>
mikdusan, I might have a better answer for you if I better understood what problem you were trying to solve with outputting .llvm
<mikdusan>
andrewrk: no _problem_ to solve; thinking outloud on what-if decoupled from the API bindings to see if there were any convincing reason to do so
<andrewrk>
mikdusan, one thing I don't like about that is how it complicates what a zig installation looks like
<andrewrk>
currently we have a single binary, a language reference html document, license file, and a lib directory tree
rohlem has joined #zig
<companion_cube>
one binary sounds good
<rohlem>
andrewrk: By its recent mention, are you currently working on #3234 ? Is my assumption correct that the underlying problem extends to similar aliasing when constructing a struct?
<andrewrk>
rohlem, I'm sort of thinking about it subconsciously while working on other issues. it's not a problem with structs because fields don't alias each other
<rohlem>
I was considering a scenario like x = S{.a = f(x), .b = f(x)}; My questions were whether all side-effects should only be observable _after the statement, or whether that should be outright illegal in the first place.
<andrewrk>
currently, such aliasing is allowed, and there is a well-defined order of things happening. f(x) runs with result location set to &x.a. f(x) runs with result location set to &x.b. Proposal https://github.com/ziglang/zig/issues/1108 aims to explore making this not allowed (and safety checked)
<rohlem>
andrewrk: I was thinking, if it's intended the assignment "appears atomic", i.e. both invocations of f can read the old values of x.a and x.b, we could pass a copy of x, but pretend its address were the original x's address, to get result location semantics.
<andrewrk>
that's just the old semantics, without result location
<rohlem>
though escaping that ruse via `@fieldParentPtr` would require further vetting
<rohlem>
It is "new semantics" in that the init function could already depend on the result's address.
<andrewrk>
ah, I see. you are proposing byval parameters
<rohlem>
Well, it would only be under-the-hood. I'll have a gist with an example in 3 minutes.
kristoff_it has joined #zig
<stratact>
Sigh, I made the buffer adjustments, but cmake returns a 255 error code from rebuilding the compiler, which means it's not able to see a file even though it exists?
* stratact
scratches head
<andrewrk>
stratact, can I see the full output from make?
<andrewrk>
the helpful output is nto error code 255, it's the message above that
<andrewrk>
it built zig0, then used `zig0 build libuserland install` which failed. that build step depends on the std lib files you edited, so you've caused a regression that made zig no longer able to build
<andrewrk>
you can use zig0 to run the relevant std lib tests and/or a debugger
<andrewrk>
you'll need `--override-std-dir` when using zig0
<andrewrk>
you can also `make zig0` to skip the steps that are failing while you troubleshoot
<stratact>
Thank you and will do. I had to change something in std.build to fit the changes in std.fs, since most things are interconnected
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<andrewrk>
rohlem, I'm going to have to look at this tomorrow, I'm getting sleepy
<rohlem>
andrewrk, sure, no need to rush or prioritize over anything else even, just wanted to give my 2 cents on the topic while the iron's hot. Rest well, and thanks for all the great work!
<andrewrk>
cheers
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<donpdonp>
so fyi, i tried zig head (0.4.0+c6e77f248 Sep 16 Fix tripping llvm assert) and after updating std.mem.<hash stuff> to std.hash_map, I'm still getting a " Assertion failed. This is a bug in the Zig compiler." compiling zootdeck (head)
kristoff_it has quit [Ping timeout: 240 seconds]
<andrewrk>
donpdonp, thanks for letting me know. I'll make sure zootdeck builds with latest master and then ping you when it's fixed
<donpdonp>
great, thx.
<donpdonp>
the zig that does compile zootdeck is 0.4.0+7f23dac6d Aug 5 'Update readme'
<andrewrk>
noted
mahmudov has quit [Remote host closed the connection]
<stratact>
Well from trying to run (and debug through gdb with) test-std through zig0, for some reason it can't open() from the buffer through FreeBSD's implementation at least.
<stratact>
which explains why it can't find the file, even though it exists
<stratact>
andrewrk: I think issue #2885 is rooted deep in the compiler level instead of standard library, because I think, and I'm just guessing, that removing file_path buffer allocation in the standard library requires that `Buf` types in the zig compiler not be allocated as well...
chemist69 has joined #zig
<stratact>
This issue is probably too big for me and I'd be responsible for tons of breakage
<stratact>
the dots are connecting
<afon>
\leave
afon has left #zig [#zig]
_whitelogger has joined #zig
<mikdusan>
stratact: is that on master or private branch?
Aransentin has quit [Ping timeout: 260 seconds]
<stratact>
mikdusan: the issues are on my local branch, upstream master is unaffected. The problem is when one decides to remove the allocator from Dir.open() which creates more work and problems down the road.
<mikdusan>
if you give me a diff i can add another pair of eyes to it
<mikdusan>
so right now this completely passes for me on freebsd with your patch: _build/zig0 --override-std-dir std --override-lib-dir . test test/stage1/behavior.zig
<mikdusan>
and I moved on to testing "std" which is very large and get a failure:
<mikdusan>
_build/zig0 --override-std-dir std --override-lib-dir . test std/std.zig
<stratact>
Ah, interesting, thank you.
<mikdusan>
are behavior tests passing?
<stratact>
yes
<stratact>
the 2nd test didn't but I got those errors you mentioned
<mikdusan>
ok. i got some missing arguments errors. if you're on the same page, it can be reduced further.
<stratact>
Yeah, just remove the `a` argument, and I think you would be good.
<mikdusan>
this runs a "subset" of std... -> _build/zig0 --override-std-dir std --override-lib-dir . test std/os.zig
<mikdusan>
just build an executable directly: _build/zig --override-std-dir std --override-lib-dir . build-exe bug.zig
<mikdusan>
(you'll note i stopped using zig0 because it's probably ok to use stage1 but still have to point it to our workstree))
<mikdusan>
so now --> lldb bug
<mikdusan>
run; bt; fr s 4
<mikdusan>
fr v
<mikdusan>
hey look we see tmp. that looks decent enough.
<stratact>
yep, but allocator doesn't
<mikdusan>
yeah that's a red flag
<mikdusan>
so i wonder... is there no global debug allocator?
<mikdusan>
well here's a quick test.
<mikdusan>
how about we just use direct allocator and see if that helps
laaron has quit [Remote host closed the connection]
<mikdusan>
same deal.
<rohlem>
andrewrk: as a heads up, I updated the gist, the new idea is much simpler and should be more readable now. I initially thought that promoting variables to result location ( #2765 ) was already implemented, but I think it's worthwhile either way.
rohlem has left #zig [#zig]
<mikdusan>
i'm just going to try a newer lldb
<stratact>
mikdusan: what's interesting is that in frame 3, the `a` allocator pointer has an address
<stratact>
sorry `allocator` allocator
<mikdusan>
yeah i noticed clang is back in version 6. so lldb is probably aged as well
<stratact>
mikdusan: ah, well I'm using FreeBSD12-stable, so I would have the llvm 8.0.1 since it's from the stable branch, iirc?
<mikdusan>
i'm just 12.0
<stratact>
So the release version
<mikdusan>
just tried on macos same deal with lldb.
<mikdusan>
let's see what gdb says
errpr has quit [Ping timeout: 258 seconds]
<stratact>
mikdusan: btw, I wouldn't mind another debugger training session from you 😄
<mikdusan>
ok i installed gdb: gdb bug
<mikdusan>
run
<mikdusan>
bt
<mikdusan>
instead of `fr s 4` it's just `fr 4`
<stratact>
I'm there
<mikdusan>
what the f.
<mikdusan>
fr 3
<mikdusan>
p full_path
<stratact>
wtf indeed: $1 = <optimized out>
<mikdusan>
i don't claim to understand it. but what i do understand is if it ain't there... that explains why a mem cpy is faulting.
<stratact>
It explains the what, but not the why.
<bgiannan>
Is there a syntax i'm not aware of to test more than one thing when unwrapping an optional? In Swift i would do `if let myoptional = unwrapped_optional, myoptional == 42 && something_else == 42 { ... }`
<bgiannan>
but in zig i end up doing: `if (myoptional) |unwrapped_optional| { if (unwrapped_optional == 42 and ..) {...} }`
<mikdusan>
so the debugger isn't being entirely useful. and looking at your diff, i'm a little concerned at some stack memory escaping
<_Vi>
Why lockfiles are mentioned there as something to avoid?
dingenskirchen1 has joined #zig
dingenskirchen has quit [Ping timeout: 250 seconds]
dingenskirchen1 is now known as dingenskirchen
Pursche01 has joined #zig
Aransentin has quit [Remote host closed the connection]
<bgiannan>
Why is `==` not allowed between two optionals?
Aransentin has joined #zig
firefox317 has joined #zig
<firefox317>
What should the result be when you compare two optionals where one of them is null?
<fgenesis>
not equal
laaron has quit [Remote host closed the connection]
<firefox317>
And both of them null true? Not sure if that makes sense because I think the intention is to compare the value of the optional
laaron has joined #zig
<fgenesis>
yes
<fgenesis>
optionals are equal when they have no value
<alexander92>
if they point to the same type
<alexander92>
?
<mq32>
alexander92, that should be the only possible way
<mq32>
it doesn't make sense to compare ?f32 to ?i32
<alexander92>
yes, just asking in case
<bgiannan>
for me two null optional should be equal
<alexander92>
does zig support something like "recursive" == for structs ?
<mq32>
yes
<mq32>
std.mem.eql
<alexander92>
hm, but does this work recursively: i guess it directly compares memory
<alexander92>
e.g. if you have a field which is a different struct
<alexander92>
does it compare a.b == other.b (comparing their fields as well)
<alexander92>
i am mostly interested in trees: in nim i find myself often reimplementing `==` for my trees
<mq32>
for trees, you have to compare manually
<mq32>
because zig can only compare pointer values, but will *never* dive into a pointer to compare the contents pointed to
<alexander92>
i see, and i guess zig is against custom operator overloading
<mq32>
correct :D
<alexander92>
ok, just read about generic structs as a result of comptime functions
<alexander92>
interesting approach
<mq32>
it's great
<alexander92>
can you have something like constraints
<alexander92>
like this
<mq32>
much more readable than most other approaches on metaprogramming i've seen
<alexander92>
e.g. you don't take fun(T: type)
<alexander92>
but something like
<alexander92>
fun(T: hashableType)
<gonz_>
No constraints on generics, no.
<alexander92>
but it does seem like something possible to me
<gonz_>
I would recommend taking a comptime function or a set of functions if you want to parameterize behavior.
<mq32>
gonz_, we can have trivial constraints on generics
<gonz_>
mq32: What do you mean by that?
<alexander92>
so i should write t: type
<alexander92>
and then comptime { if not hashable(t) .. comptime error }
<mq32>
if (MyConstraint(T)) { @compileError("MyConstraint not met for T"); }
<alexander92>
?
<alexander92>
yes
<mq32>
well, there's a "not" missing, but you get the point
<gonz_>
This isn't really needed with a set of functions, though.
<mq32>
huh?
<alexander92>
how can it be written with set
<gonz_>
It's much clumsier than a function parameterized on a set of interface functions
<mq32>
?
<alexander92>
i think those constraints can be much more powerful tho
<alexander92>
as you can run custom code inside of them
<mq32>
gonz_: i think you're missing something here
<alexander92>
similar to concepts
<mq32>
"This generic is restricted to integer types only"
firefox317 has quit [Remote host closed the connection]
<gonz_>
What's more powerful than guaranteeing that you're passed an actual implementation of a desired behavior?
<alexander92>
but how can you express it with a set
<gonz_>
I think you're over-analyzing the wording. "set" as in a struct of functions.
<alexander92>
in a function you can say something like "this type should have this function defined , this field defined and its name should start with X"
<alexander92>
what you're describing is simpler interfaces imho
<alexander92>
i am more thinking of concepts
<gonz_>
No, they accomplish the exact same thing.
<alexander92>
not really
<gonz_>
You're thinking of a clumsy way to write type classes, essentially.
<alexander92>
well, can i describe every possible statement
<alexander92>
about a type with a set
<gonz_>
You can describe how to hash a type, how to get a certain piece of data from a type, etc.
<fengb>
Type classes are Turing complete so yes probably
<alexander92>
but not stuff like "it has such an operator"?
<gonz_>
You would be passing an implementation of that operator in that case, probably.
<gonz_>
That is an existence proof of the operator being available
<gonz_>
with the correct types
<alexander92>
so basically the solution is to write a special function for each of those statements
<gonz_>
Now, could you have an issue in a language that can't refer to operators as functions? Yes.
<fengb>
There’s an (oldish) proposal on constrained types
<alexander92>
yeah, i meant something like that mq32
<gonz_>
alexander92: A piece of that interface can refer to already existing things, if they do exist.
<alexander92>
the point is that many things that are just a "function" of the type, which are not existing overloads of it
<companion_cube>
D has checks on parameters, and its comptime is close to zig's
<alexander92>
e.g. my extreme example of "the name of this type starts with i"
<mq32>
also a type has more properties than "interface" and you want to restrict on those properties, too
<gonz_>
I think this is mostly a question of unfamiliarity with this style than anything
<alexander92>
not really, interface style just checks the existance of certain overloads
<alexander92>
this is just one class of things you can check for in a type
<gonz_>
You can effectively say things like "this field exists" by simply saying "a function that takes that thing and returns whatever that field is supposed to contain exists"
<mq32>
yes
<alexander92>
so, how would my exampel of "this type starts with I" work
<mq32>
but you cannot make an interface that says "is this type an integer type"
<mq32>
because there is more than object types
<mq32>
(or: struct types)
<gonz_>
mq32: If a function that takes that type and returns an integer exists, it's an integer type
<alexander92>
but is this true
<alexander92>
i can define a "function" for a string
<gonz_>
I'm not saying we shouldn't ever inspect types or whatever, but that interfaces are a much better parameterization method than anything else.
<mq32>
gonz_: still my question: can you make an example that has the exact same properties of my example posted above?
<mq32>
i cannot imagine that your proposed style will work with that
<gonz_>
Your example effectively does nothing.
<mq32>
it does
avoidr has joined #zig
<gonz_>
This would effectively be one small part of an interface. Again, I'm not saying inspecting types is bad in itself, but if we're talking a library allowing you to change behavior, the things it exposes should probably not be relying on stuff like this.
<mq32>
just imagine that struct { … } does something useful that requires the properties checked above
<gonz_>
I think you'll have to illustrate your point a bit more because I'm not seeing anything useful here.
<mq32>
okay
<mq32>
my function Bitset creates a type that implements bitsets
<mq32>
and you can specify an underlying type here
<mq32>
(like u8, u16, u32, ...)
<mq32>
but: you are not allowed to pass any other type than "unsigned integers of any size"
<gonz_>
Sure, ok. This doesn't rely at all on any kind of additional type from the user?
<mq32>
because that is illogical and the code wouldn't compile
<mq32>
it relies on a type that must meet the requirement "unsigned integer"
<gonz_>
This isn't applicable if it doesn't involve extending behavior of some kind.
<gonz_>
You're querying a type for something it shouldn't ever extend, no?
<mq32>
i can also make restrictions with "sizeof the type must not be larger than 32 bytes"
<alexander92>
exactly
<mq32>
sorry, i don't understand the question well
<gonz_>
What we were discussing above is about parameterizing someone elses functions with your own types. You're querying a built-in that can only strictly be a built-in for type info.
<gonz_>
I don't think these things are the same.
<alexander92>
stuff like "sizeof of t should be in range X, other property of t should be y" require custom code
<mq32>
yeah
<alexander92>
maybe you can define a "myCustomSizeofRequirement" function for them and include it in your set? but that's just another way to do the same
<mq32>
i can also make something like a special type structure where any user type may be embedded, but that user type must not exceed 8 bytes
<mq32>
because it will be stored in a register
<mq32>
or such
<mq32>
this is also something i cannot solve with "interface specifications"
<gonz_>
These `sizeof` checks could be in the plumbing, sure, but that's just one part of all of this.
<gonz_>
I can agree with you that they have uses, but when you start extending it to "it has this field", etc., that's much better expressed by an actual function that pulls that information out.
<alexander92>
but isn't this the if not customFunction(t): .. compile Error method
<gonz_>
The proposed `fn f(T: HashableType, ...)` isn't at all a question of merely these `sizeof` checks, etc.
<alexander92>
oh i don't propose that
<alexander92>
i just wondered how it works
<gonz_>
and to implement them like that would most likely be the wrong way to go about it
<gonz_>
companion_cube: Presumably, yes. If they're compile-time constraints on generics.
<companion_cube>
they are, yes
<companion_cube>
using comptime function and comptime reflection, as in Zig
<companion_cube>
(I mean, lots of ideas where borrowed from D, right?)
waleee-cl has joined #zig
<gonz_>
I don't know if andrewrk has talked exhaustively about his inspirations, but one would assume.
<andrewrk>
more like independently discovered, but there's not really a difference
laaron has quit [Remote host closed the connection]
laaron has joined #zig
rohlem has joined #zig
<gonz_>
I like working with type classes / concepts / whatever you want to call them
<gonz_>
But in reality they're just hiding a passed interface
<companion_cube>
andrewrk: signs it's a good idea then :)
<gonz_>
The Haskell implementation works exactly like that; at compile time the type class is discovered (this is done globally and unless otherwise stated multiple implementations are a compile time error) and implicitly passed at the call site, then usually optimized out later.
<companion_cube>
but in haskell you can also have runtime dispatch
<companion_cube>
like, if you have an existential type
<mq32>
gonz_, i still don't agree, because type properties like size/alignment/... are also part of a type, but are not part of the interface itself
Tetralux_ has joined #zig
<gonz_>
mq32: When it comes to the proposition of `fn f(T: HashableType, ...)`, for the most part this is about (sometimes implicitly) passed interfaces.
<mq32>
yeah, but then i can use *actual* interfaces instead of type restrictions
<gonz_>
I'm not saying you can't make type guided checks inside the plumbing that uses the interfaces
<mq32>
also it may require that those interfaces are again generic and have the same checkups required as well
<mq32>
or maybe also only require sometimes a function
<mq32>
generic programming is a complicated thing
<gonz_>
It's really not
<mq32>
such like "if this property is existent, we also require this property" is bad to express with interfaces
<gonz_>
Except that could be a function that returns null or a struct with both those things.
<gonz_>
Et voila, "if one, both, if not, nothing"
Tetralux has quit [Ping timeout: 240 seconds]
<mq32>
yeah and this will get complicated :D
<mq32>
i have a ton of specializations in my C++ code just for type distinction (thus requiring a lot of comptime checks to not break things accidently)
<gonz_>
And you don't think playing snakes and ladders with a bunch of `if`s and `@compileError` gets more complicated with all of your checks?
<mq32>
it may be simpler
<gonz_>
Somehow making something that is effectively "If you can provide me this function, you can use the function" is more complicated?
<mq32>
your approach will break as soon as you have (a | b) → c
<gonz_>
Except it doesn't. If `a | b` is an actual union I can provide an implementation for it just as I could for the types alone.
<alexander92>
gonz_ please .. ignore this proposition
<alexander92>
i didn't propose that
<alexander92>
i asked if that's an existing syntax
<alexander92>
i fully agree with mq32 and the if compile Error
<alexander92>
approach
<gonz_>
Like I said, I think this is an issue of familiarity more than anything.
<mq32>
and simplicity
<mq32>
*grin*
<alexander92>
but sorry, you're right: this kind of syntax woudl be expected
<gonz_>
I think doing a bunch of procedural type guided checks is valid for some cases, but I think it seems simpler only to people who don't know the alternatives.
<alexander92>
and indeed, maybe providing this functions can work
<alexander92>
but it seems to me the same amount of work
<gonz_>
This discussion is probably more a product of different communities clashing than anything else.
<alexander92>
maybe, having a set for most cases, and a comptime call for the most "edge" case
<alexander92>
is best
<gonz_>
alexander92: What do you mean by comptime call exactly? The type guided procedural checks?
<alexander92>
somethign similar is being proposed for nim's "interfaces" vs more full "concepts" so that's why it felt similar as a discussion to me
<alexander92>
the if not customFunction(t) .. checks
<gonz_>
Mhm
<gonz_>
alexander92: Interfaces are proposed, by the way. Maybe that got lost in the discussion.
<gonz_>
People are working hard to occlude this already.
<gonz_>
There's even talk about embedding structs and implicitly having the parent struct work with functions expecting the embedded type.
_Vi has quit [Ping timeout: 252 seconds]
<alexander92>
interesting: are there concrete "RFC-s" for interfaces
<mq32>
gonz_, i think those are the main approaches on interfaces right now
<andrewrk>
I also reserve the right to reject all interface proposals if status quo is deemed "good enough"
<mq32>
andrewrk, you are BDFL, you have the right to do that :D
alexander92 has quit [Ping timeout: 265 seconds]
<scientes>
but yeah it is a little too OO-madness for me
<scientes>
like C++ constructors, and other things that are just too complicated for people trying to get stuff done to want to have to care about
<andrewrk>
if I'm able to make a nice widget API without introducing any interface language constructs, it'll be hard to convince me we need anything
<mq32>
andrewrk, yeah i think that's a really good measurement as that is where inheritance really shines in its usefulness
<mq32>
most other cases don't require inheritance
tdc has joined #zig
<gonz_>
Small nitpick: Nothing "requires" inheritance.
<andrewrk>
I tried doing a GUI in c++ without inheritance and I would go so far as to say the use case requires it
<companion_cube>
what's the status quo for interfaces, actually? like, iterators?
<gonz_>
Personally I'm probably just going to sit back and see what happens as it seems inevitable we're getting something crazy in the future. I'll either learn to like it or something else.
<andrewrk>
companion_cube, there's a pattern with @fieldParentPtr you can observe with e.g. std.io.InStream. it has some issues regarding error sets
<andrewrk>
std.mem.Allocator is one with a fixed error set, which is pretty reasonable as far as an interface goes, I think
<gonz_>
andrewrk: A type class like `IsElement` that you would have to implement for your type to be used as an `Element`, does that qualify as inheritance?
<companion_cube>
yeah, embedded structs, as in C, ok
halosghost has joined #zig
<andrewrk>
gonz_, http://genesisdaw.org/post/interesting-commits.html I didn't go into details here but: " When working on widget user interface code, I realized that I was implementing inheritence without actually using C++'s inheritance features, and it was more error prone than just giving in and depending on libstdc++."
<gonz_>
I think there's a class of languages that generally doesn't do GUI very much and I'm prepared to concede that it's because they don't have inheritance (it seems logical and rational), but I don't know that it's an empiric fact.
<companion_cube>
there's also java-like interfaces (bunch of methods with default implementation, bunch of required methods, nothing remains after it's compiled)
<gonz_>
companion_cube: `IsElement` would effectively be an interface of one function: `fn(T) Element`, that when provided allows you to obviously use things working with `Element`
<gonz_>
I don't view this as inheritance, but it does the same thing
<companion_cube>
it's like inheritance without subtyping
<gonz_>
And can also be expressed either explicitly or if implicit interfaces were added you would just implement that trait or whatever
<companion_cube>
if interfaces and types are separate things, you can get the code reuse without the type hierarchy
<gonz_>
I'm curious if this is palatable to people arguing for inheritance
<companion_cube>
I have no idea
<companion_cube>
isn't this whole discussion a bit of an blow to the idea that a C-like language can palate to modern tastes?
<companion_cube>
seems like you always want some level of abstraction and type safety C was never able to provide…
<companion_cube>
(see: generics)
<gonz_>
I think everyone accepts a certain level of additional stuff on top of C, the question is just how much you're willing to accept.
Aransentin has quit [Ping timeout: 260 seconds]
<companion_cube>
👍
<fgenesis>
i'll just throw in the design philosophy of Lua, that doesn't even have OO, but with a bit of syntactic sugar and a bit of custom code you can even do multiple inheritance if you want
<fgenesis>
so in any case i'd prefer a syntactic sugar solution over a language feature
<fgenesis>
because that one was really done right, imo
<companion_cube>
lua has a ton of dynamic dispatch though
<fgenesis>
like function X:foo(y) being equal to function X.foo(self, y)
<fgenesis>
yes, it's a different concept and all that, i know. but i like the idea
<fgenesis>
keep the language KISS but the nice stuff comes with syntax sugar
<companion_cube>
yeah, I like that too
Pursche01 has quit [Quit: Connection closed for inactivity]
<andrewrk>
fgenesis, oh neat I didn't know lua had exactly the same zig "method" syntax as zig
<fgenesis>
lolwhat
<fgenesis>
i must admit i forgot/never knew how zig did methods
<fgenesis>
but if it's done like this it makes so much sense
<fgenesis>
because the lua syntax is awesome for that very purpose
alexander92 has joined #zig
<fgenesis>
and given an optimizing compiler and loss of dynamic dispatch this is still a super powerful concept
<andrewrk>
in zig X.foo(self, y) is equal to self.foo(y) when @typeOf(self) == X
<fengb>
Lua is prototype based OO
<fgenesis>
lua has . vs : to support the sugar but aside form this it's similar yea
<gonz_>
andrewrk: Given a comptime known function taking a struct S and returning just a field from that struct, does the compiler optimize it to exactly a field access at the moment?
<fgenesis>
godbolt it? :P
afon has joined #zig
<andrewrk>
scientes, today's the day, I'm merging your SIMD branch. 1/27 commits done so far
<companion_cube>
🎉
<andrewrk>
wow, emojis work after I upgraded to xfce 4.14. I'm truly living in the future now
<companion_cube>
have you also installed noto or some similar font? :)
<companion_cube>
welcome to the future andrewrk 🌈✨
<fgenesis>
i can see emojis but i wish i didn't
<tgschultz>
^
<fgenesis>
at least on my XP they are broken and i'm glad they are
<gonz_>
What are you using that doesn't allow you to turn them off?
<companion_cube>
I'm just having too much fun with them, sorry fgenesis
<fengb>
🤮🤯💩
<fgenesis>
fengb: first 2 are broken, last one is poop?
<gonz_>
Puking, mind blown, poop
<fengb>
First two are too new for your font :P
<fgenesis>
yeah, still partially broken. all is well.
<fengb>
You could hack your font files and remove all emojis
<companion_cube>
LANG=C and you'll be alright
<fgenesis>
honestly i prefer 8====D instead of (eggplant icon) :P
<companion_cube>
or is it LC_ALL
<tgschultz>
I have emotes off in my IRC client and they still show up because unicode has declared them officially something people should care about. *sigh*
<fengb>
I should use emojis for all of my zig variables
<mq32>
<fengb> That's still more readable than APL
<mq32>
that sentence is invariant. you can apply this to *everything*
<mq32>
but APL is kinda awesome
<fengb>
I'm sure we can make an APL++ :P
<mq32>
andrewrk, scientes: i'm really excited for the vector/simd merge!
<fgenesis>
so it's an autovectorizer, or..?
Akuli has joined #zig
<fgenesis>
simd vector types as bultins?
<waleee-cl>
If you think APL is bad, wait till you see Agda
<donaldallen>
@fengb Linked list example very helpful.
<waleee-cl>
In APL you at least cannot define new unicode operators
<mq32>
fgenesis: zig has support for @Vector(4, i32) SIMD types
<mq32>
so you have native SIMD type support in the language that gets emulated on non-simd platforms
<fgenesis>
noice
<andrewrk>
it's a lot easier for the compiler to devectorize vectorized code than to vectorize non-vectorized code
<fgenesis>
wait so you can @Vector(64, i32) for maximal wideness and it gets properly translated into AVX2 if you have that?
<andrewrk>
yes
<fgenesis>
andrewrk: saw that at a university project back in the day. the thing took DAYS to vectorize a recursive raytracer, and it did a horrible job
<fgenesis>
very nice tho
donaldallen has quit [Ping timeout: 260 seconds]
<companion_cube>
llvm does vectorize a bit
Yardanico has joined #zig
alexander92 has quit [Ping timeout: 240 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
<gonz_>
Does anyone else find that they're fiddling more with trying to get zig to not optimize everything away than discovering what they're trying to discover on godbolt?
<gonz_>
https://godbolt.org/z/_VG95V <- anyway, these two ways of getting an embedded struct seem to optimize the same way
<andrewrk>
gonz_, you have to relate the input to the output. use an export function instead of main
<gonz_>
Anyway, in contrast to other forms of embedding you don't have to own either the interface or the data type to provide a function in this case.
<gonz_>
If there was an `Element` deeper in the hierarchy there would be no weird language rule that said it had to use a certain keyword or be in the top level of the struct
<gonz_>
`hasField` could never replace it in terms of usefulness
<halosghost>
waleee-cl: I love agda
<halosghost>
waleee-cl: that functions and operators are the same thing is absolutely lovely and I wish more languages embraced it
<companion_cube>
crystal does it too, woo
<halosghost>
waleee-cl: it's the only language I know of where not only can you define your own operators, but you can define operators with higher arity than 2
<halosghost>
companion_cube: really? can it define ternary operators?
<andrewrk>
ya'll are lucky zig even has the + operator
<companion_cube>
halosghost: I don't think so
<halosghost>
andrewrk: lol
<companion_cube>
andrewrk: did you mean "y'all" ? :p
<halosghost>
companion_cube: yeah; that doesn't shock me. like I said, agda's the first language I've seen to support it
<halosghost>
but I love it
<halosghost>
:)
<companion_cube>
it's basically only in proof assistants
<fengb>
Dirty yank doesn’t know how to spell y’all
<companion_cube>
(pretty Coq has something similar)
<companion_cube>
fengb: exactly
<andrewrk>
zig is not a DSL for math; it's a DSL for machine code
<halosghost>
andrewrk: so I can't have my 🐼 operator? ):
waleee-cl has quit [Quit: Connection closed for inactivity]
doesntgolf has joined #zig
spazzpp2 has quit [Ping timeout: 240 seconds]
waleee-cl has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
afon has left #zig [#zig]
drasko has joined #zig
<Sahnvour>
andrewrk: can I presently have a build step that produces a library, and another step building an executable that uses said library with its header ?
<andrewrk>
Sahnvour, if I remember correctly that works and even has test coverage
<andrewrk>
and using the build API will automatically set up the directories and such to make that work
spazzpp2 has quit [Read error: Connection reset by peer]
<Sahnvour>
ok so I just need to find the right function, cool
<Sahnvour>
I find the build system is the hardest part of zig's library to grasp without doc
<andrewrk>
I think foo.linkLibrary(bar) should do it
<andrewrk>
agreed. the interface is a bit arbitrary and the declarative nature is not clear
rohlem has quit [Ping timeout: 260 seconds]
<andrewrk>
that function automatically sets up a step dependency, include directories, and inherits dependencies on system libraries
<Sahnvour>
andrewrk: seems to work :) thanks
<andrewrk>
there will be some breaking changes with the package manager as well
<Sahnvour>
iirc someone also mentionned adding vcpkg support, do you know more ?
<andrewrk>
detecting sytem packages is in scope. linkSystemLibrary should be improved to handle the use case
DixiE76 has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<DixiE76>
Hi, I am new to Zig and was wondering if there's a common directory in which I can place libraries so that the build system will be able to link with them and locate headers when provided with a line like `exe.linkSystemLibrary("LibName")` in build.zig
<DixiE76>
To clarify, this is on Windows
<andrewrk>
DixiE76, you can give --library-path and -isystem args to zig so that it can find your system libraries
<andrewrk>
there is no standard on windows
<andrewrk>
the planned package manager will help with this
<DixiE76>
That's a small shame. Is there an ongoing repo for the package manager or is it not quite at that stage yet?
<andrewrk>
not quite at that stage yet. In this release cycle (0.5.0 is to be released sept 30) the groundwork is laid; in the next release cycle we'll have std lib networking, and then finally start on the package manager
<andrewrk>
the good news is that the package manager can be almost entirely self-hosted
<DixiE76>
That sounds quite exciting, I'm jumping it at an interesting time. Is the Master documentation on the website a decent reflection of current state leading up to 0.5.0?
<andrewrk>
yes
<andrewrk>
there will also be comprehensive release notes available when 0.5.0 is released. I've started typing those up already
avoidr has quit [Remote host closed the connection]
<DixiE76>
Very cool, thanks for your hard work. I appreciated the doc page very much as well and will no doubt refer back to it quite often
drasko has quit [Ping timeout: 276 seconds]
<mikdusan>
heh I mounted a tiny ramdisk for building zig (cmake's build dir). all kinds of fast
wootehfoot has joined #zig
<fengb>
Builds are super snappy now that we use zig build for userland files
<fengb>
Oh I've also been spoiled by NVME >_>
<scientes>
only if you have butt-loads of ram
_Vi has quit [Ping timeout: 268 seconds]
<andrewrk>
scientes, I think I'm going to be able to merge 5 ish commits from your SIMD patch set today. I started with the first and have been working my way towards the last. Would you be willing to chop off the merged commits & rebase after today?
<andrewrk>
(after they land in master)
<andrewrk>
basically I'm treating the pull request as a priority queue of commits
<andrewrk>
after each one I have a few fixups
<andrewrk>
I think if we move std/ into lib/ then zig's feature where it looks for lib files will correctly find them directly from source with no install step necessary, if the build directory is a subfolder inside the source dir
<andrewrk>
then this step can be removed from make. as long as `make install` does the right thing we will be good
<andrewrk>
no PRs for that plz, the hard thing about that is only the timing of when to do it
Yardanico has quit [Ping timeout: 246 seconds]
DixiE76 has quit [Remote host closed the connection]
<andrewrk>
Sahnvour, question about hash.auto_hash.test "testHash vector" which is failing in my branch - why is [_]u32{ 1, 2, 3, 4 } not allowed to hash to the same value as [_]u31{ 1, 2, 3, 4 } ?
Akuli has quit [Quit: Leaving]
<andrewrk>
it seems weird to make guarantees about what will or won't hash to the same value across different types
<andrewrk>
this is the proposed diff which I will go with unless you have an objection: https://clbin.com/HtS9e
_Vi has joined #zig
<Sahnvour>
andrewrk: I think it was expected to have different results because the u32 one has no padding bits in it and can be hashed as a []u8, whereas the u31 one has to use the iterative hash api, which (at some point) had different results
<Sahnvour>
cf fn hash() for .Vector
<Sahnvour>
maybe it's not relevant anymore since tiehuis improved our wyhash implementation
<andrewrk>
I think the typical usage will be comparing hashes for the same type
<Sahnvour>
I agree with your diff
<andrewrk>
ok
drasko has joined #zig
<drasko>
`in the next release cycle we'll have std lib networking, and then finally start on the package manager` - what will be actually available in stdlibs as networking primitives? Sockets, TCP server, UDP server, HTTP server?
<drasko>
andrewrk, ^
<andrewrk>
sockets / TCP/UDP server is low level enough to belong in std lib. HTTP client is needed by package manager, and will need to be tested... which menas we need an HTTP server
<companion_cube>
do you really need the tests to be self hosted as well?
<andrewrk>
not at first
<andrewrk>
but it certainly makes them more likely to get run
<companion_cube>
:D
batok has joined #zig
<companion_cube>
I guess it's a fair point
<companion_cube>
even a basic http1.1 server can be useful, I imagine, if it's going to be behind nginx
<andrewrk>
especially for tests
<andrewrk>
mocking a server is a pretty good way to do integration tests
<companion_cube>
I imagine it could also serve docs, then
<companion_cube>
`zig serve docs` so you get them on localhost:8000 or something
<andrewrk>
I don't think it's unreasonable to have an http server in the std lib
<andrewrk>
whether or not it eventually gets moved to a package is also a fair consideration
<companion_cube>
I guess a basic http parser isn't actually that hard, yeah
<andrewrk>
it's also a good demonstration of how to write such a thing such that it handles errors & allocation correctly
<andrewrk>
and async
halosghost has quit [Quit: WeeChat 2.6]
spazzpp2 has joined #zig
spazzpp2 has quit [Client Quit]
mahmudov has quit [Ping timeout: 265 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<_Vi>
Is there such thing as Zig REPL?
<_Vi>
(to navigate around available fields of something using tab completion)
<_Vi>
There's `zig-clap`. Can there be `zig-structopt` (command-line interface definition by specially annotated struct, where doccomment automatically gets populated to --help message)?
<andrewrk>
that issue is easy to find; it's the oldest open issue
<andrewrk>
I don't want people using doc comments as ad hoc attributes
<_Vi>
How much of Zig currently lives in Github Issues instead of the source code itself?
<andrewrk>
are you asking how much of it is vaporware?
<andrewrk>
or.. how much is left to do?
<_Vi>
(Remembering asking about Tahoe-LAFS, where there are Trac issue for every idea that comes to mind, but most are multiple years unimplemented)
<andrewrk>
the language reference is up to date and describes status quo, tested features
<andrewrk>
every github issue is associated with some incomplete task
<andrewrk>
so... decide for yourself. there's a table of contents in the lang ref, and labels & milestones to help navigate github issues
<_Vi>
(about #21) Maybe exposing doccomments in TypeInfo can be the first step? Actual generator may be just a special comptime call from the source itself.
<andrewrk>
you can get a sense of how fast things progress with the release notes from previous releases
<andrewrk>
we've considered this approach at length. it's a dead end.
<_Vi>
How "milestone" things are used on Github issues for Zig? I see a milestone attached to issues very often, but I also see milestone bumps often.
<andrewrk>
milestones represent the current plan for when things will be done. however zig is currently released on a schedule, so the progress of time means things have to get postponed
<andrewrk>
I'm currently a few days behind on postponing issues
<_Vi>
So for now the thing to stuff with meta-things is `StructField.name`. Is having special trinkets at the end of identifier name for poor man's tags for metaprogramming "zen"?
<_Vi>
[about milestones] Does all worthy things get a next version milestone, or some ideas explicitly milestoned e.g. 3 versions ahead, knowing it won't be done soon?
<andrewrk>
milestones are: current release cycle. next release cycle. 1.0.0. 1.1.0
<_Vi>
OK.
samtebbs has quit [Remote host closed the connection]
<_Vi>
Documentation mentions for booleans: `warn("{}\n{}\n{}\n", true and false, true or false, !true);` What is `!true`? Just "not true" (i.e. false) or it is related to `!` error handling?
<_Vi>
On one hand this place is logical place to introduce logical "not". On the other hand, it is queer that `and` and `or` is letters, but `not` is sigils.
<Tetralux_>
I find it especially useful for a constant that toggles special behavior (e.g. profiling); it's nicer to just put or remove the bang than it is to change the word 'false' to 'true', for instance.
<_Vi>
What is rationale for using `!` instead of `not`? Keep it congruent with `and` and `or` and leave `!` just for error processing things...
<_Vi>
Like if somebody wants to get away from C legacy in operators, but still cannot overcome some inertia...
<andrewrk>
`and` and `or` modify control flow
<andrewrk>
all keyword operators modify control flow
<andrewrk>
no control flow is modified without keywords
<scientes>
which is why | and & have to work on bool (or at least vectors of bool)
<_Vi>
OK, now understand. At first I though it's like Perl's `elsif` - just because of author wants so.
<scientes>
because a() | b() is differn't from a() or b()
<andrewrk>
scientes, I'm thinking that `and` and `or` will be compile errors with vectors, what about you?
<scientes>
andrewrk, that's what I have
<andrewrk>
sounds good
<scientes>
but if a() and b() return bool, a() | b() and a() or b() are differn't
<andrewrk>
I'm merging 76f53960778e84ab49730edb77b85490b07fbea2 (@byteSwap) now, that's probably all I'll have time for today
<scientes>
the former always executes b()
<scientes>
I read your fixups and was really happy with them
<andrewrk>
oh good
<Tetralux_>
What's that one about?>
<andrewrk>
Tetralux_, SIMD
<Tetralux_>
Hmm.
<_Vi>
Is Zig's `unreachable` more like Rust's `panic!()` or like Rust's `std::hint::unreachable_unchecked()`? Does it depend on `--release-safe`/`--release-fast`?
<scientes>
_Vi, it traps with debug safety
<scientes>
which is how assert() is implemented
<_Vi>
scientes, Is it guaranteed to trap with `--release-safe`?
<scientes>
yes
<Tetralux_>
Short version: It's kinda like noretyurn; it means "If you reach here in safe modes, abort.
<scientes>
well, unless you use @setRuntimeSafety(false);
<Tetralux_>
noreturn*
<andrewrk>
scientes, I really like what you did with ~ for @shuffle
<_Vi>
`@setRuntimeSafety(false)` -> Does it mean safety can be partially enabled - for some parts of the project yes, for other modules no?
<scientes>
_Vi, the point is that well-debugged performance critical code, like a hash table, can be compiled for performance
<andrewrk>
_Vi, yep that's the idea
<Tetralux_>
@setRuntimeSafety(false) means "Disable runtime safety (like bounds checks) for the current scope. (but only this scope - i.e: it won't propagate into function calls.)
<_Vi>
Is three some special option like `--debug --force-safety` to temporarily disable that `@setRuntimeSafety(false)`? The reverse can also be useful.
<andrewrk>
that's a good question and I've thought about that but not done anything about it so far
<_Vi>
By the way, is language-level sandboxing in Zig (using it's safety features) a considered idea?
<Tetralux_>
What does that mean?
<andrewrk>
_Vi, that is not a feature that is available or planned
<_Vi>
Tetralux_, It means compilation and running of untrusted user-contributed code with main security at API level - what imports are available and what is not.
<andrewrk>
it means you could use the language to guarantee that, e.g. a function call and everything it calls is limited to a white list of things it can do (no wild pointer access, no inline assembly, etc)
<andrewrk>
_Vi, I'm not sure that has been explicitly proposed so far. you are welcome to do that
<_Vi>
Tetralux_, Examples: WebAssembly, Safe Haskell (maybe), some Java things (maybe?), JavaScript in browsers...
<Tetralux_>
Sounds like a VM.
<andrewrk>
zig does support web assembly
<Tetralux_>
Or, in andrewrk's case, a builtin.
<Tetralux_>
Or other related compiler analysis.
<Tetralux_>
andrewrk's version is more like the opposite of 'unsafe' in Rust.
<Tetralux_>
i.e: 'safe { ... }'
Tetralux_ is now known as Tetralux
<_Vi>
Tetralux_, There can be sandboxing without VM. But it's tricky, especially with all those spectral meltdowns...
<andrewrk>
zig's safety features cannot guarantee memory safety completely
<Tetralux>
I'm not sure anyone could have mitigated against spectre or meltdown, even with sandboxing. That's not very clear to me.
<Tetralux>
But sure - I could see that being a use for being able to hook into the compiler
<Tetralux>
"Please compile this file, but tell me about certain things so I can prevent certain behavior"
<_Vi>
"Safe language" is juts a first step in language-level sandboxing. Is there any LLVM-based programming language targeting native code that is designed around language-level sandboxing?
<Tetralux>
One of the options that you could enable could be this.
<Tetralux>
Those two things sound separate?
<Tetralux>
Or well - no - I think I see what you mean .
<andrewrk>
D has some of these features
<andrewrk>
Rust is the most noteworthy contender
<Tetralux>
You thinking of the 'return scope int x' func args?
kristoff_it has joined #zig
<_Vi>
andrewrk, I remember opening discussion about sandboxed Rust.
<kristoff_it>
andrewrk: WRT async / await, I was able to get simple usage of the redis client work first shot. Once I moved into more complex stuff I got segfaults and a "non dominating instruction" error
<kuon>
What do you think of the pipe operator? like foo |> bar |> joe being joe(bar(foo))
<andrewrk>
kristoff_it, I'm aware of both those issues; working on it
<kuon>
I have been working with elixir and elm lately, and I really like it.
<andrewrk>
kristoff_it, was your experimentation before or after cf4bccf76566ac112f9142863c3e4dbf81e71d08 ?
<presiden>
what does language-level sandboxing means?
<kristoff_it>
andrewrk: yeah I remember you mentioned that stack traces were not working, I didn't push further also because of that, I remembered your recommendation to wait
<Tetralux>
presiden: It means sandboxing, that the compiler enforces on Zig code.
<presiden>
by limiting the feature that available?
<presiden>
in sandbox mode?
<andrewrk>
yes; for example one would probably disable @intToPtr
<_Vi>
presiden, It means accept user code, compile it (guranteed not to crash or hang compiler), run it (guranteed not to access only allowed API) security, without any hardware or OS sandboxing.
<_Vi>
*securely
<_Vi>
presiden, Imagine Java's `SecurityManager`, but the one which actually works, and for native code.
<Tetralux>
_Vi: You mean at runtime?
<kuon>
isn't that kind of security feature best left to the OS?
<Tetralux>
Like, compiler as a service, style thing?
<_Vi>
Tetralux, What at runtime? Decisions to allow or forbid particular API? Not necessarily...
<Tetralux>
It's not clear to me who the "user" is in your description.
<Tetralux>
But I'm reading it as "Build a program which loads code at runtime and compiles it, but it runs sandboxed.
<Tetralux>
i.e: Like what Lua is used for now.
<_Vi>
Tetralux, Compiler as implementation detail... Imagine an embedded computer without operating system and without MMU. You need to run untrusted code on it, and the code must be fast and aggressively optimized (so no interpreted or VM). You need language-level sandboxing.
<kristoff_it>
andrewrk: just checked, I did have that commit.
<andrewrk>
kristoff_it, noted. yeah I experimented a bunch with the segfaults. I think there's some kind of thing going on with stack probing but I need to investigate further
<andrewrk>
it's not normal for programs to access e.g. 7 MiB offset from the stack pointer, but with zig's async/await it makes perfect sense
<andrewrk>
so we may need to ...negotiate... with the OS to make it work
<_Vi>
What `type` type becomes at runtime? Some integer tag?
<Tetralux>
_Vi: I mean, a compiler is _how_ you'd do it - no?
<Tetralux>
Like, nothing abstract about that xD
<andrewrk>
_Vi, values of type `type` are only available at compile time
<_Vi>
andrewrk, How to interpret this documentation snippet then: `const normal_bytes = "hello"; assert(@typeOf(normal_bytes) == [5]u8);`. This looks like a run-time assert.
<andrewrk>
Tetralux, the use case divides the code into 2 components: a trusted component, and an untrusted one
<andrewrk>
_Vi, indeed it is, although it would work just fine to put `comptime assert(...);` there. The code gets compiled down to assert(true);. See also https://github.com/ziglang/zig/issues/425
<Tetralux>
andrewrk: Indeed; depending on exactly how it's set up, I'd essentially boil down to little more than a build option though.
<Tetralux>
It'd
<Tetralux>
.. And how one program just runs the compiler at runtime.
<Tetralux>
"Let's get meta up in here!"
<_Vi>
Does it collapse to `assert(true)` even in debug mode?
<kristoff_it>
_Vi: types evaporate during compilation. At runtime you are left with a bunch of unptyped bytes, but you know that the operations on those bytes make sense because the compiler was able to confirm that at comptime (when types were still a thing).
<_Vi>
Isn't replacing `x == x` with `true` an optimisation to be triggered not every time?
<kristoff_it>
if that's what you were asking
<Tetralux>
The expression runs at comptime because the expressions are both constants.
<kristoff_it>
_Vi: in that specific case, those are both types, they have no runtime representation so it has to be solved at comptime
<Tetralux>
And so it evals to the constant 'true' for runtime.
<_Vi>
Can there be situations in which the code compiles in release mode because of optimiser removes code involving types, but fail to compile in debug mode because of types get retained?
<kristoff_it>
yes
<Tetralux>
kristoff_it: Can you name an example?
<andrewrk>
if (builtin.mode == .Debug) @compileError("foo");
<kristoff_it>
yeah andrew beat me to it
<Tetralux>
That doesn't fail in debug _because a type is retained_ though.
<kristoff_it>
but if you have a "type that gets retained", you actually get a "this variable must be comptime" error
<andrewrk>
debug mode is unrelated to types
<Tetralux>
andrewrk: That's what makes it a bad example xD
<kristoff_it>
_Vi: experiment with the language a bit more, you will start to get an idea of what you can do or not do. On paper what you're saying is reasonable, but once you write a few programs you'll get a better "gut feeling" of how types interact with the rest of the ecosystem
<_Vi>
Types and values are closer to each other in Zig compared to other compiled languages I used...
<_Vi>
Are there niche-filling layout optimisations in Zig besides optional pointers?
<kristoff_it>
andrewrk: last time only tests 1 and 2 worked, 3+ caused various problems. Now 3 passes, but 4+ still have to be commented out in order for the program to run
<andrewrk>
kristoff_it, I'll have a look at these after the test cases I'm working on pass
<kristoff_it>
I suspect that I might have an error in 4 when defining FrameType, but I'm not sure.
<kristoff_it>
andrewrk: thanks!
<andrewrk>
scientes, this should be separate from your SIMD stuff, but I think @byteSwap should be defined to operate relative to the ABI size, not the size_in_bits
<andrewrk>
I'll make a proposal later tonight, but a good example is u24. instead of @byteSwap(u24, 0x123456) -> 0x563412; I think it should be @byteSwap(u24, 0x123456) -> undefined
<Tetralux>
Sounds like something that should be safetychecked.
<THFKA4>
there are no guarantees on how an array of u4's is going to be packed, right? each element is still likely to use 8 bits?
_Vi has quit [Ping timeout: 245 seconds]
<THFKA4>
basically trying to do what the docs call "slice narrowing" with weird sizes
<scientes>
andrewrk, LLVM packs the bits
<scientes>
ooo, you mean zero fill?
<scientes>
hmm, I'll read the proposal, cause llvm doesn't implement byteswap for u24 or u56
<scientes>
i felt that was zig does was an improvement
<fengb>
THFKA4: arrays are padded. There's a PackedArray in std