ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<bbrittain>
makes sense to me
<bbrittain>
what's the mach-o lld stuff I've been seeing you do all about ? andrewrk
mnoronha has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mnoronha has quit [Ping timeout: 268 seconds]
mnoronha has joined #zig
darithorn has quit [Quit: Konversation terminated!]
mahmudov has quit [Remote host closed the connection]
kmelva has joined #zig
mnoronha has quit [Ping timeout: 244 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
geocar has quit [Quit: Connection closed for inactivity]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 272 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ichorio has joined #zig
davr0s has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 246 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
Jenz has joined #zig
<Jenz>
Congratulations on 0.3.0 release!
<Jenz>
Bit late I know, but I’ve been away (and still am)
Jenz has quit [Ping timeout: 256 seconds]
edr has joined #zig
noonien has joined #zig
<andrewrk>
bbrittain, the macho lld code is essentially unmaintained, and can't handle a lot of simple linking tasks
<andrewrk>
plus LLD in general does not do incremental linking (nor is that planned), which is going to be a necessary component of zig's plan for Super Fast Debug Builds (TM)
<andrewrk>
bkleiner, I'm having a look now
<andrewrk>
bkleiner, I'm hitting a similar issue right now myself. my plan of attack here is: (1) redo coroutines (2) start adding race detection / other concurrency debugging features until I discover the bug
<bkleiner>
andrewrk, that make sense, i did some more digging and noticed that if i increase the buffer size here https://github.com/ziglang/zig/blob/master/std/event/loop.zig#L648 that i actually get two events for the last "event loop cycle". one with a stop node and one with the read-ready event. the order seems to be somewhat random, which would explain why the issue is somewhat transient.
mnoronha has joined #zig
<andrewrk>
bkleiner, yeah. the main issue is that I built a lot of abstractions on top of a coroutines prototype, to get a feel for how coroutines should work. and that project succeeded in that now I know what to do in the coroutine rewrite. but status quo is that there are bugs and race conditions
<andrewrk>
I think we're going to want a lot of fuzz testing in the multithreaded async I/O code
<bkleiner>
probably, yeah :)
<bkleiner>
also: i really like the coroutines interface so far. it seems to be somewhere in the middle between golang and rust. well done. im really looking forward to using it in a more "real life" application.
<bkleiner>
(although: some syntax sugar for `await try async` would be a nice to have)
<andrewrk>
bkleiner, in the rewrite, async can't fail
<andrewrk>
`await async` chain together in the same way, but error.OutOfMemory is not possible
<andrewrk>
also they sadly require initialization at runtime, which means you can't initialize them by simply setting their fields to static data
jmiven has joined #zig
<euantor>
https://github.com/ziglang/zig/issues/1626 - I've not really touched Zig at all, this is my first time looking at it but I'll try and submit a patch to add some validation of the `urandom` file and to add support for some other operating systems (FreeBSD & OpenBSD) if that's ok
<andrewrk>
hi euantor
<andrewrk>
that sounds nice
<andrewrk>
the biggest blocker for other OS support is lack of a way to run continuous integration tests
<euantor>
Awesome. I may be asking some questions in here when I get a chance to actually look at it
<andrewrk>
if we had CI tests for openbsd/freebsd I would add support for it in a heartbeat
<euantor>
Regarding CI, would a standard Jenkins setup not work?
<andrewrk>
I'm sure that could work fine, but it's a lot of work to set up and nobody has done it
<andrewrk>
and then there's the question of where are the server(s)?
<euantor>
The Jenkins agent should run on both Open and Free BSD. I might look at getting something running if nobody else is looking at it.
<halosghost>
hmm, I wonder if qemu could be used for that
<halosghost>
just be like a roll-your-own docker really
<euantor>
I've been playing with Nim for a while and they got some DigitalOcean credit donated to pay for site hosting and build servers - might be worth trying that route?
<euantor>
I've no idea how they applied for it or anything though
<andrewrk>
I don't think digital ocean has freebsd/openbsd
<andrewrk>
err, sorry, I'm thinking of non-x86 architectures
<euantor>
They have FreeBSD for sure, and I think they allow you to bring your own ISO these days
<andrewrk>
I'm getting this conflated with ARM
<euantor>
hah, easy done
<euantor>
https://openbsd.amsterdam/ are extremely cheap too, but would mean a fairly underpowered build agent
<andrewrk>
anyway, if someone makes it easy for zig to know if master branch pushes & pull requests break X, then we can add X support
<euantor>
ok, I'll have a look and see what I can do over the course of this week/end
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tankf33der has left #zig [#zig]
davr0s has joined #zig
<bbrittain>
andrewrk: I only ask because our toolchain team knows who you are because of that work
<bbrittain>
they appreciate it :)
<bbrittain>
also, why would you self host a jenkins instance? Wouldn't travisci give you free instances?
<andrewrk>
travis ci doesn't have openbsd/freebsd
<andrewrk>
there's also ARM and other architectures to solve
<andrewrk>
if you try to do something fancy like qemu on travis you hit the 1hr timeout
<andrewrk>
the azure people promised us 6 hour timeouts, so that might be something to look into
<andrewrk>
if I had a bigger office I'd just buy a bunch of servers and install various combinations of hardware, and run my own build bot cluster
<bbrittain>
oh dear, supporting *bsd is way more effort than it's worth
<bbrittain>
mark it as a tier-3 platform and move on :)
<andrewrk>
it'll have good support, it's just not a priority until the language gets closer to 1.0.0
darithorn has joined #zig
jjido has joined #zig
jmiven has quit [Quit: co'o]
jmiven has joined #zig
Hejsil_ has joined #zig
<Hejsil_>
Hmmm. Seems like you can't take `@typeOf(unreachable)`
<Hejsil_>
error: unreachable code
Hejsil has quit [Quit: Page closed]
<andrewrk>
that's right - @typeOf() takes an expression
<andrewrk>
and evaluating an expression can't hit unreachable at compile-time
Hejsil_ has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hejsil has joined #zig
<Hejsil>
Well, @typeOf doesn't evaluate the expression though
<Hejsil>
And isn't unreachable of type noreturn?
<andrewrk>
it does evaluate the expression
<Hejsil>
How does that work for runtime values?
<Hejsil>
var a: usize = 0; @typeOf(a); works
<Hejsil>
but a can't be comptime evaluated
<andrewrk>
hm I think "evaluation" is an ambiguous term in zig
<andrewrk>
I'm thinking
<Hejsil>
Well, Zig can clearly typecheck unreachable, so it's kinda weird that @typeOf doesn't work
<andrewrk>
hmm I think you're right
<Hejsil>
I'll report it as a bug then :)
jjido_ has joined #zig
mnoronha has joined #zig
jjido has quit [Ping timeout: 252 seconds]
mnoronha has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
mnoronha has quit [Read error: Connection reset by peer]
mnoronha has joined #zig
dimenus has joined #zig
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus>
andrewrk: going to try to call COM from zig
<dimenus>
hopefully build some directx code
<Hejsil>
andrewrk, are we going to wait for stage2 before making anymore breaking syntax changes?
<Hejsil>
Was considering working on #760 followed by tuples
<andrewrk>
dimenus, interesting, doesn't that require C++ API?
<andrewrk>
Hejsil, nah you can break syntax
<andrewrk>
breaking is kind of always OK, because you can do it in 2 phases
<Hejsil>
1. Break everything. 2. Make Zig fmt fix it!
<Hejsil>
Idk if these are the actual phases
<dimenus>
Yes it is a c++ api, but one of Jon Blow's employees wrapped directx in JAI directly
<dimenus>
so in theory we should be able to do the same
<andrewrk>
haha :)
<andrewrk>
dimenus, interesting, let me know what problems you run into
<dimenus>
that's my intent :D
<andrewrk>
Hejsil, what's your proposal for changing syntax to fix #760?
<dimenus>
personal life is finally settling down a bit, so I hope to work on a lot more projects in the next couple months
<Hejsil>
Ye, it seems that's what ended the discussion
<Hejsil>
And I like it
<Hejsil>
Though, error.{} requires an extra lookahead to parse
<andrewrk>
I think thejoshwolfe pointed out that this proposal still doesn't let us get rid of () in if, while, for, etc, but I don't know if he pointed that out publicly. I'll ask him
<andrewrk>
I'm still ok with the `.` solution to the syntax ambiguity though
<andrewrk>
I guess maybe let's keep the removing () as a separate thing, unless you want to take on extra scrutiny in these changes, in which case, go for it :)
<Hejsil>
My goal is not to fix if (), but to fix the return type problem, and then start looking into how we can best do tuple literals (maybe anonymous literals)
<Hejsil>
^ Exactly
<andrewrk>
one use case that i want tuples to solve is multiple return values from a block going into multiple variables
<Hejsil>
Yes plz
<andrewrk>
I think it is tightly coupled with the return value elision issue. for example:
<andrewrk>
var a, const b = blk: {
<andrewrk>
break :blk [value1, x + y];
<andrewrk>
in this case, the codegen should be a = value1; b = x + y;
<andrewrk>
no other value copying should happen, it shouldn't really even have to create a tuple
<andrewrk>
anyway that's how I'm thinking about it. we probably still have to think about the possibility of tuples represented in memory, because it will probably be allowed to have them in struct fields. right?
<andrewrk>
even though the main use cases are multiple return values and multiple arguments
<andrewrk>
and this is tied into the new coroutines rewrite
<andrewrk>
var frame = async foo(); // the memory pointer from the frame variable goes to async to be used as the memory to execute foo
<andrewrk>
it seems the next major iteration of zig's syntax/semantics is a lot of things at once. it's going to be a difficult but rewarding set of changes
<Hejsil>
Looking forward to trying async/await once it's more finalized. I've kinda just kept my distance until the idea proved it self
<andrewrk>
it's a game of pick up sticks, and I actually think that #287 is on the top
<andrewrk>
Hejsil, anyway, I do think #760 is independent. go for it :)
<Hejsil>
Already did. I actually implemented most of phase 1 before asking
<Hejsil>
Which might not have been the best idea, but
<Hejsil>
It seems it worked out
<andrewrk>
:)
davr0s has joined #zig
unique_id has joined #zig
mnoronha has quit [Ping timeout: 244 seconds]
unique_id has quit [Remote host closed the connection]
mnoronha has joined #zig
very-mediocre has quit [Quit: Page closed]
mnoronha has quit [Ping timeout: 260 seconds]
Hejsil has quit [Quit: Page closed]
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
jjido has joined #zig
Ichorio has quit [Ping timeout: 252 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<MajorLag>
dimenus: I think alexnask wrote a COM implementation already... but I can't find it in his gists so maybe I'm mistaken.
<MajorLag>
part of me can't help but think the #760 syntax is specifically designed to drive Allman brace users crazy. I'm sure I'll get over it.
mnoronha has joined #zig
<andrewrk>
oh, is that where you put it on the next line?
<andrewrk>
I think the . is unfortunate, but, it's more important to fix the ambiguity
<MajorLag>
yes, Allman braces are in the same column as their pair. It's not that big a deal, you can't reasonably be expected to accomodate these sorts of preferences .
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
tom1998 has joined #zig
<tom1998>
Heyo
<tom1998>
Last night I was having an issue @cIncluding the enet library - I tried it with translate-c, and got this src file:
<tom1998>
This fails to compile, since there are 2 definitions of suboptarg in the generated file
<tom1998>
on linux, this isn't an issue! suboptarg seems to be a mac-specific variable, since it only pops up in the apple developer OS docs
<tom1998>
This is pretty much as far as I can go with this, it should be noted that enet compiles fine with C
<tom1998>
I think the current workaround is going to have to be to create a C wrapper, then import THAT - unless there's something in zig that can be done?
<tom1998>
Potentially I can run translate-c to create a .zig file, manually doctor that, then @include normally? Is this normal for broken @cIncludes?
<andrewrk>
thanks for the example tom1998
<andrewrk>
I'll make an issue for this
<andrewrk>
in the mean time, why not edit the generated .zig code to fix the problem with suboptarg?
<andrewrk>
as opposed to creating a C wrapper and using that?
<tom1998>
yeah, as mentioned i think i'll do that, bit of a pain to commit to the repo but maybe i can do some hackery with makefiles & git diff;)
halosghost has quit [Quit: WeeChat 2.2]
<tom1998>
super cool that translate-c is exposed as a cli option though!
<andrewrk>
you can think of it as an .h file with better pointer support
<tom1998>
ahhhh ok, ta
<tom1998>
whilst i'm here bugging you with questions, what's the difference between *, [*], [X] and []?
<tom1998>
(I understand [] and *, it's mainly the other two)
<andrewrk>
I hope I answered this in the docs. let me see if that's true