<leeward>
I knew it had to be something simple. For some reason my searches weren't finding it.
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
_Vi has quit [Ping timeout: 272 seconds]
aerona has joined #zig
<leeward>
andrewrk: Trying to build an SDL application with host x86-64-linux-gnu and target x86-64-windows-gnu, I got "undefined symbol: __declspec(dllimport) timeBeginPeriod" Is that one of those symbols you were talking about?
xackus has quit [Ping timeout: 256 seconds]
stripedpajamas has quit [Quit: sleeping...]
betawaffle has quit [Ping timeout: 260 seconds]
leeward has quit [Remote host closed the connection]
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
leeward has joined #zig
wjlroe has quit [Read error: Connection reset by peer]
betawaffle has joined #zig
wjlroe has joined #zig
doublex_ has quit [Ping timeout: 260 seconds]
doublex has joined #zig
reductum has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 272 seconds]
nephele_ is now known as nephele
<skrzyp>
Hello, has anyone explored the TUI interface programming in Zig language? Are there any libraries, or even already made TUI (full-screen terminal) programs?
<skrzyp>
I'mc
<skrzyp>
I'm considering doing something between 'dd' and 'partimage' with Zig, but generally described as 'dd with status window and sendfile()/zerocopy support'
reductum has quit [Quit: WeeChat 2.8]
<leeward>
skrzyp: You can always just use ncurses.
<skrzyp>
of course I can
<skrzyp>
but, you know, ncurses gets quite old in the world of fancy modern terminals, and it's not cross-platform (many UNIX variants use their own curses impleentations and so on)
<skrzyp>
I was thinking more about termbox or even some "immediate" approach to terminal drawing
<leeward>
I don't know of anything in the standard library, but any library that's written in C is likely to work with Zig. Most work right out of the box.
<leeward>
Simple macros work, but...complex stuff is different.
<shakesoda>
well, lots of simple ones fail too
<shakesoda>
they're just still pretty unreliable
<shakesoda>
i've had to fight with them a fair bit working with lua and sdl
<skrzyp>
mhm
<skrzyp>
nice to know about macros
<shakesoda>
simple #define A 1234 macros are just fine, to be more clear
<shakesoda>
macros with parameters tend to find ways to break and you have to write your own function to do what they do.
<shakesoda>
otherwise, for normal c code, the thing to watch out for is passing and returning structs by value - that's the only gotcha i'm aware of
<shakesoda>
unless something has changed in the last month with this, at least
<leeward>
Well, there was a translate-c bug fixed relatively recently.
<leeward>
I don't remember what it was though.
<pmwhite>
Is anybody doing backward iteration over arrays?. It's not too common, but when I need to do it, it always feels more awkward than I'd like. Has anybody ever proposed reverse for-loops?
<shakesoda>
i do backwards iteration frequently
<pmwhite>
What's your usual strategy? It's awkward with unsigned indices, so i'm using an isize.
<shakesoda>
just basic var i: usize = N; while (i > 0) : (i -= 1) { ... }
<leeward>
That will skip the last item if it's at index 0.
<shakesoda>
adjust as needed :)
<leeward>
Also viable: j = len-i
slowtyper has joined #zig
<shakesoda>
i've been writing this pattern in haxe lately, not zig, so the form has been i-- > 0
<shakesoda>
which is slightly different.
<shakesoda>
i really like lua's solution here of the for loop having a step argument
<shakesoda>
i don't screw those up.
<ttmrichter>
Haxe is from the Neko guy, right?
<shakesoda>
lua reverse for: for i = #table,1,-1 do ... end
<shakesoda>
same as a regular one but you swap the start/end and step with -1
<shakesoda>
ttmrichter: neko is one of the haxe things yes
<shakesoda>
i've been using their newer thing, hashlink, for quite a while now
cole-h has quit [Ping timeout: 264 seconds]
cole-h has joined #zig
<pmwhite>
shakesoda: I'm doing `var i: isize = N; while (i >= 0) : (i -=1) { ... }` because what you showed doesn't reach the 0 index I believe.
<pmwhite>
The annoying thing is that you can't index arrays with an `isize`
<shakesoda>
could also decrement i inside of the { instead of with the : ()
<pmwhite>
that would be the same though. I'm trying `while (true) : (i -= 1) { ...; if (i == 0) break; }`, which allows i to be a usize.
<daurnimator>
^ that's what I've used
opDispatch has quit [Quit: Konversation terminated!]
<pmwhite>
it would be kinda nice to have a `rof` keyword or something that does the same thing.
<pmwhite>
maybe it's not a major enough thing to include.
<shakesoda>
i don't think it justifies a keyword
<daurnimator>
i think we need an iterator protocol
<pmwhite>
shakesoda: probly right about that. I wonder if there is another way to make that simple enough.
<shakesoda>
clearly, we need another syntax tacked on as hellish as the : (foo) is
<shakesoda>
;)
<pmwhite>
lol
<leeward>
@reversed()?
<pmwhite>
Like `@reversed(array)`?
<leeward>
yeah
<pmwhite>
Or `@reversed(for) (array) ...`, lol.
<leeward>
for (@reversed(array)) |tnmele| {}
<leeward>
I can't lleps
<leeward>
Though really, in iterator protocol would make it easy to do in a pure Zig library.
<pmwhite>
Would @reversed(array)[0] == array[array.len - 1]?
<leeward>
That would make sense. Actually, if it just translates the indices, it wouldn't be hard.
<pmwhite>
Iterators would have worse performance, though.
<leeward>
Not necessarily.
<pmwhite>
How about this, then. Iterators would be harder to reason about.
<leeward>
If it just has 1 usize for state and a "next" method, it's not worse than doing it manually with a while loop.
<pmwhite>
It would still be worse than array looping, though, right? I haven't thought to deeply about it.
<leeward>
I don't see why it would be worse.
<leeward>
I think iterators will be useful regardless; lots of standard library data structures already provide something.
dingenskirchen has quit [Quit: dingenskirchen]
<pmwhite>
Would the usize and next method be on an Iterator struct? If each next method modifies the Iterator struct, then you are writing to memory more than if you just increment a loop register, which is what I'm imagining is happening with array looping.
dingenskirchen has joined #zig
<leeward>
Iterator.next() is small enough to fit in icache, or inlined since Zig does LTO, and the usize will fit in a register. Maybe without any optimizations it would be slower, but speed doesn't matter in that case.
<leeward>
At least, usize will fit in a register if 5185 is accepted.
<pmwhite>
So, if I made a userland iterator for arrays, would that be just as good as a for-loop?
<pmwhite>
If so, then I imagine the same would be true for a reverse-array iterator.
<leeward>
Only one way to find out.
<pmwhite>
Look at output assembly? I think I will leave that for another day, since it's late. If you want to do it, be sure to let me know what you find.
<leeward>
I will if I do.
<leeward>
It is late though.
shcv has quit [Ping timeout: 260 seconds]
<fengb>
Hmm, my tests stopped running. Might be a compiler bug :(
aerona has quit [Remote host closed the connection]
mcf has quit [Quit: quit]
_whitelogger has joined #zig
<Tharro>
Can I assume there is not penalty in using defer to increment in a loop to be able to exit the body of the loop? E.g. is while(i < 1) { defer i += 1; if (condition) continue; } as efficient as while (i < 1) { if (condition) { i += 1; continue; } i += 1; }.
<Tharro>
*no penalty at runtime
<daurnimator>
Tharro: yes. though it means e.g. an error in the loop body does an increment....
<Tharro>
Ok. Makes sense, I'll keep it in min, thanks.
<Tharro>
*mind
tdc has joined #zig
dddddd has quit [Remote host closed the connection]
marnix has joined #zig
st4ll1 has joined #zig
_Vi has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
karmayogi has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
karmayogi has left #zig ["ERC (IRC client for Emacs 26.3)"]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
<Snektron>
<pmwhite "Is anybody doing backward iterat"> var i = N; while (i > 0) { i -= 1; ... }
ur5us has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
ifreund has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
r4pr0n has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
greenfork has quit [Ping timeout: 258 seconds]
ask6155 has joined #zig
<ask6155>
Hello!
<ifreund>
o7
ask6155 has quit [Ping timeout: 258 seconds]
ask6155 has joined #zig
<ask6155>
How do I read Stdin do I get a file descriptor and read it as a file as in std.io.getStdin?
<ask6155>
but there's also std.os.read which takes fd which is an i32
<alexnask>
The std.os functions are low level
<alexnask>
I would recommend using the reader/instream interface
<ifreund>
std.io.getStdIn().inStream()
<alexnask>
So e.g. `const reader = std.io.getStdin().reader();` then you have functions like readAll, readUntilDelimiterOrEof etc
<alexnask>
(this assumes master, Reader is the new name for InStream although you can still use inStream for now)
<ask6155>
but there's also std.os.read which takes fd which is an i32
<ask6155>
oops
ur5us has quit [Ping timeout: 260 seconds]
<ifreund>
std.os.read is a thin wrapper around the syscall
<ifreund>
unless you have an unusual use-case the higher level std.fs.File interface will be sufficient and nicer to work with
<ifreund>
ask6155: your slice isn't pointing to anything
<ifreund>
var buf: [1024]u8;
<ifreund>
std.fs.File.read(stdin, &buf);
<ifreund>
there's also a readFileAlloc function
<ask6155>
std.fs.File.read only fills the buffer the rest of the text goes to the next stdin
<ask6155>
isn't that bad?
<ask6155>
like if i overflow the buffer the text after the buffer length gets cut off and sent to stdin of my shell and gets executed.
marijnfs_ has joined #zig
<ifreund>
yeah, buffer overflows are generally a bad thing
<ask6155>
is there a fix for this?
<ifreund>
use a bigger buffer?
<ifreund>
read only 1024 byte?
<ask6155>
how do I read only 1024 bytes>
<ifreund>
i think the easiest way is to use an InStream
<ask6155>
std.io.instream or std.fs.File.inStream?
<alexnask>
the File.inStream returns an io.InStream
<ifreund>
File.inStream() returns an std.io.InStream
<shakesoda>
i can't be the only one who thinks the stream apis are confusing
<shakesoda>
every time i get into anything with them i feel like i'm chasing stuff all over the place to figure out wtf to do
Snetry has quit [Ping timeout: 264 seconds]
Snetry has joined #zig
donaldallen has joined #zig
<donaldallen>
Can someone please explain to me why var foo:[3]*const [3:0]u8 =.{"foo", "bar", "baz"}; warn("foo: {}, {}\n", .{@TypeOf(foo), foo[0]});
<donaldallen>
results in this: foo: type, foo
<donaldallen>
I'm specifically asking about the result of @TypeOF.
<donaldallen>
I am using the latest download on FreeBSD.
<shakesoda>
if you use another type there what do you get?
<shakesoda>
i32, or the name of some struct or something
<shakesoda>
i would expect those to also say type if nothing is afoot
<shakesoda>
and their proper names otherwise
<donaldallen>
I would expect @TypeOf to produce the type of foo, which in this case is [3]*const [3:0]u8
<shakesoda>
you might want @typeName
<alexnask>
@TypeOf returns the type, but the format package prints out `type` for any type value
<donaldallen>
Yep -- thanks. this is part of a test program I use to sort out zig questions and I've printed types elsewhere in the program -- and used @typeName(@TypeOF). Forgot about it here. Thanks.
donaldallen has quit [Remote host closed the connection]
<ask6155>
what is built.endian?
<shakesoda>
the target endianness
<shakesoda>
most systems you'll encounter will be little endian, in case you're unfamiliar.
<ask6155>
is this value given by the compiler?
<shakesoda>
big endian was popular in a lot of older machines (powerpc, etc)
<shakesoda>
yes
<ask6155>
How do I get values from the arg iterator
<ifreund>
call next() or nextPosix()
ask6155 has left #zig ["bye!"]
r4pr0n has quit [Quit: r4pr0n]
nycex has quit [Ping timeout: 240 seconds]
nycex has joined #zig
dddddd has joined #zig
nmeum_ is now known as nmeum
xackus has joined #zig
<fengb>
Ah big endian. Killed by x86 :P
Akuli has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<leeward>
ARM can run big endian, but nobody does.
<fengb>
Even POWER supports little endian now
<leeward>
I once worked on a PPC microcontroller with a little endian USB peripheral. It was not well thought out.
<shakesoda>
fengb: isn't every modern power machine running LE?
<shakesoda>
this is also true of mips
<shakesoda>
there are still some stragglers of machines that technically sometimes are BE, it's just really uncommon
<shakesoda>
but hey, programming old machines exists.
<leeward>
There's always 68k
<companion_cube>
endianess only matters when serializing, anyway, right?
<pixelherodev>
Or emulating ;)
<leeward>
It matters for debugging.
<pixelherodev>
or compiling
<leeward>
"only" implies that's not a thing that gets done all the time.
<fengb>
Yeah, I meant that the last holdout POWER has given up :P
<leeward>
Every bit that goes on a network or into a log.
<leeward>
I'm amazed that an IBM processor has gone little endian. They were hard core about big endian.
<pixelherodev>
Why?
<pixelherodev>
That's a stupid thing to care aboujt
<pixelherodev>
about*
<leeward>
Bit 0 was the MSB in the PPC manuals.
<leeward>
I'm not saying they cared a lot, just that they didn't take half measures.
<fengb>
I think they realized they'd be even more irrelevant if they don't switch
<companion_cube>
leeward: well, hopefully, serializing directly into binary isn't something you do every day
<companion_cube>
or rather it's done via a library that uses the proper _le/_be functions for dumping integers onto a stream
<fengb>
I don't bother in my emulator :P
<fengb>
Mostly because BE is totally hosed trying to do anything >_>
<leeward>
companion_cube: I used to work on network devices. Basically all of our data was big endian.
<leeward>
When we switch from ARC to Tilera, there was pain.
<companion_cube>
ah, I guess it's different domains indeed :D
<companion_cube>
still, I wouln't like to read an int without specifying its endianess anyway
<leeward>
The fun part is when a layer 7 protocol has little endian data over a big endian transport. BLE does that.
<ifreund>
don't forget to call htonl and ntohl kids
<leeward>
iBeacon is little endian, but BLE isn't. Or maybe it's the other way around? I forget.
<ifreund>
unless you're in the mood for some fun
<jaredmm>
As someone who deals with IBM on a daily basis, it is always fun to hear them called irrelevant.
<leeward>
I was calling POWER irrelevant.
<leeward>
Not that I'm saying IBM is relevant. They're not relevant to what I do, but I've never worked for a bank.
<fengb>
Remember the previous gen consoles where IBM looked like they'd stage a comeback?
<leeward>
I miss PPC. It had some great stuff and x86 is a trash fire.
<fengb>
x86 is successful because it's a trash fire
<leeward>
I know, and it makes me sad.
<companion_cube>
fengb: s/x86/a lot of things/ :p
<jaredmm>
I work in the past, where you still year z/OS, DB2, and iSeries daily.
<fengb>
Hell, Intel tried burning it to the ground. Then AMD staged a coup :P
<leeward>
Mmmm, DB2
<leeward>
Yeah, itanium didn't suck.
<leeward>
Well, except as a business decision. AMD exploited the heck out of that.
<shakesoda>
itanium didn't even try to make itanium exist outside of servers
<shakesoda>
i'm pretty happy with arm, though. very much interested in the rumored upcoming arm macs
<leeward>
$14
<shakesoda>
leeward: well, sure, but i'd also need a machine around it
<shakesoda>
and even linux has dropped it :D
<fengb>
RISCV or bust
<shakesoda>
i am interested in riscv in the future
<leeward>
There's a 1U server for $500
<fengb>
Does NetBSD run on Itanic?
<jaredmm>
In some ways, I wish that Apple would switch to ARM, then Lakefield would pop out and be better.
<leeward>
NetBSD runs on everything.
<shakesoda>
jaredmm: they're expected to be doing exactly that this/next year
<shakesoda>
lol, itanic
<shakesoda>
an apt name
<pixelherodev>
RISC-V? boo
<pixelherodev>
RISC-VI!
marnix has quit [Ping timeout: 265 seconds]
<ifreund>
6 instructions instead of 5?
<pixelherodev>
Whoa whoa whoa
<ifreund>
:D
<pixelherodev>
You can actually get Itanium?
<shakesoda>
yeah
<pixelherodev>
ifreund: ha-ha. So funny.
<shakesoda>
just nothing that runs on it. except netbsd.
<pixelherodev>
lol
<fengb>
... I was laughing at "dominate" and now my coworkers think I have a kink
<leeward>
You're near coworkers?
<shakesoda>
fengb: good
<leeward>
I haven't been to the office in 2 months.
<fengb>
I'm not sure I should tell them "No, I just get amusement about LLVM dominating all usages"
<shakesoda>
run this joke/assumption into the ground
<shakesoda>
it's way funnier
<pixelherodev>
^
<pixelherodev>
For sure
<pixelherodev>
Then, in six months, casually refer to the LLVM thing and watch their brains just stop
<fengb>
"I'm too nerdy to be kinky"
<shakesoda>
that statement doesn't make sense at all!
<fengb>
Was on a conference call. Someone mispelled dominantHand as dominateHand
<jaredmm>
shakesoda: I heard that there was (another) ARM Mac rumor, but I haven't heard any strong rumblings that Lakefield will actually be an x86 competitor to ARM.
<shakesoda>
you'd just have extremely nerdy kinks.
<pixelherodev>
shakesoda: nah
<pixelherodev>
"I'm too nerdy to have time for kinks"
<pixelherodev>
FTFY
<shakesoda>
there's always time for kinks
<shakesoda>
your kink just might be faster compiles
<pixelherodev>
Do you know how many LoC I can write in a minute?
<pixelherodev>
I mean that's a terrible metric
<pixelherodev>
but still
<shakesoda>
imagining right now: dirty talk about cache optimal data structures
<companion_cube>
in french you don't have to go that far: even "string" and "byte" are funny
<shakesoda>
the kink where it's not just your optimization which is premature!
<shakesoda>
i will see myself out for that one
DrDeano has joined #zig
<DrDeano>
andrewrk, I was able to fix my problem, The issue was I was using and arraylist and calling span() to get the argv for the process to run, when I changed this to toOwnedSlice(), it didn't throw the OOM
<ifreund>
weird
<DrDeano>
I know right, idk whether it is to do with that the items in the array list wasn't initialised and when calling span return the items and other memory with garbage
<ifreund>
one thing to note is that ArrayList.span() is deprecated, you can just use the .items field directly now
<ifreund>
toOwnedSlice() will reallocate the memory to the exact size of the slice if the ArrayList had larger capacity, maybe that has something to do with it?
a_chou has joined #zig
<afontain_>
(span() being deprecated) ah, well, that's good to know
<afontain_>
I was using it simply because that's what the doc uses
<pixelherodev>
whoops
<pixelherodev>
docs out of date again :P
<ifreund>
afontain_: link to the doc? i'm bored I might as well fix it
<leeward>
I think that one was in the 0.6.0 release notes, but yeah. It should get fixed.
decentpenguin has joined #zig
<ifreund>
found one mention in the core docs for master
<afontain_>
"Use span instead of slicing this directly, because if you don't specify the end position of the slice, this will potentially give you uninitialized memory."
<afontain_>
about the items field ^
<ifreund>
yeah, that's what the old comment said before the source was updated
<leeward>
Speaking of doc fixes, #5590
<ifreund>
i guess the std docs need to be regenerated but I don't know how that works
<afontain_>
I don't know how docs are generated tbh
<leeward>
There's a -femit-docs switch, but I'm not sure exactly how it gets used to generate the stuff in the std documentation.
<ifreund>
oh, I just opened a PR updating that example
<ifreund>
it still makes sense with .items I think
<leeward>
Better docs are better.
<ifreund>
i think this might be one of those things that isn't worth implementing well in stage1 and will wait for stage2 to get farther along
<leeward>
Are we still talking about ArrayList.items?
<ifreund>
oh I'm talking about std docgen
a_chou has quit [Quit: a_chou]
<ifreund>
there seems to be something built into the stage1 compiler for it, but I'm not 100% sure what it does
<leeward>
ah
<pixelherodev>
Hmm
<pixelherodev>
```Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C.```
<pixelherodev>
I think this is inaccurate
<pixelherodev>
Isn't it more that we explicitly *define* overflow as illegal by default?
<pixelherodev>
Ahh right, this is probably from before the UB -> Illegal switch
<pixelherodev>
terminology switch*
doublex has quit [Remote host closed the connection]
<pixelherodev>
Going to finally get back to stage2 in the next few days :)
<pixelherodev>
The emulator for showtime is now Good Enough TM, so I just need to finish a few changes in other projects and then I can get the error tests done
<pixelherodev>
Then, function calls! :)
<pixelherodev>
With arguments!
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
cole-h has joined #zig
bsrd has joined #zig
<leeward>
Why can't they get along? Why must the functions be arguing all the time?
<pixelherodev>
leeward: well, why must six be afraid of seven?
<pixelherodev>
Some things are just meant to be
<leeward>
I suppose.
<pixelherodev>
Though then again
<pixelherodev>
I mean we know that one
<leeward>
I mean 7 earned it.
<leeward>
Cannibal.
<pixelherodev>
What? No.
<pixelherodev>
6 * 7 = 42
<pixelherodev>
Six just can't handle responsibility.
<leeward>
hah
<pixelherodev>
bsrd: I haven't tried that, sorry
<bsrd>
Does pointer arithmetic on c pointers work?
<pixelherodev>
What OS are you on?
<pixelherodev>
I thinkso
<pixelherodev>
s/thinks/think s
<bsrd>
Void Linux
<pixelherodev>
std.net should work on Linux
<bsrd>
Have no issue doing basic unix socket stuff.
<pixelherodev>
I'm assuming picohttp works in C code?
<ifreund>
pointer arithmetic works fine, but you shouldn't really use [*c] pointers in your zig code
<ifreund>
they coerce to whatever zig pointer you want, e.g. [*] if you want to do pointer arithmetic
<leeward>
There is a reason why C pointers aren't listed in the "pointers" section of the docs.
<pixelherodev>
C pointers are for translated code only, really
<leeward>
And only auto-generated translated code, at that.
<leeward>
Hmm, I wonder if some day we'll be able to put translation hints in our .h files to make it so a Zig translator can tell if a pointer is actually a [*:0]
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 260 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
FireFox317 has joined #zig
greenfork has joined #zig
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
riba has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
dingenskirchen has quit [Ping timeout: 256 seconds]
dingenskirchen has joined #zig
andrii has joined #zig
<FireFox317>
andrewrk or somebody else, so we had this issue with some guy saying that zig cc is not working on arm32 (#5572). It segfaults immediately in DepTokenizer.next(). I looked into it, and it has something to with a c interop thing. in stage2.h we define stage2_DepTokenizer with a void * to a handle. Now in the zig equivalent code it is an extern struct with a pointer to the actual DepTokenizer struct. I think this is causing a segfault,
<FireFox317>
but i dont know enough about c void* (alignment etc) to know exactly what is going on.
andrii has quit [Client Quit]
riba has quit [Ping timeout: 246 seconds]
ur5us has joined #zig
wootehfoot has joined #zig
<andrewrk>
FireFox317, I don't see a mismatch here
<andrewrk>
it looks like it is a struct in both places
<dch>
bonus points for pixellated fonts it seems appropriate
<andrewrk>
dch, you thinking about doing a talk? :)
<dch>
well if you imagine somebody who hasn't written any C in mmm almost 20 years ... not sure if it would advance the world's understanding of low level programming
<dch>
but I have my computer set up now for livestreaming so I might have a crack at streaming my first zig-stumbles
<fengb>
I’m a dirty JS programmer pretending to understand low level
<dch>
fengb: I'm an erlang programmer who likes understanding the layers below. it's turtles all the way down AFAICT
<FireFox317>
okay andrewrk, it seems like OOM is not handled in the stage1 compiler right? That is basically what is happening when trying to use `zig cc` on a rapsberrypi :P
<andrewrk>
FireFox317, it's handled by panicking - a segfault is still surprising
marijnfs1 has joined #zig
Akuli has quit [Quit: Leaving]
marijnfs has quit [Ping timeout: 256 seconds]
<leeward>
dch: How did you pull off being an Erlang programmer? I keep running into walls at places because "it's weird."
<dch>
honestly its the first programming language since z80 & 6502 assembler that really made sense to me. I've since dabbled in ocaml, but no decent concurrency story so I didn't really do much.
<dch>
leeward: its a sweet spot between concurrency, distributed systems, functional programming, without shoving functors and monads in your face all the time.
<leeward>
Sure, but you found jobs somewhere? I guess I've tried converting employers; never actually looked for people hiring for Erlang.
<leeward>
dch: You don't have to sell me on it. It's one of my favorite languages; I've just never had an employer willing to pay me to write in it.
<dch>
yep. it helps to have some community links, and be familiar with some of the main apps (rabbitmq, couchdb, riak ...), and elixir & phoenix are very very nice
<dch>
remote work is tricky, its much harder to find the right mix of tech & culture
<leeward>
I mostly work on embedded stuff, so pure remote work is off the table. Shipping hardware and lab equipment around is too much time and effort.
<dch>
I actually ran into zig while looking for a safer way to integrate NIF code into erlang, I wanted to see if I could use FreeBSD jails & capsicum with erlang.
tdc has quit [Ping timeout: 256 seconds]
<andrewrk>
you know about that erlang nif project, right? just checking
<dch>
ifreund[m]: just watched your zig show talk, nice to have somebody walk through the C -> zig stuff. tyvm.
ifreund has joined #zig
shcv has joined #zig
DrDeano has joined #zig
<gonz_>
leeward: If one's in the market for a backend job Erlang can hide around almost every corner. I think a persistent but plenty ephemeral service like online soft real-time ones usually are will have a higher hitrate than anything else.
<gonz_>
Erlang is one of the languages I think has less job ads than it has users, out of proportion.
<gonz_>
There are two positions in all of Bulgaria (that seem credible), down from 4 when I searched back in ~2015.
<gonz_>
One of them is Bet365, this one would be your prototypical Erlang job
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
FireFox317 has quit [Ping timeout: 246 seconds]
drp has quit [Remote host closed the connection]
mq32 has quit [Quit: Winke winke!]
mq32 has joined #zig
<leeward>
gonz_: Interesting. Maybe that's what I'll do when I retire.
<ifreund>
dch: glad you enjoyed it!
<leeward>
(where by retire I mean stop with the full time job)