ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
arBmind has quit [Quit: Leaving.]
return0e has joined #zig
btbytes has joined #zig
btbytes has quit [Client Quit]
cenomla has joined #zig
isd has quit [Quit: Leaving.]
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]
cenomla has quit [Quit: cenomla]
cenomla has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
jordyd has quit [Ping timeout: 246 seconds]
cenomla has quit [Quit: cenomla]
davr0s has joined #zig
mal`` has quit [Quit: Leaving]
mal`` has joined #zig
return0e has quit [Ping timeout: 264 seconds]
epsyloN has joined #zig
ice1000 has joined #zig
zesterer has joined #zig
<ice1000>
Hi
<ice1000>
Anybody here
<ice1000>
How do you guys write Zig
<ice1000>
With notepad? With the plain text editing mode of some IDE?
jfo has joined #zig
samthetechieQQYS has joined #zig
samthetechieQQYS has quit [Client Quit]
steveno_ has joined #zig
<MajorLag>
I write in Notepad++ with a UDL, no idea.
<MajorLag>
*ide
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jfo>
I use vim, we've got pretty good syntax coloring support and eventually I'll get around to indenting etc type plugin stuff... https://github.com/zig-lang/zig.vim
<MajorLag>
That reminds me, I should get arround to uploading my Npp Zig UDL somewhere. My color scheme looks a bit like unicorn vomit, but of course that's user configurable.
<ltr_>
andrewrk: can you point me where to read the details on how are you going to implement async await? what are you going to use internally (epoll/kqueue) reactor pattern?etc..
<andrewrk>
ice1000, I use vim
<andrewrk>
MajorLag, unicorn vomit color scheme sounds incredible
<andrewrk>
MajorLag, mind if I throw this up in a repo and put it under the zig-lang org?
<MajorLag>
Not at all.
<MajorLag>
That goes for anything I throw on zig.tgschultz.com
<andrewrk>
cool
<andrewrk>
oh neat, you have a unicode library complete with documentation
<MajorLag>
"complete"
<MajorLag>
I'd have put this all on git, but I don't use it as part of my normal process and I'm lazy.
<andrewrk>
I linked to your site on ziglang.org
<andrewrk>
at some point I'll have the package manager working well and there can be a nice home for your library
return0e__ has joined #zig
<Hejsil>
andrewrk, sooooo, what is the type signature of an async function? Zig tells me this: @compileLog(@typeOf(SliceFn.it)); -> fn(&const []const u8,?&u8)var
<Hejsil>
This is SliceFn.it: async fn it(context: &const []const T, item: ?&T) void
<andrewrk>
that's a bug, it should have `async` before it
<andrewrk>
oh I see what's happening
<andrewrk>
what's going on is that async functions require, as part of their type, the allocator struct type
<andrewrk>
like this: async(AllocatorType) fn() void
<Hejsil>
Aaaaah
<andrewrk>
but you're allowed to leave it off and it gets inferred. but that makes it generic
<andrewrk>
and then the bug is that generic async fn type name didn't get the async keyword
<Hejsil>
I see
<andrewrk>
I think in practice everybody is going to use std.mem.Allocator
<andrewrk>
but zig the language has no dependency on the standard library
<andrewrk>
and I didn't want to break that
<Hejsil>
Ye, I can understand? So the generic allocator just need an "alloc" and "free" function?
<andrewrk>
yes. although right now, those are named `allocFn` and `freeFn` and must be function pointers
<andrewrk>
I may change this to be less esoteric
<Hejsil>
I see. I wanted to implement something simular to C# Linq with coroutines, but I might just have come up with at better way to do it without them
<Hejsil>
Oooh well, I'll play with couroutines another day
MajorLag has quit [Ping timeout: 245 seconds]
steveno_ has quit [Quit: Leaving]
<jordyd>
I'm running macOS 10.13.3 (High Sierra) and I've installed zig via Homebrew. `zig targets` lists my native environment as "unknown". Is this normal?
hoppetosse has quit [Ping timeout: 264 seconds]
<andrewrk>
jordyd, that is correct. although perhaps "unknown" should be renamed to "nonspecial"
<jordyd>
Ah ok
<jordyd>
What are the environments, btw? They appear to be ABIs?
<andrewrk>
that is correct
<andrewrk>
it's an LLVM concept
<andrewrk>
it has to do with the C ABI
<andrewrk>
maybe that would be a good thing to rename it to: Environment -> C ABI
<andrewrk>
and then "unknown" -> "unspecified" or "generic"
<jordyd>
Generic sounds best to me
<jordyd>
So what would x86_64-elf translate to? arch=x86_64, os=freestanding, env=gnu?
<andrewrk>
x86_64-elf according to gcc?
<andrewrk>
I believe "elf" translates to "eabi"
<andrewrk>
freestanding? are you working on an OS or embedded device?
<jordyd>
Yeah
<andrewrk>
cool
<jordyd>
GCC calls it x86_64-elf, which is short for x86_64-pc-none-elf I think
<andrewrk>
I would try arch=x86_64, os=freestanding, env=eabi first
<andrewrk>
I think the environ part doesn't matter much when you're doing an OS because you don't interact with C code
<jordyd>
Well, I suppose you wouldn't have to worry about it given anyone using C on your OS would just target whatever ABI you're using
<jordyd>
GCC also has an *-eabi which is used for ARM (i.e., armv6-eabi)
<andrewrk>
I believe in this case armv6 refers to the arch, not the environ
<andrewrk>
you can see armv6 in `zig targets`
<jordyd>
Yeah, I mean armv6-eabi would be the target
<jordyd>
GCC formats their targets as arch-os-abi mostly
<jordyd>
Does LLVM have documentation somewhere on their "environment" concept?
<jordyd>
Wait, actually, I should be able to ignore the environment and just use "extern" in places where it matters
<andrewrk>
I'm not sure exactly what you mean, but if you're running into a specific problem and you can show me some code or output, I can provide suggestions
<jordyd>
Basically if I define some function in assembly as `foo` and want to reference it from Zig, would `extern "c" fn foo(): return_type;` work?
<jordyd>
Basically I need to either 1) match or disable name mangling and 2) match calling conventions. C++, for example, will disable name mangling and use C's calling conventions by declaring a function as `extern "C"`
<andrewrk>
yes that will work. that will give the function the C calling convention
<andrewrk>
there is no name mangling
<jordyd>
Ah ok
<andrewrk>
you can also use a naked function in zig and inline assembly
<Hejsil>
cquery for vscode uses a spectrum of colors for highligting
<Hejsil>
Idk why
<andrewrk>
but it should use the same color for the same kind of thing right?
<Hejsil>
Nono, a spectrum for the same things
<andrewrk>
odd
<Hejsil>
Different shades of blue for enums in your case
<Hejsil>
There is an option to change the color
<Hejsil>
Or, the array of colors*
<jacobdufault>
rainbow semantic highlighting
<Hejsil>
The best
<jacobdufault>
:), I liked the feature from kdevelop
<Hejsil>
So you can see the different between SomeLargeTypeA and SomeLargeTypeB without reading their names? :)
<Hejsil>
That's really the only benifit I can think off for different colors of the same semantic category (or whatever you call it)
<jacobdufault>
I think it's most useful on variables so you can see how a variable flows through a function
<Hejsil>
Aaaah, that makes sense
<jacobdufault>
Maybe it should be off by default for other tings
<jacobdufault>
things*
<Hejsil>
cquery for Zig when? :)
<Hejsil>
Was
<Hejsil>
the json PR for cquery, or ctag or how was that
<jacobdufault>
the json PR is for cquery
jfo has joined #zig
<Hejsil>
I don't remember the specific usecase
<Hejsil>
Aah, nice
btbytes has joined #zig
<jacobdufault>
I have to write an indexer in cquery though for the json, but it should be pretty straight-forward, plus probably some refactoring since this will be the first non-clang client