dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
drasko has quit [Ping timeout: 276 seconds]
<Tetralux>
fengb: ?
<fengb>
It’s hard to accidentally pass in the wrong value
<Tetralux>
If that really is the reason, that should definitely be commented.
<Tetralux>
And indeed, I'm amazed it's not if that is the case.
<Tetralux>
But also
<fengb>
I’m just guessing >_>
<Tetralux>
That smells like a missing feature.
samtebbs has quit [Quit: Lost terminal]
<Tetralux>
Also, considering the rename for the function in #3037; I'm trying to decide on what the name should be for an iterator that is able to remove elements from the container, versus the one that cannot.
<Tetralux>
Assuming that .iterator should not be able to remove, which I'm not really sold on, but, there's been some resistance.
<Tetralux>
I also thought a little about this when I first made the PR a month ago
<Tetralux>
Short version: iteratorMut.
<Tetralux>
I think it's also pretty important for the name to be pretty close to the normal one: iterator.
<Tetralux>
Personally, I think the assertion of "I specifically do not want to be able to remove anything from this" is better than "I specifically want to [...]"
<Tetralux>
However regardless, if it is necessary to change it in order to get it into 0.5 in it's otherwise current form, anyone have any suggestions for names?
mahmudov has quit [Ping timeout: 268 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
<mikdusan>
Tetralux: u29 i think because llvm docs `1 << 29` is the max alignment
<bgiannan>
Tetralux, i just found myself needing that iterator this week-end
<Tetralux>
bgiannan: A handy tool, ain't it? :p
chemist69 has quit [Ping timeout: 246 seconds]
<bgiannan>
Tetralux, was used to how `pairs` works in Lua
<bgiannan>
Tetralux, would be useful for HashMap too
<bgiannan>
which actually was the use case i had
<Tetralux>
Removing from a map while iterating?
<bgiannan>
yes
chemist69 has joined #zig
<Tetralux>
Interesting.
<bgiannan>
what you would get i guess is a KV with a value potentially null
<Tetralux>
Why's that?
<bgiannan>
so you iterate over the set of keys as they were at the start
<bgiannan>
say you remove a key you haven't reached yet
<bgiannan>
when you get to it you just get a null value which tells you that key doesn't map anything now
<Tetralux>
Ah, I gotcha
<Tetralux>
Hmm.
<Tetralux>
You wouldnt be able to tell between a null value in the map though.
<bgiannan>
yeah
<bgiannan>
and thinking about it you don't need that
<bgiannan>
you just need to skip the dead keys
<Tetralux>
Simplest would prob be just to make it remove independant of the iterator.
<Tetralux>
Just like #3037.
kristoff_it has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
telemach has joined #zig
<telemach>
Hey folks, found some time to play with Zig again. Doing basic exercises and hit unexpected (for me) thing. I do fn LinkedList(comptime T: type) type { const Self = struct { ... }; return Self; }
<telemach>
so far so good, but when I try to reference Self in its methods zig complains
<telemach>
though similar toplevel declaration works
<telemach>
is it expected? any workarounds besides using LinkedList(T)?
ltriant has quit [Ping timeout: 245 seconds]
qazo has quit [Ping timeout: 276 seconds]
mahmudov has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
<stratact>
telemach: may we see a pastebin of the errors?
<tencho>
ops.. the compiler version in the above link is wrong, but if you change it to 0.4, it will give another error
<tencho>
the actual error that I don't understand
earnestly has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
tencho has quit [Remote host closed the connection]
tencho has joined #zig
tencho has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
uvx has joined #zig
drasko has quit [Ping timeout: 276 seconds]
mahmudov has quit [Ping timeout: 265 seconds]
uvx has quit [Ping timeout: 276 seconds]
slice has quit [Ping timeout: 246 seconds]
chavezgu has joined #zig
mahmudov has joined #zig
slice has joined #zig
halosghost has joined #zig
drasko has joined #zig
root3 has joined #zig
root3 has quit [Client Quit]
tencho has joined #zig
<fengb>
Use the nightly build. 0.4.0 is really outdated now
<fengb>
And it'll give you a better error
<fengb>
`cannot store runtime value in type 'builtin.Declaration'` type info is a purely comptime construct and this is trying to store it as runtime
<tencho>
I still don't get it. Isn't every type a "comptime construct" ?
<fengb>
I mean it doesn't exist at runtime
<fengb>
There's no memory definition for types
<fengb>
So you can't just store it into a 'var'. If you want the data, you'll have to manually pull out the fields into a separate struct
<fengb>
There's a different way to build a comptime array of decls. Lemme see if I can find it
<Tetralux>
By 'types', fengb means TypeInfo in general; for the record, I consider this a bit of a mistake on Zig's part, that TypeInfo is only available at compile time.
<Tetralux>
It's in the name of simplicity.
<Tetralux>
But yes, that is how it works right now.
<Tetralux>
Basically, the problem is `g_d`.
<Tetralux>
You cannot store TypeInfo of any kind, Declaration or otherwise, directly in a runtime-known value.
<fgenesis>
what about const Type = comptime Maketype(...) or something like that
<fengb>
So my guess is... the struct is defined, but any actual info is inaccessible
<fengb>
.name = .name works because it's a comptime string and inlined
<Tetralux>
If I try to print out g_d[0].name, it works, and prints 'mem', incidentally.
stratact has quit [Quit: Konversation terminated!]
<fengb>
So on compile, it becomes `.name = "Dwarf"` etc
<Tetralux>
But trying to print out the actual struct value does not, requiring comptime.
<Tetralux>
fengb: Indeed.
<Tetralux>
However
<fengb>
Yeah the struct data is inaccessible
<fengb>
And the compile doesn't know how to inline it
<Tetralux>
You're assigning that string literal into a struct value that is comptime only.
<Tetralux>
.. but is in a var.
<Tetralux>
This makes absolutely no sense.
<Tetralux>
Absent of magic.
<Tetralux>
Which Zig hates :)
<fengb>
My guess is the struct definition is fine
<Tetralux>
But the struct definition is TypeInfo.
<Tetralux>
.. which is only allowed at comptime.
<fengb>
But the actual type data can't be accessed at runtime, and also cannot be inlined
<fengb>
Retracting my previous statement, I'm saying the definition just exists, not just at comptime
<fengb>
But the data is only available at comptime
<fengb>
So when trying to assign the struct, it'll bomb because the data is neither accessible nor inlineable
<fengb>
But you can manually wire in the fields
<Tetralux>
None of this makes any sense to me at all.
<Tetralux>
Either you should have full access to all type info in both contexts.
<Tetralux>
Or none at all.
<Tetralux>
(.. in which case you have to copy it into a runtime stored variable.)
<fengb>
The struct is avaialbe in both contexts
<fengb>
But the data is only comptime
<Tetralux>
Meaning that you _can_ store a struct of type TypeInfo, just not ask for any of it's data?
<fengb>
So you can define a struct, but you can't use the data, unless you finangle the data to be runtime knowable
<fengb>
Yeah looks like
<Tetralux>
That makes even less sense.
<fengb>
I'm just piecing this together too :P
<Tetralux>
"You can declare a variable of type TypeInfo, but access it's fields"
<Tetralux>
.. is what I hear when you say that xD
<Tetralux>
And yeah, I appreciate that ;p
<fengb>
You can't copy the struct at runtime
<fengb>
But you can introspect all the data, so you can access its fields just fine
<fengb>
So arguably the fix is allow for inlining at runtime
<fengb>
Because I think that's the blocker that's preventing the assign
<Tetralux>
I am thinking more and more that you should just be able to access all of TypeInfo at runtime and be done with it.
<Tetralux>
This is way too difficult to understand.
<fgenesis>
yes
<fgenesis>
i mean if it's not done and the data are unreferenced it'll be optimized away anyway
<Tetralux>
Probably not in most cases though, because you'd probably use it.
<Tetralux>
I can think of a good example of the top of my head.
<tencho>
I think the problem is because of fields of type 'type'
stratact has joined #zig
<Tetralux>
For weeks I've been banging my head against a wall trying to figure out how to arcitect the decoding/encoding of CBOR. It would be solved in minutes with RTTI.
<Tetralux>
tencho: Maybe.
<fgenesis>
just thinking, assuming you'd write a sorta universal serializer for a struct that generates the right thing at compime --> in that situation you wouldn't need any rumtime stuff, imo?
<mq32>
Tetralux, what's your problem with CTTI?
<mq32>
(why do you need RTTI?)
<Tetralux>
mq32: Essentially, I want a heterogenous list of stuff.
<Tetralux>
And what type each thing is, has it's own behaviour.
<gonz_>
Shared memory message passing is in itself pretty superfluous
<mq32>
but Tetralux: i wanted to implement the UI transport layer agnostic, but right now i don't care :D
<gonz_>
Nothing really is improved by sharing memory but passing messages
<fgenesis>
whatever sort of 100% reliable channel you have doesn't matter if your hardware is still prone to derp every now and then, even if it's rare
<gonz_>
You pass messages because you have a distributed system
<mq32>
three step program: 1) make it work, 2) make it right, 3) make it good
<fgenesis>
4) rewrite it because verything sucks and software was a mistake
<mq32>
:D
<mq32>
fgenesis, want the challenge to implement a system client for AVR if i'm far enough with the API?
<mq32>
*grin*
<fgenesis>
looks like i won't get very far with this anytime soon because of life and everything, you know
<Tetralux>
gonz_: I'm not sure I entirely get your point :p
<fgenesis>
but yes it would be nice to learn zig with this eventually
<Tetralux>
mq32: I'd consider a message queue / bus.
<fgenesis>
mq32: on my list of things to do once this phd-mess is over ;_;
<Tetralux>
And then just make the messages POD so that you can easily serialize them over a stream.
<fgenesis>
make messages xml
<Tetralux>
NOPE.
<fgenesis>
nothing can go wrong with plaintext!
<fgenesis>
(except EBCDIC)
<Tetralux>
Never mention XML in my presence again
<Tetralux>
(unless riffing on it.) :)
* Tetralux
smiles
* fgenesis
fistpumps secretly
* Tetralux
laughs
<gonz_>
My point is that there's no real upside to pretending to have a message protocol between systems if you're sharing memory.
<mq32>
Tetralux, nah, POD is too large :D
<Tetralux>
Honestly, YAML is better if you're editing it manually, in my experience.
<fgenesis>
ASN-1
<Tetralux>
Damn-sight easier to read.
<fgenesis>
send as teletext-string
<Tetralux>
gonz_: I mean, "message bus" can take many forms.
<mq32>
i'm using some encoding similar to the one used in protobuf (so smaller integers take less space)
<Tetralux>
If you used shared memory, you could have an atomic or whatever to indicate if a message was ready, etc.
<Tetralux>
instead of having an array.
<mq32>
also most data transferred is var-sized, so POD types would make parsing actually harder
<fgenesis>
mq32: using zigs variable bit-integers? :D
<mq32>
fgenesis, no, it's written in C++
* mq32
said the bad word... *oops*
<Tetralux>
mq32: I don't really see why.
<mq32>
Tetralux, designing a system to take as less space as possible to make it suitable for µC
<mq32>
target space would be to probably require 32k HEAP and some extra RAM except for the heap
<fgenesis>
should be doable in 2k
<Tetralux>
If a message is variable length, you have a tag to say what kind of message it is; for variable length fields, encode the length as an int that preceedes the bytes of the field value?
<mq32>
but even my ints are variable-length ;)
<Tetralux>
WHY WOULD YOU DO THAT TO YOURSELF
<mq32>
because space matters!
<fgenesis>
or include a special kind of message that carries the bit-widths of types used later in the message, so you can change them at any time when convenient
<Tetralux>
Surely for transferring over the wire, it's okay?
<mq32>
yes, for storage of serialized data in RAM as well
<Tetralux>
You only are storing the latest message in memory in encoded form though?
<mq32>
nope, i have to store the current UI layout, all resources and data required by the UI in RAM
<Tetralux>
The first thing you do is encode it into the struct you originally had.
<Tetralux>
Then you store that.
<Tetralux>
( the struct )
<mq32>
resources is stuff like "UI layout", "images", ...
<Tetralux>
You don't have enough bytes to store one encoded message? :)
* Tetralux
smirks and narrows eyes
<fgenesis>
send the entire UI as a compressed, pre-rendered image
<mq32>
not enough space for a fullscreen image
<kristoff_it>
mq32: thanks! :)
<fgenesis>
use my special coded that doesn't need memory
<Tetralux>
mq32: Could send it in parts ;p
<mq32>
right now, my UI layout for a calculator UI takes about 100 bytes
<Tetralux>
Quadrants :)
<Tetralux>
How much RAM you got?
<mq32>
32k HEAP, 32k static RAM
<mq32>
(well, remove everything from static ram that is required for heap management)
<Tetralux>
If you use more than that, I'd be staring at all your XML you have to store.
<mq32>
what XML?
* Tetralux
grins
<Tetralux>
That's the correct response ;p
<mq32>
but i have a custom binary representation for GUI layouts :D
<mq32>
similar to ...
<mq32>
well, UI trees
<Tetralux>
ó.ó
<mq32>
imagine simplified, binary encoded HTML :D
<fgenesis>
wrapped in xml for convenience
<Tetralux>
This is unimaginable.
<Tetralux>
I totally understand.
<mq32>
for each UI widget, i need at least 3 bytes :D
<Tetralux>
I feel like you don't entirely need that.
<fgenesis>
over 9000 buttons on a 320x200 touchscreen probably
<Tetralux>
.. instance _of_ widgets.
<mq32>
instances? dunno, the system supports over 9000 :D
<fgenesis>
the way i know mq32 :D
<mq32>
my format supports all that can fit into target system RAM :D
<Tetralux>
If I walk up to this display, and try to do something reasonable
<Tetralux>
How many UI elements will I see.
<Tetralux>
And how many of them do I only need if I want to do something rare and specific?
<mq32>
depends on the kind of application
<Tetralux>
Oh, we're talking general-case?
<fgenesis>
can we agree that mq32 is totally not over-optimizing
<mq32>
yeah, sure
<fgenesis>
maybe we need to do this first
<Tetralux>
fgensis: Waaaay ahead of you ;)
<mq32>
fgenesis, there isn't much to optimize in the format anymore :D
<mq32>
seriously .D
<fgenesis>
could be done in 7 bits tho
<mq32>
it actually does and uses the 7th bit for different information *runs*
<mq32>
so, at least for property information
<Tetralux>
mq32: How about, if you only load into RAM like two "pages" (windows on Windows) and then query the network for other windows you want to display?
<Tetralux>
Or get it off SD card or whatever/
<mq32>
target platform has no SD card and a **horribly** slow I/O interface :D
<fgenesis>
mq32: still your heater control or something else this time?
<Tetralux>
Ah - so remoting into this thing is worthless to begin with? xD
<mq32>
yeah :D
<mq32>
but the idea is to have the UI system be *really* general purpose
<mq32>
develop desktop apps and embedded apps with the same UI system
<mq32>
and allow remote use
<fgenesis>
just use Xlib then
* fgenesis
runs
<mq32>
so have an embedded IoT device connect to your smartphone and provide a UI you can control the device with
<Tetralux>
Well - on desktop, message bus is fine.
<mq32>
for desktop→desktop, yes
<Tetralux>
On embedded, I'd say it still is.
<mq32>
the UI system is just a smaller part of a larger project
<Tetralux>
But you obviously need to be a lot smarter about it.
<mq32>
and i couldn't find a single ui system doing the stuff i need
<mq32>
(or networking library, lol)
<fgenesis>
somehow it's always like that, is it not
<mq32>
well
<mq32>
how much distributed, ad-hoc network stuff do you know that actually is simple and works? :D
<Tetralux>
Just how slow is this IO you speak of?
<mq32>
and UI that can work with ad-hoc displays that *may* disappear for some time and then just reappear
<Tetralux>
115200 baud? :)
<mq32>
actually, it's 230400!
<Tetralux>
Oh excellent!
<mq32>
but polling-based :D
<Tetralux>
I don't know what that means but it probably bad.
<mq32>
so, it's a real bus with multiple participants and only a single host that has to poll clients for messages
<mq32>
similar to RS485 networks
<Tetralux>
The host has the display?
<Tetralux>
Or the clients?
<mq32>
it depends™
<Tetralux>
I think message bus is still the simplest solution.
<mq32>
can you send me "more information" on "your" message bus?
<mq32>
i cannot find anything on google except for overkill enterprise solutions
<fgenesis>
mqtt?
<fgenesis>
even starts with mq
<fgenesis>
so it is literally perfect right there
<companion_cube>
redis? :p
<mq32>
does mqtt requires a connection? :D
<fgenesis>
no
<Tetralux>
So, it depends really - when I say "message bus" - the idea is that the approach is the valuable part rather than the implemenation, since that gets adapted to the use case of it.
<Tetralux>
However
<fgenesis>
you just barf things into the network
<Tetralux>
One example of it is the WinAPI PeekMessage interface.
<mq32>
ah
<fgenesis>
aaaaahh you said WinAPI
<mq32>
hey, the winapi is actually quite sane (crossref #demo.ger)
<mq32>
Tetralux, yeah that's probably the thing i will do
<mq32>
i think we talked of the same thing with different names then
<Tetralux>
I figured we might have been :p
<Tetralux>
But yes - the essence is - you have a way to push new messages, and pop off messages in order.
<mq32>
yeah
<mq32>
will have to write something for that too :D
<Tetralux>
Be it a stack implemented as an array, shared memory, stream etc.
<mq32>
fgenesis, mqtt won't cut it, it requires a central instance
Aransentin has joined #zig
<fgenesis>
fair point
<mq32>
as the UI should be generic purpose, i would just make some interface { fn poll() ?[]u8; fn send(data : []u8) void; }
<fgenesis>
saves you from using mgmt ram in the dumb, attached devices tho, which is nice
<Tetralux>
mq32: What's that the interface to exactly? The socket?
<Tetralux>
Or the message bus? :p
<mq32>
the message bus :D
<mq32>
UI encoded data and tells some broker: "put that away!"
<mq32>
and the broker say: "yeah i've received that blob for you"
<Tetralux>
I might expect messages to be structs.
<Tetralux>
But otherwise, pretty much, yes.
return0e has joined #zig
<mq32>
yeah the problem is that all my messages are variable length
<Tetralux>
The first field of each message struct is a u16 that represents it's type.
<companion_cube>
so, you mean a tagged union, right? :p
<Tetralux>
Ehhhh
<Tetralux>
More that you read a fixed size integer first
<companion_cube>
isn't that what the tagged union is about? :)
<Tetralux>
That tells you how to read that kind of message.
<Tetralux>
In that it tells you the structure.
<companion_cube>
tbh sounds like a serialization format would be cleaner
<Tetralux>
That _is_ a serialization format.
<Tetralux>
Quite literallly
<Tetralux>
Except that the type part is encoded into the struct.
<mq32>
for me, structs have always fixed size
<mq32>
even if distinguished by a type ID
<mq32>
something like { type: u32 = 1, length : u32, payload : [length]u8 } would not be a struct in my world :D
<Tetralux>
Indeed - the struct would be `payload: []u8`
<Tetralux>
But you serialize by writing a u32 length or whatever followed by that number of bytes.
<Tetralux>
And that's how you deserialize at the other end.
<Tetralux>
Read the length, read that many bytes.
<mq32>
yeah that part is clear
<mq32>
that's how most of my serialization works already
<Tetralux>
Similarly for the message itself, the fields, and what type they are depends on the type of message, which is just a u16 or whatever that you always read first.
<kuon>
Hello. I have an old lightweight UI engine I wrote a few years back for a game project. I am now working on a project of a medical device, and I need a UI/layout engine for it. I looked into what exists (nuklear, imgui...) and I realize my old engine was quite decent and I'd like to revive it. It is now written in C but as it will be used in a medical device, I'd like to rewrite it in a safer language.
<kuon>
I looked in rust, but I have a feeling of "complexity" I cannot pinpoint.
<halosghost>
hot-take: Zig is not ready for high-reliability-required, production-grade applications like medical devices
<kuon>
I know this might seem quite subjective, but I am wondering how stable zig is. Especially it's future. I cannot use a language that will be gone in a few years.
<halosghost>
having said that, I think Zig's future is bright and I look forward to the time I would feel comfortable with Zig being used in applications like that
<halosghost>
(also, I'm not heavily involved with Zig's development)
<kuon>
So you think it is too early? The device would ship around 2021 so there is time for improvement.
<halosghost>
my personal take is that any language created in the last decade is likely too young for the level of reliability I would like to be used for medical devices
<companion_cube>
kuon: if it's in a medical device, have you considered Ada?
<halosghost>
if that's helpful calibration
<companion_cube>
it's been designed for high reliability systems…
<andrewrk>
medical devices is certainly in scope of zig, however it would be irresponsible to use zig for this use case pre-1.0
<companion_cube>
even LLVM would have to be vetted, I think
<halosghost>
and LLVM's not exactly a simple piece of software
<companion_cube>
ahahah wait for Zig to have a compcert backend 🙃
<kuon>
zig uses lvvm? I didn't check that already.
<halosghost>
yes
<kuon>
I guess that's to be expected, because it supporrted a lot of targets very quickly.
<companion_cube>
LLVM is the reason why there's so many new compiled languages
<kuon>
This is not a high availability medical device, that's why I can experiment a bit.
<halosghost>
for a language that has some similarish goals to zig, but doesn't rely on LLVM, take a look at myrddin; note also that myr is even younger than Zig
<kuon>
It's a secondary monitoring solution that will only display some data.
<halosghost>
also, it's possible that myr is dead
<halosghost>
minor detail :P
<ky0ko>
kuon, i'm also working on medical devices, and we generally stick with c/c++ with qt. i don't think zig is mature enough for this even with it only being a secondary thing.
<ky0ko>
not necessarily for reliability reasons, but reproducability reasons - it's important to make sure that in 7 years after release someone can still build the whole software image for your device
<ky0ko>
zig is still actively changing, and you can't make the guarantee that it will be buildable ~10 years from now without changes
<fengb>
Man, in 7 years, I'd have upgraded 3 JS frameworks :P
<kuon>
ky0ko: yeah, the maintainability thing is my main concern.
porky11 has joined #zig
<kuon>
I've been writing C for 25 years, I want out:P
<ky0ko>
kuon, definitely should be. i'd stick with something that you're sure is still going to be more or less the same in a decade
<kuon>
Been fixing the same kind of bugs for all those years.
<andrewrk>
rust will be ready for medical devices before zig will. they've already started those efforts
<ky0ko>
kuon, i'd be able to recommend rust for this use case despite not generally liking working with it myself. it is *very* different than c, though, and you will struggle with it if you aren't already familiar with it or with similar ML-type languages
<kuon>
Rust is promising, but after a week trying it, I have some weird feeling it's "too high level".
<ky0ko>
it is definitely more analogous to c++ than to c.
<kuon>
To be honnest, I was "successful" with rust, I could write what I wanted. But I don't enjoy using it.
laaron has joined #zig
<ky0ko>
kuon, yeah, i'm with you there. it is not an appropriate replacement in my opinion and experience
<ky0ko>
kuon, are you running on bare metal, or with an os underneath?
<kuon>
Both. The UI uses a toradex module with linux. And the data module is bare metal.
<kuon>
But the data module is avr based, I don't think I'll be able to use anything else that C on it.
<ky0ko>
i meant on the ui side - i figured the data module would be bare metal. so yeah, you've got some potential options then
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<ky0ko>
if you're not afraid of extremely functional languages you might give erlang a shot, it's pretty well tested in the embedded realm (and was designed for it originally)
<ky0ko>
it comes with a wxwidgets ui, and there's some packages written for it for both retained and immediate mode graphics
<ky0ko>
(well really they're written for elixir, but are compatible with erlang as well since they run on the same abstract machine)
<ky0ko>
it's wildly different than c-like languages though
<kuon>
I do use elixir for web apps.
<kuon>
I write them more as a hobby. I didn't think of elixir/erlang for UI apps.
<kuon>
I stumbled on it when I wanted to write a small web based game, I used phoenix.
<ky0ko>
well then if you think that'd work for you i'd say to give it a shot! erlang/elixir is, imo, a fantastic option for embedded stuff. the underlying platform has been around long enough that i don't think you have to worry about future maintainability much
<ky0ko>
the elixir bits are a little different, since that's much newer
<ky0ko>
but it seems to be stable enough
<kuon>
Yeah. I give it a shot.
<kuon>
Thanks for your feedback.
<FireFox317>
Aransentin: regarding your comment on your issue, a null terminated string which can also be null should be described by an optional unknown length pointer: ?[*]u8 or maybe even ?[*]const u8
<Aransentin>
Hmm
<Aransentin>
So what's the point of [*c], then? :)
<Aransentin>
I imagined it was something like if you pass a plain "string" to a [*c] argument the compiler would warn you
<fengb>
[*c] just means it's translated from C source
<FireFox317>
When using zig translate, zig doesn't know whether a pointer points to one thing or multiple things.
<FireFox317>
I think if you read the complete section of the C Pointers on the ziglang docs, you will understand it
<fengb>
null terminated strings/slices/pointers are on the horizon but they don't exist in the language yet
<Aransentin>
Aha. Right.
<Aransentin>
[*c] is optional by default so doing ?[*c] just adds another optional on top, that's why it's 16 bytes
waleee-cl has quit [Quit: Connection closed for inactivity]
<Aransentin>
(It still shouldn't crash, but now I know why it looked so strange at least...)
kristoff_it has joined #zig
waleee-cl has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
FireFox317 has quit [Ping timeout: 276 seconds]
josuah has joined #zig
<josuah>
zig sound exciting... but I need to sleep!
<josuah>
sounds*. I have no choice but to write something in it now...
<Sahnvour>
aren't export variables supposed to work ?
mahmudov has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<nrdmn>
Apparently comptime vars of type type aren't actually variable inside while loops
porky11 has quit [Quit: Leaving]
porky11 has joined #zig
porky11 has quit [Remote host closed the connection]
<andrewrk>
Sahnvour, they are but it's not implemented for every type
<andrewrk>
sorry
<Sahnvour>
andrewrk: ha, where is it implemented ? am I right that every exported variable should be visible from the generated C header ?
marijnfs has quit [Quit: WeeChat 2.5]
<andrewrk>
Sahnvour, yes you are right. see ir_analyze_instruction_export for @export. `export` keyword for vars is handled in resolve_decl_var. the fact that they are not unified might be part of the issue
<andrewrk>
I'm also now seeing that the lazy values interacting with variables might incorrectly prevent exporting, if you look at resolve_top_level_decl
<Sahnvour>
thanks, I'll have a look if I find some time
<Sahnvour>
I wanted to do a test with exported variables of extern structs
<andrewrk>
I'd like to do a comprehensive test of export and @export with every supported type
<andrewrk>
that currently does not exist
<Sahnvour>
that would be great
<Sahnvour>
I'm having `@typeInfo(@import("root")).Struct.decls[n].data.Var` reported as a runtime value, looks like a bug ?
desperek has quit [Quit: mew wew]
earnestly has quit [Ping timeout: 245 seconds]
earnestly has joined #zig
<andrewrk>
Sahnvour, yes that is a bug, `type` cannot be runtime
<Sahnvour>
right, thanks
<Sahnvour>
i'll make issues for these
vegax87 has quit [Quit: Leaving]
<nrdmn>
andrewrk: does it make sense to have a type "*type" if there are no runtime types?
<andrewrk>
yes
<andrewrk>
it works in comptime code
<nrdmn>
I was wondering if it should
<andrewrk>
nrdmn, why not? it would be more complicated to prevent it from working
<stratact>
andrewrk: I wanted to share an epiphany I had about issue #2885. I haven't done it yet since I want wait for your mentorship. An idea I had was to instead of passing an []u8, that I could pass an ArrayList(u8) to both deleteTree() and Dir.open() in std.fs. It technically removes inserting the allocator into the API call and allows the buffer to grow when expeniencing "EINVAL" as a Dir error. However this approach doesn't completely remove
<stratact>
allocation, if that's the goal as well.
<scientes>
stratact, you can't remove the allocator from the API call and have the buffer grow....
<nrdmn>
andrewrk: see the link that I posted about an hour ago. I'm not sure if something like that should be possible :D
<scientes>
you can't allocate memory without an allocator
<nrdmn>
about the comptime vars in loops: it seems to be a bit more complicated. Some comptime vars of type type work just fine
<scientes>
also, my PR fails on Freebsd, but freebsd isn't tier 1
<stratact>
scientes: I gotcha. I guess that's why I thought just passing an ArrayList with the allocator inside ahead of time would allow me to remove the allocator parameter in those function/method calls from an API standpoint
<andrewrk>
stratact, that's a good thing to realize - an ArrayList serves a similar purpose to an allocator
<scientes>
oh, well I'm not familiar with ArrayList, it is possible to types to store their allocators
<andrewrk>
but ultimately - to have a growable ArrayList available - you will need an allocator to initialize the ArrayList with
<andrewrk>
stratact, the purpose of #2885 is to modify the current logic - which has O(N) memory requirements - to have O(1) memory requirements
<stratact>
with a static sized buffer?
<andrewrk>
I would suggest solving one OS at a time - whatever is your home OS - and carefully read the documentation for the relevant APIs to determine whether you can do a directory listing with a fixed amount of memory
<scientes>
it does need an allocator is you want to provide a wrapper that iterates a directory in sorted order
<scientes>
which is needed occasionally
<andrewrk>
scientes, in this case it can be a separate API that takes an allocator
<andrewrk>
there is value in not requiring one when it is not needed
<scientes>
yes
<scientes>
but it could just ignore the allocator?
<andrewrk>
btw your SIMD patch set is next on my list - I'm doing a couple bug fixes first
<andrewrk>
that would work fine, but a more readily understandable API will have the function prototype communicate what is and isn't needed
<andrewrk>
readDirUnsorted() vs readDirSorted(allocator: *Allocator)
<andrewrk>
even if the underlying implementation is the same function
<telemach>
I see that sometimes allocator is passed as the first argument, sometimes as the last; is there any convention when which position to prefer?
<andrewrk>
telemach, recently I've been preferring 1st
<telemach>
thanks, and in the case like this: pub fn destroyNode(self: *Self, node: *Node, allocator: *Allocator) void {
<telemach>
should it go before node?
<scientes>
telemach, yes
<scientes>
*self is magic, and has to come first
<stratact>
andrewrk: it sounds like I would need to read the API documentation and look for a readdir syscall if FreeBSD supports one to get an appropriate sized buffer for each entry and hopefully avoid allocation.
<stratact>
at least for Dir.nextBsd()
<stratact>
and maybe there might be a similar syscalls for Linux too
<andrewrk>
telemach, I'd like to remove that function from std lib
<andrewrk>
it's a "helper" that is trivially implemented anywhere else; I don't think it belongs there
<scientes>
readdir() is part of POSIX
<stratact>
Ah, nice
<scientes>
but is implemented with getdents() which has differences
<andrewrk>
getdents is the proper API for the std lib to use on linux
<stratact>
I'll note that down
<andrewrk>
it's already done, that's already how it works
<scientes>
it still needs a static allocation
<scientes>
as getdents() is batched
<andrewrk>
stratact, which OS are you tackling first?
<stratact>
I'll tackle my home OS, FreeBSD first, and try Linux there after
<scientes>
d_name[] is limited to PATH_MAX + 1, so linux_direct64 would be limited to PATH+MAX+1 + 24
<scientes>
but you will get better performance with a larger buffer
<scientes>
but that is probably actually quite adaquate most of the time
<andrewrk>
stratact, good choice. your next task is to read docs for getdirentries and come up with "proof" that can be cited that a certain size fixed buffer will be guaranteed to always return at least 1 entry. cite that reasoning/proof in comments for why the size is chosen. If there are reasons to pick a larger or smaller buffer as scientes hints, make that a comptime number that can be chosen. A nice default can be chosen for a higher level
<andrewrk>
function, which calls the slightly lower level function with the comptime number
<stratact>
scientes: I will play around those sizes
<andrewrk>
but it should comptime assert that the number chosen is at least the minimum to get one dir entry
<scientes>
i would suggest 8192
<scientes>
which is quite big for a stack allocation
<stratact>
roger that guys, I'll keep notes of this discussion, if you guys don't mind? :)
<stratact>
andrewrk and scientes: thank you for the mentorship, I got something I can work on tonight (PDT). I need to wrap up some online course work first, but later I'll dive into this assignment.