<shachaf>
I'm still a bit uncertain about the auto-async-await, it seems like a big thing to make implicit in a language that doesn't do function overloading.
<shachaf>
But I'll see how it works out. :-)
<Snektron>
mq32: remember that @Vector should not be used as a mathematical vector!
<Snektron>
Its easy to confuse the two
<Snektron>
Its much more efficient to calculate the same vector dot product for 4 different vectors than to use the dot product intrinsic for example
<Snektron>
LLVM's autovectorization is quite efficient from what i've seen in C, so i think theres a good chance you wont be able get an improvement at all
<Snektron>
That is assumed autovectorization works with Zig
kristoff_it has quit [Remote host closed the connection]
shritesh has joined #zig
shritesh has quit [Ping timeout: 250 seconds]
<andrewrk>
it does, same as clang
uranther has quit [Quit: Connection closed for inactivity]
ky0ko_ has joined #zig
ky0ko has quit [Disconnected by services]
ky0ko_ is now known as ky0ko
ky1ko has joined #zig
<andrewrk>
fengb, it looks like the await / for loop "Instruction does not dominate all uses" issues are my next blockers for the async/await proof-of-concept
<andrewrk>
I'm gonna start the late-night stream in about 15 minutes
<fengb>
Sweet. The workarounds are fine but it looks intimidating when stumbling upon
ky0ko has quit [Ping timeout: 264 seconds]
stratact has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Client Quit]
utzig has quit [Ping timeout: 244 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
laaron has joined #zig
curtisf has quit [Remote host closed the connection]
chemist69 has quit [Ping timeout: 250 seconds]
chemist69 has joined #zig
<redj>
hey andrewrk, I just missed the live stream... just caught q&a over and have a good night... are you posting the recording to youtube right away?
<andrewrk>
redj, yes, it's uploading
<redj>
very nice, will watch tonight :)
<andrewrk>
I think the demo went well even though I was clearly a bit tired
<redj>
andrewrk: great job on the streams btw... I like the status update "format" ...
<andrewrk>
I did a live demo with spawning a thread to resume an async function (I've never tried that before) and it worked first try
<redj>
andrewrk: what's the status of networking for the vvery emminent 0.5.0 release?
<andrewrk>
redj, practically non-existent
<redj>
first try -- that's always awesome! :)
<andrewrk>
redj, but I do expect to be ready to start working on networking very soon
<redj>
andrew any kind of rpc planned in the language or std lib?
<andrewrk>
probably not
<redj>
any discussion on that? or why not?
<andrewrk>
that's the kind of thing that works just fine as a third party package
<redj>
ah, understood... do you think it would have a "native" feel as such?
<andrewrk>
I'm not sure that concept applies to zig packages. even the "builtin" module you have to import the same way as you would a third party package
<redj>
I mean would it feel like a natural extension to the language
<redj>
right, and that's a good thing
<redj>
I really need to start experimenting with the language... I've only compiled from source a couple of times...
<andrewrk>
there are also binaries of master branch available on ziglang.org/download
<redj>
I know but I chose to start from source since I do want to understand the compiler maybe...
<andrewrk>
good :)
<fengb>
incompatible types: '[*]u8' and '?*c_void'
<fengb>
Missing an implicit cast?
<fengb>
Hmm there's something weird with the peer resolution here
marler8997 has quit [Quit: Leaving]
shritesh has joined #zig
<redj>
andrewrk: #2377 mentions 'stable event-based I/O' but #3063 doesn't... neither does the 0.5.0 milestone... I'm guessing there's no issue for that specifically. will that make it into the release?
<Yardanico>
JS has 7976744, Python 4063862, C 1222969, Rust 105186, Nim 3429, V 32
<Yardanico>
Not that bad considering that Zig first appeared in 2015 and Nim in 2008
abbiya has joined #zig
<bgiannan>
I think zig is way to young to start comparing its usage to other languages
<gonz_>
I agree with that entirely, but I think accidentally it also tries to say "We need/want people to make things" and I also agree with that.
<gonz_>
As a metric for some attribute of goodness of a language it's pretty meaningless, though.
<mq32>
i think Zig/andrew is doing the right right now
<mq32>
defining and refining language semantics instead of implementing a load of features/libraries that will lock the language in place (like web server, REST clients, …)
<mq32>
that was one thing that bugged me about V the most
<Yardanico>
is there a way to read a runtime-decided number of bytes from a stream?
<Yardanico>
or I should use while loop and readByte?
<mq32>
"wait, you tell me your language isn't even finished yet, but you already have UI, graphics acceleration, networking and all that stuff done?"
<mq32>
it just feels like the focus is set wrong
<gonz_>
bgiannan: Cool! What does the source situation look like?
<Yardanico>
(btw I like io.InStream in Zig, it's actually better than streams module in Nim because it has more flexibility and natively supports different endianness)
<bgiannan>
gonz_, the source situation?
<mq32>
yeah, endianess is imho an important thing in I/O everyone tends to ignore
<gonz_>
bgiannan: Are you doing any source distribution, partial or otherwise? Will you be making zig utility code available in the process?
<Yardanico>
well Nim has it, but it's in a different module so you first have to read a byte or a int and then switch the endianness of it
<Yardanico>
hmm, so can I create a []u8 variable with size known at runtime?
<Yardanico>
[len]u8 where len is a runtime-defined var doesn't work (well, as expected)
<gonz_>
Yardanico: `array[0..]`should create a slice
<gonz_>
This should have a runtime known size
<Yardanico>
gonz_: I need to pre-allocate a variable of a certain size so I could read a UTF8 string from a binary file into that variable
<Yardanico>
will a slice work in this case?
<bgiannan>
gonz_, if i end up writing anything general enough i'll extract those i open source projetcs yes
<bgiannan>
in*
<mq32>
Yardanico: var backing_buffer = [1]u8{0} ** 256; var data = backing_buffer[0..len]; readsome(data);
<gonz_>
Yardanico: `var buf: [8]u8 = undefined`
<Yardanico>
gonz_: thanks, but I need a runtime-defined size :) mq32 thanks, I'll try
<gonz_>
Yardanico: `@compileLog(@type(buf[0..]));` will be `[]u8`
<mq32>
or you can use an allocator for data with no unknown upper bounder
<mq32>
got to go
<gonz_>
If we are talking "I can't ever create this without a runtime known size", `allocator.alloc(T, count)` will do the trick
<Yardanico>
mq32: yeah, that did the trick, because I know that the string size will not be bigger than that anyway
<Yardanico>
wait, so Zig automatically emits Valgrind data to debug binaries so I can check them with valgrind? that's cool
<Yardanico>
I'm still amazed by the size of Zig-built binaries in release-fast mode after stripping them by the way :)
samtebbs has joined #zig
urluck has joined #zig
<Yardanico>
How do I pass a []u8 variable to a C function which expects to have a [*c][*c]u8 ?
<Yardanico>
(unsigned char ** outData in C)
kristoff_it has joined #zig
<samtebbs>
Yardanico: Seems to me that you want to pass the address of the array
<Yardanico>
samtebbs: yeah, this is a function from a C library for LZMA compression/decompressing
<Yardanico>
I need to pass file format (lzip in that case), input array and size (it works with &in_data[0] and lenght of it), output array and size (it will write to these two)
<Yardanico>
Zig made this definition for that function: "pub extern fn simpleDecompress(format: elzma_file_format, inData: [*c]const u8, inLen: usize, outData: [*c]([*c]u8), outLen: [*c]usize) c_int;"
abbiya_ has joined #zig
abbiya_ has quit [Read error: Connection reset by peer]
abbiya_ has joined #zig
abbiya has quit [Read error: Connection reset by peer]
<gonz_>
If anyone wants to try it out and see if it's useful for them
<samtebbs>
Yardanico: Does passing the address of your outData array work?
<gonz_>
I still haven't even really discovered the basics of making something like this available as a package, so any pointers there are welcome.
<samtebbs>
gonz_: Not sure how we should do it before we have a package manager
<gonz_>
Using deps via `git clone` is pretty bleh if you don't set up rules for these specific repositories to be cloned with `LF` endings
<gonz_>
And in this case is doubly relevant because obviously if you're using win32 you're on Windows and it defaults to cloning with `CRLF`
<Yardanico>
samtebbs: how do I do this? I currently have "var out_data: []u8 = undefined;" and tried to pass it as "&out_data[0]" to the C function but it didn't work
<Yardanico>
if I pass "&out_data" it says "error: expected type '[*c][*c]u8', found '*[]u8'"
noonien has quit [Quit: Connection closed for inactivity]
<Yardanico>
hmm, it seems to go further, now ldd can't find the symbol from that lib (it's in C source code with headers), how do I tell Zig to compile the C lib from source code?
<Yardanico>
I currently have @cInclude for headers of that lib
<Yardanico>
I do zig run --library c test.zig -isystem "$PWD" right now
<mikdusan>
well if you want to compile an entire C lib, you probably don't want to issue commands on CLI for it. Zig's analogue to makefiles is `build.zig` and the `zig build` command to run it
<mikdusan>
in there you can tell zig to compile additional .c files
<mikdusan>
i made a small command-line tool a while back that builds a .zig main, and then adds 3 .c files
<mikdusan>
fair warning build.zig is not documented yet. and look to zig tree `std/build.zig` to see the API
kristoff_it has quit [Ping timeout: 245 seconds]
<Yardanico>
mikdusan: well I know that there's no documentation for build, because I already look quite a lot in the src for the stdlib modules :) although that way I learn the language a bit faster
<gonz_>
samtebbs: I've included a tiny bit of how I'm using the package in one of my projects in the README, but I'm not sure `addPackagePath` is what people have been using at the moment.
kristoff_it has joined #zig
<gonz_>
It works, obviously.
<Yardanico>
can I somehow use addCSourceFile for all files in a directory?
<Yardanico>
I really think that there should be a way to just specify something like addCSourceFile("src/*.c", ...)
<Yardanico>
but I'm fine with an array and a for loop
<mikdusan>
if you _really_ wanted to do it std.fs.Dir lets you iterate pathnames in a dir. not sure if there is any globbing or regex support
<Yardanico>
yay it compiled
<Yardanico>
but it seems that the way I passed my out array is still wrong :D
<mq32>
gonz_, is that just a raw conversion of the windows.h file?
<gonz_>
Yes
<gonz_>
With every deficiency that incurs
<mq32>
ah okay
<gonz_>
I also haven't tested it in any other circumstance than the one I have on my two Windows machines
<mq32>
*grin*
<mq32>
what would be cool is something like
<gonz_>
My first version of this had meticulously translated, hand-written bindings
<mq32>
const user32 = @import("win32/user32");
<gonz_>
Then I realized I'm doing a ton of work for nothing
<gonz_>
That was the idea from the beginning, actually
<mq32>
ah yeah
<gonz_>
But technically it doesn't serve any purpose other than self-documentation
<gonz_>
Because we only import what we use
<mq32>
yeah, but it also makes clear what windows library actually provides this functions :)
<mq32>
maybe it's possible to only extract the function definitions and match them against the exports from the libraries
<gonz_>
So if the user knows where something comes from, they don't really need to care. It would be nice to have the split because it makes knowing what to link much easier.
<mq32>
so splitting up windows.h into subfiles would be possible
<Yardanico>
Damn even with that easylzma lib (a wrapper for 7z C lib) compiled in the after stripping the release-fast binary it's only 96kb
<Yardanico>
although I linked with the C library :)
<gonz_>
Yardanico: <3
<gonz_>
mq32: Yeah, I haven't experimented much with this. I was happy enough that I could actually extract it like this and re-use it without referring to my specific include folders
<gonz_>
(more than for the generation)
<gonz_>
I'm curious how many things change from version to version. The only way to really practically find out is from someone using something that apparently did change, I guess.
<mikdusan>
Yardanico: is your outData still borked? i think my understanding was backwards
<Yardanico>
mikdusan: yeah
<mikdusan>
k give me a sec
<gonz_>
mq32: The long-term plan is still to have a zig interface where it's warranted, probably in the top-level of that module or in some other module, that accomplishes common things in a more zig-like way.
<gonz_>
But it also turns out that writing win32 apps in zig the way you'd write win32 apps usually is also not terrible
<Yardanico>
mikdusan: I think I fixed it
<Yardanico>
1st of all I had an error in my code: I use lzip format instead of lzma, and then I used "@ptrCast([*c][*c]u8, &out_data.ptr)" for out_data and it worked
<Yardanico>
now the C lib correctly decompresses the LZMA data in the memory
<mq32>
how's the plan about networking right now? is there something in Zig/std already?
kristoff_it has quit [Remote host closed the connection]
abbiya has quit [Quit: abbiya]
<samtebbs>
Yardanico: nice one :)
<samtebbs>
What IDE is that btw?
<Yardanico>
VSCode with zig-lsp (simple Language Server implementation with some parser/lexer checks, although the parser part is a bit outdated and sometimes shows "problems" on correct Zig code)
<Yardanico>
well, open-source build of VSCode from Arch repos
<mikdusan>
i think this might be pretty clean: `var outData: []u8 = undefined; simpleDecompress(..., @ptrCast([*c][*c]u8, &outData.ptr), &outData.len);`
<Yardanico>
mikdusan: yeah, I also got it working with this (see previous messages) :P thanks a lot for helping ( didn't know that I had to use ptrCast here)
<mikdusan>
took me a bit to realize the c-api was simply setting a ptr & len; which magicaly is what a zig slice is :)
<mikdusan>
any compiler internal gurus lurking? i'm looking for any info on Extended-Basic-Blocks vs. Basic-Blocks pros/cons of each
<samtebbs>
mq32: It was waiting for async/await to be merged which was done recently, not sure if anything is blocking it now
<samtebbs>
mikdusan: What's an extended basic block?
<mikdusan>
apparently a grouping of basic blocks. the first BB can be entered from anywhere. the rest are entered only from within group. (if i understand correctly)
<mq32>
samtebbs: I'm thinking about implementing a "reliable udp" library (or at least something like that)
<mq32>
and before i start in C++, i'd like to give Zig a shot here
<mikdusan>
i first heard about it in some Rust blog where they were talking about switching to EBB then ditched the idea
<mikdusan>
and also heard about it for the Mill CPU Architecture... it uses EBB as well.
<daurnimator>
mq32: I have intentions for networking stuff....
<daurnimator>
mq32: are you targetting linux/posix/windows?
<mq32>
i am targetting "generic message passing platform"§
<daurnimator>
?
<mq32>
:D
<mq32>
serial port, udp, tcp, raw wifi, bluetooth, ...
<mq32>
anything that can transmit some kind of packet
<Yardanico>
hmm, now a question about enums, how do I convert an integer to a set (or array) of enum values? maybe there's something already in stdlib for that?
<daurnimator>
mq32: oooo. I have huge plans for that to :)
<Yardanico>
for example if 64 is DoubleTime and 8 is Hidden, and the value is 72, I want to get an array of DoubleTime, Hidden
<daurnimator>
mq32: https://ȱ.com :)
<daurnimator>
Yardanico: that should like bit flags; not an enum
<Yardanico>
ah, right
<daurnimator>
s/should/sounds/
<gonz_>
Yardanico: You can use packed structs with 1 bit fields to/from this.
<mq32>
daurnimator, sounds like a big project!
<daurnimator>
mq32: yep. I've also got bits implemented in zig :)
<mq32>
cool
<mq32>
my project "group" right now is kinda same level of crazy, but very different :D
<samtebbs>
mikdusan: Sounds like that would be useful for loops where you should only enter the initial basic block
<mikdusan>
i found a blurb suggesting it "some local optimizations such as instruction scheduling are more effective when done in EBB"
<mq32>
daurnimator, samtebbs: i assume i can access standard socket() io, right?
<daurnimator>
mq32: yeah.... sort of. it's not very nice
<mq32>
daurnimator: how do you want to design end-to-end encryption in ȱ?
<mq32>
in terms of key-ex between my own devices or similar
<daurnimator>
mq32: you share your 'master secret key' between devices by inviting your other devices to a channel that is for that purpose
<mq32>
this sounds reasonable
slice has quit [Ping timeout: 245 seconds]
slice has joined #zig
<fengb>
3 hour optimization session: -100 bytes. 5 minutes of updating to C spec: +100 bytes. Le sigh
shritesh has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Client Quit]
laaron has joined #zig
<bgiannan>
Is there a way to tell `zig test myfile.zig` to not run test of imported files inside `myfile.zig`?
<daurnimator>
bgiannan: --test-filter ?
<bgiannan>
`zig test --test-filter myfile.zig`?
<daurnimator>
bgiannan: no it is a filter on the test names
<daurnimator>
`zig test myfile.zig --test-filter myfile`
<bgiannan>
oh should i maybe prefix all my test names with something?
<bgiannan>
what do you mean by test name actually?
<bgiannan>
test "testname" {...} <- this?
<daurnimator>
yep
<bgiannan>
this is weird to want to filter on this
<daurnimator>
do I recall that an @import prefixes the module name onto the test names?
<gonz_>
Is this test behavior limited to current project? Because I've never had tests from imported files run automatically AFAIK.
<bgiannan>
yes i would have though zig had some auto-naming conventions like it does for types
<gonz_>
And obviously I use the standard library, which has tests.
<gonz_>
Or is it present only in newer versions?
<bgiannan>
gonz_, you do @import("std") and not @import("./std.zig") which maybe the difference
<gonz_>
Recursive testing without having asked for it seems very unintuitive.
<bgiannan>
my thought exactly
<bgiannan>
but i guess you could do `zig test main.zig` and run all your tests that way?
<gonz_>
Yeah, I dunno. I think running all tests is a job for globbing or a flag being passed.
<gonz_>
Or just `zig build test`
<gonz_>
As for filtering on test names it's what I've usually seen in other environments
<gonz_>
Regex filtering on test names is very useful in certain circumstances
<bgiannan>
i would have expected `zig test` without a file name to run all tests and `zig test myfile.zig` to run only the tests of myfile.zig
<gonz_>
I think that's probably what people are used to, at least.
<samtebbs>
Has anyone ever gotten `/home/samteb01/repos/zig/build/lib/zig/std/time.zig:62:15: error: container 'std.os' has no member called 'timespec'
<samtebbs>
var ts: os.timespec = undefined;` when doing `const time = std.time.timestamp();`?
shritesh has quit [Quit: Leaving...]
<samtebbs>
Oh wait maybe it's because I'm targeting freestanding
<samtebbs>
For some reason I thought it would be evaluated on the host computer at build time so I could embed a "This software was built on date x" in a boot message
<fengb>
Maybe anything that references OS should have a friendlier error message
<fengb>
"Freestanding has no OS. Your code is bad and you should feel bad."
<samtebbs>
:(
<samtebbs>
I'm sure I saw a PR that added an "Unsupported OS" compile error
<fengb>
Yeah that was just for referencing fd_t
<samtebbs>
Oh ok
<fengb>
Maybe I could disable all of OS?
<samtebbs>
Makes sense to me
<fengb>
I'm not sure what that'd impact but it might be worth a shot
<samtebbs>
Oh your PR's been open for a month now
utzig has quit [Ping timeout: 245 seconds]
<fengb>
Well it can be improved :P
<fengb>
Braindump: we should have a special path for freestanding that errors out with "Freestanding cannot use OS code", as wells the current "unimplemented" path
<samtebbs>
+1
<fengb>
I'm also surprised at the comptime thing. Is it not possible to run things in the compilation host?
<fengb>
I see 3 places where it kinda makes sense to put it: in std.zig (which breaks the current pattern of simple imports), in os.zig (which doesn't have a good home since the existing switch is hidden behind libc), or in os/bits.zig (which has a good place but located awkwardly within the file structure)
<mq32>
fengb, i still don't think about if as an expression but a statement :D
<Yardanico>
so I'm home again, starting questions again - how do I convert/cast a byte to a bool?
<Yardanico>
wel by byte I mean u7
<Yardanico>
u8 *
<Tetralux>
intToBool?
<Tetralux>
@intToBool*
<Tetralux>
I forget if that exists or not.
<Tetralux>
var b: bool = if(n == 0) false else true; -- that'd work too.
<mq32>
Yardanico: "var my_bool = (my_byte != 0);"
<Yardanico>
mq32: well ok
<Tetralux>
Ah yes
<Tetralux>
Or that xD
<mq32>
Tetralux: LUL
<Tetralux>
Don't look at me. xP
<Tetralux>
We probably should have @intToBool though.
<Tetralux>
Probably save a few bugs.
<mq32>
i would not do that
<mq32>
how should the semantic of that function look like?
<mq32>
"accept only 0, 1 or panic?"
<mq32>
"everything not 0 is true?"
<Tetralux>
That last one was my first idea.
<mq32>
"test for the LSB, if that is 0, the value is false"
<mq32>
"everything that is not 1 is false"
<Tetralux>
Nah - I'd make it just say "if it's zero, its false else true."
<mq32>
i have seen *every* option of those listed
<Tetralux>
That way it's actually useful.
<Tetralux>
Otherwise, why not just write != 0.
<mq32>
but i can express that with less code and more semanticly document by doing (value != 0)
<Tetralux>
The whole point is that you don't have to think about zero or not.
<mq32>
but it's a good point to think about that
<mq32>
i have code here that converts an ascii char to boolean
<mq32>
everything not '0' is true :D
<Tetralux>
xD
<mq32>
which is definitly not what i want :D
<Tetralux>
You want 0 or 1 and nothing else?
<Tetralux>
Only, (value != 0) === (everything not 0 is true)
waleee-cl has joined #zig
<Yardanico>
is there a pure Zig alternative to something like scanf?
<Tetralux>
parseInt, parseUnsigned?
<Tetralux>
I think that's in std.fmt.
<mq32>
Tetralux: in that code i'd actually want to be '1' true, '0' false and everything else an error
<Yardanico>
I mean I want to parse a string like with entries like "w | x | y | z", and these entries are separated by commas
<mq32>
just search for commas :)
<Tetralux>
mq32: In that case, I'd either use a switch/if-else.
<Yardanico>
ah I guess I can use a simple while loop
<Tetralux>
:s/either use/use
<mq32>
Tetralux: yeah
_whitelogger has joined #zig
<andrewrk>
bgiannan, Settlers of the Deep looks fun
<andrewrk>
gonz_, you don't need exe.linkSystemLibrary for windows DLL calls, as long as all the extern functions have extern "kernel32" etc in them
<Tetralux>
That's because kernel32 is always linked?
<samtebbs>
So I've resorted to adding a build option with the timestamp so I can print when the build was made. All I need to do now is figure out how to format the timestamp to a date string
<samtebbs>
Pointers welcome
* Tetralux
smiles because he has some idea what might be involved in implementing that.
<andrewrk>
Yardanico, you can probably further reduce release build size by using --strip if you don't care about debug info
<Tetralux>
Did you know that the UK was on BST+1 for several years during WWII?
<mq32>
samtebbs: (void*)0xB8000 // this one helps you print the text
<Yardanico>
andrewrk: doesn't the "strip -s" do the same?
<andrewrk>
no; --strip to zig becomes a comptime const value that the std lib observes and avoids wasting binary size for e.g. stack trace code knowing the info won't be available
<Yardanico>
ah, ok
<andrewrk>
--strip is kinda like "heads up, I plan to strip"
<andrewrk>
Tetralux, no, zig auto generates .def files on windows for dlls when you use extern "foo"
<andrewrk>
this is one major strategy used for cross compiling
<gonz_>
andrewrk: The generated code would have to be modified in that case. I guess a neat regex could do it.
<gonz_>
andrewrk: But are you saying this also applies to f.e. `user32`, `gdi32`, etc.?"
<andrewrk>
gonz_, yes, sadly, .h files do not contain this information. yes it applies to any DLL that you expect to exist in the target environment
<andrewrk>
my suggestion for your project would be to do `pub usingnamespace std.os.windows` and then augment it with additional definitions
<gonz_>
Mhm, yeah, I mean mostly that now it'll be very hard without some kind of external list (this seems surprisingly hard to come by in a neat format) used for modification
utzig has joined #zig
<andrewrk>
getting them from windows.h is a good start, but if you're going through the trouble of having an entire repo dedicated to it, might as well open the possibility up to improve the APIs, IMO
<gonz_>
Yeah, the idea is to have better APIs in the top level module
<gonz_>
or more "zig-like" APIs
<gonz_>
And have a backing module fully available to use `c`/`lean_and_mean`
<gonz_>
Because someone's going to want to use something you haven't sorted out yet.
<gonz_>
My first version of this had manual bindings + zig interface stuff, but I decided to scrap that approach entirely and see what would need adding by leaning much more heavily on this generated code.
<gonz_>
So once you know what feels annoying and painful, you know what you should add in the top-level.
<gonz_>
But this is mostly hypothetical as well; I have no idea how much drive and time I will have for sitting down and working with win32 going forward.
<mq32>
afaik it's not fully complete, but includes the most needed APIs
<samtebbs>
mq32: That looks like the framebuffer address to me :p
<mq32>
samtebbs: correct!
<mq32>
VGA segment
<samtebbs>
Yeah I have printing all wrapped up. Is there any date formatting support in the stdlib?
<mq32>
andrewrk: how much work would it be to convert the Zig AST into a "list of declarations"?
<andrewrk>
that's what it already is
<andrewrk>
you have a root node and then a list of declarations
<mq32>
ah i meant some export function
<mq32>
would be a helpful step towards documentation. not autogenerated documentation, but something that tells us: "hey, this stuff exists in the codebase"
<Tetralux>
Surely you'd know it was in your codebase because you-know... you read the source every once in a while xD
<samtebbs>
Not everyone knows everything about a codebase
<samtebbs>
Zig for example
<gonz_>
Some code bases are older than most of the people in this channel. :D
slice has quit [Quit: cya]
slice has joined #zig
jmiven has quit [Ping timeout: 244 seconds]
mq32 has quit [Ping timeout: 244 seconds]
<samtebbs>
andrewrk: When I asked why my run step in build.zig also built the kernel, you explained that it's because the run step uses addArtifactArg. That makes sense.
mq32 has joined #zig
<samtebbs>
What doesn't make sense is why it's being rebuilt when it's already in the zig-cache dir
<samtebbs>
Surely if an artifact is in the cache and the sources haven't changed then it shouldn't be rebuilt
<Tetralux>
samtebbs: What if the artifact depends on other source that you did change?
<Tetralux>
Much like object files.
<andrewrk>
samtebbs, the build system doesn't cache yet, other than relying on enabling the caching that the zig compiler itself supports
<andrewrk>
so, for example, build steps that are system commands will always be run
<andrewrk>
there's an issue open for that
<mq32>
Tetralux, my idea was more to throw such code at std ;)
<mq32>
so i have a list what is included in std and so samtebbs could have his question answered faster *grin*
<mq32>
got to go (and had a bad timeout :( )
<samtebbs>
Tetralux: I can build then run and run once again while doing nothing in between and it still rebuilds so I don't think it's because something else has changed
<mq32>
laters!
<samtebbs>
mq32: See ya
<samtebbs>
andrewrk: I see, caching in the build system would be cool
<Tetralux>
mq32: o/
<andrewrk>
samtebbs, yes, it's planned
<Tetralux>
Only the installation step is cached currently?
<samtebbs>
andrewrk: Is it something that can be tackled now or is it blocked? It sounds like an interesting thing to work on
<andrewrk>
it's not blocked, but it is an inherently difficult problem, pull requests would be welcome but also under deep scrutiny
<andrewrk>
well, it might be blocked by re-implementing the cache system from stage1 c++ to zig
<Tetralux>
Does stage2 build again yet?
<andrewrk>
I think we could potentially remove caching in zig0 and rely on a zig implementation of the "cache hash" system
<Tetralux>
So long as I can use the cache on Windows x)
<Tetralux>
I'm not sure I can build self-hosted on Windows.
<Tetralux>
Though, I haven't tried it in a while.
<Yardanico>
why can I be getting an OutOfMemory error when trying to append an element to an ArrayList?
<Yardanico>
I have 5GB RAM free on my PC (and 4GB swap free)
<andrewrk>
what allocator are you using?
<Yardanico>
std.debug.global_allocator
<andrewrk>
there are admittedly few docs but there is at least this, in front of that allocator: /// This should only be used in temporary test programs.
<Yardanico>
are there any other general-purpose allocators which I can use?
<Yardanico>
oh, "Are you linking libc? In this case, std.heap.c_allocator is likely the right choice, at least for your main allocator."
laaron- has joined #zig
laaron has quit [Remote host closed the connection]
<companion_cube>
is std.heap.direct_allocator one that just requests pages from the OS?
<andrewrk>
yes
<andrewrk>
it's good as a backing allocator
<companion_cube>
nice.
<companion_cube>
(I asked because I was seeing it in the arena allocator, indeed)
<daurnimator>
direct_allocator is also useful in that it requires no userland state
<daurnimator>
so useful for "the world is upside down" situations
<companion_cube>
std.heap.survival_mode_allocator
<daurnimator>
+ it means you can observe all your allocations via strace by looking for mmap/munmap
samtebbs has quit [Quit: leaving]
<Tetralux>
... and also wastes a bunch of memory xP
<daurnimator>
Tetralux: when debugging that doesn't matter :P
<Tetralux>
For a short lived program. Probably.
<Tetralux>
I guess.
<companion_cube>
I guess if you mostly allocate a few vectors/hashmap with a large initial size, it's good
<daurnimator>
companion_cube: not really IMO
<fengb>
You could use zee_alloc :P
laaron- has quit [Remote host closed the connection]
<Tetralux>
I mean, if you make a bucketarray allocator thingy and then always use that for any heap allocated thing, and then immediately resize to a reasonable number... then sure.
<daurnimator>
the other situation the direct allocator is useful is if you are going to go and modify page attributes with e.g. mprotect.
<fengb>
(Don't use it. It's not designed for lots of allocations)
<companion_cube>
daurnimator: oh that's super nice. So a library for storing sensitive data in memory, could have a custom allocator on top of that, that always protects the pages (like, noswap and all)?
<Tetralux>
I mean... how often you gonna do that?
<daurnimator>
companion_cube: yeah. you'd be able to use things like MADV_DONTFORK and MADV_DONTDUMP without much worry
<companion_cube>
well if you write crypto stuff it could be a good practice
<companion_cube>
if it's part of the allocator it's simpler, I assume
<daurnimator>
Tetralux: most programs... e.g. to protect random number state getting cloned into worker processes.
<Tetralux>
Which is why you'd probably write your own allocator.
<Tetralux>
daurnimator: Most of your programs do stuff like that?
<daurnimator>
Tetralux: I can't think of many programs I write that don't need random numbers at some point...
<Tetralux>
Doesn't that mean a syscall every time you want a random number?
shritesh has joined #zig
<Tetralux>
Two in fact
BitPuffin has quit [Read error: Connection reset by peer]
jzck has quit [Read error: Connection reset by peer]
vegai has quit [Read error: Connection reset by peer]
Snektron has quit [Read error: Connection reset by peer]
<Tetralux>
One to unprotect, one to protect
<daurnimator>
Tetralux: no
<Tetralux>
And then there's a race as well.
D3zmodos has quit [Read error: Connection reset by peer]
fengb has quit [Read error: Connection reset by peer]
Demos[m] has quit [Read error: Connection reset by peer]
<daurnimator>
Tetralux: you only need to seed with kernel-provided randomness once per thread/process.
<daurnimator>
Tetralux: the key is to know when you've been cloned() so that you can reinitialise from kernel randomness
<shritesh>
andrewrk: If there was a way to extract the ret val from a frame as an optional ptr, life would be so much easier :D
<Tetralux>
Wait - the thread needs to know if it's cloned?
<Tetralux>
Also - you use mprotect to protect the seed after initialization and only read it once from it's owning thread in order to init the rng.
<andrewrk>
shritesh, in this case would you be using .? or actually need to check?
<shritesh>
andrewrk: I want to errdefer right after an async call for cleanup without building an implicit state machine with conditional checks
<andrewrk>
shritesh, 3164 is the one to subscribe to for that
<shritesh>
andrewrk: Yep. Looks like it
<andrewrk>
shritesh, I had that example with cancel fully working - but I ended up backing out of it because I wasn't able to solve canceling non-async functions
laaron has joined #zig
<andrewrk>
it's still on the table. but status quo works, and doesn't prevent that from a future possibility
BitPuffin has joined #zig
laaron has quit [Client Quit]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
<shritesh>
Yes it does. But linking/flashing is still a pain
<andrewrk>
AVR is an experimental target in LLVM. That makes it Tier 4 in zig. I do enable AVR on the ziglang.org downloads though
<Yardanico>
mq32: too sad they didn't yet merge the xtensa changes
<mq32>
i think that will happen some time
<mq32>
i don't have my arduino stuff at home but i'll try to get an AVR blinky running when i get the time :D
* mq32
loves µC stuff
<Yardanico>
yeah, also I hope they'll add esp8266 support without waiting too much after their initial work gets merged (it only has esp32 support)
<andrewrk>
shritesh, I'm not sure exactly what that's doing, but that's the kind of thing I envision as a third party package that would be a "build dependency" once we have the package manager
<mq32>
zig build flash
<mq32>
nice :D
<andrewrk>
so you'd still be able to flash in 1 command: `zig build flash` or whatever
<andrewrk>
if you find that assert in a backtrace and change it to ir_assert or src_assert it will tell you where in your zig source code the issue is coming from
<mq32>
hm
<mq32>
i think i should start to compile my own zig compiler now :D
<mq32>
okay, i found the culprit
<companion_cube>
this edge ain't bleeding enough yet
<mq32>
it's the union over function pointer and number :D
<Yardanico>
wow, I can actually find places where I forgot to free stuff I allocated with valgrind
<mq32>
Yardanico, yeah valgrind is great
shritesh has quit [Remote host closed the connection]
<Yardanico>
and with magical "exe.valgrind_support = true;" I can even see source code lines
<Yardanico>
(their index I mean)
<Yardanico>
for me (who almost never used languages with manual memory management before) that's pretty cool
Akuli has joined #zig
<andrewrk>
Yardanico, valgrind_support = true is on by default in debug builds
<andrewrk>
valgrind gives you this in C as well. but there is one thing that zig's valgrind integration gives you right now that's unmatched - which is if you assign something to undefined when you're done with it
<andrewrk>
huh, I really should show this off on ziglang.org home page
<mq32>
hm, damn
<mq32>
i think i have to solve this different…
<Yardanico>
:D " definitely lost: 373,603 bytes in 1 blocks" (calling C function leaks memory :D), gonna solve that, it's pretty fun to fix memory leaks
<andrewrk>
Yardanico, std.heap.c_allocator integrates well with valgrind. don't forget to use --leak-check=full
<Yardanico>
andrewrk: yeah I'm using that
<andrewrk>
the tooling for native applications is unmatched
<Yardanico>
So I figured out I should add alloc.free even for variables which aren't allocated with alloc.alloc :D
<Yardanico>
" All heap blocks were freed -- no leaks are possible" :P
<Yardanico>
(well that variable is a special case since it's used as a variable which the C function uses to write the resulting string buffer into)
<mq32>
andrewrk, can i somehow create interrupt handlers with zig?
<mq32>
right now i use inline assembler, but GCC knows an attribute for that
<andrewrk>
mq32, what's stopping you?
<mq32>
boilerplate code :D
<mq32>
every interrupt handler requires inline assembler
<andrewrk>
what's stopping you from doing it without inline assembly
<mq32>
how do i annotate that the function is an interrupt handler?
<andrewrk>
my proposal for this would be to implement the planned https://github.com/ziglang/zig/issues/661 and then add this as another supported calling convention
<andrewrk>
std.mem.tokenize and std.mem.separate are useful for parsing
<Yardanico>
oh, I didn't know these were a thing :D also, asking about memory management - should I always have a deinit function for my struct if it has some memory which needs to be freed, or I can just write "defer mystruct.field.deinit();" in init function?
<Tetralux>
Yardanico: You know that won't work for floats like 4.0 right?
<Yardanico>
because for now these both work, but I don't know if the latter is considered good or bad
<andrewrk>
if your data looks like "w | x | y | z" you could use `var it = std.mem.tokenize(data, " |"); while (it.next()) |item| {}`
<andrewrk>
IMO get rid of the spaces and just use 1 byte delimiter
<Yardanico>
Tetralux: isDigit is not from ascii, it's my function and defined as "return (ch >= '0' and ch <= '9') or ch == '-' or ch == '.';"
<Tetralux>
Ah Good xD
<Yardanico>
andrewrk: yeah actually in the file these are stored without any spaces, I tried to find by looking for "scanf" in zig repo, but didn't find mem.tokenize thing
<Tetralux>
I honestly find it hard to get tokenize to work in my head for some reaosn
<andrewrk>
use std.mem.separate if you want "a||b" to return 3 items instead of 2
<Tetralux>
If it was split, it'd make more sense xD
<andrewrk>
separate is going to get renamed to split, tokenize is a good name
<Tetralux>
Wait - so what's the third item from seperate?
<Tetralux>
"a", "||", "b" ?
<Tetralux>
Only if so, tokenize does what split does in every other language I've used.
<Tetralux>
Oh wait - you mean it'd be: "a", "", "b" - in which case yeah - that makes more sense.
<Yardanico>
Wow I tried "while (it.next()) |item|: (current_var += 1){" and that syntax actually worked
<andrewrk>
it's a pretty decent language when the compiler doesn't crash, eh?
<Yardanico>
andrewrk: it's a good sign where people can intuitively write syntax which actually works and they've never seen it in examples before :P
<Yardanico>
s/where/when
<Yardanico>
I mean, firstly I tried to place :(current_var += 1) before |item|, but that didn't work and worked on the second attempt
<andrewrk>
there's a good reason for that, item is in scope
<andrewrk>
while (node.next) |child| : (node = child) {}
<andrewrk>
I wonder if it would be possible to make calling conventions a userland concept. Define them at comptime
<andrewrk>
then arm_aacpscc would be implemented in the std lib
<mq32>
andrewrk, my approach was to create function decorations in userland
<mq32>
by taking a nakedcc function as an argument and returning that function with prefix, @inlineCall, postfix
<mq32>
also: most of my hackery wasn't even necessary :)
<andrewrk>
looks like there are some other reasons the std lib parseFloat isn't its final form, there are some limitations listed there as well
shritesh has quit [Quit: Leaving...]
<fengb>
Worthwhile to port the nim code as a test
kristoff_it has joined #zig
<andrewrk>
the next thing I'm interested in as far as parseFloat goes is one that solves the problems - round trip accuracy, supports all the rounding modes, handling denormals, etc
<andrewrk>
and then after that is thoroughly covered by test cases, I'd be interested in an implementation that improves perf
kristoff_it has quit [Ping timeout: 245 seconds]
<Sahnvour>
isn't the new ryu algorithm what we'd want to use in the end ?
<andrewrk>
for rendering
kristoff_it has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<Snektron>
Hm
<Snektron>
I might replace the rpi with an arduino for the project i had zig in mind for
<mq32>
andrewrk, regarding the last error i had: should i file an issue or did you fix it already? :D
<Snektron>
Now that will be a fun experiment
<andrewrk>
Snektron, AVR is tier 4
<andrewrk>
not to discourage you, just so you know what you're up against
<Snektron>
Yes i saw it, i'll probably take a quick stab at it and see where i will get
<Snektron>
I assume clang's avr backend is pretty solid, and according to godbolt it can compile code for it without some crypting internal clang error
Akuli has quit [Quit: Leaving]
<mq32>
Snektron, most interesting part is the bootstrap as well
<Snektron>
Although its another "emit random symbols a random library should provide"
<mq32>
AVR uses a boot jump table for interrupts
<Snektron>
Hmm
<mq32>
(so the table is built from jump instructions, not pointers)
<mq32>
this may require some inline assembler
<Snektron>
Nothing that seems impossible
<mq32>
yep
<mq32>
i got blocked for today, too lazy to rewrite my code that the compiler won't crash anymore :D
<Snektron>
Anything to avoid the horrible processing ide am i right
<Snektron>
I might actually use the project in an uni project
<Snektron>
Saves me thinking of something else
<Snektron>
Anyway, andrewrk, did you see the question about off_t, before i stupidly closed and reopened the issue
<Yardanico>
fengb: well I got about from 11ms to 6ms in one iteration after using Nim's float parsing algorhitm which is faster than Nim parsing the same stuff (it got 9ms per iteration)
shankar has joined #zig
<Yardanico>
when I had 11ms per iteration in Zig the fmt.parseFloat was about 45% of runtime
<Yardanico>
now nim's float parser is about 9% of runtime (75% of runtime is now is actually used by LZMA decompression function from the C library :D)
<Yardanico>
oh wow, I found an LZMA implementation in Zig on github, gonna also try that
<Yardanico>
it's for simple benchmarks but shows time per one iteration and you can customize number of them
<Tetralux>
fengb: Compiler bug then; should give compiler error.
<fengb>
But it shouldn’t seg fault
<fengb>
So the s should be equivalent to `const s: []const u8`
<kristoff_it>
average time: 18.8941849609375 ns
<kristoff_it>
average time: 322.6269822265625 ns
<kristoff_it>
from a rmbp 15
<Yardanico>
whyy it's so slow for me hmm
<mq32>
Yardanico, what do you mean by "slow"?
<mq32>
taking 45% time?
<Yardanico>
mq32: I'm talking about Tetralux's implementation, for me it's only like 17% faster :)
<shankar>
hello
<Tetralux>
And for it's like.... 10x.... 1000% faster? xD
<Tetralux>
shankar: /me waves.
<Yardanico>
maybe there's some kind of bottleneck in my system or something is wrongly configured
shankar has quit [Remote host closed the connection]
<kristoff_it>
so now I crosscompiled it for linux and run it in docker, and... I'm still waiting for the first message to print
shritesh has joined #zig
<mq32>
perf stat may help!
<mq32>
so you can compare cycle count, IPC, cache miss values and so on
<mq32>
that may explain a lot
<mikdusan>
Tetralux: is rhs value of s a zero-length slice?
<Tetralux>
Nope
<Tetralux>
s is more than two chars.
<mikdusan>
maybe storage behind s went missing. anyhow i can't reproduce with just that alone.
shritesh has quit [Remote host closed the connection]
<Tetralux>
Okay. I also made it error if you give it too many digits, since that gives you garbage otherwise.
<Tetralux>
I'll also note that the stdlib just gives you the garbage.
<Tetralux>
(Paste updated.)
<Tetralux>
kristoff_it: Might be interested in that ;p
<kristoff_it>
Tetralux: noted, thanks!
<Tetralux>
o7
<Tetralux>
(Adds some clarity comments to the paste.)
shritesh has joined #zig
<kristoff_it>
Tetralux: thanks, I've saved it, I'll take a look more in detail once I understand a weird segfault that involves buffered in/out streams
<kristoff_it>
Without a bufstream, everything works ok. With bufstreams, in debug mode, everything works ok. With bufstreams + release-safe/fast, I get a crash
<kristoff_it>
the crash is related somehow to the length of the message I'm sending (so that makes me think it's memory corruption), but everything seems normal when inspecting the variable in gdb
<mikdusan>
kristoff_it: paste code that creates and uses bufstream
<kristoff_it>
this is where I instantiate everything
<kristoff_it>
I remember that I must make sure to keep around the actual struct and not just the interface, I already made that mistake with rand in the past
<kristoff_it>
so I'm storing basically everything in the struct
<mikdusan>
`new.bufin = ... &new.in.stream;`
<mikdusan>
and new.bufout
<mikdusan>
by creating new as local inside initIp4 it's not using copy-elision.
<mikdusan>
thus new is copied on return and those pointers become bogus
<kristoff_it>
uhh ok
<mikdusan>
set it up so your final line is `return Self{ .... };`
<kristoff_it>
ok I'll try, thanks
<Yardanico>
does anyone here know how to create a build.zig such that I'll be able to link a dynamic (.so) library with my binary?
<mikdusan>
oh wait.
<Yardanico>
it currently says "liblibrouter: linker needs 1 or more objects to link" and I don't know why is that
<mikdusan>
we don't have syntax for you to self-ref a return value yet.
<mikdusan>
so after Init(), set new.bufin and new.bufout
<Yardanico>
However it works if I compile it with this command "zig run src/main.zig --library c --library src/liblibrouter.so --library-path /home/dian/projects/zigrs/src/"
<kristoff_it>
mikdusan: sorry I'm not sure I follow what you're saying. I re-wrote the function with a final return Self {...} and now I don't get any crash. I updated the Gist with the new version.
<mikdusan>
can u pastie the update
<mikdusan>
ah got it
<mikdusan>
i really wish we had `@result()` for this
<mikdusan>
or even `@Self()` :)
<kristoff_it>
mikdusan: I think you were onto something. The small test passes, but I have a more complex routine and that still crashes.
<mikdusan>
just prepping a diff
<kristoff_it>
I think I get it: this isn't fine either because I can't instantiate the bufs independently and only after place them in the struct. they need to be created directly in there, right?
<mikdusan>
commented.
<mikdusan>
i don't know what to call this... but it's a curiously recurring zig allocate-before-init pattern :)
<kristoff_it>
ah wow ok in retrospect that's definitely the way to create everything directly in the right place
<kristoff_it>
thank you very much, I'll try it now.
<mikdusan>
i have a few typos there. but i'm almost sure this is the issue
<kristoff_it>
mikdusan: perfect. everything works now, and I've even discovered a bug with .close() (I forgot to save the file descriptor in the struct) thank you very much!!
<mikdusan>
👍
<fengb>
Oh... I think you copied the socket streams and that broke the interface pointer
<mikdusan>
yup
<kristoff_it>
yeah, same thing that I did with the xoroshiro rand generator
<kristoff_it>
this stuff actually the only annoying thing that I'm hitting regularly with zig
<mikdusan>
kristoff_it: with this it would be possible to access call-site storage inside the init function:
<mikdusan>
so for one possibility is for a new builtin like `@result()` from inside fn body gives the correct pointer
shritesh has quit [Quit: Leaving...]
<kristoff_it>
that would make sense. also an error when a copy happens to something that should not be copied. If I encountered a flurry of "you're copying stuff that should not be copied" I would have eventually solved it, probably
<mikdusan>
local stack address escape analysis is something that's been mentioned before and would make great for diagnostics. it likely wouldn't get _everything_ but still a huge win imo