<bgiannan>
well "I'm still experimenting. Don't try to use it yet."
<daurnimator>
bgiannan: you could also look at https://github.com/andrewrk/tetris/ which doesn't use SDL but might do things similar to what you want?
<bgiannan>
i know sdl and what i can do with it, glfw not so much
<bgiannan>
and i would already have to learn zig itself so adding a new lib to learn on top of that would makes things unfun
<gonz_>
bgiannan: Maybe work with zig-sdl as a base? It should be convenient to have some of the work already done and you could still change things + add more to it.
<gonz_>
Be careful to not learn Zig through the lens of compatibility types, though; it seems to be very common.
<bgiannan>
my idea was to abstract away most of the sdl stuff and forget about it
<gonz_>
I'm sure you'll be fine either way and I'm not sure which of these would provide less friction but I'd guess it'd be the "build on zig-sdl" way.
<bgiannan>
yeah i'll give it a go
andersfr has joined #zig
andersfr has quit [Client Quit]
lqd has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
<samtebbs>
bgiannan: I've been working with SDL2 lately, and I find that cImport'ing the header works well. zig-sdl didn't for some reason
<FireFox317>
Yeah I think you really don't need the zig-sdl repo, because that is for building SDL from source and you probably already have the libraries for SDL installed on your pc.
<FireFox317>
And should be able to link against them, and CImport the header files
<samtebbs>
bgiannan: Yeah it's pretty easy. Check out the build.zig to see how to link with it
<samtebbs>
`linkSystemLibrary("SDL2")` and `linkSystemLibrary("c")` will do it
<bgiannan>
great! i'll see if i can get a minimal program running
avoidr has quit [Quit: leaving]
FireFox317 has quit [Remote host closed the connection]
_whitelogger has joined #zig
<bgiannan>
When installing zig with homebrew, it asks for Xcode 11 even after i installed it
<gonz_>
I would've thought the binaries on the home page would've sufficed like for the other platforms
ntgg has quit [Ping timeout: 248 seconds]
<gonz_>
Curiously the instructions don't even mention Xcode, though...?
LargeEpsilon has joined #zig
Ichorio has joined #zig
<samtebbs>
bgiannan, gonz_: Perhaps it's asking for Xcode as that's the normal way to get a C/C++ toolchain on a mac
<samtebbs>
Installing gcc/clang separately may help
<bgiannan>
i don't mind it using xcode toolchain
<bgiannan>
just wondering why it asks for xcode 11 when it's there
<daurnimator>
bgiannan: what exactly is asking for xcode?
<bgiannan>
homebrew is
<bgiannan>
when upgrading from 0.3.0 to 0.4.0
<gonz_>
I think it's unwise to be on 0.4.0 at the moment
<gonz_>
You should probably be on master
<samtebbs>
Agreed, for the syntactical and semantic changes, as well as bug fixes
<bgiannan>
`xcode-select --install` did the trick
<bgiannan>
ah
<bgiannan>
so i should build zig myself
<gonz_>
No, you can download the master binaries from ziglang.org
<bgiannan>
ah yes just saw that
<daurnimator>
bgiannan: depends on if you expect to end up contributing to zig itself. If you can imagine yourself helping with the standard library then it's worth building things yourself
<gonz_>
Setting it up is useful, but running only self-built isn't necessary even if you do end up contributing, it seems to me. I have several downloaded versions + self-built.
<samtebbs>
bgiannan: I would only build if you (as daurnimator said) want to contribute to zig or want to pull down certain changes and build immediately rather than wait for the nightly builds.
LargeEpsilon has quit [Ping timeout: 272 seconds]
<bgiannan>
alright managed to run a minimal example
<bgiannan>
should be easy enough from there
LargeEpsilon has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
<bgiannan>
what's the best practice to serialize and save data to a file?
<samtebbs>
bgiannan: What type/s do you want to serialise?
<bgiannan>
structs? i'd like to avoid having to writing serializing functions for all my data types if possible
laaron has quit [Remote host closed the connection]
<samtebbs>
Well a naive way would be to convert your struct instance to a pointer and write that to a file as a buffer :p
<samtebbs>
That falls down if you use pointers ofc
<bgiannan>
hum
<bgiannan>
what happens when a struct field is another struct ?
<samtebbs>
That should be fine as the field is embedded inside the parent struct
<bgiannan>
alright
laaron has joined #zig
laaron has quit [Remote host closed the connection]
<daurnimator>
bgiannan: a different answer is: time to write a CBOR library or to at least "automaticify" the JSON library
<bgiannan>
the file would be huge for the amount of data i want to save
<bgiannan>
as binary it was already around 4Mo
laaron has joined #zig
<bgiannan>
as json i mean
<Tetralux>
Maybe I should write a MsgPack lib for Zig...
<daurnimator>
Tetralux: why? CBOR is better is all respects...
<Tetralux>
Never heard of that.
<daurnimator>
Tetralux: it's a proper stand created after the shortcomings of msgpack were figured out. https://cbor.io/
<samtebbs>
daurnimator: Regarding the hardware that you have access to from worksonarm, what can you do on it? Do you essentially have access (sudo?) over ssh?
<daurnimator>
samtebbs: its a dedicated hardware box. I can do anything I want with it
<daurnimator>
rules are essentially "don't abuse things" "only use it for open source projects"
<Tetralux>
Thanks, daurnimator.
<samtebbs>
Ok, so theoretically if we can just get it connected to the CI then it's a great option
<daurnimator>
samtebbs: yup
LargeEpsilon has quit [Ping timeout: 245 seconds]
<samtebbs>
That may require using a different CI solution though as from what I know, azure devops doesn't allow you to add arbitrary machines as build agents
<samtebbs>
Whereas TeamCity does
<daurnimator>
samtebbs: just give me something I can feel confidentish can't be exploited by arbitrary PRs (or at least can be reset afterwards)
<daurnimator>
samtebbs: gitlab CI does... but their arm64 runner has a bug when used in "docker" mode :(
<bgiannan>
how do i express errors in zig? from the doc it seems you define an error type as a return type for your function, but what if the function returns a valid value? can i do `fn afunction() SomeError, AValidType {...}` ?
<daurnimator>
bgiannan: you return an error by doing `return error.AnyErrorYouWant`
<samtebbs>
daurnimator: And that bug doesn't seem to be close to merging given how long it's been there for so far
LargeEpsilon has joined #zig
<daurnimator>
bgiannan: your return type will need to include your error set. just prefix with ! for automatic error set inference
<samtebbs>
benaiah: `YourError!YourReturnType`
<daurnimator>
samtebbs: indeed :(
<samtebbs>
oops wrong tag, bgiannan
<fengb>
Gitlab doesn’t seem to resolve open source bugs :/
<samtebbs>
so `fn afunction() SomeError!AValidType {}`
<daurnimator>
bgiannan: ^ that substitute in directly as may want.
<daurnimator>
though in 95% of cases you just end up using inferred error sets
<samtebbs>
daurnimator, fengb: :/ I vote for migrating to TeamCity if that is at all reasonable. I've used it at work to verify my own patches and I've made it run on arm hardware
<daurnimator>
samtebbs: its not so much a migration we need as something additional
<daurnimator>
samtebbs: I'm not familar with team city. got a tl;dr?
<fengb>
I haven’t heard of TeamCity for over 10 years. I didn’t know they’re still a thing
<samtebbs>
daurnimator: It's from JetBrains (peeps behind IntelliJ, Kotlin, CLion etc.) and is more "low level" CI software. You create scripts that happen on some event and it propogates them to your build agents
<daurnimator>
samtebbs: looks like it's not a service but a run-it-yourself?
<samtebbs>
That event can anythting from Git, GitHub PRs, webhooks...
<daurnimator>
samtebbs: if we're doing that we might as well use more traditional stuff like jenkins... or drone
<samtebbs>
daurnimator: Indeed
<bgiannan>
what's the best practice to handle c functions that may return NULL?
<bgiannan>
just test for it ? or will it raise an error?
<daurnimator>
bgiannan: ? makes a type optional in zig
<bgiannan>
ah there's optional types great
<samtebbs>
That "indeed" was regarding it being run-it-yourself. I've not looked into jenkins or drone really
<daurnimator>
samtebbs: I'm happy to manage a job-runner myself; but I'm too busy to maintain an actual drone/jenkins server myself. are you volunteering? :)
<samtebbs>
It being run-it-yourself would mean we'd need harware to run the server on but we could do that on the worksonarm hardware as it's free(?)
<bgiannan>
daurnimator, so something like `var sprite: ?[*c]SDL_Surface = ...`
<Tetralux>
bgiannan: The equivalent of T* from C cannot be null in Zig, so a pointer that might not point to a valid memory address is ?*T.
<samtebbs>
daurnimator: I reckon I am volunteering :D If I don't have to pay for it... (being a broke student and all)
<bgiannan>
`?*` or `?[c*]` ?
<Tetralux>
First one.
<Tetralux>
The second should never be used in code you write.
<bgiannan>
alright
<daurnimator>
bgiannan: [c*] is a "C pointer" => a pointer that is automatically generated from C headers that is undocumented for if it is one item or many items./
<daurnimator>
bgiannan: you should convert your C pointers to single item pointers (*), slices ([]) or multi-item pointers ([*]) as soon as possible
<daurnimator>
samtebbs: a CI server wants a bit more than that... e.g. you'll need to manage user data, backups, etc....
<samtebbs>
daurnimator: what user data?
<Tetralux>
Does the stdlib have a way to discover how much physical memory is free?
<daurnimator>
samtebbs: well usually e.g. the author of a PR can kick it off again
<daurnimator>
Tetralux: you should pretty much never be doing that
<daurnimator>
unless you're on a freestanding microcontroller
<Tetralux>
If you don't know if you are or not... for one.
<daurnimator>
what??
<Tetralux>
Otherwise, it can help to make a choice between a slow, resource-easy way, and a fast, but resource-heavy way.
<Tetralux>
Because you don't know if you fail until you are already part way through a process.
<daurnimator>
Tetralux: physical memory on a system should almost be always used. however much of it is used for speculative prefetches and the kernel will drop things as memory demand increases
<daurnimator>
i.e. memory free is not a good indicator of if memory is available
<Tetralux>
I meant that you'd be asking the kernel how much is free, if you have a kernel.
<daurnimator>
that's not useful info
<Tetralux>
What would you suggest then?
<bgiannan>
am i responsible to test that an optional is not null?
<Tetralux>
Yes.
<daurnimator>
bgiannan: yes.
<Tetralux>
There are several ways.
<Tetralux>
If you know it isn't: optional.?
<Tetralux>
If not
<daurnimator>
Tetralux: ask the kernel for lots of memory. if you get it, do the lots-of-memory path. otherwise ask for less memory; and do the small-memory path
<Tetralux>
if (optional) |value| { ... }
<Tetralux>
Or
<Tetralux>
var value = optional orelse @panic("there wasn't a value")
<samtebbs>
daurnimator: Oh I see, so you'd want an author to be able to kick off another build in case of infrastructure issues? Any changes made to a PR would be picked up and built automatically.
<samtebbs>
TeamCity does have a registration and log in system so contributors could possibly be given accounts with limited privileges.
<samtebbs>
And it may be possible for them to fire off builds from their own PRs, not sure though
<samtebbs>
s/from/for
<daurnimator>
samtebbs: so something I considered was just running gitlab in shell mode; but only for master branch. that way a driveby PR can't break things
<fengb>
Is it just the runner that's broken? We could maintain a forked copy
<samtebbs>
daurnimator: Like nightly builds
<daurnimator>
samtebbs: well per-master-commit CI rather than per-PR
<daurnimator>
fengb: so that's where I'm waiting to hear back from someone: they are apparently maintaining a working fork
<fengb>
Ah okay
<samtebbs>
daurnimator: Ah makes sense. At least that would give andrewrk a chance to review them first. But it is valuable for contributors to have their changes validated before merging
<daurnimator>
samtebbs: would be better than the status quo of nothing
<fengb>
I've been waiting for a working changeset get merged into Gitlab proper for over a year now so I'm kinda bummed at their process
<samtebbs>
daurnimator: It's certainly an option for the short-term.
<Tetralux>
You can return from a block, but you don't use the 'return' keyword. You label the block with `label: {...}` and then `break blk: value;`
<Tetralux>
Whoops - wrong window xD
<samtebbs>
fengb: I'm surprised since surely they have people paid to review external changes...
<samtebbs>
daurnimator: Can contributors currently fire off builds of their PR without making any changes?
<Tetralux>
I've wanted default parameters since I started using Zig.
<Tetralux>
I use those things pretty frequently in languages that have them.
<fengb>
Closest we have atm is a struct with default values
<Tetralux>
Though if you have we, PLEASE FOR THE LOVE OF SOMETHING BEAUTIFUL, have them so that you have to specify them by name=value ALONG WITH the positional arguments.
<Tetralux>
The second part is more important than the first.
<daurnimator>
Tetralux: that makes them *not* required IMO
<daurnimator>
Tetralux: because then you can just pass a single struct
<daurnimator>
I think struct type inference is an open proposal (maybe even accepted?)
<fengb>
At this point, I just want inferred struct builders
<fengb>
Ha
<Tetralux>
So for `fn f(x: i32, y: i32 = 47)`, you can do `f(42, y=7)`, `f(32)`
<daurnimator>
I think it would be: `foo(.{.bar="foo"})`
<daurnimator>
though there's the "tuple" issue around as well
<Tetralux>
Personally, I think that making someone have to write a struct, _just_ to give the args default values.... is a bit silly.
<Tetralux>
I'd rather it was done more ergonomically than that.
<daurnimator>
Tetralux: structs can be anonymous...
<fengb>
Overloading trashes a lot of internals, like C++ mangled symbols
<daurnimator>
which means you could declare like: `fn foo(kwargs: struct{bar: i32, qux: u32 = 42}) void { .... `
<Tetralux>
Indeed, `fn f(x: i32, opts: ?struct{ y: i32 = 47 })` is...... well no that's kinda terrible now that I look at it.
<Tetralux>
(Note the ?)
<samtebbs>
+1 for default values as an alternative to overloading
<samtebbs>
Codegen for it should be simple enough too
<fengb>
But default values is just another name for overloading. Unless there's something super magical you can do with function pointers to make it sane
<daurnimator>
hell I even overload in C with some regularity....
<samtebbs>
daurnimator: u wot
<Tetralux>
I use fn overloading often in any language that has it.
<daurnimator>
samtebbs: the C preprocessor is..... "fun"
<mq32>
hmm
<mq32>
i don't think default values will fit the zen of zig, sadly :(
<Tetralux>
*facepalms*
* mq32
grins
<samtebbs>
daurnimator: Oh I remember seeing a stackoverflow answer about macros with variable number of parameters :D
<samtebbs>
Looked ery "fun" indeed
<Tetralux>
Sometimes I feel like I should be a dentist.
<samtebbs>
mq32: How come?
<Tetralux>
"I feel like I'm pulling teeth, so often."
<mq32>
when having a struct with default values is available, we already have a way (although not obvious)
<fengb>
default value structs also sidesteps the function pointer problem
<mq32>
with anonymous structs this would allow "named args" and it would be useful for other stuff, too (storing arg lists and such)
<daurnimator>
samtebbs: i.e. the macro dispatches to the function for the relevant number of arguments: `myfunc(x)` is forwarded to `myfunc1(x)`; `myfunc(x,y)` is forwarded to `myfunc2(x,y)`; etc.
<fengb>
daurnimator: you can do that type of overloading with comptime too :P
<samtebbs>
mq32: But using anonymouse structs feels like it's too obfuscated to be in the same category as parameter default values
<daurnimator>
fengb: indeed. you can currently do overloading in zig with varargs. but "they'll be removed soon"
<fengb>
Oh right
<fengb>
So tuples
<daurnimator>
except that tuples don't exist yet
<mq32>
samtebbs: i don't like anoynmous structs anyways. but i try to work my way with stuff that already exists or is accepted (and i think they are accepted already)
<daurnimator>
so.... we're just left waiting to see what we get :p
<fengb>
samtebbs: we're trying to avoid polluting Zig semantics. Default values have a lot of technical challenges that you need to work around at a low level
hoppetosse has quit [Quit: Quit]
<fengb>
That may be solvable with closures / fat function pointers... but then I'm not sure how it'd interop with C
<samtebbs>
fengb: I could be understating it but surely if you have `foo(x); ... ; fn foo(x, y=2){}` then the codegen would just be (subject to abi) `push x; push 2; call foo`
<samtebbs>
I don't see where the technical challenge comes from
<fengb>
Yes, but if you want to pass it in as a function pointer, what would happen?
<fengb>
Would it be fn(x, y)? fn(x)? Are they the same pointer?
<samtebbs>
Ah, damn function pointers
<fengb>
C++ solves it by mangling the names
<fengb>
Which is hideous
<fengb>
If it's a comptime structure, that'd be fine, but we still need to codify the semantics
<samtebbs>
Make a pointer to a function with default values illegal?
<samtebbs>
BEcause it's impossible to know what the default value will be
wilsonk has quit [Ping timeout: 245 seconds]
<samtebbs>
Or if you can specify the default value in the type... `fn foo(x, y=2){}; ... ; func_pointer: fn(u32, u32=2) = ...`
<samtebbs>
No that doesn't work
<samtebbs>
Ignore that :p Only works with comptime known values
<samtebbs>
Making it illegal seems sensible and would still allow default values everywhere else
wilsonk__ has joined #zig
andersfr has joined #zig
<Tetralux>
I don't see how passing as a fn ptr changes anything.
<Tetralux>
Statically, the fn always has all it's arguments.
<Tetralux>
The compiler knows that some have defaults, and so allows you to omit them at the callsite.
<daurnimator>
the default values would need to be part of the function type
<daurnimator>
as samtebbs sayss above
<daurnimator>
samtebbs: why did you say that wouldn't work?
<daurnimator>
are you suggesting you'd have non-comptime-known default values? I don't think we'd need that
<daurnimator>
what I'm more curious about would be if we could cast from `fn(u32, u32=2)` to `fn(u32)`. And I think not,
<andersfr>
what editors/IDEs are popular among Zig users?
<Tetralux>
I'd say that you could cast it, just that the Zig compiler would need to understand that a default does need to passed, even if you don't provide on.
<Tetralux>
one*
<samtebbs>
daurnimator: Well my first interpretation of default values was that the caller would push them onto the arguments list, in which case it has to know what the default arguments are and therefore needs to know what function is being called (whereas function pointers are used when you don't know what the function is)
<Tetralux>
You could however implicitly cast fn(i32, i32=4) to fn(i32, i32).
<samtebbs>
However, if the callee puts them on the arguments list/loads them into its registers itself, then the caller doesn't need to know what function is being called and so function pointers with default values could work
<Tetralux>
Seems a promising line of enquiry.
<andersfr>
why don't you just create a struct and use it for arguments? They can have default arguments and everything is nicely named
<Tetralux>
Because you have to pass the struct.
<Tetralux>
For oe.
<Tetralux>
one*
<samtebbs>
andersfr: That sounds inefficient to me
<Tetralux>
And that's another :p
<samtebbs>
You'd have to rely on optimisation to figure out that the whole struct creation process is unnecessary
<samtebbs>
Since it can be expensive
<andersfr>
default values are also passed to the function
<daurnimator>
I don't even mind inefficiencies here
<mq32>
@callWithArgs and @ArgStruct(fnType) { } :P
<andersfr>
doesn't matter if you overwrite the defaults
<samtebbs>
And it's bad on the eye :p
<daurnimator>
the big thing about optional function arguments for me is that APIs evolve over time
<daurnimator>
you'll eventually want to add some extra 'canFoo' argument
<Tetralux>
By that logic though, you'd _always_ want to pass a struct to every fn though?
<daurnimator>
and you don't want to make a new function fooButWithCanFooArg()
<Tetralux>
Why not just make default args _have_ to be named?
<Tetralux>
How would the callee know that values were given for one or more of the default args?
<Tetralux>
And so doesn't need to provide its own defaults for them.
<Tetralux>
I guess statically?
<andersfr>
The callee needs to inspect the function definition site to know
<andersfr>
that is why many people dislike the concept
<samtebbs>
Tetralux: Ah, it wouldn't if the callee is expected to set the argument values itself (needed for func pointers) and it wouldn't have to if the caller does it (means func pointers won't work)
<Tetralux>
I'm not sure I quite understand
<Tetralux>
The callee is expected to set them to the defaults (for fn ptrs), but would not have to if the caller provided them.
<Tetralux>
That seems like a contradiction to me.
<andersfr>
The callee cannot set any of its arguments to anything
<andersfr>
it needs all of them provided
<andersfr>
default values are just syntactic sugar for the compiler filling in the arguments that weren't provided
<samtebbs>
andersfr: True, obviously it can't set its own as it would always end up overwriting what was passed
<samtebbs>
andersfr: That didn't cross my mind
<Tetralux>
You could just disallow defaults for fn ptrs.
<Tetralux>
.. but
<Tetralux>
.. still allow people to provide positional, non-default args by name.
<Tetralux>
Well, the second one you wouldn't have because of alloc(T, n)
<Tetralux>
But you get the drift.
<andersfr>
for alloc and create the memory is actually set to 0xaa and not zero due to runtime safety of undefined values
<Tetralux>
Simply put, it's an easy, ergonomic way of providing extra functionality to your procedure when adding some complicated struct instance that you have to pass instead, would not make sense.
<Tetralux>
andersfr: .. which is something that's bitten me before.
<samtebbs>
Actually the other day I was writing some C++ that would search a list and optionally filter based on a boolean argument. In most cases that boolean agument was false since that was the logical default
<Tetralux>
andersfr: The default arg would document it.
<Tetralux>
Part of the reason, is that if you're changing code rapidly, and don't yet know it's final form, I am not gonna want to rewrite enums several times.
<samtebbs>
That's the same though :p
<samtebbs>
enums and bools are the same thing in this issue
<Tetralux>
I'd rather just pass 5 thousand defaulted-bools and then refactor out later.
<mq32>
Tetralux, just introduce implicit conversions! :D
<mq32>
#badDesign
<Tetralux>
And yes, they are something of the same thing.
<Tetralux>
At least here.
<Tetralux>
DoAThing(list, stuff, .Sorted | .Zeroed | .RollbackOnFail) isn't bad... for a final API.
<fengb>
"I'd rather just pass 5 thousand defaulted-bools and then refactor out later."
<fengb>
Famous last words
<Tetralux>
I'd argue however that DoAThing(list, stuff, sort=true, zero=true, rollback=true) is easier to type, just as easy to understand, better at documenting at a glance what the options are, and easier to change rapidly.
<Tetralux>
especially if default values MUST be named-args.
<Tetralux>
(at the callsite)
<gonz_>
Those options could all just be u1s in an option struct, though.
<Tetralux>
And all parses could be streaming parsers.
<Tetralux>
parsers*
marijnfs has quit [Quit: WeeChat 2.4]
<Tetralux>
In this case, a struct would not add anything of value to this.
<Tetralux>
Except maybe memory footprint.
<Tetralux>
But it matters, even for just ONE bool.
<Tetralux>
f(stuff, true) is not as clear as f(stuff, doExtraThing=true)
<Tetralux>
Even that, is a good illustration of the problem.
<Tetralux>
If enums were as easy to infer as errors, then I'd use them instead.
<Tetralux>
But they aren't.
<andersfr>
DoAThing(list, stuff, sort=true, zero=true, rollback=true) would have a higher footprint than DoAThing(list, stuff, struct{ bool, bool, bool })
<fengb>
structs don't add memory footprint. It'd just as efficient as passing multiple args in Zig
<Tetralux>
Great, maybe the compiler could optimize to pass the defaults as one struct then xD
<andersfr>
that would contradict the calling convention
<Tetralux>
Also, would you provide none of them as f(stuff, .{}) ?
<Tetralux>
andersfr: In what way?
<andersfr>
the optimization lies in the fact that the struct is packed into a single register
<andersfr>
multiple arguments cannot be packed without changing the function signature
<Tetralux>
Devil's advocate: They _are_ defaults are after all...
<Tetralux>
Is it _that_ much of a jump to say they are passed differently?
<Tetralux>
Personally, I wouldn't bother.
<Tetralux>
Just pass them as bytes to the fn - problem solved.
<andersfr>
passing them differently means instantiating multiple versions of the same function
<Tetralux>
Yes, it takes three more bytes of memory.
<Tetralux>
andersfr: No, no. There'd be one. The one with the struct. And when you passed the defaults, they'd be put into the struct on the stack and passed.
<Tetralux>
Either way though.
<andersfr>
parameters on common architectures are passed as full registers or as word-sized stack allocations
<fengb>
I don't think Zig defines an ABI
<fengb>
structs are packed however Zig wants to atm
<Tetralux>
I'm not sure how much speed you would lose for having four bools as bytes versus a struct of them.
<fengb>
Of course, I'm excluding "extern"
<Tetralux>
But my instinct is that mine is actually faster.
<Tetralux>
Because usize.
<andersfr>
transforming the function signature is possible if and only if you have internal linkage and thus fastcall convention
<andersfr>
I don't think however anybody has written a pass for doing that
<Tetralux>
At any rate, I'd call it some unfortunate friction to have to change every usage of the fn to pass the anon struct, if I now suddenly decide to experiment with passing an extra default.
<Tetralux>
Like - I'm just gonna want to make a struct for every fn from the start.
<Tetralux>
Even if it contains no options.
<Tetralux>
_just_ so that I can add them later without breaking everything
<Tetralux>
Only to then maybe change my mind ten minutes later.
<Tetralux>
That friction is not worth it.
<Tetralux>
I didn't mention before of course, but the defaults can be integers etc.
<Tetralux>
So an enum would be enough.
<Tetralux>
would not be*
<andersfr>
using a struct for options is an efficient solution
<samtebbs>
If a struct can be passed as one register, then why can't booleans
<Tetralux>
.. which is anti-exploration.
<andersfr>
booleans can indeed
<andersfr>
they just take up an entire register for 1 bit of use
<samtebbs>
Not if you pack them
<andersfr>
structs can have multiple fields within the register width
<andersfr>
packing bools means putting them in a struct
<Tetralux>
This just sounds like an optimization.
<andersfr>
afk
<samtebbs>
Well internally yeah ;p That's not what the programmer sees though
<Tetralux>
Surely Zig could pass all default values as one struct.
<Tetralux>
In exactly the way you are describing.
<fengb>
So default values are a sugar for struct?
<companion_cube>
sounds like enums are better for readability?
<Tetralux>
They are not sugar.
<Tetralux>
It is an implentation detail and an optimization.
<Tetralux>
But one that Zig could reliably do.
<samtebbs>
companion_cube: Possibly, that would be up to the API implementer. They can choose to use default values or not
<Tetralux>
But not doing so would make it harder to explore with what the best API is.
<Tetralux>
Because you'd have to change the usage of it if you went back and forth it needing/wanting options.
<Tetralux>
With default args, that would not be the case.
<Tetralux>
AND
<Tetralux>
If they get optimized to a struct...
<Tetralux>
Then you get the same thing, but without breaking and with easier exploration.
<Tetralux>
I value my time writing code - I do not want it wasted too much by things like this. xD
<Tetralux>
(As I'm sure you all do too.)
<andersfr>
I do understand your motivation
<samtebbs>
(thumbs up in agreeance)
<samtebbs>
agreement*
<companion_cube>
what I'm curious about, personnally, is the interaction of generics and lack of RAII
<Tetralux>
Yes, Zig values reading over writing - but I'd humbly suggest that we don't be hardlined about it.
<Tetralux>
.. and a few other things too, at that.
<andersfr>
currently I'm working on the LSP project which fixes a lot that friction
<Tetralux>
And in this case especially, I'd argue that it doesn't even hurt reading code that much, if at all.
<Tetralux>
Oh?
<Tetralux>
Whatcha got?
<companion_cube>
andersfr: ♥ that sounds amazing
<andersfr>
it will provide introspection and auto completion
<andersfr>
and refactoring arguments for you
<companion_cube>
you have opportunities to do unusual things too, with Zig, andersfr
<companion_cube>
like, possibly, show comptime values on hover
<Tetralux>
So long as it's fast and doesn't stutter ;3
<Tetralux>
The very idea of using a socket rather than shared memory scares me.
<andersfr>
it is still in early stages
<Tetralux>
Just the sheer amount of speed you'd lose.
<companion_cube>
sockets are pretty fast these days
<gonz_>
18:19:51 <Tetralux> I value my time writing code - I do not want it wasted too much by things like this. xD
<gonz_>
I don't value your time writing code :D
<Tetralux>
gonz_: You don't value your time exploring the best way to write your code?
<Tetralux>
Because I do ;)
<gonz_>
Jokes aside, though, I don't really care about people's unwillingness to write code when there are clear ways to write it with already existing facilities.
<Tetralux>
Calling it "unwillingness" is misleading.
<samtebbs>
gonz_: With that attitude we'd still be writing assembly 24/7 ;)
<Tetralux>
+1
<gonz_>
If an issue amounts to "I don't want to write 10 lines instead of these 2 with a new construct" I think it should generally be tossed
<andersfr>
I think a lot of the issues arises from lack of tooling
<Tetralux>
If friction is built into a language, I'd consider it ripe for looking it.
<Tetralux>
This is my argument with C++.
<Tetralux>
.. along with a few other things.
<gonz_>
C++ has tons of niceties to turn 10 lines into 2
<companion_cube>
and with C ;)
<Tetralux>
You know the headaches of header files and having to update the signature in both places.
<Tetralux>
I would not call them niceities, personally xD
<Tetralux>
andersfr: Feature request: An easy way to type `while (cond) : (expr) {}` without having to type all the brackets.
<Tetralux>
.. in a way where I don't have to press tab every time.
* Tetralux
grins
<andersfr>
that is more of a snippet issue with your editor of choice
<Tetralux>
I thought you might say that.
<andersfr>
but it can actually be done with LSP
<Tetralux>
Snippets do not seems good enough for that.
<Tetralux>
I'd rather something better at the job.
<gonz_>
This is pretty much the exact use-case for snippets
<Tetralux>
It's also a good usecase for not having to put parens around everything. ;)
<andersfr>
the parens are actually very necessary to not make the parser impossible to implement
<Tetralux>
I use Sublime Text because it doesn't try to be that smart.
<companion_cube>
meh, what's the cost of writing a bit more {} if it saves you from ambiguity…
<Tetralux>
But typing the parens interrupts my flow of typing quite badly.
<fengb>
#define begin (
<Tetralux>
andersfr: Not true. Jai and Odin both omit them.
<Tetralux>
"Impossible" is a strong word.
<Tetralux>
Don't use it liberally ;)
<samtebbs>
A lion does not concern itself with the opinion of sheep
<samtebbs>
(the sheep being Jai/Odin)
<gonz_>
Maybe this highlights the core of what we talked about before. Small conveniences aren't worth certain changes.
<andersfr>
if you knew the amounts of hacks were required to make zig parseable with current syntax you would understand the use of strong words
<gonz_>
And maybe convenience should not be the overriding value at all.
<Tetralux>
samtebbs: My reaction to statements like that is, without exception, one of automatic caution.
<Tetralux>
Much like "impossible", funnily enough.
<companion_cube>
jsut use rust-like syntax already… :-°
<gonz_>
I've said it before and it bears repeating: It would be very good to have an actual outright statement of Zig's values, preferably ranked from most important to least.
<samtebbs>
I just wanted to use the quote
<companion_cube>
isn't there a zig zen already?
<Tetralux>
samtebbs:
* Tetralux
grins
<Tetralux>
samtebbs: A noble goal.
<gonz_>
companion_cube: There is and it has good points, but if nothing else it should be more front and center.
* samtebbs
trying to figure out if that was also a game of thrones quote
<Tetralux>
andersfr: Does that not imply that there might be an easier way to parse it?
<andersfr>
if you are willing to sacrifice speed and memory there is
* Tetralux
sniggers
<samtebbs>
In the end, conveniences and nice things like default values make Zig more attractive to the modern programmer, and our goal should be to dominate the world
<gonz_>
An actual statement that "Your convenience does not matter as much as the convenience of readers of code" would do wonders to dispel a lot of enthusiasm for over-engineered feature requests meant to only save people lines of code.
<Tetralux>
I'd like to point out, Jai parses 125,000 LOC in <20 ms.
<fengb>
Zig is not Jai
<gonz_>
Jai doesn't exist outside of 4 people's computers
<andersfr>
the language spec as written implies is only parseable with a PEG engine (which zig is not actually)
LargeEpsilon_ has joined #zig
<fengb>
I thought Zig had a PEG
<Tetralux>
fengb, gonz_: Both well-intentioned responses. But, with respect, slightly narrow minded to reality IMHO.
<andersfr>
the actual compiler is not implemented as a proper PEG
<Tetralux>
At minimum, there's much more nuance to it than that.
<fengb>
Oh
<gonz_>
Tetralux: As in too aligned with reality? Jai has an install base of 4 people.
<Tetralux>
gonz_: Not related to parsing speed though, eh?
<fengb>
We don't know what Jai is doing so saying it's faster doesn't really help
<gonz_>
There are research paper programs that have run on several times the amount of computers as Jai.
<Tetralux>
fengb: It's a basic, entire-source-in-memory, parser.
<Tetralux>
It's not streaming.
<Tetralux>
It's just scanning.
<Tetralux>
It tokenizes and then it parses the token sequence.
<Tetralux>
I know because I've watched many of the streams where he's worked on it.
<Tetralux>
I don't know what the best word for it would be.
<gonz_>
Until there is actual code to look at it just doesn't matter at all.
<fengb>
Then feel free to recreate it and submit the PR
<Tetralux>
Maybe recursive?
LargeEpsilon has quit [Ping timeout: 268 seconds]
LargeEpsilon_ has quit [Ping timeout: 245 seconds]
<Tetralux>
If I was familiar with how the structures are assembled by the parser, I might :p
<fengb>
I'm sure there's a lot of good going into Jai. But we can't borrow much based on vague video-based semantics
<Tetralux>
gonz_: I respect why you feel like that. I disagree.
<samtebbs>
It's not related to Zig but does anyone know why he hasn't open sourced it?
<companion_cube>
jai is just in the middle of the {zig…V} spectrum :p
<samtebbs>
^
<gonz_>
companion_cube: It's much more like V than that; you're being a bit too nice.
<fengb>
My guess is that Jon Blow is a game dev and does game dev based stuff
<Tetralux>
samtebbs: He doesn't want to be bogged down by other people's suggestions. As much as he'd appreciate them.
<fengb>
Like not releasing stuff until "it's done"
<companion_cube>
well, I trust Blow more for writing good actual code, than the V guy
<Tetralux>
It's important to him that his vision for the language stays true.
<Tetralux>
He also doesn't want people to start trying it and having to contend with compiler bugs.
<Tetralux>
Because that makes people just say "Oh I'll come back later when its ready"
<companion_cube>
I follow something called Lean (a proof assistant) and its 4th iteration is a bit like that: they develop it internally to not have to argue about every single little detail
<THFKA4>
i don't think the syntax is even set in stone
<companion_cube>
and it's developped by extremely good people
<Tetralux>
He wants people to be able to rely on it like C, from the start.
<samtebbs>
I see. I disagree but understand
<fengb>
Blow has some really good ideas
<fengb>
I just wish he was more open about it
kristoff_it has joined #zig
<samtebbs>
Tbf Ritchie must not have realsed C or Unix before it was "done"
<gonz_>
companion_cube: I do too, but it's safe to say he didn't know what he was getting himself in to from the beginning. You can plainly hear it in the first videos, he had no clue.
<fengb>
It's funny how some parts of Zig and Jai actually converged despite the original design differences
<Tetralux>
fengb: He is a game dev yeah.
andersfr has quit []
<fengb>
Which I kinda feel like wasted work... and I really wish we could collaborate on these topics
<Tetralux>
fengb: He answered a chat question about this once by saying that serious programmers do not have the time to be bothered with languages that aren't finished yet. And he wants the language to have a good shot.
<fengb>
That doesn't make sense
<fengb>
Serious programmers tinker in random crap all the tmie
<companion_cube>
it's very hard to develop a useful language, and I'm super impressed by andrewrk on the process for Zig
<Tetralux>
In the games industry, you release a game and if people lose interest, that's it.
<companion_cube>
it's the high road
<Tetralux>
So you have one shot.
<Tetralux>
Better make it good.
<fengb>
Yeah I agree with "game dev"
<kristoff_it>
Jonathan Blow has his own way of approaching this stuff, he's keeping it closed mainly because of that. I think it's reasonable to trust Jai more than V, that said, I've been watching a few recent streams and it seems a bit behind Zig in some aspects.
<kristoff_it>
The last stream on macros was very interesting
<samtebbs>
How long has it been in dev for?
<gonz_>
Tetralux: Many times you have a lot more shots than one, even to ridiculous degrees. The entire history of Crytek is a testament to that.
<samtebbs>
Zig has for AFAIK 3 years now
<companion_cube>
I mean, you can't trust V at all
<fengb>
Jai's been in the works for 5? years
<Tetralux>
I should note that another motivation for him is that he doesn't want it to fall victim to embrace-extend-extinguish.
<halosghost>
fengb: maybe
<halosghost>
fengb: there's no public release of it at all
<halosghost>
afaiac, until something is actually released, it's purely vaporware
<fengb>
Blow's original video is 5 years old. I dunno when he actually started real work
<fengb>
rant video*
<Tetralux>
Which is one of the ways he's answered the question of "are you gonna open source it?" -> "Yes, but maybe not immediately upon public release."
<halosghost>
yeah
<halosghost>
like I said, till it's released, I'll consider it not-a-thing
<Tetralux>
I should also note
<Tetralux>
It took his company 5 years or more to make the Witness.
<Tetralux>
Slow is his way of doing things.
<halosghost>
that doesn't bother me
<Tetralux>
And he doesn't exactly type quickly.
<kristoff_it>
halosghost: that's a safe way of looking at the issue. not always right though.
<Tetralux>
kristoff_it: +2.
<halosghost>
kristoff_it: there were rumors of an Old Navy coming to my hometown since I was born
<companion_cube>
typing quickly is overrated :D
<gonz_>
kristoff_it: For practical purposes it's exactly right. For speculative purposes it's not.
<kristoff_it>
I think the chance of Jai being a new V is very, very low
<halosghost>
it finally happened when I was 18
<halosghost>
I'll believe it when it happens
<halosghost>
I can't code against it; I cannot prototype with it; I cannot see what it's like to use for anything significant, or even trivial for that matter
<halosghost>
till I can, it's not a thing
<Tetralux>
gonz_: > many times you have more shots; Your actions will color you. So which ones you make are important. Especially the first one. Though, I do take your point.
<fengb>
I'm always impressed to hear Andrew type. He sounds like he's going 400 wpm
<gonz_>
Tetralux: The fact that Crytek is still in business is empirical proof that making garbage several times over doesn't stop you at all. It's a nice thought that "your actions will color you" but it just doesn't match reality a lot of the time.
<Tetralux>
gonz_: I mean it'll color people's perception of you. Like RAD game tools.
<gonz_>
And that's just one of the examples of game studios that would love the mythology that if you're still here, you're a success. The truth is that the games business isn't at all as hard as they'd have you believe.
<Tetralux>
Everyone knows RAD does quality stuff.
<companion_cube>
I'd also point out that several good indie games have used the open alpha model with success
<fengb>
No Man's Sky? :P
<companion_cube>
Rimworld, nuclear throne, prison architect, at least (citing those I know of)
<samtebbs>
Minecraft
<mq32>
companion_cube: Minecraft, Factorio are probably also good examples
<samtebbs>
^
<mq32>
and Wube/Factorio may be the best Example on *HOW* to behave
<kristoff_it>
I think this whole discussion is missing the point that jblow seems to be a person that has strong opinions over stuff and that doesn't like interacting with other developers as other more agreeable/extroverted people would.
<gonz_>
Tetralux: And yet people bought CryEngine for a long time and probably still do. The positive case ("These people do quality stuff, we like them") is probably true, but the negative case isn't as big a thing as people think.
<Tetralux>
Likewise ;)
<gonz_>
You can be a total loser in game development and still make it big and you can continue to be a loser and still have your studio survive.
<kristoff_it>
When you opensource something you get a ton of attention and people start opening issues etc. And then you have to reply with care. I think it's understandable, given what I can tell from his public content, that he doesn't want to go public too early, regardless of what the best strategy would be.
<companion_cube>
ah yes, factorio!!
<Tetralux>
gonz_: Indeed. I take your point. But Blow thinks the software industry is atrocious and believes he knows the many ways it can be better - so maybe it's partly a "be an example" thing - albeit by accident or not.
<halosghost>
kristoff_it: that's fine
<halosghost>
kristoff_it: but till he does, what he develops with it matters very little to my life in development
<companion_cube>
iirc he also really dislikes anything academic, right?
<Tetralux>
gonz_: I belive he wants it to be known because it was great from the start. Not because it's good _now_.
<halosghost>
since, again, there's no part of it I can leverage (unless I intend to make my own language, which I do want to do; and in that case, the production value is actually in his videos for thoughts on implementation, not any language he makes)
<gonz_>
Tetralux: Probably. I just wanted to temper the idea that game development is this harsh business that only the good/strong survive.
<gonz_>
I used to think it was the case and then I worked at Crytek
<Tetralux>
I suspect, in part, more by luck than judgment - though there is definitely some judgment you can leverage there.
<Tetralux>
How much is hard to judge.
<fengb>
I love all of Blow's ideas, but I feel like the closedness has hurt some parts of the design
<mq32>
fengb: it's nice to see that open business strategies (like open source, using common/open protocols, ...) doesn't hurt business structures
<mq32>
would love to see that more
<mq32>
software companies do it more nowadays, but hardware companies are like "i would prevent that you even know what this single pin on this chip does"
<fengb>
e.g. he went down ctors/dtors for a rather extended time before removing it. It's understandable, but also feels like the time could have been better spent
<kristoff_it>
fengb: I think so too, but the human factor is real, it could end up way worse the other way.
samtebbs has quit [Quit: leaving work, see ya]
<Tetralux>
He's trying to determine how to do things based on trying what he can think of, finding its shortcomings, and changing it to be better.
<Tetralux>
"Distilling the good parts", as it were.
<fengb>
I'm not doubting he's doing his best, but it also means treading down the beaten path
<fengb>
Maybe he can solve it in a better way
<Tetralux>
This is part of why it's so important to me that exploratative programming should be pretty easy.
<Tetralux>
fengb: Maybe you should join one of his streams and suggest your better idea then :3
<Tetralux>
If he sees what you address to him, and it's a good thought, he will take it seriously.
<Tetralux>
Someone did that just the other day with his macros demo.
<fengb>
Not talking about me
<fengb>
It also doesn't help that he kinda went into a hole for about a year so I have no idea what's going on anymore
kristoff_it has quit [Remote host closed the connection]
<Tetralux>
He's been doing bug fixes and cleanups for a year
<Tetralux>
Now he's back to adding the last two compiler features.
<Tetralux>
(One of which was macros, the other is modules-proper.)
<Tetralux>
Then presumably optimization.
<Tetralux>
Is it possible to declare the type of a struct field by switching on another field's value?
<andrewrk>
what happens when you run it with strace
<FireFox317>
I can't think of another issue than that something is wrong with the terminal
casaca has joined #zig
<bgiannan>
i'll tell you once i got it compiling again
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
hello world isn't compiling?
<bgiannan>
no it's not the hello world
<bgiannan>
i only meant i was using the same functions described in it to print on stdout
<andrewrk>
strace will probably have a story to tell
<gonz_>
bgiannan: Do you have a stray `@breakpoint()` anywhere?
<FireFox317>
You could show us the code through something like pastebin
<gonz_>
I ask mostly because zig builds with breakpoints just fine and the program will just seemingly not do anything at all when you run it.
<gonz_>
Luckily `zig build run` fails in the same scenario, but unfortunately not with any kind of indication of what's wrong.
<andrewrk>
the information is available. that message could be improved
<gonz_>
Obviously I'm suggesting this as a possible culprit for "I get no output and I'm super confused" because of previous experience, by the way. :D
<gonz_>
Sometimes it's the small things.
wootehfoot has joined #zig
FireFox317 has quit [Ping timeout: 245 seconds]
FireFox317 has joined #zig
ntgg has joined #zig
FireFox317 has quit [Ping timeout: 268 seconds]
tgschultz has quit [Read error: Connection reset by peer]
tgschultz has joined #zig
kristoff_it has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<dingenskirchen>
It works perfectly fine, but in l.11 I needed an IMO rather ugly call to @intToEnum, because just using c.CURLOPT_URL resulted in a type mismatch compile error.
<dingenskirchen>
Is that intentional or am I doing it wrong?
ntgg has quit [Ping timeout: 272 seconds]
laaron- has joined #zig
laaron has quit [Remote host closed the connection]
<andrewrk>
dingenskirchen, zig's rules about enum types are slightly stricter, not letting one implicitly cast an integer to an enum value. it makes me wonder, though, why didn't they make CURLOPT_URL an enum type in their API?
<andrewrk>
I think there is an optional warning that some compilers have that this is equivalent to.
lunamn has quit [Ping timeout: 272 seconds]
Akuli has quit [Quit: Leaving]
lunamn has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
lunamn has quit [Ping timeout: 258 seconds]
kristoff_it has joined #zig
<dingenskirchen>
m( I attempted to use CURLOPT_URL as a constant instead of the enum member CURLoption.CURLOPT_URL
<dingenskirchen>
using the latter works without any casts
<andrewrk>
I believe you would also be able to pass `.CURLOPT_URL` (an enum literal)
kristoff_it has quit [Ping timeout: 246 seconds]
<dingenskirchen>
that works too, great ^^
LargeEpsilon_ has joined #zig
ltriant has joined #zig
ntgg has joined #zig
LargeEpsilon_ has quit [Ping timeout: 248 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 244 seconds]
lunamn has joined #zig
<ntgg>
zig fmt is saying that the 1:1 in my file is an invaild byte
<ntgg>
why would this be
lunamn has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
<mikdusan>
ntgg: BOM on file?
kristoff_it has quit [Ping timeout: 248 seconds]
<ntgg>
mikdusan: I don't believe so
lunamn has joined #zig
<ntgg>
mikdusan: zig build seems to ignore whatever is causing the problem