<pixelherodev>
Unrelated: huge thanks to Andrew for aaf99371b22e816a4162391d799b9d22bba21120
<pixelherodev>
I plan on maintaining a 0.6 with backported bug fixes (though I'll probably update it like once or twice a week and not immediately), would be interesting to see how performance can be improved if maintainability is discarded :P
<pixelherodev>
Probably not much, by me at least
<pixelherodev>
Still don't have enough familiarity with the zigc source for that
<emekoi>
i think you can pass .res files to the linker
<emekoi>
try `LibExeObjStep.addObjectFile` on the res file
darithorn has joined #zig
<pixelherodev>
Ahh thanks
<andrewrk>
mikdusan, feel free to push to master on those release notes changes. and thank you very much!!
<foobles>
what is the diffeerence between IrInstGen and IrInstSrc?what i also find interesting is that IrInstSrc contains a pointer to an IrInstGen alwaysbut both contain the IrInst base
<darithorn>
am I using ArrayList wrong or is it broken? I create a new array list, append a 12 byte slice into it but the array list length is set to 20
<pixelherodev>
You're using it wrong ;)
<pixelherodev>
The array list allocates more space than it needs
<andrewrk>
speaking of breaking ArrayList, it just broke again, 5 seconds ago
<pixelherodev>
^
<shakesoda>
was that always invalid and i got lucky it worked or did the semantics of slicing that way change
<foobles>
and `ZigValue`s contain type info right? So with a IrInstrSrc, is it just null or something?
<andrewrk>
shakesoda, if you slice a sentinel-terminated thing with no end index, you get a sentinel-terminated result
<pixelherodev>
Oh neat, that recent breakage doesn't bother me :)
<pixelherodev>
I already switched to span
<pixelherodev>
Now I'm just deprecated :)
<shakesoda>
i was putting sentinels on them myself and expected the :0 to just promote the type
<darithorn>
i noticed that the extra bytes are all set to a constant value, in my case it was 170. so i figured something was up
<shakesoda>
saying "yes, i know what i'm doing here"
<pixelherodev>
darithorn, that's undefined
<pixelherodev>
0xAA
<andrewrk>
foobles, no - that was one of the improvements. only IrInstGen has a ZigValue
<pixelherodev>
It's inserted in debug mode to indicate uninitialized memory
<darithorn>
okay that makes sense
<pixelherodev>
Try updating to HEAD, it should work then :P
<pixelherodev>
Or
<pixelherodev>
wait for 0.6
<andrewrk>
sorry about the ArrayList churn. the new API is objectively simpler and has a footgun entirely removed
<foobles>
aaah i see. thanks
<foobles>
that makes sense
<pixelherodev>
andrewrk, no worries (from me at least)
<mikdusan>
foobles: IrInstSrc.child is a compiler-pass thing. IR "src" is an earlier pass, and "gen" is a pass after that. when a "src" inst gets generated into a "gen" inst, it's useful to have that link to follow. we don't need to follow from gen back to src.
<pixelherodev>
Huge thanks
<foobles>
cool :thumbsup:
<darithorn>
that's all good, as long as its a known issue
<shakesoda>
why is span marked as deprecated
<pixelherodev>
Not an issue so much as "outdated"
<pixelherodev>
shakesoda, because it is :P
<andrewrk>
shakesoda, now you can just reference the items field
<pixelherodev>
.items is now usable directly
<shakesoda>
ok
marijnfs_ has quit [Quit: Lost terminal]
<andrewrk>
here's the thing about zig's language and std lib design: nearly everything took several tries to get it right. the willingness to keep iterating is what makes zig higher quality. we're not smarter or better than anyone else, we just are willing to keep trying again until we get it right
<shakesoda>
i'm fine with things changing, it's just frequently not obvious 1) that they did, 2) why they did
<andrewrk>
that's a really good point
<andrewrk>
I'm working hard on the release notes, to make those things clear
<shakesoda>
i expect my code to break a /lot/ in the ever-dangerous land of pre-1.0
<andrewrk>
I've literally done nothing but merge pull requests and work on release notes for the past 2 weeks
<darithorn>
oh wow my copy of the stdlib is older than i thought. i guess this week has gone by faster than i realized
<fengb>
There’s a bit of pressure to pull in all the breaking changes before release
<shakesoda>
andrewrk: and help people on irc :P
<shakesoda>
not to be forgotten
<andrewrk>
true
<foobles>
when can you assume that an IrInstrGen has a valid `child` pointer?
<foobles>
since i assume that during 1st pass there are no Gen instructions for it to point to
<mikdusan>
Zig is like Westworld: "Those early years were glorious... no guests, no board meetings... just pure creation."
<andrewrk>
foobles, it's assigned in ir_analyze(). I think it would help you to read that function's control flow, it's kinda like the "driver" of pass 2
<pixelherodev>
`we're not smarter or better than anyone else, we just are willing to keep trying again until we get it right` I think that should be in the Zen of Zig :)
<foobles>
alright. i was just seeing some of the other ir_analyze_* functions assuming that the child pointers existed
<foobles>
thanks :]
<pixelherodev>
Is it worth me learning the internals of the compiler now? Or would it be better for me to wait for self-hosted first?
<andrewrk>
foobles, the direct answer to your question is: when an IrInstSrc is analyzed, one or more IrInsntGen are generated and added to the IrExecutableGen. The IrInstSrc is then associated (by setting child) with the last IrInstGen of that sequence
<foobles>
nice, ok
<andrewrk>
foobles, this is important so that, when analyzing the next IrInstSrc, which points to the previous IrInstSrc, we can look at the associated *generated* instruction
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
<foobles>
are the IrInstSrc a list then? Or more of a tree
<foobles>
i dont see any pointers to the "previous" IrInstSrc
<mikdusan>
roots are IrExecutable{Src,Gen} which have ZigList<IrBasicBlock{Src,Gen}> .basic_block_list
<mikdusan>
each bb has .instruction_list
<foobles>
hmm ok
<foobles>
i will take a look around
<andrewrk>
it maps pretty closely to LLVM IR
<andrewrk>
I believe this is called "SSA form" or something like that
<pixelherodev>
To check OS, it's e.g. `if (std.builtin.os.tag == .windows)`?
<pixelherodev>
(derived from `zig builtin` output)
<pixelherodev>
Oh wait that's not what I even want though
<pixelherodev>
I want to check *target* (so I can just look through std.build to figure it out)
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
<foobles>
for all non-pointer optionals, is there a guarantee about the representation for the "data" part, when it's null?
<foobles>
like will it be zeroed out, for instance?
<shakesoda>
i'd expect undefined
<pixelherodev>
In debug mode maybe
<pixelherodev>
In release mode, there's no guarantees as I understand it
<pixelherodev>
They're represented by basically a structure with a type and a boolean
<pixelherodev>
The actual value won't be initialized in optimizing modes
<pixelherodev>
So debug + release-safe, 0xAA; release-fast + release-small, undefined
<pixelherodev>
Thanfully not undefined as in "can run DOOM upon access" :P
<pixelherodev>
I vaguely remember something about an early GCC doing that to make a point
<foobles>
heh that makes sense
<foobles>
makes optional comparison more difficult though :P
<mikdusan>
heh I got all excited reading on llvm list "F18 upstreaming finished!" and thought cool probably a new language so cool they named it after a fighter jet. /a bit disappointed: it's fortran '2018
<pixelherodev>
boo
<pixelherodev>
Smart timing for Fortran though
<pixelherodev>
Instead of F17/F19 :P
<foobles>
opt_1 == opt_2 has got to become `(opt_1 == null && opt_2 == null) || (opt_1 != null && opt_2 != null && opt_1.? == opt_2.?_`
<mikdusan>
hmm has it ever been proposed to allow comparing two optionals if their payloads are peer-type compatible?
<foobles>
yeah
<foobles>
its accepted
<foobles>
im trying to implement it :P
<mikdusan>
oh. I'm always behind :(
<pixelherodev>
Hmm
<pixelherodev>
Maybe just do a comparison of the raw bytes?
<foobles>
you cant, since the actual data part, if they are null, is undefined
<pixelherodev>
ahhh that's true
<mikdusan>
whoa no. if the payload types are same bit storage but different, we can't allow that
<pixelherodev>
no no
<mikdusan>
*same size
<pixelherodev>
mikdusan, if you have `var a: ?u8 = null` and `var b: ?u8 = null`
<pixelherodev>
Both are null
<pixelherodev>
but if you were to somehow access the u8 storage, that's undefined
<pixelherodev>
e.g. in IR
<pixelherodev>
So if you, for instance, set a value ?u8 to 3 then to null
<pixelherodev>
the u8 component might be 3
<pixelherodev>
it might be 0xAA (in debug mode)
<pixelherodev>
it could be anything
<pixelherodev>
It shouldn't normally matter, since you can't ever access it (unwrapping will fail)
<foobles>
so would it have to expand to that huge, kinda nasty expression i posted above?
<pixelherodev>
Yeah
<pixelherodev>
if you're the compiler, it means that, as foobles said, you have to do that
<foobles>
xd
<pixelherodev>
Hmm
<pixelherodev>
Might be able to make it a little simpler actually
<daurnimator>
pixelherodev: you're picking projects that take ~5 years to get anything usable. do something that takes like... 6 months to 1 year
<pixelherodev>
I think a distro could show meaningful results within six months
<pixelherodev>
OS would take more than five years undoubtedly
<pixelherodev>
But distro wouldn't
<pixelherodev>
Also
<pixelherodev>
The components I would long-term use for the OS are used for a game system emulator / Zig compiler backend short term
<pixelherodev>
Both of which are short- or medium-term (less than a month for the former, less than three for the latter if I had to guess) projects
darithorn has quit [Remote host closed the connection]
<pixelherodev>
One key difference between the OS idea and the distro one is that the distro one doesn't actually require a new compiler or JIT or anything
<pixelherodev>
It can just use upstream LLVM
<gchristensen>
I probably shouldn't be here. I usually just idle, and only feel inclined to chip in when I want to talk about Nix :P... but Nix has the benefits of static and dynamic linking, in dynamic linking but with statically defined locations. sharing, but no instability.
<pixelherodev>
Installing a package == IR -> "-march=native" binary
<pixelherodev>
I'm aware of Nix, but it doesn't really solve the issue in a way I like
<pixelherodev>
Having a bunch of disparate folders isn't a real solution
<pixelherodev>
It's not bad by any means
<pixelherodev>
But I think that it's possible to do better
darithorn has joined #zig
<pixelherodev>
That is, for all intents and purposes everything is statically linked
<pixelherodev>
But the package manager knows dependencies and can relink statically on updates
<mikdusan>
gchristensen: yeah the whole notion of -l<name> searching is bad enough without "first of static or dynamic" nonsense
<gchristensen>
I'm not sure I understand the quoted bet, mikdusan :)
<andrewrk>
I just realized, `zig cc` lets you switch branches without rebuilding everything
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
<andrewrk>
thanks daurnimator - pushed
<emekoi>
wait should i tell cmake to use zig cc to build zig from now on?
<shakesoda>
probably
dimenus|home has joined #zig
<mikdusan>
andrewrk, section: Accepted Proposals; for 0.6.0 is this going to be a list of current PR accepted for 0.7.0 ?
darithorn has quit [Remote host closed the connection]
<mikdusan>
s/0.6.0/imminent release notes/
darithorn has joined #zig
<pixelherodev>
If I'm linking libc, shouldn't stdlib.h be present? :(
<pixelherodev>
This is for C++ code though
<mikdusan>
pixelherodev: os?
<pixelherodev>
So I probably need `linkSystemLibrary("stdc++")
<pixelherodev>
Linux ofc
<mikdusan>
is that a new linux distro? :P
* pixelherodev
rolls eyes
<pixelherodev>
Gentoo
<pixelherodev>
Ugh I see
<pixelherodev>
It's a freaking #include_next
<pixelherodev>
In <cstdlib>
<emekoi>
andrewrk mingw ci is building successfully
<pixelherodev>
Which is imported from <string> so I can't fix it
<mikdusan>
errr wait. we ship enough .h for include_next purposes from clang I believe. do you have a simple repro?
<pixelherodev>
Gahhh no
<pixelherodev>
It's trying to use GCC system headers
<pixelherodev>
Not the Zig ones
<pixelherodev>
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/g++-v9/x86_64-pc-linux-gnu/bits/os_defines.h:44:5: error: function-like macro '__GLIBC_PREREQ' is not defined
<pixelherodev>
GAH
<pixelherodev>
Maybe I need to specify a different -Dtarget ?
<mikdusan>
this is a blind shot but try anyways: recently changed to no longer generate this file, but can you make sure zig-cache/native_libc.txt is nuked. and ~/.cache/zig/stage1/native_libc.txt is nuked.
<pixelherodev>
With -Dtarget=native I get the include_nexe error again :(
<pixelherodev>
mikdusan, Neither is present
<mikdusan>
k
<emekoi>
does zig cc always use the bundled libc?
<pixelherodev>
Hmm
<pixelherodev>
When targeting native, it uses /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/g++-v9/cstdlib
<pixelherodev>
Is that normal?
<pixelherodev>
Compiling C seems to work fine though
<andrewrk>
daurnimator, tell them to build llvm, lld, and clang from source normally, how they do for all other cmake projects, with default options, and don't use the mono repo
<daurnimator>
andrewrk: do you have a demo of dynamically linking zig against clang/llvm anywhere?
<andrewrk>
not sure what you are asking. it's what is needed to build on homebrew
<pixelherodev>
mikdusan, thanks; let me know how it goes!
<andrewrk>
zig is not doing anything weird re: cmake/llvm config. we've bent over backwards to accommodate everything that both upstream and downstream want, and either way something is broken
<daurnimator>
remind me what the cause of ": CommandLine Error: Option 'mc-relax-all' registered more than once!" is again? that C++ constructors are getting run multiple times? because of linking the same thing twice?
<andrewrk>
yes c++ constructors getting run multiple times because static c++ libs get linked into multiple dynamic libs
<daurnimator>
do we know specifically which libs those are?
<daurnimator>
(which static lib(s) getting linking into which dynamic lib(s)?)
waleee-cl has quit [Quit: Connection closed for inactivity]
<mikdusan>
pixelherodev: ok I have a good repro
<pixelherodev>
yay?
<emekoi>
hah, zig doesn't build under `zig cc`
<emekoi>
i just find that kinda ironic
<pixelherodev>
I'mma just work on something else for now :(
<pixelherodev>
`/usr/local/lib/zig/libcxx/include/cstddef:44:15: fatal error: 'stddef.h' file not found` :(
<pixelherodev>
This still has your last patch though
<andrewrk>
zig provides stddef.h
<pixelherodev>
include_next
<andrewrk>
don't take my last patch with the re-ordered includes
<pixelherodev>
That's what I'm saying
<pixelherodev>
I didn't remove the reordered includes
<pixelherodev>
Going to do that now
<emekoi>
andrewrk, would you be okay with me porting my old code for finding mingw libc to zig and putting it stage2?
<pixelherodev>
Idea
<pixelherodev>
never mind
<pixelherodev>
:P
<andrewrk>
emekoi, take a look at e4eb817f7999a2ee9ff62f59a6bf72a57bdf40a5
<andrewrk>
that logic can be reinstated, but the problem is determining when to run it. the previous logic of looking at builtin.abi is not the correct answer for "should we look for mingw libc"
<pixelherodev>
Maybe mingw should be part of the target, like glibc and musl are?
<pixelherodev>
x86_64-windows-mingw?
<emekoi>
we have -gnu for that
<pixelherodev>
ahh
<pixelherodev>
So, if targeting -gnu, look for mingw libc?
<emekoi>
but zig ships with a mingw libc
<pixelherodev>
...hmm
<pixelherodev>
wat
<emekoi>
you didn't know?
<emekoi>
zig comes with musl libc as well
<emekoi>
perhaps just a `--use-system-libc` flag would suffice?
<pixelherodev>
No I mean
<pixelherodev>
Why should that be different from other platforms?
<pixelherodev>
If I'm targeting `native`, use s - ohhh
<mikdusan>
andrewrk: looks good. by reproduction and pixel's git repository are happy with your patch( https://clbin.com/9JjeB )
<pixelherodev>
It's a matter of whether mingw counts as system libc?
<pixelherodev>
mikdusan, andrewrk: can confirm
<mikdusan>
it's always nice to drop 3 include search dirs
<pixelherodev>
I have other issues now
<pixelherodev>
:P
<pixelherodev>
But that one is gone
<pixelherodev>
I think I might actually look into caching C files even when the overall build fails
<pixelherodev>
It'd definitely help me personally
<andrewrk>
emekoi, but what is the system libc? is it msvc or mingw? builtin.abi does not tell the answer
<emekoi>
for example, i don't have visual studio installed, but zig won't accept my libc file unless i put dummy paths for kernel32_lib_dir and msvc_dir
<emekoi>
but what about compiling c++ programs?
<andrewrk>
emekoi, zig supplies libc++ as well
<pixelherodev>
`I don't think zig should integrate with detecting native mingw libc` seconded
<pixelherodev>
That's the most reasonable solution IMO
<andrewrk>
I'd like to remove msvc integration too, if we can get away with it
<emekoi>
i'm relatively certain i'm getting linker errors from trying to link to llvm with `zig cc` because different versions of libc are being used
<pixelherodev>
All use of native libc should be eradicated IMO
<pixelherodev>
but that might be less feasible
<pixelherodev>
(e.g. macos, as discussed prior)
<daurnimator>
Is mingw actually same ABI as msvc though?
<emekoi>
i'm fine without getting rid of detection if we have a way to explicit opt in
<andrewrk>
emekoi, ok I do agree that libc text file format and the fields that it has, should support a mingw libc setup
<andrewrk>
daurnimator, I can't tell, did this get merged or what?
<andrewrk>
looks like it made it in
<mikdusan>
down the road I can see opt-in packages for "host libc" and "host libc++" which encapsulates all the probes/detection that comes along with that territory
<andrewrk>
well, at least it looks like upstream respects zig enough to make changes, that's nice
<mikdusan>
re llvm upstream: merged for say... 10.0.1 ?
<andrewrk>
hopefully. unclear
<mikdusan>
andrewrk: for the -lc++/stdc++ patch, are you progressing it or would you like me to PR it and... maybe we hold off on merge until after 0.6.0?
<pixelherodev>
Going to have to port the graphics backend from Oryol to Sokol :(
<pixelherodev>
Oryol would be a pain to integrate with build.zig
<pixelherodev>
Sokol is just headers :)
<pixelherodev>
I wanted to do that anyways, this just makes it more pressing
<andrewrk>
mikdusan, if you're happy with the patch, I'll commit it to master. I'm confident enough in this being a more stabilizing change than destabilizing
<andrewrk>
emekoi, I would be interested to know what linker errors you get if you do that thing you mentioned above
<emekoi>
what thing?
<andrewrk>
oh, because of mixing c++ compilers / c++ ABIs
<andrewrk>
you can build llvm with zig cc
<andrewrk>
it's tested
<emekoi>
oh, i just get `lld: error: duplicate symbol: vtable for llvm::opt::ArgList`
<pixelherodev>
I'm happy with the patch personally.
<pixelherodev>
It fixed the problem for me :D
<pixelherodev>
and I do agree conceptually that there's no reason to support both libc++ and libstdc++
<pixelherodev>
down the line TM, being able to use entirely custom libc and libc++'s would be nice
<pixelherodev>
But there's no reason to support it *now* in stage1
<daurnimator>
andrewrk: ^ thoughts on copying what ldc did in that link?
<andrewrk>
idk this doesn't look like it will solve the problem to me
ur5us has joined #zig
shakesoda has joined #zig
emekoi has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 260 seconds]
<daurnimator>
sorry, I don't know enough CPP to do this with any reasonable speed
<pixelherodev>
In other words, you're a good person?
ur5us has joined #zig
<mikdusan>
i invented a new word via typo. Consecurity .
<mikdusan>
how I got that instead of consecutive is anyone's guess
<andrewrk>
oh that's funny, I noticed that and assumed you had an amazing vernacular
<pixelherodev>
Skill?
<andrewrk>
I hit my quota for the day on release notes, gonna take a break now before bed
<andrewrk>
mikdusan, would you perhaps be interested in doing the Memory Usage Reduction section?
<mikdusan>
don't know how you do it andrew. I started to write up a bit with `zig cc` section and said wtf... don't even know where to begin. lol.
<mikdusan>
yeah I think I can take a stab at the memory usage section.
<andrewrk>
it doesn't have to be too involved, just give yourself some credit, show off the cool stuff you did
<daurnimator>
andrewrk: after your CTA before I also had a go at writing some release notes. suffice to say, don't let me write anything but code
<andrewrk>
lol
<andrewrk>
the noasync section can probably be backported to be used as docs in the lang ref
<mikdusan>
yes, once we release, someone (not you) maybe me, can go through the 0.6.0 release notes and backport stuff of value to lang ref
<andrewrk>
who wants to schedule/host/manage the online release party? :)
<andrewrk>
I could do a celebratory stream, but it would probably just be me asleep at my desk
* pixelherodev
celebrates!
<pixelherodev>
Two things worth celebrating now
<pixelherodev>
Zig 0.6
<pixelherodev>
and I just fixed my server!
<pixelherodev>
and it just beeped obnoxiously. :(
benjif has quit [Ping timeout: 258 seconds]
<daurnimator>
andrewrk: I'm happy to. let me know the times you're available....
<daurnimator>
timezones are hard
<pixelherodev>
That's not true.
<pixelherodev>
They're *evil*.
_Vi has joined #zig
<pixelherodev>
Writing a compiler is *hard*. Writing an OS is *hard*. Playing through or reading wiki entries about the plotline of Kingdom Hearts without bursting into laughter is *hard*.
<pixelherodev>
Time zones? They make all of those pale in comparison...
foobles has joined #zig
<foobles>
good morning
<pixelherodev>
Morning
<Snektron>
Mogge
<ikskuh>
someone here told me about a configurable assembler some day ago
<ikskuh>
pixelherodev, was that you?
<pixelherodev>
Might have been?
<pixelherodev>
I know of a few
<pixelherodev>
The one I'm using currently is scas (disclaimer: I'm the de facto maintainer since Drew no longer works on it and I'm the one only one left with experience with its internals)
<pixelherodev>
There's also customasm, which looks neat but I've never really used
<pixelherodev>
With scas, you define the ISA and either a) embed the table into the executable instead of the default z80 one (that's what I'm doing for LIMN) or b) bundle the table with scas / use it locally (`scas -a /path/to/isa.tab`)
<mikdusan>
well first is the name. I mean atatatat is just weird :)
* pixelherodev
grins
dermetfan has joined #zig
<daurnimator>
ouch, and fstatat is not only broken.... it doesn't have a windows implementation
<mikdusan>
here's a name that clears things right up: `os.@"fstat@"`
<Snektron>
st@@
<mikdusan>
ah yes. `os.@"fst@@"`
<mikdusan>
here's an easy way to remember mem is undefined: `var @"0xaaaaaaaaaa": [5]u8 = undefined;`
<pixelherodev>
pft
<pixelherodev>
That got a chuckle
frett27 has joined #zig
<nmeum>
I would like to provide my own panic function, the documentation for @panic says that the default is located in `std/special/panic.zig` but either I am blind or that file doesn't exist
<pixelherodev>
It doesn't anymore
<pixelherodev>
apparently
<pixelherodev>
Ah
<pixelherodev>
nmeum, it's in std/builtin.zig
<pixelherodev>
std.builtin.default_panic
<nmeum>
ah!
<nmeum>
should I send a pull request updating the documentation?
<pixelherodev>
If you want to
<nmeum>
will create one to prevent other people from running into this :)
<daurnimator>
nmeum: and FYI you provide it in your root file; or in your BYO-os
<nmeum>
yep, that's correctly stated in the @panic documentation then
<nmeum>
one more question regarding panic handlers: how can I convert an error to a []const u8 so I can output it through my panic handler?
<pixelherodev>
You don't
<nmeum>
what would I do instead?
<pixelherodev>
If an error is cause for a panic, you'd do e.g. `catch @panic("Panic message!!!");`
<daurnimator>
nmeum: huh? panic handlers have the signature `fn (msg: []const u8, error_return_trace: ?*StackTrace) noreturn`
<pixelherodev>
A panic means "print this fatal message and die"
<nmeum>
ah ok
<nmeum>
so I would output the error separatly
<nmeum>
that works as well
<pixelherodev>
std.debug.warn("Error occurred!");
<pixelherodev>
That will print to stderr and let you keep going
<nmeum>
can't use std.debug.warn because I am using zig on a freestandig target
<pixelherodev>
It is impossible to recover from a panic.
<pixelherodev>
Ahh
<pixelherodev>
Then it depends on the target
<pixelherodev>
What forms of I/O do you have?
<daurnimator>
nmeum: hook up std.debug.warn to go to something sensible for your target
<pixelherodev>
^ that's the correct option, yes
<daurnimator>
(I'm not 100% sure you can)
<pixelherodev>
I am
<pixelherodev>
I've done it
<nmeum>
I have implemented support for a UART, the uart has a function which allows me to output an array of bytes
<pixelherodev>
So you'll want to just output to the UART
<nmeum>
yes
<nmeum>
that's what I do in my custom panic handler currently
<pixelherodev>
Once you know that works, I can help you hook that up to a virtual /dev/stderr if you want?
<pixelherodev>
What I did was return hard-coded numbers for /dev/stderr, /dev/stdout, etc
<nmeum>
but my target doesn't have a file descriptor concept yet ':)
<pixelherodev>
daurnimator, yes I know
<pixelherodev>
I did it cleanly
<pixelherodev>
Sorta
<pixelherodev>
Not really
<pixelherodev>
I cheated again
<pixelherodev>
Had it return a constant value from errno IIRC
<pixelherodev>
nmeum, doesn't need one
<pixelherodev>
I sure as heckdidn't have one
<daurnimator>
I think nmeum should wait for #4166 and #4167 before implementing my recommendation
<pixelherodev>
Probably, yes
<pixelherodev>
But it's definitely doable now
<daurnimator>
nmeum: in the mean time; yes call out to your own outstream in your panic handler
<nmeum>
yes, that's what I am intending to do anyhow for now
<pixelherodev>
The initial option I did was to not even bother checking the fd in write
<nmeum>
I haven't really looked into the zig standard library at all yet
<pixelherodev>
I made all writes regardless of FD go to the terminal
<nmeum>
just started playing around with zig yesterday
<pixelherodev>
daurnimator, the biggest cheat I had was that this was pre-BYOS layer
<pixelherodev>
I forked the stdlib
<pixelherodev>
Fixed a bug or two in stack trace handling (by completely nuking anything I didn't need so it couldn't possibly crash)
<nmeum>
if you don't mind me asking: what exactly is the "BYO OS" layer?
<pixelherodev>
Bring Your Own OS layer
<pixelherodev>
It lets you implement a custom system API
<nmeum>
ah
<pixelherodev>
Basically, instead of using e.g. POSIX or Windows syscalls, it uses arbitrary functions you define
<nmeum>
so basically that allows using the standard library on a custom OS?
<pixelherodev>
Yeah
<pixelherodev>
It glues together the standard library with your API
<nmeum>
great, that might be useful for my purpose
<nmeum>
can I read up on that somewhere?
<pixelherodev>
Like I said, I had a custom `write` function (which normally maps to syscalls) which just dumped it's arg to term
<pixelherodev>
Docs are sparse probably
<nmeum>
hehe
<pixelherodev>
AFAIK I'm one of maybe *maybe* two people who've ever actually used it (including daurnimator)
<daurnimator>
nmeum: I think without #4166 fixed its pretty unusable unless your custom OS implements POSIX
<nmeum>
nope, it's targeting a hifive1 I don't think it will ever implemented posix ;)
<pixelherodev>
I respectfully disagree :P
<pixelherodev>
That you need 4166 fixed
<foobles>
if I am generating an `IrInstrGen` from a binary operator, should I special case when the lhs and rhs are comptime known? Or will that be resolved somewhat automatically?
<pixelherodev>
Ah wait
<nmeum>
anyway, thanks for the information so far. I need to do some work on driver code anyhow before I can interact with this "byo os" layer at all, so I will do just that in the meantime :)
<pixelherodev>
Never mind, I kinda agree
<pixelherodev>
Mixed up 4166 and 67
<pixelherodev>
good luck!
<nmeum>
thanks
ur5us has joined #zig
<nmeum>
it's a toy project for experimenting with zig so it doesn't need to go anywhere really :)
<nmeum>
but so far really like how pleasant bare metal development is with zig
<pixelherodev>
Same
<pixelherodev>
It's what got me into Zig in the first place
<pixelherodev>
Bare metal is one spot I honestly think Zig has C beat
<pixelherodev>
As in *already*
<foobles>
alright who is named "so" :@
<foobles>
but yeah, zig seems already really great
<pixelherodev>
?
<pixelherodev>
"so"?
<foobles>
if you say so it highlights
<pixelherodev>
... whoops.
<pixelherodev>
I think we just pinged someone like 20 times.
<pixelherodev>
Oh wait, that
<daurnimator>
so what ;)
<pixelherodev>
I was thinking of "stat"
<ikskuh>
<pixelherodev> Bare metal is one spot I honestly think Zig has C beat
<ikskuh>
true dat
<pixelherodev>
For regular tasks, I'd honestly say it's better to stick with C for now until Zig stabiliszes
<pixelherodev>
But for bare metaLL?
<pixelherodev>
s/LL/l
<pixelherodev>
Zig wins hands down.
<foobles>
s/LL/I?
<pixelherodev>
s/TEXTTOREPLACE/TEXTTOINSERT
<pixelherodev>
"edit"ing the above line
<pixelherodev>
s/bare metaLL/bare metal
<daurnimator>
nmeum: well please do share your project/progress; and give feedback
<pixelherodev>
(that's a lowercase l, not uppercase I)
<pixelherodev>
Seconded!
<pixelherodev>
:)
<daurnimator>
nmeum: oh, and, um, prepare for frequent breakages as zig stabilises
<nmeum>
daurnimator: it's on github https://github.com/nmeum/zig-riscv-embedded but as I said: it doesn't really do much yet just some interrupt handling and preliminary support for the hifive1 uart peripheral
<nmeum>
I am used to things frequently breaking :)
<nmeum>
as I said: I just want to experiment with the language a bit
<nmeum>
will look into it, thanks!
<daurnimator>
nmeum: misc notes as I look through your code: `const off: u5 = @intCast(u5, irq % 32);` => this could be `const off = @truncate(u5, irq)`
<daurnimator>
`_: u15 = 0, // reserved` => is the 0 actually checked for? if not, use `undefined` instead
<pixelherodev>
The ability to do the full thing in Zig is alwso nice
<pixelherodev>
s/alwso/also
<pixelherodev>
No need to jump in from asm
<nmeum>
oohhhh
<nmeum>
that's nice
<daurnimator>
`set_threshold` => convention is to use camelCase for function names in zig
<nmeum>
oops, occasionally mixed up the convention for variable and function names
<pixelherodev>
... we should really add that to `zig fmt`
<nmeum>
that would be great
<pixelherodev>
I keep forgetting and it'd be nice not to have to do it manually
<daurnimator>
pixelherodev: zig fmt never changes meaning of code
<ikskuh>
having a guideline linter would be cool though
<daurnimator>
it is essentially limited to only whitespace changes
<ikskuh>
"zig lint" :D
<ikskuh>
"this should be camelCase" "this should be snake_case"
<daurnimator>
ikskuh: too many exceptions though, e.g. snake_case is recommended when copying well-known existing APIs
<ikskuh>
yeah, true again
<daurnimator>
nmeum: `const UART_REG_TXFIFO: u32 = 0x00;` I think this should be `usize` not `u32`?
<nmeum>
there are a bunch of data types I probably need to change just went with u32 everywhere in the beginning ':)
<daurnimator>
nmeum: you should use namespacing more too: you're already in the `uart` file, so I'd put: pub const Reg = struct { pub const TXFIFO: usize = 0x00; ..... };`
<nmeum>
my original intention was to keep the address constants "private", as in: not make them part of the public api
<nmeum>
not sure if I succeded at that, didn't manage to read up much on the Zig namespacing concept yet
<daurnimator>
nmeum: why keep them private?
<pixelherodev>
I'd counter with, why make them public?
<nmeum>
idk, intuitively my intention was to provide functions for accessing memory mapped uart registers and only interact with those through the functions and only use memory mapped io (i.e. those address constants) in those functions
<pixelherodev>
IMHO the only things that should be public are those that absolutely need to be (are part of the intented API)
<daurnimator>
pixelherodev: IMO make everything public unless it gives people too much leeway to shoot themselves in the foot
<daurnimator>
for something like specifying the memmap layout.... that can end up useful for someone debugging or working around something else
<pixelherodev>
That's definitely a good point
<pixelherodev>
I'd think the goal should be that correct usage feels natural and incorrect usage feels weird
<pixelherodev>
All else should extend from that
<daurnimator>
not really....
* pixelherodev
shrugs
<daurnimator>
at the forefront of your mind should be putting the user of your library/application in control. so that they don't have to hack around your thing or come begging to expose something that wasn't before
<nmeum>
daurnimator: just slowly reading up on all of your recommendations. just wondering what is the advantage of a @truncate over an @intCast?
<daurnimator>
nmeum: @truncate does the modulo for you
<nmeum>
ah!
<pixelherodev>
daurnimator, yeah thinking about it further I agree with you
<pixelherodev>
In my defense, I've been awake for an unholy amount of time
<pixelherodev>
That's a good line :)
<Snektron>
Happy easter, btw
ur5us has quit [Ping timeout: 260 seconds]
<foobles>
when composing `IrInst`objects, is it ok for several different instructions to have aliasing pointers to the same instruction?
<nmeum>
daurnimator: regarding address constants: doesn't it make more sense to use `const PLIC_CTRL_ADDR = 0x0C000000` (i.e. comptime_int?) instead of const `const PLIC_CTRL_ADDR: usize = 0x0C000000`?
<foobles>
like could I have an `IrInstGenBinOp` where op1 and op2 point to the same thing
<daurnimator>
nmeum: if they're relative addresses then `usize` makes sense. if they're absolute then use `@intToPtr(*T, 0x12345678)`
<nmeum>
alright, thanks
daex has quit [Ping timeout: 265 seconds]
daex has joined #zig
<foobles>
how should i go about adding tests for compiler behavior? I am extending the 2nd pass, but i only see 2 functions tested in tests/stage2/compare_output.zig
<mikdusan>
tests/stage1/
<foobles>
even though I am doing the 2nd compiler pass? Or does stage2 mean something else
<mikdusan>
yes, stage2 != pass2
<foobles>
ahhhh ok i see
<foobles>
thank you
<mikdusan>
stage2 means "implemented in .zig" instead of ".cpp"
<mikdusan>
typically you'll end up dealing with 2 different kinds of tests; one that does not compiler-error, and one that does
<mikdusan>
so if you want to test for compiler errors, that's test/compile_errors.zig, otherwise test/stage1/behavior.zig
<mikdusan>
test/compile_errrors runs via `zig build test-compile-errors` and you have -Dtest-filter="match_these_chars" to speed things up during iterative dev
<mikdusan>
behavior tests can be run through `zig build test-behavior` or directly `zig test test/stage1/behavior.zig` and you have --test-filter "match_these_chars"
<mikdusan>
another trick is tests run interactively don't output in batch mode. the only way I know to do that, is pipe stdout+stderr (both) to cat to force non-tty mode
<mikdusan>
so if 10 tests are run, and you want to make sure filter is correct: `zig build test-compile_errors -Dtest-filter="yeehaw" |& cat` to show 1-line-per-test
FireFox317 has joined #zig
<ifreund>
so for my `protocol_dirs_path` array here https://paste.rs/bMf i get an "error: expected type '[][]const u8', found '*const [2][]const u8'" on the last element
<ifreund>
i'm having trouble understanding why though, or how to fix it
<Cadey>
has anyone gotten zig compiling 3ds binaries?
<foobles>
like nintendo 3ds?
<foobles>
also: when should you use UndefOk vs UndefBad when resolving comptime values?
jjido has joined #zig
<foobles>
oh, it means undefined values, not undefined behavior, is that right?
<Cadey>
foobles: yeah
<foobles>
so what is LazyOkNoUndef/LazyOk? i can guess that UndefOk/UndefBad mean that it will be an error or not based on if it evalues to something undefined
<Cadey>
oh i mean yeah the nintendo 3ds
<foobles>
oh oh oops '=D sorry i havent heard anything
<mikdusan>
foobles: maybe ir_num_lit_fits_in_other_type sheds some light; a fn that checks if a number lit fits in another type... and fn says number literal is LazyOkNoUndef meaning lazy is ok, but it cannot be a value of `undefined`
<foobles>
hmm ok
<foobles>
thanks
<mikdusan>
so an example would be... `[:0]u8` -- the sentinel cannot be specified as `[:undefined]u8`
<foobles>
ah alright. what does Lazy mean in this context?
<daurnimator>
foobles: things in zig don't exist until you use them
<daurnimator>
foobles: `pub const foo = @compileError("foo!");` => you don't get a compile error under you use `foo`
<daurnimator>
s/under/until/
<foobles>
alright, thanks
<foobles>
that makes sense
<foobles>
so does LazyOk imply undefBad then?
<mikdusan>
that's my understanding. if you said resolve(UndefBad) and later said... same deal but make allow lazy, resolve(LazyOkNoUndef)
<foobles>
interesting: at comptime, comparing a C-pointer with null will just propagate undefined values upwards, while comparing any optional T directly with null, will cause an error immediately
<foobles>
does this make sense?
<foobles>
I dont understand why this is :v
<FireFox317>
foobles, you really need andrewrk for this type of work i think, but he's busy with releasing 0.6.0 ^^ probably in a week or so, he will have a bit more time xd
<foobles>
X) gaah ok
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
<FireFox317>
foobles, maybe someone knows the answer, so asking the question is always better than not, but still andrewrk would be able to answer it in a minute if he wasnt busy with releasing zig 0.6.0
<pixelherodev>
foobles, I think that's because C pointers *can* be null
<pixelherodev>
What's the behavior of `allownull` Zig pointers?
<foobles>
this is for undefined, not null
<foobles>
pixelherodev
<foobles>
although maybe that's related?
<pixelherodev>
You said `comparing a C-pointer with null` gives undefined
<mikdusan>
it's comptime yes, but a C-pointer is raw, and there aren't any bits for zig to play with. so how would a compare know if it's undefed, or suppoed to be 0xaaaaaaaa
<mikdusan>
interfacing with C limits zig
<foobles>
pixelherodev what i said was that if the pointer itself is undefined, that is just propagated upwards. comparing it with null will do a proper check
<pixelherodev>
Ahh
<foobles>
mikdusan hmmm. but the ZigValue object isn't determined to be undefined or not based on the 0xaaaaaaa thing at compile time. it just has a member specifying if it is known to be undefined or not
<mikdusan>
how would comptime knowledge of a [*c]u8 = undefined ... be used with C? [*c] is bad and only used in auto-gen cimport.zig right?
<mikdusan>
so maybe it's not a matter of can Zig track it at comptime, it's more... why should it? this is a [*c]
<foobles>
but it is still tracked... just not immediately turned into an error when comparing with null
<mikdusan>
it could simply be a missing comptime feature then
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<pixelherodev>
^
<daurnimator>
:( Stat/Mode is much more of a mess than I expected
<daurnimator>
I'm like 600 lines of diff down this rabbit hole now
jjido has joined #zig
Xavi92 has joined #zig
xackus_ has quit [Remote host closed the connection]
xackus_ has joined #zig
xackus__ has joined #zig
xackus_ has quit [Ping timeout: 250 seconds]
<Xavi92>
https://bpaste.net/NJUA -> I'm testing this minimal example namely 'main.zig' on '-target mipsel-freestanding-gnueabi -mcpu mips1+soft_float" and, whereas 'mipsel-unknown-elf-objdump main.o -S' returns this (https://bpaste.net/PLJA), 'mipsel-unknown-elf-objdump main' returns no code. Does anyone know why is it being optimized away at linking time?
xackus_ has joined #zig
xackus__ has quit [Ping timeout: 265 seconds]
TheLemonMan has joined #zig
<nmeum>
Could someone explain this compile error, regarding packed structs, to me: https://tpaste.us/lYdY last time I checked 8 bit + 23 bit + 1 bit was 32 bit = 4 byte so the packed struct txdata should have the same size as the u32 shouldn't it?
<nmeum>
but somehow the compiler is of the opinion that this packed struct has a size of 5 byte
<fengb>
Packed structs have some bad bugs
<nmeum>
ah
<fengb>
You might get away with splitting up the u23 manually so the bytes don’t cross over
<nmeum>
should I report this as a bug or is this generally known to be an issue?
<fengb>
u16 + u7
<pixelherodev>
It's known
<fengb>
There’s a few issues on it
<nmeum>
ok, good
<nmeum>
if I split the u23 I end up with a unreachable-error in the compiler itself. I guess I will just use bitshifts then
darithorn has joined #zig
dimenus|home is now known as dimenus
<dimenus>
anrewrk: is the plan to eventually cache c artifacts created in zig build?
<dimenus>
*andrewrk
<foobles>
did you mean andrewk?
<foobles>
wait
<foobles>
nvm, sorry
<nmeum>
has anybody written a git commit hook for zig fmt yet that checks if any files are not properly formatted before comitting them?
<pixelherodev>
I haven't needed it; I set my text editor to autoformat on write
<darithorn>
yeah, most of the zig editor plugins are preset to format on save.
FireFox317 has quit [Ping timeout: 256 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FireFox317 has joined #zig
jjido has joined #zig
<dimenus>
when did zig start building its own c++ objects?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Xavi92>
Does anyone know the reason for the issue I posted above?
<TheLemonMan>
what issue?
<pixelherodev>
Xavi92, did you define an entry point?
<pixelherodev>
If you're targeting freestanding, you need to provide `start`, not `main`
<pixelherodev>
(or provide a custom linker script)
<Xavi92>
pixelherodev: sorry, I'm just insisting on the issue we discussed yesterday. See https://bpaste.net/NJUA
<Xavi92>
'mipsel-unknown-elf-objdump -S main.o' returns https://bpaste.net/PLJA , but 'mipsel-unknown-elf-objdump -S main' returns, as if everything was optimized away
<TheLemonMan>
Xavi92, change _start into __start
<Xavi92>
TheLemonMan: right, that's a huge step. Now zig returns 'lld: error: undefined symbol: __bss_end', yet if I rename __bss_end to something else (_bss_end for example), then it does not even compile
<TheLemonMan>
afair lld only export __bss_start
<Xavi92>
So I need to provide a custom linker script?
<Xavi92>
BaroqueLarouche: wow, that is really inspiring :)
wootehfoot has joined #zig
<asie>
oh, cool
<asie>
it's interesting; I'm evaluating Zig as the basis for candyk, a modern homebrew toolkit for odd platforms I was developing
<asie>
the main issue with this usecase is that LLVM doesn't have many of those odd platforms, and writing LLVM backends isn't exactly easy
<BaroqueLarouche>
Asie: Do you a git for this project?
<asie>
only for the current GCC/C-based variant, and it's mostly a lot of rough code for the PS1 and some pacman packages
jjido has joined #zig
cole-h has joined #zig
cole-h has quit [Client Quit]
cole-h has joined #zig
salotz has joined #zig
grayhatter has quit [Quit: ZNC 1.6.2 - http://znc.in]
grayhatter has joined #zig
grayhatter has quit [Client Quit]
grayhatter has joined #zig
opidopiopi has joined #zig
<opidopiopi>
Hi, I'm trying to build https://github.com/andrewrk/clashproto with the latest version and get the following error: .\src\main.zig:254:36: error: expected type '[]Block', found '*const [3]Block' any ideas ?
oats is now known as hugs
<foobles>
opidopiopi maybe try changing it to `[]const Block`?
jorge-jbs has joined #zig
<opidopiopi>
then I get the next error: .\src\main.zig:256:29: error: cannot assign to constant. if I use all_blocks: = [3]Block, it works fine ?
Xavi92 has quit [Remote host closed the connection]
<Sphax>
right now getAutoEqlFn returns a function that compares the pointer so it's never equal
moo has quit [Ping timeout: 265 seconds]
<mikdusan>
Sphax: roll your own equal fn for map: `fn eqlKey(a: Key, b: Key) bool { return std.mem.eql(u8, a.name, b.name); }`
<Snektron>
theres also std.BufHashMap i think
<Snektron>
no wait, std.StringHashMap
<Sphax>
yeah that's what I did, was just wondering if it's intended.
<Snektron>
it is
<mikdusan>
if Key is really your db record, then you need to roll your own. if key is simpls a string []const u8, then convenience StringHashMap can be used
<mikdusan>
s/simpls/simply/
<Sphax>
Ok. I was thinking that since getAutoHashStartFn with .Deep does the right thing in this case maybe there could be an equivalent for getAutoEqlFn but maybe it doesn't make sense
<mikdusan>
autohash .deep can kind of generically visit the struct fields. but for equal, how does it know which fields, which compare function, which logic
<Sphax>
hm. right
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<foobles>
in the 2nd pass of the compiler, I need to generate a bin op instruction, but also analyze it. Because I need the analysis to be done, i dont think I can just do `ir_build_bin_op_gen`, since that will never fail and does no type checking. However, if I try to just use `ir_build_bin_op`, the op1 and op2 paramaters have to be IrInstSrc objects, not
<foobles>
IrInstGen objects
<foobles>
but I only have IrInstGens
<foobles>
is there a way to go back?
<foobles>
also, what does "safety_check_on" do?
layneson has joined #zig
<TheLemonMan>
no, you can't go back
<TheLemonMan>
safety_check_on is a flag that allows you to insert as many safety checks you want during the codegen
<foobles>
hmm ok
<foobles>
so do you have any suggestion for what to do here?
<foobles>
what i am trying to do more generally, is to generate comparison between optionals where their child types are comparable
<foobles>
so I want to check: are both null? return ir_const_bool(...)
darithorn_ has joined #zig
Akuli has quit [Quit: Leaving]
<foobles>
do they both have a value? if so, generate a comparison of their child values, and recurse with `ir_analyze_bin_op_cmp` on that
<foobles>
else ir_const_bool(<not equal>)
<TheLemonMan>
well the only suggestion I have for you is to do all this work in ir_analyze_bin_op_cmp
<foobles>
also, this is all at comptime, i have much less of an idea how to do this check at runtime
<foobles>
that is where i am working
<foobles>
im looking at the other possible code paths
<foobles>
but none of them generate anything more than const bools or things like that. no recursive comparison analysis or anything like that
darithorn has quit [Ping timeout: 260 seconds]
<TheLemonMan>
yeah you're fist-deep into spaghetti, forget about recursively lowering the comparisons
<TheLemonMan>
if you get the LHS/RHS as InstGen you can easily unwrap them
<TheLemonMan>
and eventually call ir_analyze_bin_op_cmp_numeric
<TheLemonMan>
but if the inner types are not numeric there's nothing more you can do :)
<foobles>
I do have them as InstGen
<foobles>
so there is no way to analyze an InstGen?
frett27_ has joined #zig
<TheLemonMan>
they are already analyzed
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
emekoi has quit [Remote host closed the connection]
<foobles>
:'( but there is no way it seems, to generate InstSrc instructions from InstGens D:
<foobles>
oh wowah this is going to take more work than i expected
<mikdusan>
andrewrk: just fyi, Async I/O section, {#code_begin|syntax#} errors on macos; I'll switch to linux to workaround, just giving you heads up
<foobles>
oh wait I DO HAVE `InstSrc` I just forgot!
<foobles>
yes!!!
<foobles>
:D
<foobles>
oh no turns out I dont xd
marijnfs has joined #zig
<andrewrk>
mikdusan, ah thanks
<andrewrk>
yeah I think it's ok to show off the stuff that only works on linux, there's the caveat of needing to add the "glue" code there for other OS's
<andrewrk>
but it's annoying for you when trying to help with release notes, sorry bout that
<andrewrk>
did you read the async i/o section? I think it came out pretty nice
<mikdusan>
hmm.. write_file_evented and concurrent hang waiting on archlinux for me.
<andrewrk>
hmmmm
<mikdusan>
i even pullled out the write_file_Evented it's standalone file same deal
<mikdusan>
latest zig, latest archlinux
<andrewrk>
well that's good to know because it seems you found a bug in the event loop implementation
<mikdusan>
:(
<andrewrk>
this is fine, it doesn't endanger the release. it's already noted that this part is still experimental
<andrewrk>
but yeah it's annoying for writing release notes
<andrewrk>
feel free to comment out the code block with a "TODO" and we'll enable it just before posting
FireFox317 has quit [Ping timeout: 256 seconds]
<Sphax>
I don't understand this error https://gcc.godbolt.org/z/jDpe_J I tried poking around in fixed_buffer_stream but I don't get how the buffer is []const u8 at this point
<foobles>
wait, unrelated, are you the Sphax from minecraft?
<Sphax>
ah, nope
ur5us has quit [Ping timeout: 260 seconds]
<mikdusan>
Sphax: can you open a PR for that one?
<mikdusan>
err... s/PR/issue/
<Sphax>
sure
ifreund has quit [Ping timeout: 265 seconds]
dermetfan has quit [Ping timeout: 260 seconds]
<Xavi92>
Does anyone know Zig string handling examples?
<Xavi92>
No heap allocation preferred
<pixelherodev>
What sort of string handling?
<Xavi92>
Very basic stuff e.g.: something itoa-like
<pixelherodev>
Which is the same as error.NoSpaceLeft ! []u8
<pixelherodev>
Where that error means the buffer is too small for the data you're giving it
<pixelherodev>
So e.g. `var a: [4]u8 = undefined; const formatted = std.fmt.bufPrint(&a, "{}", 3948493) catch @panic("Need to increase the size of buffer a!");`
<pixelherodev>
Then, if buffer big enough (not in that example), `formatted` will contain the number you pass it as a string
<pixelherodev>
s/if/if the
<pixelherodev>
s/big/is big
<pixelherodev>
Gah, sorry; barely awake
<pixelherodev>
Piece of advice: the standard library is simple, and you have it installed locally ;)
<Xavi92>
pixelherodev: thanks a lot for your help
<pixelherodev>
No problem
<Xavi92>
Is it trivial to perform conversions between []u8 and [*:0]u8?
<pixelherodev>
.ptr
<pixelherodev>
Well
<pixelherodev>
If it's null-terminated, it should be a `[:0]u8`
<pixelherodev>
`that.ptr` gives a [*:0]u8
<Snektron>
You need to guarantee the :0 part
<pixelherodev>
^
<Xavi92>
Does std.fmt.bufPrint guarantee it?
<pixelherodev>
I think so?
<fengb>
Nope
<pixelherodev>
Ah wait, there's a bufPrintZ or something?
<fengb>
Oh maybe
<pixelherodev>
Doesn't seem to guarantee it
<pixelherodev>
Just do a \00 at the end of the format string?
<frett27_>
Does anyone has a smooth path to compile a program on rpi ? i setup a program to monitor iot devices (mqtt), https://github.com/frett27/iotmonitor
<frett27_>
on x64 and i want tocompile it on rpi
<frett27_>
cross compile seems painfull , there are a couple of dependencies
<frett27_>
compiling llvm10 , on rpi .....
<frett27_>
any ideas ?
<afontain_>
can't you use -target?
<frett27_>
i tried, but i had to get all the rpi dependencies for link
<frett27_>
quite painfull,, because i linked the mqtt client library also
<frett27_>
statically
<frett27_>
so i have to compile it also
<fengb>
There will be a binary for v0.6.0 that runs on the rpi
<fengb>
Comes out tomorrow
<frett27_>
YOOOO !!!
<frett27_>
awesome :-)
<foobles>
does anyone know the best way, given a ZigValue*:
<frett27_>
how do you compile zig on pi ?
<afontain_>
`while sleep 10; do apk upgrade -U; done`
<frett27_>
fengb, for zig binary, you recompile also llvm10 ?
<foobles>
given a ZigValue*: to create an IrInstGen containing that value, and then create an IrInstSrc with it's child pointer refering to the InstGen?
<frett27_>
afonain, :-)
<fengb>
Well I didn’t compile it no. The binary was created with the bootstrap script that does cross compile
<Xavi92>
pixelherodev, fengb: works like a charm. Thanks again!