<andrewrk>
BaroqueLarouche, I have Tracy running, now to see if I can get client integrations working with zig code
<BaroqueLarouche>
andrewrk: Keep me updated! I intent to use it in the future with Zig code
<ifreund>
that would be super cool, i would also appreciate a ping if you get it working
<andrewrk>
you got it 👍
<pixelherodev>
Same
<pixelherodev>
:)
st4ll1 has quit [Ping timeout: 264 seconds]
stripedpajamas has quit [Quit: sleeping...]
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
stripedpajamas has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
swills has joined #zig
Snetry has joined #zig
traviss has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
stripedpajamas has quit [Quit: sleeping...]
cole-h_ has joined #zig
cole-h has quit [Ping timeout: 258 seconds]
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
cole-h_ is now known as cole-h
traviss has quit [Quit: Leaving]
Snetry- has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
<Zannzen>
does Zig try to auto-vectorize through llvm or do you have to explicitly use @Vector to get simd?
<Zannzen>
(in release-fast I guess?)
<daurnimator>
Zannzen: yes. though the autovectorizor sort of sucks
<andrewrk>
yes we have auto-vectorization via the llvm backend
<andrewrk>
it's easier for the optimizer to de-vectorize than auto-vectorize
<Zannzen>
yeah, definitely was a tricky thing in c++ when you _needed_ it to vectorize and it wasn't (without using primatives)
<Zannzen>
but in general I'd rather hold off on saying "this uses simd" until I need to / have profiled code
<Zannzen>
so getting auto-vectorization is a nice plus :)
<Zannzen>
thanks
<andrewrk>
np. the idea of having SIMD types is that it lets you express your code in a readable, portable way, that also happens to be easier to optimize
<scientes>
and auto-vectorizing code can be horrible, as is the main reason people avoid -O3 on gcc
<scientes>
but now we are getting predicated SIMD instructions, and the current syntax is not very amenable to that
<scientes>
I was brain-storming that you could have a compound predicated type, that has a bunch of special rules
<scientes>
1. you cannot specify this type in a type signature. 2. it implicitly casts BOTH to non-predicated, and a vector of bools. 3. only one side of an arithmatic can be predicated (or neither).
<scientes>
and then you generate this type by doing: a #= a > b;
<scientes>
the benifit of this set of rules is that if() is still a clear branch, and you still can have vector.any(), vector.all(), vector.none()
<scientes>
you generate those clear branches
<scientes>
**by doing a #> b
<scientes>
which is super-confusing new syntax, but vector predication just works like that
<scientes>
so a #> b would result in a now being a compound predicated type, composed of a and a vector of bools of the result of a > b
<scientes>
"a #> b;"
<pixelherodev>
Predicated vectors? Ooh
<scientes>
pixelherodev, and they are essential for correct code because of things like divide by zero
<scientes>
so that proposal allows us to keep using all are existing operators
stripedpajamas has quit [Quit: sleeping...]
<scientes>
*our
cole-h has quit [Quit: Goodbye]
tdc has joined #zig
<daurnimator>
andrewrk: disregard my comment.... I re-read the whole issue
<andrewrk>
np
cole-h has joined #zig
<daurnimator>
andrewrk: the returned struct... if I passed that to another function that only *used* .function_name and .file_name, would it get optimised to never generate the line/column number?
cole-h has quit [Client Quit]
<andrewrk>
this would not be semantically guaranteed. deleting fields from structs is an optimization that llvm does not have the capability of but the zig language allows
<daurnimator>
seems bad for incremental compilation then
<daurnimator>
if I only used .function_name, and I insert a couple of lines above.... you don't need to go recomputing anything
<andrewrk>
already every decl in a file has a tiny piece of info that has to get updated when any line changes in the file, because of debug info
<andrewrk>
as long as it does not mean regenerating the *body* of a function, it's not a problem
swills has quit [Ping timeout: 264 seconds]
swills has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
swills has quit [Ping timeout: 240 seconds]
st4ll1 has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
swills has joined #zig
traviss has joined #zig
<ifreund>
hmm, do we already have a way to get the name of the current package?
<ifreund>
if not we should probably add that to @src()
frett27 has joined #zig
Amun_Ra has quit [Quit: Gdyby mi się chciało tak jak mi się nie chce…]
dermetfan has joined #zig
Snetry- has quit [Ping timeout: 246 seconds]
Snetry has joined #zig
marnix has joined #zig
FireFox317 has joined #zig
waleee-cl has joined #zig
<mq32>
andrewrk, you are an evil man. I now miss expression-switch in pretty much every language that doesn't have it
<scientes>
mq32, yeah some of the chaining properties of zig are really nice
<ifreund>
i love orelse and catch
<mq32>
using switch-expressions is just so convenient to convert enumerations to display text
<scientes>
and are optional slices represented with null pointers?
<scientes>
in the slice.ptr
<mq32>
not sure, probably yes
<ifreund>
i thinkg there's an open issue for that
<ifreund>
iirc they aren't currently
<scientes>
there is also an issue to allow optionals on integers without costing a bit, but generally think that is a bad idea, and you should just use ?u63 et cetera
<scientes>
we could also add a one's complement signed representation because that has a single unused value, but think that violates the "one obvious way to do things"
<ifreund>
I agree, if the extra bits matter to you encode it in the type
<scientes>
and has limited value
<scientes>
because INT_MIN is already a very funny value
<ifreund>
yeah that seems to be a lot of complexity for little gain
<scientes>
but the compatibility cost of expropiating it is not worth it
<scientes>
and we probably don't have ?u63 optimized yet anyways
<scientes>
that said, we could do it with floats
<scientes>
by using the NaN space
<daurnimator>
mq32: how do you return from a for loop?
<daurnimator>
with `break`?
<ifreund>
daurnimator: break
<Zannzen>
scientes `?u63` is currently 16 bytes optionals aren't currently optimized (other than nullptr) to use padding
<frett27>
hi, finally get rid of memory leak due to leveldb cache configuration (very large default configuration), for my project https://github.com/frett27/iotmonitor
<daurnimator>
there's also a proposal (reliant on int ranges?) that would allow stuffing in optionals elsewhere
<frett27>
works like a charme !
<scientes>
Zannzen, yeah, we already have to handle signed/unsigned (as llvm doesn't do that) so it is quite straight-forward
<scientes>
daurnimator, but we are saying int ranges is a bad idea
<daurnimator>
--> `?@Int(.{min=1, max=255})` -> can be 1 byte
<daurnimator>
scientes: why/where?
<scientes>
right now
<scientes>
daurnimator, it would only make sense for enums
<scientes>
to have the optional packed in like that
<scientes>
and you could do it for floats
<Zannzen>
scientes until you're dealing with a bit that moves within a struct depending on the layout :)
<daurnimator>
why?
<Zannzen>
but it's hopefully on the roadmap for ?T
<scientes>
as Donald Knuth says "premature optimization is the root of all evil."
<scientes>
and us zig people are not skilled compiler optimization writers
<daurnimator>
its not always about premature optimization; but modeling existing data layouts
<scientes>
daurnimator, then you write an adapter
<daurnimator>
?
<scientes>
will Zig have native EDIBIC and ones-complement signed number support?
<mq32>
scientes: EBCDIC is a user-space problem
<scientes>
mq32, not in languages with native unicode handling
<mq32>
ones-complement must be a different type than twos-complement
<mq32>
scientes: huh?
<mq32>
zig files are defined to be utf-8 encoded
<scientes>
mq32, we avoid EDCBIC being a problem by not having unicode as part of the zig language
<scientes>
sure source files are utf-8, but we just use []const u8
<mq32>
errm
<mq32>
it's a user space problem
<mq32>
zig does not have a string type ;)
<scientes>
only because we avoided it
<scientes>
look at ruby and the mess of SHIFT_JIS
<mq32>
ruby has a native string type
<mq32>
→ encoding is a language problem
<mq32>
no native string type → no encoding problems on language level
<scientes>
mq32, what i am saying is that ranged integer types creates far more problem than it solves
<scientes>
it is premature optimization
<mq32>
huh?
<mq32>
ranged integers are not an optimization
<mq32>
it's a type
<daurnimator>
its not mainly an optimization though... its a usability and correctness thing
<daurnimator>
+ data modelling
<mq32>
and something like "putting values out of range as optional markers" is an optimization
<mq32>
ranged integers are wonderful for data modeling
<mq32>
i have a state machine atm
<mq32>
has 14 stages
<scientes>
mq32, yeah just use an enum
<scientes>
we already have that
<mq32>
why should i use a type that could have more values? ;)
<daurnimator>
e.g. I wonder if we can get to the point where if you have a `*[100]T` -> indexing with larger than a `@Int(.{ .min = 0, .max = 100})` would be a compile time error
<daurnimator>
uh, .max = 99
<mq32>
scientes: are you shawn ladden? :D
<scientes>
yes
<mq32>
i think you're missing the bigger point
<scientes>
mq32, ...........
<mq32>
ranged integers re not at all an optimization
<mq32>
otherwise you could call "u8" and "u16" also optimizations on a 32 bit machine
<scientes>
they are
<mq32>
because those are ranged integers as well
<mq32>
s everything except "bignum" is an optimization?
<scientes>
you are getting trapped in abstractions that you don't get what their purpose is
<mq32>
but wait? how do i implement bignum?
<mq32>
their purpose is to model the data i want to process
<scientes>
yes, but modeling of data is a language problem
<scientes>
so you should read up on regular languages, and finite state automata
<mq32>
if i want to store the number of bottles in a beer crate, i need an integer ranged from 0 to 6
<scientes>
that is a finite-state-machine problem
<mq32>
regular languages (as well as FSA) are not able to compute
<daurnimator>
mq32: small crate ;)
<mq32>
daurnimator: yeah, true :D
<mq32>
still
<mq32>
or in general: any non-type 0 language is not able to compute things in general
<mq32>
type 3 for example can only recognize a very restricted type of numbers
alexnask has joined #zig
<mq32>
Finite State Automatons are equivalent to Type 3 languages (or REGEX)
<scientes>
mq32, type 1 out of 4
<mq32>
so i really don't understand what you want to tell me with those
knebulae has joined #zig
<gonz_>
What's the minimal set of things you need to install to be able to compile Zig & C code with Zig?
<gonz_>
I'm curious as to what you could throw together minimally for someone in order for them to have complete access to Zig as a productive tool (that may include compiling C code).
<mq32>
hm
<gonz_>
(On Windows)
<scientes>
gonz_, with the download binaries are statically linked
<mq32>
pretty much all in the lib folder except for probably the compiler_rt
<gonz_>
You need libc
<scientes>
so they don't need anything besides a text editor
<mq32>
gonz_: no, that's an arbitrary restriction we should resolve :D
<scientes>
gonz_, they also need a computer
<scientes>
gonz_, and they do not need libc, zig is a native cross compiler
<scientes>
and more so than llvm/clang (which is also a native cross compiler at the low level) as it comes with all the headers for supported targets
<gonz_>
How so? If you uninstall MSVC and remove your native_libc file from the Zig AppData you can't compile stuff anymore
<mq32>
gonz_: atm that's a arbitrary restriction in zig we should remove
<scientes>
well I don't know much about zig, but I know that the linux zig can compile windows binaries that run in wine
<scientes>
*much about windows
<scientes>
and wine is the only way I run windows
<gonz_>
mq32: Right, fair enough.
<mq32>
we should provide a minimal C environment that provides the minimum std headers
<mq32>
(afaik that's stdarg, stdint, stddef)
<gonz_>
I'm mostly testing this out because I want to see how one would approach having people install it if they want to learn. Obviously you want as streamlined a process as possible.
<gonz_>
Certainly you don't want to tell them to install VS
<mq32>
well
<mq32>
"download the tarball/zip file and go"
<daurnimator>
gonz_: should be fine to not have VS in the first place
<mq32>
should be enough
<mq32>
yeah, you don't need VS at all
<mq32>
the tarball/zip file is enough
<gonz_>
With stuff that needs libc?
<scientes>
maybe they should run a real OS...........(sorry)
<alexnask>
gonz_ It should work without msvc if you compile for the gnu abi
<mq32>
you don't need MSVC at all (tested on win7, win10)
<alexnask>
I havent tested it but not having a native libc shouldnt matter in that case
<gonz_>
`zig build -Dtarget=native-native-gnu` still works, yeah. Why is this not being used by default when MSVC isn't available, though? This isn't the pit of success we would like in that case.
<gonz_>
Or is this possibly something that's cached much deeper?
<gonz_>
I would've thought that removing the `native_libc` file would've dealt with previous settings.
<daurnimator>
there was talk of changing the native target to gnu
<gonz_>
Right, I know, but some level of automatic fallback would be an idea regardless of ones position on that.
<gonz_>
I personally think depending first on stuff shipped with Zig is most reasonable, but even without that it'd be good to have it as a fallback.
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<daurnimator>
gonz_: I think higher importance was placed on avoiding "works on my machine" problems; which fallbacks like you're suggesting tend to lead to
<gonz_>
Right, that's probably true.
<mq32>
but then it would be even better to have "gnu" as the default target instead of MSVC
<gonz_>
For the time being you can sort of get around this by having the following in your build file, maybe in a template
<gonz_>
If you have learners use a template repository with this already in it they'll never even bump into the issue
<gonz_>
... probably...?
<gonz_>
GitHub's new Classroom thing relies heavily on template repositories, so this would fit in that.
frett27 has quit [Ping timeout: 240 seconds]
<gonz_>
scientes: About your comment on "real OSs" before. You might be kidding, but I don't think people realize how less useful Zig would be if people ignored Windows as a platform in the future.
<mq32>
yep
<mq32>
people of the BSD community already complained that we only support stable releases
<daurnimator>
mq32: they expect us to work on random commits of mainline freebsd?
<daurnimator>
how on earth.... ?
<mq32>
^^
<mq32>
i don't thikn it was 100% serious
<scientes>
daurnimator, if they bother to run the CI I don't see why that would be a problem
<scientes>
it is only a problem with LLVM/clang as we are so tightly integrated
<gonz_>
I don't see how one would even suggest using Zig for even utilities at game studios, for example, if the story on Windows would match some peoples' attitudes.
<ifreund>
^
<ifreund>
i mean I'm likely never going to use it on windows myself, but windows support is important
<gonz_>
With that said, the story is much better than most fringe languages and overall I'm not dissatisfied.
<gonz_>
The broader community is a Linux bubble that likes to quip about Windows, but that's the extent of it so far.
<gonz_>
I wonder what the stats on C programmers are like; which platforms they use.
<gonz_>
45.8% of Stack Overflow survey respondents use Windows, 27.5% OSX, 26.6% Linux. Certainly the numbers skew towards Linux more than that when it comes to C programmers.
<gonz_>
But C++ programmers who don't even like C++ are probably a different story.
<gonz_>
And a good portion of those people probably would love Zig.
<mq32>
gonz_: true
<mq32>
a lot of C programmers don't program *for* windows or linux though
<mq32>
embedded world today is still pretty much 100% C
<mq32>
and those people care more about their tools than the compiler toolchain
<gonz_>
Right, that makes a lot of sense too.
<mq32>
like "does that flasher with parallel port still work on windows 10" (the answer is: no, you need to use windows XP or 2000)
<mq32>
<= hopes that the bluepill arrives soon
hspak has quit [Ping timeout: 272 seconds]
dddddd has joined #zig
ask6155 has joined #zig
<ask6155>
hey, I'm still confused about error handling
<ask6155>
assuming args is an argiterator
<ask6155>
var arg = if (args.next(alloc)) |result| {
<ask6155>
} else |err| {
<ask6155>
};
<ask6155>
warn("there is an error: {}", .{@errorName(err)});
<ask6155>
result;
<ask6155>
gives error: expected error union type, found '?std.process.NextError![]u8'
<gonz_>
Right, the thing you unpack from `next` is actually a `![]u8`
<gonz_>
The `var binary_path = ...` there is actually `var binary_path = try (maybe_binary_path.?)`, in a sense.
<gonz_>
So `try result` in your case should yield the `[]u8` you're looking for.
<gonz_>
You'll also need to make sure that you don't have a block not returning anything.
<gonz_>
In your `if` your first block will be a `void` block, so it matches the second. If you want to return from blocks you can `break` results from them.
<gonz_>
`if` is also an expression, so you can use it without blocks: `const x = if (something) true_result else false_result`
hspak has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
cole-h has joined #zig
Zannzen has quit [Read error: Connection reset by peer]
alexnask has quit [Quit: Leaving]
<ask6155>
Hey if argiterator is currently at ./program and there are no arguments then args.skip should return false right? (BTW gonz_ thanks for the help)
<gonz_>
Yes, `false` should indicate that we reached the end, as far as I can tell.
<ask6155>
so if I check args.skip() to be true and then give the program no args none of the code should run right?
<gonz_>
Right, because we haven't skipped anything. But there will always be the first argument.
<gonz_>
So it would have to be skip() -> true, skip -> false if there were no additional arguments.
<gonz_>
If I understand correctly.
blinghound has joined #zig
<ask6155>
but if there are no args then skip should fail because it is at the end
<gonz_>
The first arg on most OSs should be the binary we're running, no?
<ask6155>
yes I'm trying to skip it
<blinghound>
Hi all. I've managed to compile sqlite3 into my zig app, but now I'm getting Illegal instruction errors when running sqlite3_exec()
<gonz_>
Ah, I think I misunderstood your question before. `skip()` will return `true` because it skipped an argument (the first).
<blinghound>
I'm passing in a *sqlite3 connection, and a [*c]const u8 string containing the sql source
<gonz_>
Then you'll get `null` from `next()` if there were no arguments after.
<ask6155>
okay, but that is still weird
<ifreund>
blinghound: zig enables clang's UBSan by default, which is likely the cause
<gonz_>
`skip()` returns `true` if it skipped an argument, so it will guaranteed do it for the first one. Then you'll check for `null` for the argument after to see if there were any.
<ifreund>
sounds like there's some UB in sqlite3
<gonz_>
blinghound: Do you have a source example?
<gonz_>
I have some sqlite3 code running that's fine
<gonz_>
Probably because it's already disabled, maybe.
<ifreund>
part of the reason zig enables UBSan by default is to hopefully reduce the amount of UB floating around in the ecosystem
<gonz_>
blinghound: I would probably define the string as a normal slice and just pass `slice.ptr` to whatever needs it, by the way.
<gonz_>
In the general case
<ifreund>
uh, if it expects something null terminated that's probably not the best idea (I didn't look at the code)
<gonz_>
Alternatively in this case a comptime string, even, though I realize this might not be representative.
<gonz_>
String literals should be null terminated since a long time now, no?
<ifreund>
yes, but a slice isn't
<ifreund>
string literals are [*:0]u8
<ifreund>
which coerces to a slice if that's what you use to store it
<blinghound>
@gonz_ I'm still getting to grips with Zig's slice/arrays/c pointers, would I declare a slice as "var stmt: []const u8 = ..."?
<gonz_>
Right, but in this case it's just a matter of removing the type signature and letting nature do its thing
<ifreund>
blinghound: by the way, there's no need to use [*c] in your code, it should generally only be used explicitly by translate-c
<ifreund>
i would do `var stmt: [*:0]u8 = ....`
<ifreund>
if you're interfacing with C, C will almost certainly expect a null terminator
<gonz_>
blinghound: `const statement = "..."; [...] `...exec(connection, statement, ...)` will do it in this case.
<ifreund>
i was assuming it was var for a reason :D
<blinghound>
@gonz_ gotcha! What would you declare the error_message pointer as before passing it to sqlite3_exec?
<blinghound>
it expects the type [*c][*c]u8
<blinghound>
but is there a better way?
<ifreund>
i'd expect it to be var error_message: [*:0]u8; sql_thing(&error_message);
<gonz_>
My error handling in the toy example is based only on return ints and basic `error` unions with a pointer that I myself fill in with more detail about the errors.
<scientes>
gonz_, thats an enum with data, i.e. error with data
<scientes>
I guess zig already has that with tagged unions however
<ifreund>
was about to say
<gonz_>
Right, but we want a separate construct (because it's nice to special case error enums) with data.
<scientes>
they just don't have such an efficient data structure for it
<scientes>
i.e. compiler lowering
<gonz_>
I've dealt with errors in f.e. Haskell with "just ADTs" and it's not particularly nice.
<gonz_>
Having a special error type that is reasoned about separately is one of the major wins for me with Zig.
<scientes>
syntactic sugar for the default case
<gonz_>
In Haskell you'd end up defining a special error type that unifies all your errors and if you want precision you'll have to define one for each function based on the particular errors it can return.
<gonz_>
Meanwhile we get this transparently via inferred error unions in Zig
<gonz_>
When I do need errors to carry data I think having a pointer to a data structure to fill in is an acceptable solution for now.
<gonz_>
Especially because the inferred error sets buys me not having to create these ad-hoc error unions that I'd have to create in Haskell (or Rust)
<gonz_>
It's basically a meme in all of these languages that you end up returning `Either String ValueYouWant`, i.e "You'll get a string representing the error or the value you wanted"
<gonz_>
The string you get isn't useful for inspection, so you change it to an actual error type. But now when this is used elsewhere, that function is going to have to wrap up that error type in its own error type, because it might have specified its own actual error type.
<gonz_>
Funnily enough Haskell actually has subtyping (which could solve this, in a sense), but only for exception types
<gonz_>
Those aren't used in normal APIs and exceptions for the most part are discouraged.
decentpenguin has joined #zig
<fengb>
gonz_: you're the first Haskeller to say positive things about special error types :P
<fengb>
first I've seen*
<gonz_>
I'd bet. I'm not sure I think most Haskell features are a net positive in the end in general, so I guess that's why. I like it fine in terms of status quo but I think I'd be happier and more productive with something smaller and less involved in general.
<gonz_>
Hence me being here. I think these two have self-reinforced eachother. I'm here because I want something simpler and I want something simpler because I'm here.
<fengb>
Many people (including Haskell and Rust) seem to think that result types are better than builtins for optionals / errors
<fengb>
Generic result types*
<gonz_>
There are other ways of managing them in Haskell but they're considerably more involved and again don't intrinsically give you much.
<fengb>
With optionals... it's mostly just syntax sugar although I prefer Zig's way
<ask6155>
Hey, what's the equivalent for atoi() in zig?
<gonz_>
And people are constantly experimenting with even more type astronaut stuff to manage them.
<fengb>
Errors on the other hand, having "free" mixing of types and stack traces is far more useful than being generic
<gonz_>
+1
nikita` has joined #zig
<gonz_>
ask6155: `fmt` has `parse{Int,Float}` functions, etc.
<gonz_>
`const i = try fmt.parseInt(u32, slice);`
<ifreund>
man i wish we had #1717 already
<ifreund>
it would save me a lot of typing right now
<gonz_>
Lots of `usingnamespace` to mix in into a module?
<ask6155>
Hey, how do I improve (try) to improve the documentation?
<ifreund>
nah, this c library takes a struct full of function pointers
<ifreund>
many of which I want to be noop functions
<gonz_>
Ah
<ifreund>
1717 would let me do all of those in line
<ifreund>
ask6155: the language reference is generated from a html.in file in the main repo
<gonz_>
I think the stdlib browser might still not be updated.
tdc has quit [Remote host closed the connection]
xackus_ has joined #zig
<ifreund>
nope, it's quite out of date
<ifreund>
i just grep in my local clone of the zig repo
dermetfan has quit [Ping timeout: 260 seconds]
<gonz_>
I'll probably do the same at some point, but I've stopped having to jump into the docs for a lot of things since I started using zls
<ifreund>
yeah zls is awesome
<ifreund>
most of the time it just takes me right to the source in the std so I can just read the code
<gonz_>
It's actually strange how good the tooling has become in such a short time
tdc has joined #zig
<ifreund>
speaks to good language design imo, and also a great community
<gonz_>
Indicative of how good it is to start off with a modern mindset, perhaps. I know many old languages that can't provide the same experience, some even if you want to pay for it.
<ifreund>
simplicity and consistency go a long way
<ifreund>
C++ for example is incredibly difficult to parse
stripedpajamas has joined #zig
<ifreund>
with zig parsing is simple, and *part of the std*
<gonz_>
Yeah, there's a lot that goes into this being a much more tractable problem than in many languages.
<gonz_>
With some very real payoff
<ifreund>
what's most impressive is how good zls is at supporting comptime-known stuff
<ifreund>
scientes: neat, though things have gotten more complex since 98
<ifreund>
still though that's less code than I expected
<scientes>
ifreund, its because re2c is a pretty slict regexp compiler
<scientes>
*slick
<ifreund>
yeah looking a little deeper now
<ifreund>
I didn't know this existed
<scientes>
I was looking at tokenizing zig with it
<scientes>
cause out current tokenizer is annoyingly non-regular
marnix has quit [Remote host closed the connection]
dingenskirchen has quit [Ping timeout: 260 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
dingenskirchen has joined #zig
<leeward>
any zls folks around? a45939f8abe3354ad70c10f17558cace623b9e4a seems to have broken things.
<ifreund>
don't see alexnask here, probably best to just open an issue
<ifreund>
i think they tend to hang out more on the discord
<leeward>
Right, there's a discord.
<ifreund>
it's quite active, though very memey at times. and its discord :(
<leeward>
Yeah, being Discord tends to make things a certain way.
<gonz_>
It's certainly its own kind of atmosphere
dermetfan has joined #zig
<gonz_>
I like the idea of having disparate communities around a language, though, I have to say.
<leeward>
Monoculture is bad.
<gonz_>
I never had *one place* to go to for C++ stuff, we used to always just hang out in #c++.se on QuakeNet and that was the only community I needed.
<BaroqueLarouche>
wish we had a native Matrix room
<ifreund>
yeah i'm all for decentralization
<gonz_>
Nothing official or anything about it
<ifreund>
i never found a matrix client I liked, so I mostly stick to irc
<ifreund>
still logged in on matrix though cause I'm too lazy to set up a proper irc bouncer
<ifreund>
ifreund[m] is always listening
<BaroqueLarouche>
I use Riot aka the "official" one
<ifreund>
yeah, it's the one that works the best, but it falls far short of weechat imo
<ifreund>
i realize that my taste in chat clients is likely not very representative though
<leeward>
xchat is making me less a fan as time goes on.
frett27_ has joined #zig
<ifreund>
i have issues with weechat too, mainly that the config is a mess
<ifreund>
haven't had time to check out irssi or anything else though
<leeward>
My xchat problems are more...its text control doesn't seem to work correctly.
<leeward>
Maybe I'll make an irc client in Zig that's way worse than any of the other ones out there.
<ifreund>
i've actually been considering writing a minimal one as well, partially to play around with async
<ifreund>
i have too many projects already though
<BaroqueLarouche>
make a Matrix client instead, IRC needs to fade away IMO
<ifreund>
no way
<ifreund>
matrix is way too complex of a protocol
<fengb>
xmpp 🙃
<gonz_>
I used to use a bridge for Matrix -> weechat way back when
<ifreund>
it has its use case as a bridge, but I'd never choose it over irc out of choice
<gonz_>
Actually, it may have gone through bitlbee? I don't remember now.
<ifreund>
lol at that sentance I just wrote :D
frett27 has quit [Ping timeout: 260 seconds]
<gonz_>
Client stuff for Matrix didn't use to be so complicated, I have this repo from when I was playing around with it: https://github.com/GoNZooo/matrix/
<gonz_>
It's not very complete, though, but it used to be a tractable problem in that it can be done piecemeal.
Stephie- is now known as Stephie
<gonz_>
Funny how it's just 5 years ago and I have almost no recollection of writing this code.
<gonz_>
I would have as easy of a time changing this code as everyone else :D
<fengb>
5 years ago? I can’t figure out what my code did from a week ago
<gonz_>
Heh, yeah, you're not alone. There've been files I'm like "Ugh, I feel bad reading this, who wrote it?" and `git blame` says it's me :D
<gonz_>
> i have too many projects already though
<gonz_>
it me
<gonz_>
s/projects/unfinished projects
<gonz_>
But I feel like this is the nature of experimentation and exploration
reductum has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
slowtype1 has quit [Quit: WeeChat 2.8]
doublex has quit [Ping timeout: 246 seconds]
slowtyper has joined #zig
doublex has joined #zig
Akuli has joined #zig
stripedpajamas has quit [Quit: sleeping...]
casaca has quit [Remote host closed the connection]
stripedpajamas has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
waleee-cl has joined #zig
reductum has quit [Quit: WeeChat 2.8]
wootehfoot has joined #zig
casaca has joined #zig
casaca has quit [Excess Flood]
casaca has joined #zig
casaca has quit [Excess Flood]
casaca has joined #zig
casaca has quit [Excess Flood]
doublex_ has quit [Ping timeout: 264 seconds]
alexnask has joined #zig
wootehfoot has quit [Quit: Leaving]
Patrice_ has joined #zig
doublex has joined #zig
frett27_ has quit [Ping timeout: 258 seconds]
<leeward>
Well, got zls up and running on Emacs...time to see what all this newfangled lsp stuff is about.
<alexnask>
Let me know how it goes. Someone reported hover stopped working after a save with lsp-mode a few days ago
<alexnask>
But I couldnt repro
FireFox317 has quit [Quit: Leaving]
<leeward>
Oh, actually, since you're here:
<leeward>
It looks like master isn't building.
<ifreund>
did you update your zig in the past few days?
<leeward>
./src/main.zig:63:39: error: TODO: type coercion of anon struct literal to struct
<leeward>
Yeah, I just updated it.
<leeward>
Did they fall out of sync?
<leeward>
Though...I'll try updating Zig again.
<ifreund>
no, i think you need to update again, that type coercion was implemented
stripedpajamas has quit [Quit: sleeping...]
<alexnask>
Yes that was implemented a couple of days ago
<leeward>
Hmm, something weird happens with my source control sometimes and it thinks Zig is up to date but it's not.
<leeward>
I guess this is the bleeding part of the bleeding edge.
<alexnask>
lol
<leeward>
ifreund: That would be fine if I weren't weird, but I am. I use mercurial to talk to github.
<ifreund>
ah
drewr has quit [Quit: ERC (IRC client for Emacs 26.3)]
<leeward>
alexnask: You mentioned in your talk that Microsoft made the LSP spec intentionally hard to understand, but I don't get it. Don't they want people to implement servers for different languages? I can see why they would want clients to be hard to implement, but why even make a public protocol if it's going to be intentionally obtuse?
<alexnask>
Intentionally hard was probably not the best way to say this (also it was mostly in jest)
<alexnask>
There are some decisions
<alexnask>
That most server writers opposed
<ifreund>
cough, UTF-16
<alexnask>
E.g. utf16 offsets
<leeward>
*facepalm*
<alexnask>
That are very Microsoft-y
<leeward>
Ah. They do have their idioms.
<leeward>
Up to date Zig and it looks like zls is working nicely.
drewr has joined #zig
<fengb>
Isnt OOXML technically OSS?
<alexnask>
Semantic tokens were fun to impelent, especially seeing all the white text progressively getting highlighted as I did it :P
<alexnask>
Too bad I have to go back to struggling to get cImport support now
<alexnask>
implement*
shcv has joined #zig
<shcv>
I'm trying to build zig, but am running into an issue where it can't find "lld/Common/Driver.h" - it seems that my system (gentoo) installation of LLVM v10 and LLD doesn't include that file... would just downloading the source work? Or am I missing something?
<ifreund>
shcv: did you install the development headers for lld? they're split on some distros but don't know about gentoo
<leeward>
pixelherodev runs gentoo, if he's around
<pixelherodev>
wow, that was perfect timing lol
<leeward>
:)
<pixelherodev>
just woke up :P
<pixelherodev>
it's currently 16:00 lol
<alexnask>
Hi ^.^
<leeward>
Seems like you're...somewhere in oceania today.
<pixelherodev>
I need a sane sleep schedule lol
<alexnask>
Sane sleep schedules are for the weak
<pixelherodev>
shcv: LLVM 10 is a freaking mess
<pixelherodev>
I had to patch the ebuilds to change to build system to get it in a state Zig would link against
<pixelherodev>
Wasn't an issue with LLVM 9 :(
<shcv>
hmm
<shcv>
pixelherodev: would you mind sharing your patched ebuilds?
<pixelherodev>
that depends on if I still have them :P
<pixelherodev>
I haven't updated LLVM or Clang in months
<pixelherodev>
It's entirely possible I accidentally overwrote the patches
<pixelherodev>
It was about turning BUILD_SHARED_LIBS on or something like that
wootehfoot has joined #zig
<leeward>
I just have the 1 patch for Zig that links LLVMPolly to get it to build.
<leeward>
We're still saying that's an LLVM bug, right?
<ifreund>
no patches needed on void, it just works :)
<pixelherodev>
Any issue with linking LLVM is 99% likely to be an LLVM bug
<ifreund>
yeah, honestly it's looks better than the std, but still would rather use zig
<fengb>
Just use boost amirite
<nerthus>
why does documentation/master/ say Zig Version 0.5.0? (changing it to 0.6.0 in the url displays the right version)
<leeward>
The problem with (modern) C++ is not that it's missing features. C++ contains several perfectly usable languages.
<pixelherodev>
lol, yes
<pixelherodev>
Exactly
<pixelherodev>
It's lacking in lacking
<leeward>
nerthus: bugs is why. Replace "master" with "0.6.0" to get the right documentation.
<leeward>
pixelherodev: Well stated.
<rooke>
I kind of enjoy using c++... just not other peoples c++
<fengb>
C++: a centipede made by nailing legs to a dog
<leeward>
I feel like there's a market for "sane C++" that just picks a subset and makes a linter or something.
<pixelherodev>
rooke: yes, but the problem is, "C++" generally *refers* to "other people's C++"
<leeward>
Of course, that becomes intractable because of the grammar...
<pixelherodev>
Plenty of people *can* write sane code in C++
marmotini_ has joined #zig
<pixelherodev>
Problem is, then you have to deal with other people's code
<pixelherodev>
Or other people touching your code
<leeward>
It's like Perl, but with 10 times the footguns.
<pixelherodev>
Exactly
<rooke>
leeward: the couple of pals I know who went on to code c++ professionally... thats basically what their work does, restricts the language to some tractable subset
<rooke>
problem is... every company chose a different subset ;_;
stripedpajamas has joined #zig
<leeward>
rooke: Wow, I haven't seen an employer actually enforce a particular subset successfully.
<rooke>
leeward: I don't know how successful the enforcement was to be fair, only it was attempted :x
<leeward>
Well, MISRA C++ came out in 2008, so it doesn't incorporate C++0xb or later features.
<leeward>
The real problem is libraries. If you want to use a C++ library that doesn't expose its interface with "extern C" then you have to use all the C++ language features the library uses.
<leeward>
Heck, `new` throws.
<pixelherodev>
Not necessarily
<pixelherodev>
Depends on the platform
<pixelherodev>
and you can compile libstdc++ to not use exceptions
<pixelherodev>
It'll abort() instead ;)
<BaroqueLarouche>
When you do C++ with -fno-exceptions and -fno-rtti, it can get hard finding libraries that doesn't use either of those
<leeward>
pixelherodev: So much better.
<pixelherodev>
Oryol is a good graphics library that works with those both disabled
<pixelherodev>
Designed with that intent in mind
<pixelherodev>
It's also being replaced with C :)
<pixelherodev>
(Internally, with a C++ API wrapper)
<pixelherodev>
I think I have a few patches in it :P
<leeward>
Fun fact: if you call a C++ function from a C function called from a C++ function, and the innermost one throws an exception, it's altually legal in many states to shoot anyone named Stroustrup.
<rooke>
Man its got a decent spread of languages going on
<pixelherodev>
Hey, don't blame him
<pixelherodev>
leeward: he's only responsible in that he abdicated control of the language
<pixelherodev>
Blame the committee
<pixelherodev>
Proof that democracy fails
<rooke>
His book "a tour of c++" presents a very pretty version of c++ to be fair
<leeward>
pixelherodev: Can't hang a committee.
<pixelherodev>
We can certainly *try*.
<rooke>
or at least it felt pretty to me when I read it
<leeward>
rooke: I've read it, and tend to agree, but it presents a mostly-sane subset.
<gonz_>
Bjalf Starsoup is guilty
<gonz_>
make no mistake about it :D
<leeward>
But "The C++ Programming Language" can be compared to K&R just by looking at the two in profile.
<leeward>
4th edition (2013) 1376 pages
<leeward>
I left my copy of K&R in the office; no handy page count.
<rooke>
272 pages according to amazon
<leeward>
Amazon says 272 pages for 2nd edition
<leeward>
So close.
<rooke>
Only the third most popular c book on amazon?
<leeward>
So...you could drop 1,000 pages from Stroustrup and it'd still be bigger than K&R.
<leeward>
It's pretty old. I don't think it covers C99.
<leeward>
Yeah, 2nd edition was 1988
stripedpajamas has quit [Ping timeout: 260 seconds]
cole-h has quit [Ping timeout: 240 seconds]
<rooke>
A tour of c++ is bout the same length: 256
<rooke>
Back to zig: when writing tests for a library which requires an allocator, is there much reason to use anything beyond the arena allocator?
<BaroqueLarouche>
you should the testing allocator it will do a basic sanity check for alloc/free count
<leeward>
Yeah, but K&R is a tutorial with exercises and Tour is a table of contents.
<leeward>
rooke: If I expect it to be used with -lc, I usually use c_allocator.
<leeward>
Oh, right! There's a testing allocator!
<leeward>
There's also FailAllocator3.
<leeward>
s/FailAllocator3/FailAllocator
<rooke>
Oh I didn't know about the testing allocator
<pixelherodev>
Valgrind can detect that for C too, no?
<pixelherodev>
"conditional jump or move depends on uninitialized value"
<pixelherodev>
Pretty sure I fixed seven of those last night lol
<andrewrk>
yeah but you can't reassign something to undefined in C
<mq32>
<andrewrk> alright, I'm gonna start the live stream in 30 min from now
<mq32>
damn, i have to sleep
<mq32>
will watch the stream recording tomorrow
<andrewrk>
it's incredible how much more intuitive this kind of profiling is for getting an understanding of how the code performs
<andrewrk>
the bottom-up thing is nice to understand things a certain way, but there's just no comparison to understanding from a top down level what's going on
<via>
dimenus: i'm writing to you on a pinebook pro of my own! there's literally dozens of us
xackus_ has joined #zig
dermetfan has quit [Ping timeout: 272 seconds]
<andrewrk>
I have one too :D
<via>
what are you running on it?
<ifreund>
mq32: it's only 1am :D
<dimenus>
via: he runs NixOS on his daily
<via>
cool. i'm running alpine on here, though i think i'm gonna go back to something like debian
<dimenus>
i'm just using stock Manjaro
<fengb>
Anyone have a pinephone?
<ifreund>
i've been eyeing the postmarketos community edition dropping soon
<andrewrk>
via, I haven't changed the default debian thing
<dimenus>
do you guys have the v1 then?
<dimenus>
i was under the impression that all of them come with Manjaro now
<andrewrk>
fengb, I got a pine phone but wasn't impressed with it. the wifi hardware doesn't even have 5G support. the software is not ready yet either. I gave it to rich felker
<gonz_>
That's disappointing. I wanted a Pinephone but these hipster devices are likely hard to get by in Bulgaria.
<via>
dimenus: came with manjaro, rebuilt u-boot and put alpine on it
<fengb>
That was the dev edition right? I’ve heard that postmarket has gotten pretty decent... although no 5G is still a problem
<andrewrk>
I ordered a librem5 but it doesn't ship until august, which in 2020 is like 10 years from now
xackus_ has quit [Ping timeout: 240 seconds]
<dimenus>
andrewrk: isn't the software situation on the librem even worse?
<dimenus>
hmmm, in theory the Mali gpu supports Vulkan