ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
dimenus has joined #zig
rsdimenus has quit [Ping timeout: 245 seconds]
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?
<stratact> telemach: I left a comment in your gist
<telemach> thanks for the comment, TIL @This()
<stratact> Ah, I thought recognize your avatar from somewhere. You're one of the lead plugin designers for Kakoune?
drasko has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
mahmudov has quit [Ping timeout: 258 seconds]
tencho has joined #zig
<tencho> Hi, I've started learning zig yesterday. I cannot figure out why the following does not compile:
<tencho> 1 const std = @import("std");
<tencho> 4 pub fn main() void {
<tencho> 7 return;
mahmudov has joined #zig
<euantor> tencho: Can you post your full code on or or something? It seems to be cut off
<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
<Tetralux> Depends on what Maketype does.
<mq32> fgenesis: types are always comptime values
<mq32> you cannot have runtime type information
<Tetralux> .. and that's why ^ :p
<fgenesis> ah, then i misunderstood the question
<fgenesis> was still looking at and apparently my brain farted
<tencho> It works for some of the fields , but it won't work for unions ?!?
laaron has quit [Remote host closed the connection]
<fengb> Const is fine. The compiler would convert const into comptime known. It's the var that's a big problem
<Tetralux> fengb: Which const?
<Tetralux> Only L7 changes.
<fengb> const foo = anytype
laaron has joined #zig
<Tetralux> Sure, but I'm not sure how that applies to the example xD
<fengb> You can't `var foo = anytype` because vars are runtime
<Tetralux> Oh - Sorry - I thought you meant that something changed to being a const in the second example.
<Tetralux> You were being more general than that.
<Tetralux> This compiles though
<Tetralux> And it's not entirely clear to me why.
<Tetralux> When this does not: g_d[idx]= decl;
<fengb> Because the names are just strings and extractable
<Tetralux> Yeah, but you're assigning a comptime-known field.
<Tetralux> .. in a var
<Tetralux> .. that has a type only known at comptime.
<Tetralux> Why are you allowed to reassign it?
<fengb> That's not the problem
<fengb> You can't make a copy of TypeInfo because it doesn't exist in the runtime definition
<fengb> Whereas strings are fine because they're just strings
<Tetralux> Let me put this a different way.
<fengb> So it's just an array of strings, and we just made a few literal copies
<Tetralux> What's the type of g_d at runtime?
<fengb> It's a compile error
<fengb> It can't exist
<Tetralux> It is not.
<Tetralux> See the example I posted.
<Tetralux> It compiles.
<fengb> Oh...
<tencho> trying to make a better example:
<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.
<mq32> const CBORValue = uniom(enum) { integer : i64, string : []u8, … };
<mq32> ?
<Tetralux> Already have that.
<mq32> for deserialization
<mq32> for serialization you can introspect the serialized object
<Tetralux> The problem is, you may not have enough bytes to completely read an object.
<Tetralux> I haven't worked on it for over a week because it was getting me down, so I may not completely remember.
<Tetralux> But, I know how I'd do it if I had RTTI.
<Tetralux> I do not see a neat solution without it.
<mq32> huh
waleee-cl has joined #zig
<fengb> I think we need more subtle blog posts like this :)
<mq32> a bit offtopic: has someone here experience with both WASM and WebSockets?
<fengb> Uh... I've done both separately :P
<mq32> i want to do some stuff with both technologies
<mq32> i read some stuff about and it looks like it's a cool replacement for Lua (for scripting in games or similar)
<mq32> and now i wonder if i could "port" my UI system with emscripten to wasm+websockets instead of normal UDP sockets *grin*
<fengb> I don't know much about wasmer... but it looks like a runtime for wasm only. WebSockets is a browser technology and isn't a part of the spec
<mq32> yeah, i know
<mq32> but i need to glue websockets somehow into wasm (or access them from there)
<fengb> Oh
<mq32> would like to have as little JS as possible :D
<fengb> I'd expect emscripten to have glue to make it easier
<mq32> mhm
<mq32> have to look that up some time
<mq32> sadly i couldn't find a single easy websocket library
<mq32> that has the same "easyness" as the JS api
<Tetralux> Wait
<Tetralux> You use UDP sockets for a UI?
<mq32> Tetralux, not yet, but i will :D
<mq32> well, UDP is just a layer between, but just replace UDP by "realiable datagram transport layer"
<Tetralux> I'm immediately suspicious as to why a message bus is not faster.
<Tetralux> Or a msg bus over UDP if you wanted it to be remotely viewed for that matter.
<mq32> because a message bus is hard to implement remotely
<Tetralux> Can you elaborate a little on that?
<mq32> the UI uses a really non-standard way of doing things
<mq32> it's more similar to HTML/CSS than to Qt or Windows Forms
<mq32> but also more similar to WPF than HTML
<Tetralux> Sounds like the problem is more arctitectural than technical?
<mq32> the UI system needs a reliable datagram transport layer to be used
<mq32> because it is message based API, not function based API
<Tetralux> Message-based API _requires_ a reliable transport layer?
<Tetralux> You mean like...
<Tetralux> shared memory or a channel? xD
* Tetralux smirks a little
<mq32> channel
<mq32> SHM would not work over network/serial line/... :D
<gonz_> It is indeed hard to share memory over a network
<Tetralux> A message bus would though ;)
<mq32> what is a "message bus" for you?
<Tetralux> Conceptually, it's a pipe you pop off messages and handle them if there is any.
<fgenesis> something on four wheels that delivers mail and packages
* mq32 slaps fgenesis a bit with a large trout
<Tetralux> It can in practice, be a stack/array, channel.
<Tetralux> Or on top of a socket.
<Tetralux> Or file, for that matter.
<mq32> yeah, that's probably the right wording then
<Tetralux> Usually, shared memory or array though.
kristoff_it has joined #zig
<Tetralux> (for speed.)
<fgenesis> what about reliability
<Tetralux> Reliability?
<Tetralux> Of an array? :thinking:
<mq32> Rowhammer says your array content is not reliable!
mahmudov has quit [Remote host closed the connection]
<Tetralux> Better be! Literally nothing would work without it XD
<kristoff_it> fengb: :D I think once Andrew gets enough budget for a marketing team I'll have a good argument for getting hired haha
<mq32> Tetralux, lookup rowhammer attack :D
<mq32> kristoff_it, nice article again :)
<fgenesis> let's not assume cosmic rays ok
<gonz_> Tetralux: "Usually" shared memory seems misleading.
<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 ;)
<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.
<Tetralux> 3B seems reasonable.
<mq32> 1 byte type information, 1 byte property count, 1 byte child count
<mq32> well
<Tetralux> How many UI elements you got?
<Tetralux> I swear to god if you say > 1000.
<mq32> you mean widget types?
<Tetralux> Instances*, but yes.
<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
return0e_ has quit [Ping timeout: 268 seconds]
Akuli has joined #zig
wilsonk__ has quit [Quit: - Chat comfortably. Anywhere.]
<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.
<fgenesis> mq32: just leaving this here,
<Tetralux> mq32: That's good then :)
<mq32> my code right now:
<mq32> uses big-endian encoding, that's why the encoder is not as readable as the decoder :D
<Tetralux> Seems reasonable at first glance :p
<Tetralux> A faster option might be to just store numbers the same as the payload
<Tetralux> Yeah, but varints will not.
<mq32> so i have that VLI encoding for the length (1 to 5 bytes) and then the binary data
<Tetralux> Yeah, something like that.
<mq32> and i don't think that message decoding speed is slow :D
<mq32> *the slow part of the whole system
<Tetralux> The first byte tells you how many bytes the length is :p
<Tetralux> And yeah, if it's fast and works. A comment is good enough I guess.
<mq32> yep
<mq32> i have to document all formats anyways some time
<fgenesis> SOON(tm)
<Tetralux> I might frown at you for using something that isn't very obvious what it does without a comment but >.<
<mq32> i'm happy that for most of the data i can actually omit an length specifiers :D
<Tetralux> Yeah, CBOR has that too.
<Tetralux> For numbers <=22, it takes one byte.
<mq32> encoding is []{ type : u8, data : DependsOn(type) } where the array ends with a type=0
<Tetralux> Kinda like the small-string optimization.
<mq32> btw, to have something visual we talk about:
<mq32> that's the current state of the (visual) part
<Tetralux> Seems alright.
<daurnimator> Tetralux: you might want to do your CBOR stuff like
<fgenesis> not enough bling and smoothscroll
<Tetralux> It's hard to tell how much latency there is from that, but yes.
lunamn_ has joined #zig
desperek has joined #zig
<mq32> there is no networking involved yet
<mq32> also stuff like that will work with zero-frame latency, even with network
<desperek> how do i get commandline arguments? argc and argv as arguments to main?
<Tetralux> std.process.args IIRC.
<Tetralux> Or .argsAlloc if you want a slice of them in memory all at once.
<desperek> oh, thanks. do i have to read source to do anything btw?
<Tetralux> Basically yeah.
<Tetralux> It's easier than it sounds though.
<Tetralux> CTRL+F is your friend :)
<desperek> Tetralux, ctrl+f where exactly?
<desperek> in a spec. file/
<desperek> ?
<Tetralux> mainly.
lunamn has quit [Ping timeout: 240 seconds]
<Tetralux> Or the search thingy.
<fgenesis> Tetralux: you know, your answer still isn't very specific
tdeo has joined #zig
<desperek> We could not perform this search haha
<Aransentin> Is ?[*c]u8 supposed to be 16 bytes wide? This bit me when porting a C struct to Zig.
<Tetralux> desperek: You're meant to type something into the box XD
<Tetralux> But that will search all of zig.
<Tetralux> Filter for Zig code of course.
<desperek> theres no box tho
<Tetralux> Top left.
<Tetralux> "Search or jump to"
<tdeo> Aransentin: is it in an extern struct?
<Aransentin> Yes
<desperek> aa this one
<desperek> thanks
<Tetralux> o7
<Aransentin> Also doing stuff with it causes the compiler to start dumping it's internal memory to the console:
<desperek> it is hard though Tetralux
<fgenesis> Aransentin: awesome!
<Aransentin> :)
<Tetralux> duarnimator: Yeah, I considered that. First glance made me think it was a little overly complicated, but I did only glance.
<Tetralux> desperek: Yeah, if you don't know what something's called, you can only guess the file it's in.
<Tetralux> I have in my search history, for instance :)
<desperek> :/
<desperek> why is it so hard
<mq32> desperek, there was/is a project out there that parses a zig directory and creates a content listing
<mq32> maybe this is what you search?
<desperek> mq32, well, i just want to know what function does what really, not specifically searching for things
<desperek> but i guess thats not yet here .w.
<Tetralux> Yeah - doc comments are annoying sparse.
<fengb> Aransentin: pointers should be usize
<Tetralux> Oh yeah - sidenote:
<euantor> desperek: I believe you're trying to parse command line args? if so, check this:
<Tetralux> Made this yesterday.
<desperek> thanks
drazan0 has quit [Remote host closed the connection]
tencho has quit [Quit: WeeChat 2.6]
tencho has joined #zig
tencho has quit [Client Quit]
wootehfoot has joined #zig
qazo has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
kristoff_it has quit [Ping timeout: 276 seconds]
earnestly has quit [Ping timeout: 276 seconds]
earnestly has joined #zig
laaron has joined #zig
FireFox317 has joined #zig
qazo_ has quit [Ping timeout: 246 seconds]
qazo_ has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
shodan45 has joined #zig
marijnfs has joined #zig
drasko has quit [Ping timeout: 276 seconds]
ltriant has joined #zig
vegax87 has joined #zig
ltriant has quit [Ping timeout: 276 seconds]
Akuli has quit [Quit: Leaving]
kuon has joined #zig
<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> Yeah, that's my feeling.
laaron has quit [Quit: ZNC 1.7.1 -]
<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]
halosghost has quit [Quit: WeeChat 2.6]
<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 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? :)
<andrewrk> _whitelogger has that done for you already :)
<stratact> Ah of course 😌
<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.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
ltriant has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig