<stripedpajamas>
having a tricky time creating [][]u8 programmatically from a SplitIterator. i was trying to use ArrayList([]u8). is there a better way?
satchmo_ has joined #zig
dimenus has quit [Ping timeout: 265 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
marijnfs_ has joined #zig
stripedpajamas has quit [Quit: sleeping...]
marijnfs has quit [Ping timeout: 264 seconds]
spacehare has left #zig ["^D"]
aerona has joined #zig
<ifreund>
well you could do an ArrayList(ArrayList(u8))
<ifreund>
depends on your use case really
stripedpajamas has joined #zig
ifreund has quit [Ping timeout: 256 seconds]
fraktor has joined #zig
<fraktor>
Is there a way to do something like a comptime if? I basically want to ensure that a pair of constants add up to 16.
<andrewrk>
fraktor, comptime assert(x + y == 16);
<fraktor>
I'm getting an error that says "unexpected token" at the '('.
<andrewrk>
global scope? use a comptime block
<andrewrk>
comptime { ... }
<fraktor>
I did not realize. Thank you
<andrewrk>
no problem
<fraktor>
Also, is there a built-in way to turn a SegmentedList into an owned slice?
<fraktor>
If not I can just write a quick function out of an iterator.
<andrewrk>
that would require a copy since the elements are not contiguous in memory
<fraktor>
That's true. I'm okay with a copy in my case, but I understand why that's not advantageous to have in the API.
<andrewrk>
it would make sense to have an API function for copying a range
<andrewrk>
it would break it down into a small number of memcpy calls rather than iterating over each index with at()
[rg] has quit [Ping timeout: 264 seconds]
daex has joined #zig
daex has quit [Ping timeout: 260 seconds]
daex has joined #zig
wozeparrot has quit [Ping timeout: 272 seconds]
Guest15338 has quit [Ping timeout: 256 seconds]
[rg] has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
fraktor has quit [Ping timeout: 256 seconds]
layneson has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
[rg] has quit [Ping timeout: 256 seconds]
foobles has quit [Ping timeout: 245 seconds]
aerona has quit [Quit: Leaving]
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
_whitelogger has joined #zig
dddddd has quit [Ping timeout: 265 seconds]
stripedpajamas has quit [Quit: sleeping...]
ur5us has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
_Vi has joined #zig
bren077s has joined #zig
bren077s has quit [Client Quit]
dermetfan has joined #zig
slurpie has quit [Ping timeout: 256 seconds]
opDispatch has joined #zig
<opDispatch>
what's better for zig ? vim or emac ?
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
<wilsonk>
opDispatch: if you want auto completion then vscode is probably best with zls at this point. Otherwise vim vs emacs is probably pretty similar
nycex has quit [Read error: Connection reset by peer]
<opDispatch>
ok understood, so no auto completion in vim nor in emac.
nycex has joined #zig
opDispatch is now known as TypeNull
zenxhd has quit [Quit: Connection closed for inactivity]
TypeNull has left #zig ["Konversation terminated!"]
<daurnimator>
wilsonk: why not ZLS with some vim language server plugin?
neceve has joined #zig
dermetfan has quit [Quit: WeeChat 2.7.1]
<ifreund[m]>
ok kak-lsp
<ifreund[m]>
s/ok/or/
alexnask__ has joined #zig
alexnask__ is now known as alexnask
satchmo_ has joined #zig
doublex has quit [Remote host closed the connection]
doublex has joined #zig
ifreund has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
stripedpajamas has joined #zig
slowtype1 has joined #zig
slowtyper has quit [Ping timeout: 240 seconds]
<wilsonk>
daurnimator: I am just stating that vscode already has the 'plugin' so there is no extra setup required to get the auto completion. Maybe I should have been more specific about that. I think you could use emacs with the company-backends to get autocompletion working also, just not sure how much work that is
<wilsonk>
I am not a vscode fanboy (actually prefer emacs in evil mode) but I am using vscode because of the ease of setting things up
mattmurr has quit [Remote host closed the connection]
mattmurr has joined #zig
dddddd has joined #zig
slowtype1 has quit [Quit: WeeChat 2.8]
_whitelogger has joined #zig
[rg] has joined #zig
Guest15338 has joined #zig
Guest15338 is now known as dimenus
waleee-cl has joined #zig
dimenus|home has joined #zig
dimenus|home has quit [Client Quit]
r4pr0n has joined #zig
dimenus has quit [Quit: WeeChat 2.8]
dimenus has joined #zig
<fengb>
wilsonk: can you add Zanic to the store? I need another mug :)
<wilsonk>
fengb: you just want that exact pic on a mug? Or are there other items I should make with that design?
<fengb>
I just want a mug. Curious if anyone else cares >_>
<wilsonk>
Ok, I can leave an open invite here in case anybody else wants some other design. I don't have any Ziggy designs but was thinking of adding them so I can do that at the same time (I will probably do a full kit-out with Ziggy, I suppose, since I think I remember a request a while ago for that design on some shirts or something).
<alexnask>
Ziggy tshirt yould be cool yeah
<wilsonk>
fengb: do you need it right away? Or can we leave this open for a few hours...I will be going to sleep soon is why ;)
<wilsonk>
alexnask: ok, noted
<fengb>
Gottagofast
<alexnask>
Didnt realize you were the one running the store btw :-)
<fengb>
Of course it isn’t urgent :P
<wilsonk>
Lol
<alexnask>
Thanks for that
<wilsonk>
no problems
<fengb>
Might want to ping Discord too. Maybe get some buyers
<wilsonk>
Ok
<fengb>
Thanks!
<ifreund>
hmm, it'd be nice to update the shirts to the new logo as well
<wilsonk>
ifreund: sorry which new logo? Or do you mean Ziggy?
<wilsonk>
ifreund: I guess I could if it is really necessary, but it is such a small difference that I might have to delete the original store to update to that logo...otherwise one probably couldn't tell the difference on the storefront. Adding Ziggy merch in a different store should work fine and a Zanic item or two (or new storefront also) would work too, but the slight difference of the new logo might be an issue.
decentpenguin has joined #zig
<ifreund>
wilsonk: I'm sure you know better than i do what the practical way to handle things would be :D
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
[rg] has quit [Quit: Konversation terminated!]
[rg] has joined #zig
decentpenguin has quit [Quit: decentpenguin]
satchmo_ has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
[rg] has quit [Ping timeout: 256 seconds]
puzzleddev has joined #zig
satchmo_ has joined #zig
[rg] has joined #zig
puzzleddev has quit [Ping timeout: 246 seconds]
[rg] has quit [Ping timeout: 256 seconds]
[rg] has joined #zig
cren has joined #zig
<cren>
what's the rule for the letter case of builtin functions? @import is... that, and @TypeOf has UpperCamelCase. Shouldn't it be @Import?
hermier has quit [Quit: Leaving.]
<ifreund>
in general is it returns a type it should be TitleCase, which means you're technically right about @Import being correct
<cren>
looking at the docs, I can see that most of the builtins are lower camel case, but some seem to be upper camel for some reason
<cren>
oh, if it returns a type? that makes sense
<ifreund>
yeah that's the idea
<ifreund>
@import seems inconsisent now to me though
<cren>
it doesn't always return a type though. std is a struct, right? Not a type.
<alehander92>
i will try to learn a bit more zig with some example programs(main xp : nim/c/go lately)
<alehander92>
i am thinking of `grep` and all kinds of cli
<alehander92>
or generic stuff: i am very interested in writing dsl-s
<alehander92>
what would be a good example of dsl
leeward has joined #zig
<alehander92>
typical for zig? i guess something returning new types based on declarative code?
cole-h has joined #zig
stripedpajamas has joined #zig
stripedpajamas has quit [Client Quit]
<ifreund>
fengb: indeed, maybe it should be @Import...
hermier has joined #zig
<cren>
a `const` string of type `[]u8` is really a `const` pointer to the first item of a slice (and the length of the slice), right? So that makes the string mutable, right?
<alexnask>
[]u8 is mutable yes, []const u8 is immutable
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
satchmo_ has quit [Ping timeout: 260 seconds]
satchmo_ has joined #zig
<cren>
How do I read a file from the filesystem with Zig?
<alehander92>
do you usually loop around command line args with `for(std.os.argv)`
dddddd has quit [Ping timeout: 264 seconds]
Snetry has quit [Ping timeout: 260 seconds]
<ifreund>
i use std.process.args() and getNextPosix()
<ifreund>
*nextPosix()
Snetry has joined #zig
<alexnask>
std.os.argv is not set on windows iirc
<ifreund>
and nextPosix() doesn't work on windows but i don't really care :D
<alexnask>
T_T
<fengb>
I think `std.process.argsAlloc` only exists because of windows >_>
<alexnask>
andrewrk, Have you had an opportunity to look at #5151 yet by any chance? Just curious about your general thoughts on it, the concept looks really cool to me and I wonder if I should build upon it and add some more allocator types that could potentially make it to std some time
<andrewrk>
I haven't looked yet
<alexnask>
👍
wozeparrot has joined #zig
wozeparrot has quit [Remote host closed the connection]
wozeparrot has joined #zig
fraktor has joined #zig
belgin has joined #zig
Snetry has quit [Ping timeout: 264 seconds]
puzzleddev has joined #zig
<alehander92>
what do you guys use for strings?
<alehander92>
and lists: just `[]u8` and ArrayList ?
<ifreund>
depends on if the string will change size or not, if it will, then ArrayList(u8) otherwise a []const u8
<ifreund>
ArrayList should be your default resizeable container, though i also use a lot of linked lists in my project due to the need for pointer stability
slurpie has joined #zig
<betawaffle>
didn't the repo have a shell.nix (or something like that) in the past?
<alehander92>
ok
<betawaffle>
andrewrk: you still run on NixOS?
<alehander92>
so in this case function like `grep` which takes all kinds of strings would take ArrayList
<ifreund>
only if grep needs to resize the strings
<ifreund>
if not a slice is all that's needed
<alehander92>
but i get expected []u8 got [7]u8
<ifreund>
you need to take the adress of your array then
<ifreund>
grep(&my_array(
<ifreund>
(with the proper parentheses)
<andrewrk>
betawaffle, yes
mattmurr has quit [Max SendQ exceeded]
mattmurr has joined #zig
cren has quit [Ping timeout: 245 seconds]
layneson has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
salotz has joined #zig
<alehander92>
global_allocator
<alehander92>
leads to OutOfMemory to me
<alehander92>
after only 593 additions to a list
<alehander92>
of string slices
<alehander92>
should i tweak its size
<andrewrk>
global_allocator? that was removed a long time ago
<alehander92>
huh it's just a big array
<alehander92>
yeah i use 0.6 man
<alehander92>
from the downloads in the website
<alehander92>
huh its 0.5.0
<alehander92>
anyway, is there a good allocator to use for common CLI apps? i guess a global one based on a big array *might* be a good fit for many of the short lived once
<alehander92>
ones*
<alehander92>
but probably that's naive (always edge cases)
<andrewrk>
0.5.0 is unsupported
<alehander92>
sorry yeah, my question applies to 0.6
<leeward>
If you want easy and functional, C's allocator works well (though you have to link libc)
<fraktor>
alehander92: If it's an application that will have a short run time and is okay with not deallocating things in the middle of operation, wrapping std.heap.page_allocator in an ArenaAllocator should give decent performance. Otherwise the c allocator would be a good choice.
<fraktor>
andrewrk: Is the general-purpose allocator project still active? The latest commit is 6 months ago.
<alehander92>
thank you!
<alehander92>
my `grep` is now halfway there
<alehander92>
i can just leave it be a `tree` command
<alehander92>
but in zig 0.6 it seems just passing &"" doesnt work
<satchmo_>
I have a question about the Allocator interface (pre-#5064). Is it correct to say that reallocFn and shrinkFn are the only functions that require implementations, while the rest can be optionally overridden?
<andrewrk>
fraktor, it needs to be revived, but yeah I'm pretty sure it'll happen soon because the self hosted compiler (which is a big focus of this release cycle) needs it
doublex has quit [Ping timeout: 260 seconds]
<andrewrk>
alehander92, string literals are already pointers
<andrewrk>
satchmo_, yes reallocFn and shrinkFn are the only functions that require implementations. The rest will always be provided and cannot be overridden
<alehander92>
ok! so `[]const u8` !
<alehander92>
hm, this syntax seems a bit confusing tho because the error message uses `*const [7:0] u8`
<andrewrk>
you should check out the release notes :)
<alehander92>
yeah, sorry
<alehander92>
so in this case what i didnt get was the difference between `*const [stuff] typ` and `[]const typ` syntax : e.g. why slices dont just use `*const [] typ`
<alexnask>
5151 with some more composable allocator parts => 1 liner allocator definitions is my dream
<satchmo_>
andrewrk: does that mean the only differences between allocators is how they realloc/shrink? Sorry if this is obvious, I'm a bit new to allocators.
<alehander92>
it seemed inconsistent from outside, but probably there is an obvious reason
doublex has joined #zig
slurpie has quit [Ping timeout: 272 seconds]
<alexnask>
satchmo_, realloc and shrink also do the allocation and deallocation ;)
<andrewrk>
allocation is just reallocation with an old size of 0
<andrewrk>
freeing is reallocation with a new size of 0
<andrewrk>
the only reason there are 2 functions is that one of them is not allowed to fail
<fengb>
But we’re gonna split out resize in place right?
<andrewrk>
alexnask, I'm excited to check it out. I'll be sure to do that after landing the branch I'm trying to finish up
<satchmo_>
ahhhhhh, I see now. Thanks!
<andrewrk>
yeah something is going to change to the allocator interface
<alexnask>
Marler is literally allocator Jesus
<andrewrk>
lol
<alehander92>
i see its more similar to `array` type
<andrewrk>
alexnask, maybe some of that code will be useful in allocating .text segment blocks for self-hosted incremental compilation :)
<andrewrk>
it's the same problem, after all
<alexnask>
I feel like Ive overhyped this PR
<andrewrk>
if it doesn't cure cancer I'm going to reject it
<alexnask>
It just happened to fit my bias like a glove
<fengb>
But... #1717 cures cancer
<alehander92>
so why not just implementing `shrink` as a wrapper around reallocate
<alehander92>
and ignore any error inside (asserting it cant possibly error for its args)
<fengb>
realloc can fail. Shrink cannot
<satchmo_>
alehander92: I think andrew said one of them never fails
<ifreund>
we can have both 1717 and 5064 though, cancer cure and alexnask's glove
<alehander92>
yeah but usually the implementation can be shared
<alehander92>
and shrink can be just a call to realloc which expects no fail anyway
<fengb>
Although there’s a separate task to make free optional
<fengb>
I think the latest accepted proposal is: alloc / resizeInPlace / free
<fengb>
And the last two are optional. So it’ll streamline these implementations
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
<satchmo_>
despite being relatively new to Zig, even I was excited after reading that proposal lol
<satchmo_>
it just seems so nice
doublex has quit [Read error: Connection reset by peer]
<alexnask>
The talk linked is quite good too
doublex has joined #zig
<alexnask>
Although I think there is a better version in DConf or smth
doublex has quit [Read error: Connection reset by peer]
[rg] has joined #zig
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
_Vi has quit [Ping timeout: 244 seconds]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
<alehander92>
i reached unreachable code!!
<alehander92>
seems cool
<andrewrk>
check your front door, the police are outside
slurpie has joined #zig
<alehander92>
i got `EFAULT` from write
<andrewrk>
you passed a bad pointer to the kernel
<alehander92>
hm, i print stuff i got from `split`
doublex has quit [Read error: Connection reset by peer]
<alexnask>
as in std.debug.warn?
doublex has joined #zig
<alehander92>
eh, yes , it has a limit?
<alehander92>
i shouldn't just warn so much
<alehander92>
or i might get into a global warning discussion
<ifreund>
no, calling warn isn't the problem
<ifreund>
it's whatever you're passing to it (if that's really the line that's triggering this)
<alehander92>
yeah i just got it with stdout print too
WilhelmVonWeiner has joined #zig
<fraktor>
By the way andrewrk, should I make an issue and pull request for adding a way to copy portions of a segmented_list into contiguous memory? I've got some working code that's passing tests, but I'm not sure if the API is what we want.
<andrewrk>
feel free to put it up, let's take a look
<fraktor>
andrewrk: The only difference is that I didn't add an end, and just assumed you wanted to fill the slice. I can easily change that though, since I just say `const end = start + dest.len`.
<pixelherodev>
Is a tuple of tuples valid?
<alexnask>
I dont see why not
<pixelherodev>
Neither do I, the syntax just feels weird :P
Akuli has joined #zig
<pixelherodev>
I wish there was a way to have an import return an enum instead of a structure
<pixelherodev>
Single-file enums should be just as easy to use as single-file structures
<pixelherodev>
s/ingle-file/elf-contained/g
<fraktor>
I mean, can't you just do `const MyEnum = @import("myenum.zig").MyEnum;`?
<pixelherodev>
Yes, but you can do that for structures too
<pixelherodev>
My point is that it shouldn't be less convenient to do it for enums
<pixelherodev>
With a struct, it's just `const MyStruct = @import("mystruct.zig");`
<fengb>
export default enum 🙃
<pixelherodev>
?
<fengb>
Steal inspiration from JS
<fraktor>
I thought that const mod = @import("mod.zig"); would import the whole namespace, not just the struct.
<pixelherodev>
Existing structures become `X` -> return struct {X}`
<pixelherodev>
and so on
<ifreund>
hmm, imo if that's implemented it should replace the current thing
<pixelherodev>
That's the idea
<fengb>
How about @This() = fn () {
<ifreund>
i like that
<pixelherodev>
fengb: how's that better than tlrs?
<pixelherodev>
(top level returns)
[rg] has joined #zig
<fengb>
Because it’s not a return
<pixelherodev>
I'm not opposed, just curious
<pixelherodev>
So?
<fengb>
There’s no control flow
<ifreund>
it feels a little more explict
<pixelherodev>
Ahh
<pixelherodev>
Just to clarify then
<pixelherodev>
fengb: the idea was never to allow control flow
<ifreund>
it's more intuitive to me than a random return and implicit file-level function scope
<pixelherodev>
it wouldn't be e.g. return if() else
<pixelherodev>
but yes I do like that
<fengb>
Then I’m not sure why it’d be return
<pixelherodev>
You want to open the proposal, since it's your idea?
<pixelherodev>
fengb: because it's *returning* a value to the import
<fengb>
It’s more of an export default
<ifreund>
hmm, what happens to the other stuff in the file?
<ifreund>
also this kills my lovely toplevel fields
<ifreund>
rip indentation
<fengb>
Yuck back to ES6 crap
<fengb>
Well we can’t auto export if we want top level functions
<fengb>
Since functions aren’t namespaces
<fengb>
But what if they were? 🤔
bren077s has joined #zig
<ifreund>
that sounds really weird
<fengb>
Containers*
<fengb>
Nah it’s fine. Just like JavaScript
<fengb>
Actually it’s solve a few things for me, like tagging
<pixelherodev>
okay please stop the trolling :P
<pixelherodev>
I can't tell what's real and what's not anymore
<fengb>
I’m always trolling
<fengb>
That 1% of brilliance is pure luck
<fengb>
I’m a walking 1 million monkeys
<pixelherodev>
ugh
<pixelherodev>
Actually
<pixelherodev>
everything-as-a-namespace isn't necessarily a bad idea
xackus has joined #zig
<pixelherodev>
That allows static variables in functions, userspace union tags and ordinals (instead of in the language itself), and probably a few other neat tricks
<pixelherodev>
still doesn't solve the imports issue though
<fengb>
Are you agreeing with my trolling?
<pixelherodev>
Actually, yeah, it does
<pixelherodev>
fengb: that's the wrong question
<pixelherodev>
The right question is, how do you deal with a troll?
<fengb>
Fire and acid
<fengb>
Gotta melt them limbs
<pixelherodev>
lol
<pixelherodev>
Anywho
<pixelherodev>
jokes aside
<nephele>
pixelherodev, give them so much authority they cant troll anymore, obviously
<pixelherodev>
I do think there should be a way to import enums, functions, etc
<pixelherodev>
The problem is *hohw*
<pixelherodev>
s/hoh/ho
<torque>
@import('file.zig').myenum
<torque>
plus using the shift key as appropriate
<pixelherodev>
torque: yes, of course, that already works
<pixelherodev>
that misses the problem
<torque>
I don't even understand the problem you're trying to solve here but overloading "return" to mean "export" is a very bad idea
<pixelherodev>
I'm not saying return is a good syntax
<pixelherodev>
raw structs can be imported directly
layneson has quit [Ping timeout: 260 seconds]
<pixelherodev>
`@import("Type.zig")` can be used instead of `@import("type.zig").Type`
<pixelherodev>
but *only* for structures
<pixelherodev>
I think that it makes sense that enums should be importable in the same way
<torque>
I'd argue that that's a coincidence of structs being used for namespaces
<pixelherodev>
Sure, but it does also have advantages of its own
<pixelherodev>
With this, the root of the file could be the generic type
<pixelherodev>
`@import("array_list.zig")(T)`
<pixelherodev>
instead of `@import("array_list.zig").ArrayList(T)`
<pixelherodev>
Which is a tad simpler
<torque>
it's a lot uglier and less clear imo
<torque>
either way it seems like you're mainly interested in subverting namespaces
<pixelherodev>
Namespaces would be unaffected
<pixelherodev>
I'm not trying to make it so namespaces can't be imported, but so that imports aren't definitionally namespaces
<torque>
no, I mean from a usage standpoint
<pixelherodev>
How so?
<torque>
what you actually want is to be able to ignore namespaces on import
<pixelherodev>
Well, sort of
<torque>
to avoid doing a single unwrap
<pixelherodev>
The idea is that when there's only a single value in the namespace the namespace shouldn't exist
<torque>
I think I generally disagree with that
<alexnask>
I find this feature nice with structs as it removes 1 level of indentation from a whole file
<pixelherodev>
^ yes, exactly
<alexnask>
But its not the biggest of deals either way
<pixelherodev>
^ that too
[rg] has quit [Quit: Konversation terminated!]
<pixelherodev>
BUt hyeah, it doesn't matter all that much
<torque>
I don't like file-as-instantiable-object for reasons I can't really describe, but I think it's because it smells too much like java
<pixelherodev>
To me, I care more about it on its own merits than how it compares to other langs
<pixelherodev>
If it's bad, it's bad; if it's good, it's good
<pixelherodev>
The fact that Java/Node/whoever may have done it doesn't make it bad
<pixelherodev>
That's like... programmer's godwin's law
<torque>
it's not bad because of the comparison
<pixelherodev>
"Any discussion on programming language development will inevitably draw a comparison to Node.JS"
<pixelherodev>
torque: that's why I want to have the discussion on the underlying merits, or lack thereof
<torque>
it's bad because generally speaking it's ugly and not easily extensible to couple your software datastructures and affiliated data to a rigit filesystem heirarchy
<pixelherodev>
Sure, but you could make that argument about structures too
<torque>
the allusion to java being moreso that there has been a lot of discussion of the (lack of) merit of one-class-per-file in that domain that I can't articulate
<pixelherodev>
By that logic, we should make it so that the root of a namespace shouldn't be allowed to have fields
<pixelherodev>
Plus, we have one-class-per-file already
<pixelherodev>
This wouldn't change that at all
<pixelherodev>
All it would do is give the same treatment to enums and generics
<pixelherodev>
This doesn't affect "classes" (structs)
<pixelherodev>
Just the opposite
<torque>
I am drawing a semantic difference between struct-as-namespace and struct-as-data even though from an implementation standpoint they are identical
<pixelherodev>
Right, but from real usage there's no difference
<pixelherodev>
There are many examples already in usage of namespaces-as-structures
<pixelherodev>
struct-as-namespace+data, if you prefer
<pixelherodev>
Again, this won't change that in any way
<pixelherodev>
It won't encourage or discourage it
slice has joined #zig
<pixelherodev>
From the sound of it, you want to argue the opposite of what I'm saying
<pixelherodev>
I'm saying enums, functions, etc should be able to be file roots
<pixelherodev>
You're saying structs *shouldn't*
<companion_cube>
what's the usage of having a file being exactly one function/one enum?
<torque>
no, I think that structs being the root of a file is a simplicity tradeoff that works in favor of the language even if it has side effects I don't agree with
<fengb>
One function can be nice for generics like ArrayList.zig
<pixelherodev>
torque: except that again, you can get both of those at once if you wnt
<pixelherodev>
want*
<torque>
how so
<pixelherodev>
You could argue that structures-as-namespaces and structures-as-data should be distinct in the lang
<alexnask>
torque, Im curious, would you rather we reverted into a different Namespace type returned by @import (with different TypeInfo etc).
<pixelherodev>
And that namespace structures shouldn't be allowed to have fields or member functions
<companion_cube>
fengb: oh. good point.
<fengb>
Very occasionally :P
<pixelherodev>
Yeah, exactly; what alexnask is saying
<alexnask>
I dont see what the difference is except for using fields at top level and the file-as-struct pattern
<pixelherodev>
Structures are currently namespaces *and* data
<pixelherodev>
YOu could argue it should be one or the other
<pixelherodev>
Unrelated: ZLS bug report: `@import("file.zig").` should work directly
<torque>
I'm not arguing that zig needs to reintroduce distinct structs from namespaces
<pixelherodev>
wait, I should just open an issue
<alexnask>
hm that feels like it should work :P
<alexnask>
I mean, currently
<pixelherodev>
exactly
<pixelherodev>
It's so weird
<pixelherodev>
`const a = @import; a.` works
<pixelherodev>
but `@import.` doesn't
<alexnask>
aaah
<alexnask>
Yes its the same bug as func calls not getting field access completions
<torque>
however, from a philosophical design perspective, I also am not in favor of introducing more behavior that blurs that line
<pixelherodev>
torque: what you're basically saying is that you dislike it when it comes to structures but think it's worth it, but that same logic doesn't apply to other types?
<pixelherodev>
I can understand that
<torque>
I'm primarily saying that I personally would always treat a file as a namespace and declare structs/constants/enums/unions within it, as I think it's a cleaner separation of concerns
<pixelherodev>
That does raise an interesting point though
<torque>
and to a large degree eliminates the "seam" that you want to eliminate, just in the opposite fashion
<pixelherodev>
` * Only one obvious way to do things.`
<alexnask>
I agree it can be abused I just like it for system-level structs that use some children types etc
<pixelherodev>
torque: yeah, that's what I was getting at earlier, though I probably phrased it poorly
<pixelherodev>
I think that you have a point, actually
dddddd has joined #zig
<pixelherodev>
There's only supposed to be one obvious way to do things
<pixelherodev>
As is though, there's two here
<fengb>
I like the organization of toplevel structs but dislike how the definitions look
<pixelherodev>
I like the organization because it makes life easier, but I think that I actually have to agree with torque here
<fengb>
In almost every project, I've been doing `const Foo = @import("foo.zig").Foo`
<fengb>
And I much rather just hoist it to the top
<pixelherodev>
I prefer it at the top when writing, but I'm honestly not sure how I'd want to proceed here
<pixelherodev>
I really like top level structs, and I don't think they're any harder to read than explicitly defining them within the namespace as a separate type
<pixelherodev>
But I'd rather give that up in exchange for consistency
<pixelherodev>
some people *will* continue doing them as subtypes, and there's no way to [justify trying to] remove the ability to do that
<pixelherodev>
Whereas disallowing fields and member functions in top-level structs does make some sense...
<pixelherodev>
Gah
<pixelherodev>
I'm just going to get back to work
<pixelherodev>
Status quo is probably fine, there are two ways to do things but both are similar enough that it doesn't really matter
<pixelherodev>
Nobody's going to be confused by one more than the otehr
<fengb>
Prior to toplevel structs, I had silly things like `const op = @import("op.zig"); var thing = op.Op.init();`
<fengb>
And getting rid of the wrapping namespace was just better
<stripedpajamas>
if I'm getting "error.OutOfMemory;" while running some unit tests, is that an indication that I've written shitty code? or is there a memory limit when running tests? if the former, what should I be looking for?
<pixelherodev>
Is there a better way to add to an enum than @intToEnum(@enumToInt + offset) ?
metaleap has joined #zig
<alexnask>
stripedpajamas, What allocator are you using?
<stripedpajamas>
testing.allocator
<alexnask>
testing allocator uses a 2 mb buffer
<stripedpajamas>
hmm i see
<andrewrk>
I believe it's planned for testing.allocator to use GeneralPurposeDebugAllocator after it lands in std
<andrewrk>
which would not have the 2 MiB buffer limit
<stripedpajamas>
does that mean allocations whose sum that exceed 2mb in `zig test` will cause OutOfMemory?
<stripedpajamas>
just making sure i'm understanding
<andrewrk>
that is currently the case, if you use std.testing.allocator
<andrewrk>
the workaround is pretty straightforward, use a different allocator if you need more mem than that
wozeparrot_ has joined #zig
<fengb>
Yeah it was picked to run the stdlib tests at that point. Super scientific™
<andrewrk>
maybe put a "todo" in there to switch it back once GeneralPurposeDebugAllocator lands in std
<fengb>
I thought I have a todo somewhere
<fengb>
Might not be in the right place
<stripedpajamas>
got it, thanks so much
slurpie has joined #zig
wozeparrot has quit [Ping timeout: 264 seconds]
fraktor has quit [Ping timeout: 264 seconds]
<pixelherodev>
I documented the register enum in Lightzing, where I adjust the IDs by adding 16 (64-bit -> 32-bit form), and figured I'd port that back to stage2 :)
<pixelherodev>
andrewrk: if I add utility functions to the Register enum (e.g. isNative), should I add those to Zig even if they're not immediately needed?
<pixelherodev>
s/Zig/stage2
<andrewrk>
I think they should be added only if they are used
<pixelherodev>
That makes sense
<pixelherodev>
Anything I can do to help with x64 backend?
<andrewrk>
pixelherodev, how about implementing function parameters and return values?
<pixelherodev>
Sure :)
<pixelherodev>
Just did a version of that for lightzing, so the details are mostly fresh in my mind
<andrewrk>
that will unlock the ability to implement math
<andrewrk>
and other binary operations
<pixelherodev>
Consider it done :)
<andrewrk>
then you can probably put your use case for isNative :)
<andrewrk>
regarding function parameters and return values, my suggestion is to make all the other calling conventions besides "auto" a compile error for now
<andrewrk>
the nice thing about "auto" calling convention is that we don't have to match any particular ABI
<pixelherodev>
What should auto use?
<pixelherodev>
I was thinking of just implementing callconv(.C)
<pixelherodev>
and using that for now
<andrewrk>
that would be fine too
<pixelherodev>
Proposal: enum_literal keyword, similar to comptime_int
<pixelherodev>
This would avoid needing to use @TypeOf(.Lit)
<pixelherodev>
s/keyword/comptime type
<alexnask>
std.meta.EnumLiteral ?
<andrewrk>
that's a good proposal, mind typing it up? (might have been already proposed, I don't remember)
<andrewrk>
it makes sense to be consistent though, why would we have one and not the other
<ifreund>
yeah, i'd be a fan of a keyword
<andrewrk>
you can also define comptime_int as @Type(.ComptimeInt)
<alexnask>
Hmm good point
<andrewrk>
maybe the actual answer is to also remove comptime_int :)
cole-h has quit [Quit: Goodbye]
<ifreund>
hmm, i should probably finish up the std.log PR, got the scope thing working as I want with enum literals just need to decide between the current minimalism or the syslog protocol
<alexnask>
Vector is the odd man out
<fengb>
std.meta.comptime_int
<fengb>
ComptimeInt
<pixelherodev>
Hm
<pixelherodev>
I almost always prefer userspace over language
<ifreund>
i'm kinda leaning toward the syslog levels daurnimator linked since it seems like it would scale better, and Zig is intended to be useable for truely massive code bases
<pixelherodev>
But this is one case where I feel that doesn't make sense
<pixelherodev>
@TypeOf(.E) works, sure
<pixelherodev>
And defining it in stdlib is an option
<alexnask>
@Type(.EnumLiteral) is cleaner but yes :-)
<pixelherodev>
but I feel like this, definitionally, is *part* of the language
<pixelherodev>
The reality is, this is part of Zig
<pixelherodev>
It's not an extension or a userspace addon
<pixelherodev>
It's a core part of the language
<ifreund>
a keyword would make it more clear that that is the case yeah
<fengb>
So are vectors but they're userland now
<alexnask>
Vector takes 2 args which makes it difficult
<andrewrk>
@Vector isn't userland
<pixelherodev>
^
<pixelherodev>
Vector is defined by a builtin
<fengb>
std.meta.Vector
<pixelherodev>
Comptime integers are enum literals aren't
<pixelherodev>
Those are fundamentally language constructs
<fengb>
@Type(.{ .Vector = stuff })
<pixelherodev>
Not builtins, not user types
<pixelherodev>
They're *part of the language*
<pixelherodev>
We *could* probably devise a way to implement e.g. u8 in userland
<pixelherodev>
But it makes no sense
<andrewrk>
oh right, I forgot we took steps recently to phase out @Vector in favor of @Type(.{.Vector = ...})
<fengb>
They are. std.meta.Int
<pixelherodev>
Every zig compiler should be *forced* to expose these to be compatible
<fengb>
>_>
<pixelherodev>
fengb: yes, but as a wrapper
<pixelherodev>
Not std.meta.u8
<pixelherodev>
`uN` is part of the language, rather
<fengb>
Hmm, should we deprecate uXX now?
<alexnask>
vector->(4, usize) when?
<alexnask>
(jk)
<pixelherodev>
This isn't a "meta" part of the language, not really
<andrewrk>
alexnask, I'm definitely open to vector type syntax
<tdeo>
should u8 and comptime_int be defined in an implicit prelude rather than keywords?
<pixelherodev>
It's fundamental
<pixelherodev>
I'm arguing the opposite
<pixelherodev>
I really really don't like that idea
<pixelherodev>
If nothing else, it'll push people away from Zig
<pixelherodev>
Nobody's going to want to have to define every single integer types
<andrewrk>
look at my gotta-go-fast zig code handling the error correctly first try: https://clbin.com/Ci651
<andrewrk>
it's printing this once every 60 seconds
<pixelherodev>
companion_cube: syntax
<companion_cube>
yeah
<pixelherodev>
you already said that :P
<companion_cube>
that's so sad
<alexnask>
malloc()?
<pixelherodev>
Syntax matters
<companion_cube>
also, I guess, proprietary compilers
<pixelherodev>
andrewrk: that's neat, but also
<pixelherodev>
Shouldn't be a concern :(
<andrewrk>
*shrug* this is why I like git. it's decentralized, everybody can keep working no problem
<fengb>
But, how will I get free downtime
<pmwhite>
Isn't that the case with a centralized VCS, too? I mean, you obviously can't check anything in while offline, but you still have the code, right?
<afontain_>
you can't play with branches
<companion_cube>
but you can't even commit
<companion_cube>
or, with svn, get the log
<fengb>
Oh boy, I remember when I created my own adhoc local VCS
<pmwhite>
Yeah, I guess that's not ideal. It's not too catastrophic though if something is just offline for a few hours or something.
<fengb>
Just because the central server was down
<pmwhite>
alias git=cp
<pixelherodev>
oof that's evil
<pixelherodev>
`alias cd='rm -rf'`
<ifreund>
that's liable to get you punched or something
<pixelherodev>
It's a security measure :P
<pixelherodev>
If you log in but don't unalias it, it fails
<pixelherodev>
wipes data
<pixelherodev>
Better yet
<pixelherodev>
set up more complex aliases to zero out each file before removing them
<pmwhite>
what if your filesystem is copy-on-write? copying the whole tree is not so bad in that case, right.
bren077s has quit [Quit: -a- Connection Timed Out]
cole-h has joined #zig
cole-h has quit [Client Quit]
bren077s has joined #zig
<alehander92>
range types
<alehander92>
sound good !
xackus has quit [Ping timeout: 256 seconds]
<alehander92>
and not only because of optimizations: but because of correctness
kllr_sbstn has joined #zig
cole-h has joined #zig
cole-h has quit [Client Quit]
layneson has joined #zig
r4pr0n has quit [Remote host closed the connection]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
metaleap has quit [Quit: Leaving]
slice has quit [Quit: zzz]
cole-h has joined #zig
stripedpajamas has quit [Quit: sleeping...]
<ifreund>
anyone else bothered by the fact that zig fmt doesn't put a space between `error` and the following curly but does for struct/union/enum?
<pmwhite>
No, I think I agree with that choice.
cole-h has quit [Ping timeout: 260 seconds]
<alexnask>
It only does this for single item sets I think
Akuli has quit [Quit: Leaving]
bren077s has quit [Quit: -a- Connection Timed Out]
<ifreund>
note that if you change fooey to return Error!Barrr it doesn't compile
<ifreund>
so I'm pretty sure something weird is going on but not quite sure what
Kingsquee has joined #zig
<pixelherodev>
Finally
<pixelherodev>
Ported my stage2 registers definition over to lightzing (and thus Thor)
<pixelherodev>
Had to fix a bunch
<pixelherodev>
`187 insertions(+), 221 deletions(-)` Much cleaner though
<pixelherodev>
:)
<ifreund>
i love diffs that remove code while maintianing all the functionality
<alexnask>
^
dimenus has quit [Quit: WeeChat 2.8]
<pixelherodev>
ifreund: even better actually
<pixelherodev>
It removes code and *adds* functionality
<ifreund>
awe yeah
<pixelherodev>
And I'm willing to bet it's more efficient too
<pixelherodev>
Going to measure shortly
cole-h has joined #zig
cole-h_ has joined #zig
cole-h has quit [Quit: Goodbye]
cole-h_ has quit [Client Quit]
cole-h has joined #zig
stripedpajamas has joined #zig
[rg] has quit [Quit: Konversation terminated!]
<pixelherodev>
More than 14% faster in release-safe mode :)
satchmo_ has joined #zig
<ifreund>
solid
<fengb>
Wow
<pixelherodev>
I'm not too surprised
<pixelherodev>
It changed a structure into an enum
<pixelherodev>
Since the values are comptime-known, it was probably able to optimize and inline a lot more
keegans has quit [Ping timeout: 272 seconds]
fraktor has joined #zig
<fraktor>
andrewrk: I don't know if you saw but I have a pull request up.
satchmo_ has quit [Ping timeout: 272 seconds]
Guest40059 has quit [Quit: WeeChat 2.8]
<pixelherodev>
It also made, now that I think about it, e.g. reg.id(), where reg is comptime known, into a constant
<pixelherodev>
No unwrapping, no safety checks needed (since it's no longer possible for it to be optional)
<pixelherodev>
About 12% faster in release-fast, which stacks up with what I expected
<pixelherodev>
(than it was before, not compared to release-safe)
<pixelherodev>
ifreund: maybe double check that issue you just opened?
<pixelherodev>
The "if you change X to Y", X and Y are identical AFAICT
satchmo_ has joined #zig
<pixelherodev>
might be a typo in one of them
satchmo has joined #zig
<alexnask>
Havent looked through the issue but the godbolt example was broken for sure
slice has quit [Quit: zzz]
cole-h has quit [Quit: Goodbye]
<pixelherodev>
Oh, and just for context about how slow emulation is:
<pixelherodev>
`Instructions executed to print Hello World normally`: 595
<pixelherodev>
`Instructions executed with Thor`: ~40k
<pixelherodev>
The real curious number is how Thor compares to just using the JIT directly...
satchmo_ has quit [Ping timeout: 260 seconds]
cole-h has joined #zig
<gonz_>
Which platforms support evented IO more or less completely atm?
<gonz_>
`io_mode = .evented`, that is.
<pixelherodev>
None, as I understand it
slice has joined #zig
<pixelherodev>
All of them have varying degrees of support
<pixelherodev>
But nothing is fully integrated with it yet
<gonz_>
Ah, ok.
<pixelherodev>
Hmm, I could probably speed up that example by ignoring errors, but that's not a valid comparison anyways
<pixelherodev>
Since that would be improper usage of the library
cole-h has quit [Quit: Goodbye]
xentec has quit [Quit: memento mori]
slice has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
xentec has joined #zig
puzzleddev has quit [Read error: Connection reset by peer]
ur5us has joined #zig
slice has joined #zig
<fraktor>
I'm attempting to build Zig on Linux and running into #4799, but adding the proposed fix gives me: c++: error: unrecognized command line option ‘-W1,/usr/lib/llvm-10/lib/LLVMPolly.so’
dingenskirchen has quit [Remote host closed the connection]