<mq32>
yeah, zig now has automatic memory management with garbage collection </troll>
<pixelherodev>
pft
<pixelherodev>
I mean, you're not 100% wrong. I may or may not have partially implemented that in my kernel as OS-level garbage collection
<mq32>
^^
<mq32>
i remember some stuff from old bash.org
<pixelherodev>
Okay mostly joking, but I probably could do that relatively easily
<mq32>
"how do i clean up my ram?" "use: init 6"
* pixelherodev
laughs
<mq32>
well, technically correct :D
<mq32>
it frees up all memory :D
<pixelherodev>
I'd say compressed air would be more effective
<pixelherodev>
;)
<mq32>
:D
<pixelherodev>
Anyways, I'm going to clean up my OS patch and submit that now, then decide what to do with myself :P
<pixelherodev>
Major cleanup is doing stuff like `@hasDecl`ing various root.os functions and giving a more useful compiler error if it's missing
<pixelherodev>
What's the point of explicit noasync calls?
frmdstryr has joined #zig
<pixelherodev>
Hmm... question on the custom OS layer: should it work for non-freestanding OSes?
<mq32>
what is a non-freestanding OS?
<pixelherodev>
Not really any gain I can think of to doing that, but it's not like it's any harder to only check @hasDecl instead of also checking if in freestanding mode...
<pixelherodev>
Linux, Windows, etc
<Snektron>
.
ur5us_ has quit [Ping timeout: 268 seconds]
<pixelherodev>
e.g. should it be `else if freestanding then check oslayer else panic`, or `else check oslayer`
<pixelherodev>
Good example: std.debug currently uses std.heap.direct_allocator
<pixelherodev>
It might be desirable to replace that with a custom allocator in normal code
<pixelherodev>
So should the OS layer be checked always, or only when not targeting a known OS?
<mq32>
i don't see a reason to ues a custom OS layer instead of the already existing one
<pixelherodev>
Well, the most obvious is for if an official OS backend is outdated
<pixelherodev>
Or if you want to try not-yet-supported features
<pixelherodev>
Might be a good way to test features before upstreaming them
<pixelherodev>
But the point is, it's actually easier to support always, ad I can't think of any reason why it would be *bad*
<mq32>
yeah, point
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 250 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
On a similar note, DirectAllocator could easily be routed to check the OS layer for a custom implementation also...
<mikdusan>
(heads up: DirectAllocator is now PageAllocator)
<pixelherodev>
Wait what?
<pixelherodev>
I literally just pulled the source like ten minutes ago
<pixelherodev>
Accepted proposal that hasn't been implemented yet?
<mikdusan>
maybe you pulled from a fork that is behind
<pixelherodev>
I pulled from upstream...
* pixelherodev
smashes head into wall
<pixelherodev>
but it didn't check out apparently
<mikdusan>
deprecation exists if all you are using is const direct_allocator: ./lib/std/heap.zig:pub const direct_allocator = page_allocator;
<pixelherodev>
I'm not
doublex has quit [Ping timeout: 250 seconds]
reductum has quit [Quit: WeeChat 2.6]
<andrewrk>
it's just a name change, s/DirectAllocator/PageAllocator/ before merging and you won't have any conflicts
<andrewrk>
you get what I mean? one nice way to resolve conflicts is to do the upstream edit to your own branch, before merging
<andrewrk>
I think I might need to take a step back, and redesign the guts of the stage1 compiler. this result location stuff is not maintainable
<daurnimator>
andrewrk: we know that because of the 3 attempts it took
<daurnimator>
but I believe you said at the time: the complexity is *required*
<andrewrk>
there has got to be a better way to implement it though, I don't think it has to be this complex
<andrewrk>
the rules of the language are quite simple
<andrewrk>
for example, things got much simpler when I introduced Zig IR into the compiler, this has enabled lots of stuff to work while being reasonably understandable
<andrewrk>
but result location stuff is kinda hacked on on top of that. maybe if I took the time to design some kind of internal syntax, or something like that, working result locations into the design of the IR, it can be easier to understand
<andrewrk>
one of the main problems is that the rules aren't clear for how they're supposed to work internally
<andrewrk>
from the language semantics perspective it's fine, I mean like the nitty gritty details of what `skipped`, `written`, the meaning of null pointers, etc of the internal structs
<mikdusan>
working backwards, I understand that EndExpr is how each expression gets associated to a result location; but I'm not clear on what multiple ResetResult(none) does
<mikdusan>
maybe what I'll do is prepare an issue with several reduced IR dumps and ask for the broad strokes; I'd like to help with this rework
<mikdusan>
(broad strokes of status quo)
MysoftZBB has joined #zig
<MysoftZBB>
theres no downloads for binaries for windows...
<MysoftZBB>
just for wincrap64
lunamn_ has quit [Quit: leaving]
plumm has joined #zig
<plumm>
~2
<plumm>
a longshot but does anyone know what the demangler on godbolt intends to execute for zig?
<andrewrk>
mikdusan, I would welcome your fresh perspective on this, that sounds great
MysoftZBB was banned on #zig by ChanServ [*!*@unaffiliated/mysoft]
MysoftZBB was kicked from #zig by ChanServ [Banned: 2hostile4zig]
<plumm>
!log
<andrewrk>
this user had unacceptable behavior on github, so they're gone. for others wondering about 32 bit windows support, here's the issue: https://github.com/ziglang/zig/issues/537
<andrewrk>
plumm, I don't understand the question - when you say "demangler" I'm thinking of c++
<plumm>
andrewrk: i fixed the asm emit output bug for compiler explorer. this uncovers however another issue where the demangler feature doesn't work
<andrewrk>
plumm, ah, nice. can you tell me more about it? zig doesn't mangle symbols
<plumm>
trying to search around the codebase is really tiresome since a lot of fuzzy searches are dead ends and was hoping to get a lead on what it's attempting here; the demangler executable for zig is simply '.'
<plumm>
ok, if thats the case I think I can just disable the feature
<andrewrk>
yes I think that is correct
<muffindrake>
Is there a scanf equivalent in std yet?
<muffindrake>
Perhaps I simply missed it
<andrewrk>
muffindrake, I don't believe so - and such a missing feature is about to gain the spotlight on Dec 1st
<muffindrake>
I see, thank you.
<andrewrk>
muffindrake, if there were such a feature it would be a function of std.io.InStream
<pixelherodev>
If I get "invalid token: var" for sentinel in builtin.zig, I'm guessing that means I need to update the compiler too?
<pixelherodev>
On a related note, proposal: builtin.zig should be embedded into the compiler instead of part of the standard library
<pixelherodev>
It's *not* part of the standard library - not really - and it needs to match the compiler version exactly anyways
<andrewrk>
pixelherodev, I can walk you through the reasoning of why it is where it is
<pixelherodev>
Nah, if there is a reasoning I'll take your word for it
<andrewrk>
but maybe this will be enough: since it's no longer in the generated builtin code, the doc merging tool can correctly deal with it when there are built docs for multiple targets
<pixelherodev>
Wait, if that's it, wouldn't it be better to improve the doc merging tool and leave it embedded?
<andrewrk>
no matter how much the doc merging tool improves, code that is generated into different source files for different targets cannot be merged, since merging needs to observe that the AST nodes are the same file, line, column
<pixelherodev>
Unless you give it a special case in which to treat distinct files as identical
<andrewrk>
mikdusan, thanks for starting this effort, I'm probably gonna be done for today pretty soon but looking forward to working with you on this, will update that issue soon
<mikdusan>
no problem. as your time permits sir
<pixelherodev>
Is it just me or has the compiler gotten a bit faster?
<pixelherodev>
At least whenthere's an error
<pixelherodev>
Is this related to #3502? Or am I imagining this?
<andrewrk>
it's possible that 3502 had a performance impact, although that wasn't the explicit goal
<andrewrk>
maybe the interning helped
<pixelherodev>
I'd be curious about benchmarks, but don't have time to check :P
<daurnimator>
andrewrk: any suggestions on how I should check to see if Mixins bloat? I was surprised to see that mixin made the rand tests smaler
<pixelherodev>
What I can say is that when there's an error it completes in less than half of a second
<andrewrk>
daurnimator, I suggest to look at the size of the std lib tests binary
<andrewrk>
it will be interesting to see the difference between mixins branch and master branch, and debug vs release-fast will also be interesting
<andrewrk>
pixelherodev, you're probably hitting a tokenization or parse error
<pixelherodev>
Right but it notices the error faster I think
<pixelherodev>
No wait, not one of those
<pixelherodev>
`/home/noam/Documents/Development/indomitable/src/zig/std/fs/file.zig:14:15: error: container 'std.os' has no member called 'fd_t'`
<pixelherodev>
... was there a debug info rework recently?
<pixelherodev>
Because it looks like there was a debug info rework recently
<daurnimator>
pixelherodev: I moved things that operate on DwarfInfo into DwarfInfo methods. I think that's about it
<pixelherodev>
daurnimator, yeah, that's what I was noticing :)
<andrewrk>
daurnimator, do you have a streams mixin branch too?
DanielTheKitsune has joined #zig
<pixelherodev>
Also, you were right about the EAGAIN being all over the place, so I'm not sure the best way to handle this short of preventing std.event.loop from being analyzed when it's guaranteed null at comptime
<pixelherodev>
Which is very very different from the work i'm doing right now
<pixelherodev>
Different proposal: a @deprecated builtin that can be used to mark e.g. direct_allocator
<daurnimator>
andrewrk: this was just the Random changes. I guess I can see if my streams branch merges cleanly on top
<pixelherodev>
Ugh, rebuilding musl every time I upgrade Zig gets old real fast
<daurnimator>
pixelherodev: I think you need a better computer....
<daurnimator>
it takes me a couple of seconds
<andrewrk>
that process is highly parallelizable as well
<andrewrk>
btw why do you link libc? I thought your target was freestanding?
<pixelherodev>
andrewrk, it targets both static Linux and freestanding
<pixelherodev>
daurnimator, it's not my computer, it's something wrong with the build process
<qbradley>
I have been working with new evented io and the std.event.Channel. I sent a pull request for a fix to the Channel buffer wrapping logic. However, when I look at performance of a ping pong test (sending data through the channel between two task) it spends a lot of time in the Mutex in std.atomic.Queue. A lot of the other code seems to try and be
<qbradley>
lock free. I wrote my own simple channel implementation using straightforward mutex locking and suspend/resume and it is 40x faster in my test. Is it worthwhile to try and contribute that back to std library, or rather do we expect std.atomic.Queue to get faster later?
<pixelherodev>
PR opened for os layer (finally) - still needs work for a lot of use cases, but it's a start
<daurnimator>
qbradley: when did you test?
<qbradley>
I'm one commit behind master (I see one commit since I last pulled)
<qbradley>
Ha! My implementation is much slower for the factorial-channel.zig and factorial-channel-gmp.zig. I notice from top that fact-channel.zig compiled with master spikes at 500% %CPU at the start for a while then settles down to 100% for most of the time. With my changes, it is 100% the whole time.
<andrewrk>
qbradley, I suspect this is because a kernel-level mutex breaks the assumptions of evented I/O
<andrewrk>
with evented I/O, functions are split across kernel threads; rather than a mutex, code should be using std.event.Lock (which needs to be audited)
<andrewrk>
also I want to look into if it's possible to make a locking API that does the right thing in either case (mutex for blocking I/O, std.event.Lock-style protection for evented I/O)
<andrewrk>
I think it is possible
<qbradley>
I didn't use std.event.Lock because it uses std.atomic.Queue which brings the Mutex back behind the scenes again :-)
<andrewrk>
I think the real solution will come down to a better event loop implementation
<andrewrk>
perhaps thread-local jobs, work-stealing, all that traditional runtime stuff. we're essentially solving the same problem as Go, except in the std lib instead of the language
chemist69 has quit [Ping timeout: 252 seconds]
<qbradley>
Meanwhile I'll send my channel implementation into hiding unless it can do better on the factorial example :-)
<pixelherodev>
Okay, fixed a stupid that was preventing tests from passings; looks good now
<pixelherodev>
There's just one minor problem
<pixelherodev>
`zig test std/std.zig` seems to fail, because it ends up using std.os as std.os.system when std.zig is the root source file - as @import("root").os ends up == std.os
<pixelherodev>
I suppose a check for root file != std would be a simple enough fix
<pixelherodev>
That can wait for tomorrow, g'night
<daurnimator>
that took me a while to rebase my stream branch. hopefully the results are worth it :)
<adamkowalski>
andrewrk: I rewatched that video by Mike Acton that you linked me and I've been trying to learn more about data oriented design
<adamkowalski>
I am currently storing a hashmap that maps from ids to structs which contain the data that came to me from the payload (the request made by the client)
<adamkowalski>
Rather then storing pointers, structs may contain ids that can be used to look up other entries that can be useful if you need them as a data dependency
<adamkowalski>
Is this considered object oriented? What would be the data oriented alternative?
<adamkowalski>
Would I have a array which contains all my structs of a particular type? Then have some function which can map the id to an index into this array
bkleiner has quit [*.net *.split]
FSX has quit [*.net *.split]
tbodt has quit [*.net *.split]
<adamkowalski>
and the structs would not contain fields, but instead contain arraylists of fields? So now when you want to operate on a particular field you operate on every entry of that type and only load into the cache line the particular data you care about
<andrewrk>
daurnimator, your comparison seems to be missing master branch (or the stream branch?)
adamkowalski has quit [Quit: leaving]
adamkowalski has joined #zig
bkleiner has joined #zig
FSX has joined #zig
tbodt has joined #zig
benjif has joined #zig
qbradley has quit [Remote host closed the connection]
ltriant has quit [Quit: leaving]
adamkowalski has quit [Ping timeout: 250 seconds]
LargeEpsilon has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 268 seconds]
<bgiannan>
is there a way to print the stack trace without raising an error?
<mq32>
andrewrk: It's weird that it didn't occurred to me yesterday that i can just check both optionals to be not-null, then just use .? to access them both m(
<mq32>
i now feel kinda stupid
<andrewrk>
mq32, that pattern is intended
<andrewrk>
err, not the part about feeling stupid
<bgiannan>
andrewrk, fair enough
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
<andrewrk>
but it's understood that the type system can't always perfectly represent the state. sometimes you have to assert stuff at runtime (.?)
<andrewrk>
that's kinda the point of zig over rust
<bgiannan>
no idea how rust does optionals
<bgiannan>
i have to shake off some swift expectations... swift is more like ruby in the sense that it gives you a million syntax sugar to help you which is a totally different mindset than zig
<mq32>
<andrewrk> mq32, that pattern is intended
<mq32>
yeah, i thought so after seeing it
<mq32>
but now i'm looking forward on hacking onwards on the UI system
<mq32>
hat a kind of mental blocker yesterday
soulofdeveloper has joined #zig
return0e_ has joined #zig
<soulofdeveloper>
any ideas for weekend project in Zig?
<soulofdeveloper>
I'd make some microservices, but i would need small http server with support of streaming response in C
<mq32>
just write a small HTTP server in zig!
<soulofdeveloper>
i saw the video with tcp chat) It wasn't very motivating to do connection stuff using current standard library of Zig
<mq32>
why that?
<mq32>
it's the "standard" pretty much everywhere when you work with sockets
<soulofdeveloper>
i mean maturity, in live stream while developing tcp chat andrew had to fix some things in standard library, and in the end he got some very strange program lock
<mq32>
you will have those problems in all areas with zig right now
<mq32>
as i dig deeper into zig coding, i have to fix or workaround stuff on daily basis
<soulofdeveloper>
Zig works better as a language without using it's standard library i think
<mq32>
nah
<mq32>
it works much greater with zig std than C already :)
<mq32>
more *actually* useful functions
<soulofdeveloper>
idk, last time i tried i had problems even with using some container from std, something like arraylist
<mq32>
huh
<mq32>
i cannot confirm this from my experience
<soulofdeveloper>
i've created my own container library and it worked well for my webassembly purposes
<soulofdeveloper>
the language is good and the standard library is, it just needs some work and time to get to stable state
adamkowalski has joined #zig
<mq32>
you can help with that ;)
<mq32>
so zig std also fits your needs
<soulofdeveloper>
by the way i'm not against writing http server, but from what i found in standard library about tcp functions i have no idea how to use them, and also i dont know if they will change api tomorrow
<mq32>
idk the state of all socket API right now, but you can just use the POSIX api and be happy with that
<mq32>
it didn't change much in the last 40 years :D
<soulofdeveloper>
you mean the one from libc?
adamkowalski has quit [Ping timeout: 240 seconds]
<mq32>
soulofdeveloper: nah, the ones from "posix api"
<soulofdeveloper>
so listen will only work on systems with fd_t = i32
adamkowalski has joined #zig
soulofdeveloper has quit [Quit: Leaving]
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
frmdstryr has quit [Ping timeout: 276 seconds]
adamkowalski has joined #zig
soulofdeveloper has joined #zig
soulofdeveloper has quit [Client Quit]
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
soulofdeveloper has joined #zig
soulofdeveloper has quit [Quit: Leaving]
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
adamkowalski has quit [Ping timeout: 250 seconds]
LevelDrain has joined #zig
LevelDrain has left #zig ["YOU KIDDING ME?? YOU KIDDING MEEE???? (PC drinking beer) *kernel panic!*"]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 252 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
adamkowalski has joined #zig
LargeEpsilon has quit [Ping timeout: 252 seconds]
adamkowalski has quit [Ping timeout: 250 seconds]
LargeEpsilon has joined #zig
adamkowalski has joined #zig
protty has joined #zig
<protty>
soulofdeveloper: fd_t changes based on the system its running on (usize for windows, i32 for posix). It should ideally work for all since most systems implement bsd-style sockets but there doesnt seem to be windows support yet. It would be simple to add however and could work as a nice PR starting point
bjorob has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
bjorob has quit [Ping timeout: 240 seconds]
fengb has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
dtz has quit [Read error: Connection reset by peer]
Demos[m] has quit [Remote host closed the connection]
D3zmodos has quit [Remote host closed the connection]
BitPuffin has quit [Remote host closed the connection]
protty has quit [Ping timeout: 260 seconds]
LargeEpsilon has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
BitPuffin has joined #zig
dtz has joined #zig
Demos[m] has joined #zig
fengb has joined #zig
Snektron has joined #zig
D3zmodos has joined #zig
waleee-cl has joined #zig
adamkowalski has joined #zig
CatButts has joined #zig
CatButts has left #zig ["Here is my journey's end, here is my butt."]
adamkowalski has quit [Ping timeout: 268 seconds]
kapil_ has joined #zig
protty has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
return0e_ has quit []
<marler8997>
is there a plan to add the sentinel value to TypeInfo?
<marler8997>
what's the right way to convert an array pointer to a single-value pointer?
<pixelherodev>
@as ?
<marler8997>
works
<marler8997>
I'm surprised it doesn't implicitly convert
<pixelherodev>
Implicit conversion isn't something Zig eagerly embraces as I understand it
<marler8997>
it does quite a bit of implicit conversion
<marler8997>
not as much as other languages
<marler8997>
which is good
Akuli has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Quit: Lost terminal]
wootehfoot has joined #zig
lunamn has joined #zig
<pixelherodev>
What's the reasoning for depending on specific LLVM versions? Shouldn't it be possible to support older versions? Is it just not worth the effort?
<pixelherodev>
"exec is a functionality of an operating system that runs an executable file in the context of an already existing process, replacing the previous executable"
<pixelherodev>
If you do that (exec /bin/sh), it'll replace the Zig program with /bin/sh
<pixelherodev>
The idiomatic way on Linux is the same in Zig as in C AFAIK: fork/exec, not just exec
<jonathon>
ok, replacing the running executable is not really what i want to do. 😅
<andrewrk>
pixelherodev, it's stil experimental in llvm trunk
stratact has joined #zig
<stratact>
Hello Zigsters! 😄
<pixelherodev>
Right, but Gentoo supports AVR in the LLVM-10 experimental build
<protty>
stratact: ello
<stratact>
Ah, Zig improved the contributing build style by providing an option to skip copying the lib files (or previously the std files last time I contributed)
doublex_ has quit [Ping timeout: 240 seconds]
Ichorio has quit [Quit: Leaving]
doublex_ has joined #zig
<stratact>
Then again I probably need to work on another personal project to get a thought-catalyst going
clktmr has joined #zig
wootehfoot has quit [Quit: Leaving]
ky0ko has joined #zig
kapil_ has quit [Quit: Connection closed for inactivity]