<fengb>
Hmm... would it be expensive to loop through per match?
<fengb>
I guess I should test it out
<andrewrk>
fengb, you should be able to take advantage of comptime fn call caching
<Tetralux>
donpdonp: Note that it's undefined in the sense that it's not initialized to anything in particular; it's _just_ the correct number of bytes casted to an OtherThing, and then you get a pointer to it. So you cannot, and should rely on it to be in any particular state until you set it.
* donpdonp
nods
kristoff_it has quit [Ping timeout: 244 seconds]
* Tetralux
raises both arms above my head
<Tetralux>
YAY
<Tetralux>
Making progress :p
<donpdonp>
well thats enough Zig for today. thx again Tetralux, andrewrk for helping me level-up in zig.
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<hspak>
Couple questions on arrays: does '[_]' mean size is set at compile time? And second, if I want to store an array of strings of arbitrary length, what's an acceptable way of doing that? I think I want a [][]u8, but grepping the stdlib doesn't come back with much so not sure...
<daurnimator>
hspak: yes it does.
<daurnimator>
hspak: yes you want [][]u8 which is a slice of slices of u8
<hspak>
daurnimator: thanks :)
<nero57>
When I modified my zig source, and then I executed zig build, the generated target file seems not the newest version, and I must remove the zig-cache folder, and then execute zig build again, the target file is now the latest version.
vramana has joined #zig
<nero57>
Is there any way to update the generated object file at compile time?
<nero57>
Or is there any way to update the generated target binary file at compile time?
<nero57>
I didn't find a type alias in the document
laaron has joined #zig
<daurnimator>
bgiannan: what do you mean by "aliases"? you can just pass types around at comptime. if you mean distinct types, that's an open proposal I think.
<bgiannan>
you're right i can just do: `const MyNewType = std.ArrayList(i32);` ?
<nero57>
Type assignment can be considered an alias
<nero57>
Is there any way to turn off caching when executing zig build?
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<bgiannan>
it it possible to use a type as a key of an hashmap?
laaron has quit [Remote host closed the connection]
dbandstra has quit [Quit: Leaving]
LargeEpsilon has quit [Read error: Connection reset by peer]
<daurnimator>
bgiannan: types are only really available at comptime. you could probably build a monstrosity of a comptime recursive function to dispatch on type....
<bgiannan>
how about using @typeName as a key? would it be reliable?
kristoff_it has joined #zig
avoidr has quit [Quit: leaving]
ntgg has joined #zig
Mr_Slurpy has quit [Ping timeout: 260 seconds]
<samtebbs>
nero57: If you're using zig build-* the try adding --cache off
<PMunch>
Hi everyone. We have an interesting (hopefully) proposal for you! Since last years FOSDEM conference the people over in #nim have been talking about creating a developer room for small/new/unknown languages. The room will feature presentations about parts of the language, or specific cool projects done in a language. If anyone from the Zig community wants to join in on the effort, come join us over in #fosdem19newerlangs.
alexander92 has joined #zig
<alexander92>
hey guys since last years FOSDEM conference the people over in #nim have been talking about creating a developer room for smaller/newer languages. The room will feature presentations about parts of the language, or specific cool projects done in a language. If anyone from the Zig community wants to join in on the effort, come join us over in #fosdem19newerlangs
<Tetralux>
bgiannan: It can.
<bgiannan>
Tetralux, i had another issue, figured it out since :)
<Tetralux>
Good, good.
<Tetralux>
Also, I'm amused that the pair of you, alexander92, PMunch, said word-for-word the exact same thing.
<bgiannan>
most errors are helpful, but a few i encountered are a little misleading
<alexander92>
yes, i am very lazy and very copy-pastey :P
<Tetralux>
bgiannan: Yeah - many of them IME could give you much more context and suggestions.
<PMunch>
You cheat alexander92
porky11 has joined #zig
dimenus has joined #zig
<bgiannan>
Is it normal that @alignOf(fn (args: ...) void) is 0 ?
<bgiannan>
I'm trying to make a ArrayList of functions
<fengb>
That doesn't look right
<fengb>
I don't think you can use varargs dynamically
<bgiannan>
why not?
<fengb>
Because it's a compile time only construct
<fengb>
When working with memory directly, the compiler needs to know how to put variables on the stack
<fengb>
Varargs basically say "anything goes" so the compiler needs to do it at the callsite
<fengb>
Which doesn't exist at compile time in function pointers
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<kristoff_it>
Hi, I'm trying to write a function that needs to handle HashMap types. I need to get key and value types but doing T.KV.key doesn't work, presumably because .key is a struct field and not a declaration inside KV. Is there an easy way to do that without resorting to @typeInfo?
<kristoff_it>
THis is the error that I get `error: container 'std.hash_map.KV' has no member called 'key'`
<samtebbs>
kristoff_it: KV is a type, so you need to use an instance of the type instead
<samtebbs>
The `Entry` struct has an instance of KV
<samtebbs>
What are you trying to do with the map?
<fengb>
You could do std.HashMap(YourKey, YourValue).KV
<fengb>
But you should probably assign std.HashMap(YourKey, YourValue) to a const for easier use
laaron has quit [Remote host closed the connection]
<kristoff_it>
samtebbs: thanks, I'll try that. I'm writing a redis client and I'm toying with the idea of having the parser understand basic types + the ones in the stdlib, so if you try to get a hashmap key from redis, the parser should be able to deserialize it both as a struct (assuming the field names match) or in a HashMap of the right kind
<kristoff_it>
depending on what the user asks for
laaron has joined #zig
<fengb>
Oh did you want the declaration? That'd be std.meta.fieldInfo(type, "fieldName")
<kristoff_it>
yes that's what I want
<kristoff_it>
but I see that the std.meta code also goes through @typeInfo
<fengb>
Yeah, it iterates through the fields
<kristoff_it>
anyway, thanks, this definitely faster than iterating over the fields myself
<fengb>
np
<kristoff_it>
is there a big reason why doing .KV.key cannot work?
<fengb>
KV.key is a struct field
<fengb>
For "pub const key = 1;" in the middle of structs
<fengb>
Like static members in Java
<fengb>
field isn't the right word. Declaration?
<kristoff_it>
yes I'm aware of the difference between a struct field and a "namespaced" declaration inside a type. I think declaration fits and it's what the language calls those (e.g. @hasDecl)
alexander92 has quit [Ping timeout: 258 seconds]
<kristoff_it>
I was just wondering if there is any ambiguity (or other problem) in letting references to a struct field return the field's type
darithorn has joined #zig
<nero57>
Is the const declaration in a function is stored in the function stack frame?
porky11 has quit [Ping timeout: 264 seconds]
<samtebbs>
kristoff_it: Oh so you wanted the type of KV.key
<samtebbs>
There is `@typeOf` but I'm not sure if it would help here
bheads_ has joined #zig
bheads has quit [Ping timeout: 245 seconds]
bheads_ is now known as bheads
porky11 has joined #zig
nero57 has quit [Remote host closed the connection]
<bgiannan>
somehow i had to add `--library c` to run a test that uses the c_allocator on linux but not on macOS
porky11 has quit [Ping timeout: 250 seconds]
<andrewrk>
bgiannan, libc is always linked on macOS because it is the syscall ABI
porky11 has joined #zig
<bgiannan>
ah makes sense thanks!
<Tetralux>
Q: How do you get a list of keys in a HashMap?
<Tetralux>
Just iterate it?
<dimenus>
yep
<Tetralux>
If you want to write a fn that works on any map, say encoding to MsgPack for instance, you want to have a reasonable interface convesion.
<Tetralux>
Is it reasonable to say "It must have an iterator that returns *KV where a KV is essentially a tuple of a key and its value?
<Tetralux>
"If it doesn't have that, it's not a map."
<donpdonp>
I was surprised there was no hashmap function that returned []KV to use with for(slice) |value| { }
<Tetralux>
It's because that would have to copy every element and allocate it.
<Tetralux>
That's not fast.
<Tetralux>
Personally, I'd like to be able to for(iterable) but.... .v.
<donpdonp>
for(iterable) would be better, that would be a new language feature yes?
<gonz_>
It wouldn't necessarily be better at all
<gonz_>
Suddenly when you see `for` you can't guarantee anything about what's happening.
<Tetralux>
.. because the iterator can do anything.
<Tetralux>
.. whereas for on a slice _just_ does a basic while loop over the length.
<fengb>
foriter keyword :P
<Tetralux>
.. and calling .iterator manually is meant to communicate to you that it could do whatever.
<Tetralux>
I'd argue that doesn't really matter much though.
<torque>
I don't understand how `for (iterable)` is appreciably different than `while (keys.next())`
<Tetralux>
Like - you still don't know what it's doing without looking.
<Tetralux>
torque: That's basically my point.
<Tetralux>
I don't know about anyone else here, but I never write a for loop.
<Tetralux>
They're all whiles.
<Tetralux>
Because of this.
<torque>
is that a problem?
<torque>
are you some kind of loopist
<Tetralux>
XD
<Tetralux>
for (map) |entry| { ... }
<Tetralux>
vs
<Tetralux>
var it = map.iterator(); while (it.next()) |entry| { ... }
<Tetralux>
There's no point writing a for loop
<Tetralux>
Even for a slice
<Tetralux>
If you change it to literally anything else
<Tetralux>
You have to change the entire structure of the loop.
<Tetralux>
That's friction I can do without.
<Tetralux>
If you start with it being a slice and then realise it needs to be an ArrayList, for example.
<Tetralux>
May as well just write a while loop to begin with.
<fengb>
It's 2 lines
<donpdonp>
yeah thats funny id say the 'var it = ' shows why a for loop is preferable
<bgiannan>
i can't seem to be able to define a function inside a test?
<donpdonp>
as a programmer i would like for(anything_array-ish) |item| { } to "just work" on slices or maps or any thing array-ish.
<fengb>
bgiannan: functions can only be inside of structs or top level files atm
<donpdonp>
because its concise. i dont want to create an iterator variable and manage it.next() (I have to remember its 'next')
<Tetralux>
bgiannan: You cannot declare a fn in any local scope, no. You will though when/if we get anonymous fns.
<torque>
conciseness is not part of the zig philosophy though
<bgiannan>
Tetralux, noted
<Tetralux>
.. which isn't an _ideal_ solution IMO but... it'll work.
<Tetralux>
torque: Is it _not_ part of common sense though?
<Tetralux>
Like, what I just said might sound a little harsh, but.
<fengb>
bgiannan: a common pattern is doing "const Foo = struct { fn bar() }; Foo.bar"
<torque>
that's extremely minor syntactic sugar that in theory could hide a lot of complexity. if you're advocating iterators, imo operator overloading is in the same vein and makes much more sense
<fengb>
It's kludgy but lets you define functions in any scope
<Tetralux>
torque: With respect, I think I might value your time more than you do :)
<Tetralux>
And also general mental health xD
<Tetralux>
Friction is a terrible thing in something you use ever day.
<Tetralux>
every*
<gonz_>
We already have tons of languages that care lots about removing friction from the act of writing code
<torque>
friction is very important. it prevents people from sliding around uncontrollably
<gonz_>
And almost none that care about people who read code
<Tetralux>
torque: There are other ways to have control authority without friction xD
<Tetralux>
The very idea that friction is desirable is a terrible idea.
<Tetralux>
It makes doors squeak.
<Tetralux>
You don't want that.
<fengb>
This metaphor is breaking down
* Tetralux
grins
Akuli has joined #zig
<gonz_>
"Friction" is not a desirable value. You may have more friction in a language when your top priority values are *not removing friction*, however.
<Tetralux>
Iterating over a structure's data is something you do all the time in any imperative language.
<Tetralux>
Surely it's not too much for a programmer to understand that iterating over a slice is a lot simpler than iterating over an arbitrary struct?
<Tetralux>
Not to mention that fact that making something you do literally all the time not completely trivial is deliberately making the programmer's life harder.
<gonz_>
I'm pointing out that it's possible to prioritize things other than the writing of code, is all.
<gonz_>
It's very under-valued
<Tetralux>
And I'm saying that for loops should be as trivial as struct field dereferencing xD
<torque>
I disagree with a lot of the terminology you've used anyway
<Tetralux>
Except also not handicapped.
<Tetralux>
torque: That's okay. The terminology isn't the important part.
<torque>
well it is, because it's the main thrust of your argument
<torque>
I don't think looping over a data structure is nontrivial as it stands
<Tetralux>
Depends on the structure.
<torque>
depends on the interface provided by the structure
<Tetralux>
I'll note that I'd accept this syntax instead:
<Tetralux>
while (map.iterator()) |entry| {}
<gonz_>
There's a lot of emotion in the argument, first of all. Something is handicapped, making the life of a programmer harder, "[it's] a terrible thing...", etc.
<Tetralux>
Still not what I want, but better.
<Tetralux>
gonz_: I think we're talking at cross purposes; saying that forcing anyone to do busy work for something that you do all the time is not controversial
<Tetralux>
.. which is what I mean when I say it causes friction.
<gonz_>
I think you see friction only when writing a first draft
<gonz_>
Whereas friction can also be about making changes
<Tetralux>
I mean both things.
<gonz_>
And I don't see a whole lot of that perspective from the majority of your arguments
<Tetralux>
The abilty to make changes is part of the second one.
<Tetralux>
I'm not sure I quite understand your point.
<gonz_>
Fair enough. What exactly are you arguing for with regards to `for`/`while`. Let's just establish that first.
<Tetralux>
It's a couple of related things: 1) I never use for, even for slices, because it's more resistant to changing the code to using a type with a custom iterator than is worth it.
<Tetralux>
But for is simpler to type, and communicates the intent just as clearly.
<Tetralux>
I'm kinda blanking on what the part is right now.
<Tetralux>
the second part*
<donpdonp>
for *implies* iteration, thats why for(slice) is readable. also zig already alllows a 'smart' for with for(error-union) |value| {} else |err| {}. It seems a small and useful addition to determine if for(expr) supports .next() (or some other test for what is iterable) then for(array_list) |item| {} just works. while seems well established that it te
<donpdonp>
sts for a boolean and id like that to stay non-smart.
<Tetralux>
Right.
<gonz_>
I don't think the minimal friction of having to change to a `while` is meaningful. I think the friction of reading code and not knowing what goes in a `for` matters more.
<torque>
>for(expr) supports .next() (or some other test for what is iterable)
<torque>
this has the problem that it requires the language to be aware of a userspace interface
<torque>
of course you already have functioning iterators with `while` so the benefit seems to be very minor anyway
<gonz_>
I don't feel too strongly about this issue in particular, but I think it displays the same pattern as everything else; an over-emphasis on the programmer right now.
<Tetralux>
torque: If that's the problem, I'd suggest removing for altogether.
<Akuli>
i don't think having a programming language be aware of userspace stuff is bad, i quite dislike how java's int and long are "primitives" and you can't use them like you can use objects
<Tetralux>
In practice, no-one would need to use `for` in real code unless they ONLY EVER wanted to have a slice.
<Tetralux>
Which they can't ever know
<Tetralux>
Because things change over time.
<Tetralux>
It's also worth noting that there is a more powerful way to implement an iterator than repeatedly calling next.
<donpdonp>
torque: i see, maybe its not a small change at all :)
<Akuli>
so this `var iter = something.getIterator(); while (iter.next()) |val| { ... }` would change to this `for (something.getIterator()) { ... }` ?
<Tetralux>
Either that, or just `for (something) {}` depending on how you did it.
<Akuli>
(forgot |val| from my for loop)
<donpdonp>
Akuli: or a step further, if there were a standard for getting the iterator then for(something) |item| {}
<Tetralux>
Personally, I don't really like having to have a whole extra struct and making that work to do something that so simple as iterating over it.
<Akuli>
donpdonp, i think that would be a bit too much magic for zig
<Akuli>
i'm used to it in python, but it's not a thing i would want in zig
<donpdonp>
Akuli: i can understand that, but whats the test for the expr in for(expr) to see if its an error-union or an iterator-type?
<Tetralux>
You could always make iterating a slice be `for (slice.iterator()) |item| {}` too... ;)
<Akuli>
what does the error-union thing do anyway :D
<Tetralux>
It breaks when it returns an error.
<Tetralux>
Otherwise it keeps looping.
<Akuli>
calling it in the beginning of each loop?
<Tetralux>
I believe so.
<andrewrk>
while and if are the same; only difference is with while, control flow continues
<donpdonp>
var valueOrError = doit_maybe(); if (valueOrError.error) { err; } else { var winner = valueOrError.value}; that simplifies into if(doit_maybe()) |value| {} else |err|
<Tetralux>
^
<donpdonp>
folding the temporary variable into for looks like avoiding the temporary iterator varaible into for o^O
<donpdonp>
which is why for(iterator) is so attractive looking :)
<Tetralux>
Also, you actually don't _need_ it to know that it has to call next or whatever.
<Tetralux>
Maybe more like - though maybe this isn't the best way exactly - but
<Tetralux>
Well---okay--- my first thought was something like
<Tetralux>
fn next() @iterator {}
LargeEpsilon has quit [Ping timeout: 252 seconds]
<Tetralux>
And then Zig's for loop goes "Does this thing have a fn marked as the iterator?"
<Tetralux>
But that's a little funky.
<Tetralux>
Because then you'd have to do the same thing with 'next'.
<Tetralux>
But I don't really like having the extra iterator struct anyway.
<gonz_>
And then the programmer goes "Does this thing have a fn marked as the iterator?"
porky11 has quit [Excess Flood]
<Tetralux>
That's true, but you could just assume it did and get a compile error xD
porky11 has joined #zig
* Tetralux
is being partly unserious.
<Tetralux>
The compromise position is `for (map.iterator()) |entry| {}`
<Tetralux>
But I'd like to force slices to need that too.
<Tetralux>
You know
<Tetralux>
Because you don't want for to need to understand userspace code.
<mikdusan>
i haven't sussed it out enough but i'd like to see compiler recognize loop trait for a struct. it might be 2 funcs, one for const and one for non-const and trait would identify func name
<Tetralux>
To be clear - I don't want to do that.
<Tetralux>
mikdusan: I think that's kinda the same as iterator struct.
<Tetralux>
Honestly, I'd prefer a slightly novel way.
<Tetralux>
Essentially, the for loop identifies a member fn for the type, say it looks for `.iterate`
<donpdonp>
the zig docs refer to Allocator as an interface, so it seems an Iterator interface is doable in zig as it is today. I'm not sure if its efficient to have for(expr) test for it.
<Tetralux>
And it passes a comptime-known function pointer to it.
<Tetralux>
.iterate is then implemented to iterate over the structure, and @inlineCall that function pointer, passing the current element in, at the appropriate point.
<Tetralux>
The idea being that there is no function call at runtime.
<Tetralux>
To either .iterate, or the function ptr.
<Tetralux>
Both are just gaurenteed to be inlined.
<Tetralux>
The benefit of this is that the iterate's code is literally just documenting how you iterate the structure.
<Tetralux>
.. but in the form that you'd write it, if you just knew how the structure worked.
<Tetralux>
.. and then the programmers that use the code can just use the for loop.
porky11 has quit [Ping timeout: 250 seconds]
<Tetralux>
Not only that, but it's one function for the entire iteration procedure.
<Tetralux>
And it's much shorter.
<Tetralux>
And is exactly the code you wanted to write, and almost no-more.
SimonNa has quit [Remote host closed the connection]
<Akuli>
what would it do if you use 'a' or 'list' or some variable in { } of the loop? magic?
<Tetralux>
It would work as expected, because the call to iterate never happens. That's @inlineCall as well.
<Tetralux>
It basically just pastes the content of .iterate into the caller, replacing the for loop you wrote, behavior-wise.
<Tetralux>
It's no more magic that for loops currently are.
<Tetralux>
Except that you can fill out the body of what it does in user code.
<Tetralux>
no more magic than*
<Tetralux>
.. and write the iteration code in the way you would to iterate the structure, and no more.
porky11 has quit [Ping timeout: 264 seconds]
porky11 has joined #zig
kristoff_it has joined #zig
<Tetralux>
[Updated paste.]
<Akuli>
i like how you don't need to create a separate ArrayListIterator struct or similar
<Tetralux>
That is exactly what I love so much about this approach.
<Tetralux>
I've always hated having to do that in every language that does it.
<mikdusan>
what would it look like if iterate can return an error?
<Tetralux>
As well as how the way you write such an iterator is very different from how you'd iterate over it otherwise.
<Akuli>
python's yield does a somewhat similar thing
<Akuli>
class ArrayList: def __iter__(self): for i in range(self.len): yield self.at(i)
<Tetralux>
Akuli: .. accept of course that Python's way is slower.
<Tetralux>
;)
<Akuli>
yeah it is
<Tetralux>
mikdusan: I'm not sure you'd need it to?
<Tetralux>
Can you give an example?
<Akuli>
a failing iterate() would be a bit weird imo
kristoff_it has quit [Ping timeout: 258 seconds]
<Tetralux>
You could always allow for on an error union to work like while does currently on an error union. /shrug.
<mikdusan>
Tetralux: std.process.ArgIterator
<Akuli>
hmm now that doesn't seem weird at all
<Akuli>
/ prints 8 (1+2+4)
<Akuli>
// prints 8 (1+2+4)
Mr_Slurpy has joined #zig
<Akuli>
lol i had a similar thing in a comment today, i had written: -1 + 2 = 0
<Tetralux>
Akuli: it even said 7 to begin with an I changed it cause I thought it was wrong LUL
<Tetralux>
Yeah - I'm not sure iterating should fail.
<Tetralux>
We don't support while(errUnion) else {} right?
<Akuli>
ArgIterator is a real-life example where a failing iterator makes sense
<Tetralux>
Well remember, you have control what it'd do.
<Tetralux>
Well
<Tetralux>
"You" = "the person who wrote the iterator"
<donpdonp>
for(iterable) might be moot with async enabling array_list.for(process_each_item_function)
<Tetralux>
Ugh.
<gonz_>
Tetralux: Error unions work with `while (...) { ... } else |err| { ... }`
<gonz_>
Or what did you mean?
<Tetralux>
gonz_: Yeah - okay - in that case, mikdusan, you could just give for an else branch for if iterate returned an error.
<Tetralux>
That's a possiblity.
<Tetralux>
You could also `for(try list) |item| {}` but maybe that's a little too weird?
<Tetralux>
I dunno - I'd prob be okay with it.
<Tetralux>
`try for (list)` is another option.
<Tetralux>
But `for (list) {} else |err| {}` is the simplest compromise.
<Tetralux>
gonz_: What happens to an error if you use while(errUnion) and don't have an else?
<Tetralux>
Does the error get lost, or does it compile error?
<Tetralux>
Presumably the latter?
<Akuli>
hmm, since if and while are mostly same thing, does this work: if (foo) : bar=123 { ... }
<gonz_>
Tetralux: If the thing you're using can return an error whatever you're doing in the loop has to be able to use that error union.
<gonz_>
So compile-time error
<gonz_>
So you're checking for it somewhere, either where you're passing it to in the loop or immediately in the loop itself.
<Tetralux>
gonz_: Okay good. That's what I hoped.
<Tetralux>
In that case, it can work the same here.
<Tetralux>
for (list) |item| { ... } else |err| { ... } // must have an else.
<Tetralux>
( .. if it can fail.)
<gonz_>
I misspoke slightly; the actual `while` is what is checked. But yes, compile-time.
<gonz_>
Has anyone used the stb libs with Zig?
<gonz_>
Do they generally translate cleanly? I know I saw someone's project use `stb_` something at some point but can't remember if it was `image` or something else.
<andrewrk>
translate-c isn't feature-complete enough to translate the header files directly into zig but it should be possible eventually
<gonz_>
Coolio
<Mr_Slurpy>
Hello, I'm trying to compile the "vulkan-triangle" example but I keep getting a `error: no member named 'install' in struct 'std.build.LibExeObjStep'` among other errors. Does anyone know how to fix this?
<andrewrk>
Mr_Slurpy, you'll need to use a master branch build of zig
<andrewrk>
there are master branch builds available on ziglang.org/download
<Mr_Slurpy>
Ah ok. Would the package from the AUR work? Or I have to download it manually?
<andrewrk>
I'm not sure what version the AUR package is
<gonz_>
andrewrk: The array is passed to what is basically `zig cc`? I.e. you could put `"-D STBI_NO_PSD"` in that array to define that?
<andrewrk>
Mr_Slurpy, you can use `zig version` to find out
<andrewrk>
gonz_, yes
<Mr_Slurpy>
It seems to be 0.4.0
<Mr_Slurpy>
I guess ill dl it manually
<andrewrk>
at this point there have been 1136 commits to master since 0.4.0
<gonz_>
What did the last release cycle end up at in total?
<Tetralux>
It's only slow if want to preserve order.
<Tetralux>
You don't necesarily care about order.
<Akuli>
if you don't care about the order, then why would you use an array in the first place?
<Tetralux>
....
<Tetralux>
Because you want to keep track of multiple things? xD
<Akuli>
why not a set?
<Akuli>
(i started as a python programmer)
<Tetralux>
It's not about uniqueness.
drazan has joined #zig
<Tetralux>
It's about order.
<Tetralux>
You don't care about either thing.
<Tetralux>
You just have a list of items, and you want to process them.
<Akuli>
hmm, so you would use an array for an unordered collection of possibly non-unique items?
<Tetralux>
All the time.
<Tetralux>
That's my main use of arrays
<Akuli>
how do you count the occurences of an item in it? O(n)?
<Akuli>
or check whether it contains an item?
<Tetralux>
You keep track as you add stuff to it.
<Akuli>
i would use a hash table with count integers as values to have both of those be O(1)
<Tetralux>
If I care about order, I normally use a linked list.
<Tetralux>
That way prepending and appending are O(1).
<Tetralux>
OR
<Tetralux>
I keep them ordered as I insert them.
<Tetralux>
But that's pretty rare that I care.
<Tetralux>
Normally, unordered is fine, and if I need ordered, I either keep them ordered when inserting, or call sort at the appropriate moment.
<Tetralux>
The latter is usually enough.
<Tetralux>
Depends on item count of course.
porky11 has quit [Ping timeout: 245 seconds]
<Akuli>
thanks, i hadn't thought of arrays as a thing usable for order-doesnt-matter cases before
<Tetralux>
I'm kind of surprised xD
<Akuli>
unless the data is small and O(n)-ness doesn't matter ofc
<Tetralux>
Though I guess I shouldn't be.
<Tetralux>
There's many things like that that aren't necessarily obvious.
<Akuli>
i'm still a bit worried about finding something from the array
<Tetralux>
Short answer is: Avoid needing to.
<Akuli>
ik but still
<Tetralux>
I don't often need to linearly search an array.
<Tetralux>
And times I do, I don't expect to have to search through all of it.
<Tetralux>
The item I want should be near one end.
<Tetralux>
So just start at that end.
<Tetralux>
Basically, try to architect the program so that you don't need to care about it.
<Tetralux>
And if you think you need to use a slow algorithm, like sort, or keeping order, or "does it contain this", then think about it for a bit and see if you could do rework how the list is used to not require t hat.
<Tetralux>
The bone-headed example being: If I really need to know if this thing is in the list, use a map.
<Tetralux>
OR
<Tetralux>
Use the index into the array as the key.
<Tetralux>
Then an array is fine.
<Tetralux>
.. and faster.
<Tetralux>
Much faster.
<kristoff_it>
Damn I'm millimeters away from a working PoC redis client. I'm trying to use `connectUnixSocket` since it seems to be the only available networking facility available in the standard library but on macOS it causes compile errors. Does anybody know if it's completely broken or it's something minor? Does anybody know if it works on linux?
<Tetralux>
We don't have networking yet - so I'd expect nothing to work xD
porky11 has joined #zig
<Akuli>
you can create some socket code in c and compile it with zig code afaik
<Akuli>
connectUnixSocket sounds like an AF_UNIX thing, you want AF_INET
<Akuli>
(i think)
<fengb>
connectUnixSocket looks like old async code that probably wasn't updated yet
<kristoff_it>
ok so it's not just the darwin codepath that wasn't updated
<kristoff_it>
Akuli: I don't know about that honestly, sorry, I'm a dirty python programmer by nature so I just know that I started Redis with the --unixsocket option to make it accept connections using a unix socket and I was trying to use that
<Akuli>
oh then you really do want a unix socket
<kristoff_it>
related question: I can't just open the unix socket as a file and write / read to it, can I?
<Akuli>
have you ever programmed with python's sockets? they are easier to get started with than sockets in c
<Akuli>
i think you need to open it with socket() and connect() instead of open()
<kristoff_it>
oh my god this is why I never wanted to deal with certain apis... why the hell does sockaddr_in have a len field while the connect api also asks for a len parameter
<kristoff_it>
what's going on
FireFox317 has joined #zig
<FireFox317>
kristoff_it: The network api of the zig std is not final yet and I think there are some big changes coming in the next release cycle
<fengb>
I think he's dropping into the raw posix layer
<gonz_>
And then you just set the fields you need to set after, emulating typical C behavior
<kristoff_it>
written this way I think you would not respect alignment for certain types. If you do it the other way around (first create a var x: T = undefined) and then you zero it by casting x to bytes, then you should be fine.
<kristoff_it>
uhmm I'm trying it myself and I seem to be wrong, I don't get any error even when trying with weird types
<fengb>
I think it memcopies the 0s into the resulting location, so alignment will eventually be respected
Akuli has quit [Quit: Leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
FireFox317 has quit [Ping timeout: 248 seconds]
johnLate has quit [Ping timeout: 246 seconds]
<kristoff_it>
gonz_: something similar yes, I think mem.toBytes creates another copy, while I meant to write directly to `value` (using your variable names), so you would need to `@memSet(@ptrCast([*]u8, &value), 0, @sizeOf(T))`
<kristoff_it>
and then you return `value`
<kristoff_it>
anyway, your original code seems to work
<kristoff_it>
btw I was able in the meantime to connect
ntgg has joined #zig
johnLate has joined #zig
dimenus has quit [Ping timeout: 246 seconds]
wilsonk_ has quit [Ping timeout: 246 seconds]
lucus16 has joined #zig
ntgg has quit [Ping timeout: 245 seconds]
wilsonk_ has joined #zig
ltriant has joined #zig
ntgg has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
ntgg has quit [Ping timeout: 248 seconds]
<mikdusan>
Tetralux: does it makes sense to consider const vs. non-const in the loop construct? i'd love to be assured that there is a universal way to say "iterate and intend to modify elements"
<mikdusan>
`for (list) |*e| {...}` ?
<Tetralux>
You could require a non-const pointer to the struct, or struct value to remove stuff.
<Tetralux>
But yeah
<Tetralux>
Doing *e to mean "I am able to remove this" is nice for the purposes of easily changing it.
<mikdusan>
along those lines... would that require 2 iterate functions? eg. `iterate()` and `iterateConst()`
<Tetralux>
There's no difference in implementation of the iteration.
<Tetralux>
So I'd hope not.
<Tetralux>
It's literally just "am I allowed to remove or not?"
<Tetralux>
The _way_ you remove an item remains the same.
<Tetralux>
Personally, if you're faffing around with the data in the fields of a struct, you should know what you are doing.
<Tetralux>
So you should probably be one of that struct's methods, or you should know what you're doing.
<Tetralux>
Being able to remove an element can be prevented by using *const T, but I'm not sure how useful that is really.
<Tetralux>
Certainly, being able to iterate by pointer could be a comptime parameter to iterate.
<Tetralux>
And that's how it'd give you a pointer to the item.
kristoff_it has joined #zig
<Tetralux>
Also, you can infer whether you want to be able to remove or not - you're using `remove x` :p
<mikdusan>
currently in the realm of fn arguments the compiler decides value/reference when const... for perf reasons
<mikdusan>
and when non-const you signal intent with `*`
<mikdusan>
i *think* if similar optimization is desired, then 1 iterate() fn would not suffice
<Tetralux>
Zig would know statically if you wanted to possibly remove, whether you wanted to do it keeping order or not, etc.
<Tetralux>
The express point of the mechanism is that it is _no_ slower than just writing the code in iterate to begin with.
<Tetralux>
It would know btw, because you'd be using the remove keywords.
<Tetralux>
If you never did - it would know it could do the equivalent of using .iteratorConst in my PR.