<daurnimator>
error: declaration shadows primitive type 'bool'
<daurnimator>
pub fn @"bool"() bool {
<daurnimator>
^^ intentional that you can't ever create a struct method called "bool"?
hio has joined #zig
<daurnimator>
error: parameter of type 'type' requires comptime
<daurnimator>
^^ :( getting in the way of a refactor
darithorn has quit [Quit: Leaving]
_whitelogger has joined #zig
<daurnimator>
How can I set a field (dynamically)?
<daurnimator>
we can use @field to get it... but how do we set it?
<hryx>
daurnimator: curious, what's your use case?
<daurnimator>
hryx: for?
<hryx>
setting a field dynamically
* daurnimator
just mentioned 3 different issues in here and filed 4 bugs :P
<daurnimator>
hryx: initialising a struct with dynamically provided values
<hryx>
I'd love to see a hypothetical example if you have one off-hand. I had a thought about that feature but might be mixing it up with something else
<hryx>
ah heck, I was totally mixing @field up with @hasDecl
<hryx>
which made me concerned that a naughtly library could do e.g. `@import("@root").log_level = .Fatal` -- but I probably misunderstand something
<hryx>
sorry to derail!
<daurnimator>
hryx: to try and think of a simple example of what I want: `const ptr = allocator.alloc(MyConfig); for (@typeInfo(MyConfig).Struct.StructFields) |f| { @setField(ptr, f.name, conf.get(f.name, f.field_type)) }`
<hryx>
oh that is an interesting example
<hryx>
daurnimator: if I understand your example, you're taking a user-supplied config (json/toml/yaml/blah) and populating fields of an arbitrary struct with it?
<daurnimator>
hryx: yep
Tetralux has quit [Remote host closed the connection]
<hryx>
I'm used to struct tags in Go (the language I use at work) and that's how you'd normally solve this in Go (decoding a config to a struct). but I haven't thought much if that's appropriate for zig
<gonz_>
Given the nature of zig this is what I'd expect to be able to do
<hryx>
nothing in the "tags" proposal is particuarly compelling. maybe a builtin like @setField would be better
<hryx>
daurnimator, @setField seems reasonable, I say make a proposal. I'd link to #1099 and show how your idea is cheaper/simpler than tags and can accomplish similar things
<hryx>
(by "cheaper", I just mean that new builtins are cheaper to implement than syntax changes)
<gonz_>
Well, it's cheaper in terms of everything
<gonz_>
Less to learn, less to understand when reading source
<gonz_>
less to investigate
<gonz_>
"What does this tag do and where?"
<hryx>
damn good point
<daurnimator>
I haven't got to a point yet where I know I can't do it
<daurnimator>
e.g. maybe `@field(MyConfig, "foo") = blah` just works already
<daurnimator>
I'm on this weird issue where adding @panic makes the compiler segfault...
<daurnimator>
ha. `@field(MyConfig, "foo") = bar` already works
<daurnimator>
no need for a new proposal
<gonz_>
That's great
<gonz_>
This also works when iterating over the fields, then?
<hryx>
haha I just tried it to
<hryx>
I wouldn't have thought that @field works as an lvalue
<daurnimator>
gonz_: I don't understand that question?
<hryx>
daurnimator: run your original example you posted above
<gonz_>
Well, you were iterating over the fields before, no?
<daurnimator>
gonz_: yes iterating over the type fields works.
<daurnimator>
hryx: that was very very boiled down from what I have :P
<gonz_>
Yeah, I just wanted clarification that not only did the very basic example work, but the one you also pointed out before
<mq32>
so UI can be controlled from code behind directly
<scientes>
ahh so electron is very tightly coupled to nodejs and chromium's process architecture
<fengb>
s/nodejs/v8 but yeah
<fengb>
It's just packaging the entire browser into each app
<fengb>
Well... partially stripped down, but most of the meat is there
<fengb>
Anyway, it's big and bloated. I get why it's done but I'm never really happy
<dimenus>
fengb: I would consider that a named union
<dimenus>
ideally i'd be doing blah.a = 1
<dimenus>
but i appreciate the example
<fengb>
Oh I thought you meant anonymous like it has no type reference
<scientes>
so calling electron html+css+js is kinda disengenuous
<scientes>
its basically just a chrome frontend
<fengb>
I don't think we can do C11 style unions or structs
<mq32>
fengb, the sad thing is that most developers don't even get that it's just their usual chrome browser and you can actually get into the dev console in a lot of games and fiddle around with JS
<scientes>
fengb, also nodejs
<fengb>
scientes: I didn't not realize that... why is it so bloated
<Tetralux>
fengb: Re Jai being used in the Witness - AFAIK it's not - it is being used to make a complete game that Blow's planning to sell as his next game.
<Tetralux>
I also would _not_ call it vaporware - for the simple reason that it does exist and you can see it in action.
<Tetralux>
It does share the trait that it isn't publicly available in any form yet though - I can give you that.
<Tetralux>
I also can see where he's coming from on the "closed source until a little after release" - he wants to ensure it goes the way he wants without much external influence, and he doesn't want to deal with the wider community yet.
<Tetralux>
So I understand.
<Tetralux>
And he also wants to present a fully finished product so that people can rely on it like they do the C compiler.
<fengb>
I don't really agree with that. Zig has gone through radical changes for the better
<Tetralux>
Indeed - that was my first thought as well when he said that.
<Tetralux>
But it's also true that I don't want to deal with compiler bugs.
<Tetralux>
And if I want to write a fully-featured program in Zig - I would probably want to wait until it's more stable.
<Tetralux>
(I still might, but it's a consideration.)
<Tetralux>
And his point is that most people that use C++ are like that.
<Tetralux>
Well - "most people" - he doesn't want to "waste their time", as he put iot.
<Tetralux>
it*
<Tetralux>
I respect that reasoning.
<fengb>
Yeah I figured the game dev community is kinda like that... but it feels really different from what I'm used to
<Tetralux>
Likewise - but that's part of why I'm resisting the temptation to tell him that it's the wrong call.
<fengb>
As for stability... I've been mostly tinkering with wasm. And Zig's low-level wasm support is quite good, arguably better than C and I don't really understand Rust
<Tetralux>
Though honestly, if the compiler ends up being what it's like in his videos when/if it finally comes out, I'll be happy.
<Tetralux>
I think it made some pretty good decisions for what he wanted.
<Tetralux>
Quick iteration, allows 'exploratative' programming, etc.
<fengb>
I just want to see what we can learn technologically. I don't really agree with a lot of design decisions
<Tetralux>
And powerful enough where you have the power to implement compiler functionality if you want.
<gonz_>
Tetralux: For practical purposes Jai doesn't exist. It certainly isn't a good idea to argue for unproven things in it out of sheer speculation (with regards to features for zig, for example).
<fengb>
It has a bit too much magic for my taste
<gonz_>
The thing that spawned this discussion in particular; it makes some choices that are guaranteed to be reader hostile.
<Tetralux>
I'm inclined to point out that just because you don't have access to it, doesn't mean you cannot discuss the ideas.
<fengb>
But... I'm also not a game dev so it doesn't really speak to me :P
<Tetralux>
Though I do recongnise the benefit of having it in my hands.
<Tetralux>
And obviously would rather have it in my hands.
<Tetralux>
Further, yes gonz_, it's certainly less inclined towards readability.
<Tetralux>
But instead leans towards expressive power, and simplicity.
<fengb>
There's a lot of memory management in his videos that I only vaguely understand. That's not tuning I'm familiar with or even really care about
<Tetralux>
Like not having to name the iteration variable when you don't have to.
<fengb>
That's a perlism lol
<Tetralux>
It's also a nice one. How many times do you need to name that thing 'i' ?
<gonz_>
I think that pales in comparison to putting arbitrary things in contexts that may or may not be picked up by libraries, etc.
<fengb>
Zig favors explicitness. I can always track down where a variable came from. I think that's a big plus that's lost in many languages
<gonz_>
The amount of "What does this do when it's set in the context?" questions that will arise in even a moderately sized community will probably be ridiculous.
<Tetralux>
fengb: Any particular one? Or just in general? :p - And yeah - I do like that part of Zig honestly.
<Tetralux>
gonz_: My understanding is that the library would add the thing to the Context and you wouldn't care about it.
<fengb>
Tetralux: particular which? I'm not sure which line you're responding to
<Tetralux>
I mean - you'd read the library code before using it anyway, right? xD
<Tetralux>
fengb: The memory management one :)
<gonz_>
Jai also favors tagging AST nodes with arbitrary tags that may or may not be picked up by things. Anything, arbitrary tags. Those all also need to be figured out.
<Tetralux>
gonz_: Personally, I like that. Means that I'm not constrained by what Jon Blow thinks the compiler should be able to do for you.
<Tetralux>
I can just write a metaprogram that does it.
<gonz_>
Tetralux: Right, read the whole library just to figure out where they use the context and tags you have in your code? I think this is reader hostile.
<fengb>
Tetralux: the idea of manually allocating a large chunk of stack memory and breaking it down manually. I get why it's done... but it's not something I had ever considered doing
<Tetralux>
gonz_: You _can_ just search for the use of `context.`.
<gonz_>
You can already do source tagging on a library level with a sufficiently simple surface syntax. I don't think encouraging an ecosystem full of this is a great idea.
<Tetralux>
fengb: I don't remember seeing that.
<gonz_>
Tetralux: And get all of the hits for everything it might be using? Again, I think this is a pretty big cost to pay for something that probably was a bad idea from the beginning. At least with a certain set of values.
<dimenus>
is there a way to ignore the safety check in a regular union?
<gonz_>
Being explicit in the right place is IMO a much simpler choice to make
<dimenus>
eg my union is just two different views into the same data
<fengb>
It's in Jon Blow's "intro" rant video. It might not be in Jai proper...
<Tetralux>
gonz_: grepping for 'context.' would show you usage; grepping for '#add_context' would show you everything that's added to it, AFAIK.
<fengb>
dimenus: packed union
<gonz_>
Spreading out these kinds of things in other people's code is a proposition I'm not ready to accept as a good choice, least of all in a language that only exists on like 10 computers in the world.
<Tetralux>
But yes - it's fair to say that he's designing the language _he_ wants.
<Tetralux>
I've already polluted #zig with this for long enough probably but
<dimenus>
fengb: thanks
<Tetralux>
Suffice it to say, I think it's makes for a good exploratory programming language.
<Tetralux>
And I think that being able to do a simple grep to find everything like that, is a good step to make.
<gonz_>
It would be even easier if the code was simply in the correct place instead of using a context as a middle man
<gonz_>
i.e. passed as a parameter
<fengb>
I like Jai for the concepts it represents. I don't think I'd use it much though
<scientes>
but it stands for vaporware
<scientes>
until you can run something you never know
<scientes>
especially with software
<fengb>
"This syntax is borrowed from the Pascal family, along with using ^ to denote a pointer, as it is pointy."
Tetralux_ has joined #zig
<scientes>
hehe
<Tetralux_>
fengb: Isn't that Odin xD
<fengb>
Random history question: why did C choose * ?
<Tetralux_>
Commonly available character?
<Tetralux_>
I don't actually know - though I think I did know at one point.
<fengb>
Oh yeah... Zig actually rejected ^ because it's harder to type on a non-English keyboard
<gonz_>
I always thought that `->` made sense, because it points to a think.
<gonz_>
thing*
<mq32>
var x : →int;
<scientes>
yeah but its annoying
Tetralux has quit [Ping timeout: 248 seconds]
<scientes>
i spend too much time fixing C compiler errors because i got the . vs -> wrong
wilsonk_ has quit [Ping timeout: 246 seconds]
<fengb>
Ha that looks pretty cool
<mq32>
i don't really understand why they made a difference in the first place
<scientes>
but meh, it would be fine, the reading vs writing thing
<mq32>
it's not like i could access a pointer with "." anyway
<fengb>
Because -> isn't just a struct thing (confusingly enough)
<scientes>
arrays are also confusing
<scientes>
because they automatically become pointers
<mq32>
but only sometimes
<scientes>
half the time i use &foo[0] just to make it clearer
<mq32>
yeah, true dat
<mq32>
oh, btw
<mq32>
did you know that arrays actually decompose into a pointer to the array which then conventiently coerces to a pointer to the first element?
<fengb>
&0[foo]
<mq32>
one of the best constructs i saw in the last time was the XML comment
<fengb>
Cause why shouldn't we index literals by variables?
<mq32>
a <!-- b;
<Tetralux_>
It would be kinda neat if typing special chars like the arrow was trivial.
<Tetralux_>
Like `->int`
<mq32>
Tetralux_, do you use windows or linux?
<mq32>
→int
<Tetralux_>
Technically both. Usually Windows though.
<fengb>
My favorite "anti-pattern" in C is while `(i --> 0)`
<mq32>
linux has ternary and quarterny mappings with AltGr and Shift+AltGr
<mq32>
you have a lot of symbols like … or × or ÷
<mq32>
also i have a compose key instead of caps lock and dead keys
<mq32>
that's just more convenient to type
<Tetralux_>
It's just like... I think the `->int` is easier to read if it's literally an arrow... but I can't type it xD
<mq32>
we need more compose key!
<Tetralux_>
I'd have to either type 5 chars to Alt-code it or something, or set up a hotkey.
<mq32>
"compose", "-", ">" => "→"
<mq32>
♥
<Tetralux_>
At least that would make more sense to remember how to type it XD
<fengb>
That'd actually fix accent keyboards too
<fengb>
"Fix". I suppose it's not technically broken
<mq32>
fengb, yeah
<mq32>
compose key is really great
<Tetralux_>
fengb: I'm not sure about that - people that type accent'd chars all the time prob would not like that XD
<mq32>
"c" + "," => "ç"
<lunamn>
the real solution would be alt+shift+u then type emoji representing the operator manually /s
<fengb>
We need a /s emoji
<Tetralux_>
Definitely.
Tetralux_ is now known as Tetralux
wilsonk_ has joined #zig
<lunamn>
who wouldn't want to use U+000027a1 BLACK RIGHTWARDS ARROW to access struct members :)
<scientes>
and why the hell did they need an emoji of that?
<scientes>
there already are plenty of other arrows in unicode
<mq32>
i think nowadays emoji and "unicode codepoint" is pretty similar
<fengb>
I don't think people conside 芋 an emoji >_>
<mikdusan>
`var foo = →(a: u32) {};` how did i miss that opportunity?
<fengb>
We’re back where we started
<halosghost>
mq32: haskell uses \space separated args -> body
vexu has quit [Quit: WeeChat 2.5]
<halosghost>
mq32: and, incidentally, I like the idea of using ℕ and ℤ for bignats and bigints, and using nN and zN (or, alternatively, nN and iN) for width-constrained types
<halosghost>
mq32: I just don't propose it these days because people seem to hate it when I make that suggestion
laaron has quit [Remote host closed the connection]
<halosghost>
Tetralux: also, there's a port of Compose to windows that leverages XCompose files
<halosghost>
or, if you're lazier and you don't mind some odd behavior every once in a while, you can just put that in your .xinitrc (or similar for your DM if you use one)
<halosghost>
…
<halosghost>
wow
<halosghost>
that's…
<halosghost>
k
* halosghost
forgets how… complex gnome is
<scientes>
well i want it to work for wayland too
<halosghost>
huh
<halosghost>
is that possible?
<scientes>
oh course it is
<halosghost>
I was under the impression that compose in wayland had not been accomplished yet
<scientes>
oh......
<halosghost>
afaik, compose is handled by the IME
<halosghost>
I haven't read yet about wayland-compatible IMEs that do compose
<halosghost>
that doesn't mean they don't exist
<halosghost>
it's been about six months since I last seriously looked into wayland
<SyrupThinker>
I have found this std lib error that I can reproduce for several 32 bit architectures: https://godbolt.org/z/nWiadc
<SyrupThinker>
I'm not certain whether replacing usize() with a intCast is the correct way to solve this
<SyrupThinker>
Should I just open a issue or make a PR with that as a possible fix
<fengb>
That looks like a bug
<SyrupThinker>
Also I'm getting a bunch of compiler warnings with gcc 8, not sure whether thats considered issues worthy considering its pretty obvious
<emekankurumeh[m]>
what sorts of warnings?
<emekankurumeh[m]>
because the compiler is supposed to be compiled with -Werror
<SyrupThinker>
Yes, sorry, they are errors
<SyrupThinker>
I took Werror out to see whether it fails on something else
<SyrupThinker>
It didn't
<SyrupThinker>
The most common was maybe-uninitialized
<emekankurumeh[m]>
can you upload a paste somewhere of the warnings?
<fengb>
For the rand issue, it makes the most sense if we could rand(usize) instead of u64... but if not, explicitly casting makes sense since we mask it
<strmpnk>
emekankurumeh[m]: I occasionally use sublime with Zig. I'll look at it. It's worth noting that Sublime Text supports test files for syntax definitions, which might be worth the investment.
<emekankurumeh[m]>
syntax tests only sublime-syntax files and github's linguist doesn't support sublime-syntax files
<emekankurumeh[m]>
but thank you for taking time to check
<strmpnk>
emekankurumeh[m]: Ah. So this is for linguist as well as sublime?
<emekankurumeh[m]>
yes, that's why i don't want to accidentally break zig highlighting on all of github for a couple months
<andrewrk>
appreciate that :)
<emekankurumeh[m]>
no problem, now i just need to update the vscode syntax
<strmpnk>
Browsing lots of the standard library... seems to be good so far.
<emekankurumeh[m]>
it might choke on async function declarations, but i didn't bother with those because async is getting reworked
<strmpnk>
Good point. I don't have any real examples of that handy but I imagine it'll be easier to patch once it appears in the repo anyway.
<strmpnk>
The scopes on the grammar are pretty basic, which limits some of the more advanced syntax features and can look odd in some color schemes but overall I think this looks good. No glaring bugs found.
<emekankurumeh[m]>
the meta scopes were the hardest for me
<emekankurumeh[m]>
i also tried adding a config file to make more scope visible in the index but that didn't seem to work
<strmpnk>
The scope taxonomy seems to be a little non-portable anyway. Some of the meta scopes only make sense for certain kinds of languages.
<andrewrk>
async syntax is about to change
ntgg has joined #zig
<emekankurumeh[m]>
i was kind of on the fence about breaking up the next release on the grounds of that wouldn't be enough time but andrew seems to be proving me wrong
kristoff_it has joined #zig
Akuli has quit [Quit: Leaving]
<andrewrk>
what do you mean?
<dimenus>
is there a way to set parts of a @Vector without casting?
<dimenus>
eg implementing _mm_set_ss
<emekankurumeh[m]>
i don't mean to be rude or insulting but the 0.5.0 release seemed really ambitious to me, at least in terms of scope
<dimenus>
nvm, ignore that question
<gonz_>
Heh, how is that rude?
<emekankurumeh[m]>
but i suppose the whole zig project needs to be ambitious if it plans to overthrow c
kristoff_it has quit [Ping timeout: 258 seconds]
<andrewrk>
emekankurumeh[m], oh yeah sure. I don't see those milestones as accurate estimates of what will actually be done for each release. the milestones just mean "decide what to do regarding this issue before the release"
<andrewrk>
"Accept and resolve these issues, reject, or postpone them before releasing 0.5.0."
avoidr has joined #zig
ntgg has quit [Ping timeout: 244 seconds]
vexu has joined #zig
Ichorio has joined #zig
return0e has quit [Ping timeout: 258 seconds]
return0e has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
<ltr->
what is the elegant way to cast an slice to [*c]u8 ?
<fengb>
slice.ptr
<ltr->
nice!, missed that field
<ltr->
:D
<ltr->
@ptrCast([*c]const u8, &slice[0]) i was using that ugly thing.
<ltr->
ty
ltr- has quit [Quit: leaving]
eagle2com has joined #zig
ltriant has joined #zig
eagle2com has quit [Remote host closed the connection]
<Sahnvour>
how was the experience getting sokol to work in zig?
eagle2com has quit [Ping timeout: 268 seconds]
<ffddr>
With my hack to make a defaults for all the sokol's structs - it was pretty good, but its super not production ready solution obviously. With the master zig sokol usage will be a bit too painfull right now - it will involve hand writing or generating somehow a lot of wrappers like https://github.com/floooh/sokol-zig/blob/master/src/sokol.zig
vexu has quit [Quit: WeeChat 2.5]
wootehfoot has quit [Read error: Connection reset by peer]
Tetralux_ has joined #zig
Tetralux has quit [Ping timeout: 272 seconds]
<shachaf>
andrewrk: What's the reason for having "async" be implicit in function declarations when it presumably resuls in very different generated code?
<shachaf>
I think this is pretty surprising for a language that e.g. doesn't allow operator overloading for this reason (I think).