ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
emekoi has joined #zig
<emekoi>
can zig link objective-c code?
<nbjoerg>
abi-wise objective c is pretty much normal C as long as you don't want to do dynamic dispatch directly
<emekoi>
that's good to hear
<nbjoerg>
hm. in deferUnwindExample -- wouldn't it be better to say "defers are not run if they have not been reached"?
<nbjoerg>
for the UB list, I'm missing division overflow?
<nbjoerg>
(i.e. for i8: -128 / -1)
<nbjoerg>
hm. is that assumed to be under the general integer overflow section?
m4ge123 has joined #zig
<nbjoerg>
the language from @divFloor in regard to that needs to be copied to @divExact
<nbjoerg>
?
<andrewrk>
nbjoerg, looks like you have some useful feedback/fixes for the lang ref. I'm interested in that information but I'm not able to focus on it at the moment
daurnimator has joined #zig
<daurnimator>
Can someone confirm to me that there is now exponentiation operator?
<MajorLag>
There is no exponentiation operator. You have to use `std.math.pow`. Though I do think scientific notation is parsed for literals.
<daurnimator>
MajorLag: thanks
<daurnimator>
Does setRuntimeSafety(true) work in ReleaseFast mode?
<daurnimator>
e.g. if I have a block that I *always* want checks on for?
<diltsman>
Any idea why my build would fail with -1073740791?
<daurnimator>
andrewrk: cool :)
<andrewrk>
diltsman, happy to help, can I see some more details?
<diltsman>
This is the build output: TODO implement C ABI for this architecture. See https://github.com/ziglang/zig/issues/1481 The following command exited with error code -1073740791: Z:\Zig\zig-windows-x86_64-0.3.0\zig.exe build-exe Z:\Zig\SAM3X8E\test.zig --cache-dir Z:\Zig\SAM3X8E\zig-cache --output Z:\Zig\SAM3X8E\zig-cache\SAM3X8E --name SAM3X8E --target-arch armv7m --target-os freestanding --target-environ eabi --linker-script build.ld
<diltsman>
What else do you need? Simple .zig file with a global table and a function. Simple build.zig.
<diltsman>
Given that I will not be using an C, is there something that I can do as a workaround?
<andrewrk>
you ran into an unimplemented feature, which you can read more about on that issue. if you post the particular C ABI you need I can try to prioritize it to unblock you. (just posting the extern function will be sufficient to communicate which C ABI you are trying to use)
<diltsman>
I only have this function: nakedcc fn _start() void
<diltsman>
There are no functions or variables declared extern.
<andrewrk>
what target arch?
<andrewrk>
oh I see it now
<andrewrk>
this is probably a quick fix
<daurnimator>
misc thought: can zig files gain a magic-number?
<daurnimator>
as in: something that can be detected with binfmt_misc
<andrewrk>
it sounds like you're trying to intentionally defeat deterministic builds?
<andrewrk>
can you explain the use case?
<daurnimator>
andrewrk: pretend that zig programs are scripts.
<daurnimator>
i.e. be able to use zig as a scripting language
<MajorLag>
you can already do that I think, with zig run and a #! line.
<daurnimator>
though that's probably acheiveable with a shebang? (is that supported?)
<andrewrk>
what os is binfmt_misc for? shebang lines are supported
<daurnimator>
andrewrk: binfmt_misc is a linux feature
<MajorLag>
can't binfmt_misc work off of the filename pattern or am I misremembering?
<daurnimator>
MajorLag: no, binfmt_misc looks for a pattern in the file. like looking for an elf header, or a bytecode header for some languages, etc.
<andrewrk>
diltsman, I'm not getting that failure with zig master branch
<daurnimator>
MajorLag: oh wait no, there is the "E" type. I forget about that
<andrewrk>
with this source: export nakedcc fn _start() void { }
<diltsman>
I will try it with the master branch in a few minutes.
<andrewrk>
diltsman, ok. I apologize for the breaking changes that you probably run into. we're at the beginning of a release cycle, so there's quite a bit of breaking changes
<diltsman>
Not a big deal. My whole code base is 15 lines.
<diltsman>
Thanks. I was looking for that but couldn't find the artifact link.
<MajorLag>
You need to pick a green build from appveyor, then its a tab on the right.
<diltsman>
Ah.
<diltsman>
What should be here? The error message says it expects a semi before the curly. const vector_table align(4) section(".vector") = vectortable: {
<MajorLag>
probably: `const vector_table align(4) section(".vector") = vectortable: vectorable.{` if vectorable is a struct. Could be shortened to `const vector_table align(4) section(".vector") = vectortable.{`
<MajorLag>
this was a recent syntax change that looks like it will be reverted soon.
<diltsman>
Thanks. Now we are to the point of fixing the linker script, but that shouldn't be terrible.
dbandstra has joined #zig
<andrewrk>
diltsman, the linker is LLD
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
emekoi has quit [Quit: Page closed]
bheads has quit [Ping timeout: 272 seconds]
dbandstra has quit [Quit: Leaving]
davr0s has joined #zig
daftpunk has quit [Quit: WeeChat 1.6]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hejsil has joined #zig
<Hejsil>
andrewrk> "oh I see, you made the parser code according to the grammar you worked on"
<Hejsil>
I haven't made the stage1 and 2 parser follow the grammar yet
davr0s has joined #zig
porky11 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
m4ge123 has quit [Read error: Connection reset by peer]
porky11 has quit [Ping timeout: 264 seconds]
m4ge123 has joined #zig
Hejsil has quit [Ping timeout: 256 seconds]
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<nbjoerg>
andrewrk: given that you now give good compile-time functions, have you considered supporting D-like mixins?
<nbjoerg>
(btw, the intro statement about RT and GC is misleading if not wrong. it's quite possible to do real-time garbage collection)
porky11 has joined #zig
<andrewrk>
nbjoerg, according to the D docs "mixins enable string constants to be compiled as regular D code and inserted into the program."
wilsonk has quit [Read error: No route to host]
<andrewrk>
zig plans to not have this feature. comptime code gets you 90% of what you would need from this feature, without resorting to string generation, and for the remaining 10% you can generate code like normal using the build system
<andrewrk>
although as an aside I would personally suggest considering if there are viable alternatives to code generation before doing it
<andrewrk>
I stand by the Realtime/garbage collection statement. The most straightforward, verifiable way to create realtime software is to manually manage memory
<andrewrk>
although I'm not sure where you're reading this from. I don't see it on ziglang.org homepage
m4ge123 has quit [Read error: Connection reset by peer]
<nbjoerg>
"Why Zig.." in the wiki
<nbjoerg>
I'm just saying that are hard-real time gc implementations
<nbjoerg>
as all things hard real-time, they operate under certain constraints, but it can be done
<nbjoerg>
that said: the question more mixin is that it is one safe way to allow generic endogenous types without too much repeation
<nbjoerg>
i.e. linked list with internal storage
<nbjoerg>
without too many constraints
<nbjoerg>
in a way that also allows having multiple link entries in the same parent etc
<nbjoerg>
which is quite important for low-level applications like system kernels :)
<nbjoerg>
bbl
<andrewrk>
a hard real-time garbage collector has the vulnerability that if you allocate memory faster than the gc can keep up, you exhaust system resources. to avoid this situation requires careful memory management and understanding of the gc implementation. this defeats the purpose, making manual memory management the simpler choice
Hejsil has quit [Quit: Page closed]
porky11 has quit [Ping timeout: 264 seconds]
porky11 has joined #zig
wilsonk has joined #zig
davr0s has joined #zig
allan0 has quit [Ping timeout: 252 seconds]
allan0 has joined #zig
SimonNa has quit [Remote host closed the connection]
SimonNa has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
given that memcpy intrinsic has alignment annotations, would it be a performance improvement if llvm could emit libcalls to, e.g. memcpy1, memcpy4, memcpy8, etc where the number is the alignment value?
<andrewrk>
oops meant that for #llvm on OFTC
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
allan0 has quit [Ping timeout: 272 seconds]
allan0 has joined #zig
DutchGh0st has joined #zig
<DutchGh0st>
how do I convert the []T returned by pub fn alloc(self: *Allocator, comptime T: type, n: usize) ![]T { into a *T ?
<DutchGh0st>
&returned_slice[0] ?
<nbjoerg>
andrewrk: pretty small
<nbjoerg>
andrewrk: IIRC ARM did something like that at some point
<nbjoerg>
andrewrk: but generally, it rarely matters
<DutchGh0st>
and how do I go back from a ptr to a slice?
<DutchGh0st>
free seems to take a slice?
<nbjoerg>
andrewrk: still missing the point that most of those constraints apply to non-gc memory management just as well
<nbjoerg>
andrewrk: e.g. you still have the problem of how to correctly free large nested object graphs etc
<nbjoerg>
there is a reason why a lot of hard rt coding standars disallow memory allocation at all...
<DutchGh0st>
why does that complain on line 33, "error: expected error union type, found 'box(i32,*(struct Allocator constant))"
<nbjoerg>
andrewrk: going back to the mixin question
<DutchGh0st>
oh, it was the 'try' keyword
<DutchGh0st>
huh
<nbjoerg>
andrewrk: strings are just somewhat natural as the parser has to deal with them anyway and string manipulation is something easily done
<nbjoerg>
andrewrk: I don't think the current comptime functions really fit the same nieche nor do I think they provide equivalent ease of use
<nbjoerg>
andrewrk: consider a structure that should be on more than one $container without additional allocations
<nbjoerg>
andrewrk: how do you handle this with comptime functions alone without nesting (which is ugly and breaks abstractions)
<DutchGh0st>
mh, what if you have a ptr to some heap memory, obtained by a call to allocator.alloc, but the heaped memory itself is also a resource again, will it kind of like recursively free?
<DutchGh0st>
or its just 'once you free you're toast'
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<nbjoerg>
note the various *_ENTRY entries, that are for different linked lists the kernel thread might be a member of
<andrewrk>
you can use std.LinkedList for this
<nbjoerg>
for multiple lists in the same structs?
<andrewrk>
yes
<andrewrk>
use fields of type `std.LinkedList(void).Node` if you want strictly intrusive linked lists; otherwise use something other than `void` if you want the nodes to contain a value
<nbjoerg>
ISTM that would require nesting the list
<andrewrk>
then use @fieldParentPtr to get from a node pointer to the lwp or whatever struct
<andrewrk>
which is what the intrusive linked list macros do in the linked c code
<nbjoerg>
ah, that's the exactly the kind of boilerplate that I would like to avoid...
<andrewrk>
what boilerplate?
<nbjoerg>
having to repeat the element name
<nbjoerg>
but I might be missing something. sec
<nbjoerg>
right, fieldParentPtr seems to be quite redundant
<nbjoerg>
i.e. I should have to tell it the name of the node class
<nbjoerg>
(I shouldn't really have to know that name of the field either, that's already a concession to the limits of the preprocessor in C)
<andrewrk>
I don't think string processing metaprogramming is better than using the field name
<nbjoerg>
well, ignore that part for a momment
<nbjoerg>
what it looks like could be something like: mixin(linkedList, entry1); maxin(linkedList, entry2) etc
<nbjoerg>
which gives you entry1 with an unnamed struct, members for manipulation, maybe an iterator at some point in the future and a type for declaring the container itself
<nbjoerg>
similar for entry2. no further use has to mention it.
<nbjoerg>
well, @mixin
<nbjoerg>
without support for introspecting the current context, it might need an argument for the outer type as well, but again, that's a minor aspect
<nbjoerg>
it doesn't have to be string based -- but string based avoids the need for further special syntax
<nbjoerg>
it could also be a builtin-return type that just specifies a block or struct to be merged
<nbjoerg>
anyway, I can create a more consistent and thought out proposal if you are interested as soon as I have some time
<nbjoerg>
hm. can't find an open issue for the lack of pointer aliasing discussion in the langref?