waleee-cl has quit [Quit: Connection closed for inactivity]
stripedpajamas has joined #zig
craigo has joined #zig
marnix has joined #zig
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
craigo has quit [Remote host closed the connection]
craigo has joined #zig
marnix has quit [Read error: Connection reset by peer]
ur5us has quit [Ping timeout: 256 seconds]
_Vi has joined #zig
andor has joined #zig
marnix has joined #zig
antaoiseach has joined #zig
<antaoiseach>
Hello, folks ... I'm trying to build on macOS 10.14 with the -DZIG_WORKAROUND_4799=ON flag, but running into some weird errors (looks like some problem withe the C++ compiler?) I'd appreciate it if someone could take a quick peek at the errors (one page long) - https://paste.rs/S3Q.textile
<antaoiseach>
For reference, my g++ version is `++-10 (Homebrew GCC 10.1.0) 10.1.0`
<antaoiseach>
(Note, also tried it with the builtin clang compiler that's bundled with macOS, but no luck)
<antaoiseach>
My LLVM version is homebrew installed - 10.0.0
<daurnimator>
antaoiseach: what version(s) of clang do you have installed?
<antaoiseach>
daurnimator: clang version shows
<antaoiseach>
$ clang --version
<antaoiseach>
Target: x86_64-apple-darwin18.7.0
<antaoiseach>
Thread model: posix
<antaoiseach>
clang version 10.0.0
<antaoiseach>
But I'm using GCC installed via homebrew
<daurnimator>
antaoiseach: its fine to compile zig with gcc; zig just uses libllvm and libclang... 10.0.0 should be fine
<antaoiseach>
daurnimator: yeah, that's what I thought as well ... tried removing GCC and using the builtin compiler - identical errors
<antaoiseach>
Can't figure out what the problem is! Searching on llvm forums is an exercise in brain damage for me
<daurnimator>
antaoiseach: I'm wondering if you have more than one version of clang/llvm installed and its getting confused between them
<daurnimator>
like, you have 10.0.0 from brew; but then you have some version from xcode as well
<antaoiseach>
daurnimator: What do you suggest I do - try uninstalling the GCC one and try with the Xcode version?
<daurnimator>
antaoiseach: no...
<daurnimator>
try and see if you have more than one clang/llvm installed
<antaoiseach>
daurnimator: Okay, will check that and get back... thanks!
stripedpajamas has quit [Quit: sleeping...]
cole-h has quit [Quit: Goodbye]
Biolunar has quit [Quit: leaving]
Biolunar has joined #zig
nikita` has joined #zig
_Vi has quit [Ping timeout: 256 seconds]
antaoiseach has quit [Quit: leaving]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
dermetfan has joined #zig
marnix has quit [Read error: Connection reset by peer]
<pixelherodev>
Oh yeah, stage1 is fully single-threaded, right?
layneson has joined #zig
<pixelherodev>
Woot, with buildbuddy I can do stage2 work much, much faster - building self-hosted + running all stage2 tests + testing SPU-II backend takes 60 seconds locally, 20 via SSH :D
layneson has quit [Ping timeout: 256 seconds]
Ashpool has quit [Read error: Connection reset by peer]
Ashpool has joined #zig
<gpanders[m]>
Hi all, what is the difference between using `comptime T: type` and `anytype` to define generic functions? Do these work the same way in practice? Do they generate the same code?
<ikskuh>
hey gpanders[m]!
<pixelherodev>
`type` only takes in `types`
<pixelherodev>
That is, `u8`, `void`, `[]const u8`, etc
<Nypsie>
`comptime T: type` accepts a Type, `anytype` accepts any variable/reference/etc
<pixelherodev>
`anytype` means a *value* of any type
<gpanders[m]>
So does the usage of `anytype` obviate the `comptime T: type` pattern? After all, can't I use (in the function body) `const T = @TypeOf(x)` where x is a variable of `anytype` ?
<ikskuh>
gpanders[m]: ah. no, not really
<ikskuh>
it's a matter of safety what you want to do
<ikskuh>
anytype is less strict
<pixelherodev>
`T: type` means I want a type
<pixelherodev>
`T: anytype` means I want any value
<fengb>
Generally the rule of thumb is, use `comptime T: type` when you can, `anytype` if you're solving a problem
<pixelherodev>
e.g. 3 and "Hello" are valid for `anytype`, but not for `type`
KKRT has joined #zig
<pixelherodev>
Should stage1 be rebuilt if I update src-self-hosted files?
<leeward>
Along those lines, "u32" and "[]const u8" are valid values of type "type".
<leeward>
This is a good point though. `anytype` is kinda confusing in context next to `type`.
<gpanders[m]>
Right, but I can get the type of an `anytype` variable using `@TypeOf(x)`, which is evaluated at compile time (?), so what's unclear to me is why I shouldn't just do that instead of using the `comptime T: type` pattern
Ashpool_ has joined #zig
<leeward>
gpanders[m]: because users of your function won't know what to do.
<pixelherodev>
more to the point, because there *isn't* a value
<pixelherodev>
e.g. std.ArrayList(u8)
<pixelherodev>
Passing in e.g. `1` makes no sense whatsoever
<gpanders[m]>
pixelherodev: that's a good example that makes sense to me. But what about something like std.mem.dupe where I pass in both the type and the value to be duplicated. In that case, why can't the type be inferred directly from the value I pass in?
<gpanders[m]>
using @TypeOf
<fengb>
Typically stdlib works with `comptime T: type`, and only switches to `anytype` when there's more than 1 type or if the type definitions are atrocious (like readers/writers)
<leeward>
Unless that's not the case. For example, std.testing.expectEqual does use @TypeOf because it gets 2 values of any type, as long as they're the same type.
<fengb>
You can do that yes, but the signature doesn't make it obvious what's going on
<pixelherodev>
It's also because it makes it easier for the compiler to catch errors
<fengb>
At the end of the day, you can probably use `anytype` for all the function signatures. But I wouldn't recommend it
Ashpool has quit [Ping timeout: 264 seconds]
<pixelherodev>
e.g. `blah(T: type, a: T, b: T)` - if you give it `3, "hello"`, the compiler will immediately know it's wrong because it doesn't match the signature
<gpanders[m]>
fn myfunc(comptime T: type, some_var: T) T
<pixelherodev>
With `a: anytype, b: anytype`, the function has to do comptime logic - which is currently interpretd
<gpanders[m]>
are these equivalent, with the exception that one requires one fewer parameter?
<pixelherodev>
They might be equivalent in meaning, but not in perception
<ikskuh>
gpanders[m]: anytype hides the function signature and doesn't create type mismatch errors
<pixelherodev>
` * Favor reading code over writing code.`
<ikskuh>
so for example:
<pixelherodev>
That's part of the Zen of Zig - making you write out the type is annoying while writing, but easier for readers later on
<ikskuh>
fn(comptime T: type, data: []const T) is way more explicit than fn(data: anytype)
<leeward>
It's also impossible to call the second version with some immediate values. Say I want it to return u7 but I have "3" to pass in. That means I have to call myfunc(@intCast(u7, 3))
<gpanders[m]>
leeward: Ah!
<ikskuh>
leeward: @as(u7, 3)
<ikskuh>
but yeah
<leeward>
sure
<gpanders[m]>
that makes sense
<leeward>
I never remember @as exists.
<gpanders[m]>
the @as(u7, 3) is awkward
<ikskuh>
u7(3) was better imho but i understand why it was changed
<gpanders[m]>
and pixelherodev I like your explanation too, I agree with you (and the Zen of Zig) about prioritizing reading over writing
<leeward>
For what it's worth, I think the self-documenting properties are the best reason.
<pixelherodev>
Multiple good reasons exist, who cares which one's "best?"
<pixelherodev>
:)
<fengb>
I care
<leeward>
Well if the smartest person around cares, that's all the justification I need.
<fengb>
B)
<pixelherodev>
Hmm, I might have to challenge that
<pixelherodev>
Are we sure fengb is a person?
<leeward>
I've seen video. It could be a next generation deep fake, but...occam's razor suggests it isn't.
<ikskuh>
feng b)
<leeward>
Of course, I could be a bot written by fengbot to allay suspicion.
<pixelherodev>
Hmm, that's true, but occam's razor suggests that principles are incapable of making suggestions... I'm not sure where I was going with that joke :P
<leeward>
Excuse me, chairman of pedantic society. "Application of occam's razor suggests..."
* ikskuh
votes to et occam's razor be a thing of the past and instead apply occam's lazor
<ikskuh>
way more cyberpunk
* pixelherodev
seconds that vote
<pixelherodev>
It also makes it harder for people to make stupid shaving jokes
<ikskuh>
(also, occam's lazor is a band which does nice synthwave)
* andrewrk
loving these PRs to stage2
* pixelherodev
does also
<pixelherodev>
It took me a good chunk of time just to sift through them all
<leeward>
I think that's occam's laser.
<ikskuh>
waaaait. where do all these PRs come from?!
<pixelherodev>
One from pfgithub, one from luukdegram, one from vexu
<pixelherodev>
I'm still working on my SPU-II one
<ikskuh>
floats is a nice one
<fengb>
I feel like I should start contributing again
* ikskuh
is still occupied with porting C++ projects to zig and make them 150% more awesome
<Nypsie>
If float gets merged I could add it the substraction pr
<Nypsie>
it to the*
<ikskuh>
andrewrk: how's stage2 work going?
<andrewrk>
swiftly
<pixelherodev>
We're moving very quickly, it's awesome
<fengb>
Wait... Nypsie == Luuk?
<Nypsie>
Yes
<andrewrk>
it's starting to become more contributor friendly
<pixelherodev>
andrewrk: should RAM/ROM/etc specification be part of std.Target?
<pixelherodev>
I was looking in Options for a good place to put it
<ikskuh>
pixelherodev: how is that specification looking?
<pixelherodev>
My current plan is to just have an array of Ranges, where a Range is `readable`, `writable`, `executable` (bools) plus `start` and `end`
<ikskuh>
hm
<ikskuh>
because that sounds like stuff is currently in the linker script
<pixelherodev>
nope
<pixelherodev>
there is no linker script
<ikskuh>
huh?
<ikskuh>
well, _currently_ ;)
<pixelherodev>
Stage2 doesn't support linker scripts, and probably never will
<andrewrk>
pixelherodev, get something working and we'll shape it into place. think of it like working with clay
<pixelherodev>
We're trying to find better alternatives for functionality exposed by linker scripts
<ikskuh>
yeah, i know
<pixelherodev>
assuming I'm remembering random threads correctly, at least ;:
<ikskuh>
so the plan is to give zig a configurable/scriptable linking stage
<andrewrk>
I don't think there is a plan yet other than the vague sense that linker scripts are possibly the wrong solution
<ikskuh>
:D
<ikskuh>
what you *should* include right now if you do anything for linking:
<ikskuh>
separate memory target location and memory linking location
<andrewrk>
elaborate?
<ikskuh>
how do you initialize your ram with pointers when you cannot store persistent data in ram?
<ikskuh>
it's common in embedded to have the following layout in flash:
<ikskuh>
{ .boot, .text, , rodata, .data }
<ikskuh>
and on boot, you copy everything from .data into the corresponding RAM sections
<ikskuh>
so you link against 0x8000, but the actual data is at 0x3456 in the binary
<ikskuh>
storage position != linked address
<andrewrk>
so far this is the same as "normal" targets such as x86_64-linux
<ikskuh>
it is?
<pixelherodev>
ahhh, not quite
<pixelherodev>
Wait, hmm, maybe
<ikskuh>
i didn't see the copying code for .data in _start for linux
<ikskuh>
there are three things locations for a symbol:
<pixelherodev>
No yeah, with freestanding you might need to shadow ROM -> RAM etc
<ikskuh>
1. location in RAM during execution
<ikskuh>
2. location in ROM for persistence
<ikskuh>
3. location in the binary file (elf)
<ikskuh>
for linux, #2 does not exist.
<ikskuh>
you mmap 3 → 1
<ikskuh>
but for embedded, you flash 3 → 2, then load 2 → 1 at boot time
<ikskuh>
which is also important if you want several versions of the same function. you link all variants of the function against 0x8120, but they reside at 0x1000, 0x2000, 0x3000 and you copy the right function for your hardware to 0x8120
<ikskuh>
which would be a viable option for the "select correct function for SSE/AVX/…" for PC as well
<pixelherodev>
That can come later
<pixelherodev>
For now, I'm assuming a single HW target
<pixelherodev>
that'll need separate work anyways, since it'll need to work for all platforms
<andrewrk>
vexu working on stage2 is 🔥 🔥 🔥
<ikskuh>
pixelherodev: yeah, that's something for later. but it's just an application of the problem i've talked about
<pixelherodev>
it's a quare?
<pixelherodev>
square?
<ikskuh>
square?
<pixelherodev>
vexu working on stage2
<ikskuh>
i think you're using something slang right now? :D
<pixelherodev>
no
<ikskuh>
oh.
<ikskuh>
oh!
<pixelherodev>
`14:17:46 andrewrk | vexu working on stage2 is 🔥 🔥 🔥 ` <-
<ikskuh>
those are flames :D
<ikskuh>
fix your system.
<pixelherodev>
ahhh
<pixelherodev>
lol
<leeward>
Get more unicodes.
<ikskuh>
get something that can display proper emojis
<pixelherodev>
meh
<pixelherodev>
I think SPU II is more important than my fonts lol
<ikskuh>
you're in zig community. you're officially required to be able to see emoji. otherwise it's 💩💩💩💩
<ikskuh>
i don't see correlation between those two :D
<pixelherodev>
I can see *those* ones lol
<ikskuh>
good.
<pixelherodev>
Also, there *is* no "official"
<pixelherodev>
;)
<ikskuh>
i know :D
<fengb>
Unicode tofu is best tofu
<ikskuh>
but how else could you ever interpret PSV-Data?
<leeward>
trust on first use?
cren has joined #zig
riba has joined #zig
<pixelherodev>
Do we have a keyword to mark functions as always-comptime?
<ikskuh>
andrewrk: the kernel doesn't actually know about the 0x2000 thingy
<ikskuh>
when loading a ELF file linked like this, it will just happily put the data to 0x1000
<ikskuh>
and is done
<andrewrk>
I see, you're talking about the other features that linker scripts provide
<ikskuh>
yeah and those are *required* for embedded systems to actually have pre-initialized values
<pixelherodev>
We use something similar for KnightOS
<andrewrk>
the minimal thing we need is a way for code to access the start and end virtual address of link sections
<pixelherodev>
All initialized values get placed in their own section, and the crt0 copies them into place on application launch
<pixelherodev>
Yeah, that's really all it is
<ikskuh>
andrewrk: that won't help here. because the virtual adress is not initialized in that case
<andrewrk>
how would the startup code initialize .data in this case?
<ikskuh>
memcpy from flash (stored address) to ram (linked address, which i consider the virtual address the linker assigned the variable)
<pixelherodev>
It needs to basically copy all .data from some other arbitrary address in persistent s - imp'd
<pixelherodev>
We also need a way to get the physical address, then
<pixelherodev>
We don't necessarily need a way to specify (we can let Zig make that decision), just a way to retrieve it
<ikskuh>
yeah and a way to group and *sort* symbols
<pixelherodev>
Why?
<pixelherodev>
Different use case?
<ikskuh>
you want to batch-copy all symbols and don't generate code to copy each symbol alone
<ikskuh>
also sorting/grouping symbols might be required for different memory shenanigans
<pixelherodev>
Here's an idea: how about a builtin e.g. @shadow which automatically does all that?
<pixelherodev>
e.g. `@shadow(.data)` will automatically generate code to `memcpy` from the stored addr to virtual?
<ikskuh>
no, this stuff should be super-explicit
<ikskuh>
no hidden control flow
<pixelherodev>
Fair
<ikskuh>
you might need to do patching and stuff
<pixelherodev>
Could be a utility function in std at least, it should be nearly identical per platform
<ikskuh>
yeah, that's true
<pixelherodev>
But that still needs some data exposed
<ikskuh>
std.embedded.initSection(".data");
<pixelherodev>
Yeah, exactly
<pixelherodev>
Bonus: a soft-reset can just call that again, reset sp, and jump to _start
<ikskuh>
yep :D
<ikskuh>
that's how you soft-reset
<pixelherodev>
We could reasonably have std.embedded.reset
<pixelherodev>
"might need to do patching" <- why's this?
<andrewrk>
I remember playing some old sega genesis games, and after you beat the game, you could press the soft reset button, and yet there was something special about the game, some bonus content. it broke my brain, I did not understand how that was possible
<ikskuh>
arm cortex with an NVIC requires you to have one "ISR" to be a checksum
<pixelherodev>
Mind elaborating?
<pixelherodev>
Why does this need more than a memcpy?
<pixelherodev>
Won't that set it up correctly anyways?
<pixelherodev>
Does it need a specific address or something?
<ikskuh>
you need to copy the ISR table *sometimes* :D
<pixelherodev>
... huh?
<ikskuh>
and then change things in it to let it point to the right address again
<ikskuh>
yeah, weird stuff :D
<ikskuh>
relative addressing is lovely :D
<pixelherodev>
but if you know all addresses, relative addressing doesn't matter
<ikskuh>
AVR for example does not have ISR pointers
<pixelherodev>
My JIT uses relative addressing 99.99% of the time anyways
<ikskuh>
it has ISR routines
<ikskuh>
which are instructions :D
<ikskuh>
so a non-implemented ISR is not "0x0000", but "iret"
<pixelherodev>
so would that be `std.embedded.init... ; asm volatile("blah");`?
<pixelherodev>
Right, that's one of the z80 modes too IIRC
<ikskuh>
nah, that stuff is super-platform-specific
<pixelherodev>
So for that specific platform, you'd need more work, and wouldn't want the convenience func at all?
<ikskuh>
yep
<ikskuh>
something like "common platform helpers" aren't bad
<ikskuh>
but architectures are weird and you cannot really map all platform initialization to the same generic interface
<ikskuh>
for example, it might be better to first crank up your PLL, *then* initialize .data
<ikskuh>
btw, i made a improved note for the issue
<ikskuh>
with a hexdump example to make clear what should happen
<leeward>
Fun with translate-c: #define FOO ((some_type_t)-1) -> pub const FOO some_type_t - 1; integer value 1 can't be coerced into type 'type'
<pixelherodev>
It doesn't detect casts within macros?
<leeward>
It does not.
<ikskuh>
oh, that's a cast :D
<ikskuh>
lol
<ikskuh>
i didn't detect the cast as well
<leeward>
Turns out C's grammar is confusing for more than just Zig.
<ikskuh>
well
<ikskuh>
it's undecidable what it semantically is
<ikskuh>
it might be a cast
<ikskuh>
it might be a subtraction
<leeward>
Who needs context free grammars?
<leeward>
Aren't people always saying context is key?
<pixelherodev>
Hmm, no, I'm 99% sure that's always a cast
<ikskuh>
no, it's not
<pixelherodev>
`(T)literal` is always a cast, no?
<ikskuh>
but it isn't a literal ;)
<pixelherodev>
It's written out as -1
<pixelherodev>
That's literally a literal
<ikskuh>
it's a unary or binary operator -
<ikskuh>
no
<ikskuh>
-1 is "unary minus applied to 1"
<ikskuh>
so
<pixelherodev>
Ahhh, gotcha
<ikskuh>
((5)-1)
<ikskuh>
is totally legit ;)
<pixelherodev>
But *if* it's a type... so we need to analyze C and detect types?
<pixelherodev>
That sounds like a job for CFE ;)
<ikskuh>
Assertion failed at /deps/zig/src/ir.cpp:28803 in ir_analyze_instruction_check_switch_prongs. This is a bug in the Zig compiler.
<ikskuh>
:(
<ikskuh>
oh
<ikskuh>
LOL
<ikskuh>
switch(foo) { bar => {}, bar => {} }
riba has joined #zig
<pixelherodev>
zheh
<pixelherodev>
heh*
<leeward>
Hey, you found a bug in the Zig compiler that's easy to replicate!
<leeward>
That is the best kind.
riba has quit [Ping timeout: 264 seconds]
<ikskuh>
:D
<ikskuh>
i don't know if it's that easy to replicate
decentpenguin has quit [Quit: decentpenguin]
christianbundy has joined #zig
FireFox317 has joined #zig
<ikskuh>
btw, andrewrk: i noticed that zig is the first language that really makes me program defensive
<ikskuh>
the idea that you cannot ignore errors is great :)
<ifreund>
what, you're not the type to add supreflous NULL checks to your C?
cren has quit [Ping timeout: 240 seconds]
<leeward>
What percentage of mallocs would you say have `if (ptr == NULL)` after them? I would guess less than 30.
<ifreund>
honestly that's fairly optimistic
<ifreund>
there's a lot of bad code out therer
<leeward>
You're probably right.
<ikskuh>
how many C++ new() do check for bad_alloc?
<ikskuh>
or any exception at all?
<leeward>
I would guess much less than 1%
<Akuli>
does it bubble up in c++?
<leeward>
Yeah, it throws.
<leeward>
It has to, since null references aren't a thing.
<leeward>
I think that's why, anyway...it's been a while.
<shakesoda>
i definitely don't null check all my mallocs in my c, despite feeling like i usually do
<shakesoda>
i also work on games where the failure mode is halt and catch fire anyways if something like a malloc is gonna fail
<shakesoda>
not that they should not be checked
<fengb>
I mean, most languages have decided memory allocation can’t fail right? >_>
marnix has joined #zig
<pixelherodev>
Fun fact: new() can actually abort() or return NULL
<pixelherodev>
It's not a language thing, it's a stdlib thing
<fengb>
Hardware problem! Next!
<andrewrk>
it's really convenient to assume unlimited resources
<leeward>
Oh, right, it's because constructors.
<shakesoda>
zig doesn't give me a choice so if my error checking hygiene is going to be bad i have to work for it lol
<leeward>
See also: oomkiller and overcommit.
<leeward>
`try allocate()` is basically the same as an uncaught `new` though. Kick it upstairs.
<leeward>
I mean, it sucks less than exceptions, but that's a different issue.
<fengb>
I feel like Zig is exceptions done right
<shakesoda>
it isn't the same though, in a pretty simple way
<leeward>
Zig really is exceptions done right. It's what Go's multiple return values wishes it were.
<pixelherodev>
leeward: to be fair, overcommit has valid reasons to exist
<shakesoda>
which is that c++ doesn't make you actually handle it anywhere
<Akuli>
one annoyance with zig's errors is that i can't attach arbitrary data with them
<pixelherodev>
I don't say the same for oomkiller
<fengb>
Or at least, the upsides of exceptions without the downsides
<shakesoda>
zig at *least* makes you update your function signature
<companion_cube>
leeward: that, or Result
<leeward>
pixelherodev: I'm aware. Doesn't mean I leave overcommit on.
<Akuli>
if reading a file fails and i want to bubble up an error, then whatever handles that error must figure out which part of the file has the error in it
<shakesoda>
so you don't have some interior thing doing uncaught exceptions without you knowing about it. ever.
<pixelherodev>
My ideal OOM killer: suspend any process that asks for more memory while we're out, and use pre-reserved memory to switch to a TTY and ask the user what to do
<leeward>
See also: Either and Maybe monads.
<companion_cube>
either being a bad name though, result is better
<pixelherodev>
Best case: a program proceeds to release memory. Worst case: user gets to decide what to kill
<leeward>
companion_cube: Totally agreed. I like Maybe but can never remember what Either is called.
<shakesoda>
for the most part if a task is eating all my memory i want it to be killed
<pixelherodev>
I might not
<shakesoda>
it usually happens when i have screwed up profoundly
<pixelherodev>
True
<shakesoda>
so, i'm fine with that being a default behavior
<fengb>
On phones it can get tricky
<pixelherodev>
But if a ZIg compilation is using a lot of RAM in stage1, I'd rather let it finish as long as it doesn't ask for more
<leeward>
If a task is eating all my memory it's Oxygen Not Included and I've left it running for too long.
<pixelherodev>
Or, kill other stuff to make room
<shakesoda>
if a compiler is taking up so much ram it's going to oom my machine, well, that's really awful and should be fixed :D
<leeward>
The best is when oomkiller takes out ssh.
<shakesoda>
that includes you, zig stage1!
<leeward>
shakesoda: I know of no compilers that would do that. What a ridiculous hypothetical scenario.
* leeward
glances at rpi leaking magic smoke on desk.
<pixelherodev>
shakesoda: true
<shakesoda>
leeward: i've made a lot of technical decisions through recent years just to avoid things like this
<leeward>
shakesoda: things like having something eat all your RAM?
<shakesoda>
i am willing to sacrifice a good amount of runtime performance to not have to wait on builds or have things eat all my ram
<leeward>
ah
<shakesoda>
which is to say i have explicitly moved things onto jits/interpreters that are lighter on resources for this
<fengb>
omnomnom
<pixelherodev>
Smarts
<fengb>
Wait, jits are lighter on memory?
<pixelherodev>
They can be
<shakesoda>
than stuff like c compilers? god yes
<pixelherodev>
False
<pixelherodev>
GCC / Clang
<pixelherodev>
Those aren't C compilers.
<leeward>
Most of my compilation targets don't have enough flash for my computer to spend much time building code for them.
<shakesoda>
okay, fine, monsters.
<pixelherodev>
*Thank* you. There you go.
<leeward>
Are you calling GCC a fake scotsman?
<shakesoda>
no we're calling it a monster
<fengb>
GNU C Compiler
<pixelherodev>
no. I'm calling it a real monster.
<pixelherodev>
Nope
<pixelherodev>
GNU Compiler *Collection*
<leeward>
GNU Compiler Collection
<fengb>
I don't care that they renamed
<pixelherodev>
It can technically compile C, but that's like saying that it can technically assemble
<leeward>
To be fair, gcc calls gas when it wants to assemble.
<pixelherodev>
`gcc blah.c` is like `gcc blah.asm`
<pixelherodev>
It's just a terrible idea, and there's better ways to do it
<shakesoda>
leeward: on the targets i usually use, luajit is a viable option and it's a lot less of a time and resource sink than gcc et al would be for similar work
<leeward>
I don't know about you, but I really like having the C preprocessor when compiling my assembler code.
<shakesoda>
that said, i'm here, so it's not like i'm totally averse to using a compiler
<shakesoda>
i just have lots and lots of stuff pushed away from needing aot compilation
<pixelherodev>
My solution to that is to have lighter compilers :P
<leeward>
Optimizing for programmer time makes tons of sense. I think everyone should do it as much as they can.
<shakesoda>
i await zig being the fastest compiler in the west
<shakesoda>
maybe even the east, too.
<fengb>
Nah, Zen has that covered 🙃
* pixelherodev
rofls
<leeward>
shakesoda: Do you use Go at all?
<pixelherodev>
Go has much better resource consumption than other compilers I've used IIRC
<shakesoda>
no, haven't been compelled to do so
<fengb>
Go compiler is pretty fast
<leeward>
It's a design goal for the language.
layneson has joined #zig
<pixelherodev>
Go is a C-ish language which has a pretty good compiler, might be worth giving it a shot (if it supports Pi)
<leeward>
gccgo supports everything.
<pixelherodev>
but is gcc.
<leeward>
meh
<fengb>
Go has native arm support
<pixelherodev>
phew
<fengb>
I think that's the extent of native support though
<pixelherodev>
oh and
<pixelherodev>
leeward: false
<fengb>
Arm and x86
<pixelherodev>
GCC doesn't support "everything"
<pixelherodev>
Not by a long shot
<pixelherodev>
GCC + LLVM put together have *decent* coverage, but not great
<ifreund>
doesn't support the SPU II for one :D
<leeward>
pixelherodev: Weren't we talking about raspberry pi? I didn't intend to claim GCC supports building for rocks.
<shakesoda>
the coverage between them is quite a lot more than hardware i actually own
<leeward>
Yes, context sometimes matters when communicating with humans.
<pixelherodev>
Okay, both of them, but only because I can't just raise *one*, it doesn't work like that
<fengb>
I think last time I cross compiled a Go program to my arm box just fine
<shakesoda>
i generally assume "everything" to mean the usual suspects
<shakesoda>
mips/arm/x86/maybe power
<pixelherodev>
Anyways, going to spend about 90 minutes on stage2 now :D
craigo has quit [Ping timeout: 256 seconds]
<pixelherodev>
Really just need to define the address space, I think
<leeward>
I love how easy it is to use optionals with C code. Zig really nailed that.
<pixelherodev>
Definitely
* pixelherodev
hasn't actually tried but that's not the point
xackus has quit [Ping timeout: 260 seconds]
<ifreund>
yeah, i just do `orelse return error.Crap;` after every C call that might return null
decentpe1 has joined #zig
decentpe1 has quit [Client Quit]
layneson has quit [Ping timeout: 246 seconds]
marnix has quit [Ping timeout: 240 seconds]
<pixelherodev>
hmm, the question is how to decide default memory model
decentpenguin has joined #zig
<pixelherodev>
andrewrk: should I have @import("builtin") have a memory model the same way it has CPU / OS / etc, or is it better to define it manually in std.Target per-architecture (or per-triple?)?
ur5us has joined #zig
<pixelherodev>
gah, I need to stop the bikeshedding, it cna be changed later, better to just have something in place now
<andrewrk>
I can't really answer a lot of these questions without a deep dive into the code, which I will have to do anyway for pull requests. so better to guess the answer, come up with something that works, and type up a nice explanation in the PR
* pixelherodev
nods
<pixelherodev>
I'm really starting to hate stage1
<pixelherodev>
Memory usage is *insane*
KKRT has quit [Quit: KKRT]
Akuli has quit [Quit: Leaving]
<pixelherodev>
I have 8GiB of RAM, stage1 is the only program that has *ever* pushed me down to less than 3% of RAM *available*
<pixelherodev>
I average ~6.5GiB free at any given moment, the worst case I have outside stage1 is *maybe* 4GiB free
cole-h has quit [Quit: Goodbye]
<leeward>
I find it amazing that we've found something to do with our gigabytes of RAM. Software is a gas.
<shakesoda>
chrome regularly eats >90% of my 16gb
<shakesoda>
it fills to eat as much as is possible
<pixelherodev>
Hence, I don't use Chrome :P
<leeward>
gas: expands to fill container
<shakesoda>
firefox does it too
<shakesoda>
less severely, granted
<leeward>
Firefox is worse.
<pixelherodev>
I use qutebrowser
<andrewrk>
pixelherodev, well, you could backport the new decl based memory management model to stage1 if you want :P
<pixelherodev>
Which is chromium-based
<companion_cube>
slack is the worst
<pixelherodev>
But I've never even hit 1GiB
<shakesoda>
nah, firefox doesn't eat ram quite as bad as chrome does... but it's not really that far off
<leeward>
Slack is definitely the worst.
<shakesoda>
in my usage, that is
<pixelherodev>
How many tabs do you guys typically have open?
<shakesoda>
"a lot"
* leeward
goes and counts...
<leeward>
Nope, not happening. Many.
<shakesoda>
tabs are my external memory
<pixelherodev>
andrewrk: no thanks, I'd rather get CBE up to the point where we can have "stage 1" be as good as a binary blob
<shakesoda>
the internal memory doesn't work so well :D
<pixelherodev>
See, I have, at *most*, five tabs open at a time
<pixelherodev>
Tops.
<shakesoda>
yeah i can't even function with only 5 tabs
<pixelherodev>
If I need to remember something, I mark it down in a plain text file
<shakesoda>
i think i currently have around 100
<pixelherodev>
Well, don't complain that your browser is using too much RAM then
<pixelherodev>
:P
<shakesoda>
why wouldn't i? it's ridiculous that it can't handle that
<pixelherodev>
That's a hundred pages of HTML + DOM + potentially *thousands* of massive scripts
<shakesoda>
my computer has such an obscene amount of resources versus the needs of such a list
<pixelherodev>
Not really
<shakesoda>
and the browser can unload things at will
cole-h has joined #zig
<leeward>
46 tabs on this window...5 windows open, one of which only has a few. Call it 200?
<pixelherodev>
There's probably hundreds of malware scripts abusing your computer right now :P
<shakesoda>
also, i run noscript
<pixelherodev>
on chrome?
<pixelherodev>
huh
<shakesoda>
yes
<leeward>
chromium
<pixelherodev>
Same difference
<pixelherodev>
It's not all that degoogled
<leeward>
It may as well be opera or edge or safari.
<shakesoda>
fwiw, safari handles this same type of load dramatically better than either chrome or ff
<shakesoda>
(ipados safari, slightly more specifically)
<pixelherodev>
See, I don't even have a web browser open all that often
<shakesoda>
it has no problems whatsoever either keeping track of hundreds.
<leeward>
Yeah, a gigabyte is way more than any but the video tabs should ever need.
<shakesoda>
s/either//
<pixelherodev>
I often just use w3m
<pixelherodev>
So make a simpler browser
* pixelherodev
shrugs
<pixelherodev>
If you're not bothering with 100% compatibility, you can probably get decent support by taping together existing components
<pixelherodev>
e.g. Duktape for JS
<leeward>
My time is worth more than my RAM.
<companion_cube>
quickjs
<leeward>
Like, a lot more.
<pixelherodev>
Heck, if you only support HTML4 + older JS + older CSS, you can probably actually make one in a reasonable time frame, and tell all the new standards to a*##$*&@(! off
<shakesoda>
i'm not making a damned browser lol
<pixelherodev>
Heh
<shakesoda>
been there done that
<pixelherodev>
You'd have to pay me to make one
<pixelherodev>
Like, I'm insane, but not *that* insane
<pixelherodev>
I'm low-level insane, not high-level abstraction BS insane
<shakesoda>
i implemented a decent subset of one some years ago before scrapping it for being not worth the trouble
<shakesoda>
i suspect what i actually want is to just run chrome in a ram limited container
<shakesoda>
or firefox in the same
<pixelherodev>
Hmm, I wonder how hard it'd be to go back and fork an older Firefox / Chromium, backport security fixes, optimize for performance, and then only ever backport security fixes?
FireFox317 has quit [Remote host closed the connection]
<leeward>
hard
<shakesoda>
that's just palemoon
<leeward>
like, more work than I want to put in
<pixelherodev>
Yeah no, it'd be easier to just support HTML4 and call it a day
<pixelherodev>
Heck, it'd probably be easier to convince people to switch to Gemini lo
<pixelherodev>
lol*
<Sahnvour>
you probably wouldn't go very far with old html/css/js on the modern web, unfortunately
<leeward>
Pages *ought* to fail gracefully; that's the whole point of HTML5 instead of flash, but...you're probably right.
<andrewrk>
I just ran out of 32GiB of RAM trying to link a llvm 11 debug build with `ninja`
<shakesoda>
i wish tree style tab weren't nerfed on modern versions of firefox :(
<shakesoda>
top tabs blow
<pixelherodev>
I wish e.g. seamonkey was actually *good*
<companion_cube>
the serenityOS guy does his own browser 🙃
<pixelherodev>
Yeah, I pity him
<pixelherodev>
Wastes so much of his life...
<pixelherodev>
says me.
<andrewrk>
waste?
<Sahnvour>
andrewrk: lld ?
<andrewrk>
Sahnvour, nah I'm using system ld
<pixelherodev>
Writing your own browser is a waste of time IMO, but I also have no room to talk
* pixelherodev
has attempted to write his own kernel
<Sahnvour>
ha
<pixelherodev>
And thus given up the right to ever seriously say anything about wasting time :P
<shakesoda>
to be sure, andrewrk wrote his own language
<shakesoda>
wasted so much time that we're even USING IT
<leeward>
Sahnvour: Actually, Dillo renders my quick sample pretty well.
<andrewrk>
we didn't ask to be born, and nobody gave us a purpose. it's up to us to decide what to do with our own time
<pixelherodev>
... leeward: I misread that for a second. Very, very misread that.
<ifreund>
and nothing matters, which is awesome
<pixelherodev>
andrewrk: for sure!
<Sahnvour>
I wish I had time to "waste" doing stuff like the serenity os guy :)
<pixelherodev>
Optimistic nihilism woot!
<shakesoda>
i'm not really much a believer in the concept of time being wasted just you did something for interest rather than need
<pixelherodev>
... hmm, I think my ZLS is broken :(
<pixelherodev>
sadface
* leeward
doesn't update.
<Sahnvour>
leeward: didn't know about Dillo, seems unmaintained though ?
<shakesoda>
i only update every now and again
Ashpool__ has joined #zig
<shakesoda>
it works right now, so i'm not touching it
<leeward>
Sahnvour: Not sure maintenance matters on a browser with basically no features, but...it's still in Debian so there must be someone keeping the package going.
<pixelherodev>
I didn't update either
<Sahnvour>
depends on the level of finish of the project I guess
<pixelherodev>
:(
<pixelherodev>
I tried to but couldn't lol
* leeward
registers for notification on message "ZLS is fixed"
<pixelherodev>
leeward: Dillo?
<leeward>
Description-en: Small and fast web browser
Ashpool_ has quit [Ping timeout: 240 seconds]
<pixelherodev>
Real description: not usable?
<leeward>
Usable enough to browse wikipedia.
<companion_cube>
fast and simple C++ compiler
<leeward>
Its installed size is less than 500k.
<pixelherodev>
hmm
<pixelherodev>
So, graphical w3m?
<leeward>
basically
<companion_cube>
the css support is indeed quite limited :D
<leeward>
If your web site is browsable with dillo, it might be ok with a screen reader.
<companion_cube>
it's not so bad indeed!
<ifreund>
there's also Netsurf which is actively developed
<leeward>
Isn't that the BeOS browser, but ported?
<leeward>
Great, found a heisenbug. When I try to step to it in the debugger things work fine. Run it normally and it deadlocks.
<pixelherodev>
I hate those.
<shakesoda>
classic
<ifreund>
don't think so? it seems to be targeted at RISC OS primarily
<leeward>
Yeah, it managed to reproduce my bug in a way that lets me attach a debugger...I'm very pleased.
<shakesoda>
rr looks pretty amazing
<fengb>
Zig is aligned because it’s a part of the type 🙃
<leeward>
Isn't there a setting for @align(shakesoda)?
<shakesoda>
given how zig syntax is that'd probably be a .shakesoda would it not
<shakesoda>
depending on what i truly am
<companion_cube>
shakesoda: where is it not aligned?
<pixelherodev>
fengb: heh
<ifreund>
idk, i'd expect it to be something like `const shakesoda = 42; ... @align(shakesoda);`
<shakesoda>
ifreund: reasonable
<pixelherodev>
That doesn't really make sense
<pixelherodev>
You can't *change* the alignment of a *value*
<ifreund>
align taking an enum literal would be strange :P
<pixelherodev>
@align *existing* wouldbe
<shakesoda>
companion_cube: various minor syntax things (some of which are slated to be solved, such as 1717), i've got a bit more of a distaste for generics and the standard library has massively more than i can keep track of
<shakesoda>
that kind of stuff
<pixelherodev>
You can't retroactively change a value's alignment
<pixelherodev>
That doesn't make sense
<pixelherodev>
You'd have to reallocate it in memory
<fengb>
@alignCast(shakesoda, a_value)
<ifreund>
oh yeah @align() totally isn't a thing
<pixelherodev>
That changes that alignment of a *pointer*
<pixelherodev>
Rather, it treats the pointed value as a different alignment
<pixelherodev>
It doesn't actually change the alignment
<fengb>
@alignCast(pedantic, phd)
<companion_cube>
shakesoda: I meant for rust
<pixelherodev>
In release mode, it's a nop.
<pixelherodev>
fengb: I'm not *aligned* with pedancy, it's intrinisic to my nature - my *type*, perhaps?
<pixelherodev>
:P
<ikskuh>
var pixelherodev: std.human pedantic = undefined;
<pixelherodev>
Hmm, I'm not sure pedantic is a valid keyboard
<pixelherodev>
(sorry, I can't help but play into the joke)
<pixelherodev>
s/board/word
<shakesoda>
companion_cube: uh that's gonna be too big for an irc message but the very ground it stands on is things i do not want in my life. i don't want the borrow checker, it has lots of cryptic constructs, i largely don't like the ecosystem, it's just extremely too complex etc
<shakesoda>
it is not without good ideas i can get behind, but it's really not my thing
<shakesoda>
i just outright do not like using it.
<companion_cube>
ah well, ok
<companion_cube>
personally I like the defensive style and the expression-based aspect
<shakesoda>
i really, really hate the common patterns of chaining a bunch of stuff
<companion_cube>
you mean x.f().g()?
<shakesoda>
yeah.
<companion_cube>
oh.
<shakesoda>
i'm generally fine with defensive coding, although rust is *obsessed*
<shakesoda>
zig's the right amount of defensive for me
<leeward>
Zig strikes a nice balance. It's easy to ensure that errors lead to crashes without spending mental effort.
<leeward>
Rust is really obsessed with a particular class of error, which most languages don't even consider.
<ifreund>
^
<ifreund>
it doesn't even handle OOM
<shakesoda>
leeward: it's also a particular class of error that barely even registers on what i actually have to deal with day to day
<companion_cube>
you never have race conditions?
<companion_cube>
leeward: I really disagree
<companion_cube>
it's obsessed with memory errors, which most languages are shielded from because they have a GC
<ifreund>
rust does not solve race conditions in general, only data races
<companion_cube>
sure, that's a lot of races
<shakesoda>
i certainly run into them sometimes, but they're *deeply* far down the list of things that actually take up my time.
<leeward>
companion_cube: disagree that most languages don't consider it?
<companion_cube>
yes, it's more that most languages don't have the problem because they are too high level
<leeward>
GC doesn't solve data races. It's easy enough to make one in Python, for example.
<companion_cube>
rust is aimed at the kind of problem where you use C++, and there, memory errors are plenty
<shakesoda>
i write c and c++
<shakesoda>
the things rust obsesses over are not even close to the level of relevance to me that its design would lead you to believe they could be
<leeward>
The problems Rust is obsessed with are problems that arise from state that's both shared and mutable. GC doesn't have anything to do with those.
<companion_cube>
it's also a question of memory layout, leeward
<shakesoda>
they certainly exist, and rusts certainly solves the lion's share of them, but the amount of brain space they occupy is almost nonexistent when i don't use rust, heh
<companion_cube>
if you have flat memory layouts + references it becomes hairy
<companion_cube>
most GC languages don't give you that
<companion_cube>
shakesoda: I certainly appreciate not to have to use gdb :)
<companion_cube>
(most of the time)
christianbundy has quit [Quit: WeeChat 2.9]
<shakesoda>
races are hardly the only issue a debugger is helpful for
<shakesoda>
but honestly i usually print debug first
<leeward>
I'm not convinced. Iterator invalidation is a thing you can do in most GC'd languages.
<shakesoda>
depending on if what i'm debugging is going to give me a million lines of output or not if i do that
<leeward>
I find print debugging to be strictly inferior to gdb, but I go through a lot of effort to make sure I can use gdb really easily.
<shakesoda>
of course it's inferior, but it's usually fast/easy/adequate
<leeward>
I mean on the fast/easy axes too.
<companion_cube>
depends on what kind of bug you're tracking
<leeward>
It might also be related to the kinds of programs I debug.
<companion_cube>
print debugging is nice for logic errors
<companion_cube>
shakesoda: I only use gdb for segfaults, tbh
<shakesoda>
almost all real issues i need to spend time with are logic/math errors
<companion_cube>
and there I find rust is very nice, with sum types and everything
<companion_cube>
(it's not just the borrowchecker)
<companion_cube>
but then I'm used to ML…
<shakesoda>
companion_cube: i fire up debuggers whenever it's going to be less effort to start stepping through a problem than it will be to just print a couple values
<companion_cube>
assuming the problem arrives quickly enough, yeah
<leeward>
I appreciate the amount of stuff Rust took from the FP world, but it's hard to argue that it exists is anything but the borrow checker.
<andrewrk>
skipping the recompilation step can be a big deal if compilation is slow
<andrewrk>
self-hosted zig's fast recompilation will be a boon for printf-style debugging
<shakesoda>
absolutely
<companion_cube>
leeward: well, given that C++ still isn't there for these features …
<leeward>
I will be approximately 0 shocked if C++25 has a borrow checker.
<shakesoda>
companion_cube: i'm not too into fancy types
<leeward>
C++ has sum types (they're awful to use)
<companion_cube>
sum types are not fancy :/
<shakesoda>
c's types are most of what i want to begin with (dumb views of bytes)
<companion_cube>
sometimes that's all you need, sure
<companion_cube>
like if you write interpreters or disassemblers :p
<shakesoda>
that sometimes is almost all of my practical usage
dermetfan has quit [Ping timeout: 246 seconds]
<ifreund>
the one thing I miss in C is nice tagged unions. Zig solves that
<companion_cube>
yeah, zig and rust
<companion_cube>
C++ still doesn't afaik :s
<companion_cube>
currently the only 1.0 lang that I know of and that has this kind of convenience, is rust…
<leeward>
I'm pretty sure C++ does...
<companion_cube>
safe tagged unions? wut
<ifreund>
yes c++ has std::variant
<shakesoda>
i think the only thing zig doesn't have as far as types is something equivalent to haxe's abstracts. i think rust also has an equivalent
<leeward>
companion_cube: "safe" and C++ are incompatible words.
<shakesoda>
in zig i have to use a single data member struct
<companion_cube>
ifreund: but you don't have an explicit tag, do you?
<companion_cube>
you have to test if the variant you expect is in there
<companion_cube>
like, if you can't switch on it, it's unbearable :p
<companion_cube>
leeward: yeah
<leeward>
Like I said, awful to use but it exists.
<companion_cube>
tagged by integers… that's just too terrible
<companion_cube>
(seems like std::variant is enough, indeed; it's c++17 which i never looked at too much)
<shakesoda>
i have yet to move beyond c++11
<leeward>
You mean C++0xb?
<ifreund>
companion_cube: you're also forgetting e.g. haskell
<leeward>
That joke used to be way funnier.
<companion_cube>
ifreund: I mean, low level.
<companion_cube>
otherwise I have ocaml, thank you very much :p
<leeward>
OCaml?
<leeward>
Yeah
<shakesoda>
ocaml is terrifying
<shakesoda>
i can't even vaguely comprehend it
<leeward>
My biggest speed bump with ocaml is the completely empty standard library.
<companion_cube>
variants cannot hold void <--- ugh.
<shakesoda>
my biggest speed bump is every single aspect of it
<leeward>
I don't want to implement max myself.
<companion_cube>
leeward: it's not that empty, and you have stdlib extensions
<companion_cube>
(max is there though?!0
<shakesoda>
i can more readily understand foreign languages i do not know than any logic in ocaml
<leeward>
I didn't find it last time I looked, but that was many years ago.
<companion_cube>
shakesoda: what's so bad?
<shakesoda>
companion_cube: it's incomprehensible
<shakesoda>
it isn't even a specific thing
<shakesoda>
it's like trying to read wingdings
<leeward>
FP is for the differently brained?
<companion_cube>
leeward: Stdlib.max :)
<companion_cube>
shakesoda: well you have functions and values, and you can apply functions to values
<shakesoda>
companion_cube: i think you're a few steps short on the level of incomprehensible it is to me
<companion_cube>
:D
<shakesoda>
of course there are functions and values. it is a seemingly random jumble of symbols
<companion_cube>
ah, the syntax.
<shakesoda>
it is clearly organized somehow
<shakesoda>
i have yet to determine how
<companion_cube>
well, you have `let x = … in …` as the core way of doing local bindings
<leeward>
companion_cube: Maybe I'll look at it again. You're obviously right about max.
<companion_cube>
it's like `const x = …; …`
<leeward>
Shouldn't there be {}s in that const example?
<companion_cube>
leeward: I have my own stdlib extension, though, cause as you said the standard one is not too big (but not incredibly small either)
<companion_cube>
possibly, it does create a scope for each `let`
<shakesoda>
side note: i like that this is one of the only places around where several people can disagree about languages without it also causing heated arguments/flamewars
<companion_cube>
shakesoda: also, Reason is an alternative syntax that might look less alien (kind of javascripty) but still maps to it 1-to-1
<shakesoda>
companion_cube: yeah, that's quite significantly less alien
<rom1504>
it's quite useful to learn a functional language, to broaden your view on languages, even if you're not going to really use it for anything
<leeward>
Civil discourse ftw!
<companion_cube>
\o/
<shakesoda>
it's not like i'm ideologically opposed to fp languages. ocaml is just alien runes :D
<leeward>
Personally, I think Erlang is a great way to dip a toe into the FP waters without getting overwhelmed with category theory.
<companion_cube>
category theory really is only a thing for some haskellers who want to believe they're mathematicians
<companion_cube>
no one else cares
<fengb>
Erlang is very different from Haskell/ML
<companion_cube>
(now, erlang has a weird syntax!)
<leeward>
I don't mind Erlang's syntax.
<leeward>
It's easy to learn, just comes from a different family.
<fengb>
Or learn Elixir :P
<companion_cube>
I'm kind of waiting for gleam :-°
<shakesoda>
elixir looks ruby-esque
<companion_cube>
I want my types
<shakesoda>
severely enough that it is *definitely* not a coincidence
<fengb>
It’s not
<pixelherodev>
My list of languages all programmers should learn currently consists of C, Forth, Java, Lua, and Assembly - mostly because each offers a unique enough (compared to the others) set of idioms
<fengb>
Jose Valim was a former Ruby dev
<pixelherodev>
It makes it much, *much* easier to pick the right tool for the job this way
<pixelherodev>
I still need to make a Cyclopropatriene Forth :P
<shakesoda>
lua is, without question, my favorite language
<pixelherodev>
... that name is still so much more fun than Tricarbon but I really shouldn't use it
<companion_cube>
wait, you know lua and can't learn OCaml, shakesoda?
<companion_cube>
I mean, you already have all the crazy lexical scoping and lamdas in lua
<companion_cube>
so it's really just syntax, hmm
<fengb>
Huh? Lua syntax is very straightforward
<companion_cube>
I mean, the concepts
<fengb>
And it’s just a JavaScript in disguise :P
<companion_cube>
if you're used to juggle `function` and `local` everywhere, it's the same as OCaml's `fun` and `let`!
<leeward>
pixelherodev: Add a lisp variant to that list, and something designed for concurrency.
<companion_cube>
dump lua, add scheme!
<pixelherodev>
leeward: good call
<shakesoda>
i think lua's a good one for the list, though
<shakesoda>
aside from it being my favorite, the way you interact with data is very unique to lua
<shakesoda>
as tables do not give a crap about anything
<shakesoda>
it just works
<shakesoda>
also, lua's really small (standard library and all)
<leeward>
Python is ubiquitous. Hard to avoid
<companion_cube>
scheme even more, everything is lists
<companion_cube>
(I'd say it's nice to learn at least one language where recursion is the natural way of doing things)
<shakesoda>
pixelherodev: which assembly
<shakesoda>
the experience will be very different depending on the answer
<fengb>
x86
<shakesoda>
oh those poor souls
<fengb>
Go big or go home :P
<pixelherodev>
Hmm.. SPU II ;)
<companion_cube>
I should write a wasm interpreter some day
<pixelherodev>
z80 is nice, too
<pixelherodev>
companion_cube: hmm, is there a good WASM JIT in Zig yet?
<pixelherodev>
Maybe I'll tricarbon one
<pixelherodev>
This is English, so I can verb that
<companion_cube>
I have no idea
<fengb>
Speaking of which, maybe I should actually get my interpreter working
<pixelherodev>
Heh
<fengb>
I verified it runs noop correctly
<pixelherodev>
lol, nice
<pixelherodev>
Hmm, is there a good wasm spec?
<fengb>
1 instruction ought to be enough for everyone
<pixelherodev>
SUBLEQ or GTFO
<shakesoda>
reminds me of, i think was doom, recompiled to use only mov
<pixelherodev>
Yep
<fengb>
I have a few docs as reference
<pixelherodev>
movfuscator or something
<pixelherodev>
fengb: link me?
<fengb>
As usual the official spec is pretty unreadable