<andrewrk>
g-w1, yes you are trying to test a std lib copy
<andrewrk>
you'll need to delete the copy that you don't want to exist, or use --override-lib-dir
<g-w1>
hmm, im just trying to use an installed zig
<g-w1>
i might have screwed something up
<g-w1>
andrewrk: for 8561 there was a mismatch between error int being u32 and cbe using uint16_t for it
<g-w1>
im trying to fix that and prevent it in the future until the proposal gets implemented
<andrewrk>
uint16_t is correct
<andrewrk>
also the u32 is correct
<g-w1>
now im very confused
<g-w1>
what does the u32 do?
<andrewrk>
if there ends up being more errors than fits in a u16 then zig will emit a compile error
<andrewrk>
sorry for not documenting this better
<g-w1>
is this right now, or planned?
<andrewrk>
after #786 is implemented, the user will decide the error type, but compiler will still use a u32
<g-w1>
ahh, so u32 is the *max*
<andrewrk>
yes
<g-w1>
ohh, that makes a lot of sense :P
<andrewrk>
yeah my bad for not putting better doc comments there
<g-w1>
One idea is to have the error set integer type have a default of u32 <- i thought this meant, that u32 was the new default
<andrewrk>
we'll do it like the panic function, the error type will be decided by @import("std").builtin.ErrorInt
<g-w1>
ok, it was a misunderstanding, so u16 is still the default?
<andrewrk>
which will be: `pub const ErrorInt = if (@hasDecl(root, "ErrorInt")) root.ErrorInt else u16;
<andrewrk>
we can bikeshed what to put there instead of u16
<g-w1>
makes sense
<g-w1>
closing pr
<g-w1>
wait, this can be implemented now, or can the compiler not see it yet?
<andrewrk>
this will require a stage1 and stage2 change to implement
<g-w1>
ok
<g-w1>
actually, ill change the pr to rename it to `MaxErrorInt` and add a doc comment
<andrewrk>
sounds good
<g-w1>
does zig have any equavalent to `objcopy`?
frmdstryr has joined #zig
xackus_ has joined #zig
xackus has quit [Ping timeout: 252 seconds]
frmdstryr has quit [Ping timeout: 252 seconds]
a_chou has quit [Quit: a_chou]
osa1_ has joined #zig
osa1 has quit [Ping timeout: 252 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 252 seconds]
<andrewrk>
we have a zig build step that might do what you nead
<andrewrk>
*need
<andrewrk>
g-w1, check out installRaw
ur5us__ has joined #zig
ur5us__ has quit [Ping timeout: 258 seconds]
leon-p has joined #zig
earnestly has joined #zig
leon-p has quit [Quit: leaving]
osa1_ is now known as osa1
ur5us__ has joined #zig
leon-p has joined #zig
retropikzel has quit [Quit: Leaving]
ur5us__ has quit [Ping timeout: 258 seconds]
leon-p has quit [Quit: leaving]
SimonNa has quit [Quit: Leaving]
l1x has quit [Quit: Connection closed for inactivity]
earnestly has quit [Ping timeout: 265 seconds]
dyeplexer has joined #zig
daex has quit [Quit: /me 's znc kicks the bucket]
daex has joined #zig
LewisGaul has joined #zig
vazub[m] has joined #zig
amk has quit [Remote host closed the connection]
daex has quit [Ping timeout: 240 seconds]
daex has joined #zig
<g-w1>
ok, il check it out
pretty_dumm_guy has joined #zig
<plumm>
What do y'all do when there is a C api you are consuming and they have pluggable allocators? Could you write a type that wraps a mem.Allocator and use that?
<g-w1>
yes, you can, or just use the c allocators directly
<plumm>
tru tru
<plumm>
I think something is wrong iwth linking frameworks in zig 0.8.0-dev.1963+2b2920f59
<g-w1>
try ZIG_SYSTEM_LINKER_HACK=1 env var
LewisGaul has quit [Ping timeout: 240 seconds]
<plumm>
ah got the env var wrong
<plumm>
oh man
<plumm>
ok that works, thanks
<g-w1>
np
leon-p has joined #zig
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<txdv>
I compiled llvm12 and installed it to a custom directory, is it possible to tell cmake the location of that dir when compiling zig?
frmdstryr has joined #zig
<ifreund>
txdv: it should check LD_LIBRARY_PATH
leon-p has quit [Quit: leaving]
<ifreund>
hurgh, why doesn't @tagName() return the the same type as a string literal, or at least a 0 terminated slice
<txdv>
O boy, I waited for modules so long and now it is keeping me from getting zig compiled ;D
<txdv>
What clang version are you guys using to compile zig? clang version 12.0.0 (https://github.com/llvm/llvm-project.git d28af7c654d8db0b68c175db5ce212d74fb5e9bc)
<semarie>
which is "LLVM sources to llvm 12.0.0 plus one commit" :)
leon-p has joined #zig
<txdv>
nice
kchambers has joined #zig
pretty_dumm_guy has joined #zig
Akuli has joined #zig
<andrewrk>
ifreund, that particular change seems reasonably straightforward, can probably look at @embedFile for guidance
<ifreund>
andrewrk: thanks for the tip, I worked around it for now but do plan to try it before 0.8.0
<ifreund>
though the glibc linking thing should probably take priority...
<andrewrk>
we still have about a month and a half
<g-w1>
andrewrk: did you decide to change stage1 to use stage2 astgen?
<ifreund>
I'm not convinced that would be worth the effort tbh
<andrewrk>
no it is just an idea I am teasing in my head
<g-w1>
oh ok
<g-w1>
i think anyways, a binary format will need to be decided and astgen will have to be finished, so we have a while
<ifreund>
it's not just the upfront cost of modifying stage1 to accept ZIR, we'd also have to maintain that code as ZIR continues to evolve
<ifreund>
which slows down stage2 development long term
<andrewrk>
yeah
<andrewrk>
g-w1, the binary format is near trivial with the way ZIR is encoded
<ifreund>
yeah the binary format is the easy part :D
<andrewrk>
since there are no pointers you can just yeet the bytes to and from the filesystem
<g-w1>
yes, but i imagine some versioning will have to be a header so that weird bug reports don't get filed
<andrewrk>
nah we already use the zig version as part of the cache namespace
<ifreund>
I think the cache system should already prevent that
<g-w1>
ohh nice
<andrewrk>
the only thing you have to watch out for is if you're working on zig and change the format, and don't wipe the cache. in this case your zig version will be the same (because you have a dirty tree)
<g-w1>
this has happened to me, luckily i remembered pretty quickly
<andrewrk>
but that's a feature, it's the only way to work on the cache system / binary format itself
<g-w1>
oh btw, i migrated my os to fully zig build system, but installRaw did not do what i wanted
<g-w1>
i think i might need objcopy :(
<andrewrk>
ifreund, I have a small snippet of code that is an argument that `zig fmt` should support alignment for switch prongs / function calls
<ifreund>
andrewrk: tbh, I'm not a fan of zig fmt support alignment for array elements, I think `// zig fmt: (off|on)` is the best and simplest solution
<andrewrk>
hmm that's fair
<ifreund>
it now works at token granularity
<andrewrk>
thanks for the recent fix btw
<ifreund>
no problem :)
<andrewrk>
I saw that the other day happening in my editor, pretty funny and dramatic
<ifreund>
with format on save it is indeed quite fun :D
<andrewrk>
it's like, "hmm. this is not sustainable"
<ifreund>
same thing happend to me and I was like "hey... wasn't it me that wrote this code?"
<andrewrk>
ok having it work at the token level is a pretty good counter argument
<ifreund>
also if we get rid of array alignment support we don't need an allocator!
<andrewrk>
also a great point
<ifreund>
that code isn't unicode-aware by the way
<andrewrk>
that might be the nail in the coffin
<ifreund>
alright well I'd be happy to tear it out if you agree that it's the way to go :)
<andrewrk>
let's do it the official way with a proposal
<andrewrk>
just saying that I'm going to do `// zig fmt: off` here
<ifreund>
Yeah there are definitely cases where deviating from the canonical fmt is good, that's why I made // zig fmt: off work better
<ifreund>
(ther fair enough was a reply to the proposal)
<andrewrk>
much appreciated. I think it wasn't really usable before
<g-w1>
would it be out of zig's scope to include some sort of objcopy?
<andrewrk>
in scope
<g-w1>
would you consider just linking llvm-objcopy?
<andrewrk>
that's the "and toolchain" part of "Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software." :)
<g-w1>
ok cool
<andrewrk>
objcopy is not worth depending on LLVM for IMO. it's just a simple CLI on top of ELF parsing
<andrewrk>
we want it to work even in non-llvm-enabled builds
<g-w1>
does it just take the header out of elf stuff?
<g-w1>
if so, maybe i could try to implement it, since i have a use case :)
<andrewrk>
my suggestion would be to implement it in your own repo where you can iterate quickly and then once it is to your satisfaction, upstream it
<g-w1>
makes sense since it is pretty independent
dyeplexer has quit [Remote host closed the connection]
<andrewrk>
it's a well-scoped but useful project, perfect fit for you I think
SimonNa has joined #zig
earnestly has joined #zig
<Flaminator>
andrewrk have there been any thoughts about Zig without an std? So having just the absolute minimum of interface for a compiler to use every feature in the language? There is currently builtin.zig, but builtin.zig also contains structs with functions that take or return types outside of the file part of the std.
<g-w1>
whats the use case for this?
<andrewrk>
Flaminator, as far as I'm concerned that use case is solved already. if you override the default panic handler and export your own start symbol, the std lib does nothing except provide a few enums the language depends on
eax has joined #zig
LewisGaul has joined #zig
<Flaminator>
g-w1 I was just mostly interested in a split between what one would consider the zig language, and the standard library. I am sadly just an average joe so no compiler building, programming for esoteric systems or any of that kind of stuff.
<g-w1>
you can totally do it! i was just an "average joe" a few months ago
waleee-cl has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
<Flaminator>
I guess that's the way it currently works with the compiler andrewrk, I was mostly thinking about if someone was to build their own zig compiler without having an implementation of the std. It would still be nice to have access/a definition to all of the things returned by @functions or special paramaters without having to implement or have functions that can't be called because of reference to
<Flaminator>
things in the std.
<g-w1>
a lot of @functions depend on the stdlib for compiler rt
<g-w1>
are you thinking std.builtin would just be in the generated @import("builtin") file instead of in the stdlib?
<Flaminator>
I was mostly thinking about having std.builtin (The current builtin.zig file) being something special in the language like how @import("root") and @import("std") are special in the language.
<g-w1>
yeah, thats exactly what im saying, put it in @import("builtin") with all of the other platform-dependent stuff
leon-p has quit [Quit: leaving]
<Flaminator>
I am not sure what the current @import("builtin") includes though as it gets called in builtin.zig.
<g-w1>
while std.builtin just defines types that it uses
<Flaminator>
Ah ok, but yeah it was just something I've had in my head for a really long while.
Akuli has quit [Quit: Leaving]
barakkl1993 has joined #zig
eax has quit [Ping timeout: 240 seconds]
kchambers has quit [Quit: WeeChat 3.1]
<g-w1>
Flaminator: the only other zig compiler (zyg) also intends to use the zig stdlib, so i dont really think this is a problem
<noam>
zig's stdlib is basically part of the language, it doesn't make sense to replace it wholesale
<noam>
(so long as it isn't awful, the way glibc is - and zig's stdlib is no glibc)
<fengb>
It’s also replaceable using --override-lib-dir
ur5us__ has joined #zig
<g-w1>
not builtin, thats what Flaminator is talking about
<ifreund>
I think this will become clearer as the languge spec progresses, std.builtin will have to be part of that spec
<Flaminator>
I am not judging the std or anything here naom. I just feel to keep the language standard/spec small including the std in the standard/spec would not make sense in that regard.
<ifreund>
tbh, what use is a std if it's not part of the spec?
yxprogramming has joined #zig
<noam>
ifreund: as a distinct spec?
<noam>
Flaminator: std.builtin != std. I think if std.builtin is moved into @import("builtin") it's less of an issue
<g-w1>
i would be for moving it to @import("builtin")
<ifreund>
noam: if you can't rely on the std functions being available to *all* zig code, then you have a split ecosystem
<ifreund>
you see this with the rust #[no_std] sub-ecosystem
<Flaminator>
I was mostly going for moving language specific things that are part of the language not live inside of the std noam. So for example having an @import("zig") only containing language features.
<ifreund>
there is no reason for this inzig
<noam>
ifreund: agree to disagree
<noam>
I think a split ecosystem can be a good thing
<ifreund>
why?
<ifreund>
that just leads to code duplication. *reusable* software is part of zig's tagline
<g-w1>
yeah, zig already kinda has no_std because lazy
<noam>
ifreund: it's not duplication. There's different approaches to different problems, and one-size-fits-all solutions are exceedingly rare
<ifreund>
noam: that's an argument for having 2 packages with 2 different approaches to the same problem, not two incompatible ecosystems
<noam>
stdlib is one of those packages, except worse - it contains solutions to a *ton* of problems
<noam>
fundamentally, another stdlib could take different approaches to *all* of them, solve extra, not solve some that the stdlib does, and be a perfectly good alternative
<noam>
and, naturally, that'd lead to split ecosystems
<noam>
i'm not saying it's necessarily good, just that I don't see it as intrinsically *bad* - it depends on the situation
<noam>
ifreund: e.g. windows, linux, mac, freebsd, and plan9 are five different ecosystems. Would we be better off if only one existed? I don't think so.
<g-w1>
also, the stdlib does not need to be tied to the compiler, as long as it implements builtin correctly.
<Flaminator>
I am not against std being standarized that's a good thing for it to be standarized. I was just wondering if core language features could be kept seperate from it.
<g-w1>
Flaminator: it totally could. i would say the next thing to do is make a proposal if you want this change
yxprogramming has quit [Quit: leaving]
<Flaminator>
Just wanted to pulse people's interest first but I guess I can try making a proposal somewhere the coming week..
carldd has joined #zig
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
barakkl1993 has quit [Ping timeout: 252 seconds]
yxprogramming has joined #zig
<yxprogramming>
hello, I had a question about linking C libraries cross-platform. I have a project that needs to have libC linked (arm-freestanding-eabi), but the the build fails because it is unable to link libC. I have a libc for the target installed on my machine, so I'm not really sure what I need to do to get it to link. Can anyone help me?