<andrewrk>
I did some work on zig fmt today (got carried away merging DrDeano's pull request) and now formatting the entire std lib (when it is already formatted correctly and fs cache warmed up) is taking 0.3 seconds on my linux laptop, 0.6 seconds on my mac laptop, and 0.6 seconds on my windows laptop
<squeek502>
nice, i'm assuming you fixed the AccessDenied error on windows? was starting to look into that
<andrewrk>
yeah, about to push
<Snektron>
andrewrk: in the zig compiler, whats the general style for breaking long if conditions?
<squeek502>
cool, should have a PR ready soon afterwards to add `zig fmt` to the cli tests so that these types of zig fmt regressions are tested
<Snektron>
(in the c++ part)
<andrewrk>
squeek502, good call. We have as a sanity check zig fmt run against build.zig, but not against a directory
<Snektron>
and should i add a special error message about -unsigned?
blinghound has joined #zig
<andrewrk>
your call
<shachaf>
If you're doing a file system traversal thing you don't probably need to stat it, getdents will tell you whether it's a file or directory.
<shachaf>
Oh, but I guess this is about supporting symlinks.
<shachaf>
So maybe you do have to stat it (or probably you can optimistically open and getdents).
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
<leeward>
Unreachable at ./zig/src/link.cpp:1799 in getLDMOption. This is a bug in the Zig compiler.
<leeward>
Sad trombone sounds.
blinghound has quit [Remote host closed the connection]
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
swills has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
slowtype1 has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
a_chou has joined #zig
_whitelogger has joined #zig
a_chou has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
_whitelogger has joined #zig
<leeward>
Is there magic to turning a comptime_int into a *u8?
<leeward>
Never mind, missed @intToPtr
<leeward>
So much for avr support: getting an LLVM error when I try to build a trivial program.
<leeward>
hmm, maybe it's a regression since 0.6?
<leeward>
Well, godbolt thinks so but when I build it myself I get the same error. Tomorrow's problem.
dermetfan has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
Snetry has quit [Ping timeout: 256 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
waleee-cl has joined #zig
Snetry has quit [Ping timeout: 258 seconds]
Snetry has joined #zig
drewr has quit [Ping timeout: 260 seconds]
neceve_ has joined #zig
drewr has joined #zig
dddddd has joined #zig
<andrewrk>
I think avr is still experimental within llvm
Sahnvour has joined #zig
<mq32>
yeah, AVR isn't fully-featured in LLVM10
nikita` has joined #zig
Xavi92 has joined #zig
<scientes>
I doubt it ever caught up to gcc-avr
<scientes>
but seriously, Z80 is stonger in that market, and otherwise arm-M
waleee-cl has quit [Quit: Connection closed for inactivity]
<mq32>
scientes: there's a new backend for AVR
<scientes>
but why do people use avr-8?
<scientes>
it is slow and expensive
<mq32>
because they have a nice purpose
<scientes>
z80 is cheap, and arm-M is fast
<mq32>
cheap, simple
<mq32>
z80 has a lot more problems than AV
<mq32>
Also, i've never seen an industrival device since 2000 that is z80
<scientes>
gcc has __builtin_shuffle, and clang has __builtin_shufflevector
<scientes>
just because they WANT to be incompatible
<Xavi92>
mq32: gcc does not support STM8, but SDCC + stm8-binutils-gdb can be used instead. The STM8S003F3 is significantly cheaper (0.25 US$) than its AVR competitors
ifreund has joined #zig
ifreund[m] has joined #zig
Thalheim has quit [Ping timeout: 260 seconds]
<blinghound>
Is there an equivilant to calloc anywhere? or shall I allocate and then use @memset?
<blinghound>
ah nvm
<blinghound>
does allocator.alloc clear the memory too?
<daurnimator>
blinghound: zero initialising is considered bad in zig. (it only exists for compat with external APIs)
<blinghound>
ok awesome, alloc and then memset?
<daurnimator>
blinghound: in release modes no. in debug modes it sets it to 0xaa
<daurnimator>
blinghound: std.mem.set if you need it.... though why?
<blinghound>
I'm using the freetype library and I want to allocate and zero out to construct a bitmap
<blinghound>
although I could just set to 0 manually as I create the glyphs
<blinghound>
thinking about it now it doesn't really matter if the unused bitmap memory is zero'd out or not
<blinghound>
I'm translating a 40,000ish line c++ project and it's hard to get out of the c/c++ mindset
<ifreund>
that's quite ambitious, what made you decide to switch?
frett27 has quit [Ping timeout: 264 seconds]
<blinghound>
zig's compile times, @import system instead of #includes, headers and macros, zig's comptime, better error management
<blinghound>
I could go on, I'm in love with zig
<blinghound>
I've translated approx 7000 lines already and it's working beautifully
<ifreund>
yeah I also love zig, always curious to hear what others find most awesome about it
<ifreund>
my personal favorite feature is probably stronger, more granular pointer typing
<ifreund>
though it's not the most exciting or revolutionary thing, it makes writing correct code so much easier
<gonz_>
A lot of the smaller things make me much more confident in my code. Just the basics making you more aware of null in places, switch exhaustiveness checks, overflow awareness, etc.
<blinghound>
exactly. I was writing my own language for a few months to try to fix a subset of the problems I was having with c/c++, but then I found zig
<gonz_>
These are things you can count on for the most part in higher level languages but to have essentially a C these things added is a breath of fresh air.
<blinghound>
I'm kinda fond of the explicit casts too
Snetry has quit [Ping timeout: 240 seconds]
<ifreund>
yeah, I personally feel kinda icky when using higher level languages that pile on the abstraction or do things like GC.
<ifreund>
i want my code to be optimal
<ifreund>
though quick python hacks certianly have their time and place, i want something serious like C for major projects
<gonz_>
I feel the same way but rather than I want to know what's going on to a much higher degree. I honestly can't tell when a higher level language is going to allocate for the most part, for example, and playing games with the language to see if you can make it fast isn't fun.
<blinghound>
even with c++ that's a big problem in game development
<gonz_>
Ultimately one of the end goals of knowing what's going on is certainly to make it fast if I need to, but also I'd just like to feel like I have more clarity with regards to my code.
<gonz_>
It's almost disturbing that I feel so much more confident reading Zig code than I do in languages that I've read on/off for many years.
<blinghound>
definitely, I can barely read my own c++ template code after a week
<blinghound>
zig's generics solution is the best I've seen in any language
cole-h has joined #zig
<blinghound>
just wish I had more income to sponsor andrew
<gonz_>
I think Zig has legs on it to some degree, I wouldn't worry too much about it right now.
Snetry has joined #zig
<ifreund>
yeah, i'm absolutely in love with how zig solved generics. The rules are so simple yet so powerful
<mq32>
<blinghound> zig's generics solution is the best I've seen in any language
<mq32>
true
<ifreund>
I think one of the best things you can do to help out aside from throwing money at andrew is writing non-trivial software in zig
<ifreund>
which it sounds like you're already doing :D
<gonz_>
I was gonna say, this conversion is a few steps in that direction already.
<blinghound>
I'll let the chat know when I release the project I'm working on. It'll be open source too
<gonz_>
Please do :)
<ifreund>
yes for sure!
_Vi has joined #zig
<ifreund>
oh right, zig showtime is happening again today in like 15min
<mq32>
join the pre-show, talk about italien food!
<ifreund>
that sounds like a great way to hit a use-after-free
<blinghound>
do you mean like 'fn returnSlice() []u8 { var arr: [5]u8 = {1, 2, 3, 4, 5}; return arr; }'
<gonz_>
blinghound: `return arr[0..upper_bound]`, but yes.
<gonz_>
It compiles but this feels like I'm just returning an invalid pointer
<ifreund>
yes you are
<gonz_>
The thing about returning an array is that it works, but I feel like this one shouldn't...?
<blinghound>
shouldn't that be a compile error?
<gonz_>
I feel like it should, yes
<mq32>
blinghound: it's a non-trivial analysis feature, but yeah, it should be
<ifreund>
i think it's tricky
<mq32>
cases like this aren't that hard
<gonz_>
But returning `[N]T` is safe, yeah? Since I'm now learning new things all of a sudden, let's confirm this one.
<mq32>
but you have to keep track of local variable assignments for this
<mq32>
gonz_: yes, returning [N]T is a value, not a pointer
<gonz_>
good, good
<mq32>
usually, when you want to return a slice to something, pass the memory in the function itself:
<mq32>
fn foo(backing_buffer: []T) []T { }
<gonz_>
Mhm
<ifreund>
to be clear, a slice is just a special struct with pointer and length fields
<ifreund>
it doesn't hold any of the memory directly
<gonz_>
Mhm, hence my hesitation about this working
<ifreund>
arrays on the other hand are a block of memory of fixed size
<blinghound>
yeah don't you have to pass the backing_buffer by address for that to work?
<blinghound>
hmm I'm confusing myself a bit now
<mq32>
blinghound: slices are just "struct { ptr: [*]T, len: usize }"
<ifreund>
you would call foo with { var buf: [100]u8 = undefined; const my_slice = foo(&buf);
<blinghound>
@mq32 would the function declaration need to be 'fn foo(backing_buffer: *[]T) []T'
<blinghound>
or something
<blinghound>
to pass the actually array memory in
<blinghound>
actually that would be a pointer to a slice
<mq32>
no
<mq32>
you just pass the slice
<mq32>
a slice doesn't contain the memory
<mq32>
it's just a reference/pointer
<blinghound>
ohhh got it
neptunepink has quit [Ping timeout: 260 seconds]
Akuli has joined #zig
wootehfoot has joined #zig
Thalheim has joined #zig
wootehfoot has quit [Ping timeout: 264 seconds]
neptunepink has joined #zig
kubkon has joined #zig
blinghound has quit [Remote host closed the connection]
<dch>
is there a dedicated irc|chat for zig.show?
<ifreund>
dch: nope, you can just ask questions in here
<kristoff_it>
yeah, just make sure to @kristoff_it so I don't miss them
<kristoff_it>
:D
<dch>
no worries this is my first live stream with questions. I'm cross-advertising the next segment in elixir slack & irc so want to point people to the right place
<dch>
kristoff_it: sterling job mate curating the community, thanks so much
<dch>
huh iphone app is ~ 30s behind the webpage
<ifreund>
twitch can be kinda weird sometimes :D
<kristoff_it>
dch: thanks!
aerona has joined #zig
Snetry has quit [Ping timeout: 240 seconds]
blinghound has joined #zig
<blinghound>
is there a way to print an integer as a char?
<mq32>
{c}
dingenskirchen has quit [Quit: dingenskirchen]
Snetry has joined #zig
dingenskirchen has joined #zig
<blinghound>
perfect thanks mq32
dingenskirchen1 has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen1 is now known as dingenskirchen
blinghound has quit [Remote host closed the connection]
* mq32
just got a stupid idea
<mq32>
we have `const foo = @import("generated.zig");`
<mq32>
make a thing that runs a code generator at build time and alows
<mq32>
`const foo = @generate("generator.zig")`
<mq32>
which is a module that returns code on stdout ^^
<leeward>
I know I'm many hours late to the discussion, but I do tend to agree that ARM is a better fit for pretty much everything than AVR these days. I just happened to have an Arduino Uno sitting around and wanted to see if I could get Zig code to run on it. Answer: no; LLVM bugs.
<leeward>
An STM32F0 sips power and can actually (barely) run an RTOS.
<mq32>
leeward: that's imho a non-argument that if an experimental toolchain that doesn't work 100% yet, does not work yet
<leeward>
mq32: I'm not saying AVR isn't good because Zig doesn't build for it. I really like working with them, there just isn't a reason to do it any more.
<leeward>
It's not like I can use Zig at work anyway.
<mq32>
it's simpler
<mq32>
for simpler jobs AVRs are easier to setup and code
<mq32>
using the UART on an AVR is a 4-liner
<mq32>
using it on a arm processor is way more complex to my experience
<mq32>
you have to set up a PLL first
<mq32>
you have to route pins in a more complex way
<leeward>
It is simpler, but cost per unit is usually our biggest concern. If we're only building 1 of a thing then AVR's an option.
<mq32>
first place of cost per unit is currently held by a chinese 6ct microcontroller :D
<mq32>
for for small tasks, the attiny are really cheap
<leeward>
Sure, but I can get a 24 cent Cortex-M0 on digikey where the cheapest AVR is 27 cents.
<leeward>
Oh, and that 24 cents is for 1. The 27 cent ATiny was for 2,500
<mq32>
24ct for attiny10
<mq32>
ah wait
<leeward>
Granted, Digikey doesn't have the best prices, but they're comparable
kubkon has quit [Ping timeout: 245 seconds]
<mq32>
yeah
<mq32>
i just noticed
<mq32>
interesting that ARM is now even cheaper
<leeward>
They're taking over.
<dch>
what do you use something that small for?
<leeward>
The only stuff I see other processors in is extremely power constrained and specialized, like MSP430s in medical implants.
<mq32>
dch: one (real life) example is the controller for a laser gun
<mq32>
you can do battery management, impulse length, fire modes, maganzine counting
<mq32>
but you don't need a lot of pins or precision for something like that
<dch>
mq32: neat
<leeward>
dch: Things I've worked on that use tiny processors: smart cards, speakers, headphones, medical implants, bootup processors on network equipment, battery powered sensor platforms
<mq32>
pretty much anything that doesn't require high-perf computing or high pin counts
<leeward>
Another thing that leads to multiple processors with varying capability is in safety critical systems: less-critical code generally has to be isolated from the more-critical code. One way to do that is with separate processors. Nobody wants to spend huge money or power or board space for that secondary processor that doesn't need it.
<leeward>
At least it's ARM not x86.
<mq32>
yeah or you have medical stuff where both processors agree on what they do
<mq32>
or one surveills the other one
<leeward>
My senior project in school involved 3 ARM processors (made by Intel!) running the same code in lockstep, with an FPGA in the middle to reset the system if one disagreed on where they should be.
<leeward>
Probably should have used simpler processors though. ARM is, as mq32 said earlier, fancy.
<ifreund>
gotta protect against those cosmic rays :D
<mq32>
yeah
<leeward>
ifreund: Exactly.
<mq32>
but: i own a blue pill (STM32) now, just for the sake of doing zig on a embedded platform
<leeward>
I have a complete AVR toolchain set up just waiting for Zig to work.
<leeward>
Back on the shelf, I guess.
<mq32>
haha, same here :D
<leeward>
I guess building Zig for this RPi 1B is as close as I'm going to get for a while.
frett27 has joined #zig
<leeward>
hmm, I wonder if I could sneak an MSP430 dev kit out of work long enough to get Zig to build something for it.
<leeward>
Mmm, try to build a no-op program for msp430-freestanding-none and "Unreachable at /home/nathan/zig/zig/src/link.cpp:1799 in getLDMOption. This is a bug in the Zig compiler."
<mq32>
haha, is that a problem?
<mq32>
(the sneaking out)
<leeward>
Well I'd have to go into the office, which I haven't done since...March? April?
<leeward>
I don't even know any more.
<leeward>
Gotta get approval from the president to be in the building.
marmotini_ has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Ping timeout: 240 seconds]
<leeward>
Ooh, got 0.6.0 to assemble something
<andrewrk>
leeward, that "unreachable" sounds like a missing linker feature. if you look at the code it's pointing at it should be fairly obvious what's going on
<andrewrk>
check if lld supports msp430 and what -m flag should be used for it
<leeward>
It's the same error I get with avr; I think I might be passing the wrong arguments somewhere.
<andrewrk>
check the code and you'll see what's going on - it's not your code that is the problem
<leeward>
getLDMOption isn't matching my ZigTarget. It looks like it's not in the list.
<andrewrk>
exactly. but I just looked at LLD source and it looks like they may have added support since that code was written
<leeward>
Well that's nice of it.
<leeward>
I'll see if I can add it and get it to build.
<andrewrk>
I don't see msp430 here. I would ask in #llvm what -m flag is expected when making an ELF file for MSP430
<andrewrk>
or - if that architecture does not use ELF, then it means zig should be using a different binary format, or using LLD in some other way, rather than hitting that unreachable
<leeward>
andrewrk: This is some solid documentation: "-m: set target emulation"
<leeward>
No list of allowed values, no suggestion of what target emulation might be.
<andrewrk>
yeah, to use the LLVM project APIs often means reading source code
<andrewrk>
it's not so bad
<andrewrk>
the next step is to find out what should be happening for the msp430 target, then we can figure out where in the toolchain the control flow needs to be modified
<leeward>
also avr
<leeward>
starting with that one, since I can actually test the output with what I have here
<leeward>
Mmm, looks like the avr target is running into issues with usize being 16-bit.
<leeward>
It's not clear why my build is calling std.math.exp2_64, but...that function does not like 16-bit usizes.
dermetfan has quit [Ping timeout: 244 seconds]
<leeward>
whew, that was not the only case
<leeward>
And after all that I end up with "LLVM ERROR: Not supported instr"
slowtype1 has quit [Quit: WeeChat 2.8]
slowtyper has joined #zig
ur5us has joined #zig
<gonz_>
mq32: Your idea about `const module = @generate("./generator.zig");` is intriguing.
<mq32>
oh wow, someone noticed that :D
<mq32>
not sure if i really like it, but i think the basic idea is kinda nice
<gonz_>
It might easily get out of hand, but it's certainly interesting.
<gonz_>
Granted, you could generate code in a build step even now and just import the result, right?
<mq32>
as a lot of people want to generate code with comptime anyways, why not add a facility to generate code with a standard interface
<gonz_>
The standard interface would be nice because at least you can enforce rules, but at the same time the result if normal code generation is also immediately available.
<gonz_>
s/if/of
<mq32>
but something like this could also be included in the zig build system
<mq32>
instead
<mq32>
making it more obvious
<gonz_>
Yeah, I agree.
<ifreund>
I agree, this doesn't need language-level support since it can be done through the build system
<frett27>
ZLS is awesome, thank's alex and august !
<leeward>
^^
<mq32>
yes, indeed. ZLS is really nice
<gonz_>
+1
<frett27>
yep saves me time to dive into zig std lib !! awesome !
<mq32>
still recommended!
dermetfan has joined #zig
Akuli has quit [Quit: Leaving]
blinghound has joined #zig
<mq32>
pixelherodev: Kristall 0.3 was just releaed
<blinghound>
if I have a function 'fn foo(values: []u8) void'
<blinghound>
what's the best way of coercing a single value to a slice there?
<blinghound>
so I can call 'foo(single_u8_value)'
<mq32>
i think with master, (&ptr)[0..1] is possible?
<ifreund>
foo(&[1]{ value }); should also work
traviss has quit [Remote host closed the connection]
<mq32>
that will not yield a mutable slice though
traviss has joined #zig
<ifreund>
indeed
<blinghound>
hmm I'm getting error: slice of a single-item pointer using the (&ptr)[0..1] syntax
<blinghound>
I'm using today's master
<mq32>
you probably need @as([*]T, &v)[0..1]
<blinghound>
that gives me error: expected type '[*]u8', found '*u64'
<blinghound>
sorry, 'found '*u8'
<blinghound>
not u64
<mq32>
ah then it's probably not merged :D
<blinghound>
that might be it then! ;D
<blinghound>
for now I'll just make a slice manually
<blinghound>
cheers guys
<blinghound>
that sounds like a first world problem, making a slice manually, I just thought I could have been missing a shorthand
<mq32>
you can also just pointer-cast that :D
<mq32>
@ptrCast() instead of @as()
<mq32>
@ptrCast([*]T, &v)[0..1]
<ifreund>
can you init slices like structs? e.g. const foo: []u8 = .{ .ptr = &v, .len = 1 };