<fengb>
I guess it’s easy to do a naive implementation
<fengb>
Hmm I should pay attention to the proposals
<andrewrk>
damn I can't run the target.zig unit tests because the compiler depends on them
<andrewrk>
well I'll know if the code is working, once the code is working ( ͡° ͜ʖ ͡°)
<fengb>
Neat features, multi return obviates my silly “jam everything into f64” hack
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
Heh, my lexer's now so fast that I could genuinely make it faster by removing the usage of InStream.readUntilDelimiter and doing a manual scan + memcpy :P
<shakesoda>
multireturn? where
<pixelherodev>
4 ms, and I might actually be able to reduce that to 1ms if I'm willing to take a few hours to optimize (I'm not)
<shakesoda>
multireturn is one of the things i miss deeply when writing everything but lua
<pixelherodev>
I feel like multireturn could exist in Zig as syntax sugar over returning a structure... but it'd make the language more complex and probably not be worth it
<fengb>
Returning tuples will be a thing so we kinda have multi returns
<pixelherodev>
That's an accepted proposal? Neat
<pixelherodev>
make that 3 milliseconds :D
<pixelherodev>
... 2500 microseconds, rather
<pixelherodev>
That was just by stripping out libc :)
<pixelherodev>
It's nice that zig's startup time is (relatively speaking) much faster than C's too
<fengb>
Progress: my wasm bytecode doesn’t crash! I guess should actually verify it works too
ur5us has joined #zig
<andrewrk>
nice
<pixelherodev>
... okay, so after my latest change, everything works fine in debug mode, but in release-fast it behaves differently :(
<pixelherodev>
(misparses a string?)
<pixelherodev>
The worst part is that it's impossible to debug
<pixelherodev>
values are all optimized out
<pixelherodev>
Whelp, time to just do more structural changes and hope that fixes it :P
<fengb>
Does it work in release-safe?
<pixelherodev>
Good point
<daurnimator>
pixelherodev: I had a similar issue with my copy of bss. had to use inline assembly so it wouldn't be optimized
<pixelherodev>
?
<pixelherodev>
fengb, yeah
<daurnimator>
pixelherodev: uh, for certain environments, you have to set up your sections. global variables need to be initialised from their initial values in their readonly section. and you need to zero-initialise bss
<daurnimator>
the issue was that `memset` got optimized to the compiler builtin... which internally used bss... which wasn't initialised yet...
<daurnimator>
you break the loop by writing memset and memcpy by hand without any state.
<pixelherodev>
But in release-small it now outperforms the previous release-fast :P
<pixelherodev>
(by like 300 microseconds, but given the scale this runs on that's actually a lot)
nepugia has quit [Ping timeout: 248 seconds]
<pixelherodev>
Hmm, ArrayList.ensureCapacity zero-initializes the new memory?
<daurnimator>
it shouldn't....
<daurnimator>
it uses .realloc. which in non-release-fast modes will initialise to `undefined` (i.e. 0xaa). and in release-fast it will be.... whatever was there before (which for a fresh anonymous mmap, should be 0)
<fengb>
Pretty sure release-small also doesn’t memset or have any safety features
<pixelherodev>
... huh, that's odd
<pixelherodev>
Found it
<pixelherodev>
There's a @memset in *all* modes in realloc
<pixelherodev>
to undefined
<fengb>
Which should be a noop in safe or fast
<fengb>
Er... small or fast
<pixelherodev>
It's not
<daurnimator>
it should be...
<daurnimator>
what are you seeing instead?
<fengb>
Look at the assembly output. Any assignment to undefined should be optimized out in non-safe
<pixelherodev>
Double checked, and it's not.
<pixelherodev>
According to callgrind, ~1/6th of execution time is a memset call *from ensureCapacity*
<pixelherodev>
Which I'm 99% sure is inlined std.mem.Allocator.realloc
<pixelherodev>
Tjere
<pixelherodev>
there's only two function calls in ensureCapacity: self.capacity(), which just retrieves current capacity, and realloc
<daurnimator>
pixelherodev: which allocator are you using?
<pixelherodev>
PageAllocator IIRC
<pixelherodev>
Yeah
<pixelherodev>
But it shouldn't be allocator specific, the memset is in the Allocator interface's realloc function
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
pixelherodev: could you try and show off that memset in e.g. godbolt?
<pixelherodev>
Probably note, but that's because I can't possibly read the optimized asm
<pixelherodev>
s/note/not
<daurnimator>
godbolt is good at helping you see what compiles to what
<pixelherodev>
not in release-fast/release-small
<pixelherodev>
Try a simple example of ArrayList.ensureCapacity and let me know how it goes ;)
<pixelherodev>
(I know, because I tried)
casaca has quit [Quit: leaving]
casaca has joined #zig
mahmudov has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev>
Figured out why it wasn't working in release fast mode: there was a latent bug in the lexer that went unnoticed before the refactor, which ended up becoming a problem in other modes upon further changes. Fixing that fixed release-fast mode :)
<pixelherodev>
1.2 milliseconds :D
<pixelherodev>
(If I set up a bash loop to run it a thousand times, average execution time goes down even further, but that's just abusing the branch predictor to get a meaningless speed improvement)
<pixelherodev>
s/bash/shell
<pixelherodev>
Interestingly though, that performance improvement doesn't exist on the much larger IR of the lexer itself - or rather, it does, but it doesn't scale to file size :P
<shakesoda>
does zig build know about things like vcpkg or do i need to convince it to know
<daurnimator>
shakesoda: it does.
<shakesoda>
daurnimator: any magical incantation for it?
<shakesoda>
looks like i just had to manually add the paths for it and things are alright
<andrewrk>
shakesoda, yes, zig build knows about vcpkg and pkg-config
<andrewrk>
I think you do artifact.addVcpkgPaths()
<mq32>
i'd say for "extern functions" it *should* be possible
<mq32>
but i would not rely on that
<shakesoda>
argh! luajit doesn't let you do a custom allocator on 64 bit
<shakesoda>
i wonder if this was fixed in 2.1 or moonjit
<shakesoda>
looks like not
<shakesoda>
guess i'll just have to note this one as a quirk
Akuli has joined #zig
<shakesoda>
lua_tostring and stuff fail to translate
<shakesoda>
i think it's the same as one of the issues already posted, though
* shakesoda
checks
<shakesoda>
yeah, it's #4328
daex has quit [Ping timeout: 268 seconds]
daex has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
decentpenguin has joined #zig
frmdstryr has quit [Read error: Connection reset by peer]
forgot-password has joined #zig
<forgot-password>
Is it possible to pass zig var args to a c function with var args?
<Snektron>
Do you mean a struct literal or old-style varargs
<forgot-password>
a struct literal
<forgot-password>
The objc_msgSend function definition looks like this in C: id objc_msgSend(id self, SEL op, ...), but I want to write a few wrappers to make it more comfortable to use with Zig
<fengb>
Umm... there's a really bad kludge you could use
<andrewrk>
I'm hoping it can be fixed with some kind of interface language feature, but I have no concrete plan for that yet
<Snektron>
Huh? Fixing error sets with interfaces?
<companion_cube>
polymorphism + effects is hard 🤷
<andrewrk>
Snektron, yes one of the design goals of interfaces for me would be to interact with error sets in a way that lets them compose as you would expect them to
<andrewrk>
e.g. maybe an interface itself supports error set inference, something like that
<Snektron>
But what does that have to do with that issue?
wilsonk has quit [Ping timeout: 240 seconds]
<andrewrk>
well the issue is that you're basically forced to accept `stream: var` rather than `stream: *Stream` and it's mainly because of the error set
<companion_cube>
cause you'd need `stream: *Stream(E)` for an inferred E?
_Vi has quit [Ping timeout: 248 seconds]
<Snektron>
But that just seems a problem with comptime parameterizatiom rather than that specific error of not being able to figure out an error set at compile time if a function doesn't return one
<andrewrk>
yeah
<andrewrk>
oh I think I linked to a different issue than I meant to
return0e has quit [Remote host closed the connection]
<betawaffle>
has anyone taken the name "zag" for a library yet?
<fengb>
Absolutely everybody lol
<gchristensen>
do it anyway betawaffle
<andrewrk>
it's a rite of passage
<andrewrk>
the holy grail is if you can make a simple video game clone using only zig packages named "zag" that all do different things
<andrewrk>
I'm pretty sure pixelherodev does `const zag = @import("std");`
<shakesoda>
andrewrk: in the future, also while running the thing everyone expected most: zagOS
<Snektron>
If it doesn't have window 3.1's ZIGZAG you've failed
<andrewrk>
which one is considered more "default"? ARMv8mBaseline or ARMv8mMainline ?
<andrewrk>
e.g. should it be generic+v8m => ARMv8mBaseline, or generic+v8m_base => ARMv8mBaseline
<shakesoda>
andrewrk: looks like mainline is more common
<shakesoda>
according to the ever handy arm cortex m wikipedia page
casaca has quit [Quit: leaving]
<shakesoda>
unless there just happen to be a lot more M23's than M33 and M35P (maybe?)
casaca has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
doublex_ has joined #zig
<pixelherodev>
... I refer to it as Zag, but I've typically imported as std. *Until Now.*
<pixelherodev>
On the other hand, thanks for giving me a better name for my kernel shakesoda
doublex__ has quit [Ping timeout: 240 seconds]
<pixelherodev>
ZagOS has a much better ring to it, and is more accurate anyways
<fengb>
Is this in competition with vOS? 🙃
_Vi has joined #zig
<pixelherodev>
Okay, did a quick `find -exec sed`; now everything's ZigZaggy
mahmudov has joined #zig
<fengb>
Can someone suggest a less stupid name for my wasm interpreter? :)
<araspik>
fengb: 999
<fengb>
Less stupid 🙃
SimonN has quit [Remote host closed the connection]
<fengb>
I like how "Azigly" sounds but the spelling is terrible
<pixelherodev>
WASMade
<fengb>
A-zig-bee
<pixelherodev>
ZWASM
<pixelherodev>
zeh-wah-zem
<companion_cube>
WebZassembly
<pixelherodev>
Has a nice ring
<pixelherodev>
WeebASM
<pixelherodev>
WeebsAssemble
<fengb>
wazm
<companion_cube>
I like that one!
<pixelherodev>
That's actually a good oen
<pixelherodev>
one
<fengb>
What really? I tossed that out almost immediately >_>
<araspik>
yeah it's not bad
<fengb>
Acronym for web assembly zig machine
<fengb>
Okay I'll take it. Thanks
<fengb>
Luckily I avoided all names in the git so no paper trail :P
SimonNa has joined #zig
dalobstah has joined #zig
araspik has quit [Remote host closed the connection]
araspik has joined #zig
dalobstah has quit [Quit: dalobstah]
araspik has quit [Ping timeout: 260 seconds]
frmdstryr has quit [Ping timeout: 265 seconds]
<betawaffle>
i mean, what about wazm?
<betawaffle>
oh, you already had that idea
<companion_cube>
:D
<betawaffle>
it's not like i have time to read things first
<betawaffle>
only after i've already made a mistake
<andrewrk>
wazm is good
ur5us has joined #zig
waleee-cl has joined #zig
<fengb>
Oh do we have a convention for projects? Like PyFoo, Foo4J, Foo.js, etc.
<fengb>
Important questions in life
<andrewrk>
libfoo
<andrewrk>
eat c's lunch
<fengb>
So our output files will be liblibfoo.so? 🙃
araspik has joined #zig
araspik has quit [Remote host closed the connection]
frmdstryr has joined #zig
<andrewrk>
at ok cupid we had, no joke, a build artifact called liblibmodule.so
<andrewrk>
which if you think about it, means "library library library library"
<fengb>
lol
<andrewrk>
maybe this is tooting my own horn but, I really really like programming in zig compared to C++ for the self-hosted compiler bits
<andrewrk>
it's so much easier to make changes without introducing regressions
<andrewrk>
compile errors be like, hey buddy, remember that thing you needed to do?
LER0ever has quit [Ping timeout: 240 seconds]
<shakesoda>
andrewrk: zig is destroying my life and that's a wonderful thing
LER0ever has joined #zig
<shakesoda>
andrewrk: i've got some work in the queue on some c++ codebase, and it is hurting my soul so much more than usual
<shakesoda>
fortunately, that hasn't started yet, so i can enjoy using zig for myself ;)
<Snektron>
Imagine making your own programming language and then programming in ot
<Snektron>
Sounds neat
<shakesoda>
i've done it before, except my language sucked and i got distracted before really following through
<jaredmm>
andrewrk: this is a few days old now, you you were right that __cplusplus isn't defined when running an empty translate. Somehow including Windows headers seems to enable it? Been sick the last two days and couldn't investigate anymore.
<shakesoda>
never got far beyond "vaguely working prototype"
<andrewrk>
I'm excited for when zig goes into "maintenance mode" and I can actually just use it instead of working on it
<Snektron>
Same
<fengb>
I find it fascinating that a language can possibly be well-designed to account for edge cases
<fengb>
Or rather... most of the time it's not
<andrewrk>
jaredmm, this works for me: zig translate-c foo.c -target x86_64-windows-gnu -lc
<andrewrk>
that works on any system ^ (where foo.c is #include <windows.h>)
<andrewrk>
and __cplusplus is not defined
<andrewrk>
this works on any system because zig ships with the ability to build mingw-w64 libc from source, and its headers
* shakesoda
is scrolling through a cimport.zig with... many thousand... @compileErrors
<jaredmm>
andrewrk
<jaredmm>
Oops
<jaredmm>
Nevermind, my addled brain isn't working yet. I'm recalling that the problem was that it was missing an enumeration definition.
<jaredmm>
I assumed that it was running the __cplusplus code based on how the result looked, but it was actually an empty variable name?
<jaredmm>
: struct_tagMOUSEHOOKSTRUCT, is in the resulting definition when it should be `DUMMYDATA: : struct_tagMOUSEHOOKSTRUCT,`, I think. I need to get back into it.
<jaredmm>
`MOUSEHOOKSTRUCT DUMMYSTRUCTNAME;` is what the header has
wilsonk has joined #zig
<andrewrk>
jaredmm, the next step to diagnosing this is probably to try to recreate a small self-contained test case of C code that translates into different zig code than you would expect
mforney has quit [Excess Flood]
mforney has joined #zig
<jaredmm>
Yep, that's the plan. I think I did make an example the other day, just need to find it.
zfoo_ has quit [Read error: Connection reset by peer]
decentpenguin has quit [Quit: decentpenguin]
<fengb>
Can I cast between function pointers if all the types are binary compatible? e.g. fn (a: i32, b: *T) i64 => fn (a: u32, b: *T2) u64
<mikdusan>
looks like ziglang.org download bins aren't updating
<Snektron>
I think its asking for trouble, fengb
<Snektron>
I'd say to restrict it to extern functions because of the abi guarantees
Akuli has quit [Quit: Leaving]
<fengb>
My wasm vm jump table can disappear if I can use a function pointer
<fengb>
So... I'm asking for trouble :P
<andrewrk>
fengb, if you use an explicit calling convention, such as C calling convention, then @ptrCast in this case will be well-defined
<andrewrk>
otherwise a @ptrCast between these functions is undetectable undefined behavior
<andrewrk>
it's this instruction, inside cpuFeaturesFromLLVM which is part of src-self-hosted/stage2.zig
<andrewrk>
so actually I do think this has to do with incorrectly enabling extra cpu features
<fengb>
Funnily enough... I can generate the giant switch at comptime so that'd optimize out the FP if I can have reasonably similar
<andrewrk>
mikdusan, my sub-architectures branch coincides with this issue, so I'll just make sure it's working before I merge that branch
<mikdusan>
+1
<andrewrk>
mikdusan, oh, derp, I forgot to make the cmake invocation of zig0 cross compile rather than native
<mikdusan>
ah
<mikdusan>
so it produced libuserland.a with native insts ?
<andrewrk>
yes exactly
<andrewrk>
it's renamed to libzigstage2.a now btw
<mikdusan>
the cross-compile should be a target which then defaults to base features?
<andrewrk>
yes we just need to add `-target arch-os` in cmake
<andrewrk>
maybe zig0 can support -mcpu=baseline
<andrewrk>
that way we don't have to add any cmake logic
<mikdusan>
heh i was just trying `zig0 targets` but hey... it's a stage2 feature
<mikdusan>
alternatively we have /opt/llvm dependency. are there any llvm/bin/* tools that can show suitable target?
<andrewrk>
eehh I think a more reliable solution is a hard coded flag to zig0
<mikdusan>
indeed. I just saw what llvm targets look like.
<Snektron>
Zig0 = stage1?
<andrewrk>
more like stage0
<fengb>
Zig0 is the stage1 minus zig userland
<andrewrk>
stage1 has some stage2 stuff in it
<andrewrk>
bootstrapping is messy :)
<fengb>
We use zig0 to build the userland and link it into stage1
nepugia has joined #zig
<Snektron>
Wait so whats the difference between stage1 and 2?
<andrewrk>
mikdusan, alright the latest master branch commit should hold us over until #4509 is merged
<mikdusan>
zig0 builds a minimalist (explicit) amount of stuff from userland and creates libzigstage2.a; zig (we dropp the `1` suffix) is then built with c++ and links libzigsage2.a which has some exports to C. then in future we will use zig (aka zig1, aka stage1) to build self-hosted stage2 compiler
<andrewrk>
Snektron, "stage2" is when stage1 builds The Self Hosted Compiler
<andrewrk>
mikdusan, I also want to note that once we're shipping self-hosted, this problem becomes irrelevant. first of all we won't need zig0/zig. but also, if we did, it could use native CPU features because when stage3 is built that's when we would decide the for-real cpu feature set
<andrewrk>
everything until stage3 can be native
<mikdusan>
this is all the great-stage2-bootstrap-of-[2015-2020]
<fengb>
Stage3 is when stage2 builds zig source?
<mikdusan>
stage3 is when self-hosted builds self-hosted in a final, clean step
<andrewrk>
right because otherwise we would be shipping a self-hosted compiler *which was built by c++ code*
<andrewrk>
hmm it's difficult to avoid ambiguity when explaining this
<andrewrk>
it's like, consider where the compiler binary bits came from
<fengb>
And stage4 would be identical to stage3?
<andrewrk>
stage1: they came from gcc compiling .cpp code
<andrewrk>
stage2: they came from stage1 compiling .zig code
<andrewrk>
stage3: they came from stage2 compiling .zig code
<fengb>
Stage4 = we use stage3 to compile again
<andrewrk>
only stage3 has zig compiling zig
<andrewrk>
right stage4 would be identical. we can test that because release builds are supposed to be reproducible
adamkowalski has joined #zig
<andrewrk>
that will be a fun set of bug(s). when we find out that stage4 is not identical to stage3
_Vi has quit [Ping timeout: 248 seconds]
<fengb>
I think everything makes sense... but I still find it funny that stage1 uses half of itself to build the rest
<andrewrk>
right but after we are shipping self-hosted, that can stop
<andrewrk>
this is just a way to make incremental progress
<andrewrk>
err maybe I didn't understand your comment
<dimenus>
andrewrk: i have a quick question about the update libc documentation. What dir is the 'rm -rf $(ls ../lib/libc/include/ | rg gnu) supposed to be run from?
<dimenus>
from build or hdrs?
<andrewrk>
build. it's referring to $zigcheckout/lib/libc/include. it should be clear if you ls that dir first
<andrewrk>
dimenus, btw if you leave your glibc build on your hard drive, you'll be able to use `-Denable-foreign-glibcs` when running the test suite
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus>
andrewwk:but that first call doesn't delete anything then, it evaluates to a rm in the build dir instead of the $zigcheckout/lib/libc/include
mahmudov has quit [Ping timeout: 265 seconds]
<andrewrk>
well it's not a script, it's instructions for a human to follow. do you get the intent? maybe you can clarify the instructions
<andrewrk>
I see the problem you're pointing out
<dimenus>
i realize that, which is why I'm trying to clarify what the intent is
<andrewrk>
dimenus, I updated the page, should be correct now