<a92>
An alternative, simpler compiler for Zig pixelherodev is starting to make
<pixelherodev>
Name is temporary; I'll settle on a real name by 0.1, at which point I'll just `find -type f -exec sed 's/zyg/new name!!!/g' \;`, commit the results, and then be surprised that I broke it
<pixelherodev>
:)
wootehfoot has quit [Read error: Connection reset by peer]
<pixelherodev>
For now, spending another 20 minutes working-working
<pixelherodev>
If someone could send a ping in the chat to let me know it's working, that'd be helpful :P (using weechat over ssh to access it lol
<a92>
I see writing about Zyg, but it's in a recording; you appear to be offline
<a92>
Oh, you're online
mokafolio has quit [Quit: Bye Bye!]
seadragon-droid has joined #zig
<seadragon-droid>
fengb: You're right. That wouldn't make any sense. Is there any way to correctly cast a []const u8 to []u8, then?
quajzen has joined #zig
quajzen has left #zig [#zig]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
mokafolio has joined #zig
nvmd has quit [Ping timeout: 256 seconds]
mokafolio has quit [Quit: Bye Bye!]
<daurnimator>
seadragon-droid: no
<seadragon-droid>
So the correct pattern in this case is to retain a []u8 in the struct, and then provide a copied const version of the same, either by a method or a redundant field?
mokafolio has joined #zig
mokafolio has quit [Client Quit]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
<seadragon-droid>
or just to give up on exposing a []const u8 at all?
mokafolio has joined #zig
a92 has quit [Quit: My presence will now cease]
alexpana has quit [Quit: WeeChat 1.9.1]
earnestly has quit [Ping timeout: 260 seconds]
philtor has joined #zig
selby has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
selby has joined #zig
seadragon-droid has quit [Quit: -a- Connection Timed Out]
bitmapper has quit [Quit: Connection closed for inactivity]
selby has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
notzmv has quit [Remote host closed the connection]
<ifreund>
yet again I failed to reduce a test case
<ifreund>
but that branch doesn't compile
<TheLemonMan>
should it stop at "error: container '.wayland.wayland_server_core.list' has no member called 'Direction'" ?
<ifreund>
TheLemonMan: no, you need to update your submodules
<ifreund>
(can't wait tilll I can get away from submodules :/)
<TheLemonMan>
oh right, submodules
leon-p has quit [Ping timeout: 260 seconds]
earnestly has joined #zig
midgard has quit [Ping timeout: 272 seconds]
<TheLemonMan>
oh, I think it's the same bug that makes this http://ix.io/2Jf4 snippet fail to compile
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 260 seconds]
midgard has joined #zig
marnix has quit [Ping timeout: 264 seconds]
leon-p has joined #zig
marnix has joined #zig
<ifreund>
TheLemonMan: it's not really blocking forward progress tbh, just a refactor that will have to wait for now
<ifreund>
so don't spend all day on it
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Ping timeout: 265 seconds]
marnix has joined #zig
forgot-password has joined #zig
notzmv has joined #zig
<pixelherodev>
yayy, emit-h in stage2 was merged!
<pixelherodev>
I'm probably going to be working on Zig again soon, in addition to Zyg :)
<pixelherodev>
Need more CBE / emit-h support!
<ikskuh>
\o/
* ikskuh
waves pixelherodev
<pixelherodev>
hello :)
jokoon has joined #zig
forgot-password has quit [Ping timeout: 256 seconds]
forgot-password has joined #zig
marnix has quit [Ping timeout: 272 seconds]
forgot-password has quit [Ping timeout: 256 seconds]
marnix has joined #zig
forgot-password has joined #zig
<rowbee>
will zig auto-cast comptime_int to a type fitting the integer down the road or will we always have to specify the type in the variable declaration?
<ifreund>
rowbee: I don't think zig will every choose the type for you if it is ambigous
notzmv has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<m4r35n357>
hello? looking for any docs, examples etc. for zig translate-c, I've tried https://ziglang.org/documentation/master/, 'zig --help' and 'zig translate-c --help' with no success.
<m4r35n357>
tried passing it a c file, got: 'stdio.h' file not found
<m4r35n357>
is it for whole files, or just functions & small chunks?
<earnestly>
m4r35n357: You may need to tell zig where to find stdio.h, which itself can be done but iirc might be magicked with -lc
<m4r35n357>
earl, OK will try that. thx . . .
<m4r35n357>
well it behaves differently: Segmentation fault ;)
<m4r35n357>
also with --library c
<m4r35n357>
ooooooh!, platform issue!
<ifreund>
translate-c is mostly intended to be used for automatic inclucion of C headers
<m4r35n357>
fails on armv7l, works on aarch64 (quite verbose!)
<ifreund>
if you want to port a C codebase to zig you're probably best off doing it manually otherwise the result will not be very pretty
<m4r35n357>
ifreund, OK, cheers.
<m4r35n357>
ifreund, it certainly has a go at a lot more than that though!
<ifreund>
m4r35n357: yeah, well people put arbitrary C code in headers no?
<m4r35n357>
ifreund, I suppose that would mean it should cope then? ;)
<m4r35n357>
ifreund, nm I'm just kidding
<ifreund>
It should do fairly well as long as the marcros aren't too wierd
<m4r35n357>
ifreund, I wouldn't dream of putting my code in a header!
<m4r35n357>
I'll have a quick through the output anyway . . .
<m4r35n357>
look?
<earnestly>
header-only libraries are becoming more popular
<parshua>
ok, took me 'only' an hour to finally format a damn string, after 25 years of programming with system languages
<m4r35n357>
in c?
jokoon has quit [Quit: Leaving]
<parshua>
The language supports optionals, and there's the std.heap.GeneralPurposeAllocator, why not allow people to optionally skip passing allocators and use the default allocator?! The way it works now is an ergonomic nightmare and is legally punishable by hardwork in gulag
<ifreund>
there is no default allocator
<parshua>
even worse
<dominikh>
the standard library is optional :)
<ifreund>
generally library functions take an allocator parameter and use that
<ifreund>
which makes using things like arena allocators a breeze
<earnestly>
Is a "system languages", Go?
<parshua>
C
<dominikh>
25 years in Go would be truly impressive :P
<ifreund>
heh
<parshua>
this is truly brain-dead; there MUST be a default allocator, and passing an allocator should be optional, and if none is passed, the default should be used
<dominikh>
why MUST there be one? because you think so?
<companion_cube>
Odin (jai?) has this "context" that is passed implcitely, and it contains an allocator
<companion_cube>
I wonder if it'd be a good fit for zig: P
<companion_cube>
:p
<ifreund>
definitely not
<ifreund>
zig trys to be explicit not implicit
<dominikh>
passing my own allocator is about as difficult as passing null to an optional
<parshua>
because 99% of the time, that same allocator would be used, and no one cares?!
<dominikh>
<arbitrary percentage> of the time, I use an arena allocator
<ifreund>
that 99% number may be true in the C code you're used to because that's the only ergonomic option
<ifreund>
zig makes using stuff like arenas much nicer, and so that 99% is not accurate in my experiance
<dutchie>
also, things like ArrayList store the allocator so you don't have to re-pass it every call
<ifreund>
bascially what I'm saying is that there's a reason this is the way the std is designed
<ifreund>
I'd encourage you to gain a bit more experiance with it before passing judgment
alexpana has joined #zig
<ugla>
I'm using C libs in the program I'm working on and it's annoying me that I can't pass an allocator. They just do heap allocations for me with malloc, when they could be avoided completely.
<fengb>
I've found myself be lazy now that GPA is a thing
<companion_cube>
be lazy in programs, not libraries, heh
philtor has joined #zig
<dominikh>
even with the GPA, I'm just one build option away from wrapping that in Tracy magic
m4r35n357 has quit [Quit: Ex-Chat]
<dutchie>
i should try tracy out at some point
<fengb>
It's too easy to reach for it instead of thinking
<dominikh>
Tracy works about 80% great with Zig
cren has joined #zig
forgot-password has joined #zig
<forgot-password>
“/exit
<forgot-password>
Oops :D
forgot-password has quit [Client Quit]
<parshua>
I'm not saying that allocators should be removed; they should be optional. The language supports it, why not use it? Every one will be happy, and the use of the stdlib will be more ergonomic
marnix has quit [Ping timeout: 265 seconds]
<dominikh>
because it would encourage lazy programming, not making use of custom allocators. realistically, a lot of your calls shouldn't rely on a default. also, unless you make it a language feature that magically inserts a default allocator when none was passed, every function accepting an optional allocator would have to check for null and decide what the default is
<ifreund>
and you can't assume a default allocater in libraries
marnix has joined #zig
<ikskuh>
parshua, have you ever written programs outside classic desktop applications?
<ikskuh>
you want to have allocators there (if any) and you want to have control over allocation
<ikskuh>
zig is the only language where you can use most of the stdlib in any place you want conveniently
<ikskuh>
because nothing has implicit allocators
<parshua>
WTH are you people even talking about? You understand that optional allocator just makes most people's lives easier, while not making your life any harder right?
<parshua>
iksakuh: yeah I've done all of that outside if wasm
<ikskuh>
optional allocator means that we either implement everything twice => harder work, double the work
<ikskuh>
it also means that you have an implicit dependency on a global allocator if none is passed
<ikskuh>
it makes *typing* easier
<ikskuh>
but it doesn't make programming in general easier
<ifreund>
^
<ikskuh>
because being forced to think about requiring an allocator makes your software more performant
<ikskuh>
because you are forced to chose at write-time
<ikskuh>
what allocation strategy is used
<ikskuh>
and if you are *able* to use that API in the current place
<parshua>
by optional I mean: func XXX(alloc: ?*Allocator)
<dominikh>
and where does the default allocator come from? does XXX check if alloc is null?
<dutchie>
what i've been using zig for mostly recently is Advent of Code problems. i just write 3 lines of boilerplate at the top and type init(allocator) a few times
<dutchie>
sometimes allocator.alloc(..) and allocator.free(..)
<companion_cube>
dominikh: if there's no default allocator and the passed allocator is null, it could return OutOfMemory?
<companion_cube>
or whatever the failure is
<ikskuh>
parshua: what's the fallback then?
<ikskuh>
using a global allocator? who defines that? definitly not the library
<dominikh>
companion_cube: I'm trying to figure out if each and every function has to check if the argument is null and then use the default instead, or if there's going to be compiler magic
<ifreund>
the former would be better than compiler magic but is definitely worse than the status quo imo
<parshua>
no compiler magic; you'll have another [inlined] function call inside the XXX function that will try to return the allocator, and will either use the one that is passed, fallback to the default, or return an error if no default is set for some reason
<dominikh>
seems harder to write every single function that takes an allocator, then. also, you're basing this whole "there should be a default allocator" on what, an hour of using Zig? I'm not sure that's enough time to get a feeling for how often you want to pass in custom allocators
<ikskuh>
i think the status quo is near-perfect when it comes to allocation strategies
<ikskuh>
using that `null` argument makes stuff harder to use instead of easier
<ikskuh>
if you want a global allocator, you can do that in your programs
<ikskuh>
but writing libraries with a global allocator is more work
marnix has quit [Read error: Connection reset by peer]
<ikskuh>
afaik Odin has a global swappable allocator
marnix has joined #zig
<ikskuh>
but i really don't like that design, it makes stuff weird
<parshua>
I'll get used to all the ergonomic warts after extensively using the language. If I can use C, then I bet I'll be able to use Zig or anything else over time; take the feedback for what it is
<companion_cube>
ikskuh: I thought odin had a scoped allocator in the `context`
<ikskuh>
yeah, it's still kinda weird imho
<dominikh>
Odin will have whatever Jai has :P
<ikskuh>
i didn't really grasp the concept from seeing code examples
<companion_cube>
ikskuh: I think it's quite ergonomic
<ikskuh>
never used odin though
<companion_cube>
every function has a hidden "context" argument (
<ikskuh>
so if you have more insight there: please share! :D
<companion_cube>
and you can overload it locally before calling subfunctions
<dominikh>
I'm already not huge on thread-local storage, a hidden context only seems marginally better
<companion_cube>
it's dynamic scoping
<ikskuh>
it's definitly better than having a global for that
<ikskuh>
but it's still weird imho
<dominikh>
a lot of effort to avoid having to pass one more argument to functions
<companion_cube>
2, actually
wootehfoot has quit [Read error: Connection reset by peer]
<dominikh>
what's the 2nd one?
<companion_cube>
I think the context has an allocator and a scratch allocator
<companion_cube>
I imagine it's allocated on the stack and passed by ref…
<dominikh>
yeah; even if the context were a good idea, I'd pass it explicitly, not implicitly
<ifreund>
it is one hidden context arg instead of one explicit arg
<dominikh>
(then again, some people seem to absolutely hate Go for doing that with context)
<fengb>
The context is too implicit. I like my function signature indicating whether allocation is happening
<companion_cube>
it's probably nice if you want a more ergonomic language
<ifreund>
worse, people can put arbitrary stuff in the context iirc
<companion_cube>
something a bit higher level, where you have hasmap literals and stuff
<dominikh>
fengb has a good point. in Zig, you can immediately tell if allocations will happen
<companion_cube>
hashmap*
<ikskuh>
i think both solutions are good, i just prefer the very explicit way
<ikskuh>
had way too much pain in the past with implicit shit
<dominikh>
makes it a lot easier to avoid allocating accidentally, too
<ifreund>
yeah I'd take odin over C++ without a second of hesitation
<dominikh>
my function doesn't take an allocator? guess I won't allocate
<dominikh>
(unless I call into C, which is pure sadness each time)
<ifreund>
yeah zig really pushes you into writing efficient code I feel like
<companion_cube>
it's just a different tradeoff on expliciteness
<companion_cube>
like if you want something concise like python, you probably don't want to pass allocators explicitly around
<companion_cube>
jsut a different use case
<dominikh>
ifreund: I've certainly had a bunch of "wait, this can actually go on the stack" moments
<ikskuh>
ifreund, dominikh: yeah, i agree. zig makes you think more efficient
<ikskuh>
and it leaks into other languages
<ikskuh>
and i cry ever time i need to write `new TForm` in C++
<dominikh>
try being me, my main language is garbage collected :P
<ifreund>
dominikh: go also seems incapable of putting a static array on the stack
<ifreund>
though I guess if I care about performance I should just write zig :P
sawzall has quit [Read error: Connection reset by peer]
<dominikh>
ifreund: depends if you mean an array or a slice. I presume slices: for slices, there are some optimizations, when it can be sure the slice won't have to escape to the heap, and the size is known at compile time
sawzall has joined #zig
<dominikh>
but as is the way with the GC, you have to rely on optimizations, and those optimizations not changing
parshua has quit [Quit: WeeChat 2.8]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<ifreund>
yeah, that somewhat in depth knowledge about how the language is implemented being important for performance annoys the heck out of me
<dominikh>
in Go, you clear a slice with a for loop, writing the zero value to each element. the compiler then optimizes that to a memclear…
<dominikh>
it's both pretty and stupid at the same time
<CommunistWolf>
probably easiest just to build a new slice
<CommunistWolf>
it uses SSA behind the scenes anyway
<dominikh>
the backing array probably lives on the heap, so you want to reuse it, not allocate a new one
<fengb>
Does Go have escape analysis?
<dominikh>
sure
<viashimo>
CommunistWolf: what's SSA?
<CommunistWolf>
static single assignment
<CommunistWolf>
it's an optimisation pass that tries to turn all `x = ...` statements into x1 :=, x2 :=, etc
<ikskuh>
SSA is quite nice as it's easy to understand
<ikskuh>
and in theory to implement
<ikskuh>
ifreund, did you do some work on stage2? i wonder whats the difference between SSA and SSAT
<CommunistWolf>
> SSA is formally equivalent to a well-behaved subset of CPS excluding non-local control flow, which does not occur when CPS is used as intermediate representation.[3] So optimizations and transformations formulated in terms of one immediately apply to the other.
<ifreund>
ikskuh: SSAT is static single assignment tree
<dominikh>
pretty much looks like SSA with indentation :P
<dominikh>
dunno, I prefer the classic form with blocks and linear instructions
<ikskuh>
dominikh: they are kinda harder to compile i think
<dominikh>
ikskuh: hm. my background is in static analysis, not compilation. SSA (well, SSI for me) is pretty much my final representation
<ikskuh>
oh, fancy
<dominikh>
(static single information, not social security :P)
<ikskuh>
do you think zig has a good potential for even further static analysis?
earnestly has left #zig ["WeeChat 3.1-dev"]
<dominikh>
I don't know yet. it's certainly more difficult to write static analysis for Zig, on account of the compile time stuff. but I haven't looked into the zig IR yet, either. in general, you can think of most static analysis as an additional type system, enforcing more rules than the base language's type system can express. except your users won't help you out by using keywords of any sort and you have to
<dominikh>
guess intent…
<companion_cube>
you could do static analysis after all comptime is resolved
<ikskuh>
yeah that was my idea as well
<ikskuh>
you can output zig IR (which is SSAT)
<ikskuh>
and resolve that to SSA
<dominikh>
yeah, you just need tighter integration with the compiler then, as opposed to implementing your own parser and type checker (unless you want to reimplement all of the comptime stuff)
<companion_cube>
what kind of static analysis are you thinking about anyway?
<ikskuh>
which doesn't sound that bad imho
<dominikh>
or hope that the IR is high level enough for your needs. compilers and bug finding tools tend to have different IRs
<dominikh>
(and some checks you want to implement on the AST + type info, as the AST encodes more of the user's intent)
<dominikh>
std.meta will probably be able to cover a lot of checks you'd otherwise see in a separate tool
cole-h has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
osa1 has quit [Quit: osa1]
osa1 has joined #zig
osa1_ has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
wootehfoot has joined #zig
marnix has quit [Read error: Connection reset by peer]