<diltsman>
Stupid question, is there a way to specify a function that will be used unless the function is defined elsewhere? My particular usecase is an interrupt handler. I would like to provide a default no-op and then override elsewhere if it is actually used.
fengb35 has joined #zig
<daurnimator>
diltsman: are you looking for @export with a weak linkage?
fengb has quit [Ping timeout: 260 seconds]
<diltsman>
daurnimator: possibly. Will it keep the linker keep the weak function if there is a strong definition?
<hryx>
diltsman: to wit, you could either provide an init function which takes an optional function pointer, or use something like `if (@hasDecl(@import("@root"), "customInterruptHandlerFunction")) ...`
<hryx>
caveat, I'm not actually sure if that second one would work, I've never tried it
<diltsman>
Cool. Thanks.
<daurnimator>
diltsman: I think the answer to that changes based on shared vs static and depends on the target
<diltsman>
Makes sense.
<diltsman>
Given that the weak function would be an empty function, it is not a deal breaker either way.
<daurnimator>
diltsman: weak linkage vs hryx's root file suggestion: it depends if you want to override it from zig or from your linker scripts/when mixing object files with e.g. C
<diltsman>
Overriding from Zig is fine, given that the entire thing is written in Zig.
ltriant has joined #zig
kristoff_it has joined #zig
ltriant has quit [Ping timeout: 248 seconds]
kristoff_it has quit [Ping timeout: 272 seconds]
<emekankurumeh[m]>
zig's grammar isn't context free is it?
<emekankurumeh[m]>
why do people even like regex?
ltriant has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
darithorn has quit [Quit: Leaving]
fengb35 has quit [Remote host closed the connection]
<mikdusan>
IntoxicatedHippo: i think there's an issue with `var array3 = [1]S{ S{ .x = 5 }, } ** 2;`
<IntoxicatedHippo>
mikdusan, I just worked that out, `var array3 = [2]S{ S{ .x = 5 }, S{ .x = 5 }, };` works as intended
<mikdusan>
if you manually size it `[_]S{ S{ .x = 1 }, S{ .x = 2 }};`
<mikdusan>
yeah that's what i found too
kristoff_it has joined #zig
ltriant has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
avoidr has quit [Quit: leaving]
avoidr has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brakmic has joined #zig
<ffddr>
Hi! Is there some ready to use lib to parse json to an arbitary struct? I fill that this should be doable with std.json and something like std.io.Deserializer, maybe it was done somewhere?
brakmic_ has joined #zig
brakmic_ has quit [Client Quit]
brakmic has quit [Ping timeout: 245 seconds]
brakmic has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
<emekankurumeh[m]>
no, that would depend on something like @reify
<daurnimator>
emekankurumeh[m]: why?
<daurnimator>
emekankurumeh[m]: e.g. as an API, you could provide a struct, and you would parse json *into* that type.
<IntoxicatedHippo>
Doesn't @field only work at compile time?
<ffddr>
I guess it works in runtime while argument is comptime string
<IntoxicatedHippo>
Oh, I thought `field` was the field name from the json
<IntoxicatedHippo>
I'd have an init function in that struct that creates a hash table mapping struct field names to fields so you can parse the json serially rather than loading it all in to memory
mixi has quit [Remote host closed the connection]
mixi has joined #zig
Pwipwi has joined #zig
<ffddr>
hm, will the std.json.Parse.parse load the entire json anyway?
<Pwipwi>
how can I get argv ?
<IntoxicatedHippo>
it supports field lookup so it either scans the entire string each time or loads the structure in to memory
<Pwipwi>
I see there's an argiterator in os
<Pwipwi>
but isn't there something more simple that gets us a [][]const u8 ?
<IntoxicatedHippo>
std.process.argsAlloc and argsFree
<ffddr>
IntoxicatedHippo: hm, I dont quite understand your idea :( If deserialize is going to return T, it probably will need to load entire json anyway. I dont see how hashmap with struct field will help there :(
<IntoxicatedHippo>
Something like this:
<IntoxicatedHippo>
for field in json:
<IntoxicatedHippo>
if field.name in struct_fields:
<IntoxicatedHippo>
An example of when it would help: If you have a json string that you want to parse in to an array of structs, loading the entire structure of the json string in to memory will use a lot more memory than just stroing information about the one zig struct
<Pwipwi>
IntoxicatedHippo, I can't find std.process ?
<ffddr>
I see, in this way we can feed std.json byte by byte, get the new tokens and put it to the fields without any additional memory
<IntoxicatedHippo>
exactly
<IntoxicatedHippo>
Pwipwi, std.os.argsAlloc in Zig 0.4.0, it's been moved in master
<Pwipwi>
ah ok, thank you
<Pwipwi>
in general, is it recommanded to stay on master ?
<ffddr>
and parseAs is a great idea also, with moving parsing to parseAt function :)
<Pwipwi>
why do we have to go through copying all the arguments to get them ?
<Pwipwi>
aren't argv and argc given already ?
<Pwipwi>
to the process I mean
<Pwipwi>
I don't understand why more memory is to be allocated
<Pwipwi>
and copied
<IntoxicatedHippo>
You can use std.os/process.args() which returns an ArgIterator
<IntoxicatedHippo>
argv doesn't exist on a lot of the platforms zig supports
<Pwipwi>
but for those where it does, it seems a little convoluted :-|
<hryx>
It's generally important to provide a platform-agnostic API. Providing a second, simpler interface that only worked on some platforms would be redundant and encourage writing unnecessarily OS-specific code
<hryx>
and providing more than One Way To Do Things is un-zig
Pwipwi has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
trinityhex has quit [Ping timeout: 276 seconds]
Pwipwi has joined #zig
Pwipwi has quit [Remote host closed the connection]
avoidr has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 245 seconds]
Tetralux_ is now known as Tetralux
<Tetralux>
Here's a question
<Tetralux>
A hypothetical
<Tetralux>
Suppose you have a big codebase, writte in Zig.
<Tetralux>
You want to profile it to find which procedures are called most often, and how long they take, etc.
<Tetralux>
In Jai, (I'm sorry) the metaprogram can be instructed to automatically insert the necessary code into the top and bottom of every function to measure how long it takes to run at compile time without modifying the actual source code - even with stdlib procedures.
<Tetralux>
My guess would be that in Zig, the status quo is that you do the same as C: Manually write the instrumentation code.
<Tetralux>
Is this true, and is this the way Zig will ship with?
<scientes>
Is there an easy way for be to debug build failures on OSX and Windows but not Linux?
brakmic has quit [Read error: Connection reset by peer]
fengb has joined #zig
<fengb>
Tetralux: that'd be "aspects" or "function decorators". I don't think that'll ever happen automatically since it's very much not explicit, but I'd like to see something like function decorators
<fengb>
The challenge is how do you write "come from" code without being magical
<fengb>
I guess arguably we don't need it since you can do something like `const profile = Profile.start(); defer profile.end()`
<Tetralux>
For reference, in Jai, you'd have a constant variable (eqiv to const PROFILE_FNS = false) that you'd toggle in order to activate the insertion of instrumentation code.
<fengb>
Yes I know how it works. It's just magic control flow that Zig abhors
<fengb>
You can't see it happen in the function body
<Tetralux>
I'd argue that you don't need to - and in fact - shoudn't.
<Tetralux>
It's not part of the function, that it is being profiled.
<Tetralux>
You _don't want_ the function to know that.
<fengb>
But it's not obvious it's happening
<Tetralux>
It is.
<Tetralux>
Because you activated it.
<fengb>
Not looking at the code
<fengb>
At a large codebase, you can't tell where all of these "aspects" are happening
<Tetralux>
Not looking at the procedures being instrumented, no.
<Tetralux>
But looking at the variable that turns it on, you would.
<fengb>
Not talking about just instrumentation
<fengb>
Zig also doesn't like "language only" features
<Tetralux>
This variable is probably in the same file as the entry point.
<fengb>
So something like this would probably be available in userland
<fengb>
e.g. logging
<fengb>
Debuggers?
<fengb>
There's a lot of styles this would enable, but it'd also be a pain to debug later since any function at any time could have arbitrary code happening somewhere else in the codebase
<Tetralux>
*scowls*
<Tetralux>
"Abitrary" is quite a stretch.
<Tetralux>
It's known what the code is.
<Tetralux>
And it's probably even as a string in your program.
<fengb>
So... only profiling can be done this way?
<Tetralux>
Obviously not.
<Tetralux>
But if you wanted to profile you'd toggle that variable; if you wanted to count the number of variables that start with an underscore, you toggle that variable, or whatever else you want.
<fengb>
So how do you limit what's done. And which ones to run for what function
<Tetralux>
The point in Jai _is_ that there is no limit.
<Tetralux>
But also
<Tetralux>
Jai has what it calls "notes"
<Tetralux>
like
<fengb>
Yeah that's sort of my point. If there's no limit, this can just happen. For "reasons" unclear to the current control flow
<Tetralux>
(the equiv of...)
<Tetralux>
fn doLongThing() @NoProfile { ... }
<Tetralux>
In Jai, it'd look like this:
<Tetralux>
doLongThing :: () @NoProfile {...}
<Tetralux>
And the @NoProfile thing is a metaprogram accessible thing.
<fengb>
Those are annotations
<Tetralux>
Indeed.
<fengb>
I guess I was confused when you said "automatically"
<fengb>
I assumed "at any point without any reference"
<Tetralux>
*grins* No, I didn't mean that.
<fengb>
Yeah I think annotations are a good thing
<Tetralux>
Although, you could use rand() in the metaprogram to do that if you _really_ wanted to. xD
<Tetralux>
But you wouldn't do that.
<fengb>
But it's more obvious you're deferring control flow to _something_
<fengb>
I don't want control flow redirected automatically ever
<Tetralux>
You mean when you do const x = Profile.start() etc?
halosghost has joined #zig
<fengb>
Well... not in Zig. I'm happy to make concessions in other languages :P
<Tetralux>
I should note, that the code you'd insert via the metaprogram would _not_ create a function call.
<Tetralux>
It would be exactly the code you chose to insert - be it a call or just imperative statements.
<Tetralux>
But yes - the point is that it allows the code to not even think about profiling, and still be able to profile trivially.
<Tetralux>
The metaprogram would not be hard to write.
<Tetralux>
And you can turn it on and off at will.
<fengb>
C is just full of errors waiting to happen :/
<scientes>
oh god
<scientes>
but in zig that would be a compile error
<scientes>
then you would add "try"
<scientes>
and then it would be correct
<fengb>
I'm just trying to port this and I might have to spend more time fixing bugs than getting this to work
<scientes>
you might want to be an asshole and make a list of all the errors you fix
dimenus_ has joined #zig
<fengb>
Well... I'm the asshole that's rewriting this in Zig and exporting a C compatible version :P
<scientes>
exactly, so better do it properly
<scientes>
and publicly post all the suck in the orig.
<fengb>
lol
<gonz_>
Would a PR count as that? :P
<scientes>
no this is even better
<tgschultz>
he's right, it'll be a good example of how zig brings value over C
<fengb>
Actually that's a pretty good point. Maybe I should document and write a blog post
<gonz_>
Given a very low smugnesslevel I'd agree
<fengb>
I didn't even intend to fix anything. I just don't wanna deal with a C api
<fengb>
And this isn't too long of a program. Just scratching my own itch
<gonz_>
I'm not sure the "here's how our language fixes the issues in yours" strategy is what's worked before
<companion_cube>
it's good advertisement for Zig, but not that helpful for people attached to C
<gonz_>
Rust seems to attract people who mostly weren't interested in low level programming before, not C++ users
<companion_cube>
people whose pain threshold was too low for C++
<gonz_>
So I guess everyone who's like "I want something simple but I don't know that C is the language I'm looking for" would be the target for something like that.
ltr- has joined #zig
<fengb>
The error handling is elsewhere. It's not non-existent... it's just far away
<fengb>
I think it's because Rust is the only major non-GC language with modern features, and a systems language that's vaguely ML-like
<tgschultz>
Even people who like C a lot recognize it has flaws, I don't think pointing out how zig has dealt with those flaws is the same as smuggly beating up on the language.
<fengb>
Yeah, I only stuck with C so long because C++ is... not good
<companion_cube>
gonz_: except the pain threshold for C is super high too 🤷
<gonz_>
tgschultz: I think it's a good bet that most users of C++ know it has issues (many of them choosing not to use major parts of the language), but that hasn't really meant that good-natured "Hey, here are all the problems with your language that we fix" campaigns have succeeded
<gonz_>
I think Rust seems to have a great community internally, but their interaction outwards in general has been pretty awful.
<fengb>
How so?
<gonz_>
PRs amounting basically to "Rewrite in Rust?", the Rust Evangelism Strikeforce, etc.
<gonz_>
Smug, insufferable
<fengb>
Oh
brakmic_ has quit [Read error: Connection reset by peer]
<tgschultz>
well, zig has kinda already crossed that bridge by calling itself a "better C" hasn't it?
<tgschultz>
I'll agree about the evangelism, we don't want to go there
brakmic has joined #zig
<gonz_>
tgschultz: No, I think that attitude is very appropriate to have in a community. It's an ideal to strive for, with a lot of spirit and a certain set of ideas that go with it. Outwards it's a terrible attitude, however.
<fengb>
I think it's massively different to prove by example vs by proselytizing
utzig has joined #zig
<gonz_>
fengb: In the end it comes down to delivery and I think subtlety is key. Saying "Here's a PR with some robustness fixes that I noticed... while doing some zig stuff with the project, (check it out here)"
<gonz_>
I think zig is a good candidate for something that sells itself within a very short time once people get some exposure, given it's still (and hopefully will remain) small.
utzig has quit [Quit: leaving]
<Tetralux>
Just my two cents: don't put a link to the project; call it by name instead: 'Zig Programaming Language.'
<gonz_>
Even better, yeah.
<gonz_>
If people are interested, they'll find it and feel like it's something they to some extent discovered.
<Tetralux>
It's not like Zig's hard to find or anything - esp if you cutnpasted that into Google.
<gonz_>
If they're sold it by someone who begun the conversation by saying "Do you have some time to talk about our lord and savior Ctulhu?" it's harder to take it in, I think.
<gonz_>
Fun fact: I found Zig (again) when googling "nim programming language" and remembering the recurse center talk I'd seen before.
<gonz_>
It was the first result for that phrase
littleli has quit [Ping timeout: 245 seconds]
<gonz_>
I can't seem to reproduce it now, though
fengb has quit [Remote host closed the connection]
<tgschultz>
oh, I didn't catch that this was in the context of a PR, I would agree that isn't the place to talk about how zig improves upon C.
<tgschultz>
a blog post though
<euantor>
scientes: >Is there an easy way for be to debug build failures on OSX and Windows but not Linux?
<euantor>
Not sure, I don't think there's anything in place for that, easiest way would be to run a VM I guess
<scientes>
you can't even do that for OSX
<scientes>
OSX is finicky with the hardware it accepts
<euantor>
If you need access to a Windows 10 machine for a few days/weeks, I'd be happy to provide that
<scientes>
how does that even work?
<scientes>
I don't have enough bandwidth for screen casting
fengb has joined #zig
<fengb>
Microsoft actually recommends a workaround for their own 90 day limit
<scientes>
I'll just install a pirated Windows 7 VM
<fengb>
It's kinda funny
<euantor>
fair enough
<scientes>
its just a PITA
<fengb>
"These virtual machines expire after 90 days. We recommend setting a snapshot when you first install the virtual machine which you can roll back to later."
<andrewrk>
the answer to "should we support __ in zig?" is "no" unless there is a really compelling reason to do it
<fengb>
I'm looking at terminal escape sequences, and they look super foreign in hex
<fengb>
There's a decent number of old octal based stuff. Not sure if that's compelling enough since it's still representable
noonien has joined #zig
Akuli has joined #zig
<tgschultz>
does zig still support octal literals? if so, maybe we should support octal escapes... then again maybe we shouldn't support octal literals.
<companion_cube>
they're useful for file perms, right?
omglasers2 has quit [Quit: Leaving]
<Tetralux>
I've never used one, to be fair.
<Akuli>
if they are added, please don't use the 0755 syntax from c, make it 0o755 or something instead
<Akuli>
python 2 used the 0755 syntax, and they switched to the 0o prefix in python 3
<Tetralux>
I think we already have octal literals, and they are 0oXXX IIRC.
<Akuli>
hmm, but it wouldn't be too hard to create a comptime usable function that does octal("755")?
<companion_cube>
0o644 is much more clear indeed
<tgschultz>
I know we did have them, do we still? I vaguely recall something about removing octal literals.
<tgschultz>
the only time I have ever used them was with defining constants for linux API. That's probably the most common use case and I'm not sure it's a big enough one to jsutify it.
<Tetralux>
It always puzzled me why the didn't just make it an enum.
<andrewrk>
fengb, it's also possible to introduce your own string formatting function that supports octal
<Tetralux>
Why 755 has anything to do with permissions idk.
<Tetralux>
"It just does."
<Akuli>
you could do that with my octal() function too: const PERM_MASK = octal("777");
<Akuli>
755 is the default perm for folders
<Tetralux>
I was thinking more outside the box than that.
<companion_cube>
Tetralux: it's a bitmask with 4 bits for user/group/other? it makes sense
<tgschultz>
Tetralux, because it's a set of binary flags in 3 groups of 3, and old unix guys really hated typing.
<tgschultz>
it is 4 isn't it? oops
<Akuli>
hmm. how about a hex2oct function so that you can do hex2oct(0x755) or something :D
<Akuli>
tgschultz, no its 3
<Akuli>
hex is 4
<Tetralux>
See - "because old unix guyts really hated typing" sounds more like the reason I'd expect xD
<tgschultz>
mv, rm, cp...
<Tetralux>
Since it's a bit mask anyway... why would you not just have flags for it and be obvious about it?
<Tetralux>
You could even have a flag for READ+WRITE.
<companion_cube>
how do you write that in bash?
<Tetralux>
There's your first mistake *chuckles*
<Akuli>
bash supports 0755 i think
very-mediocre has joined #zig
<Akuli>
Tetralux, uh, you mean: ((READ|WRITE|EXEC)<<6) | ((READ|EXEC)<<3) | ((READ|EXEC)<<0)
<Akuli>
i don't want that :D
<Tetralux>
Not quite xD
<companion_cube>
😱
<Akuli>
there's ur 0o755
<Akuli>
or you know, compute the constants with bash and hard-code them into the code
<Akuli>
$ echo $((0755))
<Akuli>
493
fengb has quit [Remote host closed the connection]
<companion_cube>
yay for readability 🙃
fengb has joined #zig
<Tetralux>
There's three "blocks" in user perms
<Tetralux>
One is group, one is user, and the other is?
<Tetralux>
I forget.
<Akuli>
everyone else
<fengb>
We already have it for literals: 0o777. I meant as a string escape sequence
<Akuli>
ugo, user group others
<fengb>
"\x1B[?1000h"
<fengb>
That just looks weird
<Tetralux>
There's multiple ways you could have the interface.
<fengb>
I know its a convenience thing, but I've been subliminally accustomed to "\033"
<nrdmn>
why can't I return an enum(usize) with calling convention ccc?
very-mediocre has joined #zig
<andrewrk>
I think there is an argument to be made that since we have hex literals as "0x" and hex character escapes with "\x" and we have octal literals with "0o" then it would be consistent to have octal escapes with "\o"
<Tetralux>
ALL, ALL, ALL.
<Tetralux>
(.. Personally I'd use kwargs preferably.)
<halosghost>
is now a bad time to throw in my lot with the arbitrary-radix literal camp?
<halosghost>
:)
<fengb>
andrewrk: yeah that's what I meant. I'm only weakly proposing since it's not a blocker and I think it's just a historical quirk
<andrewrk>
nrdmn, I think there may be an issue for that. note that it requires a C extension to specify the integer size in a C enum
<Akuli>
i would be quite confused if i saw an octal literal in a string, in any language
<fengb>
Akuli: I don't disagree... but I've been using octals in Bash for 2 decades without realizing now
<Tetralux>
HAHA
<scientes>
octals need to die
<companion_cube>
I must say I just think of 3 separate digits
<scientes>
they only make sense with byte sizes other than 8 bits
<companion_cube>
ôO
<Akuli>
how about perms in binary? 0b111101101 for 0o755
<fengb>
Yeah I don't really get octals either. But they exist in the real world
<scientes>
oh well yeah permissions are naturally octal
<fengb>
lol
<Tetralux>
Akuli: Underscores in literals anyone?
<scientes>
but that is unusual
<Akuli>
that too
<Tetralux>
0b111_101_101
<companion_cube>
that's not too bad
<scientes>
Tetralux, go just added that syntax
<Tetralux>
I'd be annoyed if I couldn't do that in that situation.
<scientes>
but yeah its better than octal
<Tetralux>
scientes: Allowing arbitrary unders?
<scientes>
yes
<Tetralux>
Ah
<Tetralux>
Also
<scientes>
Tetralux, its actually 0b0_111_101_101
<Akuli>
new pythons allow underscores in literals too
<Tetralux>
I'd say it's better than octal, sure - I still have to know wtf each bit means though xD
<scientes>
don't forget the sticky bit
<scientes>
/ setuid bit
<fengb>
Wouldn't it make more sense to do a packed struct bitfield?
<Tetralux>
Part of me would like to pour super glue over all of this octal-file-perms business...
<nrdmn>
andrewrk: but I can return usize. Just not enum(usize)
<Tetralux>
...it is so short to type though..
<scientes>
well yeah unix file permissions are broken
<scientes>
although I don't get why no-one has promoted the obvious solution, that leaves the permission bits as-is
<scientes>
just have a groups be a DAG
<Tetralux>
wetf is DAG? XD
<scientes>
so groups can include other groups, and eventually point to users
<fengb>
scientes: but what about the 8 way merges? :troll:
<scientes>
<Tetralux> It looks like a linked list where each element can point at multiple other elements and not just one or two.
<scientes>
actually you only need one or two
<scientes>
cause you can always just use a bunch of two-way branches to make higher-level branches
<scientes>
that's how git does it
<Tetralux>
True. But I assume there's a reason why you'd have those branches. Otherwise you'd just use a linked or double-linked list and be done with it.
<scientes>
its not a queue because of the two-way branches (which have three arms)
<Tetralux>
It is. But it's elements have branches.
<very-mediocre>
most things in the real world are non-linear
<Tetralux>
And it's elems can have more than two.
<scientes>
its also not a tree, because it can merge back on itsself
<very-mediocre>
+ you can have weights on each edge (arrow between nodes)
<Tetralux>
By merge back, I assume you mean, can go down several branches and then point back up somewhere else.
<Tetralux>
.. Which is still a queue with branching elements.
<scientes>
yes, they can converge
<scientes>
well yeah, like a queue it is O(n) time
<very-mediocre>
Tetralux: Picture a set of positions with different distances, and you have to find the shortest path
<scientes>
very-mediocre, that complication is not necessary to get what a DAG is
<very-mediocre>
I'm trying to make it less theoretical
<scientes>
(and I myself have not dealt with it yet)
<scientes>
dependancies are naturally DAGs (until you have recycling)
<dimenus>
are defer statements executed in decl order or like you're popping a stack?
<scientes>
dimenus, stack
<scientes>
/ If multiple defer statements are specified, they will be executed in
<scientes>
/ the reverse order they were run.
<dimenus>
thanks
zie has left #zig [#zig]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
very-mediocre has left #zig [#zig]
dimenus has quit [Remote host closed the connection]
AlexMax has joined #zig
<Tetralux>
very-mediocre, scientes: I daresay the structure is useful under certain circumstances, but in my experience, fancy names like DAG only seem to get in the way of what's actually going on.
<scientes>
its not that fancy of a name
<scientes>
it say exactly what it is
<Tetralux>
Try describing it with concrete terms.
<scientes>
yeah
<scientes>
directed
<scientes>
acyclic
<scientes>
graph
<scientes>
three concrete terms
<Tetralux>
I meant structure kinds.
<Tetralux>
Like LinkedList, Array etc.
<scientes>
but that is irrelevent
<Tetralux>
You're not seeing my point xD
<scientes>
i am
<scientes>
and i am saying it isn't a point at all
<scientes>
this is math
<Tetralux>
_That's_ my point.
<scientes>
I think the pictures on wikipedia are the best
<scientes>
applying a flat RAM model totally misses the point
<Tetralux>
Allow me to illustrate my point like this.
<scientes>
but there are bazillions of implmentations
<Tetralux>
Nothing about anything that's been said allows me to understand _what_ exactly this kind of structure would be used for, and how it would be so.
<Tetralux>
The closest we've got is a "shortest-distance" algorithm.
<scientes>
except we mentioned systemd, zig, git
<scientes>
et cetera
<scientes>
and a lemonade stand
<Tetralux>
None of which actually tells me anything.
<Tetralux>
"Trees use wood."
<scientes>
well yeah you won't get it until you use it
<scientes>
as with any math
<scientes>
but that is not our fault
<Tetralux>
Any that's exactly my point.
<Tetralux>
I don't care much for things that are so abstract that it is impossible for me to understand them without some kind of deep explanation.
<scientes>
but its not that complicated
<mq32>
Tetralux, "LinkedList" is also an abstract concept
<mq32>
the same as Directed Acyclic Graph
<scientes>
just happens to be one you already know
<scientes>
and all lists are graphs
<scientes>
graphs are a superset of lists
<mq32>
A (singly) linked list is actually a special kind of DAG
<Tetralux>
mq32: You mean there's other kinds of linkedlist besides struct { next: ?Node, value: T }?
<mq32>
Tetralux, sure
<Tetralux>
(.. and of course the double variant.)
<mq32>
one with index into an array for example
<Tetralux>
Which
<scientes>
or even a flat array
<Tetralux>
Have a fundamentally different structure.
<mq32>
every node contains an index into an array to the next entry
<scientes>
is a version of a linked list
<Tetralux>
(That last one is the key point.)
<Tetralux>
The word "version" there is important.
<mq32>
linked list ist just "every node either points to the next node or none"
<mq32>
that's all
<Tetralux>
Every programmer knows what a LinkedList is.
<mq32>
nah
<Tetralux>
There are variants, sure.
<mq32>
HOW the pointing is done is completly irellevant to the term "linked list"
<Tetralux>
Sure - but a pointer is how it's almost always done without getting really specialized.
<mq32>
have you ever worked on platforms where you can't store pointers in objects? :P
<mq32>
brb, then i'll explain my point further
<scientes>
Tetralux, in LLVM there are linked lists that are just flat arrays
<scientes>
which confused the hell out of me
<Tetralux>
I'm not sure what exactly you mean by flat xD
<Tetralux>
The elements are contiguous?
<scientes>
yes
<Tetralux>
The nodes are? Or the actual values are?
<scientes>
both
<scientes>
oh wait, nodes
<Tetralux>
I was gonna say.
<Tetralux>
Yeah - that's fairly standard.
<scientes>
except not treating it as a linked-list
<Tetralux>
It's a way to make it not break the cache line.
<Tetralux>
The LinkedList doesn't treat it's nodes as a linkedList? xD
<scientes>
its because C++
<scientes>
in C++ you can do addition and it can write to global memory
<Tetralux>
But yes - the short form argument is just: I suggest you refrain from describing structures using mathmatical terms if it is intended to be used to program a computer by a programmer.
<scientes>
except in C++ anything can mean anything
<scientes>
so you really can't explain anything any other way
<Tetralux>
That's... open-ended xD
<scientes>
i mean i could overload the addition operator so 2+2 yields 5
<Tetralux>
Indeed you could.
<scientes>
(not my use of math term "yield" because = can also be overloaded)
<scientes>
or rather ==
<Tetralux>
I should note that you do want op-overloading for vector types.
<scientes>
no, llvm already implements those operators for vector types
<Tetralux>
I'm not sure I understand how that helps me the programmer.
<Tetralux>
I'm not using LLVM.
<scientes>
vector types are going to work similarly to the way SIMD hardware works
<Tetralux>
If I have to do vector math and cannot overload +, -, *, /, etc, then I'm prob not gonna use your language to do it in.
<Tetralux>
And yes
<gonz_>
I think we ought to deprecate focusing on helping the programmer at write-time.
<scientes>
^^^
<scientes>
reading is more important
<scientes>
and maintinance
<Tetralux>
I think that I want to not hate programming. :)
<Tetralux>
If I want that, I have C++ xD
fengb has quit [Remote host closed the connection]
<Tetralux>
But I get your point.
<scientes>
zig will NEVER support operator overloading
fengb has joined #zig
<scientes>
the only function call is the call operator
<Tetralux>
If I cannot multiply two matrices together then I prob won't make a game in Zig.
<Tetralux>
At least .mul is _sometihng_ though.
<scientes>
you just do matrix.mul(other_matric)
<fengb>
I hate all languages. I just hate some less than others
<gonz_>
You will always be able to multiply them together.
<Tetralux>
And the inplace version?
<scientes>
and LLVM is considering built-in complex number support
<andrewrk>
I'd probably word it differently than scientes, but I think it's fair to say that operator overloading is not planned and that is unlikely to change
<Tetralux>
andrewrk, I'm not sure I'd mind that honestly.
<Tetralux>
What I mind is that matrix usage of basic operations isn't a chore.
<scientes>
yeah but operator overloading isn't the way to do that
<dimenus>
is there any way to require that a type passed into a func is a slice (at comptime obviously)?
<scientes>
because you will never be able to optimize it
<andrewrk>
dimenus, you mean other than by making the parameter type a slice?
<Tetralux>
scientes: It does allow you to have *= and * pretty easily though.
<scientes>
when llvm adds complex numbers, zig might also add complex number types
<andrewrk>
dimenus, you could follow the pattern in std.mem and accept the element type as a parameter, and then the next parameter can be []T
<scientes>
andrewrk, yeah that's what i'm doing with vectors
<mq32>
re
<Tetralux>
dimenus: Like f(comptime T: type, s: []T) ...
<gonz_>
If we reach a point where the biggest problem is typing I think that'd be a success. For any long standing (or just moderately long-lived) code the issue won't be typing at the end of the day.
<dimenus>
eg in Odin I could do $T/[]$E
<scientes>
oh, so I don't really want vectors to implicitely widen their elements
<scientes>
but i do want to have a cast for that
<Tetralux>
(.. Which means: E is the eltype, T is the slicetype.)
<scientes>
what do you think andrewrk ?
<gonz_>
I do think there's a cross section where typing more leads to more errors, i.e. copy-paste errors, though.
<scientes>
because zext/sext on vectors is not as trivial as with scalars
<fengb>
I do agree that sometimes having operator overloading can make code more readable, especially when it maps closer to math
<Tetralux>
(.. It means 'T is a slice of E')
<andrewrk>
scientes, I'm not sure yet and I have a lot of stuff I'm already thinking about, not much room in my brain for SIMD for a couple hours
<fengb>
But it's complicated and seemingly abused in every language that supports it
<Tetralux>
(.. 'T is a slice of E elems)
<scientes>
oh fair enough
<andrewrk>
scientes, I do hope to get SIMD usable by 0.5.0 though
<Tetralux>
fengb: I think for math types, it makes sense.
<scientes>
andrewrk, so do I
<Tetralux>
I'm not sure you want it for anything else.
<gonz_>
What are your opinions on using ` to on-demand infix a function? I think it's pretty intrusive in terms of syntax but it's arguably better than operator overloading for clarity.
<fengb>
Tetralux: the problem then becomes how do you limit it to math types
<mikdusan>
in stage1 ir.cpp `static void copy_const_val(ConstExprValue *dest, ConstExprValue *src, bool same_global_refs);` does same_global_refs typically have to be false when `dest` is comptime?
<Tetralux>
fengb: I mean the obvious is have them built in.. If you wanted to limit it.
<Tetralux>
Vec2(T) Vec3(T)
<Tetralux>
Vec4(T)
<Tetralux>
Vec(T, n)
<Tetralux>
const Vec3 = Vec(f64, 3)
<Tetralux>
etc etc.
<Tetralux>
Those are just off the top of my head.
<andrewrk>
mikdusan, same_global_refs is a hack, the answer to how it works is hacky logic everywhere. we need some kind of copy-on-write system for values in zig. that's a big project that will fix a whole class of bugs
<mq32>
Tetralux, we already have those vector types
<Tetralux>
dimenus: You could do f(comptime S: type, s: S) and then use @typeInfo to ensure it's a slice, and use .Slice.child to get E, IIRC.
<mq32>
@Vector(3, f64)
<andrewrk>
mikdusan, see for example the TODO comment in ir_analyze_store_ptr
<Tetralux>
mq32: This is good.
<Tetralux>
However they are arrays without op overloading :)
<andrewrk>
mikdusan, apologies for this mess - this is one of those things where everything made sense at first, and then the language changed and the implementation couldn't keep up cleanly
<dimenus>
Tetralux: thanks, I spose that does cover my needs
<mq32>
Tetralux, you *can* add vectors toghether (using SIMD types)
<andrewrk>
dimenus, did you see my suggestion? it does not involve @typeInfo
<Tetralux>
mq32: What does "using SIMD types" mean.
<Tetralux>
That's just used by LLVM to implement @Vector, and therefore isn't something I have to use directly, right?
<fengb>
gonz_: I think it'd be interesting to have arbitrary infix functions. But Elm did remove it too...
<dimenus>
andrewrk: yeah, that's that I'm going to go with for now
<gonz_>
fengb: If people crave some way to infix stuff I think it's a more obvious candidate because at least it indicates a function call and which one is made, since there is a name.
<gonz_>
You *will* know what's being called; it's just that there are backticks around the function so the syntax for the call has changed.
<fengb>
Yeah, I'm more curious why Elm removed it since they did have the same `backtick` syntax you're mentioning
<Tetralux>
andrewrk: Can you get the eltype of a slice without typeinfo?
<Tetralux>
Or no
<Tetralux>
wrong question
<Tetralux>
the std.mem approach gives you 'E' and not 'T'.
<fengb>
I think maybe because Elm pipeline `|> function` is almost as good
<Tetralux>
whereas the Odin version gives both.
<gonz_>
fengb: It's anyone's guess. I don't agree with most of the choices made in Elm. That's in the context of functional abstraction, though.
<fengb>
I just want to visit why they do thing. I hate that Elm is notorious for "because BDFL says so" reasoning because it doesn't really explain why
<gonz_>
I don't know in practice if people have issues grokking the backtick infix model.
<gonz_>
Most of the design choices have been made with the rationale that they're hard features for people to use.
<gonz_>
That's the argument for not having user-defined type classes, for example.
<gonz_>
Even though they let you design APIs to be safer and easier to use.
<fengb>
But they do have operator overloading. It's just "blessed" to specific repos :shrug:
<gonz_>
Mhm
<Tetralux>
mq32: Okay, so @Vector types _do_ have op overloading?
<mq32>
andrewrk, cool. do you have an estimate when you start the stream? i hope i can watch it live without having to download the stream again :)
<andrewrk>
17:00 EDT. that's in 3.5 hours
lunamn has quit [Remote host closed the connection]
<mq32>
thanks :) that's gonna be a short night then :D
noonien has quit [Quit: Connection closed for inactivity]
kristoff_it has quit [Ping timeout: 272 seconds]
<dimenus>
andrewrk's suggestion is close enough to what I need, it just seems like a logical extension to able to verify type kinds at the callsite
<dimenus>
maybe not beceause Zig's type system is more complex than Odin's (or it seems that way from this layman's perspective)
<omglasers2>
is it ok to stay on master branch or better on 4.0 ? I've run into 2 compiler bugs on master and I'm wondering if 4.0 is more stable
<andrewrk>
fengb, for what it's worth, it is my goal for all the major proposals, whether accepted or rejected, to have documented reasoning on them
<andrewrk>
dimenus, it's the other way around. zig's type system is simple: all or nothing. to do something in between starts to move towards traits and all that stuff
<gonz_>
It's amazing how much you can get out of a few very simple parts in zig with regards to types.
<mq32>
gonz_: I'm always impressed how much you can get with a small, but well-thought system
<mq32>
Lua does the same thing for me
<gonz_>
Smalltalk is also a good example
<gonz_>
A few very simple rules and off you go
<mq32>
you can just create any kind of DSL/Markup Format for your special needs even without touch metatables/obscure features
<mq32>
and the same thing is for Zig: you can just build a lot of higher-level features with the type system that is present. and it's clear what you are doing all the time :)
<gonz_>
Haskell98 is essentially like that, but sadly it suffered the same fate as C++. Scheme would be an obvious candidate too, but people who don't like macros probably wouldn't agree so much.
avoidr has joined #zig
lunamn has joined #zig
<mq32>
it always depends on the spirit of the language
<mq32>
if macros are a fundamental part (and for scheme i think this is true) they should be used
<gonz_>
They are, yes. There's a pretty small core in a Scheme, and the rest is essentially macros on top of that.
<gonz_>
The main idea to me is that you have a small set of core concepts and the language falls out of those.
<mq32>
yeah i think scheme and Lua are good examples for this
<gonz_>
My current perception of zig is that explicitness and the removal of arbitrary compile time restriction are key concepts that most things fall out of.
<mq32>
yep, true dat
<mq32>
you can create a lot of awesome stuff with the things already there
<gonz_>
Also easily doing the correct thing with errors, obviously
<andrewrk>
mikdusan, looking
<gonz_>
Is anyone on dev.to ? I want to start a #zig tag there.
<mikdusan>
tl;dr all it does is check if comptime, and then copy_const_val with false after first iteration
<gonz_>
The editor currently doesn't support code blocks with zig syntax highlighting so I'll probably have to figure out how to get it in there.
<gonz_>
Or the markup, rather
kristoff_it has quit [Ping timeout: 246 seconds]
<gonz_>
Which makes me wonder whether or not you'd have to patch in zig highlighting in whichever library they're using.
<andrewrk>
mikdusan, does it fix the problem if you always pass `false` for same_global_refs?
<mikdusan>
yes
<andrewrk>
I think that's a safe change to make
<mikdusan>
clarification: as-is, or change to always false for comptime?
<andrewrk>
I think if you take master branch and change the `true` to `false` there, and that fixes the problem then I think that's the best bet
<mikdusan>
oh. just the 1-liner. ok. i'll run a quick build test and pr.
<gonz_>
andrewrk: What did you do to get syntax highlighting on GitHub?
<gonz_>
Anything that could be piggybacked on for other platforms?
<andrewrk>
the platform has to perceive that zig is popular enough
<gonz_>
I've sent an e-mail to dev.to asking what would need to be done but it was mostly a technical question. But you're saying there's nothing to really grab here in terms of already existing code?
jjido has joined #zig
<gonz_>
If a #zig tag is to be started it'll need syntax highlighting.
donpdonp has joined #zig
<donpdonp>
std.heap.LoggingAllocator.init(some_allocator, outStream) how does one specity stdout for outStream?
<donpdonp>
i saw something close from std.io.File, &stderr_file.outStream(), but endup with " error: expected type '*std.io.OutStream(anyerror)', found '*std.fs.file.OutStream'"
<gonz_>
Would `const standard_out_handle = try io.getStdOut();` work for you?
<lunamn>
iirc don't you need to get the proper stream by doing outStream().stream?
<donpdonp>
lunamn: std.heap.LoggingAllocator.init(callocator, &stderr_file.outStream().stream) => error: expected type '*std.io.OutStream(anyerror)', found '*std.io.OutStream(std.os.WriteError) note: pointer type child 'std.io.OutStream(std.os.WriteError)' cannot cast into pointer type child 'std.io.OutStream(anyerror)'
<donpdonp>
lunamn: thats closer :)
<lunamn>
yeah I don't know what you could do from there, that should be already working
<donpdonp>
here i was all excited about stumbling into LoggingAllocator :)
<andrewrk>
daurnimator, ^
<fengb>
He's probably still asleep :p
<donpdonp>
LoggingAllocator just became WarningAllocator :)
<donpdonp>
I naively assumed the output of init was a drop-in replacement for an allocator. const allocator = &logAlloc.init(c_allocator);
<donpdonp>
but later in the code i get error: expected type '*std.mem.Allocator', found '*logging_allocator.WarningAllocator'
<donpdonp>
which is a huge gap in my understanding of how a zig strcut would be a subclass/inherit/compatible_with an existing struct
<donpdonp>
strcut/struct
fengb has quit [Remote host closed the connection]
Ichorio has joined #zig
<lunamn>
donpdonp: get the std.mem.Allocator pointer by doing &logAlloc.init(c_allocator).allocator, the pointer is inside
fengb has joined #zig
laaron has quit [Remote host closed the connection]
<donpdonp>
lunamn: ah i see.
<donpdonp>
'allocation of 8 success! free of 8 bytes success!' \o/
<fengb>
donpdonp: Zig doesn't have subclassing/inheritance/embedding yet. We have C style function pointers
<fengb>
I keep reading about "manual memory management is hard" but there's a big divide between C and Rust
<fengb>
I wonder if there's any breakdown of the levels of hardness. Zig does a pretty good job of fixing most of the issues with out-of-bounds checks and what not, and is that good enough?
<mq32>
fengb, the hard thing with manual memory management is two things:
<mq32>
concurrency and ownership
<companion_cube>
but does it do something for double-free/memleak?
<mq32>
if you understand both well, memory management gets a lot easier most of the time
<fengb>
companion_cube: not yet, but having a debug allocator can find a lot of these issues
<companion_cube>
sure, sure
<fengb>
mq32: I mean more of buffer overflow, etc. I know Zig doesn't resolve all of these things, but it's much better than C
<companion_cube>
at runtime though, and only if exercized
<fengb>
And is that "good enough"
<gonz_>
I'm not sure the premise is all that sound in reality. Most projects would/will have a very simple allocation strategy in practice.
<fengb>
gonz_: I agree. I'm curious if we've had a breakdown on the classes of manual memory problems, rather than lumping them all together
<dimenus>
bheads: why does that make them suck?
tgschultz has quit [Ping timeout: 272 seconds]
ky0ko has quit [Ping timeout: 272 seconds]
<gonz_>
The failure modes associated with manual memory management and using a garbage collector are different, but I think you can end up spending way more effort trying to cajole the language into not allocating unreasonably than you would managing memory yourself.
<fengb>
I think gingerbill? once mentioned that there's like 1% of allocations he actually wants support with. I don't agree with his numbers, but fighting the borrow checker is something I dread in Rust
<dimenus>
by encouraging / requiring passing an allocator - zig gives the programmer a bunch of options AND makes determining if a function allocates much easier
<fengb>
Right. For instance, HTTP request allocation => arena lifetime
tgschultz has joined #zig
<mq32>
i'm not accustomed to using a specific allocator so i'm still a bit confused on how that will work with multiple parallel allocators in action
<dimenus>
errdefer is a simple concept that makes manual memory management way less painful imo
<dimenus>
i felt like I was on gingerBill's side when it came to errors until I spent the last two weeks with Zig
<dimenus>
already a convert
<gonz_>
Agreed. I think the easy to use concepts + the front and center allocators make this issue so much clearer in general.
<gonz_>
And since it's all there, explicitly, you encourage users to experiment and think about their allocation strategies, like you said.
<fengb>
I should watch more of gingerBill's videos. My problem is there's very little written and I sorta think his videos are a bit slow >_>
<mq32>
fengb, 125% speed does the work on youtube
<fengb>
Anyway... I keep hearing about Rust. But I feel like getting that strict might be overkill for a lot of things
<mq32>
fengb, that was my experience with rust at last
<fengb>
wrt Microsoft considering Rust
<mq32>
"oh, you want to do THAT? well, that is unsafe. i can't let you do that, dave (unless you use unsafe)"
<fengb>
70% of their errors are manual memory based. But how much of it is solved by proper bounds checking vs lifetime management?
<fengb>
And how much of lifetime management is just that we've only used malloc/free for 40 years instead of having a better paradigm
<companion_cube>
I guess the idea is that the borrow checker has your back even in teams, where ownership in large codebases might not be obvious
<companion_cube>
(also it's not just borrow check: move semantics is a big feature too)
<Sahnvour>
where it makes sense, lifetime management is still superior by being at compile time
<gonz_>
I think there's room on the spectrum. D has tried to add some interesting stuff in this regard with the `@live` annotation.
<fengb>
Is it better to have the language know all of it, like Rust? Or is it better to have a language that lets you manage it better, like Zig or Jai
<Tetralux>
My inclination is that the programmer should be given the tools (that are really powerful and really good, crucially) and let them do what they need to do the solve the problem they have in a simple understandable maintainable way.
<fengb>
But... I was really questioning whether we know that lifetime semantics is the bigger driver of these bugs
<Tetralux>
.. which also does not occur any more friction than absolutely necessary.
<Tetralux>
Lifetimes drove me from Rust.
<fengb>
And lumping everything into "C manual memory management sucks" doesn't really help
<fengb>
Since C is kinda broken with all kinds of things
<gonz_>
fengb: I think I lean more towards easier and more control, at least. Admittedly, though, I've only ever had experience with "OMG everything is broken" and zero control over anything.
<Tetralux>
What I like about the power of Jai's metaprogramming, _is_ that it trys to give you a few very powerful tools that are easy to use.
<fengb>
What I like about Zig is that it exists :P
<Tetralux>
Unlike SFNIANE, or however you pronounce it in C++
<mq32>
SFINAE = Substitution FAilure is not an error
<mq32>
evil concept
<gonz_>
What does that mean?
<mq32>
uff
<mq32>
if a template instatiation would result in a semantic error (like field 'x' not found on type 'T')
<mq32>
the compiler silently ignores this template
<dimenus>
zig doesn't need move semantics, we don't have constructors
<andrewrk>
the tech director of a company I once worked at sent me a code review where he used SFINAE, and I said "can you please just go refactor the rest of the codebase so that this is not necessary" and he said "no" and merged the code
<andrewrk>
if it exists in the language, it will be abused
<dimenus>
is it possible to create a slice from a ptr?
<dimenus>
i'm trying to make a dumb hack because we can't print out @Vector types yet
<Sahnvour>
andrewrk: I'd argue this is pragmatic :-)
<Sahnvour>
(tongue in cheek because I don't like this cult over pragmatism, but I reckon sfinae _can_ be useful)
<andrewrk>
dimenus, that looks good to me
<andrewrk>
the @ptrCast asks the question, why isn't self._data the correct type?
<andrewrk>
which hopefully has a good answer
<dimenus>
because for operations I want the vector type
<dimenus>
but we can't print out vectors
<dimenus>
basically i'm just trying to print out the contents of a vector
<Tetralux>
A Vector of f32?
<dimenus>
yep
<Tetralux>
If so, presumably &vec[0] should be *f32 -- which you can't slice, hence the cast?
<andrewrk>
I think a pointer to a vector should let you slice it
<andrewrk>
a pointer to a vector should implicitly cast to a slice
<dimenus>
but i dont need a slice of vectors
<dimenus>
i can't print that
<dimenus>
i need a slice of f32s
<andrewrk>
I'm saying *@Vector(f32, 10) should implicitly cast to []f32
<dimenus>
ah nice
<Tetralux>
It's interesting you know - I'd never come across the idea that a ptr and a slice are kinda the same tihng.
<Tetralux>
I'd always just considered a slice a simple struct with two members that have builtin special syntax for creating and using them.
<andrewrk>
mq32, I'm going to delay the stream by 1 hour - I need to get lunch
<mq32>
hmm
<mq32>
then watching the VOD it is
<mq32>
:(
<mq32>
have to get up in 7 hours again already
<tgschultz>
slice is a fat pointer, a pointer with additional data about what it points to. it's an old concept.
<Tetralux>
But does kinda make sense that *T is the equiv of []T, since it's just "points to one thing" and "points to multiple tihngs"
<Tetralux>
I always just thought of a slice as nothing more than a view into an array.
<andrewrk>
sorry mq32 got busy today and haven't eaten yet
<tgschultz>
which it is, the same way a normal pointer is a view of a single item
<Tetralux>
Just a ptr to memory into an array, and how many elems to consider inside it.
<mq32>
andrewrk, no problem. eating > streaming
<Tetralux>
I do consider it more a struct than a primitive though.
<Tetralux>
I can see the relation though.
<tgschultz>
both are true
<Tetralux>
Maybe that's me and my inclined fondness of being concrete xD
<Tetralux>
tgschultz: I'd be inclined to say a slice is not a primitive, because it's a struct. But an int is a primitive because it's a unit of data that the machine understands.
<Tetralux>
"The machine knows nothing of your structs!" xP
bheads_ has joined #zig
<Tetralux>
But in Zig, and Go, and Odin, slices are builtin to the language and have a primitive-like standing - but I'd not say they're primitive.
<Sahnvour>
they can be primitive to the language but not to the machine
<Tetralux>
Indeed.
<Tetralux>
That's the differentiation I am stating :p
<mq32>
Tetralux, actually the machine (x86_64) only understands like 8 of the 131072 integer types Zig allows *beeing overly pedantic*
bheads has quit [Ping timeout: 248 seconds]
bheads_ is now known as bheads
<Tetralux>
mq32: No, no. I'm equally pendantic xD
<Tetralux>
I'd agree with you.
<mq32>
so we can say: integers are structs
<mq32>
and thus: integers are not primitives
<mq32>
!
<Tetralux>
Well no. Ints up to 64-bit is primitive.
<mq32>
only 8,16,32 and 64
<Tetralux>
Indeed.
<mq32>
4 bit is not primitive
<Tetralux>
No it isn't.
<Tetralux>
And niether is 128, although it could be if you always use SIMD perhaps.
<mq32>
but i think it is important only to look at language level primitives
<mq32>
because otherwise you declare stuff primitive always regarding to a platform
<Tetralux>
I think it's important to keep perspective on the fact that the machine cares not for things that aren't primitive.
<halosghost>
I don't know what kind of machine you're on, but I have a 36-bit word-size
<halosghost>
so, i36 is a primitive for me
<mq32>
halosghost, i can offer 19 bit BCD words
<mq32>
or 12 bit architectures
<mq32>
oh, and the really obscure 55 bit one
<Tetralux>
Allow me to point out now that when I said 8, 16, 32, 64 are prim, I was assuming 64-bit xD
<Tetralux>
And 8-bit bytes.
<Tetralux>
And 16-bit words
<Tetralux>
And 32-bit dwords
<halosghost>
we're all adults here
<halosghost>
we can just say octets
<Tetralux>
And 64-bit qwords xD
<Tetralux>
*grins*
<mq32>
Tetralux: Assuming the original IBM definition of byte, the machine i made my Bachelor thesis about would have 55 bit "bytes"
<Tetralux>
It does make me wonder what exact reason they had to decide on that.
<mq32>
i think x86 has destroyed a lot of wording out there
<mq32>
Tetralux, physics, mostly :D
<Tetralux>
Good reason. :)
<Tetralux>
Although that is a LOT more that 8.
<mq32>
it had to be a multiple of 5 and 55 is luckily made of 5 and 11, which are both prime numbers
<Tetralux>
How fast was it though? ;)
<Tetralux>
Speaking of which
<mq32>
1µs bit time
<Tetralux>
It's worth noting that algorithms that read byte-by-byte are slower (in my experience) than those that operate on machine ints.
<mq32>
yeah
<mq32>
fastest memory access is bus width
<mq32>
*aligned bus width
<Tetralux>
.. Which means that many algorithms could be made faster by understanding that and----keeping perspective on the machine underneath ;)
<mq32>
which makes memcpy implementations kinda harder
<Tetralux>
I mean...
<Tetralux>
Is it really that hard to just copy as many as possible using usize and then the last one in bytes?
<Tetralux>
Or something like that.
<companion_cube>
you'd want to use simd anyway, right? multiple words at once
<Sahnvour>
that's what every reasonable memcpy implementation does
<mq32>
neat thing in zig is: we can query the target machine in code and switch on that, so we can implement target specific code
<mq32>
what Sahnvour says
<Tetralux>
Oh yeah - will there be a way to use SIMD without using @Vector?
<mq32>
or even better: use DMA controllers for memcpy and memset
<Tetralux>
mq32: What are those?
<mq32>
you mean by intrinsics?
<mq32>
on embedded hardware (and also on PC) you have "direct memory access" controllers
<Sahnvour>
Tetralux: llvm should auto vectorize stuff, but otherwise I don't know
<mq32>
for example on an LPC1786 i can say:
<mq32>
"please hardware, copy 120 bytes from here to there and increment both source and destination pointer"
<mq32>
and that just happens while you do other stuff
<Tetralux>
I mean, for instance, "I want to multiply these two 64-bit words by these two other 64-bit words." - where the four words could be contiguous elems in an array, as an example.
<mq32>
so you can memcpy while still working in parallel
<Tetralux>
And I want to ensure SIMD is used.
<Tetralux>
(.. Note 'ensure'.)
<Tetralux>
mq32: Seems legit :)
<mq32>
which is really cool
<Tetralux>
Indeed - I've been casually thinking about algorithms that could be rewritten specifically so that they could take advantage of things like SIMD and be substantially faster.
<Tetralux>
Things like DEFLATE, for instance.
<companion_cube>
mq32: does it also properly update the CPU cache?
<mq32>
yes
<companion_cube>
that seems useful indeed
<mq32>
you allocate some buffer, put a string in there, store the length and then tell your hardware:" please put this stuff into the serial port register and send it"
<mq32>
and then you just don't care anymore
<mq32>
that string gets sent
<Tetralux>
std.mem.simdMul(src[0..1], dst[0..1]), for src and dst being of type []usize.
<Sahnvour>
I thought DMA typically bypassed the cpu caches
<mq32>
Sahnvour, depends on the hardware you use
<mq32>
the hardware i'm talking about does not have caches (cortex-m3)
<Tetralux>
Wait - does the DMA bypass the memory latency delay?
<Tetralux>
I assume not.
<mq32>
depends
<Tetralux>
I mean - I guess the whole point would be to make it faster than doing the whole thing manually.
<mq32>
SOCs are weird and have strange architectures
<mq32>
Tetralux, the most important point on DMA is:
<mq32>
it copies stuff while the CPU works
<mq32>
so CPU is not fetching memory: the DMA is copying your data
<Tetralux>
Ah, so it's like copying the data in the registers but doesn't cause the thread to wait on it while it's doing it?
<mq32>
depending on what kind of DMA you use it can even have priority over the CPU on the memory bus
<mq32>
what thread? :D
<companion_cube>
sounds pretty unsafe though
<companion_cube>
another source of race conditions?
<Tetralux>
mq32: The one that exected the instr.
<Tetralux>
.. Assuming that's how you activate it.
<mq32>
if you implement multithreading, yes :D
<mq32>
and no, you just write stuff into registers
<Tetralux>
Hmm.
<mq32>
(well, memory mapped I/O)
<companion_cube>
what happens if the CPU tries to access the dest memory while the DMA is modifying it?
<mq32>
depends on WHEN you access it
<Sahnvour>
the kind of DMA mq32 writes about does not ge through the CPU at all, I think, that's handled by some other circuitry
<Tetralux>
Wait - do you use the DMA by using specific DMA instructions?
<mq32>
no
<mq32>
you just write into memory mapped stuff
<Tetralux>
And the write blocks the thread but allows the core to do other stuff in the meantime - is the idea?
<mq32>
you have 64 32-bit MMIO-registers controlling the DMA operation on real hardware
<halosghost>
instead, be sorry about pastebin.com :)
<Tetralux>
Ahhh
<Tetralux>
I see.
halosghost has quit [Quit: WeeChat 2.5]
<Tetralux>
I'm curious what exactly you'd put in the while loop while you're waiting.
<mq32>
Tetralux, just don't do that while loop
<mq32>
and just wait as soon as you want to access the data
<Tetralux>
Okay - so conceptually then, it's like you did `async memcpy(src, dst, n)`, and then can 'await' it when you actually do want to access it.
<mq32>
yes
<Tetralux>
.. which presumably you'd more often than not, want to do pretty soon after you wrote it.
<mq32>
nah, actually not :D
<mq32>
most of the time i wait for the transaction to finish before i start the next one
<mq32>
as you use the DMA to access your hardware
<mq32>
good example:
<mq32>
you have a framebuffer that contains pixels for a display unit connected to your SPI
<mq32>
then you just tell the DMA to first transfer the "move cursor to position" command to the display, then to transfer the whole framebuffer
<mq32>
and then your display gets filled while you can focus on other things in the meantime
supereti has joined #zig
ltr- has quit [Remote host closed the connection]
<mq32>
got to go
<fengb>
Another example: Gameboy doesn't let you write to the display when it's rendering, but the "not rendering" period is only 4560 cycles (0.1ms)
<fengb>
So you write to a spot in RAM during the render cycle, and DMA it over when the display is free
supereti has quit [Remote host closed the connection]
<Tetralux>
I see.
<Tetralux>
I think xD
<Tetralux>
Just about XD
ltr- has joined #zig
<dimenus>
what is zig's equivalent of sprintf?
<Tetralux>
mq32: Thanks for the effort in explaining it :)
<fengb>
std.fmt
<Tetralux>
std.fmt.allocPrint/bufPrint
<Tetralux>
IIRC.
<Tetralux>
Or rather yes - bufPrint.
omglasers2 has quit [Quit: Leaving]
<dimenus>
one more question, how do I escape '{' in a format string?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Tetralux>
Double-up the {
<Tetralux>
warn("{{ The brackets are upon us. }}");
<dimenus>
gives me unused args
<Tetralux>
I'm not actually sure if you need to do it with the closing ones or not.
<Tetralux>
You can't \ them right?
<dimenus>
nope
<Tetralux>
Hmm.
<Tetralux>
I know you can do it because I've done it xD
<Tetralux>
Did you try doubling up both?
<ltr->
error: expected type '', found 'Setter(f64)'
<dimenus>
yep
<ltr->
sounds familiar?
<ltr->
the compiler cant infer the type needed, i think
<dimenus>
ah, in my case it's triple
<dimenus>
eg, {{{0}}}
<dimenus>
prints{value}
<fengb>
lol
<dimenus>
all this to print a matrix
<dimenus>
lol
ltr- has quit [Quit: leaving]
fengb has quit [Remote host closed the connection]
<andrewrk>
ok gonna start the stream in a couple minutes
lunamn has quit [Ping timeout: 246 seconds]
lunamn has joined #zig
<dimenus>
does zig support any intrinsics? eg _mm_set_ss?
vegecode has joined #zig
<vegecode>
Congratulations on getting into the Github sponsors program. I have been donating $10 for a while, but can't do that with the tiers as they are right now. I could go down to five which would save me money, but I will still give ten if that were possible on Github. Can you do a "Choose Your Own Amount" like on Patreon?
<hryx>
vegecode: word is GitHub will add that ability in a few months
<hryx>
for now, there's no way
<vegecode>
K thanks.
vegecode has quit [Remote host closed the connection]
ltriant has joined #zig
<scientes>
so github sponsors is exclusive?
<scientes>
oh its matching
ntgg has joined #zig
<ntgg>
the test project I wrote has different behavior with -Drelease-(fast|small) modes release-safe works normal
<Tetralux>
Different?
<ntgg>
All the drawing is broken
<ntgg>
using OpenGL
<ntgg>
on release-small, it draws incorrect stuff, on release-fast it draws nothing
kristoff_it has quit [Ping timeout: 248 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
brakmic has quit []
<andrewrk>
ntgg, debug mode works normal too?
<ntgg>
andrewrk: yes
<andrewrk>
that means 1 of 2 things: (1) your code is invoking undefined behavior that zig is (at least currently) unable to provide safety checks for, or (2) you are running into a zig compiler bug
<ntgg>
I have no `unreachable` in my code, what else would cause undefined behavior?
<Tetralux>
Uninitialized variables is the obvious one.