dingenskirchen has quit [Ping timeout: 265 seconds]
sirnaysayer has joined #zig
___ has joined #zig
metaleap has quit [Ping timeout: 240 seconds]
ave_ has quit [Quit: Connection closed for inactivity]
<pixelherodev>
If I have a pointer to a structure, and I do `var a = p.*; a.blob = newval;`, `a` is a copy of whatever p pointed to, correct?
<fengb>
Yep
<pixelherodev>
Context: wanted to make sure that if I do that with a @ReturnType(std.mem.separate) (an iterator), I can then do a `.next()` w/o modifying the original
<pixelherodev>
Lexer v2 is finally at the "actually writing code stage" :D
<Snektron>
Lengthy read but it looks like they got something similar to Zig errors
<Snektron>
I think that an effect system (botton of the page) would be a nice addition to Zig as well
<Snektron>
In some form or another
<Snektron>
Because theres still a problem with the whole doubly defined methods for const and non-const
<Snektron>
You can probably do it with status quo but i dont really think thats the right way ahead
<pixelherodev>
Does seem interesting, but I'd point out the warning he mentions at the bottom
<pixelherodev>
"Gratuitously clever / hard to reason about"
<Snektron>
Yes that does seem like a point
<Snektron>
Nevertheless, i think its something to think about whether it fits in zig, possibly in some steralized way
<fengb>
“Our fundamental belief was that each is a condition the program cannot recover from.” Out-of-memory 🤔
<pixelherodev>
I don't think that's entirely wrong though
<pixelherodev>
Of course I know that Zig can catch OutOfMemory
<pixelherodev>
I think that whether that's correct is heavily allocator-dependent
<pixelherodev>
With a standard allocator - like, say, the std.c.c_allocator (or std.heap.c_allocator? either way), I think panicking is perfectly valid
<fengb>
In Zig, each library is capable of recovering from OOM
<pixelherodev>
Modern computers have a minimum of 4GB; if your system is using that much, programmers need to take responsibility and fix that
<pixelherodev>
I know
<fengb>
Instead of blowing out the entire program
<pixelherodev>
Sure, but at the same time, in most programs there is no real response
<pixelherodev>
Hence why most programs will do e.g. `catch @panic("Out of memory!")`
<pixelherodev>
For the occasional program, you might be able to free some memory that can be recovered later
<pixelherodev>
But most programs aren't structured in such a way
<fengb>
For programs sure, but we’ve decided in most languages that any library can panic and crash the stack
<Snektron>
Its the usual panic in application code but return error in library code
<Snektron>
So i think zig is taking the right way here
<fengb>
At least Zig is the only language I know that designs around gracefully communicating OOM
<pixelherodev>
Not disagreeing
<Snektron>
Well, malloc in C doesnt crash by default so i guess it communicates OOM
<fengb>
But nobody checks 🙃
<Snektron>
I usually do
<Snektron>
I usually define errors for each type and make the initialization function return those
<Snektron>
Not so nice for error compositions though
<Snektron>
So its basically a manual error set
<Snektron>
A message in riotx glitched and is now constantly at the bottom of my screen in this room :(
Snektron has left #zig ["User left"]
<pixelherodev>
fengb, not nobody; *most* people don't, some of us do
<pixelherodev>
I mean, you could *probably* actually do manual "error sets" using the standard `errno`
<pixelherodev>
But it would be much much more annoying to work with than Zig's
<fengb>
I like Andrew’s talk where he showed the standard error “checking” of C
mahmudov has quit [Ping timeout: 265 seconds]
<daurnimator>
pixelherodev: many programs have reasonable ways to react to out of memory
<daurnimator>
pixelherodev: e.g. in a http server, you just throw the current request on the ground
Snektron has joined #zig
<daurnimator>
in a game engine you can skip a frame or drop the render distance
<Snektron>
.
<Snektron>
Damn
<Snektron>
Message is still here
<Snektron>
Finally
<Snektron>
Alright sorry for that
<BaroqueLarouche>
Snektron: at least the Matrix bridge is working for you, I wasn't able to reuse it using the official IRC bridge
<BaroqueLarouche>
so I went back to IRCCloud
<Snektron>
Yeah its a bit clunky
<Snektron>
Im not much of an irc fan tbh
<Snektron>
I'm probably to young for it
<BaroqueLarouche>
me neither
<BaroqueLarouche>
I stopped using IRC a really long time ago but rejoined because of Zig
<Snektron>
This is the only group i regular
<Snektron>
Weird that after such a long time there are only a few possibly successors for irc
<pixelherodev>
Snektron, I'm 18 and I prefer IRC to any other form of chat
<pixelherodev>
And it's really not that weird
<pixelherodev>
IRC as a protocol is quite good
<pixelherodev>
I can write a simple IRC client in maybe ten minutes
<pixelherodev>
And you don't have to sign away your data to companies that don't have your best interests in mind
<pixelherodev>
Plus, there are some really good clients
<pixelherodev>
Heck, a free account on IRCCloud is better than Discord IMO
<Snektron>
I didn't say discord is a good alternative
<Snektron>
But things like sending images is rather useful in instant messaging programs
<Snektron>
Also multiline messages, for small code snippets
<pixelherodev>
Eh, maybe; I think image links are fine as is
<pixelherodev>
I'm okay with the inconvenience of needing a minute to upload to e.g. imgur if it means everyone else has to do it also
<pixelherodev>
I don't like unsolicited images; I can ignore unsolicited links
<Snektron>
I think matrix actually lets me send images to irc
<daurnimator>
I've never found a satisfactory IRC mobile flow
<pixelherodev>
Yeah, but that just posts a link anyways
<pixelherodev>
I wasn't joking about it taking ten minutes to make a client; maybe I'll make one for Android using e.g. libGDX
<Snektron>
<daurnimator "I've never found a satisfactory "> As long as the matrix bridge holds up its actually quite nice
frmdstryr has quit [Remote host closed the connection]
<BaroqueLarouche>
I'm trying to remember how long it look me to have a basic IRC client working when I did it in C# when I was 17
<BaroqueLarouche>
maybe a month?
<BaroqueLarouche>
(I'll be 34 in 21 days)
<Snektron>
I think i started on one but never finished it
<Snektron>
Similar age
<Snektron>
Happened quite a lot to my projects in that time
knebulae has quit [Read error: Connection reset by peer]
sirnaysayer has quit [Quit: Lost terminal]
knebulae has joined #zig
<fengb>
I still never finish projects :P
<daurnimator>
huh. "error: TODO: type coercion of anon struct literal to union"
<daurnimator>
I didn't realise that wasn't implemented
<Snektron>
<fengb "I still never finish projects :P"> Ive just gotten less time for side projects
<fengb>
That doesn’t stop me from starting up more >_>
<pixelherodev>
Welcome to the life of an engineer :)
* daurnimator
looks at TODO list..... oldest item on it is from 2008
_Vi has quit [Ping timeout: 272 seconds]
<shakesoda>
irccloud is nice, i've been using it for a couple years
<shakesoda>
and i, too, have written a small pile of irc clients in the past
ntgg has joined #zig
ntgg has quit [Client Quit]
traviss has quit [Quit: Leaving]
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
mahmudov has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
<pixelherodev>
`(1 of 5): broken LLVM module found: cannot guarantee tail call due to mismatched ABI impacting function attributes` Hmm
<pixelherodev>
Anyone know what that means?
<pixelherodev>
`mismatched ABI impacting function attrs`?
<pixelherodev>
This is in a function tail calling itself via `@call(.{.modifier = .always_tail}`
<pixelherodev>
`return self.next();` works, but `return @call(.{.modifier = .always_tail}, next, .{self});` gives that message
<pixelherodev>
The return type of `next` is ?!some.structure
<pixelherodev>
s/?!/!?
<pixelherodev>
Ah never mind, pretty sure it's the inferred error set
<metaleap>
daurnimator: you mentioned the other day your "autojson" endeavour can also handle unions now, now for marshaling this is smooth to do, but how do you handle them on unmarshaling?
<pixelherodev>
Better yet: `error: incompatible types: 'anyerror!?.ziggirat.LexerTree.Token' and '.ziggirat.LexerTree.Token'`
<daurnimator>
metaleap: what do you mean? have a look at the code :)
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<metaleap>
you dont analyze the json.Value-at-hand against all possible members and rank each one's suitability picking the top candidate do you :D
<pixelherodev>
Also, apparently declaring the token of optional type and then returning that constant works
<pixelherodev>
Right, but I'm saying isn't that wrong?
<metaleap>
ah "first match", yeah could work out for most practical uses
<pixelherodev>
Wouldn't it be better to actually store the active / tagged member?
<daurnimator>
sure. but not everyone does
<metaleap>
pixelherodev: for sure if you have 100% control over the JSON-"schema" you're dealing with
<daurnimator>
and usually you have a union of struct and number; rather than compatible types
<pixelherodev>
True
<metaleap>
OR you have a union of structurally-overlapping objs .. now these tho are sometimes best union-modelled at the field level but it depends
<metaleap>
daurnimator: haven't parsed through the full diff but while i rolled something custom for "practicing zig" purposes in my libjsonrpc effort (needed by my liblsp effort needed for an upcoming ziglangserver effort =) i'd in the long term of course favour on your autojson when it does land in stdlib. as such, let me share some "corner-cases" from mere reflection-based traversing i found needed handling in practice so far, more might come up --- you might
<metaleap>
have covered them or decide them out of scope for general-purpose but just to share:
<daurnimator>
I have vague plans to also have a trait `jsonParse` that e.g. unions can provide
<daurnimator>
but it got messy with the token-lookahead; so I skipped that for now
<metaleap>
(btw i operate on already-parsed / -synthesized json.Values not Tokens but nvm)
<metaleap>
ok cases i had to cover so far:
<metaleap>
1. user-provided mapping function from json-obj-field-names to zig-struct-field-names and back to handle keywords such as `type`
<pixelherodev>
Bug found in trunk: I have a function with return type `!?A`, if it does `return A{};` the compiler refuses, if it does `const a: ?A = A{};return a;` it works fine
<pixelherodev>
Anyone know off hand if that's known?
<daurnimator>
metaleap: re 1. I already added jsonDump trait support which cover this in one direction; jsonParse is sort of planned (see above).
<daurnimator>
pixelherodev: yes that's known I think
<metaleap>
2. "embedding" (think Go-like struct embeds or JS/TS/C#/etc simple single inheritance) via fields detected as "embeds" by user-specified predicate. ie. in the JSON the embed fields live at the same level as the embeddee fields and at the non-JSON side you want them in some embedded-field / "base instance" etc.
<pixelherodev>
newly found bug: if you do a readUntilDelimiterOrEof where buffer size is zero, the first byte of the stream is discarded
<pixelherodev>
Going to fix that shortly
<pixelherodev>
I'm using a dynamically increased capacity; whenever StreamTooLong is encountered, it doubles buffer size and performs a tail call to reread the line
<pixelherodev>
More generally, I think the last byte is just gone on a StreamTooLong
<metaleap>
3. option for the unmarshaler to set optional-typed destinations to null on invalid inputs rather than erroring
<daurnimator>
pixelherodev: I really want to fix those functions to not use std.Buffer
<daurnimator>
metaleap: not sure what you mean by 2. can you give me an example
<metaleap>
4. option to either set missing optional fields to null or error if explicit `null` isnt there (not so crucial perhaps tho in reality)
<daurnimator>
pixelherodev: I mean `readUntilDelimiterAlloc`
<metaleap>
can do hang on
<daurnimator>
metaleap: 3. sounds possible as a parse option. once autojson is merged you should send a PR for that one.
<daurnimator>
though it would need to be supported with a use case
<pixelherodev>
daurnimator, okay, but I'm not using that :)
<daurnimator>
I don't know what sort of program would want to coerce invalid input to `null`...
<metaleap>
2. example: now this is out-of-date / will be refactored into new proj, but as a showcase for "embedding": many of the structs in this source have the pattern of certain fields having PascalCased names exactly equal to their types' names. example in line: https://github.com/metaleap/zigbag/blob/master/dummylangserver/lsp_types.zig#L752 but scroll up or down many more such examples show up
<metaleap>
you can instantly imagine that for those such a field doesnt existing in the LSP json. instead, the fields of the "embed struct" live at the same level in json as the "own" fields. but you dont want the duplication in your own data types
<metaleap>
especially when `WorkDoneProgressParams` gets changed in a future version you dont want to change your 20 places in .zig
<daurnimator>
metaleap: that just sounds like you want anonymous fields in zig; which is an open proposal
<metaleap>
yeah but i mean for the present while the future hasnt arrived yet =)
<metaleap>
5. capture "general free-form object" field use-case. some `any`-typed or `object`-typed fields usually come up in some schemas that would be mapped to std.json.Value / Vlue.Object
<daurnimator>
1, 4, 5 all sound like they would be solved with jsonDump/jsonParse
<daurnimator>
even 2
<metaleap>
6. detect if destination is StringHashMap(Foo) and then dont treat it like any-old-user-struct , this one's probably obvious. same goes for ArrayList(Foo) if one didnt want to impose slice-only-by-convention (in the dest type structures) to the user or such
<metaleap>
you mean as traits, not as today's stdlib funcs?
<daurnimator>
To get 6. I would expect StringHashMap to implement a jsonDump method.
<metaleap>
yeah ultimately this sort of tunability is very desirable for std.json absolutely. reality always hits with cases where fine-tuned custom handling is called for.
<metaleap>
i found this in golang practice quite often and was glad for their Unmarshaler / Marshaler 1-method interface to be implementable for any userland typedef
<daurnimator>
also note that you can create helpers for custom parsers/dumpers and then use them like: `pub usingnamespace json_helpers.renameFields([_]struct {old: const[] u8, new: const []u8}{ .{.old = "foo", .new = "bar"}, ........ });`
<metaleap>
7. "option" (i do it by default for now tho) to allow cross-convertibility on unmarshal: expected int but got float & vice versa, enum from either int or float or string, bool from "true"-string or "false" string or 0/1 nums if present. now this is debatable but more like "incoming payloads are buggy wrt to the schema at hand but the outside-world owners of those wont/cant fix in the schedule that matters"
<metaleap>
for LSP i might turn it off actually, as long as one serves a buggy client can be rejected early
<metaleap>
like "optionally allow maximum sloppyness from the counterparty" setting :D
<daurnimator>
that sounds like a terrible idea
<daurnimator>
but again... can be done with a custom jsonParse if we supported that
<metaleap>
i know, but non-negotiable 3rd-party inputs can be a terrible place :D
<metaleap>
yeah so traits would be the most apt design here, because general-purpose std.json shouldnt special-case on such situational dealings indeed.
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
* redj
is cusious to see daurnimator's todo list
_whitelogger has joined #zig
<daurnimator>
redj: the oldest item is a book recommendation
<metaleap>
daurnimator: is it "getting things done" :P
<metaleap>
mikdusan: it's on the agenda at my end =) have an unrelated segfault i want to prep a mini-repro for first to file beforehand tho. clarification question however, new field "usage" isnt the existing one where userland code describes "mystep", ie. "does foo", but a new one (defaulting to null) for the possible "[-- [args]]" appendum when `addArgsFromBuilder` would be called?
<mikdusan>
yeah probably don't touch .description and add an optional beside .description
vegai-old has left #zig ["Kicked by @appservice-irc:matrix.org : issued !quit command"]
nrdmn has quit [Quit: Lost terminal]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
metaleap has joined #zig
adamkowalski has joined #zig
<fengb>
pixelherodev: generic integer types, like std.math.max. Sometimes it’s easier to build a function or struct to have @Int(size) and degenerating to u0 is easier
<metaleap>
or u0 is the "real void" and void is just readability sugar alias for fleshy verbal mortals
<mq32>
metaleap, void is more a "empty struct", which you can create with the empty-block: `{}`
metaleap has quit [Read error: Connection reset by peer]
metaleap has joined #zig
<pixelherodev>
I'd argue that std.math.max should return a u1 in that scenario, but /shrugs
<fengb>
I meant passing u0 into math.max would “just work”
lunamn has quit [Quit: leaving]
BaroqueLarouche has joined #zig
Akuli has quit [Quit: Leaving]
<pixelherodev>
Right but I don't think it *should*
<pixelherodev>
I don't think a zero-bit number makes senser
<pixelherodev>
s/senser/sense
<pixelherodev>
I saw Andrew's logic - (0 .. (2^0) - 1) as the range - and I disagree
<pixelherodev>
The actual definition of `u0` isn't `a number with the range 0 .. pow(2, 0) - `, it's `a number with zero bits`
<pixelherodev>
I'd argue a `u0` shouldn't be able to hold `0` at all
<pixelherodev>
That range is just a more intuitive definition of the range, which happens to be true for n > 0
<fengb>
It doesn’t hold 0 but it **is** zero because both are absence >_>
<pixelherodev>
No, that would be null
<pixelherodev>
We have a value for `absence of value`
<metaleap>
or void :P
<pixelherodev>
Nah, void is the type
<pixelherodev>
s/the/a
<metaleap>
ok {} bah
<metaleap>
absence of even absence
<fengb>
Absence in the math sense. Number theory is confusing
<pixelherodev>
It has zero bits. It doesn't have a bit set to zero.
<pixelherodev>
Therefore, it's NaN
<andrewrk>
you're making a special case
<pixelherodev>
For what?
<andrewrk>
for a 0 bit number. if u0 has the value 0 then it is not a special case
<fengb>
It also doesn’t store anything by definition since it’s 0bit. It’s just defined to always == 0 by the compiler
<fengb>
NaN exists only for floats. There’s no equivalent for integers
<mq32>
as in a math sense, an integer is a set that can hold 2^n distinct values where n is the number of bits
<mq32>
and thus 2^0 == 1 which means u0 should hold a set of a single value
nrdmn has joined #zig
ur5us has joined #zig
<pixelherodev>
fengb, I meant it's not a number
<pixelherodev>
Not literally the NaN value
<Snektron>
"u0 makes things work correctly" except you need a special check to see if the type is u8
<mq32>
pixelherodev, why shoud it not be a number? :D
<pixelherodev>
By that logic, we could have u1/2 which has sqrt(2) possible values
<pixelherodev>
uN is an integer where N is the number of *bits*
<pixelherodev>
If there's zero bits, you can't have a value
<pixelherodev>
u0 already *is* a special case
<pixelherodev>
There's no other type that has a real value without storage
<mq32>
void, any empty struct may have a real value
<mq32>
in a math sense, it's completly logical to have a set of a single value
<mq32>
all operations are well defined
<pixelherodev>
Right, but it also doesn't *exist*
<pixelherodev>
This is a set of no values
<Snektron>
<pixelherodev "There's no other type that has a"> comptime types
<mq32>
pixelherodev: It's a set of exactly 1 value (which is zero)
<mq32>
and the nice thing about "storing a single value from a set with only one possible value" is that we don't need any bits
robinsoncollado has joined #zig
* pixelherodev
shrugs
<jaredmm>
Windows, new directory, `zig init-exe`, copy the stdin code from https://github.com/ziglang/zig/issues/4358. `zig build run` fails with a big `The handle is invalid.` stacktrace and error. `zig build` and then running the output works.
<jaredmm>
Maybe someone can help me figure out what I'm missing here. I think I conceptually understand what could be happening, but I couldn't find any existing issue with the keywords I picked.
* mikdusan
switched to using git "worktrees" . so far so good.
<pixelherodev>
Huh, worktrees look interesting
<mikdusan>
biggest thing to keep in mind - you can't move worktree's around manually. and the main worktree can't be moved as long as other worktree's exist.
robinsoncollado has quit [Remote host closed the connection]
<nrdmn>
aren't sentinels of the same type as the array elements? If yes, then I think the array in your example should be terminated with a 99 byte and a 0 byte
<andrewrk>
good point, I accidentally introduced endianness into the test. I'll make the sentinel 0x9999
<andrewrk>
done
<andrewrk>
I used a non-zero value so that the test will likely fail in debug builds
seoushi has joined #zig
<mikdusan>
andrewrk: I'm not understanding stage1 assertNoError() (about a dozen sites, mostly in analyze.cpp). by calling type_resolve isn't that a major side-effect that is present in debug builds, and missing in release?
<metaleap>
asked this before but.. i need to hash-set strings at comptime and both the page_allocator nor the fixedbuf compile-error on me via their reallocFn
<metaleap>
has nobody ever kept a dynamic list or hashmap at comptime? :D guess can roll my own fixed-buf-backed-slice/arraylist mashup
<metaleap>
generally i mean fixedbufalloc would suffice IMHO for comptime and is just a trait-ish-layer over a fixed-size array right? might clone a comptime version then try to reduce to the error point some day. but will read thread first, was probly tried already
<andrewrk>
mikdusan, assertNoError() on type_resolve seems like a bug
<fengb>
Any allocation assigns undefined, which I believe is still broken at comptime
<andrewrk>
mikdusan, unfortunately the very idea of types resoving in phases did not used to be how it worked, and the codebase slowly evolved to accomodate that
<andrewrk>
which is a major source of bugs
<mikdusan>
on a branch I may have introduced a bug, which was hidden with this side effect. picture is clearer now, thanks!
adamkowalski has quit [Remote host closed the connection]
<aperezdc>
Well, I hope people here also fond that amusing
ltriant has joined #zig
lukeholder has quit []
lukeholder has joined #zig
<pixelherodev>
std.ascii.isAlpha checks if something matches `[a-zA-Z]`?
frmdstryr has joined #zig
<Snektron>
imagine walking around with 100 smartphones
<Snektron>
even if second hand
<pixelherodev>
My first-hand smartphone was $100
<pixelherodev>
I wouldn't be surprised if you could get 99 second-hand for... say... $4K?
<Snektron>
still a lot of money to carry around in a cart
<pixelherodev>
True
<pixelherodev>
But if it saves you time, it might be worth it even if someone steals them, say, every month?
<pixelherodev>
Time is money, after all
<Snektron>
<metaleap: has nobody ever kept a dynamic list or hashmap at comptime?> i've not in this language
<Snektron>
but my c++ ones aren't very nice to use
<metaleap>
Snektron it would be so beautiful in contrast in zig =) so many niceties in std to reuse except some rely on *sth* managing to implement reallocFn/shrinkFn in *some* fashion