waleee-cl has quit [Quit: Connection closed for inactivity]
return0e_ has joined #zig
return0e has quit [Ping timeout: 276 seconds]
lunamn has quit [Quit: leaving]
adamkowalski has quit [Quit: Lost terminal]
<mgxm>
wilsonk: great, thank you for sharing
<mgxm>
i din't know about tabnine
<mgxm>
neat
<scientes>
simd PR rebased again. When we get further along I will also redo the @shuffle and @gather and @scatter syntax stuff
<andrewrk>
scientes, nice - can you give me the first commit from that PR as a separate one?
<scientes>
oh yes
[rg] has joined #zig
<[rg]>
what release should I use on windows?
<scientes>
that type of review would be easier with the linux workflow...
<[rg]>
ok, what release is preferred for linux?
<scientes>
[rg], everybody is using master
<scientes>
git
<[rg]>
ok, that makes it seem like zig is really stable
<[rg]>
cool
<scientes>
uggh, more the opposite
<[rg]>
oh, what? lol
<wilsonk>
mgxm: no problems
<scientes>
we use master because things are still changing fast
<scientes>
although the CI must past for every commit so if you write a test for it it will work
<andrewrk>
[rg], zig is very unstable right now. give 0.5.0 a shot, and if you run into bugs or missing features then you can potentially tip your toes into master branch. but there is not planned to be a 5.0.1 release; next planned release is 0.6.0 in April
<[rg]>
ok, thanks
<[rg]>
I'll see if I can have some fun :)
<[rg]>
ah very awesome to see a microbit projet
<andrewrk>
but also know that there are already major breaking changes to the language between 0.5.0 and master. with more on the way
<andrewrk>
I will make this assertion about the future: once we are shipping the self-hosted compiler (rather than stage1), the zig project will start having bug fix releases in addition to minor releases, along the path to 1.0.0
<[rg]>
andrewrk, thanks
[rg] has quit [Ping timeout: 260 seconds]
<daurnimator>
scientes: I think you could also submit 174a6d4a587e1baacd1bb659f872cd928c6fa04b sooner rather than later
<daurnimator>
scientes: s/loose/lose/
<daurnimator>
(in 25c5ad1be061fa36b7fdf6ee6deac4e1c9b5d16d)
ltriant has quit [Ping timeout: 252 seconds]
muffindrake has quit [Ping timeout: 252 seconds]
<daurnimator>
andrewrk: any more merges expected today? :)
muffindrake has joined #zig
<andrewrk>
daurnimator, not today. how did you like my counter proposal to #3731
<daurnimator>
andrewrk: 2 thoughts: 1. why is sentinel different enough from align() to be inside the [] vs outside 2. `:` as a separator could be confusing as its also used for bit indexing in various places
<andrewrk>
(1) the [] has to do with the length of the pointer; align does not
<andrewrk>
for (2) I don't think I'm interested in any feedback that isn't a counter proposal
<daurnimator>
1. fair, makes sense. 2. I guess my counter proposal is that with that confusing-ness, I'm still happy with it being outside the [] with a keyword.
<andrewrk>
I see
<andrewrk>
either way I think I agree with you on making it more general rather than using the word `null`
<daurnimator>
`[5 sentinel(0)]u8` ?
<andrewrk>
too noisy, and `sentinel` is likely to clobber an identifier. we're not trying to punish people for using null terminated strings
<daurnimator>
don't we prefer slices with tracked length?
<andrewrk>
generally, but plenty of ABIs use null termination. And tracked length is not strictly better. It has higher memory requirements, for example
<andrewrk>
even if you do not interact in any way with C or libc, you need null termination for interacting with, for example, the linux syscall ABI
<daurnimator>
sure; but not e.g. for windows nt.
<companion_cube>
ugh, saving 1 word minus one byte
<companion_cube>
and paying O(n) length, unsafe strings, and bugs aplenty :/
<daurnimator>
yeah one thing I still don't like about the current null PR is that the length is only a *max*. there could be another null byte in the middle...
<andrewrk>
companion_cube, this is a type feature that makes them safe
<andrewrk>
if you make null pointers hard to annotate, it's not going to make people avoid null pointers; it's going to make them avoid annotating them
<companion_cube>
I'm just ranting about null-terminated strings :)
crimson_penguin has quit [Ping timeout: 264 seconds]
reductum has quit [Quit: WeeChat 2.6]
crimson_penguin has joined #zig
chemist69 has quit [Ping timeout: 276 seconds]
chemist69 has joined #zig
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
return0e_ has quit [Ping timeout: 245 seconds]
return0e has joined #zig
adamkowalski has joined #zig
<adamkowalski>
Whats the recommend way to get a string from an int?
<Pistahh>
adamkowalski: or std.fmt.bufPrint - it takes the buffer to print into so no need for allocator
<adamkowalski>
Well who allocates the buffer?
<adamkowalski>
How do you know how big to make it?
<adamkowalski>
I guess you know the max number of digits that an int can be at compile time
<adamkowalski>
Then you can allocate the buffer once and reuse it?
<Pistahh>
yes this only works if you have some idea about the max final size of the string generated. You can just allocate a buffer as a local variable, so it goes into the stack
adamkowalski has quit [Ping timeout: 240 seconds]
<daurnimator>
yeah if you e.g. have a u32, then you know that it can't be longer than 10 chars
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
return0e_ has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
<mq32>
daurnimator, your mixin style interfaces only work "per instance", right? so i cannot create an array of different object types with the same interface?
<mq32>
oh, funny bug:
<mq32>
zig fmt fails when a tab is in a comment :D
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
knebulae has quit [Read error: Connection reset by peer]
return0e_ has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
return0__ has joined #zig
return0e_ has quit [Ping timeout: 276 seconds]
<scientes>
mq32, that might be desired
<scientes>
actually, that is according to spec mq32
adamkowalski has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 265 seconds]
<mq32>
scientes: huh? why that?
<mq32>
it fixes tabs when in "blank space", but errors when in "comment space"?
<scientes>
oh zig fmt
<scientes>
i thought you meant the language spec
<scientes>
my bad
<mq32>
no, i'm talking about fmt :D
mq32 has quit [Quit: Winke winke!]
adamkowalski has quit [Ping timeout: 240 seconds]
mq32 has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 276 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
jacereda has joined #zig
<jacereda>
hi
<jacereda>
how would you write a 'ctry' function that turns ?T into !T ? To be used like "const foo = ctry(c.CreateFoo()); errdefer c.DeleteFoo;"
<mq32>
foo() orelse error.OptionalWasNull
<jacereda>
mq32: I'm not sure I follow... Is this the idiomatic way? "const foo = c.CreateFoo() orelse error.OptionalWasNull; errdefer c.DeleteFoo();"
<mq32>
i would code it like that
<mq32>
it doesn't require any special features and *should* work :D
jacereda has quit [Ping timeout: 240 seconds]
waleee-cl has joined #zig
Guest46760 has quit [Remote host closed the connection]
quetzalb has joined #zig
adamkowalski has joined #zig
Akuli has joined #zig
return0__ has quit []
<muffindrake>
I see that there's a choice between blocking and event-based mode in io.zig. How would I set it to use event-based processing in my code?
adamkowalski has quit [Quit: Lost terminal]
reductum has joined #zig
FireFox317 has joined #zig
<FireFox317>
muffindrake: in your top level of your root file put: `pub const io_mode = .evented;`
wilsonk has quit [Ping timeout: 240 seconds]
<muffindrake>
Aah, so that's what that comment meant. Well then, thank you.
wilsonk has joined #zig
vexu has joined #zig
wootehfoot has joined #zig
<marler8997>
andrew why create an assembler? Does LLVM not have good ones?
<mq32>
marler8997: to get rid of LLVM as a dependency in the long term
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
Akuli has quit [Quit: Leaving]
Ichorio has joined #zig
mahmudov has joined #zig
squeek502_ has joined #zig
FireFox317 has quit [Read error: Connection reset by peer]
\u has joined #zig
Ekho has quit [Disconnected by services]
FireFox317 has joined #zig
meowray has quit [Remote host closed the connection]
squeek502 has quit [Ping timeout: 240 seconds]
danielvu has quit [Read error: Connection reset by peer]
Ekho has joined #zig
<ky0ko>
i'm toying around with the idea of doing some baremetal code for old MIPS machines, is there a way i can tell the zig build system that i want to output ECOFF format binaries?
<ky0ko>
the bootloader for the platform i have expects that format
<ky0ko>
andrewrk, yes. it's a slightly modified variant of COFF. I'm quite positive LLVM supports outputting ECOFF, as well as XCOFF (another COFF variant of interest to me)
<mq32>
andrewrk: would it be possible to specify any output file type for any build target?
<ky0ko>
specifically ECOFF was used by MIPS operating systems and firmware from the 90s, and XCOFF was the standard for OpenFirmware machines (sparc and powerpc)
<mq32>
i know it would not make sense, but emit ELF for windows builds and PE for linux builds
<andrewrk>
issue #3182 is open for this
<andrewrk>
if it's something that makes sense to do, then yes it's in scope
<mq32>
okay, i'll write some stuff into that issue :)
<mq32>
freestanding does only support ELF right now, right?
<andrewrk>
correct
bjorob has joined #zig
<mq32>
added *and* edited a comment :D
adamkowalski has joined #zig
FireFox317 has quit [Ping timeout: 265 seconds]
<terinjokes>
just this morning I was thinking about writing an assembler for the Sharp LR35902, and then I opened GitHub
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<gruebite>
zig does not have any lambda replacement yeah?
<mq32>
lambda replacement?
<gruebite>
erm, lambda equivalent
<gruebite>
i can kinda see something working at comptime
<adamkowalski>
no lambdas yet I believe, but you can pass a function pointer
<adamkowalski>
whatever you would have closed over, make them additional arguments
<gruebite>
yeah, C style
<adamkowalski>
if it's conveniant you can build an "environment" struct yourself which has the closed over variables and pass that in as the first argument
danielvu has joined #zig
ltriant has joined #zig
ntgg has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
ntgg has quit [Client Quit]
wootehfoot has quit [Read error: Connection reset by peer]
mikdusan has joined #zig
adamkowalski has quit [Quit: Lost terminal]
<shakesoda>
gruebite: there are some issues on the tracker for those
<shakesoda>
idk what kind of priority they have but i would really love them, and otherwise treating functions as just values
adamkowalski has joined #zig
<adamkowalski>
andrewrk: hey are you there?
<daurnimator>
mq32: yes that's correct.
<mq32>
daurnimator, answer to what question? :D
<daurnimator>
mq32: though there's sort of a "trick" I have in mind for that: you can create a union of the two types you are interested in, provide the base function, and then mixin to the union
<daurnimator>
mq32: 20:14:12 <mq32>daurnimator, your mixin style interfaces only work "per instance", right? so i cannot create an array of different object types with the same interface?
<daurnimator>
uh I missed the mixin: `union(enum) { Foo: Foo, Bar: Bar, pub const ReadError = Foo.ReadError || Bar.ReadError; pub fn read(self: @This(), dst: []const u8) ReadError!usize { return switch(self) { else => |u| u.read(dst); } usingnamespace io.InStream(@This()); }`
mahmudov has quit [Ping timeout: 240 seconds]
<daurnimator>
gruebite: you can, but it's awkward right now: `const myfunc = struct { pub fn foo() void {} }.foo;` <-- and you can e.g. return this from a compile-time function
mahmudov has joined #zig
<mq32>
daurnimator, yeah, this *may* work, but it will be kinda weird
<mq32>
as i don't really have "functions" implemented on that interface except for read/write
<daurnimator>
mq32: yeah that's all you're meant to have implemented....
<mq32>
yes, and that's all functions i'm gonna need for that interface :D
<daurnimator>
mq32: my idea for the InStream mixin is that you just implement ReadError and read(); and the rest gets filled out for you.
<mq32>
yeah, that will work for instream
<mq32>
i have a slightly different case
<mq32>
i have functions working with generic block devices
<mq32>
and i need to store them in a uniform list
<mq32>
so yeah, maybe the union way
<mq32>
dunno yet, i haven't even decided on how the UI for that feature should look like, so i cannot reason much about implementation for that ^^
<mq32>
the plan right now is to have something like `ATA → Partition Table → ZGSPartition → Image` and Image is the final block device i will use
<daurnimator>
which is pretty much getting back the old/current interface style from the mixin one.
<mq32>
yeah, but the mixin doesn't fit my use casse anyways, was just curious
<mq32>
i need the "old style" interfaces or tagged unions
<mq32>
and the last ones with pointers, not object instances
<daurnimator>
yep
<daurnimator>
hopefully those lines show how you can derive them from the mixin style though :)
vexu has quit [Quit: WeeChat 2.6]
<daurnimator>
going the other direction is much more difficult and comes with runtime overheads
<mq32>
hmm
<mq32>
i think i'm just going to implement some kind of list for the UI
<mq32>
"those are your available memory slots to load/save"
<mq32>
like in older games where you have slot 1,2,3
<mq32>
but this time with block devices in the backend
protty has joined #zig
<marler8997>
zig is trying to get rid of llvm as a dependency?
<mq32>
marler8997: "llvm is an implementation detail"
<daurnimator>
marler8997: long term yes; short term no
<daurnimator>
marler8997: but whenever there's something we want that LLVM doesn't have: rather than adding it upstream to LLVM, we are quite happy to implement it ourselves to get closer to the long term goal.
<marler8997>
llvm has hundreds of thousands of hours of development time and a large ongoing support effort. it's developed to be shared amongst any language. We'd have to make a much better version to justify losing all that shared effort I think
<marler8997>
would zig's version also be meant as a shared framework like LLVM, or just zig-specific?
<fengb>
Zig was always intended to not depend on anything, including LLVM. The reference implementation might be using it as an implementation detail, but the core spec should not require it
<fengb>
And there's a lot of naysayers about LLVM too
<mq32>
it's good to have a spec that does not contain any dependencies
<mq32>
code generation e.g. should be always an implementation detail
<mq32>
compared to "behaviour specification" which just describes what memory transfers and operations happen when and what side effects those must/must not/may have
<fengb>
We're tied in the short term for a good reason, but eventually we'll have at least a GCC backend. Plus all the embedded people hopefully want to write Zig compilers
<daurnimator>
zig can't be truly "self-hosted" with an LLVM dependency.
<daurnimator>
the intention is not to remove support for LLVM: but to turn it down from a requirement to an "optional"
<marler8997>
actually zig could sort of be self-hosted if it added support to compile c++ code as well :)
<mq32>
that's a very weak definition of self hosted
<mq32>
also c++ code cannot implement a lot of features that zig has
<mq32>
@addWithOverflow is one example
<fengb>
__builtin_add_overflow 🙃
<mq32>
ah yes, but that's "c++ for gcc"
<mq32>
:D
<marler8997>
__builtin_add_overflow, that's funny, I just patched a couple tools that were using that
<fengb>
Well it's also for clang so just it's the defacto standard now
<mq32>
heh
<mq32>
i would like to see some more specific features in zig later
<mq32>
but those are very post1.0 features :D
<mq32>
but something like a scriptable linker would be neat
<mq32>
so you could generate custom output formats or implement some more specific rules in the linker
<fengb>
I'm really happy with LLVM too. Wasm was the main reason I started using zig :D
<mq32>
some embedded processors require checksums placed in certain positions and that's always annoying to implement. simplest way is to patch ELF files, but that's also really dirty
<marler8997>
in any case, I hope LLVM remains as a backend option
<mq32>
i don't say we should drop LLVM as a backend, but make it optional
<protty>
hey, would it be reasonable to assume that `std.time.Timer.start()` cannot fail?