rzezeski has quit [Quit: Connection closed for inactivity]
<ky0ko>
ronsor: if you want some more things that might make you express shock, the dos system in question is running a multitasking kernel and an x11r4 server and i want the zig program i'm writing to be an x11 client on that :)
<ky0ko>
as well as possibly using the 3dfx glide api to run a voodoo2 card...
ur5us has quit [Ping timeout: 260 seconds]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
ur5us has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
<andrewrk>
I was thinking a wasm build would have a bunch of the compiler gutted and only support the wasm32 backend
<andrewrk>
on the other hand, it could have everything enabled and provide a godbolt experience
<andrewrk>
and only be able to run wasm32 programs
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
<ronsor>
ky0ko: pretty interesting
<ronsor>
but not the craziest thing
<ronsor>
I had a multitasking kernel for DOS I had made a while ago
<ky0ko>
i'm using desqview/x, which is a multitasking dos supervisor with a built in x11 server and utilities
<ronsor>
desqview/x. haven't heard that name in years.
KoljaKube has quit [Ping timeout: 246 seconds]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
Amun_Ra has quit [Ping timeout: 265 seconds]
Thalheim has quit [Ping timeout: 265 seconds]
jicksaw has quit [Ping timeout: 265 seconds]
jicksaw has joined #zig
PC9801 has quit [Ping timeout: 265 seconds]
pixelherodev has quit [Ping timeout: 265 seconds]
V has quit [Ping timeout: 265 seconds]
dddddd_ has quit [Ping timeout: 265 seconds]
swills has quit [Ping timeout: 265 seconds]
commander has quit [Ping timeout: 265 seconds]
swills has joined #zig
rzezeski has joined #zig
jicksaw has quit [Ping timeout: 264 seconds]
V_ has joined #zig
commander has joined #zig
PC9801 has joined #zig
jicksaw has joined #zig
V_ has quit [Client Quit]
V_ has joined #zig
Amun_Ra has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
V_ is now known as V
dddddd_ has joined #zig
<andrewrk>
finally, a green CI build
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
lanodan has quit [Ping timeout: 244 seconds]
gert_ has quit [Quit: WeeChat 2.8]
lanodan has joined #zig
craigo has joined #zig
joey152 has quit [Remote host closed the connection]
marnix has joined #zig
<andrewrk>
I figured out how to codegen unsigned integer operations in the C backend
<ifreund>
andrewrk: with regards to unifying codegen.zig and codegen/wasm.zig, I'm planning to focus on river for the next few days so don't worry about any conflicts
<ifreund>
I'm happy with how the in-memory incremental compilation PoC worked out and think that design should be good long term
<ask6155>
Hey guys how do I open a file and read it?
<ifreund>
would just need to convert it to the lua peg format they use
<ask6155>
I just wrote some C code and commented it out and when I check while the file program it wrongfully says it's a C source file and due to that vid gives me C syntax highlighting. (It's not any good though)
<ifreund>
actually a pretty cool way to do syntax highlighting
<ask6155>
*vis
<ifreund>
lol
waleee-cl has joined #zig
<ask6155>
Hey I have a file struct and I read it with .read and used try so the error would appear on main but I got no errors on compilation but When I ran it It reached unreachable code but I never got to know what .read() error it was. Am I using try wrongly?
<ask6155>
var some_chars: []u8 = undefined; _ = try file.read(some_chars);
<ask6155>
}
<ask6155>
yeah it doesn't look that bad in the editor
<KoljaKube>
I think you are missing memory to read the file into
<KoljaKube>
some_chars is a slice pointing nowhere
<KoljaKube>
Since file.read does not take an allocator, it won't allocate memory itself
<KoljaKube>
Either prepare a buffer of fixed size (array): var some_chars: [1024]u8 = undefined;
<KoljaKube>
Or use something like readAllAlloc
<ask6155>
I got error expected []u8 got [1024]u8
<KoljaKube>
Guess you would need to pass some_chars[0..] to turn the array into a slice again
<KoljaKube>
That gets me all the time, too :D
<ask6155>
That's weird
<KoljaKube>
I bet there are good reasons why it doesn't coerce automagically, but I would know them
<alexnask[m]>
why? we just dont implicitly coerce arrays to pointers
<ask6155>
yeaaah I'm C where pointer and array are the same thing
<alexnask[m]>
zig aims to be more explicit
<alexnask[m]>
about all kinds of things, but especially implicit conversions
<ikskuh>
ask6155: enjoy having a language that has *actual* value arrays <3
<ask6155>
So now I have a [1024]u8 which is a slice? I wanted to log it but the function take a []const u8 aka string? so how do I convert a slice to a string now?
<ikskuh>
[1024]u8 is a array
<ikskuh>
a pointer to an array coerces to a slice
<ikskuh>
so if you do
<ikskuh>
var arr: [1024]u8 = undefined;
<ikskuh>
var slice_like = &arr;
<ikskuh>
"[]const u8" is a slice
<ikskuh>
a slice that points to several constant u8
<KoljaKube>
Forgot about the &. When is [0..] or & more appropriate?
<KoljaKube>
Bah. "error: compiler bug: generating const value for struct field '0'" I want my money back ;-)
<ask6155>
Does isSpace function take into account of all spaces in unicode?
<ikskuh>
std.ascii.isSpace?
<ask6155>
yeah
<ikskuh>
no
<ikskuh>
it's not from std.unicode.isSpace :D
<ask6155>
amen to that!
<ask6155>
I was thinking about finding out all the spaces and checking for them but I guess It's done in std~
<ikskuh>
andrewrk: i start to understand why deinit(self: *Self) is superior
<ikskuh>
it would've helped me find a bug way earlier
pixelherodev has joined #zig
<ask6155>
wait... there is no std.unicode.isDigit ;(
ask6155 has left #zig ["Later"]
<gonz_>
Hey, does anyone know what happened to `LeakCountAllocator`?
<fengb>
It got removed because the general purpose allocator does everything it did but better
<gonz_>
Allright
<gonz_>
I haven't updated zig in a while because of issues with zls
<gonz_>
GPA is in std now...?
<pixelherodev>
Yep!
<pixelherodev>
Also, freaking love git
<pixelherodev>
`git rebase master -i` :D
craigo has joined #zig
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
<gonz_>
ikskuh: You're running the Windows version of zig now and then, right? Are you seeing `NUL` files being output with the latest master?
<gonz_>
I thought this was related to the compiler erroring on `zls`, but it turns out it's on literally every compile, successful or not.
<ikskuh>
gonz_: i only run them in CI envs
<gonz_>
Hmm, ok.
dingenskirchen has joined #zig
<alexnask[m]>
Ive been getting the NUL file as well gonz_
KoljaKube has quit [Ping timeout: 272 seconds]
<gonz_>
It's nice to not be alone :D
<alexnask[m]>
I think it happens on every `zig run` (and thus `zig build`, `zig test` as well)
joey152 has joined #zig
scriptnull has joined #zig
rzezeski has joined #zig
cr1901_modern has joined #zig
<pixelherodev>
andrewrk: I'm redoing SPU-II support. For TextBlock allocation, what did you want me to be doing here? Setting an Option for valid executable range?
scriptnull has quit [Ping timeout: 240 seconds]
scriptnull has joined #zig
scriptnull has quit [Quit: scriptnull]
<pixelherodev>
I think I've got a small trick for now, but not a good long-term solution yet
radgeRayden has quit [Remote host closed the connection]
dingenskirchen has quit [Remote host closed the connection]
radgeRayden has joined #zig
xackus has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
Wow, lots of nice astgen work from Vexu :D
<ifreund>
yeah they just dove in
<pixelherodev>
Yeah, it's awesome :D
<pixelherodev>
Going to need to finish up the spu-ii work so I can get CBE support for a lot of that :)
KoljaKube has joined #zig
<pixelherodev>
Woot! Re-did SPU II support :)
<ifreund>
nice, I rewrote the 90% of the wasm backend yesterday so you're in good company :P
<pixelherodev>
This was more rebasing than rewriting
<pixelherodev>
Then, once rebased against master, a bunch of squashing, and a bit of commit-splitting
cole-h has joined #zig
<pixelherodev>
Only remaining issue is that binaries are inexplicably *64MiB*
<ikskuh>
lol
<ifreund>
heh
<pixelherodev>
This actually makes no sense though :P
<pixelherodev>
objdump indicates that it isn't even using it
<pixelherodev>
huh
<pixelherodev>
I rebuilt it and now it's 4.1KiB
* pixelherodev
shrugs
<pixelherodev>
I guess it's good then :P
<pixelherodev>
I think I understand it enough to write an ELF loader now :)
jmiven has quit [Quit: reboot]
jmiven has joined #zig
<ikskuh>
elf loader is easy
<ikskuh>
copy all sections that are marked as "LOAD" into the memory :D
radgeRayden has quit [Ping timeout: 272 seconds]
radgeRayden has joined #zig
<pixelherodev>
I know :)
<pixelherodev>
/usr/local/lib/zig is out of date, so autocomplete is a bit wonky
<ikskuh>
just run zig-update :D
<pixelherodev>
My zig updating script only affects my PC
<pixelherodev>
(remote builder)
<pixelherodev>
It doesn't affect the local files, which are used for autocomplete
<ikskuh>
but why?!
<pixelherodev>
Because I almost never use local zig
<pixelherodev>
and the script runs over ssh :P
CodeSpelunker has joined #zig
radgeRayden has quit [Ping timeout: 272 seconds]
xackus has quit [Ping timeout: 240 seconds]
Akuli has joined #zig
<KoljaKube>
Can I convert an error union into a boolean in one line?
<ikskuh>
what do you want to convert?
<KoljaKube>
Like `const can_access = std.fs.cwd().access("some_file", .{read=true}) <something>`
<ikskuh>
AnyError!AnyValue → "is there a error?"
<KoljaKube>
Yep
<ikskuh>
if(errunion) |_| true else |_| false
<KoljaKube>
Ah, I can combine error union ifs with if expression, got it
<KoljaKube>
Thanks
<ikskuh>
everything is a expression ;
<ikskuh>
in zig :)
<KoljaKube>
It is? I thought if was only an expression without braces
<KoljaKube>
Do I need the named block syntax to turn control flow into expressions or how is the expression value determined?
<ikskuh>
no, it's also a expression with braces, as blocks are expressions
<KoljaKube>
I'll try my luck with Wren for now. It's young and still forming and the community is small, so there's a little more hope for me to contribute in some wayt
<DarkUranium>
KoljaKube, use Coyote ;) (once it's ready)
<DarkUranium>
KoljaKube, on Wren: it looks really interesting, but I really dislike how it enforces some syntactic things because of its lack of semicolons
casaca has quit [Remote host closed the connection]
<DarkUranium>
E.g. the brace in `if(x) {` needs to be on the same line. Period.
<companion_cube>
the whole one-pass compiler system is interesting, but a bit constraining, too
<KoljaKube>
DarkUranium: Yeah, but still easier to get used to the brace than lua's 1-indexing ;-)
<pixelherodev>
As a totally impartial advisor, I also suggest using Coyote when it's ready ;)
<pixelherodev>
I have zero stake in the matter, despite the commit history indicating my contributions
<pixelherodev>
It's not remotely close to ready to be used, not actually :P
<DarkUranium>
Nypsie[m], there's a few, depends on what interests you. It's quite different from many embedded langs. For starters, it's statically-typed. There's also a plan to make language server-related stuff builtin (that way, even ingame editors would get all the neat autocompletion, etc, "for free").
<DarkUranium>
I'm too tired to think straight ATM, so forgive me if my "elevator pitch" is a bit flat :P
<Nypsie[m]>
I like the idea of a built-in language server
<Nypsie[m]>
Statically-typed is definitely great, but not ground breaking I suppose :P
<Nypsie[m]>
Looking forward to seeing the end result
<pixelherodev>
DarkUranium will correct me if this is a bad way to phrase it, but I like to think of Coyote like this: as powerful as C, as flexible and embeddable as Lua, and as performant (eventually, hopefully) as the JVM
<Nypsie[m]>
It's part of the contest, right?
<DarkUranium>
Nypsie[m], it kinda is, it's the only alternative to AngelScript in this category, I think.
<pixelherodev>
yep
<DarkUranium>
And AngelScript kinda sucks.
<KoljaKube>
What Wren has also going for it is pretty unsurprising structure, when coming from C/C++. If it were a user-facing part of a software, that may be a good thing
<DarkUranium>
KoljaKube, familiarity is an explicit design goal.
<pixelherodev>
Coyote is a bit Ziggy IMO
<DarkUranium>
Though there are some differences from other C-likes.
<pixelherodev>
I think Zig + Coyote will be an excellent combination when they're both done :)
<DarkUranium>
(where I deemed it "adequately beneficial")
blakeb2 has quit [Remote host closed the connection]
<Nypsie[m]>
DarkUranium: My bad for a moment I thought of strongly typed instead of statically typed.
<KoljaKube>
Anyhow, I'm not the right person to promote Wren. I've barely used it, it just didn't shy me away on a superficial level.
<KoljaKube>
I can say more once zapata is in use in my actual project ;-)
<ikskuh>
how many people here have their own pet language? :D
<Nypsie[m]>
<--
<DarkUranium>
Nypsie[m], another thing: I do intend to compile Coyote to native as well eventually. The sort of "vision" is to use the VM for development and user stuff (think mods, or level "scripts") --- but compile to native for distribution.
<ikskuh>
oh, you too? :D
<tdeo>
is there any use for the offset field in builtin.TypeInfo.StructField that can't be done with the other builtins?
<DarkUranium>
Because I'm personally a fan, the plan is to optimize for single-file distribution :)
<Nypsie[m]>
ikskuh: I told you about it the other day on Discord :P
<ikskuh>
oh :D
<ikskuh>
i kinda forget? :D
<DarkUranium>
Nypsie[m], what is thine algorithmic language, Sire?
<Nypsie[m]>
DarkUranium: I like that idea. I was planning on doing something similar for mine to learn more about compiling to machine code instead of a vm.
<Nypsie[m]>
Also private atm, been only working on it for about a month now.
<DarkUranium>
Nypsie[m], there is a feature which I think will make machine code ... a bit easier than usual.
<Nypsie[m]>
Also don't really have much experience, so it's not really something great
<DarkUranium>
Nypsie[m], namely, I figured "fuck it" and decided to use SSA for the bytecode :P
<DarkUranium>
It's 2020, JITs need it too anyways.
<DarkUranium>
pixelherodev does have some concerns about using this from JITs, but I think it should be fine. High-end JITs tend to convert things *to* SSA before doing anything else anyways. I know this one won't be a high-end one from the get go, but eventually.
<Nypsie[m]>
Hmmm interesting, will have some reads to do this weekend :)
<pixelherodev>
Lies.
<pixelherodev>
I have no concerns with it ;)
<DarkUranium>
lol
<DarkUranium>
pixelherodev, what platforms are we JITting? Zilog Z80, RISC-V, POWER9? :P
<pixelherodev>
DarkUranium: if you have no objections to it, we could just target RISC-V and use my RISC-V -> * translator ;)
<pixelherodev>
I'm still rewriting it to be, well, good
<pixelherodev>
Oh this is sick
<pixelherodev>
Kakoune's GDB integration is nice
<DarkUranium>
neat
<DarkUranium>
Nypsie[m], oh, right: If we do manage to get the plan done, Coyote will (to my knowledge) be the *ONLY* embeddable language with builtin LSP support.
<Nypsie[m]>
Looking forward to giving it a spin
<pixelherodev>
In less fun news, my battery's capacity is down 15% from where it was a few weeks ago :(
<pixelherodev>
More than that, actually
<pixelherodev>
Used to go up to ~75-80%, now it's typically at *56%*
<KoljaKube>
Laptop battery?
<pixelherodev>
Yeah :(
<pixelherodev>
Even with powertop it's pretty bad now
<pixelherodev>
ifreund: sure, but it depends on Ninja
<pixelherodev>
The whole point here was to produce a *plain* Makefile, without any extensions
<ifreund>
fair
sawzall has quit [Read error: Connection reset by peer]
<ifreund>
though I don't think ninja is a heavy dependency, there's also a c99 implementation iirc
<pixelherodev>
samu, yeah
cole-h has quit [Quit: Goodbye]
sawzall has joined #zig
<andrewrk>
ooh tdeo I think you are going to make some people very happy :)
KoljaKube has quit [Ping timeout: 260 seconds]
<ikskuh>
yeah, i've seen it too!
<ikskuh>
\o/
<pixelherodev>
:)
<pixelherodev>
Bunch of nice work going on
<andrewrk>
pixelherodev, one option you have is to make your SPU Mk II emulator a third party project and zig could have a -Denable-pixelherodevs-spu-2-emulator to match -Denable-qemu and -Denable-wasmtime
<ikskuh>
oh yeah, more backends
<ifreund>
woot! that will be fun to play with
<pixelherodev>
andrewrk: that's what I suggested initially :P
<pixelherodev>
Alternately, we could do -Denable-spu2={pixelherodev,ikskuh}
<pixelherodev>
Allow the user to specify which emulator to use
<ikskuh>
haha :D
<ikskuh>
xq plz
<andrewrk>
oh xq has one already?
<companion_cube>
you probably need a bunch of xml to scalably specify whose backend to use
<ikskuh>
andrewrk: sure i have an emulator for my CPU :D
<andrewrk>
oh right I've seen this. we need a qemu-usermode equivalent though for ci testing
<andrewrk>
well. not usermode
<andrewrk>
I spoke too quickly. Anyway. we don't have to be executing the tests in order to merge SPU Mk II backend
<andrewrk>
just cross compiling them is enough for now
<pixelherodev>
andrewrk: I can write the test loader in maybe ten minutes of work :P
<pixelherodev>
It really is as simple as iterating over the headers and LOADing the listed sections into the buffer
<ikskuh>
andrewrk: what do you need exactly?
<ikskuh>
a executable that runs a piece of code and has what as I/O
<andrewrk>
ikskuh, are you familiar with how the compare_output stage2 tests work right now?
<pixelherodev>
ikskuh: it's output-only
<pixelherodev>
not input
<ikskuh>
no, not really
<pixelherodev>
basically, it runs the produced code, and compares the output against the given "expected" output
<pixelherodev>
e.g. "Hello, world!"
<ikskuh>
okay
<pixelherodev>
If it sees any other string - or no output - it fails
<pixelherodev>
I was going to copy your suggestion - using a section of emulated RAM as "output"
<andrewrk>
ok so we have a declarative set of test cases, that specify the target being built for. even if the produced binary cannot be run, the compilation happens. the test harness will try to run the binary with different techniques, based on what you declare is available
<pixelherodev>
Heh, just get support into QEMU! /s
<andrewrk>
if you pass -Denable-qemu for example, then the test harness will actually run all the linux target cases using it
<andrewrk>
so the idea here would be to not only be able to cross compile spumk2 test cases but also verify that they have the correct behavior at runtime using some kind of emulator
<ikskuh>
pixelherodev: using the ram as output is probably the easiest thing to do
<pixelherodev>
Not really
<pixelherodev>
UART is easier, arguably
<ikskuh>
hm
<ikskuh>
yeah, maybe
<pixelherodev>
It's *slightly* more work for the test harness
<tdeo>
about to implement @Type for TypeInfo.Enum now, but i'm not sure whether to make Enum.tag_type (type) and Enum.value (comptime_int) optional types, since you can always figure out what the compiler would choose
<pixelherodev>
But in exchange, *every single test* is simpmler
<pixelherodev>
simpler*
<tdeo>
there could be a helper in std.meta that fills those in, or they could be optional fields and the compiler always returns non-null when using @typeInfo
<pixelherodev>
andrewrk: is there an issue with prepending every test for a target with e.g. an output function?
<andrewrk>
tdeo, you can override the tag values with enum { a = 1234 }
<pixelherodev>
For CBE, I prefix everything with the header
<pixelherodev>
but I'm not sure if it's a good idea to do something similar for a more standard backend
<pixelherodev>
s/more standard/proper ISA
<tdeo>
the question is, should @Type make it easy to have sequentially increasing from zero tag values or should the user have to do that themselves
<tdeo>
and second question, should @Type make it easy for the user not to have to pick a tag type and have the compiler do that for them
<andrewrk>
tdeo, hmm I see your question. my suggestion is to make them non-optional to match the output of @typeInfo and let userland solve the convenience problem (as you noted)
<tdeo>
yeah, that's what i was leaning towards myself
<Cadey>
does zig have anything like rust's env!?
<ifreund>
what does env! do?
<pixelherodev>
What's R - imp'd :P
<Cadey>
includes compile-time envvars as strings in the binary
<Cadey>
eg: env!("CARGO_PKG_VERSION");
<pixelherodev>
build_options
<ifreund>
no, zig doesn't have a way do read env vars at comptime
<pixelherodev>
They have to be explicitly specified though
<pixelherodev>
ifreund: technically, you could, via build.zig
<pixelherodev>
and then supply it as a build_option
<ifreund>
ok sure
<pixelherodev>
But no, that's not a suggested method for Zig
<ifreund>
but yeah build options are the way to do compile-time configureation
<pixelherodev>
Cadey: If you want to pass vars in while building, look into build.zig's build_options
<pixelherodev>
It lets you do e.g. `zig build -Dfoo=bar`
<pixelherodev>
Emphatically *not* `foo=bar zig build` though
<ifreund>
well one could implement this but it would be an antifeature imo
<pixelherodev>
Agreed
<Cadey>
fair, was curious more than anything
<Cadey>
wanted to use it to engrave version strings into programs at build time
<pixelherodev>
Zig does that - look at zig's build.zig
<Cadey>
how do i set -D with it?
<ifreund>
huh, didn't know we have a Version struct in builtin
<ifreund>
there's two separate parts here, reading options from the command line and passing options to the project
<ifreund>
the former done with Builder.option()
<ifreund>
the later with LibExeObjStep.addBuildOption()