ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<Braedon>
The problem is with hash_map, it wants a []u8 comparison function
<Braedon>
And it really should want a []const u8 comparison function
<Braedon>
Wrote issue about it, because otherwise you can't pass in string literals, since you can't 'downcast' (I agree with never letting anyone downcast from const to non-const)
<Braedon>
Though I still think hash_map should be changed perhaps?
<Braedon>
Since not labelling it as const makes it seem like the comparison function can edit the values
<andrewrk>
Braedon, feel free to make a pull request
<Braedon>
Swell :)
steveno_ has quit [Remote host closed the connection]
relatingdata has joined #zig
<relatingdata>
Hi, anybody using fedora rawhide (F29) to compile zig / zen?
<relatingdata>
getting error messages from Symbol Table file(s) needing copy constructors
<andrewrk>
relatingdata, good news. I have just got 100% static linux builds of zig working, and they are automatically built for every push to master branch
<andrewrk>
wait 10 min for this travis build to complete and I'll send you a link
<MajorLag>
sweet
<andrewrk>
MajorLag, I have a good solution. I figured out how to upload HTTP redirects to s3
<andrewrk>
so we will have an url like zig-linux-x86_64-master.tar.xz and it will redirect to the latest successful build
<MajorLag>
that sounds a lot easier than what I'd read about pushing to github release
zolk3ri has quit [Quit: leaving]
<andrewrk>
ugh. s3cmd version on travis is old enough to not have the cli args I expected
hobomatic has quit [Quit: WeeChat 2.1]
<andrewrk>
now to wait 15 more minutes to see if this fixes it
<relatingdata>
sounds good, soon we will have zen self hosting :-) how much remains to be done on the self hosting compiler?
<andrewrk>
lots. we have a partially complete parser, and we have linking against LLVM/clang working on all platforms
<andrewrk>
and that's about it
<andrewrk>
I'm planning on finishing up my proof-of-concept of multiplexing coroutines onto a kernel thread pool first, because I'm planning on making the self hosted parser multi-threaded
<andrewrk>
and also work out some major language changes
Braedon has quit [Ping timeout: 260 seconds]
hobomatic has joined #zig
Braedon has joined #zig
<relatingdata>
some years ago I was quiet impressed with https://bellard.org/tcc/tccboot.html and the associated tiny C compiler have you had a look? its just a little bit dated
<andrewrk>
neat
<Braedon>
Ahh okay you can't have generic types then 'add const' like `fn(a: const K, b: const K)`
<andrewrk>
Braedon, this is why I think the problem is #733
<Braedon>
Yeh, I agree
<Braedon>
Though the question is raised about generics and whether or not you should be able to add type modifiers to them since you can add '[]' to a type
<Braedon>
But you can't add 'const' for example
<andrewrk>
you can add []const to a type
<Braedon>
Yes
<Braedon>
I would say that seems weird?
<andrewrk>
what are you trying to do?
<hobomatic>
does 'const T' even make sense for an argument type currently? if its a byval argument, its effectively const anyhow from the outside.
<Braedon>
Well for example in the hash map stating that the comparer should be const
<andrewrk>
right. const only makes sense in terms of pointers
<Braedon>
Yes in some cases
<Braedon>
For example you could pass in type '&MyStruct'
<Braedon>
It makes sense that the comparison flags it as 'const'
<Braedon>
But for other non-ptr types you wouldn't care if it was const or non const
<andrewrk>
if you specify &MyStruct as the type of the hash, it's harmless to have the comparator take mutable args
<andrewrk>
you're allowed to pass a fn(&const T) where a fn(&T) is expected
<Braedon>
Yes but it requires you to have possibly two comparison types
<Braedon>
For example with strings
<Braedon>
You aren't
<Braedon>
I'll double check, I felt you couldn't
<andrewrk>
oh my god it finally worked
<hobomatic>
static?
<andrewrk>
yes
<hobomatic>
woo
<MajorLag>
"shell script is the worst language ever"
<Braedon>
You can't pass in fn([]const T) where fn([] T) is expected
* MajorLag
nods
<Braedon>
The error is: error: expected type 'fn([]u8, []u8) bool', found 'fn([]const u8, []const u8) bool'
<Braedon>
Unless that rule only applies to pointers and not arrays?
<andrewrk>
Braedon, that's a bug in the compiler, I'll fix it
<Braedon>
Ahhh okay haha, I'm happy to give it a look if you want :0
<andrewrk>
ok. fresh master build for linux ETA 27 minutes away
<aiwakura>
hey relatingdata, let me know if you run into issues compiling zen
<aiwakura>
I have a branch of zig called zen_stdlib because I frequently change the ABI
<aiwakura>
it's still a moving target - but if people are interested I'll try to make things more reproducible / have some kind of continuous integration going on
<aiwakura>
there's a loadProcesses branch where I take some dirty shortcuts to load user programs from the shell, but I'm working on making that work properly on the master branch right now
<aiwakura>
self-hosting zen is definitely a long-term goal. the next milestone in that direction is to cross-compile some non-trivial C/C++ program. we'll need to be able to cross-compile LLVM to get the zig compiler running inside zen
<aiwakura>
which means we need a reasonably POSIX-compliant C library. we'll write in zig of course :)
<MajorLag>
ok, this is weird. I'm crashing when calling DirectAllocator.alloc() on windows. It is happening at the system call itself. If I throw a debug.warn line near it, it becomes an error.OutOfMemory instead.
<andrewrk>
MajorLag, hmm. it's crashing at HeapAlloc?
<MajorLag>
HeapCreate, yeah.
<MajorLag>
...I'm fairly certain I've done allocation on windows before, but it's even failing in a simple test right now. I think I might be doing something stupid, but I don't know what.
<MajorLag>
andrewrk,ok, yeah, that seems to be it. Not sure what I've suddenly done differently to run into it though.
<relatingdata>
back in an hour and a half
<andrewrk>
MajorLag, I'm hoping we can come up with some way to catch this with runtime safety, or otherwise do this pattern in a safer way
<MajorLag>
yeah, I ran into a similar issue when using an ArrayList of structs. ArrayList.at() returns a copy.
<MajorLag>
which is what the code says, but not what I was expecting.
<andrewrk>
that's fair
<andrewrk>
perhaps after pointer reform that should return a pointer to 1 object
<MajorLag>
or getting a pointer would be a separate fn, ArrayList.ptrAt() or something. In my case I could have got away with something like ArrayList.overwrite() too, but due to the way I was using it pop()+append() worked fine.
<MajorLag>
Ah, I see. In most of my other code that I was doing a lot of allocations with I was doing linux stuff, where there is no heap_handle to screw up with a copy.
<andrewrk>
MajorLag, oh that's interesting. if there's no state in the struct then a copy is actually ok
<andrewrk>
this is a pretty sinister footgun
<MajorLag>
yeah, but the whole point of the pattern is to keep state.
<andrewrk>
right
<MajorLag>
I suppose you could do something like is done with context in format
<andrewrk>
that would require making all these interface things generic
<MajorLag>
yeah I did that test on my static build too. Then I spent some time wondering what the difference between "statically linked" and "not a dynamic executable" was.
<andrewrk>
I was just wondering that
<MajorLag>
I wasn't finding good ifnormation and didn't feel like digging through the gcc source tree. from what I could gather, it means it has, but doesn't use, a dynamic section.
<andrewrk>
oh, that makes sense, I think
<andrewrk>
hmm, I'm still confused. if I pass --static to zig build-exe, it still says "not a dynamic executable" instead of "statically linked"
<andrewrk>
the linker line is: lld --gc-sections -m elf_x86_64 -static -o hello ./zig-cache/hello.o ./zig-cache/builtin.o ./zig-cache/compiler_rt.o
<andrewrk>
maybe it has to do with binutils ld vs LLVM's LLD
<MajorLag>
I dunno. I suppose we could find out by disecting the elf if we really want to know.
<andrewrk>
I'll find out the answer to that mystery after we release 1.0.0 ;)
<Braedon>
Line 20 won't compile because the types don't match
<MajorLag>
It occurs to me that if we had privat struct fields this interface problem goes away. DirectAllocator.allocator would be private and you'd get a &mem.Allocator from DirectAllocator.allocator() instead.
<Braedon>
But line 18 is happy to pass in that const function
<Braedon>
Private struct fields would be good in lots of other ways, maybe a way to hide them?
<MajorLag>
Usually I'm not a fan of private anything, but in this case as a footgun prevention measure it makes sense. I can always use @ptrToInt() + @offsetOf() + @intToPtr() to get around private if I really need to.
<Braedon>
Or maybe just make it a compile time 'info' thing, like not a warning just some side information to be careful
<Braedon>
Or like '@overrideHidden(X.y)'
<MajorLag>
I feel like Zig's philosophy is that warnings should be errors and it's better to force you to be explicit. So something like @justGiveMeTheFieldAlready() would probably be preferable.
<Braedon>
Yeh I would prefer the builtin function way
<MajorLag>
but that could always just be implemented by the programmer as a comptime fn using @ptrToInt() + @offsetOf() + @intToPtr()
<MajorLag>
of course that can be said of a few builtins, like @fieldParentPtr.
<Braedon>
It could but if it is going to be done by most programmers why not make it standard
<Braedon>
Yeh
<hobomatic>
couldn't just a gross naming convetion work to make it obvious you are doing something bad, like ____allocator____
<Braedon>
Nah because its not so much your doing something bad
<Braedon>
but something you gotta be careful with
<MajorLag>
....yeah, I can get behind that.
<Braedon>
Gotta be careful too with '__' and C
<MajorLag>
well taking the value of something with a bunch of underscores around it should give you pause
<Braedon>
True
<Braedon>
But then is that a syntax rule or just a programmer standard
<hobomatic>
it could be a language style convention, documented in the style guide
<Braedon>
Yeh
<hobomatic>
i am just thinking in terms of 'what introduces the least amount of complexity'. Personally i like the idea of private struct fields, but i think i like fewer weird corner cases from interaction between features
<hobomatic>
... more
<MajorLag>
yeah, I like your suggestion. It's so simple.
<Braedon>
As to not produce potential conflicts with C
<Braedon>
Since their stuff is 2
<Braedon>
Haha holy hand grenade of allocators
<hobomatic>
or maybe, since zig's source encoding is utf8, we could add '😵' or '💣' to the character set for symbools you would have to do some serious hand gymnastics to even type the fields name
hobomatic has quit [Quit: emojis destroyed my terminal state]
<GitHub100>
zig/master f5b43ad Andrew Kelley: std/os: getting dir entries works on OS X
hobomatic has quit [Quit: WeeChat 1.4]
cenomla has quit [Quit: cenomla]
pixeljoelson has joined #zig
pixeljoelson has quit [Client Quit]
pixeljoelson has joined #zig
pixeljoelson has quit [Quit: Leaving]
pixeljoelson has joined #zig
tiehuis has joined #zig
<tiehuis>
heakins: i haven't done anything with DES, AES so feel free to have a go at them
cenomla has joined #zig
cenomla has quit [Quit: cenomla]
pixeljoelson has quit [Read error: Connection reset by peer]
<Braedon>
Just finished my JSON compiler yay
<Braedon>
Don't particularly like the JSON spec but its used enough that I felt it was probably worth it
<relatingdata>
in Zig?
<Braedon>
Yeh
<Braedon>
Most of the time was spent figuring out a few compiler bugs and working around them
<Braedon>
It produces a 'tree' that you can traverse, it only deserialises currently, I'll work on serialization when I get another burst of time
<Braedon>
Just uploading to github then I'll send the link :)
<relatingdata>
:-) Thanks
<Braedon>
The one annoying thing about Zig right now is how it handles string literals
<Braedon>
For example I can't index my string hashmap with a string literal since it isn't marked as const and can't be because you can't add const flag to types
<Braedon>
So I'm hyped for the changes that andrew is doing to how you can pass things in
<relatingdata>
what is the equivalent of const (char *) const for an immutable array of immutable strings?
<man213>
Hello, guys. I'm learning zig build system, and, using provided examples, composed the following script: https://pastebin.com/9TgiUMF4 When I enter the command "zig build" in windows console cmd.exe, I receive the following message: http://joxi.ru/KAxoJPWUM7XD42 Am I doing something stupid or windows build pipeline is broken somehow? Thanks.
hoppetosse has joined #zig
hopppetosse has joined #zig
hoppetosse has quit [Ping timeout: 260 seconds]
Hejsil has quit [Quit: Page closed]
<andrewrk>
MajorLag, that's a really great point about private fields
<andrewrk>
man213, damn, if we had windows stack traces it would tell exactly what happened
<andrewrk>
your code looks fine to me. I'll try this on my windows laptop later tonight
<andrewrk>
another option is to debug it with msvc
<man213>
andrewrk: Thank you, Andrew! I'll try to dig it further. At least we can debug already compiled executable with visual studio. And this is really awesome!
man213 has quit [Ping timeout: 260 seconds]
<andrewrk>
MajorLag, private field isn't a perfect solution. Because you get a pointer to the struct field, but then it's not obvious that you have to keep the struct alive for the same lifetime
<GitHub113>
zig/master 8938429 Marc Tiehuis: Add Hmac function (#890)
Hejsil has joined #zig
hobomatic has joined #zig
hinst_ has joined #zig
hinst_ has quit [Quit: hinst_]
hinst has joined #zig
<MajorLag>
@andrewrk, but isn't that the case now? DirectAllocator.init() returns a DiretAllocator struct that you later have to deinit().
<MajorLag>
I honestly think Hejsil's idea about just naming the field differently to make it obvious it is internal and using an allocator() fn is better than a private filed, but I'm biased against private fields.
<Hejsil>
I don't think that was my idea :)
<Hejsil>
But on that note, I think explicit copy is the way to solve this
<Hejsil>
Maybe
<Hejsil>
Actually no, people will just do the copy
<MajorLag>
Explicit copy isn't a bad idea, as `a = b` is sort of a hidden memcpy if b is a struct. However, there are many cases where structs are just small containers of data (like a Vec2) where that's fine and explicit copy would be annoying. I almost think there should be another type, like `Object` or something that is a struct with more protected characteristics.
<andrewrk>
even with a private (or weirdly named) field, this footgun still exists
Ichorio has joined #zig
<andrewrk>
maybe if we had really good detection of returning stack data from functions
heakins_ has joined #zig
<MajorLag>
Hmmm... yeah, it won't always be as obvious as in the DirectAllocator case.
<heakins_>
In andrewk’s recent talk at RC he said that the Zig version of SHA256 is faster than the C/asm implementations because the use of comptime/inline allowed LLVM use the rorx instruction. My understanding from the Zig docs is that comptime/inline don’t make the compiler do optimization any differently, it’s just that compilation will error if it’s not possible to evaluate at compile time. So is the i
<heakins_>
mproved performance really due to comptime/inline?
<Hejsil>
Sometimes backends (llvm) can't unroll loop completely (source: some llvm optimization talk on youtube), and when that happends it can't take advantage of the extra knowlagde gained from this. Zig's comptime forces evaluation (unrolling in this case)
<Hejsil>
I haven't looked at the asm of SHA256 btw
heakins_ has joined #zig
heakins_ has quit [Client Quit]
heakins_ has joined #zig
heakins_ has quit [Client Quit]
heakins_ has joined #zig
heakins_ has quit [Client Quit]
<andrewrk>
heakins, in theory, if the optimizer is perfect, it wouldn't matter if you use comptime/inline. in practice, the optimizer is heuristics based and so sometimes misses things
<andrewrk>
if you use inline to unroll a loop, it does generate different code
<andrewrk>
there will not be a loop in the generated LLVM IR in this case
<andrewrk>
Hejsil, I'll have an accepted proposal to solve #760 by the end of today
<andrewrk>
I want to unblock you on the parser
<Hejsil>
Well, I'm not blocked
<Hejsil>
I've started rewriting the expression parsing, anyways, because I think my current precedence code is not very good
<andrewrk>
that's what I would do too. I would just make it the state machine equivalent of the current recursive descent parser
<Hejsil>
Ye, that's what I planned
<Hejsil>
The only "hack" I have to do to make that work, is to use DestPtr as a return, between expr states
<andrewrk>
I wonder if DestPtr is overcomplicated now that we use an arena allocator for the parser
<andrewrk>
it used to be a solution for using a normal allocator where we had to carefully free correctly on error return
<andrewrk>
but this arena allocator makes it waaaay simpler
<Hejsil>
Well, we still wonna avoid ""leaks"" as that will take up memory during the execution of the rest of the compiler
<andrewrk>
right - but when the parser returns an error, we just free the entire arena
<Hejsil>
Indeed
<andrewrk>
oh, you're referring to if we waste memory on a successful return
<Hejsil>
Yes
<andrewrk>
e.g. if we prepare some memory, and then don't end up using it
<andrewrk>
got it
<Hejsil>
But for expr, I have to go AssignExpr -> UnwrapExpression -> ... -> AssignExpr, if (token == assign_token) alloc assign op; else do nothing
<andrewrk>
I agree that's a thing. But I wouldn't worry about it *too* much. this kind of wasted memory happens regardless because of alignment guarantees
<Hejsil>
Well, expressions are common, and in this case I think I would allocate to many "dead" expressions if I did it the easy way
<andrewrk>
good point
<Hejsil>
Aka, to parse '+' i would alloc an "assignment", "unwrap", ... down to the state that parses '+'
<andrewrk>
I think the recursive descent parser avoids that
<Hejsil>
Yes
<Hejsil>
It can return values, so it's trivial for it to check the next token and return expr if the token does match
<Hejsil>
DestPtr have to have an allocated node to store the expr in
<Hejsil>
doesn't*
<andrewrk>
I think there is a way to represent that logic in the state machine
<Hejsil>
I've been thinking about it, but the solution I came up with would require alot of states
<andrewrk>
it would be 1 for each of the expression types in the grammar reference, right? e.g. BinaryOrExpression and friends
<Hejsil>
Yes
<andrewrk>
I think that is reasonable
<Hejsil>
Hmmm
<Hejsil>
Ok. Option 1. Return states for all expressions
<andrewrk>
that maps to how it works in the recursive descent - every expression has to go through these states, except they end up on *the* stack instead of a heap allocated stack
<Hejsil>
Option 2: Use the DestPtr we get from the statment that wants an expr as tmp storage
<andrewrk>
oh, is option 2 what you were describing above?
<Hejsil>
Ye, was trying to lol
<andrewrk>
that sounds neat
<Hejsil>
We only ever need to store one expression
<andrewrk>
right
<Hejsil>
The one returned by prev state
<andrewrk>
sorry - my attention is split while I'm at work
<Hejsil>
Np
<Hejsil>
I'll just do my DestPtr solution. Then you can see it and decide if it's any good
<Hejsil>
Introducing the extra returns states is trivial
<andrewrk>
sounds good
<Hejsil>
Hmmm, I might need the extra states anyways
<Hejsil>
Lol
ofelas has quit [Quit: shutdown -h now]
ofelas has joined #zig
hopppetosse has quit [Ping timeout: 276 seconds]
zigzag__ has joined #zig
pixeljoelson has joined #zig
zigzag__ has quit [Ping timeout: 260 seconds]
<Hejsil>
andrewrk, why does async use "<" ">" instead of "(" ")" for the allocator?
<andrewrk>
syntax ambiguity
<Hejsil>
Hmmm, thought so. I just don't see it myself
<MajorLag>
thinking about this issue with allocators & interface pattern: at least in the allocator case one solution would be to allocate whatever you need to keep track of, like the HeapHandle, and the handle in the struct is just a pointer to that so copies don't actually keep any state. Of course that does nothing for other non-allocator interfaces, however I would like to point out, andrewrk, that your example does have
<MajorLag>
without a "deinit()" that should be a clue. Still, feels like there is a better solution.