<m3t4synt4ct1c>
I'm super excited about zig - I've been very impressed with it so far. I'd like to help out. I contribute to the patreon and am toying with ideas for small projects that would be helpful. my background is in security, network software, some embedded stuff, and distributed systems
<hryx>
m3t4synt4ct1c: that's awesome! welcome
<hryx>
there's going to be a need for network stuff for sure, although it's semi-blocked on a big upcoming language change around asynchronicity
<m3t4synt4ct1c>
yeah, I see andrew needs to work out copy elision, then re-do coroutines to enable async/await w/o LLVM before it's worth writing any networking code. I'd be happy to help with a HTTP implementation
<m3t4synt4ct1c>
I noticed the crypto libraries have a bunch of hash functions, but no AES implementation or anything. I guess linking to C code for that isn't the worst thing in the world, but that code wouldn't need any networking I/O
<m3t4synt4ct1c>
I'm interested in a possible IPFS implementation down the line as a possibility as well
<hryx>
that sounds cool
<hryx>
and AES in zig is definitely going to be worthwhile
<m3t4synt4ct1c>
that's a ton of work, but having zig native IPFS would be really cool and provide redundant implementations in the WASM and other targets
<m3t4synt4ct1c>
ok, cool, I'll poke around with that some
<hryx>
sweet. Nothing in stdlib will link to C libs (and I could easily see AES in stdlib) except where required by the OS (e.g. macos's libSystem)
<hryx>
((I think))
mikdusan has joined #zig
m3t4synt4ct1c has quit [Ping timeout: 256 seconds]
jevinskie has joined #zig
hoppetosse has quit [Ping timeout: 246 seconds]
_whitelogger has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
a_chou has joined #zig
a_chou has quit [Client Quit]
ltriant has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
scientes has quit [Ping timeout: 244 seconds]
<daurnimator>
I wouldn't trust a TLS implementation with less than 5 years in the wild. Whatever solution is chosen for TLS in the stdlib, the implementation needs to be swappable for OpenSSL, SChannel, etc.
<hryx>
daurnimator: what about after an audit by a reputable organization?
<daurnimator>
hryx: maybe after 3 audits....
<daurnimator>
hryx: OpenSSL had tens/hundreds of audits before it stopped being full of bugs...
<hryx>
A very healthy sense of caution. I like it :>
<daurnimator>
(it still is; but they're on unused codepaths)
<daurnimator>
One other notable TLS implementation we should support is in-kernel TLS :)
<hryx>
In kernel TLS? Hmmm
<daurnimator>
That doesn't cover negotiation/setup though: only certain ciphers after the connection is setup
<hryx>
Interesting! Meanwhile, Google wants to move TCP *out* of the kernel and into planet user
<hryx>
Er, that's what I assume anyway, based on them making SPDY
<hryx>
wait, no, QUIC
<daurnimator>
otherwise I spent far too much time (after discussion in #musl) designing APIs to take advantage of urings (coming in kernel 5.1). Article from January (there are several changes since): https://lwn.net/Articles/776703/
<hryx>
Hey daurnimator I've been meaning to ask. What do you foresee as the primary use case for a zig PEG? Mainly ask because you proposed adding it to stdlib
<hryx>
(besides lpeg reimplemented in zig. which would be S L I C K O)
<daurnimator>
hryx: well... parsing anything of finite length
<daurnimator>
hryx: http header fields was my intended application
<tyler569>
are http headers that complicated? o.o
<hryx>
ah right. Let me look back at the logs and find the link you posted to complex headers
<daurnimator>
hryx: but can be used for e.g. parsing urls; all sorts of various input formats people pipe around, etc.
<tyler569>
ah. silly me to think someone would make a simple protocol
<hryx>
hyper simple transfer protocol
<tyler569>
back to gopher anyone?
<tyler569>
(the kinda-like-http-but-simpler protocol, not the mascot)
<hryx>
heh! why not
<hryx>
oh hey tyler569 I just got onto the asm part of the new parser
<hryx>
I think it should fix the syntax-related issue you found on saturday
<tyler569>
sweet
<hryx>
That is, if this failing_allocator issue ever gets demystified
<hryx>
one must keep hope & a stiff upper lip
<tyler569>
let me see if I can get llvm to build here, I'd be happy to take a closer look at it if I can
<hryx>
oh awesome, that would be amazing. That reminds me, I owe you an eyeball on an issue you sent me
<tyler569>
I think that was just the asm parsing, no?
<hryx>
looking closer at the link you sent... yep. Is that covered by the GitHub issue then?
<tyler569>
No, this one was the 'expected % or [' parse error, I only reported the crash so far
<hryx>
gotcha
<tyler569>
(while I wait for llvm to twiddle it's thumbs) it occurs to me that I should probably minimal-example those blocks I sent you, since that find was pretty knarley
<tyler569>
who knows what the parser was doing 20-odd erorrs deep
<hryx>
heh. maybe post in this channel in case there is another assembly witch who can help?
<hryx>
(slash parser witch)
<tyler569>
ok, so pulling them out, massaging them a little both seem to work
<tyler569>
with the exception of the fact that zig doesn't seem to support anything more complicated than an identifier in the ()'s, which breaks a lot of my assumptions in the OS
<tyler569>
but that seems like a pretty clear "hey I know the syntax isn't done but asm blocks should do this thing that C can do"
<tyler569>
and my llvm build keeps exploding
<tyler569>
something is sending SIGKILL to the linker which makes very little sense to me
<hryx>
o no, is LLVM build blocking you rebuilding the zig compiler on the fly?
<tyler569>
well because you need llvm built with the same toolchain you're working with, right?
ltriant has joined #zig
<tyler569>
since I haven't been working on zig my workflow up to this point has been to nab the most recent version uploaded out of CI, so I'm new to this part
<hryx>
dang. I've had luck with getting LLVM via system package manager, but I know you actually found BUGS in LLVM doing this, so building from scratch is probably the right choice for you
ltriant has quit [Ping timeout: 244 seconds]
<tyler569>
welp, I was going to try the nightly deb from llvm, but that requires a libc version that conflicts with my system
<tyler569>
>.< I may have to rain check this until I run the 19.04 upgrade I was planning on doing tomorrow
<hryx>
22 commits this weekend. We're almost there! Now that I'm sweating from all this backspacing, time for bed
<daurnimator>
mikdusan: 6 bytes I think
<daurnimator>
oh no. 7.
<mikdusan>
i'm fairly certain the global sticks around for consecutive tests
<daurnimator>
it fails only on windows. I thought it might have been because of that lack of HeapFree issue recently; but I rebased the PR and it still happeneded.
<mikdusan>
it does say OutOfMemory. is there reason to distrust that error log?
<daurnimator>
mikdusan: I (mostly) trust the error. But I'm not convinced it is caused by an issue in the PR; but instead due to a bug in the allocator; possibly only when in a windows environment.
<daurnimator>
so looking for someone to help via one of: A. spotting an error in my logic. B. trying to replicate on their own windows machine. C. tell me about some other experience where a similar OutOfMemory error occured when running the test suite
<Sahnvour>
I was thinking a debug allocator should be implemented this way, as an agnostic wrapper over the actual allocator
scientes has quit [Remote host closed the connection]
scientes has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
<daurnimator>
It's also generally useful for observing allocation patterns
scientes has quit [Ping timeout: 250 seconds]
hoppetosse has quit [Ping timeout: 246 seconds]
<Sahnvour>
yep, can make many great tools off it
ltriant has joined #zig
ltriant has quit [Ping timeout: 244 seconds]
<daurnimator>
wait.. does errdefer run at end of block? or end of function
slugm has quit [Remote host closed the connection]
<very-mediocre>
errdefer should run at the end of scope afaik
<daurnimator>
okay thats really cool... and also I need to fix some things
hio has quit [Quit: Connection closed for inactivity]
hoppetosse has joined #zig
scientes has joined #zig
ManDeJan has joined #zig
Zaab1t has joined #zig
wilsonk has quit [Ping timeout: 246 seconds]
hio has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
wilsonk|2 has joined #zig
Zaab1t has quit [Quit: bye bye friends]
<Xe>
how do i create a null pointer?
<tyler569>
?*T is the nullable pointer type, like `var foo: ?*i32 = null;`
<tyler569>
hryx: I have a working toolchain! I assume you're working off the stage2-recursive-parser branch in your repo?
<hryx>
tyler569: ah sweet! Yep, that's the right branch
<hryx>
Although, I think where I left off last night caused a different error. You might need to put a custom (simple) test at the top of std/zig/parser_test.zig to reproduce the memory leak thing
<tyler569>
ok, yeah I saw there was something different happening. I'll play around with it today
<Xe>
tyler569: i found out how to do what i needed: @intToPtr([*]const u8, 1)
<Xe>
i needed to pass a syscall an intentionally invalid pointer
ManDeJan has quit [Ping timeout: 255 seconds]
<hryx>
tyler569: great, definitely let me know how that goes. When I get a sec I'll fix the new error
<hryx>
(alternatively rolling back a few commits should also work in the meantime)
ManDeJan has joined #zig
<Xe>
how would i allocate a struct with an allocator?
ManDeJan has quit [Ping timeout: 258 seconds]
very-mediocre has joined #zig
<Sahnvour>
Xe, use `allocator.create(<your type>)`
<Xe>
Sahnvour: and to free it?
<Sahnvour>
`allocator.destroy(ptr)`
<Xe>
thanks
Sahnvour_ has joined #zig
Sahnvour has quit [Ping timeout: 246 seconds]
Sahnvour_ has quit [Quit: Leaving]
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
<Xe>
andrewrk: if i want to build zig on my own hardware, how much ram does it need? I'd be using this Dockerfile: https://github.com/ziglang/docker-zig
wootehfoot has joined #zig
fengb_ has joined #zig
<fengb_>
Xe: I've been using 2GB for all of Docker. I've seen each cc instance climb up to ~400-600mb but I haven't noticed any problem with -j4
very-mediocre has quit [Ping timeout: 256 seconds]
<mikdusan>
fengb_: on linux using gcc to build llvm+clang, i usually see ~500mb per job, except for clang there are a handful of files that go >1.0gb (1.5gb iirc) for compile jobs
<mikdusan>
(gcc building clang)
<fengb_>
Yeah LLVM and clang are a doozy, but the docker instance works around that pretty well
<donpdonp>
ive read the feature list, and it has very interesting features, but ive never used it.
<donpdonp>
/j #ponylang
wilsonk has joined #zig
<scientes>
Xe, zig stage1 needs at least 4GB
<Barbas>
More on the level of if you've heard of it and what it's about. It looks interesting.
wilsonk|2 has quit [Ping timeout: 255 seconds]
<scientes>
eek, i like zig because it doesn't get in the way
<Barbas>
Yeah I'm not sure how interesting it is to use, but I'm curious how they solve the concurrency data-sharing problem
<Barbas>
But I'm already confused =D
wilsonk has quit [Ping timeout: 255 seconds]
<mikdusan>
they make everything either immutable when shared, or mutable when isolated (private)
<mikdusan>
the immutable-sharing memory is managed with a garbage collector
<Barbas>
Hmm...
<Barbas>
Not a fan of garbage collectors.
<mikdusan>
and the other big piece is the actor model. and mutable/isolated data is wrapped in an actor that permits shared access
<companion_cube>
so it's like Erlang but compiled to native?
noonien has joined #zig
<fengb_>
Without the failfast model
<companion_cube>
like, no monitors? :/
<fengb_>
No crashes
<fengb_>
Not sure how a supervisory tree would look
<fengb_>
I think Erlang is the only language that embraces errors as an "acceptable" thing. Everything else that's tried actors also tries to fix errors in different ways
<companion_cube>
grr, can't find any form of reference for their lang online -_-
<Barbas>
For Pony?
<companion_cube>
yeah…
<Barbas>
I don't know. They seem to have a million things explained. Like how to get performance, package manager, how to build on ten different Linux distributions etc, but nothing basic about the language itself.
<companion_cube>
oh well.
noonien has quit [Read error: Connection reset by peer]
<Barbas>
Ah nice, somehow I didn't manage to find that =/
fengb_ has quit [Quit: Page closed]
<companion_cube>
seems a lot like Erlang's actors, at least in terms of overhead
<companion_cube>
256B for an actor, neat
<hryx>
Yeah, with the zig 0.4.0 release people were like "you need to have a code snippet on the landing page of your website" -- after looking at the pony site I agree with that
<companion_cube>
also, you need to have a single entry point for the whole docs
<companion_cube>
yeah, I didn't mean Zig didn't do it well
<donpdonp>
whats the build.zig equivalent of zig --verbose-cc
<donpdonp>
im trying to get a dump of the imported structs from an included .h file
<donpdonp>
ok i recreated the build.zig with commandline opts, and used --verbose-cimport. that worked
<strmpnk>
companion_cube: In practice, Pony's model is very different from Erlang's. The actors are GC'ed objects rather than selective receive based, which is why the crash model and lack of supervisory structure is different.
<donpdonp>
can someone shed some light on: error: expected pointer, found '.cimport:13:13.struct_uiControl': var control = @ptrCast(c.uiControl, &w);
<donpdonp>
im reading the first param as the type to cast to, not sure why its complaining about a pointer. the second param is the pointer.
<tyler569>
you give ptrCast a pointer type to cast to, so it sounds like you want @ptrCast(*c.uiControl, &w)
<tyler569>
you can't cast a pointer to a struct (with ptrCast)
<strmpnk>
BTW, if someone wants to look at an allocator model that is Pony inspired (Pony's creator is working on this): https://github.com/Microsoft/snmalloc/ It's an interesting idea, though I have yet to compare it to things like jemalloc.
<donpdonp>
tyler569: oh i get it, the type itself needs to be pointer type. makes sense. thx
forgot-password has joined #zig
return0e_ has joined #zig
bbrittain has joined #zig
<forgot-password>
I'm currently trying to build a windows zig application that uses MessageBox (windows.h), but I'm having problems when linking
bwb_ has quit [Ping timeout: 246 seconds]
presiden has quit [Ping timeout: 246 seconds]
return0e has quit [Ping timeout: 246 seconds]
SimonNa has quit [Ping timeout: 246 seconds]
SimonNa has joined #zig
hoppetosse has quit [Ping timeout: 246 seconds]
redj has quit [Ping timeout: 246 seconds]
<forgot-password>
First of all I had to download Visual Studio to get all the headers, and now that it actually compiles it's complaining about the __security_check_cookie symbol being undefined. Are there any windows experts in this channel? ^^
redj has joined #zig
presiden has joined #zig
wootehfoot has quit [Ping timeout: 276 seconds]
forgot_password has joined #zig
forgot-password has quit [Ping timeout: 258 seconds]
beetcoin has quit [Ping timeout: 250 seconds]
donpdonp has quit [Ping timeout: 250 seconds]
edr has quit [Ping timeout: 250 seconds]
bgiannan has quit [Ping timeout: 250 seconds]
oky has quit [Ping timeout: 250 seconds]
donpdonp has joined #zig
<donpdonp>
expected type '?extern fn(...' found 'extern fn(...'
<donpdonp>
what does the ? signify
<hryx>
donpdonp: ? is for an optional type. In this case, the type is a nullable (optional) function pointer
<donpdonp>
hryx: thx
ltriant has joined #zig
bgiannan has joined #zig
<donpdonp>
im declaring export fn onClosing(..){} and using it with c.uiWindowOnClosing(w, onClosing, 0);
<donpdonp>
how would i indicate the ptr is nullable?
Ichorio_ has quit [Ping timeout: 244 seconds]
edr has joined #zig
<hryx>
oh interesting, I thought it would implicitly cast to an optional type
<hryx>
donpdonp: try declaring a variable with an explicit type and passing that to your function
<donpdonp>
but im stuck on the last param of export fn onClosing(w: *c.uiWindow, data: *c_void) c_int
<donpdonp>
c.uiWindowOnClosing(w, f, 0); -> 0 cannot be implicitly casted to type '*c_void'
<donpdonp>
ive tried a couple things but cant get a *c_void.
<donpdonp>
@ptrCast(*c_void,0) gives error: expected pointer, found 'comptime_int'
<Barbas>
I guess null should work
hoppetosse has joined #zig
<donpdonp>
Barbas: oh it liked plain null. thx
<donpdonp>
yea! the callback worked. thx all.
<Barbas>
You're welcome :)
<hryx>
nice!
wink_ has quit [Ping timeout: 245 seconds]
<hryx>
tyler569: I did a git bisect and found the commit that broke my branch (more than it already was, anyway). It was the very last commit :P
<tyler569>
ok, I'll try rolling that one back. I was playing with some other test cases but I've been needing to do actual work too :P
<hryx>
I'll fix when I get home, otherwise if you wanna toy around with it, just reset back one commit, and add a trivial little test to the top of std/zig/parser_test.zig like testCanonical("const x = true;\n")
<tyler569>
:thumbsup:
<hryx>
heh, same. Don't let me distract you!
<donpdonp>
what is the zig way to simply printf a line. ive been using warn("")
Barbas has quit [Ping timeout: 256 seconds]
<hryx>
donpdonp: for casual/debugging? warn() is perfect for that
<hryx>
you may want to file an issue, if there isn't already one. It's probably specific to function types
<Xe>
does switch work on ∆
<Xe>
oh come on i meant to press ^U
<Xe>
does switch work on string literals?
<hryx>
Xe: I don't think so because you'd have to memcmp (or the zig equivalent)
<hryx>
so I thnk doing that implicitly would be a hidden performance cost. unless there were some cool comptime magic involving that "comptime perfect hash" trick
<hryx>
which would be cool too, I dunno
<Xe>
...actually
<Xe>
hryx: that might do exactly what i need, thank you