<andrewrk>
curtisf, nice! that's an important abstraction
<andrewrk>
Aransentin, neat, I'm following the project now
<Aransentin>
Thanks! :) Ideally I'd want it to log stuff like DNS/HTTP/TLS SNI etc. and then dump a big pcap when something suspicious happens
<Aransentin>
I think it's pretty neat that with comptime I can have the program configuration as a zig file itself, and then streamline large parts of the program if the user doesn't need e.g. IPv6
<andrewrk>
:)
<curtisf>
Is there a way to compile a zig file (tests and all), but not actually run it, for the purpose of getting compiler errors? I've been thinking about hacking together something for the vscode plugin in advance of having a proper language server
<andrewrk>
curtisf, zig test foo.zig --test-cmd true
<andrewrk>
this calls /usr/bin/true instead of the test binary
<andrewrk>
to reference a function without calling it: comptime { _ = func; }
<andrewrk>
this will cause it to be analyzed
<andrewrk>
if it's not covered by a test
<curtisf>
perfect, thanks
<marler8997_1>
truncate doesn't seem to allow signed/unsigned conversion
<marler8997_1>
so how would I convert between signed/unsigned and make sure any overflow is detected in releaseFast?
<andrewrk>
@intCast is how you convert integers, preserving the mathematical numerical value
<marler8997_1>
but overflow isn't detected with intCast in releaseFast
<andrewrk>
release fast turns off overflow detection. that's what you're asking for. if you want safety on in a particular scope, however, use @setRuntimeSafety
<marler8997_1>
I want my code to detect overflow whether or not it is compiled with releaseFast
<andrewrk>
if you want to detect overflow globally, then you don't want release fast. you want release safe
<marler8997_1>
you're saying that's not possible?
<marler8997_1>
if truncate supported conversion between signed and unsigned then it would be possible
<andrewrk>
are you looking for std.math.cast?
<marler8997_1>
checking...
<marler8997_1>
that has the same problem
<marler8997_1>
overflow isn't detected with releaseFast
<marler8997_1>
wait...maybe...
<andrewrk>
are you talking about safety or not?
<marler8997_1>
actually it looks like it does work
<andrewrk>
ok but what are you trying to do? it's unclear whether "detect" means you want your application logic to use this information, or if you mean that you want safety checks to catch 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>
I don't want any undefined behavior
<andrewrk>
It's still not clear. Are you looking to introduce safety-checks, to prevent undefined behavior, or are you looking to actually handle overflow as a possible logical path of your application?
<marler8997_1>
safety-checks to prevent undefined behavior
<marler8997_1>
of course, I'd like an API that allows both
<marler8997_1>
but I want well-defined behavior even with releaseFast
<marler8997_1>
@intCast is undefined behavior in releaseFast correct?
<andrewrk>
that's not how release-fast is defined
<andrewrk>
however you can selectively choose a different mode with @setRuntimeSafety on a per-scope basis
<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?
<andrewrk>
I'm just telling you what release-safe does, and what release-fast does, and you're choosing which one to use
ntgg has joined #zig
<marler8997_1>
Hmmm...I'll have to think on that one a bit...
return0e_ has joined #zig
<marler8997_1>
Thanks for finishing the fix for the segfault issue, just built latest and now I can build my audio application again!
return0e has quit [Ping timeout: 245 seconds]
<andrewrk>
glad to hear it, sorry for the delay in fixing it
<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
mikdusan1 has joined #zig
mikdusan has quit [Ping timeout: 245 seconds]
<ntgg>
I want to have a function defined only if the arch is wasm, how would I do that?
<andrewrk>
when you say defined, do you mean exported?
knebulae has quit [Read error: Connection reset by peer]
<andrewrk>
marler8997, nice work on the @Type builtin. I gave you a first round of review comments
ntgg has quit [Ping timeout: 258 seconds]
shritesh has joined #zig
knebulae has joined #zig
<shritesh>
I think the talk went good today. Most people (almost everyone an EE) loved the built in testing and cross compilation. I think we need to provide linker scripts for well known boards/architectures/embedded devices (maybe after the package manager). The videos is up at https://www.youtube.com/watch?v=LlaNges4yt8
<andrewrk>
shritesh, nice!
<curtisf>
is there any possible way to coerce zig into output a range for an error and not a single column?
<andrewrk>
curtisf, stage2 does that
<andrewrk>
stage1 doesn't have the capability currently
<curtisf>
ah, okay
shritesh has quit [Quit: Leaving...]
stratact has joined #zig
<stratact>
How does one specify the dynamic linker in build.zig
laaron- has quit [Remote host closed the connection]
<andrewrk>
stratact, that option is not wired up yet
<andrewrk>
that's a contributor friendly issue if you want to have a shot at it. Otherwise I can have that for you tomorrow
laaron has joined #zig
<stratact>
andrewrk: I would love to help however I'm still too new for doing any real contributing upstream. There is also the possibility that option might not be what I'm looking for to solve a problem I'm facing. I would like to some advice or help with my problem if you can spare some time?
<andrewrk>
yeah, sure, what's your use case?
<stratact>
I'm trying to call a function from the X11/Xlib library which is causing my zig program to segfault
<stratact>
I want to get the list of Window IDs from the list of _NET_CLIENT_LIST windows from my X11 instance
<stratact>
Should I show you a paste of the main.zig?
<stratact>
It's a small program, it's all there is.
<andrewrk>
sure. what does this have to do with a dynamic linker?
<andrewrk>
stratact, ahh, on freebsd we don't have segfault handlers set up yet. the next step here will be to run your application with a debugger
<andrewrk>
for example: gdb /usr/home/stratact/Projects/Zig/window_list/zig-cache/o/KIE_hb777bYIRBHVw48sj38zA4bf5mBg7eirkvMGvQufEQpXTLnFggtuSE6ikn5Q/window_list
<andrewrk>
(gdb) run
<andrewrk>
gdb will catch the segfault, and then you can use `bt` to look at a stack trace
<stratact>
andrewrk: I suppose I'll try this on a Linux system (and probably migrate back to one). GDB doesn't seem to be as friendly on FreeBSD, especially since I can't step into that function before it segfaults
<stratact>
It seems to jump into some linker magic right before calling that function
<daurnimator>
stratact: btw, use `const` where you can instead of `var` :)
<andrewrk>
main.zig:14 there's where the segfault is happening
<andrewrk>
so that's the XGetWindowProperty call. notice it's happening inside XGetWindowProperty ()
<daurnimator>
stratact: you need to pass pointers to XGetWindowProperty, not undefined integers :P
<andrewrk>
which means you probably passed some invalid memory (perhaps null or undefined?) to the function
<daurnimator>
`int XGetWindowProperty(Display *display, Window w, Atom property, long long_offset, long long_length, Bool delete, Atom req_type, Atom *actual_type_return, int *actual_format_return, unsigned long *nitems_return, unsigned long *bytes_after_return, unsigned char **prop_return)`
<andrewrk>
daurnimator, oh, there's an issue for not allowing implicit casts of integers to C pointers
<stratact>
daurnimator: I've tried passing both pointers to the values and the values themselves and I got the same results
<daurnimator>
stratact: so you need to do e.g. `&atomType, &form, &len, &remain, &list);` instead
<daurnimator>
infact `list` there should be an array of chars, you currently just have a single char
<stratact>
daurnimator: hahaha, you're suggestion helped, thanks. :) Well `list` needed to be [*c][*c]u8 according to the zig compiler, so I changed list from `u8` to `[*][*]u8` and did @ptrCast([*c][*c]u8, list)` for the last argument.
<andrewrk>
you never need to explicitly cast anything to a C pointer
<daurnimator>
andrewrk: I just tried locally to do it. ` error: expected type '[*c][*c]u8', found '**u8'`
<andrewrk>
does it have a hint?
<daurnimator>
`note: pointer type child '*u8' cannot cast into pointer type child '[*c]u8'` `note: mutable '[*c]u8' allows illegal null values stored to type '*u8'`
<daurnimator>
stratact: btw, isn't new code meant to use XCB rather than xlib?
<stratact>
daurnimator: Thank you for the redone code, I appreciate it. Regarding XCB and Xlib, I'm not doing anything sophistated like making a new Window Manager. I'm trying to get info from the xserver to feed into a FVWM module
<stratact>
I dunno if XCB has the capability to get Window IDs?
<shachaf>
daurnimator: Aren't you still required to use Xlib for anything that uses GLX?
<daurnimator>
stratact: you can probably just make it a `?[*]xlib.Window` in the first place.
<daurnimator>
stratact: also I would create a slice with the result: `const windows = (list orelse return error.WindowNotAvailable)[0..len];`
<stratact>
daurnimator: gotcha, thanks
<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?
<nitram91>
andrewrk how many assumptions can the elf module make ? For example if it's being compiled for a 64bit, little endian target, can the we assume we will only be opening 64bit little endian elf files ?
<nitram91>
stacktraces would still work that way and the code would be much cleaner
<nitram91>
pretty much the endianess and the architecture would be known at compile time
<mq32>
nitram91, for what is the module?
<mq32>
use in the zig compiler? generic purpose ELF parser?
<nitram91>
module was the wrong word
<nitram91>
I mean the Elf object in the standard library (std/elf.zig)
<nitram91>
afaik it's used for the stack traces
<mq32>
i don't think its reasonable to compile it so it only can speak elf partially
<mq32>
you would have to create another ELF parser thing as soon as you want to use it for *more* stuff than just stack tracing
<nitram91>
well it can speak elf properly, but only for the architecture it was compiled for, if you compile it for some other architecture, it will be able to speak that one
<nitram91>
yeah, that's the issue
huuskes has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
kristoff_it has joined #zig
ovalseven8 has joined #zig
<ovalseven8>
Question: Why did Zig decide not to be memory-safe like Rust?
<nitram91>
mq32 and it's a weird use case when you compile for X architecture with Y endianess but you try to work with elf files of a different endianess/architecture
<mq32>
ovalseven8: mostly because it requires "hidden control flow" and that's a no-go in zig
<mq32>
nitram91: why that?
<mq32>
imagine you compile objdump for x86_64, but want to dump a PPC-ELF file ;)
<nitram91>
linkers aren't that weird use case, dynamic linkers aren't that weird use case, debuggers aren't that weird use case
<mq32>
and as i'm doign a lot of embedded coding, most of my stuff is working with foreign-platform elf files
laaron has quit [Remote host closed the connection]
<ovalseven8>
mq32, I am too much a newbie to understand language design but memory bugs are so common in kernels that I think it's worth it fixing this bug class
<nitram91>
yeah but for example, a debugger will be compiled for each architecture it's needed (gdb-x86_64, gdb-mips, gdb-arm, etc...)
laaron has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<mq32>
nitram91, yes, but it nots for the target platform
laaron has quit [Remote host closed the connection]
<mq32>
which means: my debugger is compiled for x86_64, but debugs ARMv7 code
<mq32>
(both are little endian in this example, but i could also work on PPC for example)
<nitram91>
don't you have a separate toolchain ?
<mq32>
i use clang
<mq32>
so: no :D
<nitram91>
ow nice
<mq32>
ovalseven8: It's not *that* easy to actually prevent memory bugs. Rust makes it harder to do memory bugs, but it does make it harder in general to write code at all (imho)
laaron has joined #zig
<nitram91>
definitely harder, and to do some of the kernel stuff you will need unsafe memory, which will break the point of rust
<ovalseven8>
mq32, Another question: Kotlin has null-safety through types like "String" and "String?" with compile-time checks for null. Why does Zig not use this approach?
<mq32>
it does
<mq32>
zig pointers cannot be "NULL"
<mq32>
(except for allownull pointers, but that's a special case)
<mq32>
and nitram91: your question was still: compile for platform X and load elf for platform Y
<mq32>
and that's the purpose of cross-tools
<nitram91>
yes, what I meant is that for example if I compile my dynamic linker to load 64bit LE librairies, I don't expect it to load another architecture
<mq32>
yeah that's true
<nitram91>
and making that assumption would've allowed the Elf library to use mmap
<nitram91>
instead of streams/readers
<nitram91>
and be much much more efficient
<nitram91>
and elegent
<mq32>
but for general purpose you should not do that
<mq32>
you can do both, actually :D
<nitram91>
???
<nitram91>
how ?
<mq32>
two code paths
<mq32>
but it's not that elegant
<nitram91>
(I'm not gonna like I'm a bit narrow minded as my use case for zig so far is only writing a dynamic linker)
<nitram91>
yeah but you would choose the path at compile time ? either compile super cross-platform code but slower or not cross-platform code but faster
<mq32>
yes, that's true
<mq32>
it would be a neat option to have
<mq32>
"fast, but restricted to my platform" vs. "generic, but a tad slower"
<samtebbs>
Has anyone ever explored the possibility of customising the style used by zig fmt
<fengb>
No customizations
<samtebbs>
fengb: How come?
<Aransentin>
I kinda like that all zig code looks the same. That way formatting never gets in the way when reading other peoples code.
<fengb>
Same reason as go fmt. When it’s one standard, nobody is happy. Thus everyone is happy
<companion_cube>
I feel like samtebbs wants tabs
<samtebbs>
companion_cube: Haha that used to be my nickname at uni. I've seen the light since then though
<companion_cube>
yep, it's my nick :p
<samtebbs>
I'm not a fan of some aspects of the style, such as commas after every struct member
<companion_cube>
trailing commas ♥
<fengb>
Options split the community and lead to formatting wars
<fengb>
I hated go format for about a week
<fengb>
Like straight up almost quit the language
<gonz_>
Giving people the opportunity for personal style is a massive mistake, yes.
<fengb>
But... everybody’s code looks the same and there’s no style dispute anywhere in the ecosystem
<gonz_>
A needless one that doesn't need exploration.
<samtebbs>
trailing commas don't make sense to me #changemymind
<fengb>
And I’ve probably wasted hundreds of hours on formatting by now so I’m happy to never worry about it
<companion_cube>
they make edition easier and are more uniform
<gonz_>
samtebbs: One common but IMO weak argument is slightly nicer git diffs.
lucus16 has joined #zig
<companion_cube>
I always use terminators rather than separators, if the language allows it
<fengb>
I kinda want a different struct field definition. It looks really weird starting with identifier and ending with a comma
<gonz_>
The point isn't to like the formatting anyway, it's to accept it and move on to more important things.
<companion_cube>
(but then I'd want the syntax to be more rust like, so…)
<fengb>
I can’t read Rust for the life of me
<samtebbs>
gonz_: I don't agree. Formatting is important when it comes to reading code, which you have to do a lot of when fixing bugs
<gonz_>
Rust can get pretty noisy in the worst case. There was a particularly offensive type signature someone pasted from Facebook's HHVM parser.
<fengb>
Formatting is irrelevant if it’s good enough and consistent
<gonz_>
samtebbs: This is offset entirely by the uniformity of the chosen formatting regardless of whether or not someone likes it.
<fengb>
It may not be perfect in your eyes, but it’s something I don’t have to convince you anymore
<fengb>
Cause we’re already fighting over trailing commas, we clearly don’t agree
<gonz_>
And let's be real; it's not usually a question of readability, it's a question of personal minor preference.
<fengb>
Auto formatter is the great normalizer
<fengb>
I don’t agree with all of zig’s formatting decisions, but I’m much happier having them already made
<samtebbs>
That's true. As long as the standard style isn't absurd (which zig's isn't) then one can get used to it
<gonz_>
I feel exactly the same way. I'd rather it always wrapped at something like 100 width or whatever as well, but I also would never suggest that it conditionally does with some flag, because each step of configuration is just needless differences in code bases.
<samtebbs>
I can't say the same for the GCC style though...
<Snektron>
i was just about to say that
<Snektron>
every time i see anything made by gnu, i almost have to cry
<Snektron>
the libstdc++ headers top it all off though
<Snektron>
indentation is literally random
<samtebbs>
I feel ya :p I had to suffer it for the first six months of my internship
<samtebbs>
So I'm trying to agree upon a code style for a project with a friend and one current idea is to just go with what's mandated by zig fmt as some common ground
<samtebbs>
and to be standardised with the rest of the community
<fengb>
The real reason HURD was never ready: code formatting
<Snektron>
the one thing i really disagree about with most standardized formatters is aligning values
<Snektron>
the rest i cant care about
<andrewrk>
marler8997, I'll take #3111 from here
<samtebbs>
gonz_: That's a good point when it comes to git diffs
<fengb>
I actually liked Go's alignment :(
<gonz_>
samtebbs: I dunno, I think it's weaker than people make it out to be, but it *is* a point. The copy-ability of a line is also a minor point in favor of it.
<Snektron>
am i right when saying that stdcallcc is the standard c calling convention?
<Snektron>
or should i export with 'extern' instead?
<samtebbs>
Snektron: Isn't it architecture-dependent?
<samtebbs>
e.g. it's the aapcs for Arm
<Snektron>
Just need the standard calling convetion for c on the target platform
<companion_cube>
gonz_: the noise is more because of extreme genericity
<companion_cube>
the expression syntax is, imho, almost perfect
<gonz_>
companion_cube: In part I think the most offensive examples are a combination of bad choices on the part of the writer and also a lot of mini tokens being chosen.
<gonz_>
In all of this, with some reflection, you become acutely aware of how good a choice `dyn` as a token was in comparison to all the rest of the mini tokens in that type signature.
<Snektron>
naming isn't really helping there either. 'x' and 'NS' aren't really descriptive
<gonz_>
Snektron: That's what I meant by some of the fault being the writer, yeah.
<companion_cube>
but the body is pretty cool, look at the match
<Snektron>
At least its not lisp made with c++ templates
<companion_cube>
I really mean the expression syntax (including mandatory braces, let, match, blocks returning values…)
<gonz_>
I really don't mind Rust syntax on the whole and it certainly would never be something I would cite as a reason for not using the language.
<companion_cube>
I think zig could learn from it ;)
<gonz_>
I have a few syntax preferences and they're about as far as you can come from zig, but zig is probably my favorite language at the moment.
<Snektron>
I get frustrated by not being allowed to do pointer hacks
<companion_cube>
in zig?
<Snektron>
in rust
FireFox317 has joined #zig
<samtebbs>
Snektron: hence Zig ;)
<companion_cube>
Snektron: hmm, you can?! just use unsafe
<FireFox317>
andrewrk: Regarding #2867 and the comment you made, could you explain a bit more what the ambiguity is and what the compile error should be?
<Snektron>
companion_cube: i'm aware
<Snektron>
i feel more like i'm being imposed to write in a certain way due to the whole safety thing
<Snektron>
suddently you have to copy or allocate data to keep it safe
<andrewrk>
FireFox317, yes, I'm saying that enum literals should only implicit cast to the *payload* of error unions, not to the error set
<andrewrk>
FireFox317, const T = enum { Foo } | error{ Foo}; var x: T = .Foo; // ambiguity
waleee-cl has joined #zig
<andrewrk>
FireFox317, const T = error{Foo}!enum{Foo}; var x: T = .Foo; // ambiguity (fixed)
<shritesh>
fengb, If it helps "lifetimes are just types on a different (temporal) axis". It clicked for me once it was explained as such. But I do agree there's a TON of visual noise there.
<fengb>
I should sit down and learn Rust. My last attempt ended in failure
<andrewrk>
I think I can actually read this
<andrewrk>
the actual logic is pretty straigthforward, although I don't know what &*next does
<shritesh>
I worked with Rust for a year. But interfacing with c functions (callbacks) was a major pain.
<companion_cube>
andrewrk: &*next typically derefs (a smart pointer) and re-takes a reference
<andrewrk>
companion_cube, what does that accomplish?
<companion_cube>
if you have a Box<T>, you can get a &T locally
<companion_cube>
which might be what a lot of your functions take
<andrewrk>
hmm ok
<companion_cube>
(also works for String -> &str, Vec<T> -> &[T], etc.)
<FireFox317>
andrewrk, So if I understand correctly the last example (ambiguity (fixed)) should be a compile error, because it is not clear whether it should implicitly cast to the error or the enum?
<andrewrk>
FireFox317, I'm using this as an example, to justify a language-wide rule, that enum literals do not ever cast to error sets (and transitively to error unions)
<andrewrk>
I believe your PR is good, it just does *too much*, implementing this extra thing that I don't want to be implemented
<Snektron>
Otherwise i can't see enum literals casting into E!T ever causing an ambiguity error
<andrewrk>
Snektron, no that's not supposed to work either
<andrewrk>
how would you resolve the code example I gave above?
<Snektron>
And enum{A} | error{B} doesn't work either right?
<andrewrk>
FireFox317, to be clear: enum literals should cast to error unions, but only to the payload type, not the error set type
<andrewrk>
Snektron, that was a typo. the next line has a fixed example
<Snektron>
var x: T = error.Foo; and var x: T = .Foo;
<FireFox317>
Yeah i think I got it. In that example you gave, it should work and implicitly cast to the enum (payload) and as you said never to the error set type.
<Snektron>
Is there even a way to transform an error set into an enum?
<andrewrk>
FireFox317, yeah
<andrewrk>
Snektron, that's how I'm saying it should work. we're on the same page
Aransentin has quit [Remote host closed the connection]
<Snektron>
oh right, i see what you mean
<Snektron>
I'm not sure exactly how PT_TLS and HWCAPS relate
<andrewrk>
the TLS program header is generated by zig's linker. It won't have one if there are no thread local variables
<Snektron>
Ah
<Snektron>
the HWCAPS is not what the program is compiled with, but like i suspected, what the CPU has
FireFox317 has joined #zig
<Snektron>
So that condition is checking if the linux kernel exposes tls hwcaps, regardless of wether the program wants to use it
fraktor has joined #zig
<Snektron>
sure, i'll move it below there
<fraktor>
I'm trying to compile Zig on Debian Testing, and I'm getting the following error: unable to find llvm-config
<Snektron>
install llvm
<fraktor>
Done
<fraktor>
Oh wait, apt is just dumb about what is was showing before
<fraktor>
I feel stupid
<andrewrk>
Snektron, I think beyond a certain linux version it's guaranteed to have HWCAPS. And our min kernel version supported is 3.16. So I don't think that check needs to be there
<Snektron>
done
kristoff_it has quit [Ping timeout: 245 seconds]
<Snektron>
On a side note, isn't there always going to be a TLS section as long as extern thread_local is allowed?
<andrewrk>
only if you use it
<Snektron>
Oh, llvm's doing i suppose
<andrewrk>
it makes sense, one should not have to pay the cost of an unused feature
<Snektron>
i agree, but now its not the same as builtin.is_single_threaded right
<andrewrk>
right
<andrewrk>
there is a sort of missing feature here, which is having a comptime constant that tells whether TLS will be used. unfortunately the decision of whether we need to set up TLS happens at runtime, even though we should know after linking whether we need TLS
<andrewrk>
which means that the code for setting up TLS exists in the binary, even though it will never be called
<andrewrk>
it's not impossible to solve, but it is tricky, considering it would require interacting with the linker in an advanced way
<andrewrk>
a large cost in implementation complexity with a small reward
<Snektron>
that or have a guarantee tls is not needed before linking, which is what you were proposing earlier
<andrewrk>
oh yeah. that would be much more reasonable
FireFox317 has quit [Ping timeout: 258 seconds]
fraktor has quit [Ping timeout: 246 seconds]
qazo has joined #zig
<andrewrk>
thanks to FireFox317, enum literals now work with ?T and E!T types
THFKA4 has joined #zig
marmotini_ has joined #zig
Ichorio has joined #zig
wilsonk__ has joined #zig
wilsonk has quit [Ping timeout: 258 seconds]
<Tetralux>
andrewrk: .. where T is an enum?
<andrewrk>
or a tagged union with a void field type for that tag value
<Tetralux>
So for a return type of ?T, where T is enum, you may `return .SomeEnumValue` and it'll work now?
<bgiannan>
Can i serialize a slice with io.Serializer?
<bgiannan>
namely a []u8
<bgiannan>
reading io.zig it seems serialize will serialize each element of an iterable, but how do i deserialize it? since i don't know the length of it then
<bgiannan>
i could just put manually the length before it i guess
Hirezias has joined #zig
Hirezias has quit [Ping timeout: 252 seconds]
Hirezias has joined #zig
<andrewrk>
Snektron, you've pushed Zig from Tier 3 to Tier 2 arm32 support :)
<andrewrk>
on linux, at least
<andrewrk>
I don't think ARM macOS is a thing, I'm going to mark that as N/A
Hirezias has quit [Ping timeout: 245 seconds]
mahmudov has joined #zig
bastienleonard has joined #zig
shritesh has joined #zig
<fengb>
Watch Apple announce their next Macbook :P
<shritesh>
Has anyone tried running zig on iOS?
<companion_cube>
book apple annouce their next macwatch
bastienleonard has quit [Ping timeout: 264 seconds]
<fengb>
You can't compile an iOS executable without Xcode so it's probably a non-starter
<fengb>
Although... RubyMotion somehow leverages Xcode to compile Ruby down. I wonder how they do it
<andrewrk>
marler8997, what is this function supposed to do? do you have an example use case?
<marler8997_1>
In general, it's used in generic code to convert pointer types
<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
<andrewrk>
isn't this just @typeOf(x[0..]) and @typeOf(x.ptr)?
<marler8997_1>
maybe...
<marler8997_1>
does that work with just the type as well?
<andrewrk>
if the purpose isn't clear, std lib is not the right place for it, just leave it in your project
<marler8997_1>
of course, I think that's why we're discussing it correct?
<marler8997_1>
How would you get the Slice type with just the type? Not a variable with of the type
<andrewrk>
I don't think Slice and ArrayPointer are good names for this, the name isn't descriptive enough
<marler8997_1>
fine with me
<stratact>
If I want to return a pointer from within a function, which allocator should I use?
<stratact>
Just want to "box" it, so I can send it out without having it dangling
<Tetralux>
You should pass an allocator to the function and use it to allocate memory.
<Tetralux>
That's the general advice.
<Tetralux>
The idea being that the allocation is explicit to the caller.
<Tetralux>
Oh - sorry - read that wrong.
<Tetralux>
_Which_ one.
<Tetralux>
You mean, "which one from the stdlib?" or just which one in general?
<stratact>
the former I believe
<stratact>
I'm not writing a library, it's a small app
<Tetralux>
Basically, it depends on how you're using the value and how often you're doing it.
<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
<Tetralux>
If you're doing it all the time, or if it's just one thing, I'd consider you pass in a pointer to the function which writes the result and then returns bool or something to say that it did it.
<Tetralux>
But for something more quick and dirty, ArenaAllocator will do.
<Tetralux>
If you want to put a little more time in, then figuring out a way to use a FixedBufferAllocator could be handy for something like that too though.
<Tetralux>
Especially if it's being done in a loop.
<Tetralux>
Like, "every frame, do this thing and give me an answer".
<Tetralux>
Though, I'd have to see the code to know if you even need to allocate.
<Tetralux>
Returning a struct instance may well be a better idea.
<stratact>
I'll share you a paste of my code
* Tetralux
realises I just kinda word-saladed there
<Tetralux>
*grins* That would probably help
<stratact>
I think passing a pointer to the function would be probably be the best solution for me though but here is the function http://dpaste.com/0RK381G
<Tetralux>
What's the pointer you were wanting to return?
<stratact>
`propertyValue`
<stratact>
typed `?[*]u8`
<fengb>
It's a double pointer?
<Tetralux>
I actually think you're doing it right already: just return it, since it gets set the thing you want by XGetWindowProperty, I imagine.
<Tetralux>
So it's just a value - just as if it was a usize or w/e.
<Tetralux>
I'm not sure what memory XGetWindowProperty sets it to point to though...
<Tetralux>
It doesn't take an allocator, so I'm not sure where the memory's coming from.
<stratact>
It's part of the X11 C library, so I dunno :)
* Tetralux
shrugs.
<Tetralux>
Anyhow, point being, it effectively returns to you a pointer to the property's value - I assume - and so you can just return that straight-up from your function.
<Tetralux>
Or
Akuli has quit [Quit: Leaving]
<Tetralux>
If you know what kind of thing it points to, maybe think of a way to cast it to *PropertyValueType
<Tetralux>
etc.
<stratact>
I gotcha, thanks for the advice Tetralux
<Tetralux>
o7
<Tetralux>
Is xlib just an alias to c.x11 or something?
<Tetralux>
I'm curious to look at the source for that function.
Hirezias has joined #zig
<stratact>
`xlib` is this: const xlib = @cImport(@cInclude("X11/Xlib.h"));
<Tetralux>
Okay, gotcha.
<Tetralux>
I'll fish for a sec and see if I can find it.
<stratact>
Awesome, much appreciated
<Tetralux>
Yeah - I think it calls malloc or something.
<Tetralux>
It mentions "To free the resulting data, use XFree"
<stratact>
Ah I see
<Tetralux>
There might be a XAlloc or something that it does though.
<Tetralux>
Though this is C, so it prob mallocs in the end xD
<stratact>
So no need for an allocator :)
* Tetralux
sighs xD
<Tetralux>
It's kinda wierd you can't ask it for how much space you need to store the value, and then give it a buffer for it to write into...
<marler8997_1>
out of curiosity, what made you decide to use x11 instead of xcb?
<fengb>
It's the C style :P
<fengb>
How does memory management work? rtfm!
<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>
fair enough, was just wondering as I've seen both and am curious what would make people choose one over another
<stratact>
marler8997_1: if I were writing a Window Manager, I'd probably got out of my way to use XCB
shritesh has joined #zig
<marler8997_1>
or you could use neither :)
<stratact>
hehe
<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
<Tetralux>
FYI, XGetWindowProperty; the pointer it sets is basically just a slice of bytes; the length being `remain` in your code.
<Tetralux>
So you could do `return propertyValue[0..remain]` IIUC.
guan has joined #zig
<Tetralux>
The data is formatted into either a slice of u8, u16, or u32, as indicated by `form`.
<Tetralux>
But I'm guessing it's just a string?
<Tetralux>
Depending on what you then do with this information, it's probably simplest to indeed, just return a slice.
<Tetralux>
Esp since you literally have the length information.
<Tetralux>
And you can just pass slice.ptr to XFree when you're done with it.
<stratact>
Tetralux: Awesome, I'll give that a shot
<stratact>
marler8997_1: I hope your new X library in Zig works out eventualy
<marler8997_1>
like being able to set the return type to "var"
<marler8997_1>
andrew just merged the @Type builtin so that helps alot
<marler8997_1>
I think I've been very spoiled with D with it's meta-programming capabilities, Zig's just not quite there yet
<gonz_>
You might simply be asking for a *different* language, rather than a zig down the road.
<marler8997_1>
you think so?
<gonz_>
Lots of people are, more or less. Some ask for C++, some ask for Rust, some ask for D, etc.
<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
<Snektron>
What would return type var do
<Snektron>
Return a value of any type?
<marler8997_1>
any type that is determined at compile-time
<marler8997_1>
good for generic functions that can return many kinds of types
<gonz_>
marler8997_1: Yes, you can do many things with zig even though it has very few features. Let's keep it that way. :)
<Snektron>
Ah, you want auto
<marler8997_1>
right
<marler8997_1>
most cases you don't need or want auto, but when you start getting into meta-programming it really becomes necessary
<Snektron>
gonz_: gotta find a fine line between go and c++
ntgg has joined #zig
<marler8997_1>
yeah Zig is taking the right approach of being careful about what features it integrates
<Snektron>
But you can always hack around it at the moment
<Snektron>
Return a type with a member
<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>
In any case I think zig will eventually solve these problems one way or another...it's just a matter of when and how
<gonz_>
That seems like the general case (about solving it *another way*)
<marler8997_1>
perfect example is zig's generics vs templates
<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
<gonz_>
Many "things that need solving" are not actually things that need solving as well.
<gonz_>
You never actually need private fields, for example.
<marler8997_1>
sure, not having private fields would not be a deal breaker for me
<gonz_>
Yet some people feel that's something you do need for familiarity.
<marler8997_1>
not being able to write generic re-usable code is
<fengb>
Go squeaks by with even worse generics >_>
<companion_cube>
gonz_: not for familiarity, for safety
casaca has quit [Ping timeout: 245 seconds]
<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.
<gonz_>
companion_cube: It really doesn't do much for safety.
<companion_cube>
"needed" is a bit meaningless, everyone will say "what I have is enough"
<companion_cube>
gonz_: well it helps not shooting yourself in the foot
<companion_cube>
by using something meant to not be used directly
<marler8997_1>
yes many people are satisfied with the status quo...if I was one of those people I wouldn't be using Zig
<companion_cube>
Go might become usable if they implement their generics proposal
<gonz_>
companion_cube: There are obvious ways of accomplishing that. They don't require private fields. Tons of features help you not shoot yourself in the foot, yet they're not present in Zig. I think that's for the most part fine.
<companion_cube>
you mean @opaque ?
<gonz_>
No.
<gonz_>
You don't need any new feature at all to not modify "private" fields.
<companion_cube>
I mean if you define a type and don't want users to fiddle with its internals
<fengb>
I've had more problems working around "private" bugs than private actually helping out
<gonz_>
And maybe if someone does, let's treat them like an adult?
<gonz_>
Play stupid games, win stupid prizes
<companion_cube>
so why have types at all?
<gonz_>
Are you actually equating types with private fields in terms of importance?
<fengb>
And Go is fine. It's not ideal and lack of generics sucks but it's pretty usable in general
<companion_cube>
gonz_: I mean that it serves the same purpose: make APIs that are more robust and less error prone
<gonz_>
Put an underscore or two before a field name, leave a comment that people shouldn't mess with it. If they do, tell them they're probably messing it up.
<companion_cube>
I'd be using C++ if I trusted myself with never making mistakes
<gonz_>
This isn't some big issue.
<gonz_>
"More robust". When was the last time you saw an issue that amounted to this?
<fengb>
Hiding design doesn't make it better. Documenting the API is a boon, but sealing off internals isn't really productive
<companion_cube>
I don't, because I write very defensively :D
<gonz_>
I find it ridiculous that people are spending any time debugging these things at all.
<companion_cube>
my OCaml code is full of private types, private aliases, and such things
<companion_cube>
because it removes debugging time
<fengb>
If your code is perfect... good for you
<gonz_>
And that's fine. My Haskell code is full of type classes, type level lists, etc., but I would never argue for them in Zig.
<companion_cube>
ugh, no, it's not perfect, it just helps me avoiding mistakes
<fengb>
I can't always fix upstream, and I always find a weird bug
<fengb>
And if it's private, I can't work around it at all
<Tetralux>
Yeah I'd tend to hesitate to have private fields...
<Tetralux>
IME, it feels good to say "I'll make this one private because I don't need it outside" or whatever
<Tetralux>
It feels good to write that stuff.
<gonz_>
Just because peoples' favorite languages have things doesn't mean zig has to and not everyone has to be a language designer just because the community is small.
<Tetralux>
Like how you write `public:` in C++ structs.
<companion_cube>
gonz_: of course not
<companion_cube>
but that's not an argument against a feature either
<Tetralux>
I would consider that if the bug you're making is that you need to have private fields...
<companion_cube>
people's favorite languages have iterators, and Zig can have them too
<Tetralux>
Then you need to program in a more data-oriented way.
<gonz_>
There's always an obvious argument against every feature: Let's see if we can *not* add it.
<companion_cube>
you can say that of basically everything
<gonz_>
Yes, but private fields is pretty obvious that you can simply *not add*.
<companion_cube>
why have private functions,then?
<marler8997_1>
python doesn't have private fields either
<companion_cube>
you can simply not add them
<companion_cube>
why have const? you can simply not mutate it
<gonz_>
companion_cube: What's going on with these odd equivalencies? Private functions serve a very real function; to make some task in a single file more managable by splitting up the logic.
<marler8997_1>
true, maybe we should remove private methods and const??? :)
<gonz_>
Private fields don't.
<fengb>
You can't modify a function so it's not the same
<fengb>
But if the data is wrong... well now I can't fix it because it's private
<gonz_>
These insane comparisons
<marler8997_1>
can't you do that with public functions as well?
<companion_cube>
^
<companion_cube>
private fields allow you to have some fields that you know won't be touched outside
<companion_cube>
same way private functions won't be called from outside
<companion_cube>
such fields can include cached computations, for example
<fengb>
And if the cache scheme is broken? Because it often is
<gonz_>
And you would accomplish the exact same thing by underscoring it
<companion_cube>
fengb: then it's a bug
<fengb>
Yes it's a bug
<marler8997_1>
but what's the reason for private functions then?
<fengb>
But I can't always fix it upstream
<fengb>
That's my point
<companion_cube>
sounds like you're fucked
<companion_cube>
what if you have to call a function that's bugged? are you going to edit its code?
<fengb>
... or I can work around it if it isn't private
<fengb>
But now I have to throw away the library completely
<gonz_>
Meh, private functions aren't strictly needed either, honestly. They're much more valuable as an organizational tool than private fields, though.
<companion_cube>
I agree, it doesn't mean they're obviously useful and private fields, obviously useless, as you seem to imply
<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
<companion_cube>
it's more nuanced than that
<fengb>
marler8997_1: public fields can be solved with documentation. Private doesn't have to imply hidden, just unstable
<companion_cube>
again, same with function :D
<marler8997_1>
fengb: ?
<marler8997_1>
oh wait
<fengb>
I like private == not part of the api. It's the private == cannot touch that I'm not fond of
<marler8997_1>
you're saying private doesn't have to mean you can't use it
<fengb>
Yeah, thar be dragons
<mikdusan>
interesting
<gonz_>
Also known as underscored fields
<marler8997_1>
that would be interesting...private fields are implemented by not documenting them :)
<mikdusan>
and a compiler option to emit diagnostics if using dragons when you're not an authorized slayer
<marler8997_1>
at least, not using triple slash document comments :)
<marler8997_1>
seems a bit silly at first but I like it...ship it :)
<companion_cube>
gonz_: then remove private functions and just underscore them :/
<fengb>
With private functions... I don't really care because I can't really fix the bug anyway. It's not like I can force the state to be correct
<marler8997_1>
yeah it sounded like gonz_ would be ok with that
<gonz_>
companion_cube: It'd be far from a dealbreaker. We have a smart compiler that does dead code elimination anyway.
<marler8997_1>
it's what python does...so there's precedent
<companion_cube>
yep, so that should be removed :D
<gonz_>
The better point in all of this is: We are where we are at the moment. A growing feature set is generally a failure, let's try not to fail more.
<companion_cube>
marler8997_1: in terms of design, I'd tend to do the opposite of python, generally speaking
<Snektron>
I wouldn't take python as example of good language design tbh
<marler8997_1>
lol...I really like python for the space it operates in
<companion_cube>
I dislike almost all of python's design choices :/
<Snektron>
init is such an ugly way to designate special functions
<companion_cube>
poor scoping, statement instead of expressions, whitespace significant, no typing, no good lambdas…
<gonz_>
companion_cube: Just because we have features doesn't mean we should be careless in adding more. Even if they have some "This is almost like that..." thing in there already.
<marler8997_1>
lol
<Snektron>
Same with underscores on private fields, though thats more convention i guess
<fengb>
Python is a bad ML yes :P
<marler8997_1>
gonz_ I don't think anyone thinks we should be careless in adding features, you're sounding condescending
<companion_cube>
fengb: right? :D
<companion_cube>
and they're trying to add mypy but it's a bit, hum, tough
<fengb>
Java has "private" which isn't really private, but it's really asinine to get access
<marler8997_1>
bad ML?
<gonz_>
companion_cube: OCaml; no type classes, no higher-kinded types, no custom operators, no forward references without ugly hacky methods
<fengb>
C++ has "private" that's defined publicly and kills ABI compatibility
halosghost has quit [Quit: WeeChat 2.5]
<marler8997_1>
you could get access to c++ private fields as well
<gonz_>
companion_cube: We can do this with any language and bake in as many blub things and familiarities as we can fit as well.
<companion_cube>
gonz_: well, it removed a lot of useless features ;)
<companion_cube>
I know, I just really dislke python, because I can't write anything significant in it
<fengb>
marler8997_1: all the features companion_cube mentioned are things from an ML language, like OCaml or Haskell
<Snektron>
marler8997_1: you can even do that in a defined manner
<companion_cube>
marler8997_1: you can have `a = b` be an expression returning ()
<marler8997_1>
you can?
<marler8997_1>
well then this guys just wrong
<companion_cube>
I mean, that's a valid design decision
<companion_cube>
having it return b is a bit weird tbh
<marler8997_1>
oh right, this guy is saying python doesn't do that because state mutation should be at the top level of the block
<fengb>
But... a = b = c
<fengb>
Transitive that equality
<fengb>
Er... assignment
<companion_cube>
marler8997_1: right, as in `d = {1:2}; x = d.pop(1)`
<companion_cube>
clearly I'm mutating d at the toplevel…
<companion_cube>
(so, in rust, I just checked: `a=b` is an expression returning () indeed)
<marler8997_1>
yeah if I remember right, everything in rust is an expression
<gonz_>
Expressions over statements are a good example of where cutting away something (statements) actually opens up way more, while still being simpler.
<companion_cube>
yep
<companion_cube>
I'd say the same about sum types, but well :shrug:
<gonz_>
companion_cube: As in?
qazo has quit [Ping timeout: 244 seconds]
<torque>
guido stepped down as python bdfl because of the huge shitstorm over python 3.8 adding assignment expression syntax
<torque>
Apparently assignment being an expression is very controversial
<companion_cube>
gonz_: algebraic datatypes if you prefer
<torque>
ideas have a tendency to gain a lot of inertia
<gonz_>
companion_cube: Yeah, but what exactly do you mean that you'd want to do with them or some other feature (which)? Are we talking some ideal pure version of what a sum type is; variants, etc.?
<gonz_>
I didn't quite understand the "the same" part of what you said.
<companion_cube>
it's the same in that it's incredibly useful and it simplifies the language
<gonz_>
Aha. Yeah, I agree.
<companion_cube>
(yes, variants in addition to structs)
qazo has joined #zig
<gonz_>
It's such a boon to design.
<Tetralux>
Do I want to know why assignment syntax being expressions is useful to anyone?
<gonz_>
companion_cube: I ask because sometimes it seems someone has some platonic ideal of what a sum type is and they hate some other version of it that I can't tell why it's different.
<marler8997_1>
They give some examples and rationale for why you may want assignment expressions
<fengb>
A lot of iterators can be solved using assignment expressions
<gonz_>
You never know who's one of those.
<fengb>
I wonder if Python would have benefited from matching block syntax: if (foo) |match|
<companion_cube>
I mean, I'm a ML programmer at heart, so sum types are my bread and butter (as are expressions obviously)
<companion_cube>
so of course I hate python
<companion_cube>
(although the scoping is objectively bad)
<marler8997_1>
I dont' think so...since it doesn't really have a compile-time type system to accomodate
<marler8997_1>
meh...functions have scopes. If you want a scope you can use a function
<fengb>
The Javascript way? :P
<gonz_>
Few languages annoy me enough to hate them. I used to be very into Python, but it was mostly a reaction to coming out of a 7 year C++ binge and Python felt so simple in comparison.
<fengb>
C++ binge? How are you coping?
<companion_cube>
marler8997_1: lua, erlang, have good scoping
<gonz_>
But I agree with whoever it was that said "It's good for what it does" before.
<marler8997_1>
yeah like I say I think python has a place
<companion_cube>
I did write a 50 lines script yesterday, using mypy
<companion_cube>
ugh
<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>
python's simplicity makes for alot of libraries...it's got very low friction so you can get things done quick
<fengb>
Python used to be simple...
<marler8997_1>
ah....not anymore?
<gonz_>
fengb: There is only one language I actually have a visceral reaction to when I see it. I haven't written more than 20 or so lines of C++ since maybe 2007/2008.
<gonz_>
fengb: That's how I'm coping :D
<marler8997_1>
lol
<companion_cube>
lua is simpler and cleaner than python
<companion_cube>
too bad its community is much smaller
<marler8997_1>
yeah?
<fengb>
I agree with simpler :P
<marler8997_1>
should I be using lua instead of python for my scripting needs?
<companion_cube>
cleaner, because it has good scoping with `local` :p
qazo has quit [Ping timeout: 258 seconds]
<companion_cube>
and also faster, obviously
<fengb>
I'm not a big fan of Lua syntax, but its semantics are much nicer
<marler8997_1>
I would guess it doesn't have as many libraries
<companion_cube>
clearly not
<companion_cube>
python's only strength is the ecosystem
<companion_cube>
and it's a big strength
<marler8997_1>
"the ecosystem"...reminds me of Apple products
<ntgg>
python is very easy for at least small things, it's not only the ecosystem
<marler8997_1>
sure but I think he was saying that's it's only strength over something like lua
<companion_cube>
I mean sure, dictionaries remove a lot of friction for small things
<companion_cube>
yes.
<marler8997_1>
I'll have to spend some time with lua and see for myself
Hirezias has quit [Ping timeout: 264 seconds]
<ntgg>
lua takes far more effort than python, at least for me.
<ntgg>
I have done significantly more lua dev than python dev too
<marler8997_1>
would love to see some resources comparing the two
<marler8997_1>
what's some reasons for preferring python over lua?
<gonz_>
lua, Python and Ruby seem like mostly the same-ish language to me, where you can pick an arbitrary favorite and move on.
<companion_cube>
python has nice comprehensions, I must say
<companion_cube>
(it's one of the rare nice things in it, and it's in the expression part :p)
<marler8997_1>
comprehensions?
<gonz_>
You can give a reason like "Well, I like that this one chose to model everything with some kind of table variant thingy and extended that concept really well", but do you really have to have a reason for preferring something so much like the others?
<fengb>
I prefer the Python ecosystem to Ruby
<fengb>
Rubyists love to pretend they're DSL authors
<gonz_>
marler8997_1: List comprehensions, `for x in, where some condition holds for x, bla`
<companion_cube>
marler8997_1: [x+2 for x in whatev if x>0]
<ntgg>
python has a lot more stuff included then lua, lua is a very _small_ language
<marler8997_1>
oh right...I've seen that one but haven't really groked it yet
<ntgg>
Lua is better for embedding, but you need to do so many things in lua to get to the productivity of python, even without it's ecosystem
<companion_cube>
without its ecosystem and stdlib, even?
ltriant has joined #zig
<ntgg>
I would say so, the language itself does much more for you compared to lua
<companion_cube>
what do you have in mind? apart from comprehensions and `with`, I don't really see where python shines
<companion_cube>
ah, guess there's async too now
<ntgg>
arrays are much easier to work with in python
<ntgg>
and strings
shritesh has joined #zig
<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>
I should clarify that the "like" was sarcasm
<companion_cube>
well then you can put tuples in sets!
<marler8997_1>
I suppose
<companion_cube>
(same with frozenset)
marmotini_ has quit [Quit: Leaving]
shritesh has quit [Remote host closed the connection]
<Tetralux>
Q: Does the stdlib support atomic pointers?
<Tetralux>
i.e: A pointer, where the address it points to can be updated atomically.
<Tetralux>
Or is the idea that you have an atomic usize and update it the way you're meant to do that?
<Tetralux>
For clarity, I mean, you have a pointer, you change it to point at something else - only atomically.
ntgg has quit [Remote host closed the connection]
<fengb>
Tuples are supposed to be position dependent. Python does a lousy job teaching the difference but they are different in important ways
<fengb>
In languages without proper tuples, you end up reinventing it poorly