<marler8997_>
but, you don't want a function to have access to data that you don't pass to it
<marler8997_>
interpolated strings are a bit of a special case because you can see all the data you're passing to the function
<marler8997_>
yeah it can still create confusion
<marler8997_>
You could make @callerScope be readonly though
<marler8997_>
If any function you call could reach into your @callerScope and modify variables, that would make it a nightmare to understand code
<marler8997_>
Well, @outerScope sounds more like the outer scope, like the surrounding global scope, which you would already have access to
<marler8997_>
Maybe @callerScope would make more sense though
<marler8997_>
If you could implement that, then yes, you could create a function that implemented interpolated strings
<marler8997_>
Where is that?
<marler8997_>
How in the sam hell does @outerScope work?
<marler8997_>
@outerScope?
<marler8997_>
"this is a {a}" would become .{_0 = "this is a", _1 = a}
<marler8997_>
If I were to implement interpolated strings in Zig, I would treat interpolated strings as anonymous structs, the proposed replacement for varargs
<marler8997_>
I did a fair amount of work on it. D has "mixins" which enables a library solution by mixing in the interpolation logic into the caller, but Zig doesn't have that and probably shouldn't add support for it. This means that in order for Zig to support interpolated strings, it would need to add support in the language
<marler8997_>
but right now it's a hot topic for D since the new co-leader Atila mentioned it as one of his priorities in a recent article
<marler8997_>
I implemented string interpolation in the D language, thought it was never accepted
<marler8997_>
your first version works because you're explicitly passing all the arguments to the function that performance the string formatting, but the second version wont' have access to the variables/data in the interpolated expression
<marler8997_>
yeah, the problem with string interpolation is that you need access to the caller's scope
<marler8997_>
Is there a way to cause your build function to fail without printing a stacktrace?
2019-10-12
<marler8997_>
Yeah, wasn't expecting it to work, but it did
<marler8997_>
I can do this someFunc(&anotherFunc())
<marler8997_>
so, zig supports rvalue references then?
<daurnimator>
marler8997_: indeed. also seemed to take a few hours :(
<marler8997_>
I've had to restart my clang build 3 times because it keeps running out of memory
<marler8997_>
looks like 4G of ram just doesn't cut it these days if you want to compile LLVM/CLANG
2019-10-11
<marler8997_>
watching the update vid...looking at the docs I though you had added var as a return type :)
<marler8997_>
ok fair enough
<andrewrk>
marler8997_, I think that zig should not try to open a file until it is needed
<marler8997_>
if the path in --pkg-begin name path doesn't exist, should zig fail?
2019-10-10
<marler8997_>
thanks
<tgschultz>
marler8997_ see #3391
<marler8997_>
Hey, does zig document somewhere that the windows binary require VCRUNTIME140_1.dll?
2019-09-05
<marler8997_1>
will hasField be deprecated since you can get the same info from TypeInfo?
<marler8997_1>
I will try
<marler8997_1>
oh...
<andrewrk>
marler8997_1, I tested & pushed b564e7ca59818e4 which resolves the file descriptor limit problem (in most environments) when building musl
<andrewrk>
TheLemonMan, marler8997, ah yeah, bnoordhuis suggested something that can fix that, and I didn't understand it at first but now I do
<marler8997_1>
It sounds like he keeps the file descriptors open in order to lock them, probably to keep another external program from deleting them?
<Tetralux>
marler8997_1: Also yeah - that is a pretty neat thing about Zig
<marler8997_1>
crazy that I can download a 40 MB archive, extract it and cross-compile C code to so many different platforms
<marler8997_1>
it did fix it
<marler8997_1>
if this fixes it, would this warrant an issue? not sure how or if zig could handle this though
<marler8997_1>
ok will try
<marler8997_1>
trying to cross-compile hello.c to aarch64-linux-musl
<marler8997_1>
anybody every seen this error? Unable to hash /home/marler8997/git/zig/build/lib/zig/libc/musl/src/signal/sigaddset.c: file system error
<marler8997>
correct, but I was just clarifying that [N]T should be an error
<marler8997>
it's just returning an iterator/rang type struct of the argument
<marler8997>
right, so it sounds like it doesn't make sense inj this case
<marler8997>
and it will be up to the caller to understand how to call it correctly for their particular type
<marler8997>
I'm saying that the function will treat the value differently depending on the type
<marler8997>
[N]T, sounds like it should be an error
<marler8997>
*T pass back the pointer
<marler8997>
[*]T, pass back the pointer
<marler8997>
yes
<marler8997>
so depending on what type they pass in will determine where it lives
<marler8997>
it lives in the memory passed in by the caller
<marler8997>
what makes you think it needs to be non-const?
<marler8997>
it can be a const pointer
<marler8997>
not a value
<marler8997>
It only returns a pointer
<marler8997>
the generic function supports whatever makes sense
<marler8997>
The function returns the pointer to the array, but it sounds like that won't work for statically sized arrays, even though it may work with the optimization
<marler8997>
I'm trying to figure out how to properly handle fixed-size arrays in a generic function I'm writing
<marler8997>
The compiler makes the array const so I don't think you can modify it
<marler8997>
well...that actually doesn't sound right
<marler8997>
as I understand it, C functionally solves this by only allowing the optimization if the address isn't taken
<marler8997>
you gave me a definition but I have a feeling that's not the language definition, just the current LLVM implementation
<marler8997>
what's the definition?
<marler8997>
if it's defined, then whats the definition of taking the address of a statically sized array parameter?
<marler8997>
if I take the address, it could be taking the address of a value on the functions frame or the address of a variable passed in by the caller
<marler8997>
the lifetime is undefined
<marler8997>
I am surprised that taking the address of a statically sized array parameter is undefined
<marler8997>
I understand what undefined behavior is
<marler8997>
ok
<marler8997>
this sounds like an area where we need to work on the spec
<marler8997>
but I'm asking if I can rely on it
<marler8997>
It does the optimization
<marler8997>
I have written a program
<marler8997>
is that in the spec somewhere?
<marler8997>
but in theory, you shouldn't rely on it
<marler8997>
so in practive, the address would probably be valid because of the optimization
<marler8997>
interesting
<marler8997>
Tretralux: why not?
<marler8997>
hmmmm, does that mean I could take the address of it, and that address will still be valid when the function returns?
<marler8997>
not copied? so then then answer is no?
<marler8997>
the point of the question was, is the 100-length array passed by value like passing a struct by value?
<marler8997>
ok, assume a packed struct
<marler8997>
just to double check...passing an array (i.e. [100]u8) to a function would have the same runtime ABI as passing a struct with 100 u8 fields?
2019-09-04
<marler8997_1>
I suppose
<marler8997_1>
I should clarify that the "like" was sarcasm
<marler8997_1>
I like how python has both arrays an tuples, and the only real difference is that you can't modify tuples
<marler8997_1>
oh right...I've seen that one but haven't really groked it yet
<companion_cube>
marler8997_1: [x+2 for x in whatev if x>0]
<gonz_>
marler8997_1: List comprehensions, `for x in, where some condition holds for x, bla`
<marler8997_1>
comprehensions?
<marler8997_1>
what's some reasons for preferring python over lua?
<marler8997_1>
would love to see some resources comparing the two
<marler8997_1>
I'll have to spend some time with lua and see for myself
<marler8997_1>
sure but I think he was saying that's it's only strength over something like lua
<marler8997_1>
"the ecosystem"...reminds me of Apple products
<marler8997_1>
I would guess it doesn't have as many libraries
<marler8997_1>
should I be using lua instead of python for my scripting needs?
<marler8997_1>
yeah?
<marler8997_1>
lol
<marler8997_1>
ah....not anymore?
<marler8997_1>
python's simplicity makes for alot of libraries...it's got very low friction so you can get things done quick
<marler8997_1>
lua is pretty simple, I haven't done much coding in it but I would think it has pros/cons with python
<marler8997_1>
yeah like I say I think python has a place
<companion_cube>
marler8997_1: lua, erlang, have good scoping
<marler8997_1>
meh...functions have scopes. If you want a scope you can use a function
<marler8997_1>
I dont' think so...since it doesn't really have a compile-time type system to accomodate
<marler8997_1>
They give some examples and rationale for why you may want assignment expressions
<marler8997_1>
lol...I really like python for the space it operates in
<companion_cube>
marler8997_1: in terms of design, I'd tend to do the opposite of python, generally speaking
<marler8997_1>
it's what python does...so there's precedent
<marler8997_1>
yeah it sounded like gonz_ would be ok with that
<marler8997_1>
seems a bit silly at first but I like it...ship it :)
<marler8997_1>
at least, not using triple slash document comments :)
<marler8997_1>
that would be interesting...private fields are implemented by not documenting them :)
<marler8997_1>
you're saying private doesn't have to mean you can't use it
<marler8997_1>
oh wait
<marler8997_1>
fengb: ?
<fengb>
marler8997_1: public fields can be solved with documentation. Private doesn't have to imply hidden, just unstable
<marler8997_1>
you think so? private fields allow you to hide details about your type so that you can change them without breaking compatibility....seems like the same reason for private functions
<marler8997_1>
but what's the reason for private functions then?
<marler8997_1>
can't you do that with public functions as well?
<marler8997_1>
true, maybe we should remove private methods and const??? :)
<marler8997_1>
python doesn't have private fields either
<marler8997_1>
yes many people are satisfied with the status quo...if I was one of those people I wouldn't be using Zig
<gonz_>
marler8997_1: There are degrees to that. A lot of C programmers would argue you don't need that at all. Is it actually needed? Familiarity plays a part here.
<marler8997_1>
not being able to write generic re-usable code is
<marler8997_1>
sure, not having private fields would not be a deal breaker for me
<marler8997_1>
rather than bolt a new feature onto the language, it was able to extend existing semantics and achieve the same power as a template system
<marler8997_1>
perfect example is zig's generics vs templates
<marler8997_1>
In any case I think zig will eventually solve these problems one way or another...it's just a matter of when and how
<marler8997_1>
and some of the features I would have thought it needed it doesn't actually need anymore because it was able to solve the problem another way
<marler8997_1>
yeah Zig is taking the right approach of being careful about what features it integrates
<marler8997_1>
most cases you don't need or want auto, but when you start getting into meta-programming it really becomes necessary
<marler8997_1>
right
<gonz_>
marler8997_1: Yes, you can do many things with zig even though it has very few features. Let's keep it that way. :)
<marler8997_1>
good for generic functions that can return many kinds of types
<marler8997_1>
any type that is determined at compile-time
<marler8997_1>
I can do many things with Zig today? There just seemd to be a few holes that I'm hoping will be filled
<marler8997_1>
you think so?
<marler8997_1>
I think I've been very spoiled with D with it's meta-programming capabilities, Zig's just not quite there yet
<marler8997_1>
andrew just merged the @Type builtin so that helps alot
<marler8997_1>
like being able to set the return type to "var"
<stratact>
marler8997_1: I hope your new X library in Zig works out eventualy
<marler8997_1>
I like learning protocols like this and have starting creating a new X library for Zig...but have been finding that the language is missing things that is making it alot more difficult at the moment
<marler8997_1>
or you could use neither :)
<stratact>
marler8997_1: if I were writing a Window Manager, I'd probably got out of my way to use XCB
<marler8997_1>
fair enough, was just wondering as I've seen both and am curious what would make people choose one over another
<stratact>
marler8997_1: I chose it because there were plenty of examples of what I need to do written in it out there
<marler8997_1>
out of curiosity, what made you decide to use x11 instead of xcb?
<marler8997_1>
andrewrk: what do you think about the iterators branch I sent you? I think it demonstrates a couple use cases, of course this isn't exhaustive
<marler8997_1>
fine with me
<marler8997_1>
How would you get the Slice type with just the type? Not a variable with of the type
<marler8997_1>
of course, I think that's why we're discussing it correct?
<marler8997_1>
does that work with just the type as well?
<marler8997_1>
maybe...
<marler8997_1>
For example, say you have a generic type that accepts a pointer...maybe you want to write functions inside that type that take the slice variation of the pointer type
<marler8997_1>
In general, it's used in generic code to convert pointer types
<andrewrk>
marler8997, what is this function supposed to do? do you have an example use case?
<marler8997_1>
the *[]T or *[N]T cases seem confusing
<marler8997_1>
andrewrk: maybe for now the Slice function shouldn't support 'one size' pointers?
<andrewrk>
zig has @Type now thanks to marler8997. it only works for some types
<andrewrk>
marler8997, I'll take #3111 from here
<marler8997>
andrewrk: trying to address your comment about detecting changes in size/ptrlen enums...I'm thinking we could assert somewhere that the builtin Size values are what we expect...is there an init script somewhere I could do that in?
<marler8997>
thx, just found it :)
<andrewrk>
marler8997, have a look at ./zig build --help
<marler8997>
how do I run the compile_errors.zig test?
<andrewrk>
marler8997, nice work on the @Type builtin. I gave you a first round of review comments
<marler8997_1>
no problem, I saw you were doing alot of work in that area and figured this change would take a bit to get in
<marler8997_1>
Thanks for finishing the fix for the segfault issue, just built latest and now I can build my audio application again!
<marler8997_1>
Hmmm...I'll have to think on that one a bit...
<marler8997_1>
Are you're saying that my application shouldn't get to choose how to handle overflows when it is compiled with ReleaseFast? All overflow checking should be undefined in releaseFast no matter what?
<marler8997_1>
@intCast is undefined behavior in releaseFast correct?
<marler8997_1>
but I want well-defined behavior even with releaseFast
<marler8997_1>
of course, I'd like an API that allows both
<marler8997_1>
safety-checks to prevent undefined behavior
<marler8997_1>
I don't want any undefined behavior
<marler8997_1>
I'd like my application to fail on overflow with a well-defined error, rather than going into undefined behavior
<marler8997_1>
actually it looks like it does work
<marler8997_1>
wait...maybe...
<marler8997_1>
overflow isn't detected with releaseFast
<marler8997_1>
that has the same problem
<marler8997_1>
checking...
<marler8997_1>
if truncate supported conversion between signed and unsigned then it would be possible
<marler8997_1>
you're saying that's not possible?
<marler8997_1>
I want my code to detect overflow whether or not it is compiled with releaseFast
<marler8997_1>
but overflow isn't detected with intCast in releaseFast
<marler8997_1>
so how would I convert between signed/unsigned and make sure any overflow is detected in releaseFast?
<marler8997_1>
truncate doesn't seem to allow signed/unsigned conversion
2019-09-03
<marler8997_1>
so much to do with zig
<marler8997_1>
gotcha
<marler8997_1>
Do you think "-target" could be one of the default options in standardReleaseOptions at some point?
<marler8997_1>
So do you think the "-target" option will be added by default at some point?
<marler8997_1>
and it runs on my ARM asic!!!
<marler8997_1>
oh my gosh it is!!!!
<marler8997_1>
maybe it's calling qemu under the hood with some miscelaneous exec handler!
<marler8997_1>
hmmmmm, but the elf header says it's compiled for AARCH64....how in the heck is this working?
<marler8997_1>
because I can run it on my host machine :)
<marler8997_1>
This seems to be creating a native executable, not a cross-compiled one...? zig build-exe hello.zig -target aarch64v8-linux-gnueabihf
<andrewrk>
marler8997, yes, and there is a new option b.standardTargetOptions, which has a reasonable API, but it needs to be improved with how it surfaces the options to the CLI
<marler8997_1>
*that project's build script
<marler8997_1>
ok, so every target you're project supports needs to be configured in that targets build script
<andrewrk>
marler8997, no, any target configuration has to be exposed by the project's build script
<marler8997_1>
Am I supposed to be able to pass "-target ..." to "zig build"?
<kristoff_it>
marler8997: I think this is not yet possible. You can momentarily prepare a test in a separate file and check manually that it fails with the right error message. I think some way to do this more cleanly will be added in the future.
<marler8997>
is there a way to write a test that makes sure a peice of code fails to compile?
2019-08-30
<marler8997>
oh thanks for the clarification
<marler8997>
andrew made a comment about deprecating use/usingnamespace...is there an alternative that has been introduced or any info on how to write code without it?
2019-08-28
<andrewrk>
marler8997, yeah, I'll take it from here. Thanks for the patch and the nice regression test case
<marler8997_1>
yes please feel free to merge it with another branch and fix the issues...I just want the issue fixed :)
<marler8997_1>
I didn't see it
<FireFox317>
marler8997: This is what andrew said today, maybe you didnt see it: > unless you're in the middle of it, I'll merge your PR #3119 into a local branch and fix the issues
<marler8997_1>
andrewrk: hey when will you get a chance to look at https://github.com/ziglang/zig/pull/3119 ? It looks like recent changes have caused the issue to spread into other places into the code. I just don't want to keep re-working the change. If you can let me know when a good time is to work on it I'll re-work it to work with the code then
<andrewrk>
marler8997, unless you're in the middle of it, I'll merge your PR #3119 into a local branch and fix the issues
2019-08-27
<marler8997_1>
well since it's working now I don't need pkgconfig right now...so I'm going to hold off on implementing that until I find a need for it
<marler8997_1>
well I'm in a nix-shell so the CC environment variables are set...I didn't think zig would use them but it looks like it does
<marler8997_1>
not sure why
<marler8997_1>
looks like if I call "linkSystemLibrary("xcb")" it just works right now
<marler8997_1>
that's what meson does
<marler8997_1>
library name is enough
<andrewrk>
marler8997_1, would the api need to be improved? or is just the library name enough?
<marler8997_1>
cool I'll work on that
<marler8997_1>
yeah that interface makes sense
<andrewrk>
marler8997_1, I think that it would make sense to integrate pkg-config support with linkSystemLibrary
<marler8997_1>
pkgconfig provides a tool that you can use to query for libraries installed on the system. You can ask for C flags or library files for example. To tell pkgconfig about your package, you install a "*.pc" file with all the information about your package.
<marler8997_1>
let me know if you have a different design in mind and/or if you'd like me to make a PR for std
<marler8997_1>
It would just run pkg-config, parse it's output and call the corresponding funcitons on builder
<marler8997_1>
I'm going to add support for it in my project at least. I can work on a PR for the standard library as well if you like. I was just thinking of adding a function to the Builder object to add pkgconfig libraries
<marler8997_1>
I'd like to use a C library that is installed on the system and has a pkgconfig...zig's build system doesn't already support pkgconfig does it?
<marler8997>
trying to track down a segfaul in analyze.cpp, in the function "resolve_llvm_types_union" I'm getting a case where tag_type is NULL...anyone have any idea if that is valid and/or if it should be handled? Right now it's causing a segfault further down the callstack
2019-08-21
<marler8997>
Then you could say that HP uses Zig...lol
<marler8997>
I could try to sneak some code into our printers at HP :)
2019-08-20
<marler8997>
another idea is to add a "--c-args" where zig adds those arguments to any clang invocations
<marler8997>
And if I did implement that, I would probably just run the compiler before every command, enable a "dry-run" mode where it doesn't generate any output, and then re-invoke it with the command-line I got and any options I want to add
<marler8997>
I think that would work, but I dont' want to go implement it since I'm sure there's something simpler