ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<shritesh> Found the problem
<shritesh> I had stdout_file a const and stream a var.
<shritesh> I looked at the guess example
<shritesh> It has stdout_file be a var
<shritesh> And stdout a const pointer
<scientes> the error should be better than that.....
<shritesh> I still don’t understand why it causes the error or even compiles
<shritesh> Agreed
<shritesh> Should I file an issue for this?
<scientes> yes
<scientes> better though to write a patch
<shritesh> Looks like it’s related to
voldyman has quit [Quit: Connection closed for inactivity]
<scientes> i think you got the const/var backwards
<shritesh> In the issue? What I’ve written does reproduce the problem.
<scientes> oh ok
<scientes> its strange that you have to use const
<scientes> that is super strange
<shritesh> Using const without taking the reference is a compile error, using var without taking the reference is runtime EBADF and both const and var with the reference do the right thing.
<andrewrk> shritesh, #2555 is a duplicate of #591
<shritesh> I’ll comment with a reference to 591 and close it.
<andrewrk> man. #2380 turned out to be a way way bigger issue than I thought it would be. by like a factor of 10 days
<shachaf> You were expecting it to take x days and it took 10x days^2?
<andrewrk> 1 day => 10 days
<shritesh> I like how it’ll make working on WASI simpler.
reductum has joined #zig
<daurnimator> andrewrk: .dockerignore is also a thing.
<andrewrk> .dockerignore is right out
<daurnimator> right.... (and I agree) but I feel like the reasons not to are also the reasons not create a .gitignore
reductum has quit [Ping timeout: 248 seconds]
reductum has joined #zig
reductum has quit [Client Quit]
merlyndmg has joined #zig
scientes has quit [Ping timeout: 268 seconds]
Arghblarg has joined #zig
Arghblarg has quit [Client Quit]
<ijneb> hryx: feelings on response in issue?
Arghblarg has joined #zig
<hryx> ijneb: just responded - I'm pretty sure it's settled but surely it would be fine to bring up counterarguments
<ijneb> I see, decided on closing it
<ijneb> ty
<hryx> sure thing
<Arghblarg> Greetings all
<Arghblarg> Is it allowed to ask zig n00b questions here?
<hryx> Arghblarg: yes! many of us are noobs too
<Arghblarg> :) OK. Well, I'm trying to understand how to use stdin/stdout/stderr for console-type apps...
<Arghblarg> .. it seems zig doesn't really expose them in a traditional way from entry to main().
<Arghblarg> From digging online, I see that it's possible to expose stdout with formatting capabilities by doing the following (inline inside main())
<Arghblarg> const f: os.File = try;
<Arghblarg> var fos: os.File.OutStream = f.outStream();
<Arghblarg> var fs: *os.File.OutStream.Stream = &;
<Arghblarg> try fs.print("Printing from stdOut(): {}\n", "success");
<Arghblarg> .. however putting that into a function I am having difficulty. If one wraps those three os.File setup calls into a function which returns !*os.File.OutStream.Stream, the handle is invalid (I suspect the underlying 'f', or 'fos' go out of scope on return and so are invalid)
<Arghblarg> I basically want to make this a helper func rather than doing it inline within main(), something like
hio has joined #zig
<Arghblarg> var stdout = try getStdOut(); // !*os.File.OutStream.Stream
<Arghblarg> ... I tried doing the three setup vars as globals, but one can't call with 'try' outside of a func, so how do I get these vars to live beyond my setup func?
<Arghblarg> (BTW I know I don't have to specify explicit types everywhere but it helped me to see/understand what type I'm getting at each step)
<Arghblarg> Apologies if it's tough to see here in chat.. I should make a pastebin link to the demo program I suppose.
<hryx> pastebin link is probably preferable for readability, yeah
<Arghblarg> OK, here:
<Arghblarg> TL;DR 'stdout' set up inline within main() works, but 'stdout2' set up the same way within helper fn stdOut() does not.
<hryx> Arghblarg: this actually just came up today in an issue:
<hryx> this is unfortunately a slight design flaw that currently makes it easy to write something broken
<Arghblarg> ! Heh. OK, so I'm not (completely) crazy. Good to know. :)
<hryx> it's a subtle issue that I'm not super qualified to explain. But it is planned to be addressed:
<Arghblarg> Cool.
<hryx> welcome BTW :>
<Arghblarg> As a newbie I'd say this sort of stdin/stdout/stderr setup, is a very good candidate for the tutorials (once it's working reliably of course)
merlyndmg has quit [Quit: Leaving]
<Arghblarg> Love zig so far though, just from reading the lang spec and watching the designer's tuts online. So much promise, coming from a long-time C/embedded programmer I love the idea.
<Arghblarg> That reminds me I need to donate.
<ijneb> you may want to wait
<ijneb> If Andrew gets accepted for GitHub sponsors, they match your contribution afaik
<Arghblarg> Ah, that would be good
<hryx> or do Patreon until that's available!
<hryx> _porque no los dos_
<Arghblarg> Oh, cool OK didn't know he was on Patreon. Thanks
<Arghblarg> \o/ Official Patron!
<Arghblarg> Has anyone tried building the compiler from source? I also posted on the mailing list, strange issue...<>
<ijneb> Yeah, I compile from source
<Arghblarg> No idea why my stage1 compiler ended up as this huge thing.. it works, but haven't dug into the cause yet
<Arghblarg> Bleah, IRC is munging it I guess.
<ijneb> I don't see anything new in the mailing list
<hryx> stage1 comes out normal size for me. are you following the exact directions from the readme? what OS? llvm version is correct?
<ijneb> How big does yours come out to be?
<Arghblarg> 1.6GB
<Arghblarg> AFAIK I am following the exact directions.. I had to upgrade LLVM beforehand to v8 (?) and I'm on Funtoo x86_64 so perhaps that throws some wrenches into things.
<Arghblarg> (My post was "Stage 1 zig binary is 1.6GB", 11 days ago)
<ijneb> oh I did see that
<Arghblarg> Meh, not worth others wasting their time to diagnose unless I can reproduce it. I had to clean up my box a bit last week (it's back to LLVM 7 for now) so I'll try again sometime next week.
<ijneb> I'm not really sure what could've caused that
<ijneb> did you make sure to build llvm8 in release mode
<ijneb> with `-DCMAKE_BUILD_TYPE=Release`, not sure if it could make any difference
<Arghblarg> I didn't do that, no. I'll note that and try again to see what occurs. Thanks!
<ijneb> sounds good, np
<Arghblarg> Thanks all, g'nite
Arghblarg has left #zig [#zig]
Ichorio has joined #zig
Arghblarg has joined #zig
Arghblarg has quit [Quit: Page closed]
marijnfs has joined #zig
marijnfs has quit [Ping timeout: 244 seconds]
wilsonk|2 has joined #zig
_whitelogger has joined #zig
hio has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
scientes has joined #zig
wootehfoot has joined #zig
_whitelogger has joined #zig
fengb has joined #zig
<fengb> Should the compiler downcast error unions?
<fengb> error: incompatible types: '[]u8' and '@typeOf(std.mem.Allocator.alignedAlloc).ReturnType.ErrorSet![]align(4096) u8'
<fengb> The fix is simply changing `return alignedAlloc()` to `return try alignedAlloc()`, but it seems like the compiler could be smart enough to do that for me
<fengb> Or maybe we shouldn't return bare error unions at all? Glancing at that line, it's not obvious it can error out
<mikdusan> if you do that, then looking at the code no longer tells someone if there is an error to be handled
<fengb> Yep now I see that, but I could previously return the union because I was ignoring alignment
<andrewrk> fengb, that looks like a peer cast rather than an implicit cast
<andrewrk> anyway I do think that implicit cast should work, except the source type seems under-aligned, right?
<fengb> Hmm, it doesn't talk about error unions -- e.g. ![]u8 and ![]align(4096)u8
<andrewrk> you can't give []u8 when []align(4096) u8 is expected
<fengb> Opposite
<fengb> I was returning ![]align(4096) u8
<fengb> And the compiler didn't like it
<andrewrk> ah well you certainly can't give E!T where T is expected
<fengb> But it was fine if I wrapped it with a try
<andrewrk> oh I see the function has a possible error as well. yeah that should work
<andrewrk> idk if there's an issue open for that
<fengb> Okay, I can create one
<fengb> To mikdusan's point, I kinda dislike returning the bare error union since it's not quite clear the return can error
<fengb> So I'm happy with the workaround but maybe we can think about the semantics a bit
<andrewrk> sounds good
Zaab1t has joined #zig
fengb has quit [Ping timeout: 256 seconds]