<pixelherodev>
" pixelherodev wanted to help work invest in a non-llvm future, and this is one related task" Honestly, I'm more interesting in investing in a *zig* future
<pixelherodev>
If we use LLVM IR internally, but have our own rapid backend (like zasm) that can instantly generate unoptimized code from that IR without using libLLVM / C++ I am perfectly happy
<pixelherodev>
In other words, if we reimplemented all of LLVM in Zig, I'd have no problems; It's the dependency on another language that really gets to em
<pixelherodev>
s/em/me
<pixelherodev>
And yes I know that substitution wouldn't actually do what I want; this is a text chat, it doesn't matter.
<companion_cube>
also llvm has its own semantics
<pixelherodev>
Sure, but if they're Zig-compatible it's fine
_whitelogger has joined #zig
<fengb>
Pretty sure it used to map directly into LLVM IR but it got super complicated
<companion_cube>
if you want a spec of comptime evaluation, maybe it's better to not embed the whole llvm IR into it :)
<companion_cube>
(assuming zig 1.0 gets a proper spec)
<pixelherodev>
Why not?
<pixelherodev>
Shouldn't make a difference
<companion_cube>
llvm IR is not stable
<companion_cube>
and why would zig depend on an unrelated project on which it has no control?
<pixelherodev>
Oh wait - stuff like @testComptime is probably also not easy to do in LLVM IR
<pixelherodev>
True
<pixelherodev>
Especially if it's still largely controlled by Apple
<hryx>
both LLVM and zig IR are implementation details of the reference compiler, not part of the spec
<andrewrk>
fengb, yeah, we used to go straight from AST -> LLVM IR
kristoff_it has quit []
<mikdusan>
when self-hosted comes functional it's going to be a lot of work keeping stage1 at parity; is the plan to let things like runtime safety checks and other broad swaths that stage1 won't really need?
<mikdusan>
err let things like safety checks be self-hosted only?
<hryx>
yeah good question, I was recently wondering if "multibuild" could be self-hosted-only too
<pixelherodev>
`unreachable` checks don't show up in release builds, right?
<pixelherodev>
Now I *really* hope LLVM-xtensa is eventually usable
<pixelherodev>
So I can redo this library in Zig
<pixelherodev>
So much that'd be better...
<pixelherodev>
Hell, not using a heap (using a FixedBufferAllocator instead) alone would make me much more comfortable with this code
<terinjokes>
i've noticed some of the os function signatures are different between linux and c, so that `system.fn` doesn't work. is this a bug or intentional?
<pixelherodev>
example?
<Snektron>
pixelherodev, youre working on llvm->machine code right?
<terinjokes>
os.setsockopt, opt is `[]const u8`, in linux.zig the parameter is defined `[*]const u8`, and in c.zig it's `*c_void`. error if you call setsockopt while compiling against c is "cast discards const qualifier"
<Snektron>
Why that instead of working on zig IR directly?
<pixelherodev>
Snektron, because Zig IR is just as unstable long term
<pixelherodev>
LLVM IR at least means that I'll be able to continue using this for LLVM 9 theoretically indefinitely
<pixelherodev>
and it'll be simpler to go from LLVM IR 9 to 10 than from Zig IR unspecified -> whatever comes in the future, *which isn't known*
<Snektron>
Not if LLVM is updated right
<pixelherodev>
Furthermore, this allows in theory for C support
<pixelherodev>
And some of my backends don't have any other C compilers yet
<pixelherodev>
I'm hoping to add a z80 backend, for instance
<pixelherodev>
And there are few good z80-targetings compilers
<pixelherodev>
s/targetings/targeting
<Snektron>
<pixelherodev "and it'll be simpler to go from "> I suppose thats true, but it seems like a strange step to me
<pixelherodev>
Like I said, Zig also isn't intended to be the only frontend
<Snektron>
Anyway
<mikdusan>
heh clang->ll->pixelherodev->z80
<pixelherodev>
?
<Snektron>
Are you going to add fancy optimizations too?
<Snektron>
Or will you just make naive code generation
<mikdusan>
would that pipeline work?
<pixelherodev>
Possibly
<pixelherodev>
mikdusan, ?
<pixelherodev>
Why am I in there?
<pixelherodev>
ohhh
* pixelherodev
facepalms
<pixelherodev>
Right
<pixelherodev>
Yeah, in theory
<pixelherodev>
Why?
<mikdusan>
just curious
<pixelherodev>
Snektron, probably
<pixelherodev>
Already does a few, but those are more like torturing the IR into a simpler form that the backend has an easier time parsing than actually optimizing
<Snektron>
Or, since you depend on LLVM IR, will you let LLVM handle generic IR optimization and then do naive code generation?
<pixelherodev>
Initially, naive]
<pixelherodev>
s/]//
<pixelherodev>
But long term, definitely would be adding backend-specific optimizations
<pixelherodev>
e.g. for z80, some optimizations would probably focus on minimizing amount of registers needed
<pixelherodev>
or, for e.g. u32s, would probably attempt to convert to *one* 16-bit op and not multiple when possible
<mikdusan>
pixelherodev: I only thinking in broad strokes, but fyi, I am not sure llvm-ir is going to be as suitable for incremental building as zig-ir is (or will be). because we can change zig-ir to be whatever it needs to be.
<hryx>
OT: anyone else here see "LLVM" and hear "fifty fifty five one-thousand" in your head?
<pixelherodev>
mikdusan, I don't doubt it
<pixelherodev>
But this is purely short term
<pixelherodev>
hryx, I don't work with Roman numerals generally :P
<andrewrk>
mikdusan, yeah that's the plan, stage1 only has to be good enough to get us to self-hosted, but we shouldn't have to compromise the quality of the std lib
<pixelherodev>
Huh
<pixelherodev>
Snektron, yeah, that's not a bad idea
<pixelherodev>
To use QBE IR instead of LLVM IR, that is
<pixelherodev>
But it would make Zig support much more difficult
<mikdusan>
hryx: waiting for your PR to add roman-numeral-literals :P
<pixelherodev>
Unless I write a Zig IR -> QBE IR translator for stage1
<pixelherodev>
But that's harder short-term
<pixelherodev>
In the short term, LLVM IR is easier to work with
<Snektron>
I didn't suggest that, i just thought that project might interest you
<pixelherodev>
Ah
<pixelherodev>
Heh, my bad
<pixelherodev>
Found the IL link on my own then :P
<Snektron>
You'd have to add Z80 support anyway
<pixelherodev>
Well yeah, but I need to do that regardless
<hryx>
mikdusan: ha, guess it's time to prepare for another syntax flamewar! x___x
<andrewrk>
mikdusan, it's intended to be exclusive across processes for the same file. that's how the cache eviction will avoid messing up ongoing compilations. we don't currently have eviction implemented
<daurnimator>
andrewrk: I looked into making signals an enum: wasn't sure how far to go. e.g. os.sigaction should take an enum; but should linux.sigaction? c.sigaction needs to take a c_int..... should the Signal enum be of different size depending on linking libc or not?
<daurnimator>
agreed. it unlocks lots of interesting embedded use cases
<andrewrk>
ok here's an idea I did not consider before
<andrewrk>
stage1 could emit a zig ir text format, which is picked up by stage2
<andrewrk>
no no, this can't work, this is a dependency cycle
<daurnimator>
I figured next thing to move to stage2 would be .h file generation
<andrewrk>
that's not really practical to be part of the hybrid
<daurnimator>
oh? why not?
<andrewrk>
it touches a lot of the c++ semantic analysis data types, which is tightly coupled to stage1
traviss has quit [Quit: Leaving]
return0e has quit [Remote host closed the connection]
<daurnimator>
Do we want to de-C++-ify them so that they are similar between stage 1 and 2?
<andrewrk>
that question doesn't really make sense to me
<pixelherodev>
I was actually wondering
return0e has joined #zig
<pixelherodev>
While I completely understand needing to know target features
<pixelherodev>
Why does Zig need to know host features?
<andrewrk>
for the default compilation target
<andrewrk>
by default zig takes full advantage of your cpu
<daurnimator>
andrewrk: as in: make the C++ data types suitable for extern-ing (i.e. plain C); and then 'binding' them from zig
<andrewrk>
it's not so much C vs C++ that is the problem, but the fact that everything is tightly coupled to everything. introducing a layer in the middle is likely to cause more problems than it would solve
<terinjokes>
If i pass the same target as my host, do I get a generic build, or do I get a host-optimized build?
<daurnimator>
terinjokes: right now you get a "baseline" of e.g. pentium 4 if you specify the target
<andrewrk>
passing a target gives a cross compiled target
return0e has quit [Ping timeout: 240 seconds]
<daurnimator>
terinjokes: vs if you don't specify the target you get a build optimized for your *exact* cpu
<terinjokes>
perfect, that's what I assumed
<daurnimator>
andrewrk: will there be the possibility to target a subset of two cpus?
<terinjokes>
though P4 is a _bit_ older than I had it mind
<daurnimator>
andrewrk: i.e. an intersection of features?
<andrewrk>
the way that will work is to specify a union of the cpu features of each
<andrewrk>
sorry, intersection like you said
<daurnimator>
something like `--target-cpu=cpu1 --target-cpu=cpu2` would do an intersection?
<daurnimator>
--> how would you denote a union vs an intersection?
<andrewrk>
once this branch is merged, status quo will be that you would specify -target-feature a,b,c,d
<andrewrk>
and you would have to do the intersection manually
return0e has joined #zig
return0e has quit [Ping timeout: 260 seconds]
marmotini_ has quit [Remote host closed the connection]
jjido has joined #zig
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_Vi has joined #zig
ur5us has joined #zig
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 268 seconds]
_Vi has quit [Ping timeout: 252 seconds]
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
bheads has quit [Quit: bheads]
bheads has joined #zig
eagle2com has joined #zig
hio has joined #zig
lunamn has quit [Ping timeout: 260 seconds]
lunamn has joined #zig
return0e has quit [Remote host closed the connection]
ur5us_ has quit [Read error: Connection reset by peer]
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
eagle2com has quit [Remote host closed the connection]
doublex__ has joined #zig
doublex_ has quit [Ping timeout: 260 seconds]
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
_Vi has joined #zig
eagle2com has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
eagle2com has quit [Quit: WeeChat 2.6]
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
waleee-cl has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
Snetry has quit [Ping timeout: 272 seconds]
zfoo_ has joined #zig
return0e has quit [Remote host closed the connection]
Snetry has joined #zig
return0e has joined #zig
BaroqueLarouche has joined #zig
return0e has quit []
_Vi has quit [Ping timeout: 252 seconds]
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
frmdstryr has joined #zig
_Vi has joined #zig
bheads has quit [Quit: bheads]
bheads has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
frmdstryr has quit [Remote host closed the connection]
Snetry has joined #zig
<betawaffle>
is it expected for objdump to puke on some binaries produced by release-fast and release-small?
<betawaffle>
or does that indicate a zig bug?
dddddd has joined #zig
Snetry has quit [Ping timeout: 258 seconds]
return0e has joined #zig
Snetry has joined #zig
bheads has quit [Quit: bheads]
bheads has joined #zig
leeward has joined #zig
Snetry- has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry- has quit [Ping timeout: 265 seconds]
<grayhatter>
betawaffle: define "puke"
Snetry has joined #zig
<betawaffle>
"... objdump: error: 'zig-cache/bin/...': truncated or malformed object (bad section index: 3 for symbol at index 2)"
<betawaffle>
with exit code 1
<grayhatter>
I'd be more willing to suggest it's a bug in both, but I don't know enough to have an opinion worth listening to
Snetry has quit [Ping timeout: 265 seconds]
<fengb>
Many of us are just flailing around in here with a modicum of hubris
<fengb>
That was unintentionally posh >_>
Snetry has joined #zig
return0e_ has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
Snetry has quit [Ping timeout: 272 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
metaleap has joined #zig
lanodan has quit [Ping timeout: 260 seconds]
bheads_ has joined #zig
bheads has quit [Ping timeout: 272 seconds]
bheads_ is now known as bheads
_Vi has quit [Ping timeout: 258 seconds]
Snetry has quit [Ping timeout: 258 seconds]
Snetry has joined #zig
Akuli has joined #zig
lanodan has joined #zig
_whitelogger has joined #zig
adamkowalski has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
_Vi has joined #zig
return0e has quit [Remote host closed the connection]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<andrewrk>
xackus, did you find the std.json.Writer API?
<adamkowalski>
awesome! do you have a list of what's implemented so far? Have you seen https://github.com/andersfr/zig-lsp? Would there be benefit in convering the projects?
<xackus>
andrewrk, I am using std.json.WriteStream if that's what you mean
<xackus>
it basically runs std.zig.parse on the file and displays errors
<xackus>
I also added autocompletion of builtins as a test
<andrewrk>
ah, I made an incorrect assumption based on seeing Primitive and Number types
<andrewrk>
neat
<xackus>
my automatic conversion between zig structs and json makes it easy to add features
<adamkowalski>
andrewrk: Do you have any videos where you discuss why you use NixOS? It looks pretty interesting from a reproducability and deployment perspecitve. But does it take an enourmous amount of disk space since it keeps all these previous generations? It even has a garbage collector to remove some of them right.
<adamkowalski>
xackus: do you have zig fmt integration?
<xackus>
no, I use vscode-zig for that
<xackus>
I made a fork which registers my server
zfoo_ has quit [Read error: Connection reset by peer]
<betawaffle>
xackus: aww cool!
<xackus>
thanks
lunamn has quit [Ping timeout: 258 seconds]
<betawaffle>
xackus: does your fork fix error reporting with master zig?
lunamn has joined #zig
<betawaffle>
(for me, everything gets reported with /. as a prefix to the file paths, so none of the reported errors/warnings link back to the files
<xackus>
I didn't mess with that, I didn't know there is a problem, because it works for me
<betawaffle>
huh, interesting
<betawaffle>
it worked for me with 0.5
<betawaffle>
but broke when i switched to master
<mikdusan>
betawaffle: typo? did you mean "./" relative paths ?
<betawaffle>
nope.
<betawaffle>
i'd be able to understand that at least
<betawaffle>
but /. doesn't make sense
<mikdusan>
I am missing context, is this about scraping error output from stage1 and gleaning file paths?
<mikdusan>
ok so as of fc20a589931ab9aac6f51e7685d724cbec52dd9e the compiler errors strip cwd from pathname output to help humans when the file is in cwd it will output as relative "./......" and otherwise absolute.
<mikdusan>
i think that server is not anticipating the choice
<betawaffle>
not sure how vscode.Uri.file works, but presumably that's the issue?
marmotini_ has joined #zig
<metaleap>
doesnt the stdlib get "does-it-all-compile"-tested prior to publishing a nightly binary? because just using std.io i'm getting:
<metaleap>
zig/lib/zig/std/io.zig:853:32: error: no member named 'readByte' in struct 'std.fs.file.InStream'
<metaleap>
could be tricky with the "lazy" compiler but surely there's an option to sanity-check every decl in srcfile
<mikdusan>
metaleap: tricky is understatement. right now things need to be covered in test cases
marmotini_ has quit [Ping timeout: 268 seconds]
<mikdusan>
it's almost as difficult as... having the C++ unit test all possible .h macro definitions
<metaleap>
so might wanna have a path to where nothing gets published in the stdlib that wouldnt compile when referenced i reckon.. i mean it's the *std* lib! :D
<metaleap>
i seem to remember someone mentioned there's a "reference-all" kinda flag somewhere
<mikdusan>
metaleap: that error... stream should be _interface_ not impl. pass in std.io.InStream
<metaleap>
so i was passing in `std.io.getStdIn().inStream()` but if i pass in std.io.InStream it wont use stdin now would it
<metaleap>
wonky stuff, might use the InStream's builtin readUntilDelimiter type methods directly without this io.readLine helper
<mikdusan>
does this work: `var impl = std.io.getStdIn().inStream(); const in = &impl.stream; _ = in.readLineFrom(....);`
<metaleap>
well it compiles now. so that's *that* prob solved, thank you much indeed! there's now at runtime an integer overflow but thats another thing for me to dive into next
<metaleap>
mikdusan oh btw in the method form it didnt compile but in the std.io.readLineFrom(&stdin.stream, &buf) it did
<mikdusan>
in method form did you use a pointer?
<metaleap>
both without and with: no member named 'readLineFrom' in struct 'std.io.in_stream.InStream(std.os.ReadError)'
<mikdusan>
ok just curious
<metaleap>
its an interesting corner case here tho for general zig compile-error reporting: we had a caller-at-fault but the report was for lib/std/io.zig. guessing due to the arg type `var`. so this is kinda like "caller-provided type" so type errors could then report such for the call site, not the impl being wrongly-used
jjido has joined #zig
<mikdusan>
so it seems we do not accept method syntax for generic functions?
<metaleap>
the thing that trouble me there in std.io.readLineFrom isnt a struct method in the first place
<fengb>
iirc, readLineFrom isn't a method
<metaleap>
in most stacks stdin is "open" from birth til death, same in zig? do i need to open explicitly? i'm getting EndOfStream on the first readByte occurring in a "minimal in/out console app" for crikey's sake :D guys this stuff really manages to send one back to one's earliest fumbling coding-baby days
<mikdusan>
nah it should just work like you expect
<metaleap>
so i mean what on EARTH could a meagre newb still be missing here?? https://paste.pics/7T1X8 (forgive the lack of defer mem.deinit plz)
<metaleap>
ooooh fuark just noticed the binary itself works just zig build run by default doesnt open the stdinput i guess =/
<metaleap>
no pass-through
<mikdusan>
metaleap: heh i tried `zig run foo.zig` but not `zig build run...`
<metaleap>
i gotta get used to it that `zig build foo` does whatever you tell it `foo` is-or-does :D thx for bearing with me
<andrewrk>
might be more simple to use the standard `zig build` to install; manually run your program from the install directory (install directory can be inside your project dir)
<andrewrk>
$ zig build
<andrewrk>
$ ./zig-cache/bin/foo
<metaleap>
yeah it just occurred to me way too late
lanodan has quit [Ping timeout: 248 seconds]
<mikdusan>
andrewrk: can I get your thoughts on having two instructions "*Src" vs "*Gen" instead of just one where it elevates itself by populating more fields in analysis pass? I've read the comment about type-safety but thinking about self-hosting, we're probably going to have more passes...
lanodan has joined #zig
<andrewrk>
mikdusan, I'm thinking any extra passes will all be "pass 2" instructions. e.g. they will have type info
<pmwhite>
Have you ever heard the story of Darth Guido the wise?
<fengb>
Guido also stepped down because of rampaging egos :(
<leeward>
I think that article is not wrong though. Written rules for social systems have complex consequences. There's no reason to think that because a person wrote the first line of code in a project they'll be good at managing social interaction though.
<shakesoda>
leeward: it can frequently enough be a better indicator of the opposite, lol
<fengb>
Good engineers can often be terrible at social IQ >_>
<leeward>
No idea what you're talking about. I've never met a good engineer who didn't get along with everyone.
<shakesoda>
<- guilty
<fengb>
You're assuming that you're good 🙃
<shakesoda>
leeward: hah
mahmudov has quit [Ping timeout: 240 seconds]
<fengb>
I really hope Zig doesn't boil over some SJW issue :(
mahmudov has joined #zig
<shakesoda>
in my experience it's the people who are causing the issues to begin with that boil over such things
<shakesoda>
so i'd rather hope zig stays true to the channel topic
<shakesoda>
"be excellent to each other"
<fengb>
Most problems are nuanced and have multiple bad actors
<shakesoda>
yes, and most simple explanations of social problems are wrong as such
<fengb>
Most social problems*
<fengb>
But there's been a big upheaval lately. Many of them are old problems that are finally boiling over, but the trend is a little scary
<shakesoda>
the worst project related social fiasco i've ever been involved with spawned from what i perceived to be a benign request to lay off on insults
<shakesoda>
at which point i received an explosion of anger for all kinds of things i'd never so much as heard of
<fengb>
I'm really concerned that we're becoming really good at mob justice
<pixelherodev>
Hey, that's awesome! I always assumed mobs would be terrible at doling justice!
<shakesoda>
i'd place the game on being the social media numbers game, which actively places incentive on being incendiary
<shakesoda>
s/game/blame/
<shakesoda>
so you can get massive amounts of anger rallied around something trivially if you ignore all the nuance in the reality of whatever the situation is
<companion_cube>
if a project is entirely absent from social media, is it isolated from mobs?
<shakesoda>
no - because links exist
<pixelherodev>
"entirely absent from social media" that's a hilarious concept
<companion_cube>
if you can't hear twitter scream, does it matter? :D
<companion_cube>
pixelherodev: I don't count IRC as social media :)
<pixelherodev>
Not what I meant
<pixelherodev>
I don't have *any* accounts on any of those sites - no Twitter, FB, Instagram, etc
<shakesoda>
and i don't just mean hyperlinks, links also in the form of just referencing it elsewhere
<pixelherodev>
Discord / IRC are the closest I get
<pixelherodev>
I'm willing to bet I've been tagged on sites on which I have no presence dozens of times
<leeward>
As long as you don't look at reddit, it doesn't matter what they're saying. Right?
<pixelherodev>
As an *individual*
<fengb>
Github is a social network of sorts :P
<companion_cube>
leeward: exactly :p
<shakesoda>
unfortunately your awareness of issues or not doesn't mean it won't become your problem later, independent of how it spread or its truth
<companion_cube>
(well, you do need to modate github issues, indeed, I imagine)
<pixelherodev>
Heh - reminds me of the argument I got into with someone on Reddit who was saying C++ for kernel-level code was a good idea in response to my blog post about Zig https://www.xkcd.com/386/
<companion_cube>
isn't the standard answer to taht to cite Linus?
<companion_cube>
(not that I'd agree, but still, it seems like a time honored tradition)
<fengb>
I was gonna say, Linus would allow Zig far earlier than C++ :P
mahmudov has quit [Ping timeout: 272 seconds]
<shakesoda>
in the spirit of being good to people, i will withhold my opinions about c++ and its users ;)
<leeward>
shakesoda: Good idea. /join #c++-flaming
<leeward>
Wait, did I type that?
<shakesoda>
:D
<pixelherodev>
That's a real channel?
<shakesoda>
everything is a real irc channel if you believe
<leeward>
Define real.
<pixelherodev>
Didn't think so
<pixelherodev>
... and yes I checked anyways
<shakesoda>
the act of checking is enough to make it real, such is the beauty of irc
<pixelherodev>
I'd define real as having more than one user.
<shakesoda>
reasonable
mahmudov has joined #zig
<shakesoda>
per freenode policy though, it should probably be a ## channel if it were to be real
<leeward>
shakesoda: I checked without joining it.
<pixelherodev>
shakesoda, true
<pixelherodev>
Hence me languishing alone in the #limnstation and #zany80 channels here until such time as a) someone gains interest in those projects and b) they also use IRC
<shakesoda>
leeward: i've been had!
<leeward>
:P
<pixelherodev>
The intersection of A and B seems to be approximately zero :P
<leeward>
It looks like a set with 1 member.
<pixelherodev>
I don't believe I qualify for set A
<pixelherodev>
Especially not for #zany80 ; I started that in my freshman year of high school, and put it on hold earlier this year due to lack of time
trilead has joined #zig
<trilead>
Hi, I'm new to zig and trying to build for armv7-freestanding, but I'm having trouble with build.zig. Particularly with this "exe.addCSourceFile("src/blink.c", [_][]const u8{"-O3"});". I am getting ".\build.zig:13:41: error: array literal requires address-of operator to coerce to slice type '[][]const u8'". But even when I prefix the array with '&'
<trilead>
I still get the same error.
<pixelherodev>
& goes before the [_]
<trilead>
Yeah I put one there, but I got the exact same error
Akuli has quit [Quit: Leaving]
<leeward>
trilead: https://godbolt.org/ has Zig highlighting if you want to paste something larger.
<pixelherodev>
whelp, beats me, sorry; haven't worked with arrays in Zig all that much
<trilead>
ok
<trilead>
thanks anyways
<mikdusan>
trilead: put an `&` in front of the array rhs --> `&[_][]const u8....`
<BaroqueLarouche>
In my GBA build.zig assuming zig master, addCSourceFiletileDemo.addCSourceFile("examples/tileDemo/brin.c", &[_][]const u8{"-std=c99"});
<trilead>
pixelherodev: I thought I had tried that but I had made another small change which probably borked it. Didn't notice it until then.
<trilead>
pixelherodev: "small"
<daurnimator>
I miss having the builtin docs in the main documentation
<DorianXB>
Hey, I'm a bit new to zig and its compilation mechanism. I'm wondering how to have both i386 and x86_64 binary in the same elf file. Is there a way to do this in pure zig (like the [BITS 32] and [BITS 64] in nasm) or do I need to mess with linker settings ?
<andrewrk>
you'll have to make 2 different object files
<andrewrk>
and then link them together with messing with linker settings
<andrewrk>
this is a use case that is in scope to support in a better way however
<DorianXB>
Alright, I feared that was the case, but now I'm set, thx ^^
<daurnimator>
:( segfault in llvm::BasicBlock::getContext
<daurnimator>
(#2727)
leeward has quit [Remote host closed the connection]
<pixelherodev>
ugh
<pixelherodev>
I freaking *hate* 2727
mahmudov has quit [Remote host closed the connection]
xackus has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 258 seconds]
M-ou-se has quit [Ping timeout: 248 seconds]
M-ou-se has joined #zig
DorianXB has quit [Ping timeout: 260 seconds]
<mq32>
#181 (keyword: let) is a pretty hot topic ^^
<fengb>
It's ballooning out of control
<mq32>
yeah a bit
<mq32>
i think let and var is totally fine, but i don't really care as long as it is not that much to type for something i do nearly every line of code
<fengb>
I was in favor of context based declarations (let / static / threadlocal) but walked back because of anon functions
<fengb>
This looks super gross: `static method = fn(self: Self) {`
<mq32>
yeah, also: more keywords
<mq32>
but it's not that much of a thing
* shakesoda
doesn't think it's especially gross
<fengb>
It's almost anti modern OO, since static and method are antitheses of each other
<daurnimator>
mq32: FWIW I don't like let and var: I think they should be different lengths
<mq32>
daurnimator: i would also be happy with "let mut" or similar
<andrewrk>
reopening that issue is mainly to save 2 keystrokes when declaring functions, to counter #1717 punishing function definitions a bit
<companion_cube>
(yesssss, closer to rust, closerrrr)
<shakesoda>
fengb: the world needs more anti-OO :P
<pixelherodev>
I honestly vastly prefer status quo
<fengb>
Let's do Jai: `method := fn()`
<mq32>
but i think it's a good feature to differ between "const value" (let x = …) and const refernce ([]const u8) to something
<companion_cube>
`status quo x = fn(…)` ??
<shakesoda>
i rather like let and let mut
<shakesoda>
or let and const
<mq32>
as this seems something that is often confused
<shakesoda>
let and var seems the worst option by far
<fengb>
shakesoda: but you're taking something that's OO based (methods) and shoving it into an overloaded context that looks anti-OO
<fengb>
It's like how Go decided that it doesn't want inheritance, but implemented embedded structs... which is a (admittedly nice) implementation of inheritance
<companion_cube>
where does zig have OO methods‽
<shakesoda>
just having methods doesn't make something oo
<companion_cube>
embedded structs feel more like composition than inheritance to me
<companion_cube>
yeah, it's just UFCS in a way
<shakesoda>
+1
<pixelherodev>
var / const > mut / let if you ask me
<fengb>
¯\_(ツ)_/¯ methods originate from OO land
<shakesoda>
pixelherodev: i think they're sufficiently unambiguous, but i think it's a good point that the language has business in guiding you toward better practice
<companion_cube>
and lambdas originate from lisp, doesn't mean java is a lisp ;)
<shakesoda>
const being more effort to type discourages exactly this imo
<fengb>
But it's a function construct
<fengb>
functional*
<companion_cube>
roughly as much as `foo.bar()` is OO :D
<fengb>
Anyway, my point is, it takes something familiar to many people and makes it really foreign and different
<shakesoda>
having made that argument, like everyone else in here and on the issue, i don't really care so much for the keyword itself so much as just having anonymous functions everywhere
<mq32>
function literals are are really ckol thing :)
<mq32>
*cool
<mq32>
as well as sleep, so: gn8!
<fengb>
+1 to anon functions
<shakesoda>
it closes a big gap with how i write programs in other languages (e.g. lua), which have this
<shakesoda>
or even (urgh) c++
<fengb>
And hopefully we get actual lambdas "soon"
<companion_cube>
how do you do closures, though… that's always the hard part
<shakesoda>
one step at a time :)
<fengb>
I'm gonna keep ignoring closures :P
<companion_cube>
it'll pop up as soon as you can do `let f = fn() { … }` in a block :p
<shakesoda>
even in c++, most of my anonymous functions don't need to do variable capture
<fengb>
It's already popping up whenever we deal with a callback / fp
<companion_cube>
that's quite surprising to me, if you do even a for_each or whatever you'll want to update something outside the lambda
trilead has quit [Remote host closed the connection]
<mq32>
fengb: i would rather have a nice interface system that uses vtables instead of embedded vtables. zig is flexible enough to use this instead of some capturing lambdas
<shakesoda>
by default, i pass everything of relevance, and i don't regularly use for_each or similar at all
<shakesoda>
not to say one shouldn't - just that for my use case it doesn't come up all the time
<fengb>
Internet argument > sleep 🙃
<mq32>
yep
<shakesoda>
aye
<mq32>
what is the current idiomatic way of storing a "pointer to any"?
<fengb>
Uh... *c_void? :P
<mq32>
:D
<watzon[m]>
So I've noticed there haven't been many updates in the HTTP area since the `http.headers` module got added. Anyone know if there's something I could do to help out in that area? I want to contribute and that's an area where I have some decent knowledge.