<Xavi92>
Kingsquee: don't really get it either. But that might be to my current lack of expertise with the language
<karrick>
Pardon my ignorance, but what does `def bar: Bar = .A;` mean in the above linked GitHub comment?
<karrick>
The `.A` is what I don't know in Zig parlance yet.
<karrick>
(maybe the enum)
<karrick>
oh duh
<karrick>
yeah: the type is `Bar` and the value is Bar's `A`.
<Xavi92>
karrick: is one of the fields from the enum. If I'm not mistaken, the `.` must precede so it can be inferred, I guess
<karrick>
yeah makes sense. thx
<karrick>
Is there a reason to put colons in `var` and `def` statements at all?
<karrick>
`def bar Bar = .A;` vs `def bar: Bar = .A;`?
<karrick>
same with `var foo Foo = undefined;` vs `var foo: Foo = undefined;`
<karrick>
I suppose I might be treading on thin ice, because I don't have as much experience in Zig as any of you.
<Xavi92>
karrick: the example has not been compiled since it relies on syntax that has not been accepted (or even reviewed) yet, but currently Zig uses 'const/var name: type = value;'
<Kingsquee>
don't sell yourself too short
<Xavi92>
karrick: np :)
<Kingsquee>
@Xavi92: def wouldn't replace const everywhere, with pointers etc
<Xavi92>
Kingsquee: why not?
<karrick>
I never understood the purpose of having that colon in the var statements. Figured it was a parser issue.
<Kingsquee>
*def i32
<Kingsquee>
not very clear
<Xavi92>
Kingsquee: that wouldn't be needed at all. Why not just *i32?
<Kingsquee>
yes, that's my point
<Xavi92>
*i32 = status quo *const i32
<Kingsquee>
unless I missed something, you might want to edit your post to clarify you're not just proposing 'def == const'
<Xavi92>
Kingsquee: "This requires const to disappear so *Foo and []Foo are immutable by default. Otherwise, it makes it inconsistent to have const for declarations but not for forcing const-safety, so it just can't be used. "
<Xavi92>
I think that statement made that clear. Or at least I hope so
<Kingsquee>
ah, I missed something
<karrick>
Having qualified my opinions as meaningless in this arena, I do agree with Xavi92's statement about that code block example being very readable.
<Xavi92>
Kingsquee: Please do not hesitate to ask any other details. I would like the explanation to be as understandable as possible
<Xavi92>
karrick: thanks for the kind words. :)
<Xavi92>
karrick: the whole Zig community has been on a heated discussion about this for a couple of days now, but I think the `def` approach is what makes most sense now, after reading all of the other approaches
<Kingsquee>
I personally kind of like the idea of 'a <- 4' if a is var, since that gives a really nice readability of "this thing is being changed and not defined", but in the current situation I think your proposal is, in positive vibes that utf8 cannot express, most-tolerable
<karrick>
Kingsquee: I have thought of that idea as well. However, we have a problem in that we have a history of C like expressiveness to mutate variables, and we are trying to make immutability the default for declarations. So I kept my mouth shut.
<Xavi92>
Kingsquee: `a <- 4` is introducing a new operator to the language, which I'm not a fond of, as stated on my proposal. Also, people coming from C, C++ or Rust would find that strange at first glance
<Kingsquee>
I'm from all of those so ¯\_(ツ)_/¯
marijnfs_ has joined #zig
<Kingsquee>
the only reason I can see it's impractical is destructuring
<Xavi92>
Kingsquee: then think of reducing the number of operators on Zig to a minimum
<Kingsquee>
it's really not though, as what we currently have could be considered an overloaded operator
<Kingsquee>
it's just one we've gotten really used to
<Xavi92>
Kingsquee: as I stated on the proposal, destructuring should be really put into question if it's causing troubles in language design
<Kingsquee>
anything that helps me see exactly where the moving parts are is nice
<Xavi92>
Kingsquee: can't see it as a priority. There are many other ways to return multiple values from a function
<karrick>
After finishing reading Xavi92 's suggestion, it seems to bring together the best ideas from different people.
<Xavi92>
Kingsquee: be it returning a tuple, a struct or using a mutable pointer
<Xavi92>
Thanks again, karrick :)
<Kingsquee>
that said, there's really no ambiguity when the only time '=' could mean assignment is when the variable name is prefixed by 'def'
<Kingsquee>
so it works out
<karrick>
Xavi92: would you mind editing your example to include how one would define struct methods
<Xavi92>
karrick: well, didn't try to write methods on enums actually, so that might be plain wrong
<Xavi92>
karrick: but I hope everyone gets the idea behind, after all
<fengb>
they can have methods yes
<karrick>
I am not trying to a smart ass. I honestly don't know well enough whether it was possible.
<karrick>
thanks fengb
<Xavi92>
fengb: phew, then I got that right by luck :P
<Xavi92>
fengb: did you read my comments on the proposal (link above), BTW?
<fengb>
Yeah, I don’t really see how def is better than const
<Xavi92>
fengb: "This requires const to disappear so *Foo and []Foo are immutable by default. Otherwise, it makes it inconsistent to have const for declarations but not for forcing const-safety, so it just can't be used."
<karrick>
I like `def` because it implies `define`. Define this symbol to always mean thus and such.
<fengb>
Not sure hijacking a proposal for something tangentially related is that great either
<Xavi92>
fengb: removing `const` and providing sigils instead does not sound like a better idea either
<fengb>
I’m in favor of status quo
<Xavi92>
karrick: actually I don't really care that much about which keyword ends up being used. It's just `const` cannot be used for some things but not for others, so it's better to remove it
<Xavi92>
fengb: status quo favors default mutability
<karrick>
`const` never bothered me either
<fengb>
Again this isn’t the issue for that
<Xavi92>
karrick: default mutability is already an issue in C and C++, specially since we programmers are lazy and prefer fewer keystrokes over const-correctness
<karrick>
fengb: is your concern the fact that in the "drop const keyword" some discussion suggested using `def` rather than `const`?
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<fengb>
Nah it’s just switching const to def doesn’t feel like it solves andrewrk’s problems, and getting rid of const is shoving all the changes at the same time
nephele_ has joined #zig
<Xavi92>
fengb: I think Andrew also made clear he would make default immutability a thing, so I don't see how `const` fits on the language once that is implemented
nephele has quit [Ping timeout: 258 seconds]
<fengb>
I also don’t have that much weight. I just talk a lot >_>
<Xavi92>
fengb: getting rid of const is introducing new operators to the language, which IMHO translates directly to worse readability
<Xavi92>
Operators should be kept at a minimum. We prefer reading words than sigils, that's a fact
<Xavi92>
fengb: as I said on the comments, "Removing the const qualifier and making declarations solely depend on the operator will surely look confusing to newcomers, at least those coming C, C++, Rust or similar languages, which I think are the principal target for Zig."
marijnfs has joined #zig
<Xavi92>
Anyway, bed time. See ya!
Xavi92 has quit [Remote host closed the connection]
<karrick>
👋
marijnfs_ has quit [Ping timeout: 240 seconds]
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
ur5us has joined #zig
foobles has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 256 seconds]
klltkr has joined #zig
ur5us has quit [Ping timeout: 265 seconds]
<GreaseMonkey>
"error: compiler bug: integer and float literals in var args function must be casted." oh that is wonderfully honest
<GreaseMonkey>
even if i am aware that varargs are gone in trunk
<fengb>
One of the many reasons varargs was removed :P
wootehfoot has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<oats>
re: the 'const' thread bikeshedding:
<oats>
I really do not like this example in particular
<oats>
a +=, b :=, var c :=, d = someFn();
<oats>
I really hope the language doesn't end up encouraging/allowing this :P
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
<foobles>
oats I was the one who proposed that
<foobles>
and I totally agree
<foobles>
that was a bad call :p
<foobles>
mixing assignment / declaration on one like, imo, is awful
ur5us has quit [Ping timeout: 246 seconds]
<oats>
haha, I appreciate your coming forward :)
<oats>
definitely good to get all the bikeshedding out of the way now instead of in 3 years once the nuclear power plant is built and everyone is riding their bikes to work
<mikdusan>
uniform mutability and (decl or assign) for lhs: This is the Way®
<oats>
as in two forms only?
<oats>
some kind of 'const (a, b) = someFn();'
<oats>
or 'var (a, b) = someFn();'
<mikdusan>
except I don't think we need parens
<oats>
sure
<oats>
not the part I was focusing on though :)
<foobles>
I wouldn't care about parens
<foobles>
but it makes it clear that the const/def/var is distributing over all of them
<oats>
const {a, b} = someFn();
<oats>
whatever :P
<mikdusan>
and last 4 lines of this is what it would look like with `:=` for decls. I added a parens for mixed lhs.. pretty much would match what fn params parens would be. it's a receiver:
<darithorn>
it happens a lot in Go with the idiomatic way of error handling
<foobles>
yeah, but zig has better error handling
<foobles>
so I dont think this would be nearly as necessary as go
<foobles>
*as in go
<darithorn>
very true
darithorn has quit [Quit: Leaving]
<mikdusan>
I consider the tuple lineup as sugar and semantically equiv to having the tuple reference, and then `const a = tuple[0]; const b = tuple[1]; // equiv to `const a,b = tuple;`
<mikdusan>
and the normal name-collision and shadowing prevents Go shadowing footgun
klltkr has quit [Ping timeout: 258 seconds]
<GreaseMonkey>
i've now got a working deflate+gzip unpacker but the code's a bit of a mess
<GreaseMonkey>
and, well, for some definition of "unpacker" - there's a struct you can call read against but i'm not feeding the results into an actual file, plus the CRC isn't being calculated for the gzip stuff
<GreaseMonkey>
having said that, the port of Mark Adler's puff.c mentioned in the issue tracker should be fast enough if you believe the statistics in the file itself being about 1/4 of the speed of zlib (which is *still* pretty fast)
<foobles>
how is `~|CONST!#(x)|~ y;` as a replacement for `const x = y;`?
foobles has quit [Ping timeout: 240 seconds]
<GreaseMonkey>
ok, turns out my deflate implementation is using 460KB resident according to top
<GreaseMonkey>
had to check it for leaks
<GreaseMonkey>
attempting to decompress a ~512MB tarball does result in, uhh, let's say it isn't fast enough to handle that nicely
<GreaseMonkey>
-Drelease-fast maybe doubles the speed so i should probably buffer it better
<pixelherodev>
Profile!
<pixelherodev>
Callgrind, perf, etc!
StateOff has joined #zig
<StateOff>
Hi everyone. Trying the newest zig release again for Ludum Dare (gamejam). I am a little stuck and would appreciate any help.
<GreaseMonkey>
anyway, change "valye" to "value" before that bites you later... and after that, you need self to be a pointer to Data, otherwise it ends up constant
<StateOff>
So it needs to actually be a pub fn append(self: *Data, value: u8) !void { ... if it is supposed to be mutable (not self: Data).
<StateOff>
Thanks for listening. Curious to see if there will be more zig entries to LD. Good night everyone.
_whitelogger has joined #zig
dddddd has quit [Ping timeout: 250 seconds]
ifreund has joined #zig
StateOff has quit [Ping timeout: 256 seconds]
dermetfan has joined #zig
dermetfan has quit [Quit: WeeChat 2.7.1]
dermetfan has joined #zig
<GreaseMonkey>
alright, 546300976 bytes compressed, 1635216384 uncompressed. (exact file i'm testing for benchmarks is FreedomStudio-2019-08-2-lin64.tar.gz.) here's the metrics from time
<GreaseMonkey>
-Drelease-safe takes 50.879s real / 49.617s user / 0.797s sys.
<GreaseMonkey>
-Drelease-fast takes 41.643s real / 40.546s user / 0.721s sys.
<GreaseMonkey>
it does not write to disk at this point, but it does read from disk (although there's a chance it's all in cache right now)
<GreaseMonkey>
also, 116KB resident lol... and that's with a 100KB block buffer
<pixelherodev>
How's that compare to standard tools?
<pixelherodev>
In terms of compression/decompression speed
<GreaseMonkey>
oh right the resident value is kinda moot for zig as it doesn't factor in stack usage much i think
<pixelherodev>
(I'd measure locally, but it wouldn't be a valid commparison)
<pixelherodev>
s/mm/m
<GreaseMonkey>
for standard tools? yeah i'll check that
<GreaseMonkey>
gunzip into /dev/null: real 8.989s / user 8.770s / sys 0.157s
<GreaseMonkey>
long story short, it's Fast Enough™. there's still room for improvement though
<GreaseMonkey>
also, 906 lines across 8 files
<GreaseMonkey>
but not particularly well commented... OTOH, there's a blatant copypaste
Xavi92 has joined #zig
<Xavi92>
Hi there :)
<pixelherodev>
How long does yours take for just decompress?
<GreaseMonkey>
i don't have compress at this stage
<GreaseMonkey>
i will say though, if we're making packages the size of a heavily customised Eclipse w/ all the embedded toolkit stuff bundled (typically GCC, GDB and the whatever-Link tools), then something is probably wrong
<GreaseMonkey>
at this stage anyway
<ifreund>
i think any working implementation is a step up over none
<pixelherodev>
for sure
<ifreund>
speed can certainly be improved in the future
<pixelherodev>
I was simply curious
<ifreund>
yeah me too
<pixelherodev>
Speaking of improving performance
<pixelherodev>
I've committed unholy devilry :)
<pixelherodev>
`mmap`
<pixelherodev>
Mapped virtual memory directly to physical memory (w/ an offset for some of it since the zero page is off limits :( )
<pixelherodev>
Have a few restructures to boost performance as well
<pixelherodev>
and the urge to hit myself for wasting time on this when it already runs in <5ms
<pixelherodev>
Yay, ~15% faster now! That was totally worth the effort. Not.
<GreaseMonkey>
i used mmap for some C code which i wrote to stabilise the Perfect Dark Attack Ship Agent 2:06 WR video, it was *really* nice to be able to do the per-frame stuff in a way that was disk-backed so i could leave it and come back to it
<GreaseMonkey>
mmap is a sorely underrated facility
<pixelherodev>
On the bright side, the performance hit of being unable to use the zero page is only ~2.5%
<pixelherodev>
(based on enabling access temporarily and measuring instruction count via callgrind)
<pixelherodev>
Actually, that's completely inaccurate, and I have no way of measuring it; the stdlib fails because the returned pointer is null
* pixelherodev
facepalms
<pixelherodev>
The `mmap` syscall is returning a null pointer, Zig is trying to store it to a non-allowzero pointer
<pixelherodev>
I was really measuring cost of running vs cost of print a stack trace, which is a completely useless metric
<pixelherodev>
(stack trace w/o debug info)
Xavi92 has quit [Ping timeout: 264 seconds]
Kingsquee has quit [Quit: Konversation terminated!]
dermetfan has quit [Ping timeout: 246 seconds]
<daurnimator>
GreaseMonkey: is your deflate implementation uploaded anywhere?
Xavi92 has joined #zig
nephele_ is now known as nephele
<GreaseMonkey>
daurnimator: currently not, i can sort that uhh
<GreaseMonkey>
oh right, MIT licence, yeah let's do that
<GreaseMonkey>
also i personally prefer snake case over camel case any day of the week, but it does seem that the standard library uses camel case
<GreaseMonkey>
nevertheless, there are a few places where snake case has slipped in
<GreaseMonkey>
...should've clarified it's for 0.5.0
<GreaseMonkey>
although the 0.6.0 linux binary from the site Just Works™ so i might go and port it to that
TheLemonMan has joined #zig
<ifreund>
GreaseMonkey: I used to be a snake_case everywhere man myself, but I've grown to quite like the conventions of snake_case for variables, camelCase for functions, TitleCast for types, etc. that zig uses
<ifreund>
makes code more readable imo
<GreaseMonkey>
i've seen camel case be the cause of bugs
<GreaseMonkey>
and is it GZipReader or GzipReader?
<GreaseMonkey>
stuff like that
<ifreund>
i feel like if they both exist that's a problem
<TheLemonMan>
pixelherodev, you forgot to update the stack-trace tests too
<Xavi92>
daurnimator: it depends on the keyboard layout I guess. On QWERTY, `def` are three keys that are very close between them
<daurnimator>
'def' => all on the left hand; annoying. 'let' => starts on the right hard, doesn't feel right. 'const' => starts on the left and has nice see-saw from left-right-left
<Xavi92>
daurnimator: I don't see that as a convincing argument nonetheless
<daurnimator>
yeah its probably just a me thing
<Xavi92>
ifreund: whereas I like `const` too, I already explained why it doesn't fit if default immutability is achieved
<ikskuh>
daurnimator, Xavi92: I wrote some stupid stuff about the typeability of `let` vs `const` vs others in the `let` issue :D
<ifreund>
Xavi92: i've honestly had my fill of bikeshedding for a bit
<ikskuh>
Xavi92: i think for declarations, there should be no "default", the coder should always chose
<GreaseMonkey>
daurnimator: stdlib CRC is nice and fast, thanks for the suggestion, commiting and pushing now
<ikskuh>
but pointers should be immutable by default
<GreaseMonkey>
i do also believe in "immutable by default", it's safer
<Xavi92>
ikskuh: I agree. Default declarations seem to force new operators
antaoiseach has joined #zig
<GreaseMonkey>
...hmm, actually, yeah, requiring one to say "this is mutable" or "this is immutable" but not leaving it ambiguous does kinda appeal
<GreaseMonkey>
OTOH there is also the extreme of "what if we made sure everything was explicit", which is... well, has anyone here ever tried Vulkan?
<Xavi92>
GreaseMonkey: any modern systems language such as Zig should be safe-by-design, rather than what C already does
<Xavi92>
GreaseMonkey: so I agree completely with default immutability
<Xavi92>
GreaseMonkey: I already proposed that on #5056 but soon got rejected by andrewrk
<Xavi92>
GreaseMonkey: in fact I prefer default immutability (which I pointed out clearly on #5056), nonetheless
<Xavi92>
BTW, https://github.com/XaviDCR92/zig/tree/issue_5076 still not compiles. If anyone could help me out with this, I'd be very grateful, and it will be possible to show what I intended using real working examples
<Xavi92>
Still, new function declaration syntax is not implemented `def foo = fn() void {}`, but I intend to add this feature on that fork too
<Xavi92>
Again, if anyone contributes to that branch, I'll be very glad
wootehfoot has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
<FireFox317>
TheLemonMan, what are you using the Once object for? Just curious where it can be applied
<mikdusan>
anything lazy. singleton patterns.
<FireFox317>
I see, nice
mattmurr has quit [Ping timeout: 265 seconds]
mattmurr has joined #zig
mattmurr has quit [Ping timeout: 252 seconds]
mattmurr has joined #zig
decentpenguin has joined #zig
antaoiseach has quit [Quit: Lost terminal]
<TheLemonMan>
FireFox317, yeah I needed it to create singletons without having to worry about data races
<TheLemonMan>
it's also useful for shared libraries when you cannot run your own init code
rappet has quit [Quit: No Ping reply in 180 seconds.]
rappet has joined #zig
sanaris has joined #zig
<daurnimator>
TheLemonMan: "unless the test block in once.zig is analyzed." => like with meta.refAllDecls?
dermetfan has joined #zig
dimenus has quit [Remote host closed the connection]
<TheLemonMan>
daurnimator, that shouldn't reference the tests blocks
<karrick>
I have been anxiously following the Async work in Zig for some time, wondering how Zig will handle concurrency without a scheduler. I read the section in the 0.6.0 release notes regarding the efforts, and have to comment, because I noticed something when designing concurrent algorithms in Go using atomic primitives. https://github.com/karrick/gosync#fundamental-requirements-for-synchronizing-concurrent-algorithms
<karrick>
I realize the above link is about Go concurrency, but the bottom line is algorithms need to be able to signal when they are runnable or not.
<karrick>
I was watching andrewrk do a live coding demo with async work a number of months ago, and I got the impression that at syscall boundaries for slow calls, Zig compiler was introducing some modicum of logic to detect whether new threads were threads were runnable.
<karrick>
There must be a way for threads to communicate to the scheduler, in the OS since Zig does not schedule threads, whether that thread is eligible.
<ikskuh>
karrick: yes, there are syscalls to query FDs on their readyness
<ikskuh>
it uses a scheduler that is implemented somewhere in zig std
<ikskuh>
look at the man page for poll or epoll
<karrick>
That must be where I saw andrewrk working on in his demo
<ikskuh>
please note that zig async works completly different compared to go for example
xackus_ has joined #zig
<ikskuh>
go uses user-space threads with a custom scheduler whereas zig uses more of a continuation style
<ikskuh>
where you can suspend routines into a "frame"
xackus has joined #zig
xackus__ has quit [Ping timeout: 265 seconds]
xackus_ has quit [Ping timeout: 256 seconds]
foobles has joined #zig
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
<karrick>
ikskuh: thanks for the links. I know it works completely differently, because it eschews a runtime and scheduler, and have been wondering how it will accomplish proper concurrency without a scheduler. Accordingly, some feedback method needs to be provided that allows a thread of execution, or not thread, to say when something makes sense to run. Sort of like condition variables. "I'm going to sleep. Wake me up when..."
<ikskuh>
zig async _has_ a scheduler
<ikskuh>
but not a thread scheduler
<ikskuh>
when a function awaits something, it suspends and returns to the caller
<karrick>
Okay, then it's making sense. I suppose Zig is designed to also run without an OS.
<ikskuh>
yes
<ikskuh>
suspending means: storing its state in a frame somewhere and you can resume that frame later
<ifreund>
yep, and also to give you absolute control if you want it
<ikskuh>
^= this
<karrick>
So Zig cannot defer to the OS to make those scheduling decisions.
<ifreund>
sure
<ifreund>
i'm fairly certain you can implement thread-based async in zig
<ikskuh>
zig async is actually multithreaded by-default
<ikskuh>
but you can utilize each thread for more than one async task at a time
<ifreund>
what i mean is that you could implement whatever go is doing in zig theoretically
<ikskuh>
not sure
<ikskuh>
but probably yes, you can implement coroutines in zig
<ikskuh>
but needs some assembler
<karrick>
I need to do some reading about how the event loop is evolving...
StateOff has joined #zig
marijnfs has joined #zig
<fengb>
Async isn’t scheduled. The event loop is scheduled of sorts but the async stuff is actually synchronous under the hood
<fengb>
e.g. resume “freezes” current execution and hands back control to the previously suspended frame
<fengb>
For event IO, it’s similar to how nodejs does it. Any IO tosses the suspended frame to the event loop manager, and schedules a callback with the native OS kqueue/epoll/uring to wake it back up
<karrick>
^ that summary is much appreciated
<fengb>
And I’d imagine the event loop is pretty dumb and just runs whatever is woken back up
<ikskuh>
Xavi92: "def cmd_a = CmdHandler {" definitly a bad idea
<karrick>
kind of like condition variables might
<fengb>
But... you don’t need the builtin loop to use language async. It’ll just be a bit more raw
<ikskuh>
has a really low readability, hides several declarations
z0ltan has joined #zig
z0ltan is now known as antaoiseach
dermetfan has quit [Ping timeout: 246 seconds]
<fengb>
karrick: just to be a pain, you can have comptime var that stores structs and/or functions
<fengb>
I don’t know why you’d do that but it’s possible
dermetfan has joined #zig
<karrick>
I was pondering that possibility and could come up with no practical reason to support it. Unless you wanted to be able to support functions modifying themselves, like in Lisp.
<ikskuh>
well, in zig functions and function pointers are synonymous
<ikskuh>
so having a function pointer is also just "var x : fn()void"
<karrick>
I expected as much. But when you bind a function declaration to a symbol, do you expect to rebind it later? Sometimes yes. Event loops and higher order functions use that all the time.
<fengb>
In comptime yes you can do self modification
<ikskuh>
fengb: with #1717 you can do that for all functions
<karrick>
But when bound at the top level, usually you are making a constant declaration, and do not intend on rebinding a function name to a different function body later.
<ikskuh>
var foo = fn() void { std.debug.warn("I'm gone…\n", .{}); foo = fn() void { std.debug.warn("this is you future now\n", .{}); }; };
<fengb>
Zig used to have your syntax idea. It was changed and you can probably find the old issue
<karrick>
There is a difference between re-binding a pointer to a function pre-compiled function body, and building new functions at run time.
<ikskuh>
we need zig fmt for the irc chan
<ikskuh>
karrick: true. zig will never have the second one except you thunk that
<fengb>
I prefer const foo = since you can easily grep for a declaration
<karrick>
ikskuh: that example makes sense
<fengb>
@ikskuh: Oh that’d make sense in a body yes
<ikskuh>
fengb: yeah, that is my argumentation as well. you can grep pretty easily
<ikskuh>
fengb: it would also make sense on top-level to do stuff like "init on first call"
<ikskuh>
and you can just call "init_once()" all the time
<ikskuh>
and after the first call, it will just be a ret
<karrick>
fengb: I agree. And while when I first started to read Zig code thought it bizarre to see `const` keyword preface struct declarations, I find it really easy to read.
<karrick>
I have done exactly that in some Go and JavaScript code, ikskuh ...
<karrick>
I have had multi-stage inits for some things... hold on. ugly example link coming up
<fengb>
Change is hard. I also wanted C style declarations a year ago
<ikskuh>
fengb: yeah, true. but i don't think the stuff proposed in "the issue" is worth the change
<fengb>
I have no idea what’s going on there. We apparently decided it’s a dumping ground for all the changes
<karrick>
That silly code modified a field member pointing to a function 3 times.
<fengb>
And most of them don’t solve andrewrk’s issues in the first post
<ikskuh>
fengb, yeah, true
<mikdusan>
heh #5076 (drop const keyword) is now tied for zig all-time most comments in issues; tied with #544 (hard tabs)
<karrick>
It's a complex topic being discussed, with different scenarios being considered.
<ikskuh>
i'm still happy that there are a lot of people who think "status quo + #1717" is totally okay
<ifreund>
the 2 tallest bikeskyscrapers in zig history
<fengb>
I don’t disagree that it’s complex, but we’re also shoving in random stuff that’s pretty irrelevant
<BaroqueLarouche>
const main = fn will be weird at first, but more consistent with the idea that (almost) everything is an expression
<ifreund>
Yeah i'm totally happy with the status quo optinon personally, but also rather tired of the discussion
<companion_cube>
this is why you need a dictator, like andrewrk :)
<karrick>
agreed
<ifreund>
exactly, i just want andrew to lay down the law
<BaroqueLarouche>
Judge Dredd Andrew
<fengb>
I expressed my viewpoints already so I don’t have much to add. Whatever decision he makes, I’ll be happy it’s done lol
<karrick>
Maybe I'm wrong, but while it is a proposal to do X, and whose intention is to solicit discussion on the PROS and CONS of X, does that not allow for Y and Z to be discussed, if they are related to X?
<fengb>
I don’t think it’s disallowed per se, but I also don’t see most of the posts addressing anything close to the original point
<karrick>
I am completely cool with benevolent dictator / enlightened monarch approach as well. But it sounds like andrewrk is asking for different ideas so he can make an informed decision from the community of users.
<karrick>
in the end, I'm still a fan of Zig and wish I could carve out more time to learn and use it
<fengb>
andrewrk wants to drop const to make it easier to assign stuff. That part has been missing in half the discussions
<ikskuh>
it was dropped in favour of more flexibility and more consistent declaration syntax
<karrick>
✅
<ikskuh>
how do you declare an anonymous struct with that? ;)
<ikskuh>
you know that you can do that:
<fengb>
andrewrk amended the proposal to include all const declarations, including inside functions
<ikskuh>
var foo : struct { i : i32 } = .{ .i = 10 };
<ikskuh>
?
<fengb>
And then the flood doors opened to make all the syntax changes
<karrick>
I don't have any good reasons to oppose whatever is decided upon.
<fengb>
I don’t see most of the discussions close to solving his problems though
<karrick>
Have you had any thoughts about how to resolve his concerns?
<fengb>
Not really. SpexGuy had a good summary that I mostly agreed with. And the ones in consideration don’t have the problems I initially feared
<fengb>
So... I’m just here bikeshedding about bikeshedding and hoping this gets resolved before we destroy ourselves >_>
<karrick>
I actually don't think there is any solution that will make everyone happy, because we are jamming immutable and mutable language together.
<fengb>
I don’t even know why that topic came up
<karrick>
why what topic?
<fengb>
Nowhere is a part of the original proposal
<karrick>
what
<fengb>
Default immutability
<ikskuh>
karrick, zig is never gonna be a immutable language
<karrick>
I'm not saying it would or should be
<fengb>
That wasn’t the intent of the original proposal
<karrick>
yeah, I just rescanned the proposal and did not see it there.
<fengb>
And while I like default immutability, I’m really annoyed that it’s all we’re talking about here
<ifreund>
^
<mikdusan>
my take on this; the uniform-multi-assign is pretty much agnostic to { const, `=`, `:=` } possibilities. and the `=` option has the consequence of a new keyword like `set` or `reset` for assign
waleee-cl has joined #zig
<companion_cube>
zig secretly becomes tcl
<ifreund>
after reading SpexGuy's comments I don't think there's much more to say
<ikskuh>
mikdusan: why do we need destructuring in the first place?
<karrick>
Isn't dropping `const` imply a "default immutable" stance, however?
<companion_cube>
to use tuples as multiple return ikskuh
<companion_cube>
{x,y} = f()
<karrick>
Right now the mutability or immutability is pretty explicit: `var` or `const`.
<ikskuh>
companion_cube: i know that this is the use of this
<ikskuh>
but why do we need this?
<mikdusan>
ikskuh: i believe it's an accepted proposal #498
<companion_cube>
ah, idk
<companion_cube>
although it is indeed convenient to return multiple values somehow
<ikskuh>
mikdusan: damn :D
<companion_cube>
instead of C's ugly "return one value and modify argument pointers for the other return values"
<ikskuh>
C++ got destructuring as well
<ikskuh>
and it's horror
<ikskuh>
companion_cube: we have anonymous structs
<foobles>
`auto[x, y] = foo();` :)
<companion_cube>
ikskuh: but without destructuring it's annoying
<ikskuh>
nah, because your returns are named
<ikskuh>
readability++
<mikdusan>
> "C++ got destructuring as well and it's horror" --> "C++ it's horror" ; there I simplified it.
<ikskuh>
foobles: that works for a LOT of stuff. like … arrays, structs, tuple, …
<fengb>
JS has destructuring and I find it far more abused than useful
daex has quit [Ping timeout: 264 seconds]
daex_ has joined #zig
<ikskuh>
mikdusan: we try to cramp even more features into destructuring than c++ or c#
<ikskuh>
like, reassigning values mixed with declarations and so on
<ikskuh>
this screams for abuse
<ikskuh>
it's easier to type
<companion_cube>
go also does that a bit with their `x, err := …` right?
<ikskuh>
but definitly not easier to maintain
<mikdusan>
i guess my point is this: by making destructuring uniform (ie: no mixing), it's not going to matter which way const goes
<foobles>
I think destructuring should only be allowed for declarations
<companion_cube>
yeah I don't see why one would reassign in a destructuring either
<companion_cube>
it's… unheard of :p
<ikskuh>
foobles: +1
<ikskuh>
and then we can just use "const { a, b } = foo();"
<ikskuh>
which is at least semi-readable
<companion_cube>
`let {a, mut b} = foo();`
<companion_cube>
oops :-°
<ikskuh>
but will eventually yield hard-to-find bugs
<companion_cube>
why so?
<ikskuh>
because you may want to return a complexer type in the future
<ikskuh>
like, having an additional info in the return type
<companion_cube>
ikskuh: there's a trivial solution to that
<ikskuh>
now everything that depends on that will break
<companion_cube>
fail if you don't bind all the fields
<foobles>
what about destructing more complicated struct? `const { a = .x, b = .y } = foo();` if foo returns a struct with x and y?
<companion_cube>
(cause it's a bug to ignore a return value)
<mikdusan>
I would expect destructuring to support `_` in positions
<mikdusan>
but I don't know if that's been talked about
<companion_cube>
mikdusan: that seems obvious
<ikskuh>
what is allowed to be destructured?
<ikskuh>
only tuples?
<ikskuh>
or structs and arrays as well?
marijnfs has quit [Quit: leaving]
marijnfs_ has quit [Quit: leaving]
<mikdusan>
ikskuh: so far I've only seen destructuring wrt. initialization lists (tuples). so sounds like no for structs/unions/arrays
<companion_cube>
(and that's where I'm going to wish for pattern matching)
<Xavi92>
zig's std lib won't compile yet, but I'm getting closer. I'd be very grateful if anyone helped me out with this
<Xavi92>
fengb: "I don’t even know why that topic came up" "Default immutability" -> andrewrk suggested removing `const` would make things easier to provide default immutability on a later stage. That's the relation between both topics
<Xavi92>
fengb: As I've already explained on #5076, `const` loses sense if default immutability is provided, but I don't agree with the idea of `a = b` as a declaration. That'd be a big step backwards in terms of readability IMHO
<karrick>
I think the "default immutability" aspect arose because the desire to remove the requirement for `const` from global declarations evoked some negative feedback about the resulting asymmetry between global and function level `const` declarations. Some people wanted to ensure both were the same to allow code to easily moved back and forth.
<Xavi92>
Whatever andrewrk finally decides, I hope he has readability and safety as main priorities
<Xavi92>
karrick: #5076 came right after #5056 was closed down, and since #5056 was aiming for default mutability, I see the relation between both proposals
<Xavi92>
ikskuh: "def cmd_a = CmdHandler {" definitly a bad idea" -> I don't see why. After all, status quo has as `const name = definition` syntax for structs and enums, so I think it could work for functions too. It also avoids repeated code in the case of handlers, which is quite common in C
decentpenguin has quit [Quit: decentpenguin]
<ikskuh>
Xavi92, tell me all declarations in this code:
<ikskuh>
and please explain why your variant is superior
<ikskuh>
i can't see why it should be
<Xavi92>
ikskuh: imagine you have N functions with that very same signature, and any change in the signature requires changing all of those N functions
<ikskuh>
yes
<ikskuh>
favour reading code over writing
<ikskuh>
i don't care if i have to do that
<ifreund>
^^^
<fengb>
Where are the variables?
<ikskuh>
i am happy if i return back to the code 2 years later and don't have to look up every teeny tiny bit of declaration
<ikskuh>
i used to do a lot of macro stuff in C/C++
<Xavi92>
ikskuh: if N functions are declared with the same signature, it might not be so clear the relation between them. `MyCallback` provides an interface to that
<ikskuh>
now i went on to generating code
<ifreund>
Xavi92: that's a job for a namespace + comments imo
<ikskuh>
Xavi92: so? I can surely match patterns
antaoiseach has quit [Quit: leaving]
<ikskuh>
and what ifreund says
<ifreund>
and good variable names
<pixelherodev>
Refactoring is freaking trivial with a good editor
<ifreund>
^
<ikskuh>
i'm a lazy fuck, but i have learned that sometimes typing more is the long term solution to being lazy
* ikskuh
has learnt power of multi-line-editing in VS Code and is now 15% more effective in doing stupid stuff
<Xavi92>
Anyway, I just suggested that syntax **could** be used.
<pixelherodev>
ikskuh, I've learnt that power in Kakoune :)
<Xavi92>
I'm not defending it either. I already know the cons behind it
<ifreund>
ikskuh: join pixelherodev and I over in kakoune land to learn the true power
<Xavi92>
My efforts are concentrated on having default immutability and avoid the crazy idea of introducing new keywords because some people don't like typing between 3 and 5 characters
<frett27>
hello, i hardly try to make iotmonitor project compile on rpi (https://github.com/frett27/iotmonitor), thank's to bootstrap and precompiled zig binary, i could compile a hello world on the arm, but when adding the -lc flag (adding the libc), it fails with illegal instruction or core dump
<ikskuh>
frett27, do you use any C code in your project?
<ikskuh>
or only zig code with libc linked?
<frett27>
yes,
<frett27>
i tried with : zig build-exe -target hello.zig -lc
<nycex>
when i run the std tests, can i specify to only run e.g. the tests for std.fs?
<ikskuh>
you can havea a test filter
dermetfan has joined #zig
<nycex>
what do i specify there? i tried to specify the a part of and the full name of the test and also the path of the file the test is in, but it both didn't work
<TheLemonMan>
meowray, the patch process with phabricator has been nothing but frustrating for me heh
<TheLemonMan>
meowray, hm that's the only non-pdf opcode listing I've found, the same notice can be found on other ppc manuals
foobles has quit [Remote host closed the connection]
<shakesoda>
does zig std have any of whatever that data structure is called where you have a linked list of fixed size arrays, instead of one big one you grow
<shakesoda>
it's easy enough to just make one, just wondering if there's already one
omglasers2 has quit [Read error: Connection reset by peer]
<ikskuh>
a new small library on the sky of zig packages!
<BaroqueLarouche>
Nice!
Akuli has quit [Quit: Leaving]
nephele_ is now known as nephele
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<Xavi92>
ifreund: so will default immutability be finally implemented?
<Xavi92>
I can't believe a proposal with +70 comments finally resulted in status quo
<ikskuh>
Xavi92: why that? it's totally legit and there was no conensus about how it should change
<Xavi92>
ikskuh: wrt default immutability I mean
<Xavi92>
In fact, even if I suggested replacing `const` for something else for consistency reasons, I could live with it. Default immutability is a more important issue though
<ikskuh>
i don't think it's that important
<ikskuh>
depending on what andrews plans are on close(),deint() and so on
<ikskuh>
we will have way less `const` things in idiomatic zig codes
<ifreund>
don't forget that having `var` things that could be `const` will become a compiler error, that proposal is accepted
<ikskuh>
yeah, i wonder how that will turn out
<oats>
\[T]/ praise status quo
Cogitri has quit [Quit: killed]
<oats>
I hope this sets a precedent of being reluctant to make large, sweeping changes to syntax unless a really big issue shows up
<karrick>
Cool: "don't forget that having `var` things that could be `const` will become a compiler error, that proposal is accepted"
Cogitri has joined #zig
<oats>
ifreund: as in, if you declare something as var, but don't actually mutate it, the compiler will yell at you?
<oats>
rust does something similar, but I don't remember if it's a warning or an error
<ifreund>
it's warning
<ifreund>
zig doesn't have warnings though :D
<oats>
shit, really?!
<karrick>
I wonder if this is something that `zig fmt` could fix...
<oats>
that's kinda cool
<oats>
I need to write more zig
<oats>
stuff like that slipping under my radar
<Xavi92>
ikskuh: didn't know that proposal got accepted. That turns it around
<Xavi92>
Now I can sleep at nights :)
<torque>
man, I'm kind of glad for that wild ride, as it helped me realize I definitely care enough about zig to throw my hat in the ring
<Xavi92>
Overall, I'm happy with the decisions made: #224 and #1717 are accepted, which are a step forward in safety and readability, respectively. Can't wait to see these features implemented
<ifreund>
yeah i'm quite happy with the direction zig is going
<ifreund>
i think that issue was good to get some pent up bikeshedding out of everyone's systems
<Xavi92>
Congratulations to the community, and specially andrewrk, for what I think is driving Zig into the valid direction
<oats>
torque: thanks for your input, I enjoyed your first comment :)
<Xavi92>
ifreund: gotta admit so much bikeshedding was exhausting, tough lol
<oats>
I was feeling almost exactly the same and thought about weighing in before I saw yours
<oats>
so we have settled on white for the color of the bikeshed :P
<marijnfs>
I have some strange issue where I spawn a thread and pass a context, but the context is corrupted when it reaches the function
dermetfan has quit [Ping timeout: 252 seconds]
<marijnfs>
is there an issue allocating a buffer in a main thread, and then using it in a spawned thread?
<mikdusan>
andrewrk: it seems we build musl when -target *-*-musl; so this I think is borking alpinelinux host. `zig cc` seems to always build musl.a
<mikdusan>
by always I mean use it. the cache is working fine.
<meowray>
TheLemonMan: We should use Power ISA Version 3.0B for reference, not AIX stuff
<mikdusan>
marijnfs: do you have a code reduction?
<marijnfs>
mikdusan: i'm trying to make one, it seems hard to reproduce atm
<mikdusan>
is your context storage stack or heap?
frett27 has quit [Ping timeout: 256 seconds]
<marijnfs>
mikdusan: heap, it a pointer
<mikdusan>
ok; just make sure by the time thread finishes, that memory is still valid
<GreaseMonkey>
ok, had a go at porting my deflate decompressor to use BitInStream and... i'm surprised as to how slow it is
<GreaseMonkey>
using a 1KB buffer gives me a 10x speed improvement over doing reads a byte at a time for my own implementation so i'll try shoving in a BufferedInStream
opidopiopi has quit [Remote host closed the connection]