ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
cenomla has joined #zig
cenomla has quit [Remote host closed the connection]
cenomla has joined #zig
cenomla has quit [Remote host closed the connection]
cenomla has joined #zig
hoppetosse has quit [Ping timeout: 252 seconds]
cenomla has quit [Client Quit]
cenomla has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
hoppetosse has joined #zig
jdufault has joined #zig
hoppetosse has quit [Ping timeout: 260 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
SimonNa has joined #zig
jdufault has quit [Ping timeout: 240 seconds]
cenomla has quit [Quit: cenomla]
cenomla has joined #zig
cenomla has quit [Client Quit]
cenomla has joined #zig
cenomla has quit [Quit: cenomla]
davr0s has joined #zig
arBmind has joined #zig
zesterer has joined #zig
arBmind has quit [Ping timeout: 256 seconds]
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 256 seconds]
hoppetosse has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<hoppetosse>
andrewrk: I'm soooo close to getting a win32 framebuffer up
<hoppetosse>
?.c:1:1: note: integer value 2147483648 cannot be implicitly casted to type 'c_long'
<hoppetosse>
?.c:1:1: note: use of undeclared identifier 'int'
<hoppetosse>
I've basically traced the first error to the parsing of an enum which has an element of value -1 and another 0x80000000
<MajorLag>
Huh, I think I am doing more or less the same thing as you. Ran in to the same problem, with CW_USEDEFAULT?
<MajorLag>
translate-c makes a mess of it: pub const CW_USEDEFAULT = if (@typeId(@typeOf(2147483648)) == @import("builtin").TypeId.Pointer) @ptrCast(c_int, 2147483648) else if (@typeId(@typeOf(2147483648)) == @import("builtin").TypeId.Int) @intToPtr(c_int, 2147483648) else c_int(2147483648);
<MajorLag>
I replaced it with: pub const CW_USEDEFAULT = @bitCast(c_int, c_uint(0x80000000));
<hoppetosse>
I think it happenss before that point though
<hoppetosse>
I also get this in the importc output: const __INT_FAST32_TYPE__ = int;
<MajorLag>
oh, wait, that CW_DEFAULT line I pasted says c_int, that must be from a correction attempt because I swear translate-c inserted 'int' instead.
<hoppetosse>
Yeah, I think something goes weird before
<hoppetosse>
Are you importing windows.h with WIN32_LEAN_AND_MEAN?
<MajorLag>
Yep, I have the same line in my windows.h.zig
<MajorLag>
I ran translate-c over windows.h and import it as zig. Lets me manually correct it.
<hoppetosse>
const c = @cImport({
<hoppetosse>
@cDefine("WIN32_LEAN_AND_MEAN", "");
<hoppetosse>
});
<hoppetosse>
@cInclude("stdlib.h");
<hoppetosse>
@cInclude("windows.h");
<hoppetosse>
That cDefine makes a lot of stuff not get included
<hoppetosse>
makes the output a lot smaller with less room for error
<MajorLag>
I just commented out everything but the constants, and I manually go and uncomment the procedures I need since I'd have to manually touch each of them to get them to link properly anyway.
<MajorLag>
translate-c doesn't handle the MAKEINTRESOURCE macro, so it missed a bunch of stuff from winuser.h I had to manually add.
<hoppetosse>
That actually sounds pretty clever
<hoppetosse>
yeah, I had to recreate MAKEINTRESOURCE
<hoppetosse>
I'm gonna try what you did, running translate c and importing as zig without the offending lines
<hoppetosse>
thanks for the idea!
<hoppetosse>
how do I run just translate-c?
<MajorLag>
There are several instances where translate-c inserts "int" as a type for some reason, now that I've searched for it in places Id idn't already touch. Interesting.
<MajorLag>
zig translate-c windows.h
<hoppetosse>
do a regex search for \Wint\W
<hoppetosse>
thanks
<MajorLag>
Yeah, I got them all, I'm just surprised it happens.
<hoppetosse>
Is there any way to define that WIN32_LEAN_AND_MEAN?
<MajorLag>
I'm not aware of a way to do it from the commandline. When I've had to do that I've just created a new header file with the define and then the include of what I wanted
<hoppetosse>
I was running it with --verbose-cimport and piping the output to a file
<hoppetosse>
PS E:\Projects\Tick\platform\framebuffer> zig translate-c windows.hunexpected error from clang: error reading 'windows.h' unable to parse C file: C compile errors
<MajorLag>
interesting, I didn't have any problems with it. Oh, are you sure you're pointing at all the right system include paths?
<hoppetosse>
I didn't specify any, but I'll try that now
<MajorLag>
-isystem "./" -isystem ".../VC/BuildTools/include" -isystem ".../VC/BuildTools/ucrt" are what I've got
<hoppetosse>
No luck =/
<MajorLag>
odd.
<hoppetosse>
I don't have those BuildTools folders
<hoppetosse>
I have them at C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
<hoppetosse>
tried it with 12.0 as well
<MajorLag>
You're using VisualStudio I imagine. I'm just using the BuildTools without VS. I'm not sure where the equivelent VS folders are.
<hoppetosse>
Yeah, pretty sure these are the equivalent ones
<MajorLag>
I can confirm that translate-c doesn't error for me, I just ran it again to make sure I wasn't crazy.
<hoppetosse>
there's a windows.h in there, so...
<hoppetosse>
I'm a few commits behind master, but I dont think anything's been done sice
<hoppetosse>
are you running a debug build or release build?
<MajorLag>
whatever the build artifact is. I'm pretty sure it's release.
<hoppetosse>
Then yeah, same here
<hoppetosse>
I mean, I compiled it, but it's release
<MajorLag>
0.1.1.1c1c0691, alsoa few commits behind
<hoppetosse>
Could you send me your windows.h.zig?
<MajorLag>
in addition to the include with windows.h, you also need the base one (contains stdint.h) and ucrt one (contains wchar.h)
<MajorLag>
Sure, one sec
<MajorLag>
It's ~63k lines.
<hoppetosse>
Yeah, nevermind
<hoppetosse>
let me make sure those other files are there
<MajorLag>
I don't know if it will apply to you or not, but I get "error: link error" when building with that unless I manually designate where each extern fn comes from and make it stdcallcc. Which is why most of them are commented out.
hoppetosse has quit [Ping timeout: 268 seconds]
hoppetosse has joined #zig
davr0s has joined #zig
<hoppetosse>
MajorLag: Well, at least now I'm not getting import errors, but the compiler crashes =)
<hoppetosse>
MajorLag: Well, at least now I'm not getting import errors, but the compiler crashes =)
<hoppetosse>
(sorry, wrong window)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<hoppetosse>
And now at least it doesn't crash, but I'm getting a linking error.
<MajorLag>
Is it "error: link error"? I get that with the older version of LLVM unless I go in and manually make the extern fns specify the library they're in and mark them stdcallcc. pub extern "user32" stdcallcc fn CreateWindowEXA(....
hoppetosse has quit [Remote host closed the connection]
hoppetosse has joined #zig
hoppetosse has quit [Read error: Connection reset by peer]
davr0s has quit [Ping timeout: 256 seconds]
MajorLag has left #zig [#zig]
MajorLag has joined #zig
MajorLag has left #zig [#zig]
MajorLag has joined #zig
<MajorLag>
Is there a way to make lld not treat all warnings as errors?
<andrewrk>
I would need to add a way to pass linker args with the zig command line, or decide that we should default to that setting on windows
<andrewrk>
what are you running into?
<MajorLag>
That was going to be my follow up question.
<MajorLag>
Eh, just playing around trying to build against MinGW64 libs. Supposedly they fixed this issue with -aligncomm in .drectve at some point, but not in this one. It'd be fine if I could tell LLD to just ignore it, though I'm pretty sure the next thing I'll run into is "error: link error"
cenomla has joined #zig
Tobba has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
<andrewrk>
MajorLag, what's stopping you from using the llvm6 branch?
<andrewrk>
(sincere question - maybe I can help you get it working)
<andrewrk>
do you need a pre-built binary for llvm? or do you need me to make the llvm6 appveyor artifacts work?
<andrewrk>
Hejsil, yeah that's still not supposed to be allowed. You're successfully creating an identifier named "type" but that conflicts with the existing "type" identifier. same error for trying to declare a variable with the same name twice
<MajorLag>
I'd rather have the artifacts work, but it isn't a big deal. Though if you know of a place I can get a prebuilt llvm6 for windows I can compile to obejct and link with that to see if it works.
tridactyla has quit [Remote host closed the connection]
tridactyla has joined #zig
<jacobdufault>
andrewrk: curious if you have any thoughts on go vs zig language design (ignoring the fact that go is not really targeting a similar performance model), it seems like the languages have some shared ideals/goals w.r.t. simplicity
<MajorLag>
Thanks andrewrk, I'll maybe take a look at that in the near future.
<andrewrk>
jacobdufault, my main complaints about go are: hidden memory allocation which it is impossible to check for failure, tedious and therefore easy to bungle error handling, lack of generics
<andrewrk>
also, I *just* finished async/await support in the async branch, which I will be merging later today. I think this is a better concurrency model than goroutines
Ichorio has quit [Quit: Leaving]
hoppetosse has joined #zig
<hoppetosse>
MajorLag: Yeah, that's the error
<hoppetosse>
I'll keep y'all posted =)
zesterer has quit [Quit: zesterer]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]