ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<MajorLag>
any chance a bug was introduced recently regarding printing usize? I'm getting some odd results.
<MajorLag>
wait, nevermind. They make sense when I pay attention
<MajorLag>
...yeah, it helps to read the right section of code
<alexnask>
Do you have a .collect() or similar that consumes the iterator into an array?
<Dodo>
&Windows(u32).init(array, 2) should give [1, 2], [2, 3], [3, 4] etc etc
<Dodo>
Not yet, was planning on doing that also
<Dodo>
but...collecting into an array?
<alexnask>
What is the differene between Windows and Chunks?
<Dodo>
Chunks do not overlap, Windows does
<alexnask>
Right, gotcha
<Dodo>
collecting into an array is kind of...dangerous
<alexnask>
Well, yes, something like .to_array() would be a better name I guess
<alexnask>
It should allocate the array ;)
<alexnask>
On the heap
<Dodo>
what if the iterator has more items then the len of the array
<alexnask>
Right there needs to be some heuristic
<Dodo>
what if the array has more space than the iterator
<Dodo>
is there a Vector-like type?
<alexnask>
The way I would do it is have a stack array of N elements
<alexnask>
collect N at a time and move them into the heap allocated array (initially of size N)
<alexnask>
reallocate the array for each chunk
<alexnask>
There is ArrayList I think yes
<alexnask>
Which would do all of this automatically
<Dodo>
I mean, if there is a vector-like type, you could just consume the Iterator, calling .push() or .append() for each item
<alexnask>
std.array_list
<Dodo>
and not care about how the vector re-allocates etc, since you should not have to care about that
<alexnask>
Sure
<Dodo>
that should just be a function on Iterator, .collect() seems a good name I guess
<alexnask>
@andrewrk I'm kinda stuck on @typeInfo, I'm generating a TypeInfo union at compile time, the tag (which is a TypeId) seems to work correctly
<alexnask>
But as soon as I set a struct payload
<alexnask>
I get an error from 'ir_resolve_const': "unable to evaluate constant expression" when I try to access the payload in a comptime ccontext
<alexnask>
Which probably means the field access doesn't get that the whole thing is const.
<alexnask>
hmm
<Dodo>
error: expression value is ignored <-- mhh
<alexnask>
_ = (expr)
<alexnask>
You can't ignore any expression value (that includes returned values from functions) excpet for void s
<alexnask>
_ = (expr) tells the compiler you don't need the expression
<alexnask>
(It's missing method info but it will be added)
<alexnask>
Currently I'm working on the inverse, @typeInfo, which takes a type and gives you a TypeInfo
<alexnask>
Then I'll proably remove or deprecate all current metaprogramming calls (expect for @typeId, @sizeOf) and add a std.meta package that works on top of @typeInfo
<alexnask>
Kinda ugly but you can think of it as a function expression syntax (with no captures) :p
<alexnask>
Closures are not supported atm
<alexnask>
I think the issue is with the argument capture and how that would all work safely
<Dodo>
the argument can no longer be used once captured in the closure,
<Dodo>
unless you capture by reference
<alexnask>
Well, I for one would be ok with C++ style captures
<alexnask>
But there's a lot of edgecases and ways to shoot your foot off
<Dodo>
mh, I never had that much trouble with closures in Rust
<alexnask>
+ all allocations need to be explicit, this is a design decision (so you can't just move all your captures to the heap and be done with it like in most other languages)
<Dodo>
but hey, that's the point of Rust :3
<alexnask>
Right but rust closures rely on the burrow checker
<alexnask>
The whole language has strong guarantees about memory so closures profit off of that
<Dodo>
\o/
<Dodo>
one thing that would also be cool to have is to be able to have an Iterator over slices,
<Dodo>
now there is the for loop, but that doesnt work with our Iterators xD
<alexnask>
Well you could write a SliceIterator
<alexnask>
It sound pretty trivial
<Dodo>
how should it be writting?
<Dodo>
should it use the Range() Iterator to acces the index?
<Dodo>
or should it take a slice, yank out a ptr to the first element, and a ptr to the last element, incrementing the ptr each time?
<alexnask>
Both are possible, the second option sounds better to me though
<alexnask>
So you can just store 2 pointers (current + end)
<Dodo>
or like 'if (self.slice.len == 0) {return null;} var ret = self.slice[0]; self.slice = self.slice[1..]; return ret;'
<alexnask>
Right, that's an option too, it's basically the same
<alexnask>
If you think about it all you're doing is keeping a stable end pointer and bumping a pointer in front of it
<alexnask>
I think it would actually pretty much generate the same code
<Dodo>
the last one is less error prone I thing
<Dodo>
*think
davr0s has joined #zig
<Dodo>
yay, done
<alexnask>
:D
<Dodo>
maybe I should do a SliceIterMut and SliceIter
<Dodo>
where SliceIterMut returns &T, SliceIter &const T
<Dodo>
that would avoid copying each item
Dodo2 has joined #zig
Dodo has quit [Quit: Page closed]
Dodo2 is now known as Dodo
<alexnask>
wow i'm blind
<Dodo>
what happend @alexnask ?
<alexnask>
I was passing a pointer to the first field instead of a pointer to the 3rd field
<alexnask>
And banging mu head against the wall :p
<alexnask>
Noice Pointer @typeInfo up and running!
<Dodo>
hehehehe
<Dodo>
I one type spent half a day in Python wondering why I got an error that some type was not Iterable...turned out I passed in a tuple, instead of tuple[0]
<alexnask>
I just want to know if it's the right way to approach the problem in a general sense, although I think it's probably fine
hooo has joined #zig
<hooo>
is string concatenation via '+' planned?
<alexnask>
@hooo You can use ++ ;)
<alexnask>
It works on any slice
<hooo>
cool thanks
<alexnask>
No problem, ask away if you have questions
<Dodo>
can you index into an &[]T ?
<Dodo>
which is a ptr to a slice, right?
<alexnask>
I think you'd have to deref it first
<alexnask>
(*slice_ptr)[idx]
<Dodo>
I was thinking to have .split_at() and .split_at_mut() take a pointer to a slice, and return a [2]&const []T / [2]&[]T so you don't lose the original slice, but still get 2 subslices back
<Dodo>
why is this distracted me from my schoolwork ._.
<alexnask>
Taking a pointer to a slice seems weird to me
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
Why not take the slice by value and return [2][]T ?
<alexnask>
schoolwork is for losers, come to the dark side :P (/s)
<alexnask>
We have pointers and cookies
<Dodo>
hahahaha
<Dodo>
why not take the slice by value....well, don't I lose the original slice?
cgag has quit []
cgag has joined #zig
<Dodo>
and Im making my life easy, making templates for the next schoolproject
<Dodo>
15 forensic investigations and starting each time all over again, nah, that's not gonna work out
<alexnask>
:D
<alexnask>
What do you mean you will lose the original slice?
<alexnask>
Taking it by value will just copy the ptr+len pair
steveno_ has joined #zig
<Dodo>
oh right
<Dodo>
Im still used to move semantics
<alexnask>
Ah, right
<Dodo>
and Im used that I could never take a slice by value, because it was not 'Sized',
<Dodo>
at least, in Rust a '[T]' is impossible to pass around, '&[T]' and '&mut [T]' is fine though
<alexnask>
Right
hooo has quit [Quit: Page closed]
<Dodo>
I wonder, what was the first language to have a 'slice' type?
steveno_ has quit [Ping timeout: 255 seconds]
steveno_ has joined #zig
<MajorLag>
Believe it or not, there's a wikipedia article for that. FORTRAN probably.
davr0s has joined #zig
<Dodo>
:O
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag>
C was actually kind of an outlier in not passing length information along with array pointers.
Dodo has quit [Ping timeout: 260 seconds]
Ichorio has joined #zig
<andrewrk>
achambe, and their title slide says "For Great Justice"
<andrewrk>
what did you mean about errdefer vs crashing? are you talking about how handling errors introduces untested code paths whereas crashing eliminates code paths?
<andrewrk>
alexnask, yes, for ConstUnionValue the payload is nullptr when the tag type is void
davr0s has joined #zig
<andrewrk>
alexnask, for "unable to evaluate constant expression" it helps to use --verbose-ir
<andrewrk>
but that's probably too much output, and there are some techniques to get smaller output
<andrewrk>
alexnask, oh, you maybe needed to set constexprvalue->special = ConstValSpecialStatic
<andrewrk>
alexnask, if you look at test/cases/union.zig you can see comptime union tests
Dodo has joined #zig
<Dodo>
how do I copy I directory (recursively) ?
<andrewrk>
Dodo, that's a useful utility function we should have in the std lib, which we do not currently have
<andrewrk>
alexnask, I'll have a look at your diff!
<Dodo>
ah I see
<andrewrk>
alexnask, want to go ahead and make this a work in progress pull request, and that way I can add some comments via github?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
cenomla has joined #zig
davr0s has joined #zig
<Dodo>
is there some way to annotate something is heap allocated?
steveno_ has quit [Quit: Leaving]
<andrewrk>
that's an interesting idea
<andrewrk>
that should be comptime known
<andrewrk>
Dodo, can you explain more?
<Dodo>
uff
<Dodo>
a pointer type that is heap allocated?
<andrewrk>
I mean, what problem would it solve?
<Dodo>
or rather, that points to heap memory
<andrewrk>
what are you working on that made you want this feature?
<Dodo>
nothing really, just some random thought I had
<Dodo>
some languages have like a special type for that, just wondered haha
cenomla has quit [Quit: cenomla]
jjido has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noonien has quit [Quit: Connection closed for inactivity]