tgschultz has quit [Read error: Connection reset by peer]
tgschultz has joined #zig
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 246 seconds]
ltriant has quit [Quit: leaving]
mahmudov has joined #zig
<mq32>
<andrewrk> I don't think that beginner questions are noise, I think they are very on topic
<mq32>
+1, even if some beginners get on your nerves
<mq32>
ky0ko: i have some windows ce 6.0 devices at my hands, so: people still manufactor devices with windows embedded
<mq32>
as i just recognized, one could understand my second-previous message wrong: welcome beginners even if the get on your nerves
mahmudov has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
mahmudov has quit [Ping timeout: 250 seconds]
jokoon has joined #zig
traviss has quit [Quit: Leaving]
<Snektron>
andrewrk: You'd think if you eliminate all basic assignments in the example of the first issue, it'd be fixed automatically
<Snektron>
I think my compiler for some compiler construction class did that
<Snektron>
Although that was on register-level
LargeEpsilon has joined #zig
jzck has quit [Quit: 30 day idle timeout.]
LargeEpsilon has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 264 seconds]
keithdc has joined #zig
marijnfs__ has quit [Quit: WeeChat 2.6]
jokoon has quit [Quit: jokoon]
jokoon has joined #zig
jokoon has quit [Remote host closed the connection]
jokoon has joined #zig
LargeEpsilon has joined #zig
kllr_sbstn has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 268 seconds]
muffindrake has quit [Quit: muffindrake]
muffindrake has joined #zig
jokoon has quit [Quit: jokoon]
rappet has quit [Quit: -]
rappet has joined #zig
waleee-cl has joined #zig
jokoon has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
jokoon has quit [Read error: Connection reset by peer]
jokoon has joined #zig
Akuli has joined #zig
keithdc has quit [Disconnected by services]
keithdc has joined #zig
<ky0ko>
mq32, yes, i work with those devices - i'm an embedded systems software engineer by trade. the company i work for helps others port their old software to newer operating systems, whether that's newer versions of wince, windows proper, linux, or something else
<mq32>
oh, another embedded coder :)
* mq32
only does embedded for hobby, but i work at an embedded systems manufacturer
<ky0ko>
yeah, i started out that way, and then the small embedded systems manufacturer i was working for learned that i knew linux and c, and moved me from being a field technician to being an embedded linux engineer, which worked out great
<ky0ko>
until they lost a big client for reasons i'd warned them about years in advance, and had to lay people off
<mq32>
oh damn
<mq32>
i'm quite happy with my position here. i'm doing inhouse-tech
<ky0ko>
i eventually settled down in a better position across the country though so it's all good
<ky0ko>
also i just want to say, to andrewrk and everyone else working on the language, i have really been appreciating zig the more of it i learn and write. i've had much less trouble with it than some other languages like rust and go, and it often really just 'makes sense' to me how it does things
<ky0ko>
i've been porting a fairly old, bitrotted, >100,000 sloc project from c to zig as a learning project, and having a pretty enjoyable time of it
<andrewrk>
happy to hear that
wootehfoot has joined #zig
marijnfs has joined #zig
THFKA4 has quit [Ping timeout: 276 seconds]
marler8997 has quit [Read error: Connection reset by peer]
<andrewrk>
I've been spending the last hour trying to launch a scaleway arm vps instance. they advertise ARM servers but only show x86 servers in the list
lunamn has quit [Ping timeout: 265 seconds]
<andrewrk>
also tried an AWS EC2 server and that didn't boot up
FireFox317 has joined #zig
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
mahmudov has joined #zig
<andrewrk>
ah, scaleway requires phone number verification and customer support request before allowing arm hardware access
lunamn has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
qazo has joined #zig
FireFox317 has quit [Ping timeout: 268 seconds]
<ky0ko>
so, i've hit a compiler error trying to port some c code to zig, trying to put together a data structure that other c code in the project works with, and i'm trying to find a workaround
<andrewrk>
ky0ko, ah, you've hit a compiler bug. that one looks like it might be easy to solve, if you wouldn't mind filing a bug I think it could be taken care of relatively quickly
<andrewrk>
as for your code, I think it will be fixed with 1 modification: change the type to [*]?[*]const u8
<andrewrk>
because your inner type can be null, you need the ?
<ky0ko>
ah yes of course, thanks. that compiler error still occurs, i'll file the bug report!
<andrewrk>
ky0ko, oh, your outer type should be an array too. [_]?[*]const u8
<ky0ko>
when i do that, i get "error: expected type '[*c][*c]const u8', found '[11]?[*]const u8'"
<andrewrk>
that's good, you just need to take the address then
<ky0ko>
oh hey it built
<andrewrk>
one of the general rules of the type system is that zig won't make a reference without your consent
<andrewrk>
which is probably an argument for making |x| capture values go back to copying unless |*x| is specified
<andrewrk>
your bug is still valid. some parts of the compiler incorrectly assert() instead of making a compile error
<andrewrk>
ah this is yet another regression from result location semantics
<ky0ko>
submitted as #3524
<kllr_sbstn>
Hey Andrew, will there be a stream today?
<andrewrk>
ky0ko, fixed. thanks
<andrewrk>
kllr_sbstn, yeah I'll do one later in the evening
<kllr_sbstn>
andrewrk, nice! looking forward to it
waleee-cl has quit [Quit: Connection closed for inactivity]
Ichorio has joined #zig
Akuli has quit [Quit: Leaving]
<Snektron>
So i've been thinking
<Snektron>
I need to make an xml parser for something, and it turns out to be quite nasty since im a perfectionist
<Snektron>
But i wonder if it can work with async functiojs
<Snektron>
At least the lexing part
<andrewrk>
I don't think async functions is the right solution to text processing. you're thinking of generators
<andrewrk>
which are being considered
<Snektron>
Aren't those functionally pretty equivalent though?
<Snektron>
The only difference is you write your result to a buffer before you suspend
<Snektron>
I'm trying to think of a way to do it without too many allocations, and the best way even would be to act directly upon a stream
<Snektron>
my current idea was having a Lexer struct with a ?State member, then a member function next() !?u32
<Snektron>
https://wank.party/UVgW.zig basically something like this. It can work with a lookahead buffer but the way im implementing it turns out to not be very reader-friendly
<Snektron>
(after .next() returns null, lexer.state would contain the new state)
<andrewrk>
it would make more sense to me to have it be while (try lexer.next()) |token| {}
<andrewrk>
where token is a tagged union
<Snektron>
Yes, but then you need to allocate the space for the token somewhere
<Snektron>
std.json takes a similar approach i believe, though its a bit different there
<andrewrk>
I suggest to accept a buffer on init, and return error.TokenTooBig if it doesn't fit
<andrewrk>
and document that the strings become invalid after every call to next()
<andrewrk>
this will be very reasonable API for most use cases: they will support a maximum <tag> size and return an error if one is too long
<Snektron>
hmm
<Snektron>
maybe another option is to supply a function in the next function to which the token data is written
<Snektron>
The idea would be that you can pass different functions depending on the token, but then you'd need to know the token beforehand, which is the same as my initial idea
<Snektron>
Probably better to just accept an allocator instead of a buffer
<Snektron>
that way the allocated space for a token can grow dynamically, or be allocated statically in the case of a fixed buffer
<andrewrk>
a low level parser would allow streaming the long content, and have a fixed upper bound for small content
<andrewrk>
small content being tag names and attribute names. long content being data between tags. attr values would probably be "long content"
<Snektron>
but thats pretty much the same as the snippet
<Snektron>
except instead of a single char it would return a buffer
knebulae has quit [Read error: Connection reset by peer]
<Snektron>
and handle long content EAGAIN style i suppose
keithdc has quit [Quit: leaving]
<andrewrk>
tgschultz, I have an idea which partially addresses the annoyances of error sets and streams
<andrewrk>
the idea is that the buffering output stream also buffer errors. so writing to this stream cannot fail directly. but flush() can fail. and then make it always be anyerror. one is expected to do an @errSetCast with flush.
traviss has joined #zig
<andrewrk>
this makes buffered output stream not generic
<andrewrk>
it also models how people want to use output streams. write a bunch of stuff, check for error later. this is what C FILE* does
<Snektron>
At what point can writing to a buffer fail?
<Snektron>
except when its out of bounds of course
<andrewrk>
not a fixed buffer - buffered. there is an underlying output stream which could have any error set
<andrewrk>
buffered just means that you can write 1 byte, 4 bytes, 3 bytes, 10 bytes, 100 bytes, and then flush all 118 bytes with a single write()
<Snektron>
Yes, but that can only happen on a flush
<andrewrk>
if you fill the buffer, then it flushes to empty the buffer and make room for more data
<Snektron>
So the actual error can only happen on a flush, but i suppose you need to be able to flush in write() so you still need to make that return an error
<andrewrk>
yes, but I'm also suggesting that this error itself would be buffered, e.g. since zig errors are values, just save the first error that occurs, and then return that on flush()
<andrewrk>
on the public flush function
jjido has joined #zig
<Snektron>
What would that help to deal with error set annoyances?
<Snektron>
Wont that imply that the user has to call flush manually?
<andrewrk>
because it would not be generic
<andrewrk>
calling flush manually is already a requirement of std.io.BufferedOutStream
<Snektron>
Oh
<jjido>
ah, I missed the start - what wouldn't be generic you are talking about?
<andrewrk>
scroll up to "I have an idea..."
<andrewrk>
so if this turns out being nice, then most APIs which want to accept output streams would accept a *std.io.BufferedOutStream, and that would not require making your API generic
<jjido>
I like the idea of "error on flush" but yeah, calling flush manually... Let me check the API
<Snektron>
The generic streams are annoying yes
knebulae has joined #zig
keithdc has joined #zig
<jjido>
Where can I find the source for std.io.BufferedOutStream?
<emekankurumeh[m]>
i just had the weirdest error, i was hitting a compiler assertion when trying usingnamespace a file with just comments
<emekankurumeh[m]>
then i cut and pasted the comments and i can't reproduce the error anymore
<andrewrk>
jjido, use a tool to search the std lib directory for BufferedOutStream
<jjido>
ah I was looking inside the io directory. Thanks
wootehfoot has quit [Quit: Leaving]
<jjido>
manual flush is only required if the buffer is not full. If you write more than a buffer's fill there is automatic flush which can throw an error
<jjido>
so are you going to defer that error until there is a manual flush?
<jjido>
maybe you should refrain from flushing the stream automatically when the written bytes fill the buffer exactly in that case - someone may be tempted to use a buffer exactly the right size and bypass manual flushing, thus losing error information
<daurnimator>
Snektron: xml parsers... just use libexpat. making your own is a 2 year excersise in pain. I know from experience
<emekankurumeh[m]>
just rewrite in zig: jwiz
<daurnimator>
andrewrk: you didn't have to rent on scaleway; as we've done before, I can spin up servers for us. Let me see if I can give you permissions on the account somehow...
<andrewrk>
daurnimator, oh, forgot about that. can I have a 32 bit one for a couple hours?
<andrewrk>
also, wtf, clang just gave me error: the clang compiler does not support '-march=native' on aarch64
reductum has joined #zig
<andrewrk>
you know what this means... time to implement -march=native in zig and pass the specific target flags to clang
<ky0ko>
-march, -mtune, and -mcpu all have different semantics on different architectures in gcc (they're specified by the backend), and clang tries to emulate that
<daurnimator>
andrewrk: looks like I can't give you permissions to create servers. will ping organisers to see if I can gain that permission to delegate to you
<ky0ko>
you're certain to see the same problem on mips and powerpc, which iirc both expect -mcpu and don't have a "native" equivalent
<daurnimator>
andrewrk: the CPU we get is an Ampere EMAG. I think it's capable of both 32bit and 64bit modes.
<daurnimator>
andrewrk: let me know if you want me to boot one for you (and what OS; centos 7 and ubuntu 16.04 are quick to boot. others take like 20 mins)
<andrewrk>
we can implement CPU detection logic in zig itself, and call that code from stage1
<daurnimator>
andrewrk: also tell me which ssh key... you have 5 active on your github
<daurnimator>
andrewrk: I still have a PR open refactoring the elf/dwarf code; you once commented you had issues with the code. but I had no problems. could you try again?