<andrewrk>
only 2 commits of data in there so far, but it's now set up to add data points with master branch commits
stripedpajamas has joined #zig
slice has quit [Quit: zzz]
jmiven has quit [Quit: bye]
<foobles>
aha! some of the blocks are not being rendered, causing the phi instruction's incoming values to not have llvm_values
jmiven has joined #zig
slice has joined #zig
wozeparrot has quit [Ping timeout: 264 seconds]
xackus has joined #zig
xackus has quit [Ping timeout: 265 seconds]
slice has quit [Quit: zzz]
<pixelherodev>
Is there a YAML lib yet?
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dddddd has quit [Ping timeout: 264 seconds]
aerona has quit [Quit: Leaving]
stripedpajamas has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
foobles has quit [Ping timeout: 245 seconds]
<andrewrk>
pixelherodev, yeah, it's only 1 line in zig
<andrewrk>
@compileError("pick a better serialization format");
<andrewrk>
j/k
slice has joined #zig
<andrewrk>
I don't think there is one yet
<pmwhite>
Lol, true. Same for JSON though.
<pmwhite>
Sexps are the way to go.
<pixelherodev>
:P
<andrewrk>
btw pixelherodev I'm back to hooking up functions in self-hosted
<pixelherodev>
Nice :)
<pixelherodev>
I"m just about done with a simplistic register allocator
<andrewrk>
what's this interval thing you're working on? just curious, it seems interesting
<pixelherodev>
Maybe ten more minutes of work
<andrewrk>
oh it's a register allocator?
ur5us has quit [Ping timeout: 260 seconds]
<pixelherodev>
A live interval register allocator
<pixelherodev>
based on the Linear Scan Register Allocation paper from poletto et al 98
<pixelherodev>
s/al/al circa
<andrewrk>
live? does that mean JIT?
<pixelherodev>
It *can* be
<pixelherodev>
In this case it is
<pixelherodev>
but it doesn't have to be
<pixelherodev>
live != JIT
<pixelherodev>
Live interval == the interval in the IR in which a variable is alive
<pixelherodev>
That is, the first use to the last
<andrewrk>
oh I see
<andrewrk>
this sounds like it might be relevant to stage2 pretty soon
<pixelherodev>
It's marginally less efficient than graph coloring
<pixelherodev>
But it's *significantly* faster
<pixelherodev>
So for a JIT, it's the optimal path IMO
<pixelherodev>
For incremental compiling too, I daresay ;)
<pixelherodev>
Do we have regalloc in stage2 yet?
<andrewrk>
no
<pixelherodev>
If not, I can work on adding it later :)
<pixelherodev>
Now that I have a better idea of what I'm doing
<andrewrk>
one thing I plan to try is to not doing any register allocation - if it's fast enough at runtime to use stack memory and it saves compilation perf, then that seems worth it
<andrewrk>
but I'll be sure to measure it and make a judgement call on that tradeoff
<pixelherodev>
This should be fast enough to outperform that easily
<pixelherodev>
Compile time overhead is near zero, and runtime boost is massive
<pixelherodev>
But I definitely support measuring
<andrewrk>
ok that definitely sounds worth :)
<pixelherodev>
Measure measure measure
<pixelherodev>
Always
<pixelherodev>
Because there's always factors you don't consider
<andrewrk>
yep that's why we have gotta-go-fast
<pixelherodev>
e.g. it might wreck cache behavior, or the branch predictor, or...
<pixelherodev>
hmm
<pixelherodev>
tdeo: suggestion for fallback
<wilsonk>
blast from the past...I had to read that Linear Scan Register Alloc paper for a course in Uni (and a graph coloring paper also to compare/contrast) ;)
<pixelherodev>
fallback to std.debug.warn for unimplemented pieces
<pixelherodev>
wilsonk: neat :)
<pixelherodev>
I guess that puts me a leg up
<pixelherodev>
... or however that idiom goes
<andrewrk>
hmm I just realized that kcov works fine for zig executables
<andrewrk>
don't believe the percents, code that was never even semantically analyzed is shown in white and not counted as the percent. that's even worse than red
_whitelogger has joined #zig
cole-h has quit [Quit: Goodbye]
cole-h_ has quit [Quit: Goodbye]
hooo has joined #zig
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bgiannan>
that's awesome
<pixelherodev>
So it needs to track whether or not code is ever analyzed?
Xatenev has joined #zig
dermetfan has joined #zig
wootehfoot has joined #zig
slice has quit [Quit: zzz]
ifreund has joined #zig
eddyb[legacy] has quit [Ping timeout: 252 seconds]
cbarrett has quit [Ping timeout: 252 seconds]
haliucinas has quit [Remote host closed the connection]
guan has quit [Ping timeout: 252 seconds]
wjlroe has quit [Ping timeout: 252 seconds]
eddyb[legacy] has joined #zig
guan has joined #zig
cbarrett has joined #zig
wjlroe has joined #zig
haliucinas has joined #zig
opDispatch has joined #zig
<daurnimator>
andrewrk: oh wow, awesome that kcov works
<daurnimator>
andrewrk: we should publish stats with each PR
<daurnimator>
hook codecov or coveralls up to CI
dermetfan has quit [Ping timeout: 265 seconds]
st4ll1 has quit [Quit: WeeChat 2.8]
ur5us has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
slurpie has quit [Ping timeout: 272 seconds]
dingenskirchen1 is now known as dingenskirchen
waleee-cl has joined #zig
_Vi has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
alexnask_ has joined #zig
alexnask_ is now known as alexnask
puzzleddev has joined #zig
dermetfan has joined #zig
<puzzleddev>
Hello, what is the purpose of 'std.os.windows'? To represent the entire windows API and it's just not done, or will it only contain what the standard library needs?
<ikskuh>
puzzleddev: there's an issue asking exactly this question on github
<ikskuh>
it's not decided yet
<puzzleddev>
Thanks
<ikskuh>
i think it's better to have a WinAPI package and only have only the required functions in the base package
stripedpajamas has joined #zig
<alexnask>
Yes I believe there is some package that includes all the windows api stuff without win32-lean-and-mean somewhere
<puzzleddev>
Thanks, I already had a look at it. I believe that the standard library should either not export any part of the underlying platform, or all of it.
<daurnimator>
puzzleddev: what about "just the parts needed to bootstrap"
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator>
also how do you define "underlying platform": ntapi? kernel32? user32? everything (which includes e.g. opengl?)
<puzzleddev>
They have to be in there somewhere, but shouldn't be exported, so that there is only one - good - way to do things: Get the proper package.
ur5us has quit [Ping timeout: 252 seconds]
<puzzleddev>
My personal ideal of a standard library is to provide a common interface with the platform, without the user having to know anything about it. This means excluding some capabilities only some of your target platforms have.
<daurnimator>
puzzleddev: that is indeed how some parts of the standard library work
<daurnimator>
puzzleddev: e.g. `std.fs` is mostly just common functionality
<alehander92>
but what's the difference
<alehander92>
between importing stdlib.winspecific.stuff
<alehander92>
and importing it from a winspecific package
<daurnimator>
alehander92: nothing
<alehander92>
stdlib is about usefulness as well
<daurnimator>
alehander92: except that e.g. std.fs *uses* std.os.windows under the covers
<daurnimator>
std.fs doesn't expose *every* flag possible on windows; and it shouldn't: if you need something specific, you have to drop down a level
<alehander92>
i am talking about "get the proper package"
<alehander92>
it's an interesting idea: on the other hand i fear of cases where one needs e.g. an optional flag for something on a platform
<alehander92>
but still wants to use `fs` for 80% of the code
<daurnimator>
exactly
<alehander92>
but yeah that's probably doable
<daurnimator>
you should try and use `std.fs` for cross platform compat and good semantics + good errors. but sometimes you need non-portable things
<alehander92>
also , `std.fs` and others are in a way examples of how good zig code looks
<alehander92>
so it would be a bit confusing for me as an user to not be able to use `std.os.windows` as well
<daurnimator>
there is a philosophy of "as little code is 'special' as possible"
<daurnimator>
std.fs is code anyone could write: it just uses std.os.windows
<alehander92>
exactly
<alehander92>
i was wondering about the "not exporting" idea, i misunderstood
<daurnimator>
std.os.windows is code anyone could write, it just wraps dlls and adds some zig semantics. + some inline asm
<alehander92>
it might mean its usable only in other stdlib modules
<daurnimator>
we don't have (or want) that barrier
<daurnimator>
if someone wants to fork std.fs; we don't want them to fork std.os.windows too
<daurnimator>
just ignore the bit of std.fs you don't like and hook in one level lower
<alehander92>
yeah, ok
<puzzleddev>
In the issue about the windows API the possibility was raised that only parts of it should be included in the standard library. On its own this is sensible, it reduced the amount of code to be written and maintained. However, new users are drawn to what the standard library contains, so the will naturally use this, partial, interface. What happens now if they need to grow out of it, if they need some functionality the standard library
<puzzleddev>
doesn't?
<puzzleddev>
There are then two or more ways to interact with Windows and the likelihood of them being partially incompatible is quite high. The way I'm seeing this it goes against one of Zig's principles of 'One obvious solution'.
<daurnimator>
puzzleddev: the correct answer is meant to be "the higher level module" :P
cren has joined #zig
<cren>
Is there an easy way to make all the characters in a string lowercase?
<ikskuh>
i don't think so, yet
<ikskuh>
there is no string(as in text) handling in stdlib yet
<alexnask>
std.ascii.allocLowerString
<alexnask>
If we are talking about ascii ofc
<opDispatch>
well for unicode this is another story
<cren>
ah I didn't see the `ascii` module because I was looking for the word `string`
waleee-cl has quit [Quit: Connection closed for inactivity]
cren has quit [Ping timeout: 245 seconds]
<fengb>
Philip White: I wrote a sexpr parse already! (Not that it’s hard...)
omglasers2 has joined #zig
layneson has joined #zig
layneson has quit [Client Quit]
layneson has joined #zig
cren has joined #zig
<ifreund>
i thought null terminated pointers would coerce to slices so I could compare them with std.mem.eql
<ifreund>
this seems to not be the case, and std.meta.eql compares them by pointer i believe
[rg] has joined #zig
<ifreund>
is there a proper way to do this with the std that I'm missing?
<ikskuh>
use std.mem.eql and std.mem.spanZ
<ifreund>
nice, thanks
<ifreund>
a little more verbose than I would have liked, but works great
<ikskuh>
no hidden control flow
<ikskuh>
searching the null terminator is that
<fengb>
Most of stdlib still doesn't understand null
<ifreund>
agreed
<ifreund>
though maybe an std.mem.eqlZ would be useful
<ifreund>
when working C you need to do strcmp fairly often
<fengb>
Zig now has badazz APIz
<ikskuh>
i think it's okay to repeat some of the spanZ
<ikskuh>
you can always import it into your namespace if you need it more often
<ifreund>
i mean i could, but i always go for the full std.mem.eql(u8, std.mem.spanZ( ...
<ifreund>
that would also avoid needing to @ptrCast() to a [*:0] first
<dimenus>
i just wrap cstr's in spanZ and then use regular eql from there
<dimenus>
that way i'm only calculating the length once
dimenus has quit [Quit: WeeChat 2.8]
dimenus has joined #zig
waleee-cl has joined #zig
xackus has joined #zig
terinjokes has joined #zig
nycex has joined #zig
layneson has joined #zig
drewr has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
stripedpajamas has joined #zig
wozeparrot has joined #zig
shakesoda has joined #zig
<oats>
is there a recommended way to use an allocator when you have to allocation across multiple diferent tests?
<oats>
I see there's a std.testing.allocator
<ikskuh>
std.testing.allocator is great as it also checks allocation count :)
<oats>
what do you mean by that? leak checking?
<ikskuh>
yep
<alexnask>
Yes it uses a leak checking alloc
<oats>
oh neat
<ikskuh>
each test will fail when it leaks memory
<alexnask>
Does it automatically call `validate()`?
<ikskuh>
and don't assume tests are run in a specific order or even at all
<ikskuh>
afaik yes
<alexnask>
Hmm interesting didnt realize this
redj has joined #zig
slice has joined #zig
<ikskuh>
alexnask, thanks for your contribution
<ikskuh>
is someone here using MacOS X?
<dermetfan>
When I want to free a slice obtained from ArrayList.toOwnedSlice(), I need to use the same allocator as in ArrayList.init(), right?
<alexnask>
haze on discord uses macos I believe
<alexnask>
dermetfan, yes
<dermetfan>
alexnask: Thanks
<dermetfan>
Does that mean the easiest way to store an owned []u8 in a struct is to store a pointer to an allocator along with it?
<dermetfan>
(so i can free the []u8 later when I no longer need the struct)
<alexnask>
It is common for structs that own some data to also hold an allocator pointer yes
<alexnask>
(or somethimes an Arena constructed from the passed in allocator instead)
<dermetfan>
Thanks a lot, that cleared things up for me
<dimenus>
dermetfan: typically you'd use the same allocator for most of your allocations. Think of allocation at the 'systems' level instead of the more granular object level
<dimenus>
systems or lifetimes
<alexnask>
Right, if you are making a tonne of these structs (let's say some kind of node with a name) you wouldnt store the allocator in each of them
<dimenus>
eg in my vulkan backend, i have a simple bump allocator that I reset every frame. No need to even worry about the allocator on the individual resources
cole-h has joined #zig
slowtyper has joined #zig
[rg] has quit [Ping timeout: 272 seconds]
<fengb>
I'm on macOS
<fengb>
Oh you switched
cole-h__ has joined #zig
cole-h_ has joined #zig
cren has quit [Ping timeout: 245 seconds]
cole-h has quit [Ping timeout: 265 seconds]
slurpie has quit [Remote host closed the connection]
<andrewrk>
pixelherodev, do you know what is the encoding of x86_64 call to a 32-bit hard coded address?
<pmwhite>
Wow, that's kinda risky, isn't it? Is it even being used/tested in anything yet?
<andrewrk>
for libraries like this, 1.0 isn't scary because the cost of rolling the major version is low and well-understood
<andrewrk>
it's a nice thing to do to hit 1.0, it means you are going to be meticulous about documenting when breaking changes happen
<andrewrk>
it's not a guarantee to not make breaking changes
<ikskuh>
pmwhite: tested on 8 different systems, 5 of them are fresh installs, except for zig
foobles has joined #zig
<ikskuh>
and now i'm going to use it :)
<ikskuh>
actually, i was creating the whole library only in a submodule, not as a standalone repo :D
<fengb>
1.0 is the new 0.1
<ikskuh>
i really hate having something working and calling it a "0" versiob
<ikskuh>
all this fear of big numbers
<ikskuh>
people in my company complained that their document is now "Version 78"
<ikskuh>
well, they hit "save" 78 times, doh
<fengb>
Back in mah day, nodejs jumped from 0.12 to 4.0
<ikskuh>
also, as andrew said: bumping versions with semver is documenting breaking changes
<ikskuh>
1.0 just means "first release of the first API design we got"
<ikskuh>
a well tested library is probably 1.3.2 or something
<ikskuh>
"we forgot stuff and we had some bugs"
<andrewrk>
consider how little developer time it would take to check what happened in 1.0->2.0 in a known-folders package update, and update your application to use the new version
<ikskuh>
yep
<ikskuh>
also, 2.0 would mean "breaking changes in the API" which may happen
<nephele>
Somehow, an api that gives a settings file handle would be much nicer than having to deal with XDG ;)
<ikskuh>
but an API consisting of 1 type and two functions :D
<andrewrk>
and the benefits are huge: the package can iterate towards the ultimate version of a robust, optimal package for that purpose, not constrained by past mistakes
<ikskuh>
nephele: we deliver that! at least, partially :)
<pixelherodev>
That's... hmm, one sec, going back to the manual
<pixelherodev>
0x14 0x25, I think?
<pixelherodev>
seven bytes instead of six
<pixelherodev>
Yeah!
<pixelherodev>
That works!
<pixelherodev>
0xFF 0x14 0x25
<andrewrk>
testing
<pixelherodev>
callq *0x0
<andrewrk>
oh that's indirect?
<pixelherodev>
... it looks it, yeah
<pixelherodev>
I... can't tell because the freaking asm syntax always confuses the hell out of me
<pixelherodev>
I somehow have an easier time with raw machine code lol
<andrewrk>
I don't think there is an encoding for call direct a 32 bit immediate address
<pixelherodev>
Yeah, I don't think so either
<pixelherodev>
RIP-relative, yes, but that's not really what's wanted here either
<andrewrk>
hmm in this case there was no point to setting up the trampoline table
<andrewrk>
I should just do `0xFF 0x14 0x25 xx xx xx xx` with the same global offset table as all the decls are in, nothing special for functions
<pixelherodev>
:)
<ikskuh>
andrewrk: why no riprelative?
<pixelherodev>
RIP-relative is also an option, yeah
<ikskuh>
you know the address of RIP anyways, right?
<pixelherodev>
&
<pixelherodev>
s/&/^
<pixelherodev>
Plus it's six bytes instead of seven
<andrewrk>
ikskuh, this is the part where all function calls are intentionally indirect in debug builds, so that they can be moved around in the elf file without causing O(N) updates to the elf file
<pixelherodev>
Hmm
<pixelherodev>
Actually
<pixelherodev>
Ohhh, right
<pixelherodev>
okay then nvm
<ikskuh>
moving a function around without recompilation?
<andrewrk>
yep
<pixelherodev>
that also explains why 0xE8 encoding is off the table
<andrewrk>
moving it around in virtual address space
<pixelherodev>
Have fun with that :P
<pixelherodev>
Huh
<pixelherodev>
it would actually take *more* work to use a trampoline table than to use GOT directly lol
<pixelherodev>
We'd need a `mov addr -> reg` `call reg` pair :P
<andrewrk>
yeah that's what I'm saying
<dimenus>
you're trading runtime speed for faster code reloading
<dimenus>
:)
<pixelherodev>
Nope, not quite
<pixelherodev>
It's also faster
<dimenus>
the trampoline table?
<pixelherodev>
No
<pixelherodev>
That would be slower
<pixelherodev>
Using the GOT directly is faster to generate *and* faster to run
<dimenus>
sorry by 'you' i mean Andrew / the debug backend
<pixelherodev>
Yeah, that's what I'm referring to
<pixelherodev>
Ohh
<pixelherodev>
The backend in general?
<dimenus>
sorry, not familiar with the 'GOD'
<dimenus>
*GOT
<pixelherodev>
Yeah
<pixelherodev>
The GOT is used for all calls in the incremental compiler
<pixelherodev>
and it is slower than direct calls
<pixelherodev>
but necessary for the "incremental" part
<andrewrk>
dimenus, yeah that's correct
<pixelherodev>
So yeah, the backend as a whole *does* trade runtime speed for faster compilation on the next *increment* :)
<andrewrk>
it's going to take some more development efforts to improve release builds as well, but that's the point. the compiler does the complicated work so the programmer can enjoy simplicity
<pixelherodev>
Hey, it's been a full day since I've accidentally put an IRC command into IRC chat! Huzzah!
<pixelherodev>
:)
[rg] has quit [Ping timeout: 256 seconds]
<andrewrk>
cool, got function calls working. thanks pixelherodev :)
<BaroqueLarouche>
nice :)
<pixelherodev>
:)
<dimenus>
andrewrk: Your progress on that backend so far is pretty epic, how many times have yo had to iterate on the ZIR design?
<pixelherodev>
More than welcome
<pixelherodev>
Figured out why I thought it was /4
<pixelherodev>
That's jmp
<pixelherodev>
:P
<pixelherodev>
Mixed up the call and the jump encodings
<andrewrk>
dimenus, I spent an entire week just messing with struct definitions without testing anything
<dimenus>
hah awesome
<dimenus>
i'm working on a wayland native stack for a vnc client to work with wayvnc
<andrewrk>
cool
<dimenus>
(in zig of course)
<ifreund>
wayland + zig is wonderful
<fengb>
X + zig is wonderful :P
<companion_cube>
X + rust is wonderful
<companion_cube>
oops
foobles has quit [Remote host closed the connection]
<fengb>
Ew a four letter word
<ikskuh>
oops?
<companion_cube>
cool
<pmwhite>
oops is my favorite programming paradigm.
[rg] has joined #zig
<fengb>
OOP = oops oriented programming
<pixelherodev>
Objects of Power
<pixelherodev>
Managed to crash ZLS like ten times in the last sixty seconds
* pixelherodev
grimaces
<ifreund>
weird, hasn't crashed on me once today
<fengb>
ZLS can't handle the power
<pixelherodev>
ifreund: it crashes ten times in the exact same file
<pixelherodev>
Reallllly didn't like the partial AST
<pixelherodev>
Probably wouldn't have happened if I disable the auto check for errors while typing thing
<[rg]>
what is zig status now? last time I checked advice was to use master
<pixelherodev>
Still the case
<[rg]>
ok, ty
<pixelherodev>
Or a nightly build from the site
<ifreund>
well, depends on your project
<ifreund>
0.6.0 has been been fine for me for something a little more long term
<andrewrk>
[rg], I think 0.6.0 is still viable at this point
<andrewrk>
but please test with master before reporting bugs
<pixelherodev>
Isn't the advice to use master because breaking changes are the norm and thus you're going to need to update over time anyways?
<pixelherodev>
(and thus, you should do it incrementally by sticking with master)?
<ifreund>
zig fmt should be able to update most things between stables
<fengb>
Minimal breaking changes since 0.6 so far
<andrewrk>
pixelherodev, that's up to the individual. when I suggest to use master, it's because I anticipate that they will run into already-solved issues
<ifreund>
breaking changes will hopefully be coming in the form of #1717 though
neceve has joined #zig
<fengb>
Uh huh. I've waiting an entire release cycle for that :P
tgschultz has joined #zig
<ifreund>
anonymous functions will be so nice
<pixelherodev>
No more struct wrapping?
tgschultz has quit [Ping timeout: 265 seconds]
tgschultz has joined #zig
<andrewrk>
I'm a bit confused why everyone is so excited about this
[rg] has quit [Ping timeout: 265 seconds]
<dimenus>
exit
<dimenus>
oops lol
* pixelherodev
shrugs
<pixelherodev>
same
dimenus has quit [Quit: WeeChat 2.8]
<pmwhite>
So we can make zig-lodash.
dimenus has joined #zig
<ifreund>
it'll make the ergonomics of stuff like setting up callbacks and using filter functions for iteration a lot niceer
<ifreund>
i also just like the syntax
<ikskuh>
^-
<companion_cube>
using filter/map? how is that C like? :p
<pmwhite>
It's not C like, but that's okay.
<pmwhite>
Async/await isn't C like.
[rg] has joined #zig
<pmwhite>
I was also kind of joking about zig-lodash. If you aren't careful with that, you could end up writing slow code.
<companion_cube>
or high level code, who knows
<pixelherodev>
The good news is, my register allocator works! Yay
a_chou has joined #zig
<fengb>
I was previously waiting for #1717 to make function pointer dispatch, but I eventually went another direction
<[rg]>
pixelherodev: you work on the compiler as well?
<dimenus>
[rg]: i think he's doing embedded stuff
<pixelherodev>
[rg]: Yes
<pixelherodev>
dimenus: not quite
<pixelherodev>
I do work on stage2, though I'm not right now
<pixelherodev>
Well
<pixelherodev>
I'm writing a simple register allocator, which *will* be part of stage2 down the line
<pixelherodev>
Or at least, a different implementation will
<[rg]>
interesting
<pixelherodev>
But I'm doing this for a JIT project
<[rg]>
zig jit? xD
<pixelherodev>
I work on both, finding places where one is beetter than the other and improving them both in the process
<pixelherodev>
[rg]: yeah
<fengb>
So it'll be a part of the comptime engine right?
<pixelherodev>
This specifically is part of codegen
<dimenus>
all the backends!
<pixelherodev>
Parts of lightzing will be useful for accelerated comptime though
a_chou has quit [Client Quit]
<[rg]>
is the project public?
<pixelherodev>
Most of it is, yeah
<pixelherodev>
ALl of it *will* be
<pixelherodev>
Some parts are a bit too WIP for that yet though
<[rg]>
ok, I'll wait, hopefully I'll have finished my codegen material and can contribute
<pixelherodev>
Currently up are an LLVM IR parser and the status of the JIT / assembler stuff from three weeks ago
<scientes>
how do i do a array of i24 that is densely packed?
<scientes>
its packing it to 4-wide, instead of 3-wide
<scientes>
even if i do align(1)
<pixelherodev>
Bug
<pixelherodev>
Packed stuffs are bugged atm
<scientes>
its just [*]align(1) i24
<scientes>
not a struct or array
<andrewrk>
I just had a phone call with a representative of MajorLeagueHacking Fellowship. they're interested in sponsoring a handful of students for 12 weeks to contribute to Zig. and they provide their own mentors too
<andrewrk>
it's a public benefit corporation, seems like it might be a great fit!
<pixelherodev>
Hmm
<pixelherodev>
I mean, *I'm* technically a student
<fengb>
That's amazing
<pixelherodev>
:P
<pixelherodev>
I probably don't qualify though
<andrewrk>
pixelherodev, you should for sure apply and try to get funded
<pixelherodev>
worth a shot, that's for sure
<pixelherodev>
There an application link on their site, or?
<ifreund>
very cool!
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus>
amazing
<dimenus>
andrewrk: are the mentors people we might recognize?
<andrewrk>
hm I'm not sure
<alexnask>
Time to indoctrinate some young people in the ways of zig
<pixelherodev>
alexnask: I'll have you know I'm already indoctrinated, thanks
<pixelherodev>
;)
<ikskuh>
pixelherodev, you are faaar beyond that already :D
<[rg]>
oh cool!!!
<[rg]>
mlh sounds great, but I'm also looking for work, does sponser mean you get paid also?
<GreaseMonkey>
i would be surprised if it didn't
slice has quit [Quit: zzz]
<andrewrk>
yes they pay students. it's an alternative to internships
<[rg]>
ok, I'm hopefull to get through
<andrewrk>
good luck!
<GreaseMonkey>
had a thought i would have to apply when i finish work for the day: for implementing a deflate compressor i think the first thing to do would be to do Huffman compression without using the LZ stuff, the LZ stuff can come later
kllr_sbstn has quit [Quit: WeeChat 2.7.1]
<GreaseMonkey>
i'm thinking that the pre-Huffman chunks should be split into a maximum of 2^15 entries, when i get around to the LZ stuff i'd probably opt for a 32KB sliding window
stripedpajamas has joined #zig
slice has joined #zig
<GreaseMonkey>
in the interest of cleanliness i'd be happy to use a bit more space to keep the distances in a separate buffer, and the offsets from the base lengths and distances in a separate buffer still
<GreaseMonkey>
that way i can calculate dynamic Huffman trees against the literal and distance buffers fairly cleanly
<pixelherodev>
andrewrk: where's the application to?
<andrewrk>
I sent a follow-up email asking this, will let you know when I get a response
<pixelherodev>
Thanks :)
[rg] has quit [Ping timeout: 272 seconds]
<pixelherodev>
I really need to port my Register improvements from stage2 to Thor
<blueberrypie>
pretty cool andrewrk. nice to see development of Zig getting sponsored.
<andrewrk>
pixelherodev, [rg], and other students: apply here: https://fellowship.mlh.io/students/apply and then msg me your names/emails so that I can tell them to flag your application
<andrewrk>
will make an announcement on other channels about this today as well
<pixelherodev>
:)
<pixelherodev>
Ugh, need to update my resume :P
<pixelherodev>
At least I can add "Stage2 Zig contributor" now :)
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 252 seconds]
MajorLag is now known as tgschultz
FireFox317 has joined #zig
slice has quit [Quit: zzz]
<FireFox317>
¨We’ll be funding up to 1,000 students to work full time on major open source projects under the mentorship of experienced engineers.¨ Damn, that is cool!
<pixelherodev>
Nice :)
tgschultz has quit [Ping timeout: 252 seconds]
<pixelherodev>
msg andrewrk ... I'm going to guess high school
tgschultz has joined #zig
<pixelherodev>
Oohh, ZLS changes look awesome :)
<alexnask>
pixelherodev, We have simple generic typefn support now :-D
<pixelherodev>
I saw :)
<alexnask>
ArrayList wont quite work but other std types do
<pixelherodev>
:D
<pixelherodev>
Updating now
<pixelherodev>
I'm hopeful some of my custom types work :)
<alexnask>
It should work if you have a single return with a container decl expression
<pixelherodev>
:(
<pixelherodev>
That's a "probably not"
<alexnask>
I cant really see how to do anything but single return statements without evaluating comptime expressions
<alexnask>
I will prob have to do this for simple booleans based on builtin + build option stuff
<alexnask>
To enable std.os stuff too
Akuli has quit [Quit: Leaving]
B4s1l3 has joined #zig
<pixelherodev>
Figured out why kak was running so slowly
<pixelherodev>
There were like three hundred processes attempting to connect to the kak-discord daemon plugin :face_palm:
<pixelherodev>
Which was dead
GoorMoon has joined #zig
<pixelherodev>
Hey, it works!
<pixelherodev>
Now I just need packages, and I'm good!
[rg] has joined #zig
<pixelherodev>
alexnask: ZLS has access to build.zig, correct?
<alexnask>
We dont do anything useful with it but we are planning to parse it and get build options etc
<scientes>
when i try to build zig master I get (.text._ZN12_GLOBAL__N_118EmitAssemblyHelper30EmitAssemblyWithNewPassManagerEN5clang13BackendActionESt10unique_ptrIN4llvm17raw_pwrite_streamESt14default_deleteIS5_EE+0x1f15): referencia a `getPollyPluginInfo()' sin definir
<andrewrk>
alexnask, one thing that's always been planned with build.zig is that an IDE or ZLS project would be able to run it in a special mode that outputs machine-readable information about the build. it is declarative, after all
<pixelherodev>
Right, that's what i'm thinking
<pixelherodev>
I might take a break later and add package support
<pixelherodev>
Temporary patch idea:
<andrewrk>
alexnask, so let me know if you get to that point and we can figure out what will work for you
<pixelherodev>
In the config.JSON, add a `packages` array thats maps imports to paths
<pixelherodev>
It adds a working short-term solution until proper parsing is done
<ikskuh>
andrewrk: brainfart, but that means that build.zig is actually a full-featured project file where we can write an IDE with a project tree and everything
<alexnask>
andrewrk, Sure, that makes a lot of sense
<ikskuh>
:
<ikskuh>
:D
squeek502 has joined #zig
<pixelherodev>
ikskuh: yeah, I think that's the point :)
<ikskuh>
it's awesome :D
<andrewrk>
alexnask, in fact, one thing that's even possible now, since ZLS has access to the zig binary, is to have the ZLS have an alternative build runner zig file (e.g. implementing a different main() than std/special/build_runner.zig) which collects the build information and then does whatever you want with it
<andrewrk>
you'd just @import("the-user-build-zig") using --pkg-begin the-user-build-zig path/to/build.zig --pkg-end and run it
<andrewrk>
then call build()
<andrewrk>
and then do whatever you want
<andrewrk>
collecting package info in this way should be pretty straihtforward I think
ur5us has joined #zig
<pixelherodev>
I'll tackle that tomorrow, if nobody else wants to do it :)
<pixelherodev>
I just need to get some other stuff done tonight, and then head to sleep early (since I was up at five this morning :P)
<pixelherodev>
But I can probably get that done by noon tomorrow
cole-h has quit [Quit: Goodbye]
<pixelherodev>
Drats, onImport doesn't have the config :(
cole-h has joined #zig
<pixelherodev>
If it did this would be trivial
<pixelherodev>
... meh, locally patching analysis to have Config isn't a big deal
<pixelherodev>
It's temporary anyways
<alexnask>
pixelherodev, On latest master we pass the zig_lib_path to the analysis context anyway, you can just modify that to take the whole config
<pixelherodev>
Ohh yeah
<pixelherodev>
Good point
xackus has quit [Ping timeout: 260 seconds]
<pixelherodev>
Okay, that's simple enough
<pixelherodev>
ugh, doesn't work though
<pixelherodev>
Oh whoop
<pixelherodev>
allocation missing
<andrewrk>
damn I got nerd sniped by the perf benchmarks, I'm 2 hours into reworking the self hosted parser to go faster
<fengb>
Can’t know how fast you go without measuring it!
layneson has quit [Ping timeout: 264 seconds]
<pixelherodev>
h
<pixelherodev>
ah
<pixelherodev>
lol
neceve has quit [Ping timeout: 256 seconds]
<pixelherodev>
Screw it, not wasting more time on this
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stripedpajamas has joined #zig
<[rg]>
does zig have regular expressions?
<andrewrk>
not in the std lib
<[rg]>
that by design? or planned
<andrewrk>
whether regex in the std lib is planned or not is yet to be determined
<[rg]>
ok fair enough, regex is pretty complex
<pixelherodev>
It's planned to plan whether to plan for regex
<andrewrk>
true
<jhamren>
lol
FireFox317 has quit [Ping timeout: 256 seconds]
[rg] has quit [Quit: Konversation terminated!]
dimenus has quit [Ping timeout: 256 seconds]
layneson has joined #zig
squeek502_ has joined #zig
squeek502 has quit [Ping timeout: 264 seconds]
THFKA4 has joined #zig
foobles has joined #zig
GoorMoon has quit [Remote host closed the connection]
<foobles>
when you use heap::c_allocator, do you have to free anything?
<foobles>
or is that just done automatically when the compiler exits
<andrewrk>
allocation with std.heap.c_allocator is equivalent to calling malloc() and freeing is equivlent to calling free()
<pmwhite>
The is frees everything once the process exits.
<pmwhite>
OS*
<andrewrk>
the OS frees all your memory when your program exits, but if you do anything in a loop, that won't be quite enough
<pixelherodev>
Is it worth sending a PR to fix a single typo, or should I look for more first? :P
<foobles>
andrewrk I am allocating a buffer to pass to ir_build_phi_gen
<foobles>
just like what ir_analyze_phi or whatever does
<foobles>
and they dont free their ziglists
<andrewrk>
oh yeah stage1 is pretty bad about freeing memory
<foobles>
oh ok
<foobles>
so its ok if I just don't worry about that?
<andrewrk>
yeah it's ok. it matters more or less depending on context but we can work out these details during PR review
<pixelherodev>
...
<pixelherodev>
if I send patches to free memory, would they be accepted?
<andrewrk>
of course, if they don't introduce use-after-free
<foobles>
alright thanks
<pixelherodev>
Coolio
<pixelherodev>
I might look into doing that
<pixelherodev>
Also, Thor works :D
<pixelherodev>
Really freaking excited
<pixelherodev>
It actually works
<andrewrk>
register allocation?
<pixelherodev>
and then some
<andrewrk>
well done
<foobles>
also one thing i noticed is that all the static `constexpr IrInstGenId ir_inst_id(Foo *) {` functions are never actually evaluated at compile time
<foobles>
wow it put a winky face in my code
<foobles>
but anyway, they are all passed runtime pointers
<pixelherodev>
`msg` is a register on this virtual chip (obtained by allocateRegister)
<pixelherodev>
The *real* register allocator assigns virtual registers to real ones
<pixelherodev>
Takes care of passing through to host functions (such as `write`, which is just a callconv(.C) shim over std.os.write)
<pixelherodev>
Correctly handles multiple args, and supports multi-return
<pixelherodev>
I plan on improving efficiency of generated asm before adding more; I want to make it within 3% as fast as using the raw backend for any given platform, to encourage usage of the high-level abstraction
<pixelherodev>
One goal of this is to be able to hook it up to comptime processing in stage2
<pixelherodev>
So that comptime code can be passed through to Thor, and from there to the native backend (x86, ARM, RISC-V, etc)
slice has joined #zig
<andrewrk>
foobles, you're welcome to try to re-arrange that code if it has same or better maintenance properties and better performance properties
<foobles>
alright cool. would it be ok to use template overloading instead? if anything, maybe just getting rid of the `constexpr` since its misleading
<andrewrk>
better yet would be something that doesn't depend on c++ features at all since we eventually want to not use any c++ in stage1
<andrewrk>
but if that's better than status quo, go for it
<pixelherodev>
ooh, I can port stage1 to C?!
<andrewrk>
not yet
<andrewrk>
first we have to be shipping stage2
<pixelherodev>
Drats
<andrewrk>
then stage1 needs to generate C instead of llvm
<andrewrk>
then you can port stage1 to C
<pixelherodev>
Even if it doesn't break anything and I do it incrementally? :P