frett27 has quit [Read error: Connection reset by peer]
frett27_ has quit [Read error: Connection reset by peer]
klltkr has quit [Ping timeout: 264 seconds]
grant_ has quit [Quit: grant_]
marijnfs_ has joined #zig
foobles has joined #zig
gazler_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
gazler has quit [Ping timeout: 246 seconds]
darithorn has joined #zig
factormystic has joined #zig
<wilsonk>
copy: if you are trying to cross compile for Mac you can just build object files on linux/win and then link with ld64 (or the osxcross compiler) and the binary will work. Here are my commands: 'zig build-obj main.zig -target x86_64-macosx -lc' -> 'o64-clang main.o ~/zig/temp/libcompiler_rt.a -o main'
<wilsonk>
I haven't gotten it working with a library that uses Cocoa yet, but command line stuff seems to work with my minimal testing
ur5us has quit [Ping timeout: 272 seconds]
layneson has quit [Quit: WeeChat 2.8]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
nephele has quit [Ping timeout: 240 seconds]
nephele has joined #zig
ikskuh has quit [Ping timeout: 265 seconds]
<daurnimator>
mikdusan: 10.5 is ancient. we can specify that as the minimum
mq32 has joined #zig
<daurnimator>
mikdusan: infact we can specify 10.13 as the minimum can't we?
<mikdusan>
I think my digging so far is half-assed, in that I only tried setting minimum during exe linking. but that was against a non-minimum libcompiler_rt.a which I assume builds at current host levels, in my case 10.15.4
<mikdusan>
I'll do a quick try at (when null, aka zig0 bootstrapping) setting 10.13 universally for compiling/linking so libcompiler_rt.a is in the loop and see what happens
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
<terinjokes>
is there a way to specify the cache/maniest directory?
<terinjokes>
probably cache-dir
<terinjokes>
ah, but can't pass to zig cc
<daurnimator>
andrewrk: "By default, the size of enums is not guaranteed." -> really? I didn't realise `enum(u16) { .... }` could be not a u16.
<daurnimator>
oh and a thought about math.clamp and some other functions: with @TypeOf now doing peer-type resolution, something like: `fn (a: var, b: var, c:var) @TypeOf(a,b,c)` might make sense.
_whitelogger has joined #zig
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
dddddd has quit [Ping timeout: 258 seconds]
grant_ has joined #zig
joey152 has quit [Remote host closed the connection]
grant_ has quit [Remote host closed the connection]
grant_ has joined #zig
<mikdusan>
daurnimator: yup 10.13,... all the way back to 10.7 helps with -pie but hit another bug in --library processing
grant_ has quit [Ping timeout: 258 seconds]
<mikdusan>
if using `-target native-native` all is good. but as soon as os becomes specified, even if it is same as native: `-target x86_64-macosx` is_native is now internally set to false. and for some reason --libraries are cond is_native==true
* mikdusan
checks linux
<daurnimator>
mikdusan: yes that's intentional
<mikdusan>
what part?
<daurnimator>
mikdusan: the idea is that unless you're targeting native-native then -l shouldn't look in /usr/lib
<daurnimator>
you'd have to add -L/usr/lib to look there
<mikdusan>
but if I'm targeting anything, I need to be able to setup custom paths and libs
<mikdusan>
what I'm saying is custom -lWHATEVER does not get added if (is_native == false)
<daurnimator>
oh. that's wrong
<mikdusan>
hell this might even extend to `zig cc`
<terinjokes>
that works for me when using zig cc
<terinjokes>
i was using it last night without issue
<mikdusan>
w/ -target ?
<terinjokes>
yes
<mikdusan>
ok i need to investigate further
waleee-cl has quit [Quit: Connection closed for inactivity]
<mikdusan>
terinjokes: linux?
grant_ has joined #zig
<terinjokes>
mikdusan: yeah, I'm on x86_65-linux. i missed seeing you were on macosx
<terinjokes>
(x86_64, I do not have an extra 65th bit)
<grant_>
most of those errors repeat
<grant_>
so should I edit the cmake files now?
<mikdusan>
terinjokes, darithorn: it's a macho (macosx) thing. all build-exe/test and `zig cc` linking.
<mikdusan>
whups i mean daurnimator
<mikdusan>
verified linux is ok
<terinjokes>
mikdusan: okay. again, sorry for disrupting you
<foobles>
I just noticed something weird about `ir_analyze_bin_op_bool`. I have tested it, and it definitely short circuits. like: `comptime { if (false and undeclared_ident) {} }` will compile
ur5us has quit [Ping timeout: 252 seconds]
<foobles>
since the `and` only evaulates the left side at comptime
<foobles>
but in the function, it runs `ir_resolve_const` on the lhs and rhs before comparing them
<foobles>
how is this possible? Does `ir_resolve_const` not actually resolve anything?
ur5us has joined #zig
grant_ has quit [Read error: Connection reset by peer]
grant_ has joined #zig
grant_ has quit [Ping timeout: 258 seconds]
grant_ has joined #zig
grant_ has quit [Quit: grant_]
grant_ has joined #zig
grant_ has quit [Ping timeout: 260 seconds]
ave_6 has joined #zig
lunamn8 has joined #zig
ave_ has quit [Ping timeout: 240 seconds]
ave_6 is now known as ave_
lunamn has quit [Ping timeout: 264 seconds]
lunamn8 is now known as lunamn
darithorn has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 252 seconds]
foobles has quit [Ping timeout: 240 seconds]
_whitelogger has joined #zig
cole-h has quit [Quit: Goodbye]
Xavi92 has joined #zig
omglasers2 has joined #zig
FireFox317 has joined #zig
<pixelherodev>
git seems awfully quiet post-0.6.0
<pixelherodev>
commit-wise at least
<Xavi92>
How can Builder execute/include another build.zig from another library?
<Xavi92>
Just 'cd path_to_lib && zig build'? Or are there other, more appropiate methods?
<Xavi92>
appropriate*
<Xavi92>
Are always all struct members public if the struct is pub? Or could some of the members be private/internal?
greaser|q has joined #zig
demizer has quit [Ping timeout: 256 seconds]
demizer has joined #zig
<FireFox317>
Xavi92, build.zig is just a regular zig file, so you can just `@import` the other build.zig file
<Xavi92>
FireFox317: thanks!
<Xavi92>
FireFox317: do you know the answer for my other question, BTW?
kenaryn has joined #zig
<kenaryn>
Hello, please what does imply 'null-terminated'? for example, in the case of a string, does it mean ending with `\n` sequence? is it stripped off its LF byte? I do not understand the concept.
<mikdusan>
ending with u8 value 0
<kenaryn>
Isn't that a sentinel-value?
ur5us has joined #zig
<Xavi92>
kenaryn: yes, but it's also called null-terminated, at least in C
<mikdusan>
yes, it's c-string style. zig calls them terminations "sentinels" . because we can teminate on other values too.
pingiun has joined #zig
<kenaryn>
Thank you mikdusan and Xavi92.
<Xavi92>
kenaryn: you're welcome :)
<mikdusan>
Xavi92: think of it like this, if the symbol is not `pub` then no other file can see it. And for it to be accessible outside current file, it has to be pub, and any of its same-file enclosing structs need to be too
dermetfan has joined #zig
<mikdusan>
also I assume by "members" you meant NON-fields . if you're asking about fields, they don't have pub option
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<Xavi92>
mikdusan: oh. That would be useful when a library does not want to expose internal information to the user, but data must still be allocated
<Xavi92>
mikdusan: in C, there are some ways to achieve this, all of them with pros and cons. One is to allocate the private resources dynamically and return an opaque pointer, other is creating a public interface with dummy names but same types as the private interface, and another would be creating a public interface as 'struct tag {char[X] buf};', where X is the number of bytes actually used by the private data structure
<Xavi92>
mikdusan: the first is not acceptable on constrained devices where dynamic allocation is not an option. OTOH, Zig wants to target these devices too
<Xavi92>
mikdusan: the latter two allow allocating the resources statically, but are not portable since private struct members could have different sizes according to the target (e.g.: pointers)
<Xavi92>
mikdusan: the best way I could think of so far in Zig is based on the 'struct tag {char[X] buf};' method, where fortunately X could be extracted at compile-time by calling a comptime function.
<Xavi92>
mikdusan: for example, 'const buf: [getSize()]u8 = undefined;' (or even '[getSize()]var u8', as I suggested on ##5056), where (in a separate file) 'pub fn getSize() usize {return @sizeOf(PrivateStructure);}'
<Xavi92>
If I'm not mistaken, I think it could be even changed to 'pub fn getSize() usize {comptime return @sizeOf(PrivateStructure);}'
ur5us has quit [Ping timeout: 256 seconds]
<Xavi92>
FireFox317: @import() would work in many cases, but for my specific case the path is given by an environment variable which is obtained at runtime. Obviously, @import would not accept that, so what other solutions are available?
<mikdusan>
I may have misled you by calling them "symbols". `pub` is for globals and yes, they can become exported symbols in a c-compatible fashion; but I was speaking only about globals
<mikdusan>
now if you take a c-compatible structure and export it, then it is exported in an ABI fashion
<mikdusan>
are the struct fields visible? yes. and the interface is through .h . so if .h says they're visibile then they are.
<mikdusan>
c-structs are public iirc
<Xavi92>
mikdusan: I know, but for improved modularity some libraries prefer hiding the internals to the user
<Xavi92>
mikdusan: talking only about zig here (let's now forget about C), if I had to write a library that wants to hide the internals to users but still allow them to allocate the needed resources statically, how could that be achieved?
antaoiseach has joined #zig
<antaoiseach>
Hello all! I am working through the memory section of the master doc, and the following code throws an OOM error - https://paste.rs/mq8. If I change the type of the allocatot to `const` and initialise it with the address of the allocator directly, it works as expected. Anybody know why? Or is this a bug?
SimonNa has quit [Remote host closed the connection]
<mikdusan>
Xavi92: right now libraries in zig are source. Zig wants to see it all. is that the kind of library you are talking about?
<FireFox317>
Xavi92, uhm i guess then you could use a systemcommand and run `zig build` from that directory, maybe somebody else has a better idea tho
<Xavi92>
mikdusan: not exactly. Let's look at it from another angle: in Rust, a struct can be public, but the visibility of each member can be assigned individually
<Xavi92>
mikdusan: so you can have 'pub struct Bar {field: i32, pub other_field: i32}', where 'field' is private whereas 'other_field' is public. This means anyone using Bar can access 'other_field', but not 'field'; that one would be only accessed by the library itself
<Xavi92>
mikdusan: that provides encapsulation, "similarly" to scope for class members in C++ (and only similarly)
<mikdusan>
antaoiseach: https://bpaste.net/WBQQ ; there is a subtle footgun there. that `.allocator` is a object that should never be copied. we have ideas coming to address it. but for now this is how you do it
<mikdusan>
llx nice
<mikdusan>
l1x: nice
ur5us has joined #zig
<l1x>
mikdusan: yeah i just got to know that project but it is extremely nice because zig supports so many platforms and the code can be leaned up quite a bit
<l1x>
i am interested in how much code reduction it is going to be
<kenaryn>
Thanks FireFox317 for the detailed answer.
<antaoiseach>
mikdusan: Thank you! So for now I can simply follow the idiom of `const allocator = &<allocator initialisation>` consistently?
<mikdusan>
yes but the lifetime of allocator is only good until end-of-scope
<mikdusan>
if you did that in 2 steps it would be clearer; `var fba_state = FixedAllocator.init(...); const fba = &fba_state.allocator;`
<mikdusan>
your other choices are make state global or put state itself on heap
<antaoiseach>
mikdusan: Ah, okay. That does actually make it clearer to understand
<antaoiseach>
Thank you!
<mikdusan>
tbh, I always 2-step it.
bsrd has joined #zig
dddddd has joined #zig
<pixelherodev>
I do the same
<pixelherodev>
I 2-step everything really
<pixelherodev>
I prefer to have multiple simpler pieces than fewer complex ones
<antaoiseach>
Interesting... I'll also follow the idiom then! :-)
<pixelherodev>
FireFox317, that I do
<pixelherodev>
I mean I don't do e.g. `a(b += c);`
<pixelherodev>
Function calls should never contain assignments inline IMO
<antaoiseach>
One more question - I am almost done with the master documentation. I was planning to start reaading the lib source code to understand the standard library better, especially for the data structures and algorithms in it. Is there any specific way you guys would recommend I go about it?
<pixelherodev>
I think that allowing e.g. `if (a = 1)` to *ever* be valid was a mistake in C
<antaoiseach>
I believe that documentation for the stdlib will be some time coming?
<Xavi92>
Sorry for insisting, but is there any feasible solution to the issue I described above?
<FireFox317>
antaoiseach, we have some experimental std library documentation: https://ziglang.org/documentation/0.6.0/std . But they are incomplete and do not show the exact definitions of generic functions. So better would be to just look at the source, and especalliy the tests inside the std library files
<antaoiseach>
Firefox317: that's a great suggestion - to start with the tests. I think I'll follow this route - should make it easier to trace the flow
pingiun has quit [Read error: Connection reset by peer]
mq32 is now known as ikskuh
<pixelherodev>
Xavi92, what's the issue?
<Snektron>
assignment in if statements can be useful in some cases
<Snektron>
Assignment-in-while is a good example
<Snektron>
But that rather points at a weird implementation of a language feature where you avoid having to repeat yourself in that specific kind of construction
<Snektron>
I would assume that members of private structs are still private, so if you return a private struct you get an opaque handle
<Xavi92>
Snektron: if dynamic allocation is not available, then you can either return it from the stack or perform static allocation
<Xavi92>
The former might be problematic on constrained devices with low amounts of RAM, while the latter needs to know the size of the private struct outside the module
<Snektron>
i mean opaque as in you can't view the insides
<Xavi92>
Snektron: I know what opaque means, but if the struct needs to be statically allocated, then the user must allocate the resources before calling the function
<Snektron>
im not sure how we suddenly arrived at allocation
<Xavi92>
Here, a.c could happily modify any of the members from 'm', usually without knowing what they mean and often creating potential bugs, if 'my_struct' was only meant to be modified by 'b.c'
<Snektron>
ah, like that
<Snektron>
you'd best look up the relevant issue about removing them
<Snektron>
Oh and also, the returning thing works different in Zig because of the result value locations
<Xavi92>
But this is not portable since sizeof pointers changes between architectures, and is very error-prone
<Xavi92>
Snektron: do you know which issue was it?
<Snektron>
So in the first example you posted, you could just return my_struct from bar, and everything will be fine. There are some quircks with the mechanism though, but young language and all that i suppose
<Snektron>
No sorry, i only learnt it through the update notes
ifreund has joined #zig
<mikdusan>
heh I'm still not clear on wether this is about public ABI or API ?
<mikdusan>
those links are basically c idioms for library ABI barriers. hiding stuff from those users. Zig doesn't have an ABI.
<daurnimator>
sorry everyone.... I am expecting this issue to take me a day or two to write out
<Xavi92>
Snektron: returning my_struct from bar would be fine if the struct was small enough (as in the example), but it the struct was very large e.g.: 1024-byte long, you might face a stack overflow on some microcontrollers
<Xavi92>
mikdusan: it has nothing to do with ABI as far as I can tell. It's just a matter of encapsulation and hiding the internals to library users
<mikdusan>
daurnimator: accepted! /s
antaoiseach has quit [Quit: leaving]
<Xavi92>
Snektron: that's why static allocation is needed. Placing the large buffer on .bss instead of the stack avoids potential stack overflows
<Xavi92>
Snektron: of course one wouldn't care when writing zig for a x86_64 CPU with GiBs of RAM, but the situation changes when facing a microcontroller with 2 KiB SRAM
kk- has joined #zig
<Xavi92>
Snektron: and, AFAIK, zig also wants to target such devices. IMHO at least it should attempt to do so if it really wants to replace C, where very often is the only available language for microcontrollers
kk- has quit [Client Quit]
<FireFox317>
Xavi92, static allocation is totally possible in Zig
<Xavi92>
FireFox317: I'm not saying static allocation isn't possible, which I know it fortunately is. It's the fact of allocating statically an opaque structure from the user's point of view that is later casted into a private structure by the library
<mikdusan>
.bss? yeah. zig makes use it
<mikdusan>
use of it
<mikdusan>
we already have std examples of static allocation that is private with interfaces made public. see std.heap.page_allocator, c.allocator, etc.
<Xavi92>
mikdusan: I'm afraid I'm not explaining myself right
<Xavi92>
mikdusan: std.heap.page_allocator is a static global variable used internally by heap.zig. Ignoring how std.heap works internally, what if two or more page_allocators had to be used simultaneously?
<Xavi92>
mikdusan: (considering heap.zig does not know how many page_allocators will be used, since it is determined by the user who uses the library)
neceve has quit [Read error: Connection reset by peer]
<mikdusan>
page allocator is an interface to the operating system. the operating system offers a global page allocator. what's the issue?
<mikdusan>
heap.HeapAllocator exposes an os-provided many-heap pattern. when used the way it's meant to be used, you get access to heap allocator's interface and that's all.
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
<Xavi92>
mikdusan: again, I think I'm not explaining myself right. Nevermind, it's possible to do what I meant in Zig: https://bpaste.net/K67Q
<Xavi92>
mikdusan: I was only asking if there was a more idiomatic solution to it, but I guess this is the way to go. I'm glad Zig has powerful compile-time capabilities
<Xavi92>
mikdusan: probably access() should take '*Op' instead of 'Op', so it is ensured the reference is modified
Xavi92 has quit [Remote host closed the connection]
waleee-cl has joined #zig
xackus_ has joined #zig
kenaryn has left #zig ["WeeChat 2.3"]
xackus_ has quit [Quit: Leaving]
TheLemonMan has joined #zig
ave_ has quit [Quit: ave on thelounge.lasagna.dev]
lunamn has quit [Quit: ave on thelounge.lasagna.dev]
ave_ has joined #zig
grant_ has joined #zig
<Snektron>
<Xavi92 "Snektron: returning my_struct fr"> (sorry for the late reaction) I don't think the result location semantics discriminate between stack, static or heap memory. Afaik its a kind of implicit transformation of `fn a() Struct { return Struct{...};}` to `fn a(result: *Struct) {result.* = Struct{...}};`
<Snektron>
where `result.* = Struct{...}` would be inlined to `result.a = ...; result.n = ...;` etc
<Snektron>
I'm not certain on the details though
<fengb>
Returning the struct at the same time it's built (`return Struct{}`) would be equivalent to passing a pointer
<fengb>
We haven't guaranteed it for any other type of returns yet... but LLVM may choose to use a pointer under the hood
<Snektron>
I'm pretty sure it doesn't work for `{const a = Struct{...}; return a;}`
<Snektron>
I find that kind of odd
<fengb>
I think it's in the pipe but it's not built yet
<Snektron>
Seems like a basic block peephole optimizer would take care of stuff like that
<foobles>
i submitted a patch to my PR and i saw the automated tests on azure failed
<foobles>
turns out the mac one just disconnected
<foobles>
I didnt even see if it ran any tests at all
<foobles>
i just submitted another patch, cleaning up formatting, and it seems to be working
<fengb>
Yeah that happens :(
<fengb>
Nobody's fault (except Microsoft 🙃)
<foobles>
hoorayyy
<foobles>
well im just glad i didnt accidentally blow something up with that original patch :)
cole-h has joined #zig
jmiven has quit [Quit: reboot]
jmiven has joined #zig
SimonNa has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
<mikdusan>
oh that is new. PR github has a "convert to draft" clickable
<fengb>
Oh finally!
<AndroidKitKat>
they do? nice
<ikskuh>
can somebody explain what this does?
<fengb>
You can create a PR draft which tracks your changes but doesn't let it get merged. Previously you can only *create* these PRs, so if you accidentally promoted it or created it wrong, it's permanently stuck in "open"
<ikskuh>
ah
<mikdusan>
or for me it's like "nah this PR is so good it doesn't need draft mode" and the CI runs and changes my mind
<fengb>
Oh maybe it'll be better than close/reopen :P
kenaryn has joined #zig
<kenaryn>
Hello again computerizing people. Please what is the intent behind the 'Avoid local maximums' narrative in zig zen philosophy? Perhaps a simple example would be in order to explain it to me :D (And Andrew, by the way, 'maximum' is a singular word; hence, it cannot be put with a trailing 's'. In Latin, you might want to use 'maximata' to express a plural concept, like 'eloh'/'elohim' in hebrew).
<fengb>
I think technically the word is 'maxima' but that sounds super pretentious :P
<kenaryn>
You may be tend to the thrust :)
<shakesoda>
fortunately, we speak english, and there are no rules in english
<shakesoda>
noun any verb, verb any noun, plural any singular!
<shakesoda>
capitalization!? foolish!
<shakesoda>
WE USE CAPS ONLY TO YELL
<fengb>
Basically it means, we shouldn't make decisions to fix short sighted problems. Sometimes we have to go backwards a little to reach the global maximum
<shakesoda>
fengb: maybe the wording should be made more... plain
<shakesoda>
i'm not actually sure i'd have ever interpreted it that way
<fengb>
Like how Zig switched to `const Foo = struct` syntax. It was painful at first but now we don't even think about it
<fengb>
I'm also not andrewrk so I'm interpreting his words too :P
<ikskuh>
fengb: we all can only interpret the words of god *laughs*
<ikskuh>
<shakesoda> fortunately, we speak english, and there are no rules in english
<ikskuh>
well, same rules apply to pretty much all languages
<ikskuh>
like "oh yeah, let's just make that adjective a verb"
<fengb>
Am I a prophet?
<kenaryn>
Nicely put, thanks for your explanation fengb (and I suppose you're right, maximata doesn't not exist, but maximita means 'grandeurs'. Hence, you may be right about maxima, thanks for instructing me).
<fengb>
I'm sure English especially would drive the French crazy :P
<kenaryn>
I'm not crazy :D
<fengb>
kenaryn: English isn't latin. We like to invent our own rules
<ikskuh>
yeah it's maxima :D
<shakesoda>
fengb: that's fine, everything drives the french crazy
<shakesoda>
;)
* ikskuh
knows some stuff about latin from school :D
<fengb>
Some are Latin based. Some are German based. But mostly 'murican
<ikskuh>
fengb: Kindergarten! Rucksack!
<kenaryn>
but I regret main guidelines on github recommend to switch from en-GB towards en-US :/
<shakesoda>
well, github is a us company
<shakesoda>
or do you mean zig github
<kenaryn>
github belongs to Microsoft so they it is US...
<kenaryn>
so yeah*
<shakesoda>
github was in the us to begin with
<shakesoda>
so it makes sense that en-us would be preferred
<fengb>
Zighub?
<kenaryn>
zig github would be the same as Andrew is from NY
<ifreund>
you want to write a website in zig?
<shakesoda>
i'd consider it
<ikskuh>
why not?
<ikskuh>
static site generator in zig
<kenaryn>
yeah let's all adopt emscripten in production :p
<shakesoda>
i was thinking in the generating html sense, but okay
<fengb>
Like our docs?
<ifreund>
the generator sense makes more sense yeah, though i was thinking of the wasm/emscripten sense originally
grant_ has quit [Ping timeout: 260 seconds]
<kenaryn>
It will be a event when we'll reach Tier 1 support
<fengb>
I’m really liking the new allocator direction
hazeycode has joined #zig
Xavi92 has joined #zig
owl_000 has joined #zig
<Xavi92>
Hi there :)
<owl_000>
hi
<owl_000>
good wishes zig
owl_000 has left #zig ["Leaving"]
<kenaryn>
Didn't know your reply, thanks fengb who is non-kind :D
<kenaryn>
doesn't the std.testing.allocator intended for early prototypes before replaced by a more specific ones?
<kenaryn>
does*
<fengb>
It’s mostly for running the test suite
<fengb>
Libraries typically accept any allocator so in test mode, we can give it a special allocator that’s decently fast and checks for stuff like leaks
<fengb>
Not recommended for actual programs
<fengb>
In the future, it will have more robust debugging checks
<kenaryn>
Thanks again.
<kenaryn>
I think early prototypes concepts in Zig competes with some of Python's market segment and I'm quite pleased about it.
<kenaryn>
Python's use cases I mean.
<Xavi92>
I would like to ask you all to please review this issue so it grabs more attention from the community in order to make a decision -> https://github.com/ziglang/zig/issues/5056
hazeycode has quit [Ping timeout: 240 seconds]
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 256 seconds]
MajorLag is now known as tgschultz
Akuli has joined #zig
layneson has quit [Quit: WeeChat 2.8]
klltkr has joined #zig
tgschultz has quit [Ping timeout: 256 seconds]
tgschultz has joined #zig
wootehfoot has quit [Ping timeout: 250 seconds]
marijnfs has quit [Ping timeout: 264 seconds]
Akuli has quit [Quit: Leaving]
Akuli has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<kenaryn>
Hey dude, be cautious with endlessly enhancing the language's parsing expression grammar. D has lost himself and never developped its own identity by being obssessed with 'what/how are the other languages doing?' narrative to end like a scripting glue for C++ codebase and in the process, became more and more complex to deal with.
<kenaryn>
to end up*
<companion_cube>
it was started by C++ devs, though, maybe it was already lost
<kenaryn>
lol... you're right
<BaroqueLarouche>
C++ compiler dev to be exact
<kenaryn>
By the way, are you French or Canadian?
<BaroqueLarouche>
me ?
<BaroqueLarouche>
Québecois
<kenaryn>
you both actually
* companion_cube
is french
<kenaryn>
Allright :)
<companion_cube>
(well, technically, I'm both, but I grew up in france)
<kenaryn>
A small language would have more traction and reach a critical mass more rapidly if the entry barrier is quite low and would be a favorable reason to migrate a existing industrial basecode towards Zig. For example, everybody has at least notions of Shell because it IS a small language.
<companion_cube>
you mean `sh`? what a nightmare
<companion_cube>
but Zig is still pretty small
<kenaryn>
Hence, the employers are more favorable to its adoption in professional context because he's aware of a rapid learning curve from his employees.
<kenaryn>
Yes, there's no function in 'sh', but I had 'zsh' in mind actually. Never mind :)
<companion_cube>
zsh is … not small :D
<kenaryn>
Please do `orelse` and `catch` have equal priority during the semantic analysis? I do not know whether there is a precedence or not for operators in the same line in the 'Precedence operators' documentation subpart.
shinzo has joined #zig
<kenaryn>
Another example would be: is `<<` and `>>` have equal precedence?
<ikskuh>
kenaryn, there's an issue regarding precedence
<ikskuh>
in short: if the precedence is not obvious (like 3 + 4 * 5) then you must put parenthesis around it
naught-fowl has joined #zig
<Xavi92>
kenaryn: "Hey dude, be cautious with endlessly enhancing..." <- is that because of what I posted above?
<kenaryn>
Yes, I'm sorry for being rude, you are not a dude.
<Xavi92>
kenaryn: np. I don't think my proposal adds any complexity to the language though
<Xavi92>
kenaryn: the proposal just adds zero-cost safety that IMHO should be already there. I'm the first to think Zig should be kept as simple as possible, but not simpler
<Xavi92>
I'm the first who agrees*...
<kenaryn>
Xavi92: It's nice to know you're following Albert's Einsten philosophy.
<Xavi92>
kenaryn: glad you caught the reference :)
<kenaryn>
I admit being mistrustful towards your proposal because it's based on a beginner's bad practice (like you eloquently put it).
<kenaryn>
if ( zig_user_skill == low) then decrease_readibility=true and force_convention_guideline=false. You get the picture.
<Xavi92>
kenaryn: Still I think a beginner (or anyone in general) would prefer a compile time error than shooting on his/her foot because of a bug caused by non const-correct code
<kenaryn>
In order to resume, your postulate is pessimist. That's my opinion.
<kenaryn>
You're right about that.
<Xavi92>
kenaryn: C makes everything mutable by default (including pointers, which are my main motivation behind the proposal) and, while it might make the language more readable to beginners, IMO it's just an illusion. Const-correct code is less readable in C, but that doesn't mean it's superfluous
<kenaryn>
Nevertheless, if 'Only one obvious way to do things.' is correcly enforced, there is no reason to project oneself in a beginner's shoes perpetually because we SHOULD hope that's the begginner's user base is still fleeting (i.e. short-lived) thanks to a allegedly learning curve (except the fact that new begginner's are endlessly replaced for the sake to the language continuity).
<shakesoda>
part of what I don't like is that it throws syntax in yet another place, and I'd really rather have a language that favors not making you write more than you need to
<kenaryn>
smooth learning curve* I mean
<foobles>
"prioritize reading code over writing code"
<kenaryn>
Agreed with you all, as strange as it may look like.
<kenaryn>
A snippet is insufficient to take action, a real use case would be sane to balance pros and cons.
<Xavi92>
kenaryn: unfortunately I've read many non const-correct libraries in C written by not-so-beginners from big companies, which force me to remove const checks from my code while crossing my fingers to avoid compiler warnings
<shakesoda>
I'm not entirely even convinced this is a real problem in zig as it stands, since it's a lot harder to violate to begin with.
<shakesoda>
zig is already rather heavy on the syntax for stuff, too, I'd rather have less than more
<kenaryn>
I recommend you to add your last sentence to a Nota bene in your github proposal.
<shakesoda>
note that my complaint applies to writing out *const and *var on everything, I'm indifferent if it just removes writing const and makes you write var
<Xavi92>
shakesoda: again, I don't think this proposal should be left out because of this reason. I'm sure there are other places in the language (can't tell now since I'm not that experienced in Zig) that might need or have already been simplified from their initial revision
<shakesoda>
default immutability is not something I have a complaint about, just the implementation of it increasing the total amount of syntax
<kenaryn>
Like Andrew pointed out in the release notes, the whole point of zig is to rethink abstraction concepts, maybe, it's time to stop reasonning like C and adopt a new paradigm. But I still think there's never enough safety mechanisms in any language.
<Xavi92>
kenaryn: wouldn't that imply removing the concepts of pointers and array?
<kenaryn>
A strong use case would be ideal to help settle the proposal.
<Xavi92>
kenaryn: that's saying I would have to justify const-correctness. I'm sure the Internet has lots of articles on that, regardless the language
<Xavi92>
kenaryn: unless I've misunderstood you. Which strong use case would you propose?
<kenaryn>
I do not know, I'm speaking of a real codebase from one or several zig's user(s) for at least medium-size projects to report a feed-back based on practical experience.
ur5us has joined #zig
<shakesoda>
a large amount of zig's entire appeal is that you can reason about it like C.
<shakesoda>
I'm free to scribble on pointers all I want as long as I tell it I'm doing so on purpose
<kenaryn>
Maybe, your proposal will lead towards unsuspected new mechanisms in the next weeks. I forbid you to lose hope. You SHOULD keep defending your initiative :)
<Xavi92>
kenaryn: thanks for your kind words :)
<Xavi92>
kenaryn: OTOH, if such a codebase existed today (which I don't know), I don't think it's a representative example. Zig users today are much likely experienced with other programming and are used to common pitfalls in similar languages such as C or C++, so they might not find explicit mutability necessary. But that might change in the future as the number of user grows and first-time programmers are introduced to Zig
<Xavi92>
...with other programming languages* and are...
<companion_cube>
does Zig really stand a chance of becoming a really mainstream language? I mena, beyond kind of power users?
<kenaryn>
shakesoda, you're right as usual. Being convinced to switch to another language thanks to an already implemented and mastered one is no-doubt a driving force for the latter one.
<companion_cube>
(I'd say C is not exactly mainstream either in that sense, at least on the desktop and server)
<kenaryn>
but what will become of Zig in 5-10 years if it doesn't develop its own identity (beware of Dlang syndrom lol).
<kenaryn>
C is still a mover for embedded programming industry.
darithorn has joined #zig
<shakesoda>
I use C extensively in games, graphics
<kenaryn>
Now I'm jealous.
<shakesoda>
zig has utterly destroyed my need to deal with C++ for anything personal
<shakesoda>
huge quality of life improvement, there
<Xavi92>
kenaryn: I work for the embedded industry and I feel the need for the industry to move for something else than C, at least in a long term
<Xavi92>
shakesoda: also liked Zig a lot. Coming from C and C++, I learnt some Rust (even got the official book) but after reading real-world code I didn't feel it really fits on constrained hardware. And I also feel Rust is becoming very complex, similarly to what happened to C++
<kenaryn>
And mutability by default is a blocker you mean? or is it part of something more that you're waiting to propose too? (no offense lol)
<kenaryn>
It's a trick question, do not answer it :)
<shakesoda>
rust has a lot of good ideas combined into one extremely complicated and frustrating mess
<companion_cube>
complicated compared to what, though?
<kenaryn>
yeah the borrow checker you mean... not appropriate for numerous use cases.
<shakesoda>
everything other than C++
Akuli has quit [Quit: Leaving]
<companion_cube>
seems simpler to me than, say, scala, or D
<shakesoda>
rust just isn't my thing.
<shakesoda>
but it gets a lot of the basics right
<Xavi92>
companion_cube: I find C++ complicated since it has many (IMHO sometimes too many) ways of doing things. One could read C++ from two or three programmers and none of them might look similar e.g.: STL, Qt C++ or Boost look like different languages from my own perspective
<kenaryn>
replacing c++ firefox's codebase was the Rust raison d'être, it was never intended to become industrial-wide adopted (my opinion only of course).
<companion_cube>
Xavi92: I'm saying rust isn't as complicated as C++
darithorn has quit [Remote host closed the connection]
<Xavi92>
companion_cube: I didn't said that, I just meant it *might* become as complex as C++
<mikdusan>
it's funny what happens when you build an industrial tool to handle a huge project (re: rust for firefox/mozilla? codebases)
<Xavi92>
(or is heading towards to)
<companion_cube>
I don't think so, it evolves quite slowly
<mikdusan>
git is another example. made for a huge project, and now git is everywhere.
<companion_cube>
(besides, C++ added things it was never designed to do and made it even worse, like move; what could rust possibly add that'd be that bad?)
<Xavi92>
Good example :)
<shakesoda>
c++ is built on bad ideas to begin with, so rust will always have advantage
<shakesoda>
although maybe i should avoid getting too deep into that holy war
<Xavi92>
Exactly :)
<companion_cube>
I mean, rust's foundations seem pretty sturdy to me
<companion_cube>
enums + move + borrowing
<companion_cube>
the rest is nicetise
<mikdusan>
if you look closely right now, zig is building in what it needs to cross-compile. from the get-go, comptime access to all this information is available. and sooner or later people are going to say "why am I bothering mucking with building cross toolchains, I can just use zig for .c, .cpp or .zig"
<fengb>
I find Rust's syntax to be very noisy, and I can't wrap my mind around the borrow checker
<Xavi92>
companion_cube: also lambda functions and lifetimes
<shakesoda>
lifetimes are one of the most cryptic programming concepts i have ever encountered
<companion_cube>
lifetimes are paired with borrowing
<companion_cube>
I'd add traits to my list, and say lambdas are just sugar for traits :)
<shakesoda>
it is /incredibly/ easy to get into mystifying and hard to resolve situations when you get into that stuff
<Xavi92>
companion_cube: I know, but in Rust they need an additional specific syntax
<shakesoda>
anyway, I want my language to be dumber than all that
<BaroqueLarouche>
When I tried Rust and have a start of a 65816 assembler, I found it hard to deal and couldn't imagine my coworkers at the time dealing with it.
<shakesoda>
zig is the kind of dumber that I want
<companion_cube>
Xavi92: C++ does, too… :)
<mikdusan>
rust surprised me in how long it took to bring in non-lexical lifetimes around. when I first tried rust, the lexical lifetime issue was very disappointing
<companion_cube>
indeed. I think it was just hard to implement right
<fengb>
I tried to learn Rust but all I got was a slap in the face :/
<mikdusan>
i agree it was a hard thing to implement, but it's like a cornerstone of the language
<Xavi92>
companion_cube: my experience in Rust is that it took me weeks to understand user-level code. In Zig it took me less than three days to understand the std library
<companion_cube>
I agree, but zig will have more runtime errors that you need to learn how to debug
<companion_cube>
(if you're not already used to C and gdb, that is)
<shakesoda>
Xavi92: that's kind of where I stand with it too, as with many complicated C++ codebases
<mikdusan>
and to be honest, I feel like rust dropped the ball and deferred that opportunity to get the lifetimes better
<shakesoda>
zig just doesn't let you build the same nature of demons
<Xavi92>
companion_cube: well, then we can eliminate at least one of this possible runtime errors by introducing explicit mutability, as suggested on my proposal :)
<kenaryn>
Xavi92, I would like to add that immutability by default is a good point to conquer medical software's market segment for it made zig more safe and can compete with Eiffel.
<shakesoda>
you can certainly make an awful demon in any language, mind you
<fengb>
I don't think Rust is bad. I just don't get Rust
<fengb>
It's just too much for me
<shakesoda>
I also don't think rust is bad. it's bad for me.
<fengb>
And I think it's great that we have a language that can be "fully safe"
<shakesoda>
I do, however, think C++ is bad, and I only suffer at its hands because I'm being paid to.
<shakesoda>
:D
<fengb>
But I'm not writing medical devices. I'm making stupid emulators
<companion_cube>
so… talking about footguns… why no RAII? :s
<shakesoda>
the moment zig has raii is the moment i drop zig
<shakesoda>
it is the champion of footguns, defer is better in every possible way
<fengb>
RAII is lifetime management. I'm not sure I want to deal with that
<Xavi92>
I don't think Rust is bad either. Actually, the good thing is programs usually worked once got them to compile. But I feel it more difficult to port into small microcontrollers, which is what I enjoy working on (and it's what I do for a living, too)
<companion_cube>
shakesoda: why is it more a footgun than defer?
<companion_cube>
to me that's the opposite, a small bit of RAII saves you from leaking resources
<shakesoda>
because defer hides nothing, raii is explicitly hiding control flow
<kenaryn>
I'm under the impression that among the 187 zig's contributors, 186 have alimentary job and only 1 live from his passion.
<fengb>
Maybe it can be better with something less anal than Rust, but with better language support than C++
<companion_cube>
shakesoda: hmm, what if there was an equivalent of `try` for resources? :)
<Xavi92>
kenaryn: I don't think you need to go to the medical market for that, nor the need to compete with Eiffel. Any embedded device that needs to operate for days or months (IoT anyone?) should benefit from safety features
<companion_cube>
you'd have to explicitly say "clean that at the end of the scope"
<fengb>
Don't you love how IoT runs on Python and Javascript? :P
<companion_cube>
and couldn't forget, unless you explicitly choose to discard the resource
<shakesoda>
imagine how awful interfacing with c would become
<companion_cube>
I'm not following?
<shakesoda>
I think I will just stick to a leak checking allocator
<kenaryn>
I agree with you Xavi92. Good point.
<companion_cube>
not all resources are memory
<Xavi92>
fengb: Not on anything I have access to as a programmer. Ever. :)
<companion_cube>
but error sets already make it weird to interact with C, don't they?
<fengb>
It's a good heuristic but by no means robust
<fengb>
Oh okay
<shakesoda>
the standard one is handy, but not strictly what I mean
<Xavi92>
I like the 'defer' concept, though. Saves boilerplate code (or goto statements) I'd have to write in C instead
<shakesoda>
defer and errdefer do pretty much everything I want for cleaning up on scopes. I'm not particularly opposed to some hint you could add to indicate the caller will have cleanup to do, though
<shakesoda>
and they're dirt simple
<Xavi92>
It'd be even better to somehow force the user to use 'defer' after specific functions (usually initialization ones), but I don't want to flood Zig's github with proposals :)
<shakesoda>
I very much want dirt simple
<companion_cube>
yeah, I think it's more explicit indeed
<companion_cube>
just like `try` really
<companion_cube>
explicit cleanup code that you can defer/errdefer or discard
<shakesoda>
this is the same complaint I have with most languages, really, they do all kinds of complicated crap that I have no desire for. I want simple.
<companion_cube>
but ofc different people want different things.
<companion_cube>
it's always a tradeoff
<fengb>
There's a floating proposal for resources. andrewrk still wants to handle async cancellation
<shakesoda>
robustness and comprehensibility fall off like a rock the further away from simple you get :)
<shakesoda>
if all your complexity is geared toward one of them you can subvert one of them.
<companion_cube>
damn I'd love to see serenityOS rewritten in Zig
<fengb>
Or in the case of
<companion_cube>
it's such a crazy project
<fengb>
C++, subvert both!
<shakesoda>
fengb: C++ subverts all positive attributes you could have
* shakesoda
gets back to work... on a mess of c++
<Xavi92>
:)
<Xavi92>
Good luck, shakesoda!
kenaryn has left #zig [""Keep up the excellence towards each other to bring in collective intelligence!""]
omglasers2 has quit [Quit: Leaving]
puzzleddev has joined #zig
<Xavi92>
companion_cube: didn't know about serenityOS. Looks like a nifty project :)
<Xavi92>
companion_cube: do you know the system requirements for it? I have a spare AMD K6-II laptop that might enjoy running it :)
<companion_cube>
it's pretty cool, and they have an IRC channel
<Xavi92>
companion_cube: just joined lol
<companion_cube>
mostly qemu I think but these days it works on *some* real machines
<Xavi92>
Bed time. See ya!
Xavi92 has quit [Remote host closed the connection]
dermetfan has quit [Ping timeout: 240 seconds]
<fengb>
Good night!
Snetry has quit [Ping timeout: 264 seconds]
Snetry has joined #zig
<fengb>
;.;[[=[
<foobles>
bless you
<fengb>
Sorry, toddler attack
<fengb>
It's a series of sad emojis
marijnfs has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
r4pr0n has joined #zig
wootehfoot has joined #zig
<pixelherodev>
Don't apologize, I'm curious what he has to say!
<pixelherodev>
It's a treatise on why `[[` should be the same as `[` in shell scripts!
<Snektron>
<companion_cube "damn I'd love to see serenityOS "> Someone is making a nice kernel i believe