<very-mediocre>
the source will be released on the 22nd
<very-mediocre>
just wanted to give you a heads up since this language had come up before in discussions
<very-mediocre>
there's this unrigorous air about it that's bugging me, everything seems really simple I feel like there must be gremlins under the surface somewhere
curtisf has quit [Ping timeout: 256 seconds]
<torque>
lol the compiler checks online for updates before compiling https://github.com/vlang/v/issues/284 this seems like a very good sign of things to come
<very-mediocre>
yow.
ltriant has quit [Quit: leaving]
_whitelogger has joined #zig
marmotini_ has joined #zig
<andrewrk>
I said my piece on HN. as tempting as it is, let's try to keep it zig-focused & productive in #zig
<andrewrk>
(if there are any actually good ideas V has they are of course on topic)
<mmx87>
andrewrk, this seems a bit much? Is this intended?
<andrewrk>
mmx87, I'm aware of the uninitialized value jump in llvm's dwarf code although I haven't submitted a patch to them yet
<andrewrk>
if you're referring to the "leaks" don't forget that the OS frees all the memory when you exit()
<andrewrk>
stage1 compiler will never bother freeing memory. the self-hosted compiler is a long-running process and so will manage memory without leaks
<mmx87>
>don't forget that the OS frees all the memory when you exit()
<mmx87>
Yeah, I know. I was just curious.
daex has quit [Ping timeout: 268 seconds]
daex has joined #zig
<andrewrk>
fair enough :)
fsateler has quit [Ping timeout: 258 seconds]
fsateler has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
<ki9a>
bootstrapping is tricky :)
<ki9a>
andrewrk: are you happy with llvm?
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 248 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
return0e has quit [Ping timeout: 245 seconds]
return0e has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
<samtebbs>
FireFox317: Option 2 is the best option IMO since option 1 seems like a temporary workaround
<FireFox317>
samtebbs: With option 2 you mean the separation of the object files inside the library? I think I'm gonna wait on andrewrk's response anyway
<samtebbs>
FireFox317: Yeah you should wait, it's probably the best option though :)
st4ll1 has joined #zig
<samtebbs>
Is it ok to ping a PR/issue when it's been a week or more since the last feedback? I don't want to bother andrew too much since he has a lot to give his time to.
marijnfs has joined #zig
<marijnfs>
zig in sublime text is nice
<marijnfs>
can i define anonymous functions?
<BitPuffin>
marijnfs: you can define anonymous structs and put functions in them
very-mediocre has joined #zig
uso_ has joined #zig
kristoff_it has quit [Remote host closed the connection]
st4ll1 has quit [Ping timeout: 246 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
<curtisf>
Oh, that actually works, I must have messed something else up
curtisf has quit [Ping timeout: 256 seconds]
halosghost has joined #zig
fengb has joined #zig
Akuli has joined #zig
marmotini_ has joined #zig
st4ll1 has joined #zig
mikdusan1 has joined #zig
mattisme has quit [*.net *.split]
mikdusan has quit [*.net *.split]
THFKA4 has quit [*.net *.split]
return0e has quit [Ping timeout: 245 seconds]
<samtebbs>
Does anyone have any interest in working on a zig equivalent of creduce? I think forking creduce and adapting it to Zig would be viable but I'm not sure how to do so in the best way.
<scientes>
samtebbs, everyone here has more to do they have time for
<samtebbs>
It could be useful for reducing reproducable code when submitting a bug report
<samtebbs>
etc.
<scientes>
it would need to use the stage2 parser
<scientes>
so it can keep step with language changes
<samtebbs>
scientes: Does bugpoint support arbitrary languages? If that is the case then adapting that could be better
<scientes>
i don't know, but probably not
<scientes>
i think it is llvm only
<scientes>
but it would be useful at the same time, so a unified interface would be nice
<scientes>
llvm-ir
return0e has joined #zig
<andrewrk>
ki9a, llvm provides a huge part of the compiler. it allows us to have many targets, inline assembly, and debug info on posix & windows. the downsides are it is a huge, cumbersome dependency, and it's the bottleneck in compilation speed of debug mode builds
<daurnimator>
There are only so many mature code optimizing backends. Creating one is rarely done without a huge multiyear academic project
<scientes>
not to mention maintinance
<daurnimator>
not to mention new architectures
<scientes>
llvm should be improoved
<scientes>
that benifits everyone
<daurnimator>
LuaJIT is probably the only one I've seen that was created by one person; and where new architectures came calling
<daurnimator>
scientes: agreed. I think it would be a waste to duplicate that effort right now. we have better things to work on
<scientes>
or ever, other languages want improvements too
<fengb>
I think LLVM has some poor C++ idiosyncrasies, but I imagine having more frontends will help guide its efforts
<scientes>
only sensible thing would be to add a gcc backend
<scientes>
but that would require a lot of work in llvm, like getting llvm's assembly syntax identical to clang (which emulate's gccs)
<AlexMax>
I've been really wanting an excuse to translate my C hobby project to Zig, because C's various idiosyncrasies are really starting to bug me, and I always feel a little uneasy about the code I write in it, not ever being completely sure that I'm handling error code paths properly.
<andrewrk>
scientes, if zig becomes popular enough, I think people will enjoy creating alternate compilers
<andrewrk>
the simplicity makes it more approachable than e.g. making a rust compiler
<AlexMax>
However, I recall discussions around the rustification of bzip2, and one of the legitimate beefs I saw floating around was portability, precisely because LLVM just doesn't quite have the reach of GCC and doesn't have the history of most platforms of the past having a C compiler.
<scientes>
I can see people writing a differn't zig interpreter for comptime
<andrewrk>
I agree that is legitimate beef. But I think there are enough incentives set up for people that it is likely for LLVM to gain more backends
<AlexMax>
I always thought that Nim's strategy of simply compiling to C code was quite a clever workaround, but I imagine that's a gigantic can of worms to open.
<fengb>
Completely asinine idea: compile to wasm then convert to C
<andrewrk>
AlexMax, zig is actually trying to compete with C, that's the main problem with that strategy
<andrewrk>
I mean, replace C
<scientes>
no new general purpose architecture that doesn't have a llvm AND gcc port can be successful
<scientes>
embedded is different
<scientes>
compiling to C is quite painful
<AlexMax>
Yeah, and I feel like if the goal is long-term replacement, LLVM is the correct play for the primary compiler. But compiling to C might be useful for just getting your foot in the door in a closed ecosystem that knows some propietary C compiler and nothing else.
<andrewrk>
fair point
<halosghost>
I don't agree
<scientes>
nah
<halosghost>
compiling-to-c means you bite a ton of C's baggage
<scientes>
those platforms are not worth the effort
<scientes>
and hsail is here
<halosghost>
I quite like C, but compiling to it means you get a ton of issues that you'd almost certainly rather not have
<halosghost>
(it's one of the reasons I only looked at nim incidentally; many of the choices they made in their C codegen were major turn-offs for me)
<andrewrk>
I think LLVM should have a C target. I believe it used to have one
<AlexMax>
Yeah, I noticed that Nim had to pass a bunch of -f flags to the C compiler presumably to make it behave in expected ways.
<scientes>
and some of those propriatary compilers are c89-only too
<daurnimator>
target web assembly and then use a web assembly VM written in C ;)
<halosghost>
AlexMax: and, to be fair, that's how you have to interact with C if you want consistent behavior everywhere; but that's part of the problem
<AlexMax>
And even though Nim outputs C, how often do you suppose that proprietary and outdated compilers are actually exercised.
<fengb>
andrewrk: how comprehensive should translate-c bitfield be? I saw an issue about packed attributes, but would it okay to ignore for first pass?
<andrewrk>
part of the philosophy of what zig is doing is unraveling a few layers of abstraction which have become old and leaky, and then rebuilding them in a modern way
<halosghost>
AlexMax: proprietary compilers? all the time
<halosghost>
perhaps not with nim
<daurnimator>
zig targeting C *is* a good idea though I think. `zig translate-c` exists, why not the other way?
<andrewrk>
daurnimator, sure and I want it to be implemented in LLVM
<halosghost>
but msvc (which isn't really a C compiler even though folk think of it as one) and icc are quite common in the production world
<daurnimator>
andrewrk: I actually think it would be better to use that as a demo usecase of "zig is not tied to LLVM"
<andrewrk>
fengb, that's what translate-c does now, it demotes structs with bitfields to opaque types
<daurnimator>
andrewrk: have zig be able to output: LLVM IR, GCC trees, C.
<fengb>
I mean, I want to implement actual bitfields
<AlexMax>
halosghost: Sorry, I should have clarified. I was thinking more along the lines of those weird compilers you see with embedded chips.
<halosghost>
AlexMax: ahh
<daurnimator>
AlexMax: another interesting use case is targetting MISRA C. It's the only way into parts of the car and aerospace industries
<andrewrk>
fengb, ah. incremental improvements are great as long as they don't have false negatives. does that make sense? e.g. don't attempt a translation of a type that would be unsound
<halosghost>
daurnimator: that's much more compelling of an idea imo
<fengb>
That makes sense. I'm just not familiar with all the __attributes__ that can happen, but I can dig into it
<halosghost>
daurnimator: having said that; I cannot, for the life of me, find a freely-available MISRA compilance-checker or a MISRA-only compiler
<halosghost>
daurnimator: or even, for that matter, the MISRA spec
<halosghost>
daurnimator: do you have links I could use? I've been wanting to get a copy of any of those three things for quite a while
<andrewrk>
I am warming up to the idea of having alternate backends besides llvm. but not for a while into the future. I do want to make an attempt for one of these ultra fast debug build compilers that go straight to machine code
<daurnimator>
halosghost: I once had one back in university (10+ years ago....) can't remember what is was called.
<halosghost>
daurnimator: I would be equally happy with a CERT compliance checker
<halosghost>
but I can't find that either without paying a phenomenal amount
<fengb>
andrewrk: regarding `zig fmt a && b`, I have a quick port to the stage2 tokenizer, but there's not a good way to generate a useful error atm
<AlexMax>
To be clear, I'm looking at the problem strictly from a retrocomputing angle. My hobby project is a libretro core, and RetroArch runs on tons of odd platforms whose toolchains probably haven't been updated in a decade or more. I might be in that 1% of situations where if I want to remain potentially portable to those platforms, I don't really have a choice but to stay with C. I'm part of that 1%, and I
<AlexMax>
totally understand if targeting that 1% is probably not worthwhile use of time.
<fengb>
I think the tokenizer needs a way to generate errors with messages similar to how the C++ code does it. Thoughts?
<AlexMax>
But embedded applications might be another story, and are probably a lot more common than me.
<andrewrk>
fengb, I made the design decision that the tokenizer won't emit errors. but it can emit an "Invalid" token
<andrewrk>
so the parser will have to notice the invalid token and display an appropriate message
<fengb>
It's currently doing "error: expected Semicolon, found Invalid"
<fengb>
Oh... push the logic into the parser then?
<andrewrk>
you can also just add a token for a double ampersand, and then not do anything with it in the parser
<fengb>
Alternatively, would it make sense to tokenize as '&&'
<andrewrk>
yeah
<fengb>
Ah okay, wasn't sure if that would be considered hacky
<andrewrk>
and then there should be a way to make the parse errors nicer, perhaps in general, or perhaps with some special case code for &&
<fengb>
Thanks
<AlexMax>
If you're writing code for an RTOS for some tiny chip with a proprietary compiler, how would Zig get its foot in the door? That's an open question, not rhetorical.
<andrewrk>
fengb, eh, if it doesn't harm perf, and the logic is straightforward enough, I'm not sure it's even possible to put hacks in tokenizers & parsers
<andrewrk>
the logic is what you want it to be, if it's a flow chart with && then so be it
<andrewrk>
and it's so easy to test
<andrewrk>
I'm not really worried about code quality there
<andrewrk>
AlexMax, my best answer would be: a fork of LLVM adding a backend for the chip, and a fork of zig adding the arch
<andrewrk>
proprietary compiler means they aren't sharing their work; the work must be duplicated - those forks are the least amount of work to get there
<andrewrk>
zig's MIT license would increase the chances that they also provided a proprietary zig compiler for the chip
<scientes>
or for now, an unmaintained one
<andrewrk>
as much as I would prefer things to be open source, that is allowed
<tralamazza>
FireFox317: do you have a blue pill to test?
<ki9a>
andrewrk: well aware of the advantages of llvm. I have a commercial compiler using it too. Just feel i spend more time fighting llvm issues, speed and updates than actual work these days
<FireFox317>
Nope, I have a nucleo stm32f4 board, but I can try to test it on there
<tralamazza>
FireFox317: you might have to change the clock init
<daurnimator>
scientes: heh yeah I saw the gcc bug when it was first filed
Akuli has quit [Quit: Leaving]
marmotini_ has quit [Remote host closed the connection]
<marijnfs>
how do i add a include dir for c-code?
ross_k has joined #zig
<tralamazza>
is there a way to place a variable at a specific memory address?
<tralamazza>
(besides linker section trickery)
<ross_k>
Hi, I asked the other day about getting my project building on zig 0.4.0. I'm a bit further after downloading the latest master, but getting stuck at this error: