BaroqueLarouche has quit [Ping timeout: 246 seconds]
D3zmodos has quit [Ping timeout: 246 seconds]
return0e[m] has quit [Ping timeout: 246 seconds]
BitPuffin has quit [Ping timeout: 246 seconds]
ky0ko has joined #zig
BaroqueLarouche has joined #zig
D3zmodos has joined #zig
return0e[m] has joined #zig
BitPuffin has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us has joined #zig
ky0ko has quit [Ping timeout: 246 seconds]
dtz has quit [Ping timeout: 246 seconds]
ky0ko has joined #zig
doublex has quit [Ping timeout: 260 seconds]
dtz has joined #zig
doublex has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 246 seconds]
nephele_ is now known as nephele
craigo has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
<pixelherodev>
Brilliant idea: `pun` -> `pub fn`
<pixelherodev>
Or `punk`
<pixelherodev>
`public func`
hspak6 has quit [Quit: bye]
hspak6 has joined #zig
hspak6 is now known as hspak
dingenskirchen1 has joined #zig
dingenskirchen has quit [Ping timeout: 246 seconds]
dingenskirchen1 is now known as dingenskirchen
craigo has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us has quit [Ping timeout: 246 seconds]
arandomandy has left #zig [#zig]
ur5us has joined #zig
_Vi has joined #zig
ur5us has quit [Ping timeout: 246 seconds]
redj_ has joined #zig
redj has quit [Ping timeout: 256 seconds]
_Vi has quit [Ping timeout: 260 seconds]
doublex has quit [Ping timeout: 246 seconds]
doublex has joined #zig
<scientes>
how do i build zig with asan?
<scientes>
if i add -fsanatize=address then the link fails
<Amun_Ra>
you have to add libasan too
<scientes>
where?
<scientes>
if i do -fsanatize=address -lasan I still get missing symbols, and all the docs say the only way to get those symbols is to link with clang, not lld
<scientes>
got it
ifreund has joined #zig
<scientes>
yeah I can't get the glue to work. I've got this bizaare crash from getContext()
<scientes>
which makes no sense
<mikdusan>
scientes: are you rolling your own llvm/clang build?
<mikdusan>
make a skeleton main.c; do `clang -o main main.c -fsanitize=address -###` to show you command line args. try without -### to see if it even links. the args will tell you which libaries. maybe `libclang_rt.asan-x86_64.a` ?
<scientes>
I got asan to build
<scientes>
didn't help
<mikdusan>
doesn't ubuntu llvm10/clang have asan?
<scientes>
***correction: got zig to build with asan
* mikdusan
shrugs. I have no idea what /usr/lib/libasan is and why you would need it for clang -fsanitize
<mikdusan>
oh wait. you're building stage0/stage1 with gcc. ah. ok
<mikdusan>
I see this on gcc 10.1 link line when using -fsanitize=address: `<snip>/../lib/libasan_preinit.o -lasan <snip>`
<mikdusan>
scientes: I used stock archlinux, gcc-10.1 and asan was already installed; used this diff to build zig0 and seems to work fine. gives me leaks just doing `zig0 --help` and a ton of leaks with building .zig stuff.
<scientes>
but the path to the crash I am seeing had no asan errors
<scientes>
or valgrind (except the crash itsself)
<mikdusan>
maybe I misunderstand; sounded to me like using -fsanitize=address was giving you the crash and without it, no crash
<scientes>
yes you did
cole-h has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
dermetfan has joined #zig
<scientes>
Yeah I don't think I can do this
<scientes>
there is just too much to think about at the same time
Kingsquee has quit [Quit: Konversation terminated!]
dddddd has joined #zig
mikdusan has quit [Quit: WeeChat 2.6]
alehander92 has joined #zig
cren has joined #zig
<cren>
has anyone made a TUI (text/terminal user interface) library for Zig yet?
<ifreund>
not to my knowledge, but you could almost certainly use a C one
<cren>
yeah that's true
Nypsie has joined #zig
Nypsie has quit [Remote host closed the connection]
ur5us has joined #zig
bjornroberg has joined #zig
_Vi has joined #zig
KoljaKube has joined #zig
<KoljaKube>
G'day
<KoljaKube>
Is there a way to cast away const?
<ifreund>
KoljaKube: pretty sure @ptrCast will let you do that
<KoljaKube>
That's what I expected, but I get "error: cast discards const qualifier"
<KoljaKube>
In `@ptrCast(*vec3, a)`
<KoljaKube>
(a is a *const vec3)
<ifreund>
hmm, maybe not then
<ifreund>
well, @ptrToInt and @intToPtr would probably work
<KoljaKube>
`@as` didn't work either`
<KoljaKube>
That sounds ... hacky?
<ifreund>
casting away const is hacky
<ifreund>
ideally you should never have to do this
<KoljaKube>
Not my fault, the library I'm trying to use just doesn't use const for readonly parameters
<KoljaKube>
But I can see in the source that nothing is mutated
<ifreund>
ah
<ifreund>
yeah that's kinda annoying
<KoljaKube>
I know that it should not be done without a very good reason, but I would have expected that there still would be a language feature for it
<KoljaKube>
You are right about the int casting by the way
<ifreund>
cool
<ifreund>
if this is a C library you could probably modify the generated bindings to make the function take a const pointer
<KoljaKube>
I guess I can use that for now
<KoljaKube>
Is there documentation on how to do that in a way that survives deleting zig-cache?
<KoljaKube>
Although I don't know how much that would help, since the in-only parameters are not marked in any way
<KoljaKube>
Submitting a const-patch upstream would probably be the same amount of work
<ifreund>
I haven't actually tried this myself yet, but the idea is that you'd call `zig translate-c` manually, put the output in your repo, and use that as a package
<ifreund>
yeah sending the a patch upstream would be a good move
<KoljaKube>
By the way, is `*const i32` a const pointer to an int, or a pointer to a const int?
<KoljaKube>
It kind of seems to be both?
<ifreund>
pointer to a const int
<ifreund>
if you are taking that as a paramter, it will be a const pointer to a const int since parameters are always const
<ifreund>
in zig you just read right to left, unlike C where you usually read left to right but sometimes add some loops
* KoljaKube
facepalms
<KoljaKube>
I should think before I write, of course I can't reassign a pointer I declared `const` :D
<ifreund>
hah
ur5us has quit [Ping timeout: 246 seconds]
ask6155 has joined #zig
<ask6155>
Hello!
<KoljaKube>
Hi
<cren>
hello
<ask6155>
Hey, has someone made a zig cheatsheet yet? The documentation is long (And that's good) but I'd like to get in quickly.
<cren>
I was thinking of writing a "Getting started with Zig" article but I don't know enough about Zig yet xD
<ask6155>
Is there a video quickstart by someone?
craigo has quit [Ping timeout: 272 seconds]
decentpenguin has joined #zig
<ask6155>
Is it possible to have a dynamic array?
<ifreund>
ask6155: you want std.ArrayList
<ifreund>
in general there is no allocation built into the language, it's all userland
<scientes>
except the stack
<scientes>
ask6155, it is short
<scientes>
and there are two sets of general documentation
<pmwhite>
What languages do have allocation built-in?
<ask6155>
yeah so I pass it a type and it gives me a var?
<scientes>
all garbage-collected languages
<scientes>
but even C
<pmwhite>
How-so with C? I wouldn't count malloc, since that's the stdlib, and Zig also has a stdlib allocator.
<ifreund>
c++ has new/delete
<leeward>
The difference between Zig and C here is that C libraries assume you're going to use malloc. If you want to use a different allocator, you have to play games with the linker. Zig bumps that up a layer. It's either a minor irritant (everything takes an allocator) or super handy (everything lets you specify an allocator) depending on your use case.
<gonz_>
It's infinitely easier to see what allocates if everything that allocates has to make it obvious.
<leeward>
True facts.
<gonz_>
So it'll always be super handy. People who complain about having to make things more obvious when it's something so important should get some perspective.
<pmwhite>
leeward: that's more the culture and ecosystem than the language, though.
<pmwhite>
ifreund: good point, it's been a while since I've used C++, so I didn't even think of that.
<leeward>
pmwhite: True. I don't agree with scientes's statement about even C having an allocator bulit in.
<ifreund>
libary design is kinda part of language design tbh
<ifreund>
how people use languages is very much defined by how the major libraries are written
<leeward>
It is, and the ecosystem is important, but Zig comes with allocators in lib/std.
<pmwhite>
It would be interesting to make a libc alternative with custom allocators.
<pmwhite>
ifreund: true, I'm thinking of what you said with how Zig allocation is user land, which is also the case for C, and both have allocators in their standard libraries..
marler8997 has quit [Ping timeout: 260 seconds]
<leeward>
I've worked on systems where malloc was a pool allocator.
<fengb>
malloc is unfortunately global and pervasive so it’d be hard to make other libraries work like that
<ifreund>
pmwhite: yeah, hence my point about the design of libraries, in particular standard libraries, being part of language design
<fengb>
Compilers generally let you swap the malloc implementation but not per unit
<ifreund>
allocation is userland in C, but practically it may as well not be
<leeward>
I don't know about that. Lots of embedded systems just assume malloc doesn't exist.
<ifreund>
ok, yeah that's very true
<pmwhite>
Have there ever been discussions toward removing parens around the condition of control flow blocks?
<fengb>
It’s for disambiguation
<ifreund>
well then you can't do `if (thing) 1 else 2;`
<companion_cube>
pmwhite: lots of discussions, but it ultimately clashes with `{a;b}` not being a value-returning expression
<companion_cube>
(cause if you remove () you want to add {})
<ifreund>
yeah, i think zig has pretty much made its choice on the `if thing { a } else { b };` vs `if (thing) a else b;` decision
<pmwhite>
What prevents if thing a else b?
<companion_cube>
how do you delimit `thing`?
<pmwhite>
It's an expression. Zig doesn't allow juxtaposition of expressions, so it's not ambiguous.
<companion_cube>
I don't think it would work with a simple grammar
<companion_cube>
(ie no lookahead)
<pmwhite>
You would need parens for complex conditions without braces, but you wouldn't when you do use braces.
<companion_cube>
almost all conditions are more than an identifier, I think :)
<ifreund>
imo you loose in readablity by dropping the parens without adding curlies too
<ifreund>
s/oo/o/
<fengb>
Wow somebody using lose correctly
<fengb>
Or mangling the to
<ifreund>
:D
<ifreund>
it's the former, i didn't ad a g at the end
<ifreund>
s/ad/add/
<pmwhite>
companion_cube: almost all conditions are followed by curlies, though, right?
<companion_cube>
imho they should
<companion_cube>
syntax is to be bikeshed to death :D
<ifreund>
i've been dropping them a lot recently
<fengb>
#5076
<ifreund>
if (condition) foo.bar();
<ifreund>
pretty readable imo, you see it a ton in the std as well
<companion_cube>
ifreund: too close to goto fail; to me taste :s
<fengb>
Goto fail is on the plate for a syntax error
<companion_cube>
because of indentation?
<ifreund>
yep
<ifreund>
also zig fmt already fixes it
<ifreund>
though making it a compile error is even stronger
<scientes>
shedbike
<pmwhite>
Okay, better idea. Make the parser pluggable so that people who are sufficiently peeved and motivated can make their own syntax.
<companion_cube>
:DDDD
<fengb>
I think that’s built into our tooling. I think it’s called a “fork button”? 🙃
<companion_cube>
call the fork "zen"
<companion_cube>
oh wait
ask6155 has quit [Quit: leaving]
<pmwhite>
Lol, that brings a load of other issues with it. If the std lib comes with an AST printer, then I guess it really is not that harder to transpile a custom syntax to Zig.
<fengb>
With ZIR being a thing, I don’t think it’d be too hard to develop a separate frontend
<companion_cube>
fragmentation of syntax isn't something I'd wish on a small community
<fengb>
If you’re not bikeshedding semantics, it should be pretty simple to maintain a different syntax
<fengb>
Then all variants of #5076 can be a thing!
<companion_cube>
maybe you could comptime set what parser you use at the start of the file 🙃
<companion_cube>
parsers are just packages
<leeward>
sounds like something Haskell would do.
<companion_cube>
meh, haskell has a pretty minimal syntax
<companion_cube>
but in OCaml we have that, in a way: ReasonML
<companion_cube>
(and there's a bit of a cultural fork of the community around that)
<companion_cube>
(webdevs vs old timers)
<pmwhite>
I don't think fragmentation of syntax is actually that bad of a thing. For one thing, each project will probably enforce one syntax. For another, Zig programmers would learn to be better at learning new syntaxes. Then again, it might just be a bunch of extra cognitive burden to switch between different syntaxes.
<gonz_>
Racket has more of what fengb is talking about. Racket is a platform/language for making languages that can run on that platform.
<companion_cube>
well racket is designed for that, yes
<companion_cube>
pmwhite: what I'd fear is that tooling would have trouble keeping up (say, zls)
<leeward>
See also: Erlang/Elixir, all the JVM/.NET languages.
<pmwhite>
Ideally, reading and writing code are decoupled enough that one person can write in one syntax, and another person can read the same code in their own preferred syntax.
<companion_cube>
the jvm langs are pretty distinct, it's not just syntax
<leeward>
fair
<pmwhite>
Just like how tabs are!
<leeward>
Coffeescript...
<fengb>
Isn’t Racket just Scheme taken to the extreme? Make your own DSL and call it a separate language
<fengb>
JavaScript is the ultimate language platform :P
<companion_cube>
racket is a proper research language on how to make an extensible language
<companion_cube>
(and the compile to go with it)
<companion_cube>
it's much more advanced than normal scheme afaict
<gonz_>
This would depend on how you define what a separate language actually is.
<gonz_>
And yes it is.
<gonz_>
At the top of your file you usually specify which language the file is written in: `#lang datalog`, etc.
<gonz_>
Of course, you can also have `#lang sicp`. Is the difference to Racket huge in that case? No.
<companion_cube>
but you can mix and match within one project, righT?
<gonz_>
Yes.
<companion_cube>
so that's pretty nice.
<companion_cube>
I'd take a `#syntax rust` at hte beginning of the file, I must say :p
<companion_cube>
replace const with let, mandatory {}, and no need for labelled breaks :p
<pmwhite>
It would fit with the "decentralised community" idea.
<gonz_>
Which one? There are so many in the thread. :D
<fengb>
The one I linked directly
<fengb>
“Go doesn’t need to be fast”
<fengb>
Like... wat
<gonz_>
I can sympathize with people wanting better compile-times and giving up optimization for it, but I'm not sure I see the point for release builds.
<leeward>
Yeah, I think that person doesn't understand Go's design goals.
<gonz_>
I'd like to have the dumbest compiler ever for dev builds, or just real degrees with which to control optimization.
<gonz_>
I think Per Vognsen's response to "How do you make a sophisticated compiler that's fast?" was pretty on point in the Twitter thread I linked last time we talked compiler speed a few days ago
<gonz_>
"You don't make it sophisticated"
<gonz_>
It's completely valid
<companion_cube>
fengb: it's already reasonably fast
<fengb>
Fast, sophisticated, pick one?
<companion_cube>
I think people who say that are comparing it to python
<fengb>
It’s fast but it can go faster
<companion_cube>
but it'd probably make compile times worse
<fengb>
And I don’t know why you’d ever have the attitude “oh... we don’t care about speed”
<fengb>
In any language, not just Go
<companion_cube>
because you can make something that ~works in 1 week instead of 2, I imagine
<companion_cube>
or so I hear
KoljaKube has quit [Ping timeout: 246 seconds]
<gonz_>
fengb: I think for the kinds of compiler speeds I want, yeah, you probably can't have it do much.
<gonz_>
Just emit the code, move on, etc.
<fengb>
“Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really.”
<leeward>
In the speed/cost tradeoff, most of my code has the slider set all the way to cost.
<companion_cube>
fengb: yes that's also realistic
<leeward>
If something's not fast enough, measure it and find out what, then make that part fast enough.
<companion_cube>
syntax sucks for number crunching anyway, people expect operator overloading these days
<fengb>
Um... Java runs fast and doesn’t have this attitude
<fengb>
Took quite a bit of effort but still
<companion_cube>
java starts slow though, they optimized for different things
<companion_cube>
and memory usage is… not the best 🤷
<fengb>
My point is this is a shit attitude
<gonz_>
Big picture Java doesn't run that fast and realistically speaking can't, though.
<fengb>
“Oh just don’t use Go”
<gonz_>
For what it's worth I agree
<fengb>
But it can run fast. HFTs commonly use Java
<gonz_>
But also see where people are coming from when they don't want to give up something they have for something they don't know they'll have or enjoy having.
<companion_cube>
Go can occupy some niches java is terrible at
<companion_cube>
like CLI tools
<companion_cube>
gonz_: yeah the "no need for generics" kills me every time
<fengb>
I feel like a lot of Go is just cultists
<companion_cube>
(or, and it's not even on their radar, the lack of sum types)
<leeward>
I really like Zig's solution to generics.
<fengb>
“I have this so sucks to be you”
<fengb>
I get it’s about trade offs
<fengb>
But let’s talk about trade offs instead of saying “that’s not the Go way”
<fengb>
Feels like Go people love to pigeonhole their language into “it’s made the perfect trade offs already!”
<leeward>
fengb: The language designers did talk about tradeoffs when they decided to exclude them. Can't really stick the users and fanboys with the job of defending language design decisions.
<fengb>
Yeah I’m mostly fine with the designers. They’re still sorta wanting to include generics without compromising the language too much
<fengb>
But then you got the fanboys going “generics are dumb!”
<companion_cube>
rob pike was also like that, tbh
<leeward>
That happens with any language that gets popular.
<gonz_>
Rob Pike gets let off the hook even though he's arguably a big catalyst for a lot of dumb stuff in the general discourse around lack of certain features, yeah.
<fengb>
Like syntax highlighting? 🙃
<leeward>
If things work out, some day there will be Zig fanboys saying that...(variadic functions) are dumb and useless and should never exist. (placeholder for feature of your choice)
<companion_cube>
generics are dumb, except for the few custom types Go designers wanted
<companion_cube>
leeward: at least Zig has a good alternative to that :p
<ikskuh>
companion_cube: not yet, though
<fengb>
I liked Go for being simple and pragmatic :(
<leeward>
companion_cube: Go has an alternative to generics: write more code.
<ikskuh>
right now zig replaces "variadic functions" with "code bloa"
<ikskuh>
*bloat
<fengb>
go generate
<companion_cube>
ikskuh: I thought the tuple solution was good? am I missing something?
<ikskuh>
yes: every tuple makes the funtion generic
<ikskuh>
and creates it's own copy
<companion_cube>
oh I see what you mean.
<companion_cube>
how are varargs normally passed to a function, in C? idk anything about the call convention
<leeward>
It's an array.
<leeward>
Also: it's awful.
<ikskuh>
no, it's not an array
<fengb>
How do you have an array of heterogeneous items?
<ikskuh>
it's passed via the stack
<leeward>
it's a va_list
<ikskuh>
a function with void(int,int) is the same as void(int, ...)
<leeward>
Sure, not actually an array, sorry.
<ikskuh>
when you pass another int
<ikskuh>
internally it's pointer magic
<companion_cube>
that also seems awful…
<ikskuh>
in the standard, it's defined that you have to use va_list
<fengb>
But... what if you have (int, struct, char)
<ikskuh>
well
<fengb>
How do the values line up?
<ikskuh>
that will still call the same function
<leeward>
man 3 stdarg
<ikskuh>
and it will just yield invalid code :D
<fengb>
Oh I think I read about a bug that manifested where someone passed a long instead of a short
<ikskuh>
yep, that will happen
<companion_cube>
you also lose all type safety
<companion_cube>
I mean, are variadic functions that common? outside of format?
<leeward>
companion_cube: This is C we're talking about, right? What type safety?
<companion_cube>
I know, but how to adapt it to Zig? :p
<gonz_>
I was gonna say, for such an unimportant feature there's a lot to pay for it.
<fengb>
format() is pretty bloated once you start using it heavily
<fengb>
And not at all obvious
<ikskuh>
yep
<ikskuh>
it also duplicates a lot of code
<ikskuh>
i think that andrew has a solution for that up his sleeve but i'm not sure
<fengb>
Copy-paste reuse is the best kind of reuse
<ikskuh>
well, i think zig can do something about it
<ikskuh>
but not sure how it should work as every format function has a different signature
<ikskuh>
and has hidden overloading
<companion_cube>
ikskuh: the solution to template-like bloating is to pre-specialize templates ;)
<companion_cube>
as is known in C++
<shakesoda>
i'm really getting those "when this happens you've already lost the battle" vibes here
<shakesoda>
as usually happens when generics and templates and code generation come up
<ikskuh>
shakesoda: i don't see a solution right now
<shakesoda>
zig's solution to such things is the most reasonable i have encountered and yet still ends up pretty regularly in scary places
<shakesoda>
ikskuh: nor do i
<ikskuh>
problem right now is probably that the formatting thing is a bit *too* generic
<ikskuh>
it should be possible to make it non-inline the formatting functions itself
<ikskuh>
so
<ikskuh>
warn("{},{}", .{ a, b} ); will just get
<ikskuh>
printFormatted(a);
<ikskuh>
printraw(",");
<ikskuh>
printFormatted(b);
<ikskuh>
and force-inline and force-unroll the formatting
<ikskuh>
which will then also compile to very small code
<ikskuh>
as every formatting function for a type is only generated once
<ikskuh>
and the formatting itself is inlined
<ikskuh>
which is okay as it's in 95% of all cases special to that place anyways
<ikskuh>
only thing that is needed is some kind of type enforcer
<ikskuh>
which converts `*[N]T` to `[]T`, same for const
waleee-cl has joined #zig
dimenus has joined #zig
edr has quit [Ping timeout: 256 seconds]
<scientes>
this is like pulling teeth
<scientes>
I have no idea what is going on
<fengb>
People get paid good money for pulling teeth
<scientes>
and values just drop out
<scientes>
fengb, hahahaha
<companion_cube>
fengb: and they may even get good job satisfaction
<companion_cube>
6667 seems to not work (unless it's no ssl?)
<ikskuh>
6697/TLS
<companion_cube>
ah thanks
arekishi has joined #zig
ur5us has joined #zig
<pixelherodev>
ikskuh: gemini :)
<pixelherodev>
=
r4pr0n has joined #zig
Xavi92 has joined #zig
r4pr0n has quit [Quit: r4pr0n]
<Xavi92>
any pointers on how to provide an implementation of std.fs.openFileAbsoluteZ() for a new OS? Is it needed to modify the standard library from zig sources?