<akavel>
I kinda hoped just .h files would be enough
<andrewrk>
unfortunately that's not how C works. why are you adding . as an include dir? is lua copied into your project's tree?
<akavel>
yep
<andrewrk>
ok you probably want zig to build lua for you then, so you'll need to add that to the build script first, then you can do lib.linkLibrary(lua)
<andrewrk>
that might be what daurnimator's script does, I didn't look
<akavel>
I mean, I only copied lua.h and lauxlib.h into my project
<andrewrk>
in this case, how were you expecting your project to find the actual lua library files?
<andrewrk>
that's not a rhetorical question, it's something you must ask so that other people (or yourself later) know how to build your project
<akavel>
as I said, I kinda thought .h files would be enough for building a dll, and then lua.exe would be able to use such a dll
<andrewrk>
you either need to have your project depend on lua being installed on the system, or you need to vendor it as part of your project. when zig has a package manager, then it could be gracefully solved with a package
<akavel>
I'm kinda having some flashes of memory that maybe there was some kind of .def files, that were used in place of .dlls as dependencies
<andrewrk>
lua has to exist somewhere. it has to either be installed or you have to provide it with your project. this is a fundamental property of nature, independent from any programming language
<daurnimator>
FWIW you shouldn't actually link against lua
<daurnimator>
the symbols are provided by the interpreter/host application
<andrewrk>
it's a header-only library?
<andrewrk>
that wasn't the case when I looked at it
<daurnimator>
andrewrk: no. the host application provides symbols to be used by a lua module
<daurnimator>
--> the host application links against lua; lua libraries shouldn't.
<akavel>
kinda "reverse linking"
<akavel>
or "reverse dependency"
<andrewrk>
you can't have a dll that depends on a library that isn't linked
<andrewrk>
you can have a .lib though
<daurnimator>
andrewrk: sure you can
<daurnimator>
the dynamic loader resolves it for a dynamic library
<mq32>
these ring-dependencies are pretty common for shared-object plugins
<mq32>
both in linux and windows world
<andrewrk>
I see
<andrewrk>
I guess that's a missing build.zig api then, allowing undefined symbols in the linker
<mq32>
this stackoverflow topic explains the pattern quite well
<andrewrk>
thanks
<fengb>
Quite philosophical: "lua has to exist somewhere. [...] this is a fundamental property of nature"
<akavel>
:D
<akavel>
The Law of Lua
<akavel>
Kelley's Law of Lua Conservation?
<mikdusan>
andrew: context: https://github.com/ziglang/zig/pull/4119#issuecomment-572803709 "Instead, new codegen.cpp code needs to be added to support sub-byte addressing with arbitrary alignment of the host integer, and the layout code for packed structs needs to support non-power-of-two host integers."
akavel has quit [Ping timeout: 260 seconds]
<mikdusan>
if we allow arbitrary alignment (non-power2) host integers, why do we even need host integers? deduce load size from alignment and field bits ?
zfoo has joined #zig
<mikdusan>
I think I'll make a table to grok these rules
return0e has quit [Ping timeout: 268 seconds]
blueberrypie has quit [Quit: Ping timeout (120 seconds)]
return0e has joined #zig
blueberrypie has joined #zig
mokafolio has quit [Quit: Bye Bye!]
adamkowalski has joined #zig
mokafolio has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<AndroidKitKat>
really dumb question, i'm getting an error when im trying to build-exe from latest head
<AndroidKitKat>
"Unable to open /Users/meiseman/Library/Application Support/zig/stage1/native_libc.txt.tmp: No such file or directory"
<AndroidKitKat>
this just a simple hello world am im not sure
<andrewrk>
not a dumb question. mikdusan, looks like the new native_libc.txt cache code needs to ensure the directory exists
<andrewrk>
I'll be happy to help with the packed struct thing in ab it
<AndroidKitKat>
should i just mkdir the folder?
<mikdusan>
AndroidKitKat: sounds related to a recent change I made; you are on macos?
<AndroidKitKat>
I am on macOS
<mikdusan>
AndroidKitKat: wait a moment. I'd like to reproduce
<AndroidKitKat>
thanks
student069 has joined #zig
<mikdusan>
AndroidKitKat: can you paste the zig command line?
<AndroidKitKat>
wdym?
<AndroidKitKat>
zig version?
ScentedFern has joined #zig
<AndroidKitKat>
0.5.0+357f42d
<mikdusan>
`zig build-exe hello.zig` <-- anything other args?
<AndroidKitKat>
no
<AndroidKitKat>
`zig build-exe ../asdf.zig`
<mikdusan>
`which zig`
<AndroidKitKat>
//usr/local/bin/zig
<AndroidKitKat>
i did --HEAD when installing with brew
<AndroidKitKat>
but I also confirmed it doesn't work with the binary from the website
<mikdusan>
ok let me try a few variations
<AndroidKitKat>
thanks
<mikdusan>
waat. it fails for me. I can't believe I didn't test this
<AndroidKitKat>
f
<mikdusan>
AndroidKitKat: ok I'll work on a fix. in the meantim just create the dir all the way up to and including stage1/
<andrewrk>
mikdusan, another workaround would be zig build-exe hello.zig -target x86_64-linux-gnu
<andrewrk>
cross compiling would init the cache :)
<AndroidKitKat>
that'd do it chief
<student069>
thanks o7 I was having the same issue
<pixelherodev>
`<mq32> these ring-dependencies are pretty common for shared-object plugins` can confirm
<pixelherodev>
Literally using one in Zig at the moment
<pixelherodev>
Works w/o issue as is, even with unknown symbols though
<pixelherodev>
But I'm not using build.zig
<pixelherodev>
I'm using `zig build-lib`, so that might be why
<shachaf>
How much prefix tree code is there that you don't just write at the use site anyway? It's a very transparent data structure.
<shachaf>
Maybe something like a radix tree is useful to have in some library.
mahmudov has quit [Remote host closed the connection]
<daurnimator>
fengb: in practice tries are inefficient
<daurnimator>
fengb: we do need a btree though; and a radix tree.
<daurnimator>
and a radix tree can be a type of trie
<fengb>
I actually realized bsearching an array would be smaller and faster for me >_>
<shachaf>
Hmm, what sort of B-tree thing are you after?
<shachaf>
I wrote a B+ tree implementation in C recently for u64->u64 maps, and it's faster than anything I've benchmarked it against.
<daurnimator>
shachaf: hmm. I wanted one for some reason a couple of months ago. can't remember off the top of my head now
<shachaf>
(absl::btree_map, Rust btree_map, etc.)
<daurnimator>
FWIW I wanted the radix tree for a general purpose allocator.
<daurnimator>
--> given a pointer (and possibly a length): look up the allocation metadata
<shachaf>
Why not a hash table or something, if it's just point queries?
<fengb>
Hmm is that just a compacting trie?
<shachaf>
Anyway if there was some interest I could port my thing to Zig maybe.
<student069>
could someone point me to example code for reading a file in zig?
<daurnimator>
shachaf: one reason I had was that I wanted to be able to pass an address in the middle of an allocation; and find out about what it belonged to
<shachaf>
Ah, so not just point queries. Makes sense.
<shachaf>
I bet a B+ tree thing would be way better for that sort of thing, though.
<daurnimator>
student069: read a file as a whole? line-by-line? how did you want to read it?
<daurnimator>
shachaf: not really. radix trees are the perfect data structure for it
<student069>
Line by line is what im looking for
<shachaf>
Actually, hmm, you could write a special-case B+ tree for storing intervals which would be more regular than the usual kind.
<daurnimator>
shachaf: I also want to write a maple tree implementation in zig :P but first things first
<shachaf>
daurnimator: I stand by my bet.
<pixelherodev>
What I've gotten out of the last few minutes of the chat: I really need to get some more experience with data structures :P
<fengb>
The only thing I know about B trees is that they're everywhere in file systems and databases >_>
<daurnimator>
student069: hmmm. there's io.readLineFrom.... but I don't like it already
<pixelherodev>
readUntilDelimiterOrEof
<pixelherodev>
That's what I'm using for the LLVM parser
<pixelherodev>
Though I'm actually using a slightly modified version
<daurnimator>
pixelherodev: ah yeah that would work for student069
<student069>
oh neat
<pixelherodev>
I didn't want to tweak ~~the stdlib~~ zag at the time so I just did it in the parser source
<pixelherodev>
Yeah, just pass `\n' as the delimiter
<pixelherodev>
I'd suggest finding the source for it and reimplementing a local version that can check for multiple delimiters, or manually stripping off any `\r`s found at the end of lines
<daurnimator>
student069: so yeah; get dir -> open file -> get reference to file's stream field -> call `readUntilDelimiterOrEof` with '\n'
<daurnimator>
student069: you will probably want to wrap it in a buffered reader too
<student069>
tyvm pixelherodev & daurnimator
<pixelherodev>
I'll probably submit a PR opening a version that requires a comptime delimiter
<pixelherodev>
No problem!
<student069>
This is pretty neat to see, having just taken a compilers class last semester
<pixelherodev>
s/comptime delimiter/comptime array of delimiters
<fengb>
I feel like such an old fart
<pixelherodev>
Should allow for the same performance as manually checking each delimiter
<pixelherodev>
fengb, why?
<shachaf>
I should flesh that text out a little more and post it somewhere probably, I think the usual explanation is much more complicated.
<fengb>
Cause apparently everyone in here is gen z >_>
<daurnimator>
What's gen z? >.<
<student069>
1998->
<student069>
ish
<daurnimator>
I thought that was millenials
<student069>
you would think that
<fengb>
Millennial is ~1980-96
<Snektron>
I got ninjad
<AndroidKitKat>
Gen Z skrrt skrrt
<fengb>
But we're still apparently teenagers who'll ruin the world
<daurnimator>
fengb: I thought that was Gen Y?
<Snektron>
Fengb, how old are you?
<fengb>
35
<fengb>
Millennial is the new term for gen y lol
<Snektron>
About the B trees
<Snektron>
It seems to me like a memory efficient alternative to hash maps for associative types
<Snektron>
On tries, i read julia tries are quite efficient
<shachaf>
Hash tables are certainly going to do better when you don't need ordering.
<daurnimator>
Snektron: b trees preserve order; so things next to each other stay next to each other
<Snektron>
Oh i forgot to type:
<Snektron>
B trees can be memory efficient when used together with an arena allocator
<AndroidKitKat>
he was running Ubuntu 18.04 using the latest head and im on Fedora 31 same version
<mikdusan>
AndroidKitKat: building a binary on one machine by zig defaults to use host cpu features
<AndroidKitKat>
yeah but im trying to compile the code i linked
<AndroidKitKat>
not transfer binaries
<mikdusan>
oh
<AndroidKitKat>
jcharbon: was the one who wrote it
<AndroidKitKat>
we're a rag tag group of young men who like to use esoteric langs
<AndroidKitKat>
i can build the executable just fine on my box, but it doesn't do anything
<mikdusan>
maybe your pwd is empty
<mikdusan>
works for me on archlinux
<AndroidKitKat>
weird
<AndroidKitKat>
it's working when i do ./ls /etc but not certain things
<student069>
im facing the same issues on AndroidKitKat on rhel
<student069>
hmmm maybe its debug time? we appreciate the help tonight btw
marmotini_ has quit [Remote host closed the connection]
<daurnimator>
AndroidKitKat: "certain things"?
<AndroidKitKat>
yeah, like the cwd
<AndroidKitKat>
for example
<AndroidKitKat>
/home/foo/bar works but /home/foo doesn't
<traviss>
i noticed that you're using `var iter = dir.iterate();` which i thought should be `var iter = dir.iterator();`
<traviss>
just a guess thought. not sure what the difference is.
<daurnimator>
AndroidKitKat: misc comments: no need for your `stat_ptr` variable. use `mem.cmp` for comparing slices. sorting should be optional for a ls-alike, default is *not* sorted. declare you variables at the latest time possible: e.g. don't hoist your declaration of `tempString` out of the loop
<AndroidKitKat>
jcharbon: ^^
<AndroidKitKat>
thanks for the tips
<daurnimator>
also use std.ArrayList for tracking entries... not a static sized array and a counter
<AndroidKitKat>
that's a very helpful hint
<AndroidKitKat>
all of us were scratching our heads at that
<daurnimator>
in general you variables should be ~90% `const`, with only a couple of `var`.
<pixelherodev>
Although generally, generalizations are false
<daurnimator>
pixelherodev: In theory, theory matches practice; in practice, it doesn't.
<pixelherodev>
Nice one :)
* andrewrk
doing a refactor that touches nearly every line of ir.cpp @_@
<daurnimator>
andrewrk: check for any open PRs first :P
<andrewrk>
anything touching ir.cpp will likely have to be manually rebased
metaleap has joined #zig
<fengb>
Is it something like `s/ / /`? >_>
<daurnimator>
`git diff -w` "what changes?" ;)
<andrewrk>
it divides IrInstruction into IrInstSrc and IrInstGen base types
<andrewrk>
saving memory and preventing bugs
<andrewrk>
hopefully enough to merge #4264
<andrewrk>
I'm on line 2312 of 30,000 in the compile errors
marmotini_ has joined #zig
<AndroidKitKat>
sounds... exciting?
<fengb>
Gotta break eggs
marmotini_ has quit [Ping timeout: 265 seconds]
<jcharbon>
daurnimator .. a few questions on the comments you made. I've been trying to adjust my code closer to what you said, but am running into personal issues due to lack of understanding.
<jcharbon>
1 - I don't fully understand your recommendation for mem.cmp. I am using stat_ptr with the syscall stat for a directory. does mem.cmp do the same? also I didnt even realize I was working with slices there?
<jcharbon>
2 - Why do you think sorting should be optional? just a preference? I thought ls-like functions usually were always default alphabetized.
<jcharbon>
3- what's the best way to understand how to use std.ArrayList? Can you possibly give me an example to see how it's used?
<jcharbon>
4 - why should most of my variables be const? I feel as though all of my var variables need to be like that because they change throughout the program running. Maybe its just my current limited grasp of how to code in zig.
<daurnimator>
jcharbon: 1. I meant swap out the `alpha_compare` function for `mem.cmp`.
<jcharbon>
oooh that makes more sense
<daurnimator>
jcharbon: 2. `ls` has a variety of sorting flags (by name/mtime/ctime/owner).
<daurnimator>
jcharbon: 3. looks at the tests in lib/std/array_list.zig
<daurnimator>
jcharbon: 4. most variables *shouldn't* change :) what makes you think they should?
ltriant has quit [Quit: leaving]
dddddd has quit [Read error: Connection reset by peer]
<jcharbon>
Well I guess a decent chunk of mine will go away if I use mem.cmp and ArrayList. I guess I didn't think too much in beyond using incremental counters for everything
<jcharbon>
Also I guess throughout all my coding experience I never thought too-too much about constant but the more I think now i see your point
<andrewrk>
zig will reward you for generally preferring const to var
<daurnimator>
jcharbon: two related principles: prefer the smallest scope you can for variables. only make something non-const if you're going to modify it.
<jcharbon>
Thanks for the tips. I will keep this all in mind going forward haha. Thanks a lot for all the help. I really appreciate it!
<fengb>
Matt Godbolt has the best last name ever
<andrewrk>
what about Usain Bolt, who holds the world record for the 100 metres and 200 metres sprint
<daurnimator>
I had a friend that had an appointment with a "Dr Hurt"
<mikdusan>
andrewrk: ok if I merge #4279 "stage1: make sure to create native_libc.txt dir" - Windows CI is out to lunch
<andrewrk>
yep
<andrewrk>
I'm working on a master branch commit to reduce memory usage
<mikdusan>
nice!
<mikdusan>
exploring ideas: if self-hosting implemented comptime via bytecode/vm (is that what Jai does?), what would the pros/cons be? I'm thinkin pro would be less memory usage but slower performance for the main use case - run once
<andrewrk>
is that different than what stage1 does?
<daurnimator>
Another proposal would be to just.... not cache comptime function calls. Or use an LRU cache.
<daurnimator>
jcharbon: oh I just noticed that you use os.linux.stat... and don't check the result
<andrewrk>
not caching comptime calls breaks ArrayList(i32)
<daurnimator>
jcharbon: we should (we don't... but should) have a `os.Stat`
<daurnimator>
jcharbon: however; at least on linux, getdents() returns some pieces that stat tells you
<andrewrk>
we have std.fs.File.Stat which is cross platform
<andrewrk>
generally it would be advisable to use the cross platform API first, and use OS-specific (or POSIX-specific) API only if that is not viable
<daurnimator>
andrewrk: that requires an open file handle
<daurnimator>
andrewrk: you might not have read permission on a file; but you can still `stat` it.
metaleap has quit [Quit: Leaving]
<andrewrk>
yeah sounds like there is some missing API surface
<daurnimator>
andrewrk: yep. os.statat is missing; and that should probably be exposed as a fs.Dir method `statPath` or similar
<daurnimator>
sounds like a good contributor friendly PR for jcharbon or AndroidKitKat to get their hands dirty ;)
<mikdusan>
well played daurnimator ... well played
adamkowalski has joined #zig
<fengb>
So the Zig compiler basically contains an interpreter
<fengb>
We could attach a repl to it :P
<andrewrk>
now I am on line 3596 of 30,000 in compile errors
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
livcd has joined #zig
adamkowalski has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 248 seconds]
lunamn_ has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
return0e has quit [Remote host closed the connection]
eagle2com has joined #zig
eagle2com has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<metaleap>
have a func with a `comptime T: type` arg, branching on T. want it to return `!void`. only some branches could return error, others dont. compiler complains "must return at least 1 error". can confirm have call-site T instantiations that hit all branches. known issue?
<metaleap>
s/have/have various different
<mq32>
you can always make the error set explicit
<mq32>
fn() error{InvalidSomething}!void
marmotini_ has quit [Remote host closed the connection]
<Snektron>
metaleap, i think that might be a problem with how a comptime function evaluates
<Snektron>
cause its lazy, if it doesn't hit any error during evaluation of a function, it won't know the exact error set
<Snektron>
Its can
<Snektron>
It can'
<Snektron>
wtf
<Snektron>
anyway, it can't figure that out from multiple invocations because the actual error set might be different per invocation
<Snektron>
consider `return if (comptime a) error.A else error.B;`
HesamR has joined #zig
aequitas_ has quit [Remote host closed the connection]
<betawaffle>
is it possible to specify multiple outputs from an inline assembly instruction, or would i need to arrange for the outputs to be read out in multiple inline asm statements?
<Snektron>
I think its possible if you add the outputs as pointers
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
<betawaffle>
what would be the syntax for that?
marmotini_ has quit [Remote host closed the connection]
marmotini_ has quit [Remote host closed the connection]
<Snektron>
Too bad gitea has no Zig syntax
zfoo_ has joined #zig
<betawaffle>
does llvm let you tell it explicitly what register to put an argument in? like a manual calling convention?
<Snektron>
i think the best way to do that is with asm
<betawaffle>
anyone know how i can get rid of this seemingly useless `movl %eax, %eax`? https://godbolt.org/z/nLKp8i
<metaleap>
Snektron mq32 thx! makes sense
<Snektron>
betawaffle, you could write the entire function in assembly
<betawaffle>
yeah, that's what i ended up doing
<Snektron>
hm
<Snektron>
I hopy andrews assembler thingy will use intel syntax instead of at&t
<Snektron>
hope*
<metaleap>
std.HashMap: for a call path where `.put()` calls `.autoCapacity()` calls `.ensureCapacityExact(.entries.len * 2)` the first thing in there `assert(math.isPowerOfTwo(new_capacity))` which fails for me, ergo can fail for innocent user-land `put`s. in my case len was 3 so 6 was attempted (not by me but from inside std/hash_map.zig via my put)
<metaleap>
known issue? can file or PR otherwise. the assert with now TODO suggests to me that ensuring power-of-two is expected to occur somewhere prior/user-facing (likely in `put`)
<metaleap>
oh of note! thats only when i do `myhashmap.initCapacity(iKnowHowManyItemsWillBeThere)`
<metaleap>
so i suppose "user error" / initCapacity not fully commented yet. my bad =)
<fengb>
We should probably assert at initCapacity
<metaleap>
well there's still time til 1.0 =) good thing there's math.ceilPowerOfTwo
<fengb>
I think this is seeing there's 1 element and trying to make it a u0 enum
<metaleap>
oooh what a funky corner case
<fengb>
What is this, 1 based indexes
<fengb>
Do the numbers matter?
<metaleap>
what this is? Language Server Protocol
frmdstryr has quit [Quit: Konversation terminated!]
<fengb>
I'm making a dumb joke. We don't support VB arrays around these parts 🙃
<metaleap>
adding a "fantasy/never enumerant" will probably hotfix this for now, but hum gotta be a way to have such scenarios work oob eventually, thx for your sharp eye fengb =)
<metaleap>
VisualBasic arrays?
<metaleap>
lol got it
<metaleap>
1-based, heh, how about lua then
<fengb>
That depends on whether daurnimator is asleep
decentpenguin has joined #zig
<metaleap>
now with my "hotfix" in, a 2-member enum such as `DiagnosticTag` errs with "integer value 2 cannot be coerced to type 'u1'"?! really bugs me out.
<metaleap>
so really enums have to start with 0 right now huh? if you need to pad with discard values. hope `_` as ident will be supported at least
marmotini_ has quit [Remote host closed the connection]
<fengb>
How important is the number? If not, you can let Zig auto generate a number. If it is important, you should probably know the underlying number type
<metaleap>
the number values of these enumerants are serialized/deserialized to/from json so they're inviolably prescribed. but i figured out the non-exhaustive enum story so that helps
marijnfs has quit [Remote host closed the connection]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 265 seconds]
return0e_ has quit [Remote host closed the connection]
<andrewrk>
what do you expect @tagName to return for a number that is not in the set of named values?
decentpenguin has quit [Quit: decentpenguin]
<andrewrk>
a nice beginner contribution to the stage1 compiler would be to replace all the zig_panic("TODO ...") with add_compile_error("TODO ...")
Akuli has joined #zig
<SyrupThinker>
andrewrk: I'd think undefined
<metaleap>
good point! i'd say "_" is apt for that.. or optional
<metaleap>
i'll push std PRs for the months to come I feel, but c++ is out at my end =)
<andrewrk>
I think @tagName has to have an optional return type for non exhaustive enums
<andrewrk>
not 100% sure yet though
<metaleap>
either way users would have to check --- either for "magic name" / "_" or for null --- better to be made aware of the necessity by the compiler via optionals
<metaleap>
(i mean, on average / in many / most cases i guess, perhaps not always)
kristoff_it has joined #zig
<andrewrk>
you can't check if it equals "_" because it is ambiguous with a real tag name
naltun has joined #zig
<metaleap>
I'd vote for optional anyway, over special-name-value (say "" instead of "_")
return0e has joined #zig
<fengb>
But that means changing the signature depending on context
<andrewrk>
yeah that's a problem
<andrewrk>
exhaustive enums are more elegant than non
<naltun>
Does Zig support HTTP user-agents? Something like:
<fengb>
How about returning 💩
<naltun>
const get = @import("std").http.get; ***
<naltun>
I'm trying to implement a CLI I wrote, but I require making HTTP requests
<andrewrk>
naltun, not yet without a third party library such as curl. we're trying to solve some async i/o stuff first
<naltun>
andrewrk, aynsc is good. Okay. I haven't tested using an existing lib, but using libcurl could be a fun exercise. Thanks.
<andrewrk>
maybe 💩 can be the default user-agent string
<metaleap>
"But that means changing the signature depending on context" is that so bad for comptime? sure when you check enums back and forth it can be annoying but otherwise each incompatible "overload" fits exactly the different meanings passed to. might even prevent sloppy refactors
traviss has quit [Remote host closed the connection]
<metaleap>
s/check/change
kristoff_it has quit [Remote host closed the connection]
naltun has quit [Remote host closed the connection]
return0e has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
naltun has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Client Quit]
kristoff_it has joined #zig
<Snektron>
andrewrk, don't you mean 🦎
<Snektron>
My favourite is 🐍 of course
adamkowalski has joined #zig
<metaleap>
my hexchat on void doesnt emojis. probably keep it that way =°)
<jcharbon>
daurnimator: i would be more than willing to help with a statPath contributor friendly PR, but am too much of a noob with PRs and that process to even know where to get started haha. I would need a bit of guidance, but again, am more than willing to help contribute :)
<naltun>
I recognize a daurnimator from the Arch repos as a maintainer. Probably same person. Neat.
adamkowalski has quit [Remote host closed the connection]
<fengb>
Yes he is
<fengb>
Internet famous!
<andrewrk>
jcharbon, I believe GitHub has some nice tutorials on how to contribute to projects via pull requests
<naltun>
Question: Why does the following produce a value ending with e+00?
naltun has quit [Remote host closed the connection]
<andrewrk>
oh nice I didn't know tiehuis was actively working on it
<andrewrk>
is zig in the news somewhere? 3 new sponsors today
<andrewrk>
btw I decided to pull the trigger on starting Zig Software Foundation. so that'll be official within a few months if all goes well.
<Snektron>
nice, congratulations
<BaroqueLarouche>
nice!
<mq32>
\o/
<fengb>
Congrats
naltun has joined #zig
<andrewrk>
yeah. then people (and businesses) will have 2 new important options available: (1) donate money to a non profit org bank account, which is held accountable by law to uphold the org's mission with the money (2) the donations are tax deductable
<BaroqueLarouche>
also you could ask for devkits of consoles with a proper organisation
<fengb>
Would there be employee #1 in the foreseeable future? :)
<andrewrk>
plans for funding the org are: provide a way for people to donate directly to the org, and me personally to donate from savings. I have enough to contract part time work, but the first job opportunity will probably be a "grant proposal writer"
<andrewrk>
e.g. the job isn't to code, it's to try to get more money to the org
<andrewrk>
but if there is more cash flow, then yes I absolutely want to spend it on employee or at least contracting hours, so contributors can get paid
<fengb>
Oh... I never thought about the logistics
<andrewrk>
I would be careful about hiring as an employee unless the cash flow was very stable
<fengb>
That's a good point
<mikdusan>
andrewrk: when you get a chance, I'm trying to amalgamate what a `packed struct` is likely to be in the future (with #3133) before any related PR work; corrections and feedback welcome:
<metaleap>
andrewrk: on point (2) tax deductable: not sure if you'll focus on US first or global from the outset, but if you take a weekend (or pro-bono / student law-person) to figure out exactly what slip of document to issue (once a year) to EUR zone folks (entities and self-employeds) for donations, it could prove most worthwhile. many devs are freelancers here on this continent and have annual income tax figures between
<metaleap>
8-30+K (damages for mundane enterprise morass often) depending on other write-off-ables. and to stay sane they often have "currently-market-irrelevant/emerging/pet techs" to play with during off-hours, that they'd love to divert some of these otherwise-to-the-govt funds to. just sth to keep in mind
<Snektron>
(i think andrew lives in Canada so focussing on the US would be pretty weird)
<fengb>
He's in NY
<andrewrk>
mikdusan, #3133 would enable packed structs to opt in to non-well-defined memory layout
<andrewrk>
e.g. you could embed a struct in a packed struct. between #3802 and #3133, the only difference between `struct` with all fields `align(0)` and `packed struct` would be very similar
<andrewrk>
that sentence didn't make sense after I edited it
frmdstryr has joined #zig
<andrewrk>
mikdusan, "field order matches declaration order; no extra fields added by zig*; all fields align(0) by default;" would be the entire set of distinguishing characteristics of a packed struct
<andrewrk>
(* unless opted in which is a not-yet-accepted proposal)
<mikdusan>
(yes). I need to word things better. I kind of want to show how a packed struct begins it is considered guaranteed memory layout, and opt-in I used the term phrase "becomes opaque"
<andrewrk>
but a lot of the packed struct logic you have listed there would apply to align(0) fields of normal structs as well
<mikdusan>
oh i c what you're saying. the packed-struct continues to be a packed struct basically as if we... joined P0+S0+P1 (where P is packed and S is plain)
<andrewrk>
yes
<andrewrk>
so you would actually be able to embed non-packed-structs in packed structs, and have them be align(0), so they get bit-packed
_Vi has joined #zig
<mikdusan>
what happens with method syntax `packed_obj.packed_field.printName()` ?
<andrewrk>
(...).printName() evaluates the ... expression as an lvalue, aka a pointer. the pointer type that `packed_obj.packed_field` produces has alignment/bit offset metadata in it. depending on what the parameter type of printName() is, it may be a compile error or not
<andrewrk>
if printName took for example, a Foo type (not a pointer) then the pointer-with-metadata would be properly dereferenced with bit shifting or whatever was required, and the function call proceeds as expected
<mikdusan>
oh wow
<andrewrk>
if printName took a pointer type that lacked the metadata, it would be a compile error. you can observe this today with packed structs
<andrewrk>
if printName took a pointer type that had matching metadata, it would also work
<andrewrk>
note also if it took a `var` parameter it would also work fine
<andrewrk>
when I first started on zig, struct layout seemed opaque to me and my reasoning about it was really fuzzy
<andrewrk>
but now it's pretty clear in my head how everything is supposed to work
<andrewrk>
I'm on line 18,866 of 30,698 in this slog of a branch X_X
<andrewrk>
separating IrInstruction into pass1 and pass2
<Snektron>
ah, the infamous ir.cpp
<andrewrk>
for having a simple syntax, zig sure has a ton of ir instructions
<mikdusan>
lol
<Snektron>
and a lot of keywords
* Akuli
finds ir.cpp
<andrewrk>
is that actually true? I bet zig has an usually low number of keywords
<Akuli>
github web viewer doesn't even show that file :D
<mikdusan>
Akuli: yeah that sucks
<Akuli>
this is a long file
<Akuli>
:D
<andrewrk>
after my branch it would make sense to split ir.cpp into ir1.cpp and ir2.cpp
<Snektron>
andrewrk, more than c
<andrewrk>
ast->ir1->ir2->llvm
<mikdusan>
today most c has a lot of attributes, pragmas and things. Zig adds keywords to replace some of that spaghetti so don't count that as negative :P
<andrewrk>
also there is a proposal to move all the builtin types to become keywords. sounds counter intuitive, but because of @"syntax", keywords are actually easier to work around shadowing problems than builtins
<fengb>
Man, we'd have 128+ keywords starting with the letter 'u'
<Snektron>
That doesnt sound counterintuitive at all
<mikdusan>
heh
<Snektron>
it surprised me that i could do that before
<andrewrk>
I don't like that integer builtins are special
naltun has quit [Ping timeout: 260 seconds]
<Snektron>
Im not sure if writing @Int(0, 1 << 32) everywhere is the way to go though
<andrewrk>
that actually would look good if the if had proper indentation
<andrewrk>
maybe the builtin fn formatting isn't adding a new level of indent when calling renderExpression
<andrewrk>
basically there's a hidden `usingnamespace @import("primitives");` at the top of every zig source file. It would be nice to sometimes omit that
Akuli has quit [Quit: Leaving]
<andrewrk>
the Zig Way to do this would be to require that line explicitly in order to use primitive types. but that might be too extreme. people already hate blk:
<Snektron>
yeah i think that'd be too annoying
<Snektron>
but i have no problems with blk:
<Snektron>
plus `i(32)` looks a bit weird
<mq32>
andrewrk: i'd actually go for something like "std.int.i32" or "std.i32"
<mq32>
where std only exports some commenly used integers like {u,i}{8,16,32,64}
<andrewrk>
it would be std.primitives so that you could usingnamespace
<fengb>
My qualm with blk: is the colon switches places
<mq32>
fengb: +1
<andrewrk>
you don't like bash's if/fi case/esac? 🙃
<Snektron>
i think blk: vs :blk is nice to see source and destination
<fengb>
Well then it should be break :klb
<andrewrk>
I wouldn't mind swapping the colon over to the left for the block name, if it was overwhelmingly popular
<fengb>
How about change the keyword to goto :blk? 🙃
<mq32>
nah, no goto
<mikdusan>
was prefix colon added for clarity instead of `break blk 10;` or `break blk;` ?
<mq32>
i think there was the discussion of blkreturn or something
<andrewrk>
mikdusan, `break blk` is ambiguous whether it should return from a block named `blk` or whether it should look up an identifier named `blk` and return it from the innermost loop
<mq32>
mikdusan: actually a good idea: make block names just names/identifiers as everything else
<andrewrk>
also, if you have never learned zig, you can probably figure out how break :blk works without reading any docs. the colon helps that
<fengb>
Compromise: put colons on both sides
<mikdusan>
:P:
<andrewrk>
one of my guiding principles for syntax is: can someone who knows a programming language or two but not zig understand this clearly, without reading any zig language docs?
<andrewrk>
you know, like [*:null]const ?[*:0]const u8
<andrewrk>
j/k
<mq32>
/o\
<mikdusan>
andrewrk: ah ok so labels don't shadow/conflict with anything. I see.
<andrewrk>
it's nice to be able to look at only 1 line (`break foo;`) and without looking at anything else, know whether it's jumping to a label or not
<Snektron>
not so much about shadowing but rather about parsing ambiguity
<Snektron>
Though its strictly not ambiguous
<andrewrk>
for humans as well as the compiler
<Snektron>
One thing i thought about was that its possible to create a language without semicolons or other terminators
<fengb>
What about sneks
<mq32>
Snektron, that's actually quite possible, but it restricts your grammar a bit
<Snektron>
If you dont allow expressions without assignment, which zig does not, stuff like `a = b + 1 c = d + e` is perfectly unambiguous
<mq32>
Lua for example doesn't need terminators for 99% of instructions
<Snektron>
but lua allows such expressions
<Snektron>
for example you could write `a = 2 -b`
<Snektron>
could be interpreted in two ways
<mq32>
the code above is actually valid lua ;)
<mq32>
"-b" is not a valid lua statement
<fengb>
I'm not sure I like that
<Snektron>
afaik it is
<Snektron>
oh wait, you mean like that
<Snektron>
huh, i didnt know lua allowed that
<Snektron>
Nice
<Snektron>
but you can go even further
<andrewrk>
will consider removing semicolons at the very end before 1.0 if it makes sense then. I don't think it's important enough to design around it
<Snektron>
because `if a == b b = d` end is also unambiguous
<fengb>
Just because it's unambiguous for the computer doesn't make it a good construct for legibility
<andrewrk>
the main problem is that *invalid code* which is inherently ambiguous, is made less ambiguous with semicolons, making compile errors more helpful
<Snektron>
Im not advocating for it, but its possible
<mq32>
andrewrk: i would recommend not removing semicolons as they reduce readability for humans
<fengb>
Ah okay
<andrewrk>
you don't want typos to be valid code
<mq32>
it's much better to fast-scan for semicolons
<fengb>
Eh, Python and Ruby get by without semicolons
<fengb>
JS isn't that bad either once you get around the weird ASI
<metaleap>
i suspect the only reason go managed to ditch semicolons was to require curly braces on all blocks even 1-line "blocks"
<companion_cube>
python's syntax is kind of the worst, though
<metaleap>
s/only/main
<Snektron>
go uses line endings as statement terminatros
<fengb>
We should use 💩
<fengb>
How about: any emoji codepoint is a terminator
<fengb>
Personalize our code
<SyrupThinker>
Go to Perl6/Raku route? :)
<SyrupThinker>
*the
<fengb>
Are we moving towards using files as full structs?
<Snektron>
does that mean i can `struct{usingnamespace @import("std")}{};`
<mq32>
<fengb> Eh, Python and Ruby get by without semicolons
<mq32>
return a
<mq32>
+4
aperezdc has joined #zig
<mq32>
returns "a", then syntax-errors :D
<SyrupThinker>
Ruby returns 1 o:
return0e has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
return a\n + 4 is problematic for humans too
mahmudov has joined #zig
_Vi has quit [Ping timeout: 248 seconds]
<frmdstryr>
Would it be possible to access variables on the stack from a @frame?
<frmdstryr>
It seems like that would allow closures to work
<metaleap>
losing my mind here! what in the?! https://paste.pics/7U4NW (nvm all the superfluous `comptime`s, just wanted to see if that'd change the buggy outcome)
<metaleap>
aaaarg sometimes it takes a screenshot to see one's own stupidity
<metaleap>
getting too late... loop and i-=0
<metaleap>
(wouldnt happen with i-- ;)
<fengb>
I've done that before :P
<andrewrk>
this pass1/pass2 thing has revealed one likely hiding place of some result location bugs
<mikdusan>
andrewrk: for aligned fields; confirm: 1. do not have to be power-of-2 bytes. 2. if most-aligned-field > packed-struct's align (overalign), packed-struct alignment is increased... and extended to meet power-of-2 requirement?
<fengb>
Hmmm will this conflict with your result location cleanup branch?
<shakesoda>
i think the only language i know does just fine without semicolons is lua, and it has them anyways just in case
<shakesoda>
in practice the only time i have ever needed them is if i have a line which is, for some reason or other, wrapped completely in parenthesis
frmdstryr has quit [Quit: Konversation terminated!]
<andrewrk>
mikdusan, (1) alignment must be a power of 2 bytes, or 0, indicating sub-byte alignment. (2) all struct alignments (packed, extern, and normal) are defined to be equal to the most-aligned-field's alignment
<andrewrk>
(2) ...and extended to meet minimum of align(1)
<andrewrk>
fengb, nah, there is no fundamental conflict between these two branches
<andrewrk>
it will have easily fixable git conflicts
<andrewrk>
there's always the option to manually take the smaller branch, and apply diff to the larger branch by hand
<andrewrk>
sometimes it helps to know when to not use your tools
<mikdusan>
andrewrk: ah thanks. I somehow confused "non-power-of-2" for host-integer with alignment. much easier to grok align now
<andrewrk>
guess we know Vexu's opinion on #181 :)
<fengb>
Also no semicolons
<Snektron>
thats a controversial issue
<andrewrk>
damn, I thought this pass1/2 thing would be simply refactoring, but I actually have to fix this result location bug to solve compilation errors
<andrewrk>
I guess that's a good thing
metaleap has quit [Quit: Leaving]
<andrewrk>
but now I'm like 8 yaks deep
<Snektron>
I was hoping to write some function to make automatic conversion of vulkan variable names
<mikdusan>
what kind of names do they use?
<Snektron>
but it seems like i don't have enough information to handle some cases
<andrewrk>
btw Snektron there is this clause in the style guide:
<Snektron>
mikdusan, its mostly just camel case for types/functions/members and screaming snake for constants
<andrewrk>
" These are general rules of thumb; if it makes sense to do something different, do what makes sense. For example, if there is an established convention such as ENOENT, follow the established convention. "
<andrewrk>
if your goal was to follow the style guide, it would suggest to keep vulkan's names
<andrewrk>
I would even add that as an example: if translating vulkan API from an xml file, don't mangle the names
<Snektron>
Not in particular, but i have a preference to have most stuff in the same style, even if originally in another case
<Snektron>
But there are more motives outside of style preference, however i can probably get by with a simpler substituion
adamkowalski has joined #zig
<Snektron>
One of my motivations of writing this was to remove some clutter that appears when using the headers directly, for examply writing VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO when .InstanceCreateInfo would suffice
adamkowalski has quit [Remote host closed the connection]
<Snektron>
I think that reads nicer enough to justify the change of style
<Snektron>
One drawback is that its harder to write Vulkan code in Zig if you're following some non-zig documentation and have to map those names to zig names though
<andrewrk>
that's the idea behind keeping the names the same
<andrewrk>
I could see taking off the VK_ prefix and putting things in a vk namespace though