<daurnimator>
fengb: closures would make them in scope ;)
<fengb>
I totally didn't intend a pun
MajorLag has joined #zig
mmx8700 has joined #zig
tgschultz has quit [Read error: Connection reset by peer]
mmx870 has quit [Quit: Ping timeout (120 seconds)]
creationix has quit [Ping timeout: 256 seconds]
mmx8700 is now known as mmx870
MajorLag is now known as tgschultz
creationix has joined #zig
<leeward>
I don't think Zig is respecting my volatile pointers.
<leeward>
Oh, never mind. It's clearing that register.
<leeward>
What the heck, then?
<leeward>
Interesting. GCC and LLVM generate exactly the same code for the C version, but Zig is generating some weird stuff. Time to figure out what that macro actually does.
gavra has quit [Ping timeout: 246 seconds]
<andrewrk>
`zig translate-c` in a nutshell: "Time to figure out what that macro actually does"
<leeward>
hah
<leeward>
Well, this macro is #define sfrb_(x,x_) volatile unsigned char x __asm__("__" #x)
<leeward>
and I have no clue what __asm__("__" FOO) means
<daurnimator>
leeward: #x is turn x into a string
<leeward>
Yeah, that part I knew.
<daurnimator>
leeward: and two strings next to each other are concatenated
<leeward>
WTF is "__" though?
<leeward>
Oh, holy crap
<leeward>
thanks
<daurnimator>
and x_ doesn't seem to be used?
<leeward>
It's a 2-layeIt...does not.
<leeward>
Wow, backspace fail.
<andrewrk>
is that just @fence() ?
<leeward>
Hmm, maybe it is. It generates: extern volatile unsigned char P1DIR __asm__("__" "P1DIR");
<daurnimator>
leeward: it's probably just using it to pull things out of the linker script?
<leeward>
Yeah, probably. It generates asm like "mov.b&__P1DIR, r15"
<andrewrk>
I think you can just make an extern variable named __P1DIR and take the address of it
<leeward>
Huh, translate-c just turns that into "pub extern var P1DIR: u8;"
<daurnimator>
andrewrk: I think the point is so you can write e.g. `P1DIR |= 1` without having to write & anywhere
<andrewrk>
oh I see
<leeward>
Yeah, C code treats it like a variable that happens to have its address set to the right memory-mapped register.
<daurnimator>
while in zig right now; `volatile` is a pointer attribute
<leeward>
So I tried this: const p1dir = @intToPtr(*volatile u8, 0x0022);
<leeward>
Which worked fine for avr, but on msp430 it's not generating correct read-modify-write code.
Mulugruntz has joined #zig
frett27_ has quit [Ping timeout: 258 seconds]
<leeward>
I think Zig is actually generating more efficient correct code than llvm here; just not sure why it's not working.
pfg_ has quit [Remote host closed the connection]
<leeward>
Linker issue. Naturally.
jeyr has joined #zig
jeyr has left #zig [#zig]
ur5us has quit [Ping timeout: 256 seconds]
Mulugruntz has quit [Ping timeout: 272 seconds]
Mulugruntz has joined #zig
cole-h has quit [Quit: Goodbye]
ellester has joined #zig
ellester has quit [Ping timeout: 240 seconds]
discipulus has joined #zig
dermetfan has joined #zig
<discipulus>
daurnimator: on issue 5836 can you remove the "standard library" label please? The proposal is to change the language documentation not the standard library documentation.
<daurnimator>
discipulus: its docs about using the standard library
<discipulus>
I think I know what you mean, though.
<daurnimator>
std.debug.assert vs std.testing.expect is a standard library distinction. I understand what you mean though....
<daurnimator>
labeling is an inexact science
<discipulus>
Yeah, I realized your meaning and how you understood it. I just didn't want to confuse making changes in the standard library documentation.
dermetfan has quit [Ping timeout: 256 seconds]
<discipulus>
had to step away...anyways, I wanted to clarify because the "standard library" label is described as "This issue involves writing Zig code for the standard library."
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
squeek502_ has quit [Read error: Connection reset by peer]
squeek502_ has joined #zig
Shucks has joined #zig
<Shucks>
Heya
<ikskuh>
hey Shucks
dermetfan has joined #zig
<ikskuh>
i'm working on zig-network these days, have fixed some bugs yesterday for linux
<Shucks>
I was pretty surprised that calling defer in a loop works how its "expected" to be. I guess in go all defers get called once you leave the loop scope.
<andrewrk>
go appends defers to a function-local array list and runs them when the function returns
<andrewrk>
in zig defers are scope-local
<andrewrk>
in go, defers allocate memory
matti has quit [Ping timeout: 244 seconds]
tyler569 has quit [Ping timeout: 246 seconds]
tyler569 has joined #zig
matti has joined #zig
ovf has quit [Ping timeout: 244 seconds]
ovf has joined #zig
<Shucks>
Great. Is there a decission yet if std.os.windows will cover the complete windows api now or just that stuff which is required by zig itself?
utzig has quit [Ping timeout: 256 seconds]
kushalp has quit [Ping timeout: 244 seconds]
utzig has joined #zig
kushalp has joined #zig
l1x has quit [Ping timeout: 244 seconds]
jzelinskie has quit [Ping timeout: 244 seconds]
jzelinskie has joined #zig
l1x has joined #zig
craigo has quit [Ping timeout: 256 seconds]
_Vi has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dermetfan has quit [Remote host closed the connection]
dermetfan has joined #zig
<Shucks>
How would I iterate over a range?
nikita_ is now known as nikita`
<ikskuh>
a range as in "from X to Y"?
<ikskuh>
var i : usize = start;
<ikskuh>
while(i < end) : (i += 1) { … }
<ifreund>
or if you have a slice: for (items[start..end]) |i| { ... }
<Shucks>
Oh cool. I didn't had to wrap all that stuff manually >.<
<gonz_>
I think your version is fine in general when you know exactly what you want and there's less than 10 things or whatever.
<fengb>
Ultra lean and mean
<gonz_>
This was how I started out doing it and it worked fine when I had one thing I wanted to do, but I started experimenting with having zig translate all of `windows.h` at some point
<gonz_>
And then I spent a few hours annotating a bunch of functions with their lib after that
dingenskirchen has quit [Remote host closed the connection]
<Shucks>
Well atleast it's good to know where I could look up. Does zig eliminate dead code in case I'm importing that whole api?
<gonz_>
Yeah
<gonz_>
You'll only get what's used
<gonz_>
Even in terms of checks
<gonz_>
Only the paths your code go through end up getting checked and in the artifact
<Shucks>
Great
<gonz_>
Part of why I usually mention it to people when they bring Win32 up is so that I get more users and can find bugs, etc.
<gonz_>
It's legitimately useful, IMO, but also something that just needs more code paths travelled
layneson has quit [Ping timeout: 240 seconds]
evgeniuz has quit [Ping timeout: 245 seconds]
dingenskirchen has joined #zig
traviss has quit [Remote host closed the connection]
<fengb>
Caveat in my implementation: only supports up to 16 chars max
<fengb>
And not necessarily too performant (I haven't tested too thoroughly)
<shcv>
I had thought about doing something like that actually
<shcv>
another option for short, fixed-length strings might be to cast them to ints...
<shcv>
would work best for strings that fit in a usize
<shcv>
looking at your Swhash implementation, it looks like you're doing that for smaller strings?
<shcv>
I guess I was expecting it to be an actual hash :P
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
nmeum_ has joined #zig
nmeum has quit [Remote host closed the connection]
layneson has quit [Ping timeout: 256 seconds]
xackus has joined #zig
<leeward>
So I figured out why my msp430 code wasn't working correctly. The asm output didn't include `.section .init9,"ax",@progbits` which the linker wanted. After having Zig generate asm, adding that line made it so gnu ld put main in the right place. I guess I'll try to get ld.llvm working next.
<leeward>
Silly linkers needing main to be in an executable section...
<frmdstryr>
leeward: Is your msp430 project public somewhere?
<leeward>
frmdstryr: It will be once I get it to work at all
<leeward>
Well, without hand-editing generated asm files
nikita` has joined #zig
stripedpajamas has joined #zig
gavra has joined #zig
cren has quit [Remote host closed the connection]
marnix has joined #zig
<marnix>
I just heard in zig.show #6 that ppl are interested in seeing Zig projects. So for what it is worth, as a Zig noob (and with C/C++ ~15 years behind me), I'm working on
<companion_cube>
marnix: oh I meant the metamath list
<marnix>
companion_cube: :-) Oh, yes, I'm on there for a long time already.
<marnix>
(No progress on zigmmverify for 3 weeks now though, long holiday, which I spend hiking, not having any computer with me except my phone, watching zig.show, installing this bleeding edge IRC client on my phone, and more hiking. :-) )
marnix has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
xackus has quit [Ping timeout: 240 seconds]
marnix has joined #zig
<Shucks>
Could I mark a function return type as "ignoreable"? Or do I have to ignore it explicit with `_ = Foo()`
cole-h has joined #zig
waleee-cl has joined #zig
<leeward>
Shucks: If it returns void, you don't have to do anything with the return value.
<Shucks>
It's returning a value which i don't need
<leeward>
Yeah, then you have to explicitly ignore it.
<Shucks>
alright thanks
xackus has joined #zig
nmeum_ is now known as nmeum
KoljaKube has joined #zig
<KoljaKube>
Can I use Allocator.free with memory a C library allocated with malloc?
<KoljaKube>
c_allocator.free I mean
hspak has quit [Ping timeout: 240 seconds]
<ifreund>
KoljaKube: yes that should be fine
<KoljaKube>
Coolcoolcool
<Shucks>
how could I create a array with a size which isn't known at comptime?
<KoljaKube>
Too bad malloc does not use some sort of userdata void* by default
<KoljaKube>
Would make delegating to different allocators a lot easier I would think
<leeward>
Shucks: look into ArrayList
<Shucks>
once again, thanks ;)
<leeward>
np
<KoljaKube>
Shucks: Or use an allocator, if its size won't change
<KoljaKube>
ifreund: Got around to watching your river zig show presentation yesterday, quite interesting
<leeward>
Yeah, for that you can just use an allocator.
<KoljaKube>
Or, since you seem to know the size at the caller, pass in a slice
<KoljaKube>
That way you won't have to add an *Allocator param
<fengb>
Yeah we often use an out buffer for that
<leeward>
Oh hey, good point
<KoljaKube>
ifreund: If you don't mind me asking, is english a native language for you?
KoljaKube has quit [Quit: WeeChat 2.8]
KoljaKube has joined #zig
<KoljaKube>
And that's how you Cmd+W the wrong window :D
<ifreund>
heh
<ifreund>
yeah I'm from the states
<ifreund>
I speak pretty decent german now too though
<fengb>
He speaks 'murican
<Shucks>
So I'll create a array which will be big enough and create a slice with my size from it right?
<KoljaKube>
Wouldn't doubt that, but I was a little confused by Aachen + the missing accent ;-)
<KoljaKube>
Shucks: You can only create comptime-known sized arrays
<KoljaKube>
Shucks: But you can leave it up to the caller where to get the memory from if you pass in a slice, passing in an allocator makes the function a little more complicated
<KoljaKube>
-complicate +inflexible I guess
<ifreund>
Shucks: yeah that sounds like a reasonable thing do to
<ifreund>
*to do
<ifreund>
your other option would be to dynamically allocate an array of the size you want
<marnix>
Na schön, I'm looking from ein Ausland at German trees at the moment-- which reminds me, any Dutch folks here / in the Zig community? (Think a Zig 'GitHub action' or something is by someone from NL?)
<leeward>
marnix: I'm pretty sure there are some Nederlanders, but I don't remember who.
<KoljaKube>
A map would be nice, but that website doesn't seem fit for the job
<fengb>
Bait and switched
<leeward>
Yup
<leeward>
It had a bunch of pins before it collapsed.
<KoljaKube>
I bet it would be possible to hack something together using OpenStreetMap and Github Pages or some other relatively low maintenance solution
<KoljaKube>
Are there any best practices when it comes to managing memory ownership?
<KoljaKube>
I'm contemplating whether it's a good idea to have the same struct manage memory that may be passed in and is not owned or that is malloced by a C library
<KoljaKube>
"Always call deinit(), but maybe it's a no-op" doesn't sound amazing, but duplicating all the other code isn't great either
<KoljaKube>
And just now I noticed that `defer foo.deinit()` needs foo to be var. Which makes sense, but for some reason I always read deinit() as basically a dtor
<ifreund>
well, foo only needs to be mutable if deinit() needs to modify members. Often all deinit() needs to do is free memory so foo can just be passed by value
<KoljaKube>
Mh, right
<Snektron>
marnix hello yes ik ben Nederlands
<KoljaKube>
OK, other way around: what are the consequences of `self.* = undefined`? Does it only matter in debug/safe builds?
<Shucks>
What exactly is `writer` on std.fmt.format? I'm trying to save a byte as its hex representation.
<leeward>
KoljaKube: If the compiler can tell that you're accessing undefined memory, it will fail in any build mode. `var x: u32 = undefined; var y = x;` will always fail to build.
marnix has joined #zig
<leeward>
For the destructors clearing out their structs, I'm less sure. Safe builds will catch it and unsafe builds aren't required to.
scientes has quit [Read error: Connection reset by peer]
<KoljaKube>
leeward: Thanks. So I have to choose between some sort of debugability/safety and being able to declare something as const
<KoljaKube>
Shucks: writer is basically a stream, as long as it provides a specific list of functions it can be anything
<KoljaKube>
You can format your byte with the picture {x} for hexadecimal representation, regardless of which writer is in use
scientes has joined #zig
<Shucks>
mh yea all I wanna do is: var foo = std.format("{X}", .{mybyte})
<Shucks>
So thats confusing ;p
<ifreund>
accessing undefined memory is UB, it's not something you should ever knowingly do
<leeward>
KoljaKube: This issue came up a little while ago, and...yeah. You could take a const pointer to it and use that to do all your work on it, but `var foo_ = Thing(); defer foo_.deinit(); const foo = &foo_; ...` is a bit awkward.
<ifreund>
Shucks: you might be looking for std.fmt.bufPrint() or std.fmt.allocPrint()
<andrewrk>
KoljaKube, yes, `self.* = undefined;` is a no-op in unsafe build modes. in safe build modes it will cause 0xaa bytes to be written to the members, which is the bit pattern for undefined. it also by default has valgrind client annotations to mark the memory range as uninitialized
<leeward>
Shucks: zig/lib/std/io/writer.zig
<andrewrk>
valgrind is especially powerful with zig code because of the ability to assign `undefined`
<KoljaKube>
Shucks: if you want to writer to a buffer, ArrayList can provide you with a writer
<andrewrk>
ifreund, to be clear, accessing undefined memory is well defined, however branching on it is illegal behavior
<andrewrk>
you are allowed to do this: var a: i32 = undefined; var b = a;
<leeward>
really?
<leeward>
b is just undefined?
<andrewrk>
yes but you cannot then do for example `if (b == 0)`
<ifreund>
I see, that makes sense. Thanks for the clarification
<leeward>
Huh.
<KoljaKube>
leeward: Just out of curiosity, that const pointer could in principle suffer a performance penalty due to indirection, or is that optimized away?
<andrewrk>
also: any operation which takes a set of inputs for which there exists some combination of inputs which would cause illegal behavior, any inputs which are undefined are assumed to be the most adversarial values, and if that would cause illegal behavior, then the operation causes illegal behavior
<andrewrk>
all that is to say, @intCast(u8, @as(i32, undefined)) is illegal behavior
<companion_cube>
if you have an i64, checked it's in 0..u32.max, can you not cast it to u32?
<leeward>
KoljaKube: Andrew probably knows the answer to that, but I would be shocked if it did actually incur any performance penalties.
<KoljaKube>
Strike that, I don't think that makes sense
<andrewrk>
companion_cube, if the value is undefined, then checking if it is within range would be branching on an undefined value
<companion_cube>
ahhh my bad.
<KoljaKube>
I guess for every non-trivial struct, in a function call the same pointer should be passed
<companion_cube>
I thought you were saying all such casts were bad -_-'
<andrewrk>
ah. yeah I was specifically clarifying undefined values
<companion_cube>
💯
<andrewrk>
also, `a + b` where `b` is undefined is illegal behavior. Because it could cause overflow. But `a +% b` where `b` is undefined is allowed, and the operation results in an undefined value
<marnix>
So does Zig have something like Java's blank final? So `const x: usize = undefined; if (...) { ...assign x exactly once...} else {...same again...} ...use x...` ? Because even replacing `const` by `var` fails in zig 0.6.0 I seem to remember? (Can't double-check now.)
<companion_cube>
so being undefined is a taint, that propagate through operations, and is removed via assignment
<andrewrk>
however it's not guaranteed that an undefined value will always show up as the undefined bit pattern (0xaa bytes)
<andrewrk>
although safe build modes strive to make this happen, since it improves safety properties to uphold this
<marnix>
Thanks andrewrk , clear!
FireFox317 has joined #zig
<FireFox317>
marnix, hello fellow dutchman!
<KoljaKube>
Shiny, that labeled break
<andrewrk>
yes, that's a "go-to" control flow mechanism ;)
<leeward>
What's the use case that led to labeled blocks? It seems like the job for a function to me.
<marnix>
FireFox317: Hé hallo daar! :-)
<andrewrk>
leeward, mainly the one that marnix pointed out above. It helps you to have more locals `const` instead of `var`
<andrewrk>
plus it's the reason we don't need goto (hence my pun above)
<marnix>
About those labeled blocks: the need to need to invent a label strikes me as-- overly complex. Perhaps allow : as a label? Or would that lead to line noise code?
<andrewrk>
there's an issue or maybe several open for this
<companion_cube>
the syntax has been discussed many times :-°
<andrewrk>
you're not alone in this
<KoljaKube>
andrewrk: The advantage over functions is the access to other local variables, or am I misunderstanding?
<fengb>
We need to break (:o) compatibility with C
<leeward>
I still don't see it. `const x: usize = decideWhatXShouldBe();` serves exactly the same purpose, no? And for something trivial, `if` is an expression, so `const x: usize = if (...) thing else other_thing;`
<companion_cube>
a function is a lot mory work to define
<andrewrk>
there's nothing wrong with long functions
<companion_cube>
more*
<leeward>
I guess the only advantage I see is the one KoljaKube mentioned: implicit access to all the locals.
<andrewrk>
a function is a nice tool in your toolbox and so are labeled blocks
<KoljaKube>
leeward: The blocks can have side effects and a single path (no else), that is a difference
<leeward>
KoljaKube: Ok, I guess I can see that. I mean, functions can too, but free access to locals is nice.
<KoljaKube>
From the docs: `var y: i32 = 123; const x = blk: { y += 1; break :blk y; };`
<leeward>
That code smells bad, but sure.
<KoljaKube>
Yeah, well
<KoljaKube>
I didn't write it ;-)
<leeward>
:P
<KoljaKube>
But I guess it would be hard(er) to do otherwise
<fengb>
I just realized the new implementation is really easy so I should probably refactor
<fengb>
Mutation + return value is really annoying to stick into a function
<KoljaKube>
Off-topic re fundude, river: Fun thing about zig is how all the authors of the more well known projects can be found in one place. Reminds me of my old #clonk days (not that I expect any overlap)
<leeward>
Mmm, returning from the outer function would make it complicated.
<KoljaKube>
(Clonk was/is a C-like scriptable game with a very tight-knit community)
* marnix
will drop soon, see y'all later.
<leeward>
KoljaKube: It is cool, but I look forward to the day when there are significant projects written in Zig by people who don't rebuild the compiler from master at least a few times a week.
<leeward>
That said, having an actual community with a large portion of the users is pretty great.
<KoljaKube>
leeward: Sure, I get that. I was just being nostalgic, that was the time I was a) really getting into programming and b) basically living in IRC. It's nice to repeatedly recognize names.
<KoljaKube>
Also I don't think I have had so much fun with a language since I started learning ruby
<ifreund>
hey river is still 0.6.0 for now
<KoljaKube>
And I download tarballs due to the polly linker problem ;-)
<ifreund>
don't want to track master as it would make packaging pretty much impossible
marnix has quit [Ping timeout: 240 seconds]
<leeward>
I have a patch for the libpolly thing that I keep in my repo. Want to build? Push the patch, then build, then pop the patch.
<leeward>
It's a 1 line change.
<leeward>
msp430 blocked for the moment, but I just got a pair of nRF52840s. Looking forward to being able to actually use Zig for the whole chain.
<KoljaKube>
Is there a lot of advantages to building master over using the tarballs? I have a script that jq's the latest version from the homepage and installs it into /usr/local
<leeward>
Only if you want to make changes.
<KoljaKube>
The limitation I wanted to mention next (I don't) ;-)
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
xackus has quit [Ping timeout: 240 seconds]
<KoljaKube>
Well, it's getting late. See you very fine people later
KoljaKube has quit [Quit: WeeChat 2.8]
marijnfs has joined #zig
<marijnfs>
invalid token: 'var
<marijnfs>
what did i miss
<ifreund>
var -> anytype when used as a type
<marijnfs>
danke mein freund
<andrewrk>
`zig fmt` auto fixes it
<leeward>
Oh, when did that happen?
<ifreund>
last couple days?
<leeward>
nifty
marijnfs has quit [Quit: Lost terminal]
marijnfs has joined #zig
ur5us has joined #zig
<marijnfs>
the var keyword was indeed overused, so its better