<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>
var fos: os.File.OutStream = f.outStream();
<Arghblarg>
var fs: *os.File.OutStream.Stream = &fos.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 std.io.getStdOut() 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>
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>
Has anyone tried building the compiler from source? I also posted on the mailing list, strange issue... https://lists.sr.ht/~andrewrk/ziglang/%20<CAN4yCu-2zwCqFZskNtQaS-GLzG3%3D_pSnx+XT9AguqgtHaVaSww%40mail.gmail.com>
<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
<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]
Zaab1t has quit [Remote host closed the connection]
bugabinga has joined #zig
bugabinga has quit [Quit: WeeChat 2.4]
shawn_ has joined #zig
scientes has quit [Ping timeout: 246 seconds]
Flaminator has joined #zig
shawn_ is now known as scientes
Zaab1t has joined #zig
Zaab1t has quit [Remote host closed the connection]
marijnfs has joined #zig
Zaab1t has joined #zig
Zaab1t has quit [Remote host closed the connection]
gamester has joined #zig
<gamester>
I got bit by implicit cast from array to slice. I was supposed do this: std.mem.eql(u8, std.mem.toSlice(u8, arrayString1), std.mem.toSlice(u8, arrayString2)); I passed one array in without converting it to a slice.
<gamester>
toSliceConst rather, same thing though
<gamester>
I mean t std.mem.eql(u8, std.mem.toSlice(u8, &arrayString1), std.mem.toSlice(u8, &arrayString2))
<gamester>
marijnfs: toSlice will count the length of a zero-terminated string and return a slice for that string. An implicit cast from array to slice simply makes the slice the length of the array, even though the string inside the array is smaller
<gamester>
marijnfs: so std.mem.eql gave me false when it should have returned true
<marijnfs>
gamester: achso, yeah so thats useful to deal with cstrings?
<gamester>
yeah, toSlice and toSliceConst
mq32 has joined #zig
<gamester>
marijnfs: I see that there's also cstr.zig in the standard library. I could have used std.cstr.cmp(s1, s2)
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
<tgschultz>
weird that they're just in the mem namespace with no indication whatsoever that they're for dealing with null terminated arrays.
<andrewrk>
tgschultz, the types will serve that purpose after 265
<andrewrk>
but you're correct
<tgschultz>
andrewrk, if we're going with "decl" instead of "def" then I should update std.meta to match that terminology.
<andrewrk>
tgschultz, sounds good. I think "decl" makes sense since it applies to variables and constants
<tgschultz>
just so I'm sure we're on the same page: "decl" => namespaced constants, variables, function definitions, etc. and does not include struct instance fields?
<andrewrk>
correct
Ichorio has quit [Ping timeout: 252 seconds]
<tgschultz>
k, should be an easy PR, I'll put it on my to-do list.
<andrewrk>
thanks
<andrewrk>
I don't think my big wip branch touches std.meta
<emekankurumeh[m]>
can we please allow for inferred error sets to be empty?
Flaminator has left #zig [#zig]
<tgschultz>
andrewrk: typeInfo should also be updated, I'll see if I can manage that
<emekankurumeh[m]>
typeInfo is also wrong in some cases
<andrewrk>
emekankurumeh[m], I think that's probably a good change
<andrewrk>
I believe tgschultz would agree, yeah?
<tgschultz>
whole heartedly.
<tgschultz>
emekankurumeh[m] I haven't encountered any instances of TypeInfo being incorrect personally. Incomplete in some spots, but not wrong. Is there any issue?
<emekankurumeh[m]>
i was trying to do some meta-programming in zig to see if a function was exported or not in a struct/ see the calling convention but in the FnDef the calling convention was always unspecified and `is_export` and `is_extern` were always false, no matter what i did
wilsonk|2 has quit [Ping timeout: 258 seconds]
<tgschultz>
well that explains it, I've never inspected export, extern, or cc.
<marijnfs_>
dammit I was trying to integrate cudnn (deep learning library), which has a c interface, but seems like internally it wants to link to c++ stuff, std::string etc.
<andrewrk>
that can work
kristoff_it has joined #zig
<andrewrk>
the self hosted compiler build.zig might have some hints
<andrewrk>
this will be a common use case soon and should get easier as zig matures
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
<emekankurumeh[m]>
on an unrelated note calling meta.definitionInfo on a varargs function crashes the compiler
<andrewrk>
it's problematic that @typeInfo returns definitions. that might go away
<emekankurumeh[m]>
how so?
kristoff_it has quit [Ping timeout: 245 seconds]
<tgschultz>
yeah, I'm curous too.
fengb has joined #zig
kristoff_it has joined #zig
st4ll1 has joined #zig
kristoff_it has quit [Ping timeout: 250 seconds]
<marijnfs_>
what is a good way to deal with c functions that return statusses?
<marijnfs_>
E.g. i can't defer cudnnDestroy because it returns a value
<marijnfs_>
also using the c enums makes it an integer, which i can't compare to the actual returned value becuase it has the proper type
wootehfoot has quit [Read error: Connection reset by peer]
<scientes>
marijnfs_, what do you mean by a "statusss"
<scientes>
marijnfs_, you can get values in a defer, just use a block
<scientes>
defer { a = f(); }
<marijnfs_>
scientes: ah that would work
<marijnfs_>
well in this c-header there is a typedef enum named cudnnStatus_t, which functions return
<marijnfs_>
but if you would do an assert(somefunc() == c.CUDNN_STATUS_SUCCESS) it complains, saying the latter part is an int and can't be cast to a cudnnStatus_t
<hryx>
it builds fine, but running it on a test case results in an infinite recursive walk of the ast
<hryx>
I suspect it has to do with the values I'm setting in the returned TransResult in translate_c.zig -- I don't understand that struct super well yet
<andrewrk>
hryx, I think the c++ version has some detection of hitting the same function decl and avoiding analysing it again
<hryx>
oh sweet, good call
<andrewrk>
hmm, looks like that's already in the zig version
<andrewrk>
if (try c.decl_table.put(@ptrToInt(fn_decl), {})) |_| return; // Avoid processing this decl twice
<hryx>
shouldn't it not hit that in this case, since this is a local var decl, not a fn decl?
<hryx>
Ohh, I'm seeing something in the C++ one now. trans_scope_var_create()
<hryx>
I didn't create a new scope for the var decl. I assume that's needed?
<andrewrk>
that will probably be needed but I don't see why not having it would cause an infinite loop
<andrewrk>
your code looks fine to me at first glance
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 259 seconds]
<hoppetosse>
I've been following Bob Nystrom's crafting interpreter series in zig, finally caught up with the lessons