<ronsor>
I already have tons of plugins and hacks installed on the regular discord client
<ronsor>
probably not gonna change that
<pixelherodev>
ronsor: I don't disagree wrt perf
<pixelherodev>
I disagree that this is worth the trade
<pixelherodev>
What's the advantage here?
<pixelherodev>
A higher degree of cross-platform compatibility?
<ronsor>
code portability is #1
<pixelherodev>
IMO that's not the way to go about it
<pixelherodev>
WASM is an *ISA*
<pixelherodev>
I'm working on an IR-based solution
<pixelherodev>
Probably using e.g. QBE
<pixelherodev>
(Not actual QBE, but something heavily based on it with an emphasis on portability)
<pixelherodev>
The idea is to have a compiler spit out the IR, then have systems finish compilation as part of the install process
<pixelherodev>
This results in similar compatility gains *without* the performance cost
<pixelherodev>
This in fact ends up being *faster* than native code currently
<ronsor>
could probably be more performant
<pixelherodev>
Since it allows -march=native to use
<pixelherodev>
be used*
<ronsor>
yeah
<ronsor>
truly native optimizations
<ronsor>
that idea kinda reminds of TinyCC
<pixelherodev>
It basically shifts the compiler backend to the install process, leaving only the frontend and generic optimizations for the release process
<pixelherodev>
Best part is it should be 100% compatible with existing kernels
<pixelherodev>
No kernel-space tricks needed
<pixelherodev>
e.g. you could make a Linux distro, or patch FreeBSD to support htis
<pixelherodev>
this*
<ronsor>
If you make it, I'll add support
<pixelherodev>
?
<pixelherodev>
To what?
<ronsor>
my OS
<ifreund>
heh, the programs would be double-portable
<pixelherodev>
Ahhhh
<alexnask[m]>
Snektron: 👋
<pixelherodev>
This would really just be a specialized package manager
<pixelherodev>
Hell, I could probably make it a Gentoo repo
<pixelherodev>
overlay*
<pixelherodev>
Have the server preprocess ebuilds as part of CI, producing IR
<pixelherodev>
On `emerge`, it only has to finish compilation from IR -> native
Snektron has left #zig ["User left"]
<pixelherodev>
... Hell, I could have a proof-of-concept *really* quickly using LLVM as a test
<ronsor>
On the IR, you mention emphasizing portability. How are you going to handle things like sizeof()?
<fengb>
Snek killed snek
<pixelherodev>
One option is to produce per-architecture IR, then deduplicate it
<pixelherodev>
So you have a common base file, plus per-architecture `diff`s to apply
<pixelherodev>
But this is still POC
<ronsor>
may not even need per-architecture
<pixelherodev>
Real portability would come from a better IR
<pixelherodev>
Not LLVM
<ronsor>
possibly just 32-bit/64-bit
<pixelherodev>
LLVM would be the proof-of-concept stage
<pixelherodev>
ronsor: not quite
<pixelherodev>
alignment is an issue also
<ronsor>
alignment is usually the pointer/register size AFAIK
blinghound has quit [Remote host closed the connection]
Snektron has joined #zig
azarus_ has quit [Ping timeout: 256 seconds]
azarus has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<pixelherodev>
ronsor: not qutie.
<pixelherodev>
quite*
<pixelherodev>
RISC-V mandates two-byte alignment for all functions; Intel CPUs work best with 32 *byte* alignments for functions; etc
<ronsor>
I didn't know that
ur5us has joined #zig
<gruebite>
is there any way to save comptime type information to be used at runtime? i'm sending a pointer (could be any zig type) to C, and when I get it back I'd like to get the declarations back
<pixelherodev>
Probably
<ronsor>
I don't *think* there's a builtin function for that, but you could write one
<ronsor>
@typeInfo should make that easy
heitzmann has quit [Read error: Connection reset by peer]
heitzmann has joined #zig
<andrewrk>
gruebite, zig doesn't provide you runtime type information, but you can expose that information to yourself via comptime code
<daurnimator>
andrewrk: is there a good pattern for mapping types to some sort of id?
<daurnimator>
I guess comptimehashmap?
<daurnimator>
or is e.g. @typeName guaranteed to be unique?
<andrewrk>
I know it's not a direct answer to your question, but I think that's a smell, trying to get a type id at runtime
<daurnimator>
true. can probably rethink of a way to do it at comptime
<daurnimator>
one thing I've been meaning to propose/write is an argument to e.g. std.json.parse where you provide per-type overrides
<daurnimator>
e.g. "when parsing into a `Foo` for *this* parse operation, do X instead of Y"
<daurnimator>
this would allow people to specify how to parse into a Foo without modifying Foo to have a jsonParse method.
<andrewrk>
makes sense to me
<alexnask[m]>
You can do this wth a comptime closure
<daurnimator>
the problem I hit last time I tried this was how to mass that is as an option
<daurnimator>
*pass
<daurnimator>
at the moment `ParseOptions` isn't comptime-known I think?
<alexnask[m]>
I wouldnt recommend this but its possible
<alexnask[m]>
(similarly you could copy some type info instead of keeping a counter, take back a runtime usize and return the runtime type info struct that corresponds to the index)
waleee-cl has quit [Quit: Connection closed for inactivity]
epmills has joined #zig
<epmills>
howdy, all.
<ronsor>
hey
<epmills>
using the latest master and unable to cross-compile to windows from macos...
<epmills>
...complaining on: const stdout = std.io.getStdOut().writer();
<epmills>
error: unable to evaluate constant expression
<epmills>
.x86_64 => asm volatile (
<epmills>
known issue? unable to locate in issues list.
<epmills>
fwiw, this builds fine: std.debug.warn("\n", .{});
<andrewrk>
epmills, hmm did you perhaps put the stdout as a global and not a local variable? on windows getStdOut() has to do something at runtime
<epmills>
andrewrk: that was it. i'd declared it above main. moving it into main fixed. thx for the insight - live 'n learn.
<andrewrk>
np
epmills has quit [Quit: Leaving...]
cole-h has joined #zig
cole-h has quit [Quit: Goodbye]
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
welp, caught at least one regression in llvm 11
<andrewrk>
oof found another one
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
<Nypsie[m]>
Rewatching the last stream. That incremental compilation is really really neat
<andrewrk>
:)
<andrewrk>
oh shoot I still didn't go over ifreund's wasm design thing
Ristovski has quit [Quit: 0]
[Ristovski] has joined #zig
<ifreund>
andrewrk: I'm a little confused, decls are toplevel things like functions or globals right?
<ifreund>
the types section only lists function signatures, which currently are the only types in wasm that can be user defined
<ifreund>
you are totally right that we can use unreferenced types for padding and wrap the section in an allocator-like interface
<ifreund>
and yeah I haven't give all that much thought to multi-threaded friendliness
ur5us has joined #zig
<ifreund>
so I think each decl has either 0 or 1 entry in the types section
<scientes>
wow, FPGAs are desperately in need of higher level languages
frett27 has joined #zig
waleee-cl has joined #zig
<andrewrk>
ifreund, yes decls are toplevel things like functions or globals. it's also the unit of memory lifetimes in stage2. each decl has an arena where all the allocations go that are related to analysing the decl
<andrewrk>
point being the operations the incremental compiler needs to be able to handle is: add a new Decl, update an existing Decl, delete a Decl
<andrewrk>
so it will be the most straightforward if you organize the binary file data in accordance with those operations
<andrewrk>
good night
<ifreund>
makes sense, I think my plans may have suffered a little from lack of familiarity with the rest of the stage2 codebase
<ifreund>
night!
frett27 has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
[Ristovski] is now known as Ristovski
gazler has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
stalli has joined #zig
<gonz_>
Fuck. I think I exactly missed the window of Zig & zls versions that work together.
<gonz_>
zls master seems to fail with a zig compiler error
<Nypsie[m]>
What compiler error do you get? I don't see any changes that could break it
<gonz_>
Zig also outputs a `NUL` file into the directory which is very cumbersome to remove :/
<gonz_>
I picked a really catastrophic release to do this with
<ifreund>
oh fun
<Nypsie[m]>
Oh wew
waleee-cl has quit [Quit: Connection closed for inactivity]
craigo has quit [Ping timeout: 246 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
decentpenguin has quit [Ping timeout: 264 seconds]
antaoiseach has joined #zig
<antaoiseach>
Hey guys, I have a pretty basic question, but one that has been gnawing away at me for a while
<antaoiseach>
Suppose I am designing an API that wants to consume strings (I know we don't really have a proper string type yet), and I want to support the maximum range of operations on it
<antaoiseach>
I'm wondering which would be the best signature for a string input in that case? []const u8 ? *[]const u8 ? *[] u8? [] u8 ?
<antaoiseach>
In some of these cases, I can pass in a static string like "foo", for others I will have to use "foo"[0..] etc.
<ikskuh>
[]const u8
<ifreund>
well, it totally depends on what the function does
<antaoiseach>
I want to allow the greatest flexibility in input
<ikskuh>
if you don't want mutable data (no write-back)
<ikskuh>
and []u8 when you want writeback
<ikskuh>
resizing is not possible in both cases
<ifreund>
but yeah, in unless you want to mutate the string passed to you, []const u8
<ikskuh>
antaoiseach: what do you mean by "flexibility"?
<antaoiseach>
say I want possibly mutation, and will take care of the invariants even if I don't mutate it
<ikskuh>
your algorithm either mutates the data or it does not
<ikskuh>
if it does mutate the data: []u8
<ikskuh>
if it does not: []const u8
<antaoiseach>
ikskuh: to be more precise, say I have var foo = "hello", and const foo = "world" and I also want to pass in "hello, world" to the function directly along with foo and bar
<ikskuh>
that's all "non-mutable data"
<antaoiseach>
and make it so that the user does not have to do anything special with the input - &foo or foo[0..] etc.
<ikskuh>
it's all []const u8
<ikskuh>
if you don't mutate the data in the algorithm, use a non-mutable slcie
<ikskuh>
*slice
<ikskuh>
everything else is less flexible
<ifreund>
string literals have type [:0]const u8 if you're not aware
<ikskuh>
ifreund: not correct!
<antaoiseach>
ikskuh: ifreund: thanks for the inputs ... sort of goes back to my original choice of [] const u8 I suppose, but I had some irksome user-experience cases ...
<ifreund>
ikskuh: what???
<ikskuh>
string literals have the type "*const [_:0]u8"
<ikskuh>
which coerce to []const u8
<antaoiseach>
this part is where Zig seems to be getting a bit all over the place
<ifreund>
urgh yeah and that coreces to what I said
<antaoiseach>
not very clean :(
<ikskuh>
antaoiseach: zig has the most clean pointer experience i ever used
<ifreund>
^
<ikskuh>
you probably didn't grasp a concept of zig yet ;)
<ikskuh>
which forced you to work around certain (reasonable) limitations in the type system
<ikskuh>
but string literals are const-pointer-to-array-of-u8
<ifreund>
which coreces to a bunch of things including []const u8, [:0]const u8, and [*:0]const u8
<ikskuh>
oh yeah, i forgot the 0 terminator…
<ikskuh>
sorry
<ifreund>
in C you have only a single pointer type and have to "just know" that your pointer happens to be a pointer to one item or a null terminated string or whatever
<antaoiseach>
Okay, having the type []const u8 copies the argument, right? So if I make the argument type *[]const u8, then why can't I do foo(&"hello")?
<ifreund>
zig brings necessary granularity to pointer types, which greatly increases type safety
<ifreund>
[]const u8 is a slice
<ifreund>
a slice is a pointer + a length
<ifreund>
the data being pointed to is not copied when you pass a slice
<antaoiseach>
So, if I wanted a pointer type for the arg and wanted to pass in a static string, how would the signature look like?
<ifreund>
a slice is a pointer type
<ifreund>
what's your goal here?
<ifreund>
you can think of a []const u8 as a struct { ptr: [*]const u8, len: usize }
<ikskuh>
(you are even allowed to access and change .ptr and .len!)
<ikskuh>
antaoiseach: if you pass a pointer to a slice, that would roughly be "char ** slice_ptr" in C
<antaoiseach>
Okay, let me present a use-case like so. In Rust, if I have an API like so: fn foo(s: &[u8]), then I can call it like so: foo(b"hello");
<antaoiseach>
or like let message = [b'w', b'o', b'r', b'l', b'd'];
<antaoiseach>
foo(&message);
<antaoiseach>
or even like let mut another_message = [b'w', b'o', b'w']; foo(&another_message);
<ikskuh>
that's all "[]const u8"
<ifreund>
^
<ifreund>
const message = [_]u8{ "a", "b", "c" };
<ifreund>
could also be var no problem
<antaoiseach>
and if I wanted to modify it then I would need to use []u8 instead, right?
<ikskuh>
yes
<ifreund>
and then you pass it with foo(&message)
<ikskuh>
that would be a "mut" slice in rust
<antaoiseach>
Okay, so I would not be able to pass in something like "baz" in that case, right?
<antaoiseach>
since that would remove the constness?
<ifreund>
right, literals are const
<antaoiseach>
Okay, thank you guys, ikskuh and ifreund ... this has been a very useful session for me. Cheers!
antaoiseach has quit [Quit: leaving]
<ifreund>
hmm, does var x = "foo".*; give you a mutable array on the stack?
<fengb>
Yep
<ifreund>
nice
<ikskuh>
yep
haliucinas has quit [Quit: leaving]
euandreh has quit [Ping timeout: 272 seconds]
haliucinas has joined #zig
wilsonk has quit [Ping timeout: 264 seconds]
wilsonk has joined #zig
xackus_ has joined #zig
dddddd has quit [Remote host closed the connection]
dddddd has joined #zig
<ikskuh>
hey
<ikskuh>
how i can i check if a std.fs.Dir is the root directory?
<ikskuh>
i would like to find build.zig in the current project tree similar to git finds .git or zig build finds build.zig
<ifreund>
probably just traverse up until you find the file/dir indicating the root no?
<ifreund>
could also look how zig finds build.zig
<ikskuh>
<ifreund> probably just traverse up until you find the file/dir indicating the root no?
<ikskuh>
i don't see a possibility to check for this with the current API
cole-h has joined #zig
<ifreund>
uh, itereate over the contents of the dir and compare name/type of each item?
<ikskuh>
and how do i find out if i'm at the root dir?
<ifreund>
look for a build.zig file or .git file?
<ifreund>
.git dir I mean
<ikskuh>
yeah
<ikskuh>
that's not the problem ;)
<ikskuh>
the problem is finding "/"
<ikskuh>
the end
<ifreund>
oh, / doesn't contain a ..
<ikskuh>
it does D
<ifreund>
if you have a ./.. dir, you can traverse upwards
<ikskuh>
[felix@denkplatte-v2 ~]$ ls /../../../
<ikskuh>
bin dev etc
<ifreund>
what is this madness
<ikskuh>
OS
<ikskuh>
main.cpp does it by path manipulation, not by using directory handles
<ifreund>
maybe that's the way do do it
<Nypsie[m]>
The way I solved it in my Git implementation is by traversing up and using std.fs.path to check the current directory. I hold a count if I pass the same dir twice (means I entered root?)
<ifreund>
i was just about to say that
<ifreund>
/../../ will be the same fd as /
rzezeski has quit [Quit: Connection closed for inactivity]
euandreh has joined #zig
LanceThePants has quit [Quit: Leaving]
sawzall has joined #zig
dermetfan has joined #zig
<andrewrk>
ifreund, is there some way I can help with #5985 ? want me to go over your other sections ideas and give feedback?
KoljaKube has joined #zig
<ifreund>
andrewrk: Would definitely appreciate more feedback on #5985. I haven't had time to make more progress on it yet today but plan to sit down this evening for another round of planning, possibly sketching out an implementation
<andrewrk>
ok you got it
<ifreund>
I think that overall I need to tie things more closely to the lifetime of decls
<ifreund>
We may actually be able to treat most of the sections as allocatable memory, it seems like that might be good pattern to follow
<ifreund>
it gets a little weird in the details of the restrictions on the padding, but it should be workable
wootehfoot has joined #zig
<andrewrk>
that sounds about right
FireFox317 has joined #zig
linuxgemini has quit [Quit: Ping timeout (120 seconds)]
isolier has quit [Quit: Ping timeout (120 seconds)]
isolier has joined #zig
linuxgemini has joined #zig
<protheory8-new-m>
Hi everyone, so when will Zig become popular?
<ikskuh>
i think zig is quite popular for its current state
<Nypsie[m]>
I asked my crystal ball; the answer is 5
<Nypsie[m]>
Jokes aside, I think there's quite a nice community going already.
<fengb>
I’m happy where Zig is right now. Not too overhyped :P
<ikskuh>
^= this
<Nypsie[m]>
Seen quite some comments of people who said they're coming back in a few years when it hits 1.0, so possibly that brings in alot more 'popularity' for w/e that may mean :P
<protheory8-new-m>
Yeah, I don't develop anything in Zig right now anyway
<protheory8-new-m>
Only made one library
<andrewrk>
it's popular enough that we have some income to fund development. but not too popular that it's falling over its own weight
<companion_cube>
besides, a lot of people won't have/see a usecase for it
<ikskuh>
yeah i think community momemtum right now is near-perfect
<andrewrk>
a big milestone is going to be fast compilation + package manager working well
<ikskuh>
yeah
<andrewrk>
I think we'll see an explosion in the community growth at that point
<ikskuh>
also the syntax finalizations
<ifreund>
#1717 is still looming :D
<ikskuh>
when we can rely on zig that our code won't break because someone found out that "a" is better than "b" :D
<ifreund>
I mean that won't really happen until 1.0
<ikskuh>
well, syntax and semantics are quite different things
<ifreund>
zig is already good enough to build real software with
<ikskuh>
finalizing the syntax is probably a good first step for the spec though
<andrewrk>
we should be able to get the planned syntax changes all done by 0.8.0 I think
<ifreund>
nice
<ikskuh>
\o/
<andrewrk>
(not the upcoming 0.7.0)
<ikskuh>
andrewrk: btw, i wanted to ask it on the last showtime, but i think the question didn't get through:
<ikskuh>
i heard rumors that you don't like #1717 personally, but you still accepted the proposal. why?
<andrewrk>
it's consistent with the rest of the language
<ifreund>
I see it as anon functions are a thing we want, and "one way do things" is important
<ifreund>
#1717 follows naturally
<companion_cube>
are functions really first-class though?
<ikskuh>
yeah, i think they are
<ikskuh>
but you don't have runtime closures
<companion_cube>
closures would be truly first-class, but functions, imho, are special because they can only be toplevel
<ikskuh>
ifreund: same thoughts on that
<ikskuh>
companion_cube: they don't have to be toplevel atm
<ikskuh>
with #1717 they won't even need a helper struct anymore
<companion_cube>
honestly, without closures it's hard to do anything functional :p
<ikskuh>
companion_cube: i still think we can make awesome closures with #1717 and comptime
<ikskuh>
a bit more explicit than in c++, but still with the same feature level
<protheory8-new-m>
Is Jemalloc actually faster than C allocator? I tried to benchmark them, it's seems like it was slightly faster, but I'm not sure if my benchmark is even good.
<companion_cube>
closures would be structs, not functions, ikskuh
<companion_cube>
I mean, I can't see how they'd be functions
<philtor>
heh... just investigating zig and was going to ask about closures.
<companion_cube>
protheory8-new-m: depends on your OS' malloc
<protheory8-new-m>
Assuming Linux with glibc and GNU userland in general
<ikskuh>
companion_cube: closures are a combination of struct and function... so ;)
<ikskuh>
in the end, it does only matter in language theory, but the code that will be executed is the same
<fengb>
C allocator is just an interface. Some OSs like FreeBSD use jemalloc
<companion_cube>
ikskuh: so I'm not sure how #1717 is relevant
<fengb>
s/OSs/libcs/
<ikskuh>
companion_cube: it makes the language more consistent
<ikskuh>
less cluttered with struct { fn x() void { } }.x
<companion_cube>
hu, in what way?
<ikskuh>
you just write fn() void { }
<ikskuh>
instead of that thing
<companion_cube>
ah, for anonymous functions?
<ikskuh>
a lot of zig already uses function pointers
<ikskuh>
yep
<ikskuh>
implementing interfaces will be nice as well
<protheory8-new-m>
fengb: glibc
<companion_cube>
I thought you were talking about toplevel declarations
<ikskuh>
i'm talking about #1717 in general ;)
<ikskuh>
as you can init your interface impls directly in the instantiation of the vtable instead of introducing functions for wrapping
<companion_cube>
I think I like the distinction between functions and closures that rust makes :s
<companion_cube>
it's very clear what's a function in it
<philtor>
it looks like #1717 has been accepted?
<ikskuh>
i think zig will be super-clear as well
<ikskuh>
philtor: a long time ago
* ikskuh
is waiting for ages! :D
<ikskuh>
andrewrk: have you read the idea of function "label" vs function pointer distinction already? what do you think of it?
<andrewrk>
yeah but I'd have to refresh my memory and read it again. I also discussed it with thejoshwolfe and he explained the situation in a way that made a lot of sense. I want to double check with him before proceeding
<ikskuh>
sounds good :)
<ikskuh>
i really like the idea, as it's the best way of distinction for exportable symbols :)
<andrewrk>
Sahnvour, I was thinking the same thing :D
<Sahnvour>
I've been planning to use tracy for some time but didn't yet, I bet it has some frame-based analysis tools that would be a great fit for this use case
<FireFox317>
ikskuh, thanks
craigo has joined #zig
decentpenguin has joined #zig
domust has joined #zig
domust has quit [Client Quit]
domust has joined #zig
domust has left #zig [#zig]
metasyntactic has quit [Remote host closed the connection]
KoljaKube has quit [Ping timeout: 244 seconds]
waleee-cl has joined #zig
marnix has joined #zig
ur5us has joined #zig
rzezeski has joined #zig
r4pr0n has joined #zig
FireFox317 has quit [Ping timeout: 256 seconds]
marnix has quit [Read error: Connection reset by peer]
<DarkUranium>
I've just realized what Zig's error handling reminds me of! (the idea of its `error.*` types, that is)
<DarkUranium>
It's Erlang.
<DarkUranium>
For example, `badarg` is returned for bad arguments, or `{try_clause,Value}` if Value does not match a `try` clause.
dermetfan has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
<leeward>
Did "anytype" turn into "any" when I wasn't looking?