<pixelherodev>
shakesoda: is there anything other than powertop that is worth using as well?
<andrewrk>
pixelherodev, yeah something like that
<pixelherodev>
gotcha
<shakesoda>
pixelherodev: i just use powertop
<pixelherodev>
Going to leave the other three in place for now, merge their functionality into Stages, add addZIRCase functions (and port the existing ones so that they generate single-stage cases), port over tests
<pixelherodev>
That's the path for this specific PR
<pixelherodev>
adding more tests / reenabling old tests could come later
<pixelherodev>
One nice feature about this design is that it allows seamlessly adding additional stages later on
<pixelherodev>
e.g. OptimizationStage
<leeward>
Alright, here's a kinda-minimal version of a problem I'm having: https://godbolt.org/z/xrP3EW Anyone know why it can't evaluate the constant expression?
<pixelherodev>
... okay this is the last help I'm giving for today, I swear
<pixelherodev>
Taking a look
marijnfs has joined #zig
<leeward>
;)
<pixelherodev>
(I really need to get more work done :P)
<pixelherodev>
Hmm
<pixelherodev>
That's what I would've expected to see with maybe 0.5
<pixelherodev>
not 0.6
marijnfs_ has quit [Ping timeout: 264 seconds]
<pixelherodev>
This is almost definitely a bug, unless I'm missing something
<leeward>
I was afraid you'd say that.
<fengb>
I don’t think you can stick `var` in a struct
<pixelherodev>
ahh, yeah
<pixelherodev>
Good catch
<pixelherodev>
The compiler should be refusing that
<leeward>
Well, that's 1 bug then.
<pixelherodev>
leeward: give me one sec and I'll paste a fixed version
stripedpajamas has quit [Quit: sleeping...]
<leeward>
Does it involve passing the type in to a function and constructing the struct with that type?
<ttmrichter>
Cool. I'm going to give zig a try for embedded systems then. I'm tired of C. Like REALLY god-damned tired of it. :D
<shakesoda>
i've been really happy with it, although i think c will continue to have a place in my life
<shakesoda>
i think my bias toward being happy with it is fairly clear based on, well, being here
<ttmrichter>
I'll start assembling a quirky Zig toolchain in my Copious Free Time and maybe start wrapping peripherals in libraries and such.
<leeward>
Be warned, ttmrichter: header file generation is not done, so if you want to link to Zig libraries from C you may hit some bumps.
<pixelherodev>
The only problem with targeting ARM is that you currently *have* to specify the features list for native compilation IIRC
<pixelherodev>
Wait, what?
<pixelherodev>
That's not true
<pixelherodev>
Headers generate just fine IIRC
<pixelherodev>
-femit-h
<leeward>
There are bugs.
<pixelherodev>
Ahh
<pixelherodev>
Gotcha
<pixelherodev>
Good to know
<ttmrichter>
leeward: I'd be doing things from scratch here.
<leeward>
I have a medium sized project that's waiting for that bit of the codebase to stabilize.
<pixelherodev>
But yeah, once I'm done with the errors_test branch (which *will* be within the next twelve hours), self-hosted ARM feature detection is next on my radear
<leeward>
No problems then. Enjoy.
<ttmrichter>
The idea being a whole-hog switch to Zig. It's not as if these beasts are multi-billion transistor devices after all. :D
<pixelherodev>
Whole-hog?
<pixelherodev>
Ahh
<pixelherodev>
Gotcha
<ttmrichter>
Just ground-up write of the libraries to C. Starting with using the register description files to generate the structures, etc. for the various devices.
<ttmrichter>
s/C/Zig/
<ttmrichter>
Damned language infects everything. :D
<leeward>
hah
<leeward>
Yeah, that sounds fun.
<daurnimator>
I think someone did a generation thing from.... srt files?? I don't recall wel
<ttmrichter>
That's where I'd go for ARM for sure, yes.
<ttmrichter>
So ... RISC-V?
<pixelherodev>
srt?
<pixelherodev>
... subtitles?
<pixelherodev>
ttmrichter: ooh
<pixelherodev>
RISC-V?
<ttmrichter>
SVD I think he means.
<pixelherodev>
What about it?
<ttmrichter>
Does LLVM support RISC-V as a back-end yet?
<pixelherodev>
Yep!
<pixelherodev>
in LLVM 10, it's an official target
<pixelherodev>
Zig will support it, too.
<pixelherodev>
That's not a question.
<ttmrichter>
Crap! Uh ... Let me desperately pull something out of the air. STM8?
<pixelherodev>
because I'm going to make sure of it.
<leeward>
Oh, you want to USE our processors? Well, they're super advanced and our competitors would kill to know how to use them, so...you'll have to sign these.
<ttmrichter>
Sounds like effin' NXP to me.
<daurnimator>
TI had a similar thing for their DSPs
<ttmrichter>
"Here's a data sheet that doesn't actually give you the information you need to evaluate whether our product is suitable or not. If you want the full datasheet, you have to order at least 10,000 units."
<pixelherodev>
You have got to be kidding me.
<leeward>
Well, I get a "No route to host" when I try to go to that particular company's web site now.
<pixelherodev>
Seriously.
<pixelherodev>
The datasheet doesn't mention the ISA.
<pixelherodev>
That's ridiculous.
<leeward>
NXP: because Freescale got such a terrible reputation.
<pixelherodev>
I might have to e.g. find the register count or something
satchmo has joined #zig
<ttmrichter>
I know one of their docs did because I decoded the whole alphabet soup to figure out what was inside.
<ttmrichter>
Maybe I have to go to the "Bumblebee Core" docs.
<ttmrichter>
That's the one that opens at the end.
<pixelherodev>
Pretty sure that's what I'm looking at
<daurnimator>
ttmrichter: for me at that url I get GD32VF103_Datasheet_Rev_1.2-2.pdf
<pixelherodev>
No wait
<pixelherodev>
^
<pixelherodev>
yeah
<ttmrichter>
Weird.
<ttmrichter>
Why would we get two different docs?
<daurnimator>
you logged in?
<leeward>
I have a basic b.addTest("src/filename.zig") type thing, and can't figure out how to get it to dump the test executable someplace easy to find/debug.
<pixelherodev>
leeward: LibExeObjStep in build.zig has `output_dir: ?[]const u8`
<ttmrichter>
That's where the Bumblebee Core itself is documented.
<leeward>
pixelherodev: I tried setting that to ".". No joy.
<pixelherodev>
e.g. if `a = b.addTest...`, a.output_dir = "blah"
<pixelherodev>
std.fs.cwd()?
<pixelherodev>
There might be a way to get cwd as a path
<ttmrichter>
Anyway, weirdness aside, god DAMN am I glad that Zig will be supporting RISC-V as well as my Cortex-M devices.
<pixelherodev>
Anyways, heading off
* pixelherodev
peaces out
<pixelherodev>
andrewrk: you still on?
<pixelherodev>
Eh
<pixelherodev>
Worst case you have me redo some work
xackus_ has joined #zig
xackus has quit [Ping timeout: 272 seconds]
xackus has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
<pixelherodev>
andrewrk: stage2 incremental compiler idea: a way to serialize the current state, so that if you're working on a giant (think Chrome) project, and you reboot or something, it still can continue where you left off instead of needing a fresh build
marijnfs_ has joined #zig
<andrewrk>
yeah, planned
marijnfs has quit [Ping timeout: 260 seconds]
stripedpajamas has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
cool :)
<pixelherodev>
glad to hear we're on the same page
hspak has joined #zig
<pixelherodev>
That means more focus for the next bikeshed!
<pixelherodev>
Should it be green, or blue this time?
<pixelherodev>
:P
riba has joined #zig
xackus_ has joined #zig
xackus has quit [Read error: Connection reset by peer]
riba has quit [Ping timeout: 265 seconds]
reductum has joined #zig
joey152 has quit [Quit: Leaving]
satchmo has quit [Ping timeout: 246 seconds]
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
<andrewrk>
blue
<daurnimator>
transparent red.
slowtyper has joined #zig
dddddd has quit [Ping timeout: 258 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
Zannzen has joined #zig
Zannzen has quit [Remote host closed the connection]
zannzen[m] has joined #zig
aerona has quit [Quit: Leaving]
Zannzen has joined #zig
Zannzen has quit [Remote host closed the connection]
stripedpajamas has quit [Quit: sleeping...]
marijnfs_ has joined #zig
<ttmrichter>
Peach, leaning more to the yellow end.
<ttmrichter>
Looking over the Zig manual, am I correct in reading suspend/resume as coroutines and async/await as reactors?
marijnfs has quit [Ping timeout: 272 seconds]
<daurnimator>
ttmrichter: what is a "reactor" here?
<daurnimator>
ttmrichter: think of `async foo()` as "start running foo(), but I don't want the result yet"
<daurnimator>
while `await frame` is "okay I want that result now"
<daurnimator>
`await async foo()` is equivalent to `foo()`
slowtype1 has joined #zig
slowtyper has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 260 seconds]
stripedpajamas has joined #zig
dermetfan has joined #zig
<ttmrichter>
daurnimator: The most well-known reactor would be Node.js right now.
<daurnimator>
ttmrichter: so reactor=event loop implementation?
<ttmrichter>
Event loop plus callback Hell, yes.
<daurnimator>
ttmrichter: ah. no then. zig's "reactor" is std.Event.loop
<ttmrichter>
OK, so this is more like a futures thing?
<daurnimator>
ttmrichter: depends what you mean by futures....
<ttmrichter>
I call a function and it goes its merry way until I want the results. It may or may not be executing in parallel, but when I ask for the result it either returns an extant one or it stops and waits for one.
<ttmrichter>
So I'm saying "I want the result to this at some undetermined point in the future".
<daurnimator>
sounds close enough.
<ttmrichter>
So the designer has thrown the entire concurrency kitchen sink into it? :D
<daurnimator>
ttmrichter: so there's a few settings that control it
* ttmrichter
looks for shared-state threading, actors, and pi calculus...
<daurnimator>
ttmrichter: in your root .zig file, you can have a `pub const io_mode` -> the standard library looks at this and decides if it should use e.g. blocking IO, or a threadpool.
<daurnimator>
if `read()` returns `EAGAIN` and you have an event loop, then give it to the event loop (which *may* `suspend`); otherwise return an error.
<ttmrichter>
I am looking forward to experimenting with Zig in the embedded world. What's a good stress test for its ability to keep small? I have a few MCUs with about 4KB of SRAM and 16KB of Flash. Is that too small or could I feasibly do something useful in that space?
<daurnimator>
ttmrichter: I don't know... what would you implement in that much space with C?
reductum has quit [Quit: WeeChat 2.8]
benjif has quit [Quit: Leaving]
<ttmrichter>
Last time I worked with one, I implemented a power switch. :D
<ttmrichter>
Oh, no. A joystick controller too.
stripedpajamas has quit [Quit: sleeping...]
<daurnimator>
ttmrichter: try doing that in zig then?
ur5us has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
_Vi has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
xackus has joined #zig
xackus_ has quit [Ping timeout: 246 seconds]
marijnfs has quit [Quit: Lost terminal]
yawniek has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
ur5us has joined #zig
craigo has quit [Ping timeout: 240 seconds]
<ttmrichter>
daurnimator: First step is a blinky, obviously. :D
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
ifreund has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
m910q has joined #zig
recombinant has joined #zig
ur5us has joined #zig
mondra has joined #zig
mondra has quit [Remote host closed the connection]
mondra has joined #zig
dddddd has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
Snetry has quit [Ping timeout: 246 seconds]
Snetry has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
st4ll1 has quit [Ping timeout: 256 seconds]
st4ll1 has joined #zig
bheads has quit [Remote host closed the connection]
opDispatch has quit [Remote host closed the connection]
opDispatch has joined #zig
<gonz_>
ttmrichter: It's unlikely that you'll see a kitchen sink approach in Zig generally speaking.
ifreund has quit [Ping timeout: 258 seconds]
ifreund has joined #zig
mononote_ has quit [Remote host closed the connection]
mondra has quit [Remote host closed the connection]
drewr has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
nycex has quit [Client Quit]
mokafolio has quit [Remote host closed the connection]
mokafolio has joined #zig
<pmwhite>
Someday I'd like to see a language who's design philosophy is to have every feature imaginable.
dongcarl has joined #zig
<fengb>
C++? Scala?
<leeward>
Lisp?
<leeward>
Really though, sounds like modern C++.
<ifreund>
pretty much yeah
<BaroqueLarouche>
D also
<companion_cube>
or scala, indeed
<ifreund>
yeah D is beating C++ in that it has a freaking "optional" garbage collector
<gonz_>
D is a lot more targeted also in that Walter Bright's tried to add "the future" to D several times.
<leeward>
Boehm is an optional GC for C++.
<pmwhite>
If D, Scala, or C++ were actually the kitchen sink language, they would have logic programming too.
<ifreund>
true, someone should make a proposal!
<fengb>
I’d expect logic programming to be complete incompatible with imperative
<companion_cube>
pmwhite: heh, monads can do that in scala™
<fengb>
Although I suppose C++ would be willing to prove me wrong
<companion_cube>
and implicits are already logic programming at type level :D
<ifreund>
inline prolog subroutines
<leeward>
Take the Lisp approach and write a prolog in C++?
<fengb>
Hmm... can we use comptime to implement prolog?
<leeward>
almost certainly
<fengb>
I dub it... nooblog
<leeward>
There's an interesting idea: using comptime Zig code to implement other languages.
<leeward>
Not a good one, mind.
<pmwhite>
How would you write a line of prolog if you were to do that?
<companion_cube>
in a []u8 :p
<alehander92>
you can use it as a type system inference engine
<pmwhite>
Zig doesn't have syntax quoting.
<companion_cube>
and the comptime executes it!!!
<alehander92>
i tried once for python
<leeward>
@embedFile
<alehander92>
it was very naive as i am not good at those
<fengb>
You can stick anything into a comptime string and create an ast
<alehander92>
but it kinda fits
<fengb>
Feels a little cheaty though
<pmwhite>
Oh, lol, I guess a string would work. I like @embedFile though.
<shakesoda>
the crazy metastuff people are doing in zig and the package manager nonsense are already pushing beyond the things i actually want, language-wise :D
<pmwhite>
I see what y'all are thinking...compile-time evaluation of other languages.
<shakesoda>
PLEASE NO MORE, MY POOR BRAIN NEEDS SIMPLICITY
<alehander92>
and you dont even have http downloads in macros yet
<fengb>
At that point it’s basically a runtime parser but we can get away with doing it at comptime
<alehander92>
you're so missing out
<fengb>
Jai has arbitrary syscalls at comptime.... maybe
<shakesoda>
really looking forward to all the new work going into fast builds, that aside
<alehander92>
many langs have that
<alehander92>
ok, not *many*
<shakesoda>
fengb: jai may or may not have anything but it doesn't exist
<shakesoda>
until it's out ;)
<alehander92>
but rust, nim can also execute many io things
<alehander92>
on CT
<fengb>
Jai is the only other language that has comptime in the same way Zig does
<fengb>
Sorry, it may have comptime :P
<companion_cube>
shakesoda: what's your problem with the PM?
<shakesoda>
or would, if it existed
<leeward>
What about D?
<companion_cube>
it'd happen anyway, no modern lang doesn't have a PM
<shakesoda>
companion_cube: package managers have this inherent way of increasing the complexity of utterly anything that gets near them by breaking things up into these tiny little hells of recursive dependencies
<alehander92>
do you guys like nix
<shakesoda>
companion_cube: incidentally, i have this gripe with essentially every "modern" language
<companion_cube>
shakesoda: it's a question of culture
<pmwhite>
alehander92: yeah
<shakesoda>
it is a question of culture for sure.
<alehander92>
a friend of mine often talks to me about it, but i mostly read general stuff about it
<fengb>
Funny enough, Ruby didn’t have this problem
<shakesoda>
don't get me wrong, it's not like i want managing dependencies to suck
<companion_cube>
shakesoda: I read somewhere that C has a package manager, it's just priviledged enough that it's the OS's PM directly
<shakesoda>
but at the same time i'd take managing deps being terrible over ending up with some cargo or npm disaster
nycex has joined #zig
<shakesoda>
companion_cube: i go out of my way to avoid os package managers too.
<shakesoda>
since they're also all disasters
<companion_cube>
so, slackware or nothing? :s
<shakesoda>
heh, i just build my deps in-tree so i can have some consistency across platforms.
Akuli has joined #zig
<companion_cube>
well cargo lets you do that too 🤷
<companion_cube>
it's really a question of culture, not tools
<shakesoda>
my problem with cargo is more cultural, not tools
<gonz_>
As long as I can reasonably avoid other peoples' code it's not that big a deal if it turns into npm/cargo.
nycex has quit [Remote host closed the connection]
<shakesoda>
builds take foreeeeeever and that's just normal
<companion_cube>
cargo is good at its job, it's just that people use deep chains of dependencies
<shakesoda>
i agree
<companion_cube>
(more or less the same with npm/yarn)
<gonz_>
In JS unless you plan to reimplement everything everywhere you end up with a thousand 2-line packages in your repo.
<fengb>
npm is culturally the worst
<companion_cube>
but currently I'm doing a bit of rust with a core library that has 0 deps
<shakesoda>
it's more sane to just implement everything yourself in js anyways.
<fengb>
People love 2 liner repos
<companion_cube>
and then a wrapper around that has a few deps
<companion_cube>
pretty happy so far
<gonz_>
companion_cube: Right, I think Rust can still allow you to not have to pull in extra deps for basic stuff. JS doesn't feel the same way.
<companion_cube>
yeah, the rust stdlib is, imho, very good
<companion_cube>
it's not big, but it's very good
<shakesoda>
really i'm just strongly in the camp of bringing in only exactly the code you need, which largely means eliminating deps entirely to the degree possible and putting things in tree for consistency and maximum deletion etc
<shakesoda>
this is not very friendly for splitting things into libraries to begin with.
<pmwhite>
I don't think small packages are a bad thing. 2 lines is probably too small, but 100 lines is fine to me. I'd be fine if every file were considered it's own "package"
<companion_cube>
cargo vendor + features (a lot of packages allow you to disable their features that bring deps)
<fengb>
shakesoda: that's what npm was designed for. And that's also why there's a million 2 line packages
<companion_cube>
like, clap with `default-features=false` is pretty lightweight
<shakesoda>
a thing i really don't like that is universal to package managers being in the picture is that you have to untangle the messes they bring in :(
<shakesoda>
including if they are well designed
<shakesoda>
it can be quite a task just to figure out what the heck you even have brought in and how much needs to be disabled
<shakesoda>
such that most... don't.
<companion_cube>
if you follow the shiny and trendy, for sure
<fengb>
Well sure, but a well designed ecosystem never has a tangle in the first place
<companion_cube>
but, since it's mostly a question of culture, I'm not worried for Zig
<fengb>
Ruby typically doesn't have a crazy nest of deps
<fengb>
So it's solvable
<shakesoda>
such trust has to be earned
<companion_cube>
I think Zig's PM will not do transitive deps implicitly? (I'm way out of date)
<companion_cube>
so you'd be very aware of what you pull in anyway
<shakesoda>
well that's good
<ifreund>
i would be a fan of that. It'd be a good incentive to keep your dependency tree small
<gonz_>
The good news is that regardless of situation, Zig will be very appropriate for building fundamentals. If you hated dependencies in some languages you'd have to learn another just to make good fundamental libraries yourself.
<pixelherodev>
Morning all! :)
<afontain_>
damn I've been reading PM as Prime Minister for a few minutes
<ifreund>
I'm optimistic about the culture of Zig package management as well, I feel like many zig users come from C and have a more sane take on dependencies
<companion_cube>
yo pixelherodev
<afontain_>
"I read somewhere that C has a package manager, it's just priviledged enough that it's the OS's prime minister directly"
<companion_cube>
C has a more sane take because the tools have been terrible, imho, not because it magically has a better culture :p
<companion_cube>
afontain_: well on unix that's true :D
<shakesoda>
now if we can do better than c's build times, that would make me very happy
* shakesoda
is happy to see effort on this exact area
<leeward>
shakesoda: Do you mean C++'s build times?
<shakesoda>
lower memory usage during builds would be great too
<shakesoda>
i mean both.
<shakesoda>
but i do mean c
mondra has joined #zig
<leeward>
C's build times are not absurd. I've worked on multi-million line codebases that took a few minutes to build.
<shakesoda>
a few minutes is an insane build time
<shakesoda>
that's glacially slow
<companion_cube>
for millions of lines?
<leeward>
For 2 MLoC for a build from scratch?
<mondra>
compared too?
<gonz_>
There have historically been compilers that manage a million lines per second. I think most of us are just not attuned to the idea that most compilers are slow.
<afontain_>
to be honest, in my experience, C is much faster to build than zig
<shakesoda>
yes, c builds way faster than zig does right now
<companion_cube>
comptime will not help
<shakesoda>
mondra: most things that... aren't c, c++ or use llvm
<fengb>
I think our target is a million per second
<companion_cube>
shakesoda: I can only think of pascal for compiling that fast
<fengb>
Stage 1 compile times are not reflective of stage 2
<mondra>
most of stage 0's time is spend on llvm was it not?
<gonz_>
It's not unreasonable at all for a compiler that does very little optimization.
<leeward>
I'm not concerned with build times from scratch. 99% of the builds I do are after changing 1 or 2 files. As long as that can be fast, I'll be happy.
<companion_cube>
millions of locs/s… that's tough
<fengb>
Sorta. We also have not focused on performace in the C++
<shakesoda>
i'm concerned about all build times, especially on the old/weak machines i actually use.
<shakesoda>
and the amount of memory they use too
<companion_cube>
memory required for build is also a bigger concern to me
<leeward>
For what it's worth, that few minutes (3-5) was over NFS on SPARCs running SunOS.
<companion_cube>
cause the stakes are not "wait a bit more" but "you can't build that, sorry"
<shakesoda>
dodging build times is a huge reason i have massive amounts of code that i just jit or transpile to jit stuff
<shakesoda>
e.g. haxe->luajit
<mondra>
well an incremental compiler helps a lot with the 2 line change build times
<shakesoda>
incremental compilation is also still a workaround for the build being fundamentally slow, but yes it absolutely does.
<shakesoda>
i'd like waiting to be enough less painful that i'm willing to actually do it, instead of doing far more than needed with what is often the wrong tool for the job
<mondra>
a little C compiler I like using when I change a few lines in a big program is TCC, there are probably better options out there, but ye
<pixelherodev>
Regarding stage2 perf: there's a number of tricks already
<companion_cube>
it's all about debug build vs release build anyway
<pixelherodev>
e.g. the enums used to represent value types (and type types) and actually extern unions, which are either pointers to the real value or just a raw enum
nycex has joined #zig
<bgiannan>
hey there, so i'm trying to update a zig project i've not touched in 4 months. I have a weird issue with AutoHashMap which complains i'm not giving a comptime parameter and I'm not sure why/how: http://sprunge.us/2JOFqo
<pixelherodev>
Since the first page is unusable on most OSes, that gives 4096 types
<gonz_>
I personally don't mind waiting for release to take a while, but debug builds are painfully slow in lots of languages. You shouldn't have to wait seconds for some editor feedback, regardless of it waiting on a compiler.
<pixelherodev>
Which means we have specializations like u8_array_sentinel_0
nycex has quit [Client Quit]
<leeward>
bgiannan: comptime *Unit
nycex has joined #zig
<companion_cube>
full debug build can still take time because you output a ton of dwarf
<companion_cube>
gonz_: `cargo check` is the kind of thing that helps
<bgiannan>
leeward, i tried that and am still getting the same error
<mondra>
yeah, debug builds should absolutely be sanic speeds ;)
<pixelherodev>
companion_cube: what if you keep the DWARF in RAM only?
<companion_cube>
why generate it then? :D
<pixelherodev>
Or replace it with something else within the compiler, and have the compiler manage debug builds?
<leeward>
oh, wait, that doesn't make sense anyway
<pixelherodev>
The is, patch the debugger to talk to the incremental compiler
<companion_cube>
a language server shouldn't "build" at all
<pixelherodev>
Well, yeah. So?
<pixelherodev>
What's that got to do with anything?
<bgiannan>
leeward, zig is complaining about it deep into a stack of call where the parameter is everytime declared as comptime
<pixelherodev>
Dod I miss a bit of the convo?
<pixelherodev>
did*
<companion_cube>
I think it's just that "debug" builds are not the fast ones either
<fengb>
I'm hoping for a -O1 with the self-hosted backend
<pixelherodev>
shakesoda: I disagree that incremental compilation is just a "workaround"
<companion_cube>
there should be a "fast" build that does as little as possible to give you a binary
<fengb>
So I can actually test stuff
<shakesoda>
pixelherodev: it comes about as a direct result of the build being slow to do in full
<shakesoda>
i.e. it is a workaround
<shakesoda>
it's a useful one that i think is good to have in context here
<pixelherodev>
Yes, but it's still useful is the build is faster
<pixelherodev>
if*
<shakesoda>
but that doesn't change that it is a workaround
<leeward>
bgiannan: What's a Unit?
<shakesoda>
and hey if you're fast enough you can just jit... now there's something i want
<bgiannan>
leeward, `pub const Unit = struct { // a looot of stuff }`
<shakesoda>
zigjit
<mondra>
no
<shakesoda>
:D
<mondra>
X^R
<fengb>
comptime might become a jit :P
<shakesoda>
zig compile is so slow currently that it is utterly impractical to use it for my regular workflow on slow machines (where i can still reasonably enough use c)
<shakesoda>
a situation which should improve a lot with the ongoing work on this
<shakesoda>
very, very much looking forward
<mondra>
how is it comptime if it is jit?
<fengb>
comptime is an interpreter running inside the compiler
<fengb>
And it's balls slow right now
<companion_cube>
so, separate compilation for comptime? 🙃
<mondra>
I don't really see that as jit, but that might be my narrow definiton
<fengb>
It's not a jit right now; it's just an interpreter. But maybe it's worth jitting to speed it up
<mondra>
for me jit is a compiler living in the runtime
<shakesoda>
that's a definition issue here
<mondra>
yeah, because I'm all good with doing anything to speed-up comptime stuff, but no runtime jit'ting
<scientes>
mondra, that wouldn't be comptime, would it?
<mondra>
yeah, that's why I was confused xD
<shakesoda>
we're talking jitting as in compiling comptime stuff to machine code during the process instead of just interpreting it throughout
<scientes>
fengb, in order to compile it with llvm we need to teach llvm about slices, so that more stuff can be pure
<shakesoda>
nothing to do with runtimes
<pixelherodev>
Workaround shakesoda I mean
<mondra>
yeah, I get that now, it's about a jit in the compiler, not a jit in the runtime
<shakesoda>
but of course there's so much gains to be had long, long before doing that
<pixelherodev>
Whoops
<shakesoda>
pixelherodev: sorry there are no workarounds for shakesoda, i have looked
<scientes>
comptime is seriously limited
<pixelherodev>
shakesoda: I mean, I'm actually planning on trying to connect Tricarbon to Stage2 for a (potentially unofficial) comptime JIT
<fengb>
Then we'll be able to import the jit into the runtime and have a copy of the official Zig interpreter :P
<shakesoda>
will get back should i ever find one
<shakesoda>
;)
<pixelherodev>
lo
<pixelherodev>
l
<scientes>
even a fully interpreted comptime would be more featureful than what we have now
<scientes>
which doesn't even have a memory model
<fengb>
andrewrk has mentioned that current comptime is held together by duct tape
<scientes>
it is
<scientes>
it still is pretty awesome
<scientes>
as it is a first
<companion_cube>
not entirely, D was mostly there :p
<leeward>
^^
<companion_cube>
(the new aspect is that it's the only powerful construct in Zig, even for generics, imho)
<pixelherodev>
Is there really supposed to be a defined memory model?
<pixelherodev>
THat seems unnecessary for an interpreter
<shakesoda>
i find comptime stuff gets really crazy and i usually don't want to see it for more than basic type substitutions D:
<gonz_>
shakesoda: It's great for small strings representing data, though. Being able to write a simple thing that takes a string to something else and have it be properly checked, etc., is nice.
<gonz_>
Format strings being one of the good examples.
<shakesoda>
every now and then i'll screw up a format and get some kind of cryptic error message deep in the formatting code
<shakesoda>
and it is code i never, ever want to see
<shakesoda>
lol
<shakesoda>
also very much citation needed here but i recall that stuff also compiling into quite a mess, like it just doesn't optimize properly
<shakesoda>
i think that was formatted prints, but i don't remember now
<shakesoda>
not sure it matters a whole lot since prints are going to be slow as heck anyways
<fengb>
There's a lot of duplication when compiling format strings yes
<pixelherodev>
That's not fundamental though
<pixelherodev>
The optimizer should be able to deduplicate the output
<pixelherodev>
(Ideally)
<pixelherodev>
It's more akin to overagressive inlining, really
<pixelherodev>
In the sense that if you turn the inliner too high in e.g. GCC, you'd probably have the same issue
<pixelherodev>
Kinda funny that we have the reverse lol
<mondra>
is that in release or in debug mode tho?
<pixelherodev>
Both
<pixelherodev>
It's nothing to do with optimizations
<leeward>
bgiannan: I think it wants K to be comptime there, which means *Unit has to be comptime.
<pixelherodev>
(thogh it sticks around because we need to optimize it later on)
<fengb>
I don't think LLVM can detect the different generated functions as dupes
<pixelherodev>
Basically, formatters are generated at compile tiem
<pixelherodev>
time*
<fengb>
And Zig definitely doesn't at the moment
<pixelherodev>
each one is its own function
<leeward>
bgiannan: I'm not sure though, since my little toy example works.
<pixelherodev>
We need a Zig optimizer later to clean it up :P
<pixelherodev>
Or, better yet
<pixelherodev>
Tweak how comptime generation works instead
<pixelherodev>
Don't rely on something else to fix it down the line
<pixelherodev>
e.g. the actual codegen part itself should have a list of every permutation of a comptime function
<companion_cube>
the classic way of sharing code is by defining functions, so the compilation of format strings should generate functions
<companion_cube>
(without duplicates)
<pixelherodev>
Before ever generating asm / ZIR, it should - yeah exactly!
<pixelherodev>
It should find duplicate sections above a minimum threshold, and turn them into their own functions
<pixelherodev>
Sort of reverse-inlining
<companion_cube>
:D neat
<shakesoda>
i hope the zir stuff will have an -O1 or so to get at least a decent amount of performance before jumping to waiting eons for llvm
<pixelherodev>
This would let the actual inliner tackle it
<pixelherodev>
shakesoda: neither
<pixelherodev>
LLVM isn't going to be the official stage2 optimizer
<pixelherodev>
It's going to be an option, yes
<pixelherodev>
But we're also going to have our own optimizers
<shakesoda>
anything to spare me from waiting eons for llvm
<pixelherodev>
lol
<pixelherodev>
yeha
<pixelherodev>
yeah*
<pixelherodev>
anyways, I'mma get back to the stage2 compiler now
<pixelherodev>
I... somehow have WiFi up here. I never do.
* pixelherodev
shrugs
<pixelherodev>
Weird
<mondra>
as someone who isn't a compiler guru, why is llvm so insanely slow?
<pixelherodev>
Bloat.
<shakesoda>
because they do not give a crap about compile time
<pixelherodev>
^
<shakesoda>
it isn't even on the list of things they care about afaik
<pixelherodev>
They don't give a damn
<shakesoda>
they care about the output, but not the time it takes to do it
<fengb>
They've started a performance regression test suite just recently
<shakesoda>
oh that is excellent news
<mondra>
I see...
<fengb>
Back in mah day, LLVM was snappy 🦖
<shakesoda>
i will happily revise my statements if the trend reverses as a result
<leeward>
Also, it started life as a C++ compiler, which...well, C++ is not a thing that can be compiled quickly.
<mondra>
yeah, I've pretty much avoided since I got into programming because it just looks obfuscated to me (or it is basically C with classes) xD
<leeward>
bgiannan: Try to reduce your code to something like this: https://godbolt.org/z/Mx6fwr If you can find the part that makes it work, that's what's breaking it.
<leeward>
mondra: Avoiding C++ is a good thing to do if you can get away with it.
<shakesoda>
c++ is truly insane and convoluted
<shakesoda>
i have to deal with it for work and have to really push to keep anything straightforward
<leeward>
What's a decidable grammar?
<mondra>
leeward: lucky I can :)
<leeward>
Why would I need that?
<mondra>
I'm forced to use C# tho 0.0
<shakesoda>
that's more sane than c++ at least
<shakesoda>
even if i also don't like it
<shakesoda>
both c++ and c# utterly fail in the language simplicity department
<leeward>
The last time I used a language from MS it was VB6. I hear good things about C#.
<fengb>
I wish they called it something else. It's nothing like C >_>
<shakesoda>
fengb: well they couldn't call it what it is
<fengb>
J# or something
<fengb>
CoffeeSharp
<mondra>
J is an array programming language, no?
<ifreund>
do we have constants for e.g. u32 max value somewhere in the std?
<shakesoda>
isn't there an @ for that
<ifreund>
maybe
<afontain_>
std.limits?
<fengb>
`std.math.maxInt(u32)`
<shakesoda>
oh, std.math
<leeward>
I did play around with a Microsoft J++ thing that existed in the '90s. It...did not work.
<leeward>
Mix a little Al in, and you have thermite.
<mondra>
yeah, >Iron doesn't burn xD
stripedpajamas has joined #zig
* leeward
uses mercurial. hg transplant
<scientes>
saturating llvm intrinsics would be really nice to have
<fengb>
Iron burns at high enough temperatures
<scientes>
they are great for avoiding corner cases
<leeward>
fengb: Another way to say that is that iron fires are very hot.
<nephele>
Hellu, I would like to write a SCTP server in zig (later linking against whatever DTLS support there is), could someone point me to examples of SCTP in zig? (or maybe the zig tcp server example andrew wrote?)
cole-h has quit [Quit: Goodbye]
nycex has quit [Remote host closed the connection]
cole-h has joined #zig
nycex has joined #zig
waleee-cl has joined #zig
<gonz_>
It's not unlikely that you're the one writing the example
<ikskuh>
nephele: i have used BearSSL with zig, but haven't used DTLS
<ikskuh>
you may want to look up MasterQ32/zig-bearssl
<ikskuh>
on github
<ikskuh>
as a starting point
<nephele>
Ah, i don't know if bearssl supports dtls at all (their website lists it under not supported, but i dont know if that is accurate), I'll have a look at that package anyway, thanks :)
<ikskuh>
ah well, then it's not supported
<ikskuh>
BearSSL is really stripped down
<ikskuh>
i think you have to use something like LibreSSL or OpenSSL
<nephele>
Libressl does not support DTLS :D
<nephele>
I only know of OpenSSL and WolfSSL to support it
<ikskuh>
hm
<ikskuh>
i didn't get WolfSSL running with Zig
<ikskuh>
maybe you are more lucky with that
<nephele>
Well, wolfssl seems like the better choice of the two, but then wolfssl is gpl which i don't like that much, i suppose it's fine though, i can still dual license the wrapper and anything build with that wrapper would hardly be a "derivitive" of wolfssl :3
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
doublex has quit [Ping timeout: 240 seconds]
satchmo has quit [Ping timeout: 252 seconds]
doublex has joined #zig
<leeward>
Thank you, hg.sr.ht, for not being bitbucket.
ave_ has quit [Quit: Ping timeout (120 seconds)]
linuxgemini has quit [Quit: Ping timeout (120 seconds)]
doublex has quit [Ping timeout: 272 seconds]
lunamn has quit [Ping timeout: 260 seconds]
drewr has quit [Ping timeout: 258 seconds]
linuxgemini has joined #zig
lunamn has joined #zig
ave_ has joined #zig
<pixelherodev>
lol, yeah
<pixelherodev>
nephele: the question is whether the wrapper qualifies as a deriviative
<pixelherodev>
I'm not a lawyer, so I can't answer that
<nephele>
the wrapper probably does, yeah
<pixelherodev>
But the wrapper's license doesn't really matter, as long as you take care to keep it distinct from your application built over it
<pixelherodev>
andrewrk: is there a reason ZIR comparisons don't need a cross target?
<nephele>
but the gpl does not prevent me from licensing the code under a different license too, so i think i can license it MIT aswell, so if someone obtains a commercial license from wolfssl they can use the wrapper too under MIT anyhow :3
<andrewrk>
pixelherodev, integer comparisons?
<pixelherodev>
Ah wait, I see
<pixelherodev>
Nah, OutputComparisons
<pixelherodev>
because it has to run natively
<pixelherodev>
I think we should revamp that?
<pixelherodev>
Tests can e.g. require QEMU, and use QEMU to run the application
<pixelherodev>
QEMU-user mode
<pixelherodev>
nephele: it doesn't?
<pixelherodev>
That's... odd
<pixelherodev>
I mean, your code sure
<pixelherodev>
Ahhh I see
<pixelherodev>
If you license *your* wrapper under MIT, and someone has a license from the *original* author to use it w/o GPL, then they can use your deriviative work under those terms?
<pixelherodev>
That... I'd really check with a lawyer for that
<pixelherodev>
I think *you* would need a license from them to be able to do that
<pixelherodev>
but IANAL
<pixelherodev>
andrewrk: it's fine to require QEMU for some tests, right?
<pixelherodev>
if cross_target != native?
<pixelherodev>
(Or WINE, or WASI, or...)
<pixelherodev>
That's the last thing I need to check, them I'm offlining to finish this
<pixelherodev>
Pretty close to done :)
<nephele>
pixelherodev, well, that wouldn't be my problem, but whoever gets a commercial license from wolfssl ;), assuming anyone ever wants to use my potential wrapper xD
<andrewrk>
pixelherodev, there is an option, -Denable-qemu, that tells whether the tests have qemu available
<pixelherodev>
I mean, why not?
<pixelherodev>
andrewrk: gotcha
<fengb>
I don't know if reimplementing headers is fully tested in court
<pixelherodev>
It's not
<pixelherodev>
Oracle vs Google, right now
<fengb>
Linux has a specific out for this reason
<pixelherodev>
oof
<pixelherodev>
nephele: it kind of *is* your problem IIUC though
<pixelherodev>
*You* can't release a deriviative of WolfSSL under a license that's incompatible with GPL
<pixelherodev>
AFAIK
<nephele>
Not really, i don't have a license, for me the wrapper stays gplv2
<pixelherodev>
Right but
<nephele>
isn't it i can't /use/ it under a different license?
<fengb>
Yeah it gets tricky what's a derivative. Clean room is probably okay but it's not certain yet
<pixelherodev>
When you select a license, you're giving people the right to use your code in a certain manner
<nephele>
i still have the copyright to all my code, if i distribute it violating the gpl then i loose the right to use the wolfssl code
<pixelherodev>
in order to be able to give a right, you need to have it yourself
<pixelherodev>
Right, but I'm saying that distributing a deriviative work of a GPL project under non-GPL might be a GPL violation
<nephele>
but if someone else uses it and does not need to concern themselves with the gpl they should be able to use it under mit if i allow that :3
<pixelherodev>
Yes, but again
<pixelherodev>
The issue isn't them
<fengb>
But you must relicence under GPL if you're doing a derivative
<pixelherodev>
Legally, you have to use GPL
mondra has quit [Remote host closed the connection]
<pixelherodev>
not dual-license
<pixelherodev>
I would really really check with a lawyer first
<pixelherodev>
Or at least ask them
<fengb>
Yeah, only upstream can choose to dual license
<pixelherodev>
^
<pixelherodev>
You don't have the rights given by the MIT license, so you can't grant them to others AFAIK
<nephele>
Eh, that seems incredibly wierd
<pixelherodev>
How so?
<fengb>
No that's the whole purpose of GPL
<pixelherodev>
^
<nephele>
I do for my code :)
<fengb>
Forcing downstream to remain GPL
<pixelherodev>
Yes, but
<pixelherodev>
Not really
<nephele>
I don't have the right to use it under the non-gpl if i want to use the upstream code
<pixelherodev>
If your code is a deriviative of a GPL license, you don't legally have the right to relicense it
doublex has joined #zig
<pixelherodev>
Even your code qualifies here.
<nephele>
I legally have the right to license all my code
<pixelherodev>
Legally, your code *is* GPLed, and not by you
<fengb>
No, not if you use GPL
<fengb>
You don't own GPL code so you cannot relicense it
<nephele>
Nope, the gpl cant take away my right
<nephele>
it can only take away my right to use other gpl code
<pixelherodev>
Except that it's not about your right
<pixelherodev>
It's about *WolfSSL*'s
<pixelherodev>
Your code is considered to contain theirs, legally speaking
<pixelherodev>
Which means that you can't license your code in a way incompatible with their license
<nephele>
wolfssl has no way to force me to license my code, other than the threat that i /cant/ use wolfssl code anymore
<pixelherodev>
Seriously, *talk to a lawyer*.
<pixelherodev>
Don't make assumptions.
<fengb>
You cannot use WolfSSL without abiding to their terms. They can literally sue you for breaking the license
<pixelherodev>
^
<nephele>
There is no way the gpl can take away my copyright
<pixelherodev>
licensing your code in such a manner is *itself* a GPL violation
<pixelherodev>
yeah, there is.
<pixelherodev>
Because their copyright is affected too
<companion_cube>
nephele: it's called "viral" for a reason
<pixelherodev>
This is *literally* the point of copyleft licenses
<nephele>
A gpl violation would mean i loose my right to use the software :)
<fengb>
You can't derive work off GPL code and relicense it to something permissive
<pixelherodev>
No, it means you get taken to court.
<fengb>
That's the entire the point of GPL
<nephele>
Yes i can, aslong as i don't have the gpl part anymore
<pixelherodev>
It's the same way you can't relicense a fork
<pixelherodev>
nephele: only with LGPL
<pixelherodev>
Not GPL
<pixelherodev>
It applies to *all deriviative works*
<pixelherodev>
Like I said, you really need to talk to a lawyer and make sure this doesn't qualify
<pixelherodev>
I would *not* take that for granted.
<nephele>
no, not just with the lgpl, if i move my code over to use openssl instead of wolfssl for instance i still have all rights to relicense it
<pixelherodev>
Yes, but this is about a wrapper explicitly *for* WolfSSL, no?
<pixelherodev>
WolfSSL Zig bindings, effectively?
<pixelherodev>
Like I said, IANAL, but I would at least *talk to them* first
drewr has joined #zig
<nephele>
Well, primarily a way to use DTLS over SCTP in zig
<pixelherodev>
Let's say you're right and it's not a violation; what if *they* think it is?
<pixelherodev>
If they take you to court, it doesn't matter if you win
<pixelherodev>
It's still a giant hassle which could easily be avoided by just *talking to them*
<pixelherodev>
I doubt they'd have an objections to what you want to do
* pixelherodev
shrugs
<pixelherodev>
It's your project
<nephele>
I never said i plan to do that without talking to them :D
<pixelherodev>
Jsut my two cents
<pixelherodev>
Just*
<nephele>
anyhow, i'll just do my wrapper, which would be gplv2 then and deal with that later, assuming zig gets commercial interest :P
<nephele>
(or alternatively use openssl for dtls, but then openssl is openssl :3... i wonder if zig will build native DTLS heh)
<pixelherodev>
What's wrong with OpenSSL?
<ikskuh>
OpenSSL = 😱
<nephele>
the api is easy to misuse :/
<ikskuh>
it's a horrible API mess
<ikskuh>
way too easy to use wrong
<fengb>
What about LibreSSL?
<ikskuh>
they removed a lot of cruft from OpenSSL
<pixelherodev>
Ehh
<pixelherodev>
LibreSSL has had its own problems
<pixelherodev>
(security wise at least)
<pixelherodev>
Both of them have had issues that the other has not
<nephele>
mainly on linux :D
<pixelherodev>
I'd need a source for that :P
<nephele>
well, getting a prng on linux is somewhat harder than on openbsd, atleast the kernel one, since urandom can't be trusted, random sometimes blocks etc
<nephele>
I think there was somewhat of a problem for the getrandom syscall too, but not sure what it was, i think that it was to be changed to also behave wierdly (and its not on olderrrish linux kernels)
<pixelherodev>
uhh
<pixelherodev>
false.
<pixelherodev>
urandom can be trusted.
<pixelherodev>
It's a common misconception that it's not trustworthy
<pixelherodev>
gimme a sec to pull up the source
<ikskuh>
/dev/urandom is afaik getentry, whereas /dev/random is getrandom
<nephele>
no, it can't, it returns uninitialized prng data at boot
<pixelherodev>
It can't be trusted *at boot* is a different story
<pixelherodev>
For most uses, urandom is preferred over random
<pixelherodev>
there's probably a way to verify that it's initialized
<nephele>
name one case where random is preffered over urandom :D
<pixelherodev>
At boot?
<pixelherodev>
Since it blocks until... oh wait
<pixelherodev>
Yeah, no, that's a terrible idea
<pixelherodev>
Actually
<ikskuh>
how to slow down boot 101
<pixelherodev>
urandom doesn't return uninitialized data at boot on some systems, IIRC
<pixelherodev>
They store entropy between boots, or something?
<pixelherodev>
Not 100% on the details
<pixelherodev>
Vaguely remember seeing something like that
<fengb>
We should simply plug in a background radiation sensor directly into the kernel
<pixelherodev>
That might be a distro thing, though
<pixelherodev>
Not a Linux one
<nephele>
urandom on FreeBSD blocks till the pool is inialized and then never again, easy to use api :D, having to watch out not to use urandom on boot is a bit "eh"
doublex has quit [Ping timeout: 240 seconds]
<nephele>
systemd stores some entropy to seed the pool afaik
<nephele>
but it is a userspace thing so may not be available everywhere :3
<nephele>
I shall check if libressl supports dtls somewhat... hard to find docs about that (only vague mentions of it in the changelog somewhere... :g)
<pixelherodev>
Seriously, worth five minutes to read it :)
<sqwishy>
Hi! Is it possible to write something like `union { struct { x: i32, y: i32 }, struct { w: i32, h: i32 } }` using packed whatevers? It looks only possible if each struct has a member name
doublex has joined #zig
<fengb>
Yeah zig doesn't have nameless fields
<nephele>
pixelherodev, i think its a bit more complex than that, on some kernel versions they dont give exactly the same since they have seperate pools and such :3
<pixelherodev>
nephele: on any reasonably modern Linux system.
<pixelherodev>
I'm not talking about systems stuck on e.g. 3.x
<andrewrk>
I think stable debian is still on 3.16
<pixelherodev>
Notice the use of the word "reasonable" ;)
<pixelherodev>
I don't find myself very impressed with Debian, at all.
<andrewrk>
it's pretty bold to call stable debian unreasonable
<marler8997>
andrewrk, removing the requirement that lengths have to be exact will making the allocator simpler
<pixelherodev>
Debian stable goes to unreasonable lengths for stability
<andrewrk>
marler8997, yeah, and note that the higher level abstractions can still be built upon this proposed interface
<pixelherodev>
andrewrk: to paraphrase QBE, "70% of the stability with 10% of the age"
<marler8997>
this fits my 5151 proposal more closely as well
<pixelherodev>
Debian stable goes waaaaay beyond "stability" into the territory of stagnancy
<marler8997>
but will require some work to get that interface to work with current clients who expect the length to be exact
<nephele>
debian 8 was on 3.16 i think
<andrewrk>
the ArrayList use case would call the lower-level function which allows getting more bytes than requested, so that actually would improve ArrayList efficiency I believe
<marler8997>
it would
<andrewrk>
ok so you're on board with this?
<fengb>
I like returning larger buffers. It's been weird just pretending the buffer is smaller
<marler8997>
yeah
<marler8997>
it was something I already was thinking of
<andrewrk>
cool. if you have the motivation to do another pass on the branch, go for it, but also feel free to hand off if you are tired of it and want to move on to something else
<leeward>
I've been running Debian stable on web servers for almost 20 years. Rock solid is the only way to describe it. Meanwhile, I've been running unstable on my desktop for the same period.
<marler8997>
I'll get to work on it today
<fengb>
pixelherodev runs Gentoo so bleeding edge is his idea of stable ;)
<leeward>
It's got plenty of things going for it.
<leeward>
I went to school with some gentoo developers. I like being able to install a browser in less than 8 hours, but cool.
<andrewrk>
marler8997, I like that we won't be pointlessly passing alignment for reallocs. it's a nonsense use case to try to increase the alignment of something
<marler8997>
yeah that was a nice bonus
<pixelherodev>
fengb: lol
<marler8997>
however, this interface doesn't have a path to call C's realloc
<pixelherodev>
nah, I don't consider this stable
<pixelherodev>
At all
<pixelherodev>
But Linux kernel is on *5* right now.
<pixelherodev>
It's been around a looooong time
<pixelherodev>
and Debian is on *3*
<fengb>
I'm still running 2.4 >_>
* pixelherodev
makes a thinky face
<fengb>
(I'm not but those were the good old days)
<pixelherodev>
leeward: also
<pixelherodev>
for the record
<pixelherodev>
on my relatvely weak laptop, I can install qutebrowser in closer to *one* hour
<pixelherodev>
Or firefox in two minutes
<pixelherodev>
Gentoo has binary packages
<pixelherodev>
The official repos only have them for larrrrge stuff though
<pixelherodev>
Like FireFox, and LibreOffice
<pixelherodev>
Gentoo isn't a traditional distro, it's a *meta*-distribution
<pixelherodev>
You could build a fully binary distro using Gentoo
<andrewrk>
marler8997, hmmm. good point. maybe c_allocator could take advantage of malloc_usable_size ?
<pixelherodev>
All you have to do is set up mirrors, configure the distro how you want it (maybe replace emerge with alpine's apk for instance, set USE flags), and create an installer
mondra has joined #zig
<leeward>
pixelherodev: Sure, but you're living in the future. In 2004, Firefox was 8-10 hours.
<pixelherodev>
Binary packages ;)
<leeward>
And for what it's worth, my system is running a 5.4 kernel
<leeward>
Yeah, binary packages: not at all why people use gentoo.
<marler8997>
andrewrk, oh I've never heard of that, looks like that would alleviate not being able to call realloc
<pixelherodev>
leeward: I know
<leeward>
If I were up to date, I'd be on 5.6.14
<pixelherodev>
I wouldn't call that distro Gentoo, but if I were to make a distro, that's how I'd do it
<pixelherodev>
I'm on 5.6.15 rn :P
<fengb>
Wait, what's the blocker for realloc now?
<leeward>
Debian's a single point release behind Gentoo? Sounds pretty bleeding edge to me.
<andrewrk>
marler8997, I think it could be used heuristically. e.g. it would determine whether or not to call realloc. we'd still have to check realloc return value to see if it moved the ptr and in that case free it and return failure
<marler8997>
andrewrk, that's one way to do it, that's fine with me
<pixelherodev>
leeward: Debian stable?
<leeward>
Hells no
<pixelherodev>
Exactly
<leeward>
Who uses that on the desktop?
<andrewrk>
fengb, libc realloc can move the ptr. we can provide c_allocator with this interface, no problem, but if there was any efficiency in using realloc() rather than malloc()/memcpy()/free(), it would be lost
* pixelherodev
shrugs
<leeward>
Like who uses gentoo on servers?
<pixelherodev>
...
<leeward>
They're different things.
<pixelherodev>
uhh
<pixelherodev>
heh
<pixelherodev>
heh he
<pixelherodev>
Hi
<leeward>
Yeah, unless you're serving a web page I've heard of, you don't count.
<andrewrk>
well we have a handful of benchmarks now that will let us know what perf changes happend from messing with c_allocator :)
<fengb>
But can't we try resize first before doing a move+copy?
<marler8997>
fengb...nope
<leeward>
I mean, I've run a web server on a mac mini, but I wouldn't call it a good idea.
<marler8997>
c heap doesn't suppor tit
<fengb>
Ohhhh sorry, I was thinking the other direction (exporting malloc)
<pixelherodev>
`ssh pixelleefair
<pixelherodev>
leeward: fair
<pixelherodev>
whoops
<andrewrk>
fengb, right we can, but consider what happens if we end up having to do move+copy: realloc() -> does the work of allocating a block. damn the ptr moved. free() -> does the work of freeing it. malloc() -> a second time! memcpy() (second time)
<pixelherodev>
leeward: you *can* keep a stable Gentoo box though
<andrewrk>
oh and a second free()
<pixelherodev>
Even if's not the default
<pixelherodev>
andrewrk: what if we use heuristics?
<leeward>
Sure, and you can make Windows XP secure.
<pixelherodev>
"if size < x try reallocing?"
<pixelherodev>
no you can't
<pixelherodev>
you don't control the kernel, or the components
<pixelherodev>
Gentoo is only unstable if you make it so
<leeward>
Sure you can. Fill the USB ports with super glue and unplug the ethernet cable.
<pixelherodev>
That's.... very different
<andrewrk>
pixelherodev, that's why we would use malloc_usable_size
<pixelherodev>
Gentoo can be easily made stable
<pixelherodev>
andrewrk: gotcha
<pixelherodev>
was only hearing half the convo :P
<nephele>
leeward, how does that help against my wifi card :D
<pixelherodev>
remove it
<pixelherodev>
screwdriver
<leeward>
nephele: XP doesn't have drivers for your wifi card.
<nephele>
Ha, but it does :D
<leeward>
:P
<andrewrk>
I think what we learned from all this is that the libc malloc/realloc/free interface isn't quite low level enough. it's not quite the right primitives
<leeward>
andrewrk: sbrk?
<marler8997>
yeah
<marler8997>
c's heap is a bit cripped because of it
<andrewrk>
I would be OK with an optional reallocFn which is the same as resizeFn except the return value is Error![]u8 and it allows moving the pointer. a default implementation can be provided
<andrewrk>
then we would not need malloc_usable_size heuristics
<leeward>
The problem is that some allocators only want to support malloc and free.
mondra has left #zig [#zig]
<pixelherodev>
hence the default impl
<andrewrk>
leeward, why is that a problem?
<leeward>
I don't know, I remember there being some issues with some bits of Allocator not working when I tried hooking up one that didn't realloc.
<leeward>
I could be misremembering though.
<andrewrk>
if (new_len == 0) free() else if (new_len > old_len) return error.OutOfMemory else return ptr[0..new_len]
<leeward>
Yep, that looks familiar.
<leeward>
It just doesn't support actually shrinking.
<andrewrk>
that's fine though. the interface supports it, but the implementation doesn't have to
<leeward>
fine for implementors; misleading for users without good documentation
riba has joined #zig
drewr has quit [Quit: BLM]
<marler8997>
yeah an optional reallocFn could solve that issue
<marler8997>
something we could decide to add if needed
drewr has joined #zig
<leeward>
That would be cool.
doublex has quit [Ping timeout: 256 seconds]
doublex has joined #zig
jaredmm_ is now known as jaredmm
riba has quit [Ping timeout: 256 seconds]
<pixelherodev>
andrewrk: ready for a first look?
<pixelherodev>
I haven't bothered running tests yet
<pixelherodev>
I want to make sure the design is good before making sure the implementation is :)
<pixelherodev>
(that's also why only Transforms actually run right now, anything else would error.unimplemented; implementing those would be trivial, given the other three harnesses)
<pixelherodev>
Pushed to the PR
<gonz_>
Well done to everyone on Zig Showtime
<gonz_>
And well done to everyone else for being great as well :D
<pixelherodev>
:)
<pixelherodev>
Thanks :)
<pixelherodev>
(I'm in the latter group)
<pixelherodev>
I'm going to be a speaker on one soon though :)
<leeward>
Ok, this is a thing I've been trying to figure out for a while and today is the day it actually happens. I have a very simple project (zig init-lib) and I want to dump the test executable in the same directory as build.zig. What do I have to add? I don't see anything in LibExeObjStep that does it.
<pixelherodev>
output_dir
<leeward>
Nope, it's not there.
<pixelherodev>
?[]const u8
<pixelherodev>
yeah it is...
<pixelherodev>
I just saw it today
<pixelherodev>
Yeah
<pixelherodev>
Just checked again
<pixelherodev>
it's the first result for output_dir in std/build.zig
<leeward>
I just set main_tests.output_dir to "."
<pixelherodev>
That's relative.
<pixelherodev>
Try absolute
<pixelherodev>
My guess is it's not relative to the dir you think it is
<pixelherodev>
The tests don't run next to build.zig
<leeward>
just tried absolute
<pixelherodev>
build.zig doesn't, I mean
<leeward>
no joy
<leeward>
I meant the binary wasn't there, not the property :P
<pixelherodev>
setOutputDir
<pixelherodev>
Try that
<pixelherodev>
It duplicates the path
<pixelherodev>
Ahh
<pixelherodev>
and handles path separators
<pixelherodev>
step.setOutputDir(abs_path)
<leeward>
nope
<pixelherodev>
ugh
<pixelherodev>
THat's a bug, then.
<pixelherodev>
Unles it's not supported for tests?
<leeward>
Well, at least I feel okay with not having found it.
<pixelherodev>
I mean, you did find it, technically
<pixelherodev>
It just doesn't work
<pixelherodev>
:P
<leeward>
The crazy thing is I know it can be done. I've seen it.
<pixelherodev>
For tests?
<leeward>
I just don't remember where or how.
<pixelherodev>
Or for executables?
<pixelherodev>
try it with addExecutable and see if it behaves differentl
<pixelherodev>
differently*
<pixelherodev>
If so, ping me here and I'll investigate
<leeward>
Yeah, andrewrk gave me some magic argument to pass on the command line once when I was running Zig's test suite.
<pixelherodev>
I mean, yeah
<pixelherodev>
If you're invoking Zig directly, it probably handles it
<leeward>
It does behave differently with addExecutable. output_dir works fine there.
<pixelherodev>
I'm guessing the build system discards ooutput_dir for tests
<pixelherodev>
Gotcha
<pixelherodev>
Will investigate while I wait for Andrew's feedback on 5422 :)
<leeward>
fun times
craigo has joined #zig
<pixelherodev>
Should be straightforward to fix
<pixelherodev>
I have a good amount of experience with the build system by now :)
<pixelherodev>
which for the record
<pixelherodev>
we need a better name for
<pixelherodev>
ZBS is meh
<pixelherodev>
build.zig is too vague
<pixelherodev>
(It can refer to a specific project's build file)
<leeward>
take off every zig?
<pixelherodev>
toez?
<pixelherodev>
heh
<pixelherodev>
Zig Intelligent Generator
<pixelherodev>
lol
<leeward>
Not ambiguous at all.
<pixelherodev>
ZBS Build System
<pixelherodev>
Just to make it worse
<pixelherodev>
Ooh
<pixelherodev>
Buildz
<ikskuh>
bzr
<pixelherodev>
Simple
<ikskuh>
build.zig runner
<leeward>
where ZBS stands for Zag Build System?
<pixelherodev>
Zigbar?
<pixelherodev>
Zig BuildSystem Automated Runner
<leeward>
bzr: because the last program to have that name has failed so completely that we can just replace it.
<pixelherodev>
That's... hah
<pixelherodev>
I like that
<pixelherodev>
but no
<pixelherodev>
terrible idea
<pixelherodev>
I'm going with ZBS or buildz for now
<pixelherodev>
As long as you know what I'm talking about it's fine
<marler8997>
andrewrk, one modification, I think it would be better to have resizeFn just return usize instead of Error!usize
<pixelherodev>
I just don't like writing the whole thing out every time I talk about buildz
<pixelherodev>
marler8997: why's that? What if it fails?
<pixelherodev>
Ahh wait, I see
<pixelherodev>
The program shouldn't rely on it succeeding?
<pixelherodev>
Or, rather
<leeward>
Well if you have managed to actually grok the build system, feel free to write up a guide for the rest of us. It's pretty severely lacking in explanation that isn't example.
<marler8997>
well this is just the allocator interface, most programs wouldn't call it directly
<pixelherodev>
the size is idntical
<pixelherodev>
... hmm
<pixelherodev>
leeward: you know what, sure
<pixelherodev>
Give me ~20 minutes
<andrewrk>
marler8997, makes sense to me
<leeward>
\o/
<marler8997>
ok cool
<pixelherodev>
And I'll do a stream explaining the Zig Build System's internals?
<leeward>
I would watch that.
<pixelherodev>
Sure thing
<leeward>
Though probably not live.
<pixelherodev>
Let me just have tests use output_dir real quick
<pixelherodev>
PR incoming
<pixelherodev>
andrewrk: When you get a chance, thoughts on 5422 would be nice :)
<pixelherodev>
So i can finish implementing it :)
<andrewrk>
will look now
<pixelherodev>
Perfect
<pixelherodev>
:)
<pixelherodev>
... I was like, "why is build.zig showing up as blank?"
<pixelherodev>
Me: `kak kak lib/std/build.zig`
* pixelherodev
facepalms
<pixelherodev>
:P
<gonz_>
ifreund: Did you ever use XMonad?
<ikskuh>
kak => 💩
<leeward>
That's what I thought.
<ifreund>
gonz_: bounced off the haskell, though if I understand correctly it's basically dwm in haskell?
<gonz_>
AFAIK, yeah.
<pixelherodev>
lol
<pixelherodev>
kakoune
<pixelherodev>
:P
<pixelherodev>
and yes I know
<gonz_>
Though I'm not sure exactly how dwm handles active windows, etc.
<gonz_>
As far as I heard they're about the same. The complaint about not tiling automatically into a set layout seemed like it suggested something like XMonad
<leeward>
Hmm, urge to write zwm? No, X is awful.
<gonz_>
I started using XMonad before I learned Haskell. Wasn't long after, though. The config is still very easy to handle without much Haskell knowledge, IMO
<ifreund>
yeah, river implements the default tiling layout of dwm
<ifreund>
which afaik is also the default for xmonad
<leeward>
I used xmonad on a laptop for a while. It was ok, but...I like fluxbox.
<leeward>
also wmii, but it's too crashy
<ifreund>
yeah, but to tweak it you need more and more haskell :D
<companion_cube>
i3 is top-notch
<ifreund>
i disagree, but it seems that many think that
<gonz_>
I dunno, Haskell in such a small context is very simple.
<ikskuh>
companion_cube: @as(i3, +1)
<gonz_>
Creating bigger things in Haskell and bringing in type-astronaut stuff is where it fails.
<gonz_>
Or where it's more likely to fail, at the very least.
<pixelherodev>
leeward: Found it :D
<pixelherodev>
companion_cube: sway is better IMO :)
<leeward>
pixelherodev: \o/
<pixelherodev>
Yeah, it's pretty simple
<pixelherodev>
There's an if (isTest) branch in LibExeObjStep.make
<pixelherodev>
the output dir is set *jusssst* after it
<companion_cube>
ifreund: I like i3 with a vanilla config, I should specify
<pixelherodev>
Here's the thing
<companion_cube>
(or almost vanilla)
<pixelherodev>
I have *no idea* what the output name will be
<pixelherodev>
It might be test
<pixelherodev>
It might be based on the file
<pixelherodev>
i didn't check :P
<pixelherodev>
Basically, for non-tests, it executes with the builder, then copies the produced file
<pixelherodev>
What I'm going to do here is add an `install` flag for test steps
<andrewrk>
@memset to undefined is a no-op in unsafe build modes. in safe build modes, it sets all the bytes to 0xaa, and if valgrind integration is enabled (which is the default when available and debug mode), it also makes a valgrind client request to note that the entire range is undefined
<marler8997>
I think it would be easy to make it a separate change, don't know for sure though
<andrewrk>
doing the valgrind client request is much slower if you do it for each byte independently
<andrewrk>
up to you
<marler8997>
ok
slowtype1 has quit [Ping timeout: 264 seconds]
sacredbirdman has joined #zig
ur5us has joined #zig
<xackus>
why are the std lib docs so outdated?
<pixelherodev>
They're from 0.6, I assume?
<xackus>
i'm looking at master
<pixelherodev>
Is there docs for the master branch?
<pixelherodev>
wlrobs is what I have installed right now
<pixelherodev>
and it, well
<pixelherodev>
segfaults occasionally
<pixelherodev>
randomly
<pixelherodev>
without pattern :P
<pixelherodev>
At least, in the scpy backend
<pixelherodev>
I'd need an OBS fork to try the dmabuf one
<pixelherodev>
I'll try txproto in the future, but for now, just installing feh
<pixelherodev>
because I know it's stupid, but it feels so weird having a blank background
<pixelherodev>
Just about done though, so it'll only be a minute :P
<pixelherodev>
companion_cube: yes, it is
<ifreund>
my background has been blank since i started using tiling window managers
<pixelherodev>
but it's currently the present
<pixelherodev>
:P
<pixelherodev>
Wayland is better than X11 because there is no "The wayland server"
<pixelherodev>
Whereas there's noly one real X11 server
<pixelherodev>
Okay, starting momentarily
<ifreund>
i don't buy into the transparent terminal emulator bs so there's not really a point if it will never be seen
<pixelherodev>
I'm not using CRT anymore
<pixelherodev>
don't worry
opDispatch has quit [Ping timeout: 256 seconds]
B4s1l3 has joined #zig
<pixelherodev>
I just like having a background?
<companion_cube>
pixelherodev: that's a bit of a weak arg, but ok :D
<pixelherodev>
It doesn't cost me anything
<companion_cube>
I was a bit trolling anyway
<sacredbirdman>
zig compiler terminates unexpectedly.. how do I find out why :P
<ifreund>
sacredbirdman: do you get a stack trace?
<pixelherodev>
sacredbirdman: depends. If you want to fix it yourself, I can help talk you through it later, otherwise, report it to the mailing list or github issues
<pixelherodev>
If it has the Tricarbon video it's me :P
* pixelherodev
facepalms
<pixelherodev>
delay for a minute
<pixelherodev>
spammer in a discord channel I mod
<pixelherodev>
need to sign in to the client :P
stripedpajamas has quit [Quit: sleeping...]
stripedpajamas has joined #zig
stripedpajamas has quit [Client Quit]
<pixelherodev>
whelp, here goes nothing
<leeward>
twitch still says offline, fwiw
Akuli has quit [Quit: Leaving]
<pixelherodev>
I know
<pixelherodev>
Had to refill tea real quick :P
alexnask has joined #zig
<ifreund>
i can't wait to learn how the ZBS works
<companion_cube>
you could stream the tea
<companion_cube>
just like andrew does
<pixelherodev>
:P
<ifreund>
i think i already use it pretty effectively, but i got to my current build.zig by cargo-culting/trial and error
<pixelherodev>
Anyways, good to go now
<pixelherodev>
Finally
<pixelherodev>
Just removing wayland plugin
<pixelherodev>
jic
<pixelherodev>
ten seconds probs
<alexnask>
Just read build.zig /s
<pixelherodev>
That's my goto advice
<pixelherodev>
Figured I'd explain it better though
<pixelherodev>
Reading the code is the second-best teach
<pixelherodev>
er*
<pixelherodev>
Experience is the best
<ifreund>
yeah i read a little bit, but build.zig is long
<pixelherodev>
Okay, starting now
<ifreund>
for real for real?
<pixelherodev>
Okay yeah
<ifreund>
music, nice
<alexnask>
hi mom
<alexnask>
Oh you tabbed out :(
<ifreund>
pixelherodev: audio is kinda fuzzy
stripedpajamas has joined #zig
<gonz_>
How good is zig-lsp generally?
<ifreund>
zls is quite good is that what you mean?
<gonz_>
Someone complained about it gobbling up memory or something a while ago. Is it a reasonably good experience most of the time and is it trending upwards?
<gonz_>
zls, yeah.
<ifreund>
strong upward trend yeah
<ifreund>
and it's quite useful already, though you probably want to update daily to stay on top of the development
<gonz_>
Mhm
<fengb>
Bleeding edge, just like the language
<gonz_>
This I sort of expect anyway, it's the usual routine with zig
<gonz_>
Only way to find the edges is to use it, I suppose
<gonz_>
Though I have to say, Zig isn't particularly hard without super advanced tools.
<ifreund>
no, it really isnt
<ifreund>
most valueable thing for me is goto-definition and completions for the std i think
<gonz_>
I like the completion in general for discoverability, yeah.
<pixelherodev>
...
<pixelherodev>
ifreund: did I leave my music running? :P
<pixelherodev>
gonz_: it was I
<pixelherodev>
I complained about memory usage.
<fengb>
But we don't have goto 🤔
<pixelherodev>
As the complainer:
<pixelherodev>
ZLS is awesome.
<ifreund>
pixelherodev: nah, just for the first minute
<pixelherodev>
it was more an issue on my end, I'm 99% sure
<pixelherodev>
ifreund: ahh, gotcha
<pixelherodev>
leeward: patched :D
<pixelherodev>
#5514
<pixelherodev>
;)
<pixelherodev>
Was more than I expected, needed to patch stage1 2
<pixelherodev>
Sorry, I mean, stage1 too
<pixelherodev>
:P
xackus has quit [Ping timeout: 256 seconds]
_Vi has quit [Ping timeout: 256 seconds]
recombinant has quit [Quit: Leaving]
dermetfan has quit [Ping timeout: 246 seconds]
sacredbirdman has quit [Remote host closed the connection]