mahmudov has quit [Remote host closed the connection]
lunamn has quit [Quit: leaving]
lunamn has joined #zig
adamkowalski has quit [Remote host closed the connection]
shakesoda has quit [Ping timeout: 246 seconds]
shakesoda has joined #zig
alexnask has quit [Ping timeout: 258 seconds]
<jaredmm>
translate-c works if I extract the header code that isn't translating to its simplest form. I'm not sure what part of the Windows header causes the problem and they are vast. Any pointers for ways to investigate?
drp has joined #zig
drp has quit [Remote host closed the connection]
nepugia has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
Cadey has quit [Quit: WeeChat 2.7]
mforney has quit [Excess Flood]
mforney has joined #zig
<mikdusan>
full disclosure: I don't know what I'm doing -- just unpinned an issue that was closed; think it was that illegal instruction thing.
dddddd has quit [Read error: Connection reset by peer]
nepugia has joined #zig
ur5us_ has quit [Ping timeout: 248 seconds]
_Vi has joined #zig
nepugia has quit [Ping timeout: 240 seconds]
LER0ever has quit [Remote host closed the connection]
LER0ever has joined #zig
<andrewrk>
mikdusan, sounds good, I just wanted that there until the downloads got fixed
pixelherodev has quit [Ping timeout: 240 seconds]
LER0ever has quit [Ping timeout: 258 seconds]
LER0ever has joined #zig
waleee-cl has joined #zig
notjones has joined #zig
<Snektron>
I wonder whats more powerful
<Snektron>
A 3990X or 4.6 million Z80's
_Vi has quit [Ping timeout: 272 seconds]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
return0e has joined #zig
alexnask has joined #zig
mixi has quit [Remote host closed the connection]
mixi has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee-cl has quit [Quit: Connection closed for inactivity]
knebulae has joined #zig
slowtyper has quit [Ping timeout: 265 seconds]
slowtyper has joined #zig
waleee-cl has joined #zig
neceve has joined #zig
Xatenev has joined #zig
ave_ has joined #zig
drp has joined #zig
jjido has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
_Vi has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pixelherodev has joined #zig
marmotini_ has quit [Remote host closed the connection]
<pixelherodev>
`zig fmt` integration in Vim has ruined my ability to indent properly :P
<pixelherodev>
I just leave formatting a total disgusting mess (don't even always bother hitting newline) and let the formatter clean it up :P
<Xatenev>
pixelherodev, I always do that lol
<Xatenev>
in all languages
<Xatenev>
function a() { do something; do something else; yes; } - Ctrl L
<Xatenev>
done
<Xatenev>
:P
dimenus has quit [Quit: Leaving]
zfoo_ has joined #zig
mahmudov has joined #zig
decentpenguin has joined #zig
marmotini_ has joined #zig
<pixelherodev>
There a standard way of using ANSI escape codes?
<dingenskirchen>
didn't find a proper[tm] way, but I'd personally go with constants like ANSI_RED and ANSI_RESET to use format() with
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
frmdstryr has quit [Read error: Connection reset by peer]
jjido has joined #zig
frmdstryr has joined #zig
metaleap has joined #zig
<pixelherodev>
Yeah, but for now `\x1B[32m` in one or two places is fine
<fengb>
Uh oh... I've been assuming *u64 == *u32. That's a little endian nism right?
<pixelherodev>
Yeah
<pixelherodev>
Unless Zig defines otherwise, which would be interesting...
<shakesoda>
hope u like swapped bytes
<pixelherodev>
Actually, that's an interesting proposal
<shakesoda>
zig should absolutely, for sure, not attempt to correct for endianness lol
<pixelherodev>
All code can assume that it's running on little endian systems, and the compiler implicitly changes pointer accesses on big endian systems to facilitate this
<fengb>
I'll just pretend BE doesn't exist :P
<shakesoda>
BE practically doesn't exist on modern systems, so that's fair
<fengb>
I don't think it's actually bad yet... but I'm too lazy to redesign
<pixelherodev>
There are BE-capable modern systems, aren't there?
<pixelherodev>
IIRC OpenPOWER?
<shakesoda>
yes, but nobody uses them in BE
<fengb>
I'm mostly assuming union locations are fixed, and I don't think I ever actually cross types
<shakesoda>
both arm and power are bi-endian but everyone uses them as LE, iirc
<shakesoda>
mips is LE these days too
<shakesoda>
I think the only users of such hardware in BE would be some crazy network hardware
<shakesoda>
i.e. things crazy enough that avoiding byte swapping for stuff going through the pipes actually saves money
<fengb>
Hmm... HFTs? :P
<fengb>
Those nanoseconds count
<shakesoda>
for my own purposes the last time I had to deal with BE was previous gen consoles
<shakesoda>
x360 etc
<fengb>
Oh that was still on POWER?
<shakesoda>
yep, that was ppc
<shakesoda>
ps3 was also power
<shakesoda>
...and so were the wii and wii u, now that I think about it
<fengb>
The last hurrah
<fengb>
I'm getting into the weird state where both endians are making sense and it's confusing me
dimenus has joined #zig
<shakesoda>
fengb: abort! abort!
<shakesoda>
endians do that to me, too
nepugia has joined #zig
zfoo_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
I'm going to submit a patch shortly to add ANSI codes to zag
<pixelherodev>
Just as soon as I figure out a good namespace to put it in...
<pixelherodev>
Also, I love that std.debug.assert improves optimizations in releasefast/releasesmall modes
<pixelherodev>
Huh, some ANSI codes are already in std.debug
<pixelherodev>
... but they're not public?
<pixelherodev>
Would a patch to create e.g. std.ansi, move those constants in there and have std.debug use them from there be accepted?
<metaleap>
pixelherodev "std.debug.assert improves optimizations in releasefast/releasesmall modes" how's that work, the compiler actively watches out for any calls to a symbol resolving to exactly std.debug.assert? pretty neat if so
<Xatenev>
I never understood why network byte order is big endian but everything else uses little endian
<Xatenev>
anyone has a clue? :p
<pixelherodev>
metaleap, nah, because it uses unreachable
<Xatenev>
I always thought its just historical reasons.
<metaleap>
ah yeah gotcha, of course. even neater
<pixelherodev>
So the optimizer knows that whatever's inside the call can't be true
dimenus has quit [Remote host closed the connection]
<fengb>
BE was popular when networking was invented. DEC, PDP, were all BE
<fengb>
I think x86 was the outlier that ate the industry
<pixelherodev>
AFAICT it's for the same reason tabs are banned in Zig
<pixelherodev>
"It doesn't matter, just shut up about it and get back to work"
<fengb>
But... mah tabs and carriage returns
<mikdusan>
never mind that. what about EBCDIC support /s
<shakesoda>
adding chunks should be thread safe (as it is in the compute shaders) although I haven't tested that
nepugia has joined #zig
<Barabas>
andrewrk thanks!
jjido has joined #zig
xackus has joined #zig
<xackus>
do zero length slices always have a null pointer?
karelb has joined #zig
<karelb>
hey. I like ziglang, but have no clue what to do or build with it. So, I had an idea. I like protobuf. I will write some library (ish) to support protobuf in zig. Is that a good idea?
<karelb>
I have no real idea how zig actually works
<karelb>
so it will be funny
<karelb>
it looks like something at least a bit doable, right...
<andrewrk>
today, 5pm EST, which is in 4 hr 50 min. topic will be more casual game dev
return0e has quit [Remote host closed the connection]
<nepugia>
finding your twitch channel has been quite difficult for me, perhaps you could add a link to your website for people that follow me in trying to find it :P
<nepugia>
s/to/on/
return0e has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<andrewrk>
good point
Akuli has joined #zig
<andrewrk>
BaroqueLarouche, are you available to confirm that ZigGBA works correctly with the sub-architecture-annihilation branch?
<andrewrk>
I sent you a PR
<BaroqueLarouche>
I’ll check that tomorrow, today is my birthday
<BaroqueLarouche>
Or at best tonight before I go to bed
frmdstryr has joined #zig
<frmdstryr>
How can I iterate over a tuple?
<frmdstryr>
`for (args) |arg| {` is saying error: unable to evaluate constant expression
<andrewrk>
happy birthday BaroqueLarouche!
<andrewrk>
frmdstryr, that is supposed to work
<mq32>
frmdstryr: std.meta.fields
<fengb>
Not sure we should allow iterating over any tuple since they’re heterogeneous
<companion_cube>
a comptime iteration should be ok, right?
<scientes>
(although that author has it wrong, and means armv4t+)
<scientes>
for example, if you want documentation of the old non-IEEE compliant floating point in those pre-thumb CPUs you have to do a special request from ARM
<scientes>
its mixed-endian too
<scientes>
the big early feature that we *can* support however is that pre-armv6 ARM does not support aligned access, and while most software does not work with this, zig code should (and needs to for other arches, and it would be useful to have some of these CPUs to test on)
<BaroqueLarouche>
any cool device that use pre armv4t ?
<scientes>
BaroqueLarouche, I had a armv5t device, and its pretty slow by today's standard, the Nokia N900 phone also had a armv4t chip
<scientes>
they are probably used in industrial automation, specifically the strongarm chips, but I don't know what I am talking about
<scientes>
so while that would be an argument against turning it off needlessly, I wouldn't want to be the person to try it
<scientes>
yeah, so I take back what I said---if you try to use it you probably know the limitations and know you will have to deal with bugs
<scientes>
(and know you can't use the floating-point)
<scientes>
cause generally every programmer assumes IEE# 754, and zig should probably have some flag so that zig programs can also assume that, and force soft-float if it is unavailable
<BaroqueLarouche>
I have made a FixedPoint generic struct, still local to my machine
<scientes>
does it only have a single method? i.e. is it actually a generic?
<scientes>
*a single member
ofelas has quit [Quit: shutdown -h now]
<BaroqueLarouche>
you can specify the number of bits of the integral and the fractional part
<scientes>
yeah, but those values need to only be part of the type, and not part of the run-time value
<BaroqueLarouche>
they are part of the type
<scientes>
OK, cool
<scientes>
another feature that doesn't have to be part of core
mahmudov has quit [Ping timeout: 260 seconds]
<BaroqueLarouche>
nope, it will only useful for old computers and consoles that don't have FPU
<scientes>
fixed-point has use even in computers with a FPU
<scientes>
every financial application uses fixed-point math
<scientes>
(or decimal floating point, but that is uncommon)
<scientes>
(again, I don't really know what I am talking about)
<Barabas>
error: expected type '[*c]?*c_void', found '**c_void'
<Barabas>
note: pointer type child '*c_void' cannot cast into pointer type child '?*c_void'
<Barabas>
Shouldn't that be possible?
<andrewrk>
oh shit, I can't stream yet because the "build all glibcs" command I started in the morning is still running and maxing out my cpu cores
<andrewrk>
and it is incapable of resuming if it gets interrupted
<companion_cube>
ctrl-z ? :D
<companion_cube>
(will eat your RAM still)
<Barabas>
Download some more cores :P
<andrewrk>
I have enough ram. that migth actually be the first time ever I had a legitimate use case for ctrl+Z
<andrewrk>
wow amazing it works perfectly
<companion_cube>
I often do `ctrl-z` followed by `fg ; notify-send 'done'` so I can focus elsewhere
<Barabas>
hahaha
<fengb>
I've never trusted ctrl-z >_>
<companion_cube>
ctrl-z always worked super well for me
jjido has joined #zig
decentpenguin has quit [Quit: decentpenguin]
<andrewrk>
Barabas, consider: you give a **c_void, which is not allowed to have nulls. it becomes [*c]?*c_void. Now somebody does this: `x.* = null`; now your **c_void has an illegal null
<andrewrk>
so, an automatic type coercion is not allowed
<Barabas>
Aha!
<Barabas>
I see.
_Vi has joined #zig
* betawaffle
waits patiently for stream to start
<SyrupThinker>
+1
<nepugia>
I must say, betawaffle is a great nickname
<betawaffle>
thanks
<dimenus>
andrewrk: I re-did my PR to move the checking up to targets.cpp and now my breakout clone runs great
<dimenus>
>>> referenced by functexcept.o:(std::__throw_logic_error(char const*)) in archive /usr/lib/libstdc++.
<Barabas>
I thought: "This is the umpteenth time I needed `testing.expectNotEqual(a, b)`, let me write it, it's probably super easy..." and then I saw how big `testing.expectEqual` actually is...
<fengb>
(I'm not sure I should talk about getting anything done)
<mq32>
fengb, you wanted to do stuff on the wasm interpreter, right?
<mq32>
how's it going?
<fengb>
Uh... it parses an empty wasm file
<fengb>
(lol)
<mq32>
oh, i can do that as well!
<fengb>
Actually the entire bytecode parser is "done"... or at least coded directly to spec
<fengb>
I need to convert it to the proper internal code, then actually run it
<pixelherodev>
Yay!
<pixelherodev>
Parsing emptiness is a great second step
<fengb>
Which the opcodes are somewhat done, and I blindly implemented function calls
<fengb>
So it's like maybe 30-40% functional. But it looks like 0% so there's that :P
<fengb>
I stalled a bit trying to find documentation on how the wasm stack works. I'm pretty sure that... there's no standard for it so I just made something up that'll hopefully work decently
<mq32>
i thought rewriting my VM is a piece of cake
<metaleap>
re vscode: i have visions of creating a textmode editor "zodium" in zig that loads vscode settings-files and extensions (they're just nodejs proggies anyway) and behaves similarly ux-wise (panels, terminal, diags-view etc) .. once i figure out the termios situation in zig and the LSP is "done enough" :D
<mq32>
and now i'm sitting here, writing unit test by unit test
<shakesoda>
i've only used a tiiiiny bit of comptime so far
<mq32>
shakesoda: my example above is pretty much the stuff you cannot do in a lot of languages
<mq32>
i encode the instruction encoding directly in my Instruction-union
<mq32>
so i can add new instructions and the encoder will decode them happily
<fengb>
Yep same. It feels good if it works
<mq32>
yeah
<mq32>
i can now simplify my code again
<fengb>
“Reimplementation of the LoLa language in C++” 🤔
<mq32>
yeah, now: Zig :D
<mq32>
Iteration v3
<Barabas>
> and now i'm sitting here, writing unit test by unit test
<Barabas>
You should do that before writing your code :P
<mq32>
nah
<fengb>
Hard to unit test VMs
<mq32>
yeah, but i can debug a lot of stuff
<mq32>
*test
* mq32
is not a fan of TDD
<Barabas>
Why not?
<Barabas>
Zig is pretty great for it
<mq32>
because it assumes the impossible:
<mq32>
to know the correct type of API before implementing a thing
<companion_cube>
I thought TDD was something only dynamic language users did :)
<mq32>
just look at zig and how often we have breaking changes
<companion_cube>
I like type-driven development personally 🙃
<Barabas>
Yeah the API thing is also one of my objections
<mq32>
if we would program to fulfil a predefined API instead of a evolutional API
<fengb>
I think it’s fine for specific cases. For VM development, the obvious units are too small and only behavioral tests are concrete tests
<Barabas>
But suppose you're using your unfinished API, it's still good to test your code before it crashes in a production environment
<Barabas>
So, you could argue you should write tests anyway ^^
<mq32>
but TDD is "write tests, then code"
<mq32>
i go the other way
<fengb>
Like there’s no way for me to test my op codes because that’s dumb
<companion_cube>
just write integration tests, man
<mq32>
because i often refactor my APIs one to five times when developing them
<Barabas>
It's very hard to test everything with integration tests.
<mq32>
it's even harder to test stuff with unit tests
metaleap has quit [Quit: Leaving]
<Barabas>
Depends
<mq32>
most stuff in "real software" isn't really testable as it depends on the outer world
<Barabas>
Nah
<fengb>
Yeah it depends. I have a few unit tests in wazm already and it’s been useful
<companion_cube>
it's very to test everything with any technique
<fengb>
Just... nothing in the core logic yet
<mq32>
i got the job to test software a colleague is writing
<companion_cube>
(I guess the one exception I know of is sqlite, and they have 100× more loc for tests than for the DB itself)
<Barabas>
It's easier to write tests for all edge cases for one small class than to write integration tests which cover all edge cases in your whole software.
<mq32>
and i say: it's impossible to test this stuff with "inside tests", black box tests are the way to go here
<companion_cube>
I guess it depends on what you write. If you're writing a compiler, the number of edge cases is absurdly high, and testing components in isolation is very hard
<nepugia>
both types of tests can only protect you against failures you can predict or know about
<mq32>
<nepugia> both types of tests can only protect you against failures you can predict or know about
<mq32>
this
<Barabas>
@nep
<mq32>
you cannot test against failures you don't know
<Barabas>
nepugia that's why with TDD you write tests before you write code ^^
<fengb>
Depends. Many unit tests I find are testing trivial things that are too tiny to be useful
<Barabas>
So you don't have any code you didn't test.
<mq32>
Barabas: how would you develop a serial driver then? ;)
<nepugia>
Barabas, that hardly helps, if you have a new failure case (compiling breaks when you sneeze into your microphone) you cannot protect against that, if that is outside your known enviroment
<mq32>
i cannot write tests for that
<mq32>
neither unit- nor integration tests
<Barabas>
sure
<Barabas>
some things you can't write tests for
<fengb>
Like... I cant unit test Redux at all because all the units are too tiny and have no core logic
<Barabas>
But most software isn't drivers ^^
<Barabas>
Graphics stuff is also hard/impossible to test.
<companion_cube>
how do you unit tests video games?
<nepugia>
for drivers i sure like fault tolerance like minix3 does it, they survive so much compared to other OS drivers :3
<companion_cube>
sounds like "most software" is hard to test :)