<g-w1>
is there anything else a shell needs besides this?
<g-w1>
if so, ill just use std.os
Dharco has quit [Remote host closed the connection]
<mikdusan>
a typical unix shell has a lot of redirect abilities. redirect to a file. to a pipe. the file has options like create or append and which perms to create with,
<mikdusan>
then there's redirecting a single descriptor vs. multiple (eg. stderr and stdout)
<g-w1>
yes so i do f = open("file.txt", "a"); child.stdout = f;
<g-w1>
multiple times for stderr and stuff
<mikdusan>
and these kinds of details are beyond ChildProcess
<g-w1>
so you are not supposed to control the ChildProcess.std{out,in,err} ?
<mikdusan>
in it's current state that is. here's a good example of exposing pretty much every thing one can think of for an API:
<ifreund>
g-w1: if you haven't seen it yet, this is probably the simplest posix shell implementation to taken inspiration from: https://github.com/emersion/mrsh
<mikdusan>
no I'm just saying ChildProcess is a long ways from giving you that kind of flexibility
<g-w1>
ah :)
<g-w1>
ifreund: i have seen that :) it looks nice
<ifreund>
though IMO posix is a dead end in terms of shell design
<g-w1>
you like stuff like nushell?
<ifreund>
no, that's far too complex
<g-w1>
so what is a good direction?
<AtomToast>
what about something like mksh?
<ifreund>
that's still posix compatible no?
<AtomToast>
I think so but it adds a lot of user friendly non posix syntax. Can't say that I really used it myself. But one guy I know loves it
<ifreund>
I want a scripting language that follows something closer to zig's design philosophy, and sofar the only project I know of that seems close to how I imagine that is marler's stitch
<ifreund>
AtomToast: the problem is that posix comapability means you support all the ugly legacy stuff I want to get away from
<g-w1>
my goal is the readline friendlyness of fish (auto completions, nice prompt by default) but posix so i don't have to remember multiple things and can eventually use it as my main shell
<ifreund>
zsh fits that use case for me
<AtomToast>
that aligns quite well with what I want as well
<ifreund>
it's quite complex and far from perfect, but for interactive usage it's good enough
<g-w1>
zsh does not have it by default. i like sensible defaults :)
<AtomToast>
zsh is what I use atm but I am not married to it and I would love sth more minimal that I can easily hack on myself
<ifreund>
I was talking more about a scripting language
<mikdusan>
what we need is a shell that you extend with zig code, then it builds the .so and loads it. fast prompts go brrrrrrrr
<recalloc>
Does Zig happen to have a feature to fuse two structs together? Something like JavaScript's `{a:1,b:2,...{c:3,d:4}} => {a:1,b:2,c:3,d:4}`
<g-w1>
i was thinking `config.zig` with those fast compile times of stage2
<ifreund>
g-w1: I do too, but no enough to motivate me to start writing my own instead of writing a bit of config
<g-w1>
recalloc: you can probably do something like this with @Type( and @TypeInfo( although if they have declarations it won't work as @Type can't accept declarations yet
<AtomToast>
g-w1: suckless style :)
<recalloc>
I see, thanks
<g-w1>
well thanks everyone, i think ill just use std.os, and it will give me a bigger oppurtunity to learn actually how posix works :^)
<ifreund>
I also am very much not a fan of suckless style config :D
<g-w1>
imo its better than .so
<AtomToast>
would hav guessed as much :p
<ifreund>
g-w1: yeah, but that's not a high bar :P
<ifreund>
I think a shell should be configured in itself
<noam>
Note that the binary is based at address 0x20, with a high-level emulated BIOS from 0x00 - 0x20
<noam>
Hence the addresses are all 0x20 higher than you'd expect :P
<noam>
(the binary gets loaded in at 0x20)
<noam>
Manually disassembling: first eight bytes are start, which calls main (the test runner), then signals the BIOS the equivalent of exit(0). 0x28 is foo, which just returns. 0x29 is main, which calls foo (0x28) a few times, then loads HL with the panic string (BAR) and signals a panic to the BIOS :)
<g-w1>
ok, i got it working with std.process. it is much better than std.os
<v0idify>
hm, wouldn't it be nice to have a "stage2 status" page? are we stage2 yet? or a "this week in zig" in general
<g-w1>
people have asked for that before iirc
ur5us has joined #zig
<v0idify>
i would volunteer to write a this week in zig if needed but i'm not active enough to compile a list of things that happened (rather, if i received a list of things to review i could make the write-up)
<g-w1>
#showtime in the discord server has a pretty good list imo
<g-w1>
and you could follow #stage2-meetings for some progress
<g-w1>
on stage2
<g-w1>
s/showtime/showcase
* v0idify
has no discord because i get auto-banned for using tor/vpn :)
<v0idify>
sadly
<g-w1>
i could copy and paste the channel every week if you dmed me :)
<v0idify>
haha okay that could actually work
<v0idify>
although it would be a bit exhausting having to read the log all at once, would <discord admins> be okay with having a bridge to an irc? (I already have the infrastructure (matterbridge and an irc for it) if it's ok)
<v0idify>
(matterbridge is a software that allows bridging many different platforms with each other)
chivay has joined #zig
<v0idify>
i can't find any of the discord admins (according to the Community page) here
<daurnimator>
andrewrk: I don't think the longjmp issue should have been closed?
<v0idify>
i'm gonna log off for now, if the discord admins are okay with adding a bridge (which will be possibly open to others if wanted) or anyone else wants to discuss making a "this week in zig", please send me an email v0id@riseup.net
<daurnimator>
v0idify: people have asked for an IRC<>discord bridge before and we decided against it
<noam>
v0idify: alternate zig compiler
<v0idify>
daurnimator: oh, may i ask why? it doesn't necessarily have to be on #zig
<noam>
Different communities with different behavioral norms and such, I think
<daurnimator>
v0idify: okay; it was denied in the context of linking to this current #zig channel
<v0idify>
i get why that's the case, it's very possible that this channel would end up spammed with bridge messages
<v0idify>
noam: awesome! i figured because of the log, blah. written in c right?
<noam>
Yep
<v0idify>
does it have any dependencies?
earnestly has quit [Ping timeout: 260 seconds]
<noam>
A C99 compiler
<noam>
LO
<noam>
:P
<v0idify>
:)
<noam>
A tiny bit of POSIX, I think
<noam>
But plan9 is a first-class target :)
<v0idify>
ohh nice!!
jsb has quit [Quit: .]
jsb has joined #zig
notzmv has quit [Ping timeout: 252 seconds]
zenkuro has quit [Ping timeout: 240 seconds]
v0idify has quit [Remote host closed the connection]
sm2n has quit [Ping timeout: 240 seconds]
skuzzymiglet has quit [Remote host closed the connection]
Kingreil has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
<koakuma>
I also tried to link the objects manually with GNU ld, but it gives me this warning: "ld: warning: cannot find entry symbol rror-limit=0; defaulting to 0000000000100720", and produces a binary whose entry point is `__sparc_get_pc_thunk.l7`
<koakuma>
Anyone has an idea of what's going on?
<mikdusan>
nuke the error option; it differs from ld.lld slightly
<TheLemonMan>
hey koakuma, thanks for testing the patch
<TheLemonMan>
gnu ld doesn't support the -error-limit switch
<mikdusan>
one step forward two steps back. I got dragonfly passing `zig build test` :) but some recent libunwind changes has borked *bsd linking again
<mikdusan>
recent master commits that is
fritchie has quit [Quit: Leaving]
<TheLemonMan>
what's up with your newly-found love for DragonflyBSD?
<koakuma>
TheLemonMan & mikdusan, thanks, linking with GNU ld works now :)
<TheLemonMan>
I'll fix the LLD errors if you upload somewhere all the .o files
<koakuma>
I'll try to upload it somewhere, do you need the system and GCC files too?
nerthus has joined #zig
<TheLemonMan>
only the .o files referenced in your gist
<TheLemonMan>
I guess you've also applied the libunwind patch for sparc
<koakuma>
Oh, I haven't applied that one, sorry
<TheLemonMan>
andrewrk forced the builtin libunwind to be linked even when using the system libc
<TheLemonMan>
but that's not connected to your errors
<koakuma>
Ah also the patch fails to apply to bundled libunwind - it probably needs some updating
bitmapper has joined #zig
nathanael has quit [Quit: connection reset by purr]
v0idify has joined #zig
sm2n has joined #zig
Kingreil has joined #zig
skuzzymiglet has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
nathanael has joined #zig
Kingreil has quit [Quit: Kingreil]
Kingreil has joined #zig
bluekeys has joined #zig
<bluekeys>
Hey peeps. I'm running guix linux and there isn't a package for zig. I'm trying to build zig from source, so I can submit a package, so everyone else using guix can get some zig goodness. Unfortunately, I am struggling to even manually compile zig, likely due to something very obvious. I'm gonna post an error message here, if anyone has any ideas will they please shout back. :)
v0idify has left #zig [#zig]
<bluekeys>
OK. It's at 1% now. I promise it wasn't working last time I tried!
Kingreil has quit [Remote host closed the connection]
amk has quit [Read error: Connection reset by peer]
amk has joined #zig
Kingreil has joined #zig
B767B has joined #zig
pretty_dumm_guy has joined #zig
waleee-cl has joined #zig
tomku has quit [Ping timeout: 245 seconds]
Bernstein has joined #zig
tomku has joined #zig
Kingreil has quit [Quit: Kingreil]
Kingreil has joined #zig
<Kingreil>
bluekeys: did you manage to build it? The error sounds like a llvm version mismatch to me (i haven't built zig though)
hiljusti has joined #zig
<bluekeys>
Still working on it. Kingreil, I think I'm not including headers properly. I don't often build things from source, so I'm just trying things and making notes...
<Kingreil>
Nothing to be ashamed of :) The error you got was during the linking phase (the moment where you get an executable from a buch of .o and library references)
<Kingreil>
So, i'm not sure what's >>exactly<< the error but it looks like you had all the include paths properly set up (the project compiled) but something was wrong with the library paths
<ifreund>
bluekeys: zig requires llvm to be built with support for all targets, depending on where your llvm is coming from this may not be the case
<Kingreil>
ohhhhh that sounds like the problem
<Kingreil>
makes sense, the error is on coff::something
<bluekeys>
Oooh, that sounds interesting. Let me ask in the guix channel, how to tell if I've installed an llvm that was built with support for all targets or not.
<ifreund>
you also need to make sure that your are compiling zig with the same c++ compiler used to compile llvm
<ifreund>
this is probably already the case though if you are using your system compiler
<Kingreil>
don't know how the release cycle of llvm works
<ifreund>
that seems very odd, llvm/clang/lld are all released at the same time
<Kingreil>
they probably forgot to update lld on the package
<Kingreil>
or they are packaging the lib parts of llvm-12 but not the tools (clang/lld/lldb/etc)
<ifreund>
zig links against llvm lld and clang
<bluekeys>
Maybe if I try again, but limit to version < 12?
<bluekeys>
Oh, no that won't work because v12 is mentioned explicitly on the building from source wiki. In which case, maybe I need to get myself a copy of lld 12
<ifreund>
bluekeys: zig master requires llvm/lld/clang all to be version 12
<bluekeys>
I'm just checking in #guix if anyone knows why llvm is 12, but lld maxes at 11 currently.
B767B has quit [Remote host closed the connection]
<Kingreil>
bluekeys: if you change the version in the llvm.scm to 12 it __should__ work i think
<Kingreil>
i don't know a lot of scheme but it seems like they automatically use the llvm version to build clang and the runtime libs
<Kingreil>
probably it was all version-bumped by hand at some point. Somebody automated the process for clang but forgot to do it for lldb, lld, etc
<bluekeys>
I wonder if i can figure how to bump the version. guix edit lld takes me to the build code. I just have to figure how to make the change from 11 to 12
<andrewrk>
mikdusan, because some native libcs depends on libunwind
<andrewrk>
as an example, hello-world.cpp regressed on x86_64-linux-gnu
<andrewrk>
apologies for not running that through the CI first
<mikdusan>
this confused me. it's hybrid mode in that native-libc but instead of native-c++ it's bundled-c++ and then we change how native-libc stuff is linked?
<mikdusan>
ie. we change native-libc linking when not even doing anything with c++
<andrewrk>
native libc does not necessarily imply native libc++
<mikdusan>
right so why then libunwind?
<andrewrk>
because when we switched to native libc I got link errors with libunwind
<mikdusan>
even when building a non-c++ thing?
<andrewrk>
no because if that were the case the CI would have failed
<mikdusan>
this may be a confluence of things. but on *bsd what is happening now to build hello.zig, it's building libunwind and linking it
Bernstein has quit [Remote host closed the connection]
<mikdusan>
ah ok maybe this narrows it down: if using `-lc` then libunwind.a gets built/linked . and that's default mode on *bsd
<mikdusan>
I would think for linux `-lc` building libunwind.a is unecessary too (unless in c++ mode)
<TheLemonMan>
hmm, now that inline is callconv(.Inline) the `noinline` prefix looks out of place
<andrewrk>
tbh i'm not happy with calloconv(.Inline)
<andrewrk>
it's technically not wrong but it feels wrong
<TheLemonMan>
yeah
<andrewrk>
I'll put a up a PR for only building libunwind when linking c++
<mikdusan>
this sounds like a good solve
<TheLemonMan>
oh no, zig fmt is eating the whitespace before a noinline fn
arkurious has joined #zig
<TheLemonMan>
mikdusan, can you try adding -lgcc_eh and removing the libunwind reference from the lld line?
xackus__ has joined #zig
<mikdusan>
for linux or a bsd with gcc?
<TheLemonMan>
should work on both
smorks has joined #zig
smorks has left #zig [#zig]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
smorks has joined #zig
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #zig
smorks has left #zig ["WeeChat 3.1"]
racoon has quit [*.net *.split]
jzelinskie has quit [*.net *.split]
lunamn has quit [*.net *.split]
stilbruch has quit [*.net *.split]
justin_smith has quit [*.net *.split]
Tharro has quit [*.net *.split]
cCCCCcccccCCc has quit [*.net *.split]
jzelinskie has joined #zig
lunamn has joined #zig
Tharro has joined #zig
stilbruch has joined #zig
amk has quit [Ping timeout: 240 seconds]
racoon has joined #zig
amk has joined #zig
smorks has joined #zig
nathanael has quit [Remote host closed the connection]
nathanael has joined #zig
nathanael has quit [Remote host closed the connection]
nathanael has joined #zig
sord937 has quit [Quit: sord937]
novakane has quit [Quit: WeeChat 3.1]
hiljusti has quit [Ping timeout: 260 seconds]
smorks has left #zig ["WeeChat 3.1"]
<shachaf>
ifreund: Do you not have a huge amount of variance benchmarking zig fmt? I did when I tried.
Akuli has quit [Quit: Leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<ifreund>
shachaf: yeah, my benchmarks aren't very scientific. Mostly just wanted to check for any sign of a significant regression which I didn't find
<ifreund>
I did several runs for each and eyeballed one in the middle
<andrewrk>
shachaf, use perf and look at cache-misses, instructions, and cycles
<andrewrk>
those will be more stable
<ifreund>
andrewrk: I posted those perf stats on the PR if you didn't see yet
<andrewrk>
ahh
ur5us has joined #zig
<ifreund>
tldr, not much change: a few more cache misses but fewer instructions and cycles
<shachaf>
andrewrk: I seem to remember doing that and still seeing a lot of variance.
<ifreund>
the main reason I want this is because it would make stepping through the parser in a debugger soooo much nicer
<ifreund>
shachaf: did you see any real difference before and after your change?
<shachaf>
It was too noisy to measure easily.
<andrewrk>
merged
<ifreund>
nice :)
<andrewrk>
76a259799d5bac3effabd1df44c0dec9e4fa16d4 will fix the CI; I'll open the libc++ thing as a separate PR
smorks has joined #zig
<shachaf>
Oh man, merged just like that? I guess that works.
<mikdusan>
TheLemonMan: yes linking this way worked on pre-libunwind.a patches:
<mikdusan>
zig c++ -o main main.cpp -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0 -lgcc_eh
<mikdusan>
and catch() exceptions works too
<mikdusan>
gotta run.
<shachaf>
It might also be nice to do prefix/postfix operators and other things in the same way eventually.
marler8997 has joined #zig
<marler8997>
andrewrk, I'm not sure I understand your comment about not being able to know what the calling convention is
<marler8997>
call(.NoInline) would mean the default calling convention, but you're not able to inline it
<andrewrk>
this would remove the ability to specify noinline + a non default calling convention
zenkuro has quit [Ping timeout: 252 seconds]
<marler8997>
a non default calling convention infers nonline does it not?
zenkuro has joined #zig
<marler8997>
how could you inline a function with a non-default calling convention?
<marler8997>
unless, you're saying that some callers could inline it and some may not?
<marler8997>
so nonline prevent all callers from inlining it, is that correct?
<andrewrk>
correct, noinline prevents all callers from inlining it
<marler8997>
so if a function has a non-default calling convention, some callers can still inline it?
<andrewrk>
I belive the only calling convention that does not allow inlining is naked
<marler8997>
gotcha
<marler8997>
to follow up on the train of thought, what would happen if we made non-default calling conventions imply nonline?
<andrewrk>
what problem are you trying to solve?
<marler8997>
language spec simplification
<marler8997>
if we did that, I think the question would be, are there any use cases Zig couldn't support?
Bernstein has joined #zig
<marler8997>
In the case where you want to emulator todays behavior, you would have to define the function using the default calling convention, then define a wrapper with an explicit calling convention
<marler8997>
given we could emulator today's behavior, I don't think there's any use cases we couldn't support. so we have 2 solutions to compare now
<marler8997>
emulator => emulate
<andrewrk>
can anyone run this command on OpenBSD and tell me the result? `c++ -E -Wp,-v -xc++ /dev/null`
<marler8997>
thinking on it, I can't really tell if it's simpler to keep inline orthogonal to the calling convention or not
<ifreund>
I mean, they are related concepts but also not exactly the same thing
<marler8997>
if we decide to keep it orthogonal, then callconv(.Inline) doesn't make sense
<ifreund>
I'd prefer keeping inline as a keyword for functions, just like noinline
<marler8997>
yeah it seems like Zig could kinda go eitehr way
<ifreund>
we already have inline as a keyword in many other places
<ifreund>
having it *not* work on functions seesm inconsistent
<marler8997>
yeah good point in favor of inline
<marler8997>
if we went back to "inline fn", do you think we should make it an error to specify inline with at least some kinds of calling conventions?
<marler8997>
doing so implies it's not orthogonal, they do seem related but the coupling is a bit odd
<marler8997>
it's like a 45 degree relationship :)
jokoon has quit [Read error: Connection reset by peer]
<marler8997>
I dunno, I'm going back and forth. explicitly forcing a function to always be inlined is actually completely orthgonal to any calling convention
<andrewrk>
inline is a calling convention. it's nice to also be able to configure the calling convention with a comptime value. I think we'll just have both, with a preference for `inline fn` when the value would just be hard coded
<marler8997>
that's not a horrible solution
<andrewrk>
arghh the messiness of libc++ is bumming me out
<marler8997>
I'm sure I will regret asking, but what's the messiness?
outerpassage has quit [Quit: quitting]
outerpassage has joined #zig
<andrewrk>
every system has a different, incompatible libc++, and they have different dependencies on other libraries such as libunwind that don't come with libc++
<andrewrk>
I can't even summarize it, it's just 99 different stupid problems that shouldn't exist that make everything Just Fail To Work
<marler8997>
I once looked into writing dlang bindings to libc++....then I realized the same thing, it was going to be a montrous undertaking
<noam>
Forced inline isn't orthogonal to calling convention, but forced *noinline* is
<noam>
If you're inlining, no other callconv is valid
<noam>
If you're *not allowing inlining*, you can still require a specific callconv
<noam>
It might make sense to specify allowed and disallowed calling convs, instead of a specific callconv to require?
<noam>
e.g. callconv(.{}, .{.Inline}) is noinline, callconv(.{.Inline}, .{}) is the current callconv(.Inline)
<noam>
Or, since two tuples makes no sense:
<noam>
callconv(.Disallowed, .{.Inline}) means "any callconv is fine, but no inlining is allowed"
<noam>
callconv(.Allowed, .{.Inline}) means "only inlining is allowed"
<noam>
callconv(.Allowed, .{.Inline, .SysV}) means "you're allowed to inline or use sysv for any given call"
<ifreund>
what use case does that complexity solve?
<noam>
This also frees up the compiler to produce multiple copies of small functions if doing so is beneficial, which can be the case if differing registerization characteristics make one option better than another in specific call sites
<noam>
ifreund: it more gracefully integrates inline and noinline
<noam>
inline *is* a callconv, but noinline means "don't use callconv .Inline"
<noam>
This generalizes that logic to *all* callconvs, removing a special case for inlining, while unifying the syntax
<noam>
It also means that `noinline fn callconv(.Inline)` can't exist lexically
<noam>
but that's an afterthought
hiljusti has joined #zig
<andrewrk>
oh no, I thought of a valid use case for mixing `zig c++` with system compiled libs