<nrdmn>
Hmm, jemalloc looks like it does what I need
<nrdmn>
I've been looking for an allocator that can allocate from multiple slices
ofelas has joined #zig
laaron has left #zig ["Leaving"]
keegans has joined #zig
<keegans>
was just testing out android as a cross compilation target but was wondering if it is possible to use the android libc since i'd like to dlopen
knebulae has joined #zig
V-X has joined #zig
<V-X>
What version of C++ is used when using @cInclude? I'm trying to import some headers from https://github.com/ultralight-ux/Ultralight which uses C++11 but am getting errors like `unknown type name 'namespace'`
<Tetralux>
I believe you can pass --std=___ after --c-source, or....
<V-X>
@Tetralux How would this work if I'm just trying to import `.h` files and not `.c` files?
<Tetralux>
I believe "C source" means "anything C", including .s files IIRC.
<Tetralux>
Like
<Tetralux>
"Compiled with clang"
<Tetralux>
If you take my meaning.
<Tetralux>
If you would have otherwise passed it to clang to compile it, you can pass it to c-source.
<Tetralux>
Something like that.
<keegans>
is it possible to tell zig build-exe where my crtbegin crtend etc. are , it is linking against crt1.o which is nonexistent as this is a clang based toolchain that has crtbegin etc ?
<Tetralux>
--c-source --std=c++11 file.c
<Tetralux>
Something like that I tihnk.
<V-X>
Tracking, now I'm getting `invalid argument '-std=c++11' not allowed with 'C'`
<V-X>
Neither my `build.zig` or my other zig code contains any references
<fengb>
Zig doesn’t support C++
keegans has quit [Quit: Lost terminal]
<Tetralux>
Huh... Interesting.
<Tetralux>
That seems... unfortunate.
<V-X>
Thanks @fengb I've swapped to the C compatibility header and now I'm getting `lld: error: undefined symbol: __gxx_personality_v0` Is this a Zig thing or on my library side?
<V-X>
Well, some tinkinering and removing `linkSystemLibrary("c")` fixed it
<V-X>
Well, that seems to have just hidden the error: `Segmentation fault at address 0x0???:?:?: 0x0 in ??? (c)/usr/bin/lib/zig/std/special/start.zig:129:22: 0x226abc in std.special.posixCallMainAndExit (ultalight) root.main(); ^/usr/bin/lib/zig/std/special/start.zig:56:5: 0x2269ce in std.special._start (ultalight)
<V-X>
Well, that seems to have just hidden the error: ```Segmentation fault at address 0x0???:?:?: 0x0 in ??? (c)/usr/bin/lib/zig/std/special/start.zig:129:22: 0x226abc in std.special.posixCallMainAndExit (ultalight) root.main(); ^/usr/bin/lib/zig/std/special/start.zig:56:5: 0x2269ce in std.special._start (ultalight)
<mq32>
just import the function with a fitting pointer type instead of using c-void
<ceymard>
why having the first extern statement then ?
<ceymard>
have*
<mq32>
just for reference :D
<ceymard>
ok
<ceymard>
is there a type that accepts anything ?
<mq32>
if you never need to pass anything non-function
<ceymard>
because I may have to use the same field to store something else
<mq32>
probably "? * const c_void"
<ceymard>
ah, const.
<ceymard>
that way it accepts anything
<ceymard>
that would work
<ceymard>
the only sad thing is then @cInclude is no use to me anymore
<ceymard>
I like the @cInclude :D
<ceymard>
I'll stick to magic I guess, just for that field...
<ceymard>
after all, when talking to c you can't avoid being somewhat messy.
<ceymard>
I'm in fact building a library to interact with the C library
<ceymard>
so I guess this library will be the rampart that exposes the safe bindings
_Vi has joined #zig
ofelas has quit [Quit: shutdown -h now]
_Vi has quit [Ping timeout: 252 seconds]
dimenus has joined #zig
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
_Vi has joined #zig
halosghost has joined #zig
<andrewrk>
donpdonp, I'm having trouble getting all these cimports to resolve with zootdeck. currently stuck on lib-2.60.6-dev/include/glib-2.0/glib/gtypes.h:32:10: error: 'glibconfig.h' file not found
<andrewrk>
where is that file supposed to be provided?
<andrewrk>
I think this would be fixed by adding pkg-config support to linkSystemLibrary
<mq32>
pkg-config support would be super-cool
<mq32>
builder.addSystemPackage("sdl2");
<andrewrk>
it'll just be foo.linkSystemLibrary("SDL2")
<mq32>
also with correct setup of include paths for @cImport?
<andrewrk>
yes
<mq32>
♥
<andrewrk>
we need a robust C compiler flag parser in the std lib. we already have 2 use cases for it
FireFox317 has joined #zig
<FireFox317>
Are we then gonna include pkg-config as part of zig? Because otherwise we rely on the fact that it is present on the system, or something like try it with pkg-config and if it fails use some other method?
<andrewrk>
FireFox317, this is in the implementation of linkSystemLibrary
<andrewrk>
so it makes sense to use the stuff already present on the system to find system libs
<FireFox317>
pkg-config is available on every system?
<andrewrk>
no
<andrewrk>
also vcpkg isn't available on every system
<FireFox317>
So we should have some fallback method when it is not available right?
<andrewrk>
right, it's just something that linkSystemLibrary is capable of trying to utilize
<halosghost>
andrewrk: apropos of nothing: so, i1s are a thing now, but you cannot have an array of i1s yet, is that right?
<halosghost>
i.e., Zig doesn't yet allow for a true bit-array/bit-buffer?
<andrewrk>
you can have arrays of i1 but @sizeOf(i1) == 1
<companion_cube>
sounds like you want a bitvector anyway
<andrewrk>
what's your use case halosghost?
<halosghost>
andrewrk: in this case, bitboards for simple games (e.g., representing a game-of-life board)
<halosghost>
companion_cube: well, yes
<andrewrk>
halosghost, interesting. I wonder if @Vector / SIMD could be useful here
<companion_cube>
it's reasonably easy to write your own with bit fiddling from a []u32
<halosghost>
companion_cube: well, I threw together a “library” (read: header full of macros) for defining/operating on a bitarrays/bitbuffers in C
<companion_cube>
:D
<companion_cube>
doesn't everyone?
<halosghost>
I was just wondering how it might go in Zig :)
<companion_cube>
I remember hearing about packed arrays here
<halosghost>
I like the eventual idea of being able to use Zig in place of C (though I don't think I'm personally ready for that yet)
<mq32>
FireFox317, i think if done right, zig only needs the pkg-config workaround until the custom package manager works right
<fengb>
Packed arrays currently exist in userland
<FireFox317>
halosghost: maybe a packed struct with 8 i1's and then an array of these packed structs?
<andrewrk>
donpdonp, never mind, I think I'll have this solved with some pkg-config integrations I'm adding to zig build, which should also simplify your build script
<donpdonp>
+1
<donpdonp>
i looked at different libs before going with gtk and some of the 'experiments' in src/gui are still there but unused.
<mq32>
andrewrk, that is needed if a shared-object based plugin system can load symbols from the executable
<mq32>
and i assume that gobject does something like that
<andrewrk>
that's definitely sketchy
<mq32>
so is GetOpenFileName on windows :D
<mq32>
that function loads about 50 libraries on my system
<fengb>
We've had async for awhile. And anything that doesn't have it will reimplement it poorly in userland
<fengb>
No offence to libuv >_>
<companion_cube>
don't you love yourself some callbacks??
<mq32>
i think your rework of async/await is quite well done, andrewrk
<mq32>
allows a lot of user-space designs built on top of it
<andrewrk>
it also solves safe recursion
<andrewrk>
in a pretty elegant way, IMO
<andrewrk>
I haven't enabled that yet, waiting for it to stabilize a bit
<fengb>
I managed a pretty clean — albeit hard to reuse — pattern for generators
<companion_cube>
how does it enable safe recursion?
<andrewrk>
safe recursion was another thing planned since the beginning
<companion_cube>
:o
<mq32>
yeah that's true. just create a new frame on the heap and call that frame :)
<companion_cube>
that'd be a killer feature
<companion_cube>
ah, fragmented stacks?
<mq32>
not stack, but stacklike :D
<companion_cube>
segmented* I should say
<fengb>
But it also makes recursion pretty gross :P
<andrewrk>
true
<companion_cube>
but yeah, pushing continuations into the heap… useful
<mq32>
as zig knows the whole stack frame for function calls, you can allocate the deepest stack size in one go
<companion_cube>
still less gross than derecursifying by hand
<andrewrk>
companion_cube, so check this out, if you were to have recursion in async functions, it wouldn't work. because an async frame would be inside another async frame. you get a compile error that shows you all the recursive calls
waleee-cl has joined #zig
<andrewrk>
the epiphany I had, about how to do safe recursion for normal blocking functions
<fengb>
I'm rather intrigued at how seamless the async is. Allowing the frame to go anywhere is amazing
<andrewrk>
is to make it so that if zig detects a call graph cycle, it *forces all the functions in the cycle async*
<andrewrk>
this causes the aforementioned compile error, as well as making it so that heap allocating the frame solves the recursion problem
<fengb>
Will tail call optimization be part of the language spec?
<andrewrk>
yes
<companion_cube>
so it forces you to do the heap stuff, I see
<andrewrk>
it's necessary for this safe recursion thing to work
<companion_cube>
I mean, there should definitely be convenient allocators for that
<andrewrk>
so then the only thing left is external functions and function pointers. simple solution - annotate stack size for both. debug runtime safety for function calls, when the actual function's required stack size is > the annotation on the pointer
<andrewrk>
function pointers are horrible in zig, nobody will ever want to use them
<companion_cube>
hum :D
<companion_cube>
horribleness never stopped people
<companion_cube>
I mean, look at what they write in C
<andrewrk>
ha
<Tetralux>
I'm not sure I entirely understand the function ptr thing.
<donaldallen>
I'd like to offer the suggestion that better documentation for pointers be a priority.
<donaldallen>
Having said that, it appears that [*]const u8 and [*u8 are different types. A function defined fn foo(bar:[*]u8) void and called as foo("hello") will result in an error, because "hello" is of type [*]const u8.
<companion_cube>
which makes sense, foo might modify its argument, right?
<donaldallen>
Is there some way to define the type of the parameter so that it is a superset of these two types? I really don't care if the string is a literal or constructed.
<companion_cube>
I'm not sure, but if you ask for a [*]const u8, you should be able to pass a []u8
<andrewrk>
why doesn't the function care about the length?
<donaldallen>
@companion_cube I'm not positive either, but []u8 is defined as a pointer to something whose length is known at runtime. [*].... pointers point to something of unknown length, so are different.
<donaldallen>
@andrewrk Because the argument is being passed into C-land (calling sqlite functions).
<mq32>
donaldallen, slices have runtime-known length, not comptime known length
<mq32>
so you can pass any length to []const u8
<andrewrk>
you can get from []T to [*]T with `.ptr`
<donaldallen>
@andrewrk What about getting from [*]const u8 to [*]u8?
<andrewrk>
you can't write to a const ptr
<andrewrk>
if the pointer is mutable then it should be [*]u8 in the first place
<andrewrk>
where did the [*]const u8 come from?
<donaldallen>
The [*]const u8 is a C literal string, e.g., a sql query. I need to go back and review my own code to recall why I defined the parameter that gave me trouble as [*]u8. This little discussion has actually made things clearer to me, so may be enough for me to fix the code. If not, I'll re-appear.
donaldallen has left #zig [#zig]
<andrewrk>
ok, yeah that's going to be in the .cdata section and will segfault if you try to write to it
zyzzy has joined #zig
<zyzzy>
Hey! I've got a `s: []const u8` and want to pass it to some function in C (`char *`). If it's not const I can cast it via `&s[0]` and everything works fine. But with const, the compiler ofc errors. Any way to cheat the compiler?
<andrewrk>
zyzzy, why is it const? where did that come from?
<andrewrk>
also are you sure the c code doesn't want it null terminated?
_Vi has quit [Ping timeout: 252 seconds]
<Tetralux>
Also does the C function modify data in the slice?
<zyzzy>
Ah, forgot to mention; it's just a printing function in curses. Uses the len-variant instead of \0-strings, doesn't modify it.
<tgschultz>
andrewrk: a bit off topic, but I just want to confirm that the consensus was that one simply cannot write a wayland client without linking to a host system library and therefore probably glibc, right?
<zyzzy>
Trying to use it with the fmt.Format interface, which gives []const u8.
<fengb>
I think we’ll be encountering a lot of C libraries that don’t mark `*const char` correctly
<andrewrk>
zyzzy, it sounds like in this case the .h file is incorrect. one option would be to provide your own external function prototype with the correct type signature, and call that. the nuclear option is @ptrToInt / @intToPtr
<andrewrk>
tgschultz, that's something I'm interested in investigating. it's not 100% clear to me what the answer is yet, but it seems that could be a likely possibility
<zyzzy>
Alright, cheers!
<andrewrk>
tgschultz, if it comes down to glibc, at least we now have the ability to cross compile targeting any version of it
<andrewrk>
in theory we could also write a driver loader that sets up whatever the dynamically linked libc on the target system requires in order to function correctly
<andrewrk>
given that most libcs are pretty stable, I think that would be a reasonable thing to try
<tgschultz>
sure, maybe. it's just annoying that something described as a protocol requires this
<andrewrk>
agreed
<andrewrk>
"protocol" is a very generous word in this case
<andrewrk>
donpdonp, alright I'm reproducing your zootdeck zig crash with master branch
<alexander92>
there was some limitation on windows
<alexander92>
on the length of cli commands
drazan has joined #zig
<andrewrk>
yes there is
<andrewrk>
we'll probably need a way to specify the equivalent of CLI args with a file or something
<alexander92>
yes, that's what people decided to do as a workaround
<alexander92>
in the project i remember
porky11 has joined #zig
Tetralux_ has joined #zig
Tetralux has quit [Ping timeout: 276 seconds]
Tetralux has joined #zig
lunamn_ has joined #zig
Tetralux_ has quit [Ping timeout: 245 seconds]
lunamn has quit [Ping timeout: 245 seconds]
<donpdonp>
andrewrk: great! sounds like progress. note the qt lib can be eliminated with problem. shouldnt have been in there anyways since its a C++ project.
_Vi has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk: In the big CLI command you generated there are multiple lines which have `--library glib-2.0` for example. Did you see this?
<andrewrk>
FireFox317, I didn't, but it's harmless
<andrewrk>
and may actually be intentional by pkg-config
<Di0genes>
andrewrk: Any plans on doing Shared Generics in the future?
<andrewrk>
I've never heard of Shared Generics before
<Tetralux>
^
<Di0genes>
andrewrk: It allows the compiler to emit the object for all objects of a particular type once instead of each time the object is used(as in Macro Expansion which is what is being used right now).
<Di0genes>
errr...object code.
<andrewrk>
oh I actually was planning on looking into something like that
<Di0genes>
If you want to get the bloat out of your software, Shared Generics is great way to do it.
<andrewrk>
idea is to reduce code bloat when the only thing different about the generic type is something that doesn't matter to the machine code
<andrewrk>
for example error sets
<Di0genes>
andrewrk: Precisely.
<Tetralux>
Wait - I'm confused - emitting a specialization for each instantiation of a generic type exactly once is a basic principle of how generics work.
<Di0genes>
Teralux: The problem is that most compilers don't do it that way.
<Tetralux>
That is insanely ridiculous.
<Di0genes>
Tetralux: They use Macro Expansion.
<Tetralux>
That shouldn't matter.
<Tetralux>
It ends up as C code anyway.
<Di0genes>
Tetralux: Agreed.
<Tetralux>
I find it really difficult to believe that anyone who cares about any kind of performance would not perform that basic optimization.
<Tetralux>
Like really - wtf are they smoking.
<Di0genes>
Tetralux: I've used the Green Hills Ada compiler and the GNAT compiler, and neither turns into C. But they do use Shared vs Macro Generics.
<companion_cube>
if you memoize comptime computations, you get shared generics
<Tetralux>
This is an optimization that should not require any kind of user intervention.
zyzzy has quit [Ping timeout: 265 seconds]
<Tetralux>
"You want a version of this generic template that has this set of values for the parameters? Okay fine. Did we make that specialization already? Yes? I'll just give you the same instance of it then."
<Tetralux>
Like, really.
<Di0genes>
Tetralux: Well...the drawback is that it's harder to use a debugger on the object code.
<companion_cube>
it's also hard to do it when you have separate compilation
akhetopnu has joined #zig
<Tetralux>
Di0genes: How are those two things connected?
<Tetralux>
Mangling?
<Tetralux>
And by debugging the object code, do you mean debugging the final program or ensuring that the correct object code was generated?
<akhetopnu>
hi. i'm looking at the tutorial on https://ziglang.org/ and the examples with std.fs.* are not working. I'm getting an error "error: container 'std' has no member called 'fs'"
<Tetralux>
I mean, runtime program debugging is fine because you just put in debug info with the specialized names, surely.
<Tetralux>
That's how everything else does it.
<Tetralux>
Or so it appears.
<Tetralux>
As for object code generation, surely it's not that difficult to read it and figure out if it's right or not?
<Tetralux>
At least for small examples.
<Di0genes>
Tetralux: Yeah, but I don't have that luxury. Using Frama-C and the Ada Spark Toolkit for High Assurance programming.
<Tetralux>
But even so
<Tetralux>
How does that have anything to do with whether or not you perform that basic optimization?
<Tetralux>
I have no idea what either of those are, but I'm guessing they're a little jank xD
FireFox317 has joined #zig
<gonz_>
Are you saying you don't know what Ada is or specifically SPARK?
<halosghost>
Di0genes: !
<Tetralux>
I know of Ada, and know it's still used for some areas, but :)
<halosghost>
Di0genes: frama-c is excellent
<halosghost>
Di0genes: I'm excited to hear of someone using it live :)
<FireFox317>
akhetopnu: What version of zig are you using?
<akhetopnu>
FireFox317 0.4.0
<akhetopnu>
just downloaded through pacman from arch linux community repo
<FireFox317>
akhetopnu: The code on the homepage of Zig is based on the master branch of Zig, so you would have to download the master version from https://ziglang.org/download/
<Di0genes>
Thinking about using Zig for some Blockchain apps.
<Tetralux>
> supports the hardware-accelerated virtualization of Microsoft Windows through the use of a fully de-privileged variant of VirtualBox [vbox] running inside a strongly isolated VM subject on top of Genode’s base-hw kernel.
<Tetralux>
That's quite a mouthful.
<Di0genes>
Tetralux: Basically, it can run as it's own OS or as a Hypervisor.
<Di0genes>
Liking Zig because there's alot less bootstrapping involved.
<Di0genes>
halosghost: Actually lots of people use Frama-C, but it's usually in commercial products.
<halosghost>
Di0genes: indeed; that is my understanding as well
<companion_cube>
eg. trust-in-soft
<Di0genes>
Surprised at how fast the Zig compiler is.
<scientes>
Di0genes, really?
<FireFox317>
caching ^^
Ichorio has joined #zig
<gonz_>
It *should* be faster, considering how the language works, but I'm guessing most of the waiting is LLVM
<Di0genes>
scientes: Usually C type compilers are notoriously inefficient.
<andrewrk>
I could try to create a tarball for the linux CI to do that as well, it might be not too many bytes
<scientes>
its not a big deal
<scientes>
well, its great what we have :)
samtebbs has quit [Quit: Lost terminal]
<andrewrk>
fengb, I'd strongly prefer to keep it simple
<fengb>
Sure, I'll probably just alias them locally to keep myself sane
<fengb>
Huh, zig master shave 4 KB off fundude somehow
<fengb>
Not complaining. Just happily surprised :)
<andrewrk>
fengb, llvm 9.0.0 perhaps?
<andrewrk>
the merge commit for llvm9 branch is e81156b87364a31bee892aee2e6145f65c02fa35
<andrewrk>
Sep 19
<andrewrk>
maybe they improved -Os for wasm32
<fengb>
Weirdly, release-fast adds back 4 KB
<fengb>
And release-small
<andrewrk>
so, debug is 4 KB smaller, release-fast same size, release-small same size?
<fengb>
It's only release-safe that got smaller. I'm a little confused but I need the safe mode as-is
<andrewrk>
it could be that the optimizer was able to prove that some safety checks were unnecessary
<fengb>
safe is 4 KB smaller than old safe. fast and small are both bigger than safe now :/
<andrewrk>
woah
<andrewrk>
that... does not make sense
<scientes>
--release-safe is great
<scientes>
as the vast majority of code does not need to be fast
<fengb>
Not a big deal since I really need safe here
<fengb>
But it's a little confusing
<andrewrk>
if (@import("builtin").mode == .ReleaseSmall) { var @"( ͡° ͜ʖ ͡°)": [9999]u8 = undefined; }
<FireFox317>
XD
<akhetopnu>
I'm trying to build the build.zig file from tutorial about integration with C libraries without FFI bindings and I'm getting this error: "error: expected array type or [_], found slice"
<akhetopnu>
and it's pointing at line "exe.addCSourceFile("test.c", [][]const u8{"-std=c99"});"
<akhetopnu>
I downloaded the latest zig binary (master)
<akhetopnu>
I'm copy-pasting the example code so it's the same as in the tutorial
<andrewrk>
akhetopnu, you found the one code snippet from the home page that isn't automatically tested. I'll fix it
<andrewrk>
update [][]const u8 to [_][]const u8
<akhetopnu>
that worked :P
<FireFox317>
andrewrk: I'm trying to solve the _DllMainCRTStartup issue (#3237). Apparently when we are doing --c-source <anyfile> we are not including the start.zig file, which is probably what we want. But then I can't solve the issue by putting the logic into start.zig.
<FireFox317>
I checked Zig 0.4.0 and that had the same exact issue
<_Vi>
Is there something like `zig check` to check source code for compile errors without calling LLVM?
<andrewrk>
FireFox317, hmm. I'm considering unconditionally adding start.zig and then having it do comptime logic to detect if we're building a library
<andrewrk>
FireFox317, part of the problem is we don't know if the C file has supplied _DllMainCRTStartup or not
porky11 has quit [Remote host closed the connection]
<akhetopnu>
how can I specify a path for the output binary? I'm running zig build --prefix ./ but it still puts the binary in zig-cache/o/<some-long-hash>/test
<andrewrk>
akhetopnu, the default step is "install". so if you put `exe.install();` on there, the binary will get "installed". The default install prefix is zig-cache. so if you do this it will be zig-cache/bin/yourbinary
<andrewrk>
the reason install isn't on by default is you can build tools and execute them without having to put them anywhere
<andrewrk>
I know, it's completely impossible to find this stuff out from docs
<andrewrk>
soon.
<fengb>
"I'm not a fan of Nim because types go after the variable."
<fengb>
This is such a big deal to people :/
FireFox317 has quit [Ping timeout: 245 seconds]
<companion_cube>
oh no, the syntax is better!
<akhetopnu>
ah, i see, I added 'exe.install();' to ./build.zig, executed 'zig build --prefix $(pwd)' and zig created ./bin folder with my 'test' binary in it
<fengb>
Sometimes I think C has stunted the community
<andrewrk>
it's a loud minority. people with these strong misguided opinions tend to file a lot of issues and not write very much code
<companion_cube>
I could say the same about zig's if/while syntax though ;)
<companion_cube>
it's C like, and it could be rust-like, ie. strictly better
<fengb>
Specifically in this case, they must have never worked with function pointers.
<fengb>
Or parsing code... but that's probably a given :P
V-X has quit [Remote host closed the connection]
<scientes>
We could verify function poiin
<scientes>
functionn pointers on ARM
<scientes>
with the pointer authentication features
<andrewrk>
scientes, memory tagging? yes there are some cool things to explore here
<andrewrk>
we can verify function pointers without those features too, and that's planned
<andrewrk>
zig functions can have small prefix data before them, runtime safety can make sure the type signature is valid and stack size is ok
<akhetopnu>
andrewrk what text editor do you use to jump to zig's std library function definitions? (something like ctags)
<akhetopnu>
is there anything you recommend for checking zig out
<scientes>
there is also providing guarantees about control flow
<akhetopnu>
it's probably too much to ask but maybe there is a better 'beginner friendly' way than using vim-zig plugin
<fengb>
The VSCode plugin works decently
<andrewrk>
akhetopnu, I might not be the best person to ask. I have every file and function memorized and I use fuzzy file finder to jump directly to the file that I want, and then regex search for the name
<akhetopnu>
I only learned about zig's existence today btw, been looking for something like C but without the header file nonsense, some syntax niceties etc and zig looks more or less like the choice, despite its early stage of development
<andrewrk>
the early stage of development is a serious downside but if you can get past that I think it's really good :)
<akhetopnu>
I'm a web developer by trade (javascript/html/css and all that), but I want to get into low-level stuff and C seems like the simplest/go-to/default language of choice but I've been spoiled by high-level features, I think I'm liking the rust/golang twist to C in the form of zig
<andrewrk>
akhetopnu, I think you'll find stack traces / error return traces / debug info to be especially helpful. Although without much C experience, you won't realize how bad debugging can be :)
<alexander92>
debugging async code is always an interesting
<alexander92>
area as well: especially with classic step-level debugging
<andrewrk>
ah. yes, that is an unsolved problem currently, but zig is well-poised to improve on it
<alexander92>
i believe it's a tooling problem more than a lang one
<alexander92>
but languages surely can make it easier
<alexander92>
for tools
<akhetopnu>
one of zig'z elevator pitch features is 'fast compiler', I'm guessing the time was comparing with gcc/clang (?) but there is also tcc (tiny c compiler) which is truly blazing fast and running c programs feels like running bash scripts
<akhetopnu>
i know it's not a priority right now but is it at least being considered for the future of zig?
<andrewrk>
akhetopnu, yeah, did you see my comments regarding the self hosted compiler about an hour ago?
<scientes>
well LLVM will slow zig down
<alexander92>
tcc is nice
<alexander92>
but i really want to add more debug info capability
<andrewrk>
scientes, the more I think about it, the more confident I am that zig will support more backends besides LLVM
<andrewrk>
in particular, it will be interesting to look into a fully self hosted implementation (probably first for x86_64) that is not limited by any third party code, so we have no perf excuses
<scientes>
well, to me the program's speed is far more important
<andrewrk>
I'm still planning on trying to make llvm faster by parallelizing it though
<scientes>
and gcc and llvm are unmatchable ATM
<andrewrk>
right. this would be for debug builds, where compilation speed is the priority
<andrewrk>
e.g. hot code swapping during game development
<companion_cube>
dmd is pretty good at that, I think
<companion_cube>
andrewrk: it would buy you a *fully* self hosted compiler, as well
<scientes>
that isn't very important however
<alexander92>
what about cranelift ? is it something that would be usable from static languages, or is it only jit-related
<companion_cube>
or: target wasm directly, without llvm
<alexander92>
(as a maybe lighter llvm)
<companion_cube>
then you get to use wasi ;)
<andrewrk>
scientes, I agree that a zig with LLVM or GCC backend will remain a primary use case
<andrewrk>
companion_cube, then I can do my sandbox thing where it's a static site, all client side :)
<andrewrk>
"try it online" but it's just your own computer, mwa haha
<donpdonp>
expected LLVM 9.x but found 8... /me goes looking for newer llvm bits
<companion_cube>
yeah…
<companion_cube>
(also can be useful for bootstrapping, you start from wasm, not from an ELF binary)
<andrewrk>
donpdonp, what distro?
<donpdonp>
ubuntu 18.04
<andrewrk>
apt.llvm.org
* scientes
just updated to ubuntu 19.10 for llvm 9
<donpdonp>
thx.
<donpdonp>
after apt install clang-9, cmake says -- Found LLVM: -lLLVM-9 -- Could NOT find CLANG (missing: CLANG_LIBRARIES CLANG_INCLUDE_DIRS)
<donpdonp>
anyone know what pkg covers those?
<donpdonp>
ah its libclang-9-dev.
waleee-cl has quit [Quit: Connection closed for inactivity]
halosghost has quit [Quit: WeeChat 2.6]
<akhetopnu>
when i declare some methods on a struct - are these methods actually assigned to the struct's fields (as function pointers) or are these 'global' function that are converted into calls with the first argument being the struct?
<andrewrk>
akhetopnu, the latter
<andrewrk>
you can call them with TheType.method(instance), there is no difference
<andrewrk>
donpdonp, how's it going? is it working for you?
<donpdonp>
oh i got distracted by random github repors and a pint of porter. i got as far as building and installing zig head.
* donpdonp
tries it out
<andrewrk>
haha no rush, I just want to feel the relief of knowing it's working
telemach has joined #zig
doesntgolf has joined #zig
waleee-cl has joined #zig
<donpdonp>
andrewrk: newest zig and newest zootdeck seem to be working great. thx
<andrewrk>
happy to hear it
<andrewrk>
the new build script is ok for you?
<andrewrk>
I think the caching will work better with it this way
<andrewrk>
(without setOutputDir)
<donpdonp>
yes, once i found zootdeck in zig-cache/bin/ :)
<donpdonp>
by the way do you have a mastodon account somewhere?
<andrewrk>
@andrewrk@mastodon.social
<andrewrk>
but I have never tooted
* donpdonp
nods and subscribes anyways
<_Vi>
Is there already an issue for third visibility mode (non-private and non-`pub`)?
<andrewrk>
_Vi, there is not
<_Vi>
Is there some concept of projects/libraries that consist of multiple source files and have some stable API (so that care should be taken not to expose wrong thing)?
<_Vi>
Or are zig projects supposed to talk to zig libraries using C ABI?
<andrewrk>
_Vi, this will become more clear during the next release cycle, when we gain a package manager
<andrewrk>
zig expects all zig packages to be in source form, although of course you can use C library interfaces if you choose
<_Vi>
I tried `zig init-lib` and it created project template for C ABI-exposing library.
<_Vi>
"when we gain a package manager" -> Will the new visibility mode (function accessible within package) be a part of it?
<andrewrk>
fengb, I love fundude's startup screen
<andrewrk>
_Vi, what new visibility mode?
ltriant has joined #zig
<fengb>
😁
<fengb>
I spent too much time on trivialness
batok has quit [Ping timeout: 265 seconds]
Ichorio has quit [Ping timeout: 252 seconds]
knebulae has quit [Read error: Connection reset by peer]
<via>
i've been eyeing the async and event loop stuff for a while, and looking through code/watching the livestream, i'm wondering how might the loop stuff might be usable on baremetal
<via>
right now the loop code itself looks to be specific about what os its targetting
<via>
but i'm imagining baremetal code that might have some interrupts, say notifying when a tx buffer for a uart is empty/ready to write, or some adc value is ready interrupt, and being able to make a project-specific loop to handle this
<via>
so that you could use write/read and such in an async fashion
<via>
right now from what i've glanced at it looks like i'd more or less need to make my own event loop logic where i await on very specific frames
<_Vi>
andrewrk, "what new visibility mode?" -> Visible outside current namespace, but not in other packages. Or maybe even better make `pub` to grant only intra-package access and make new keyword or attribute for items that consist package's official API.
<via>
which i'm willing to do -- its way better than what i'm doing now, but i'm wondering if there's any hope for making the event loop a bit more of an interface rather than the specific
<andrewrk>
via, async functions in freestanding is a use case I explicitly had in mind
<andrewrk>
From what you've described it seems to me this should work for you no problem with no dependency on std.event.Loop
<via>
maybe i misread, but it looks like Loop has comptime errors all over the place for unsupported os, including ones in the direct path of read/write?
<via>
and yeah, i think it is absolutely awesome that await/async works on freestanding
doesntgolf has quit [Read error: Connection reset by peer]
<andrewrk>
But I don't think you need to depend on std.event.Loop. So you won't hit those errors
<andrewrk>
There's no implicit dependency on it
knebulae has joined #zig
<andrewrk>
_Vi, you should be able to do what you want with status quo features and usingnamespace
<andrewrk>
You have full control over what gets exposed from a given file. For a package there is a root file
<via>
andrewrk: okay, i'll have to look again, but it looked to me like i couldn't do what i'm describing, i'll have to get back to you
<andrewrk>
via, std.os.write will give you a compile error on freestanding
<andrewrk>
But I've been considering making such functions overridable in the root source file. Doing this would enable zig packages that use such functions to work in freestanding if you provide implementations
<via>
yeah, i guess thats what i mean
<andrewrk>
So you would hook up such implementations into your own event loop if you wanted that
<andrewrk>
Yes,this is a more general problem than async await :-)
<via>
okay, no worries, the current work is spectacular, i just wanted to know if you'd thought of the use case, and you have, thank you