<jjido>
mikdusan I don't like IEC/IEEE decimal numbers anyway. Why allow denormalised representations?
<jjido>
"representations that have the same numerical value but different quantum exponents, e.g., (1, 10, −1) representing 1.0 and (1, 100, −2) representing 1.00, are distinguishable."
<jjido>
crazy
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nickster has joined #zig
_whitelogger has joined #zig
shakesoda has quit [Quit: Connection closed for inactivity]
_Vi has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 256 seconds]
shakesoda has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
AndroidKitKat has quit [Remote host closed the connection]
AndroidKitKat has joined #zig
MajorLag has joined #zig
mikdusan1 has joined #zig
Snetry- has joined #zig
daex has joined #zig
andrewrk has quit [*.net *.split]
daex_ has quit [*.net *.split]
tgschultz has quit [*.net *.split]
mikdusan has quit [*.net *.split]
Snetry has quit [*.net *.split]
MajorLag is now known as tgschultz
dddddd has quit [Ping timeout: 256 seconds]
andrewrk has joined #zig
daex has quit [Ping timeout: 265 seconds]
daex has joined #zig
_whitelogger has joined #zig
<daurnimator>
fengb: heh. I just andrewrk's fixup commit.... I was going to make some of those same changes
<fengb>
Great minds think alike :)
<diginet>
jjido: the alternative to not allowing them is far worse and more complicated
joey152 has quit [Remote host closed the connection]
rappet has quit [Ping timeout: 272 seconds]
rappet has joined #zig
_whitelogger has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
marmotini_ has joined #zig
ur5us has joined #zig
marmotini_ has quit [Remote host closed the connection]
Kingsquee has joined #zig
_whitelogger has joined #zig
<Kingsquee>
so I'm looking over the zig documentation, and it says that casting a signed number to unsigned int is UB
<daurnimator>
Kingsquee: with @intCast: yes: you're promising that the number fits in the destination
<Kingsquee>
oh, can I @yoloCast or something?
<daurnimator>
Kingsquee: e.g. you might have a i64, but you *know* its only between 10 and 4000: you would @intCast it to a u12
<daurnimator>
Kingsquee: you might be looking for @bitCast for going between unsigned and signed?
<daurnimator>
that lets you e.g. go between a isize and a usize
<Kingsquee>
I see there's also @as
<daurnimator>
Kingsquee: @as only lets you go... "bigger" e.g. `@as(u64, my_u32)` works, `@as(u32, my_u64)` is a compile error
<Kingsquee>
so many casts
<Kingsquee>
a cast-astropy
<daurnimator>
Kingsquee: @intCast is a pinky-promise that you can fit into the destination
<daurnimator>
Kingsquee: if you're not sure if you can fit into the destination, see @truncate
<daurnimator>
Kingsquee: explicit over implicit
<Kingsquee>
this is interesting since I never thought about this stuff being implicit
<Kingsquee>
and yet it be
<Kingsquee>
@daurnimator @bitCast looks like what I was expecting, yep
<Kingsquee>
thanks
<daurnimator>
Kingsquee: and FYI, @bitCast will compile error if the types are not exactly the same size.
<Kingsquee>
yeah, I saw
<Kingsquee>
same dealio as rust's mem::transmute<T>(x)
<Kingsquee>
this language looks pretty nice
<Kingsquee>
the smooth jazz that is anyerror feels almost sinful after coming from rust
<daurnimator>
Kingsquee: welcome :) what sort of things do you work on?
<Kingsquee>
i make bideo game
slurpie has quit [Ping timeout: 258 seconds]
<Kingsquee>
I've been trying to do a thing with fixedpoint numbers in rust but the language's lack of compiletime numbers in generics has limited my shenanigans
<daurnimator>
What's on the menu Kingsquee?
<Kingsquee>
so productivity hasn't been all that great but I really didn't want to go back to C++
<Kingsquee>
and then Zig ((holylight))
<Kingsquee>
so I'm playing around with it despite its apparent infancy
<Kingsquee>
is zig actually practically usable in its current state?
<Kingsquee>
or are we regularly playing compiler bug whack-a-mole
TheLemonMan has joined #zig
<daurnimator>
Kingsquee: you will hit compiler bugs.... but its usually when you have buggy code
<Kingsquee>
fair
frett27 has quit [Ping timeout: 256 seconds]
<daurnimator>
Kingsquee: which is to say: *most* compiler bugs tend to be when the zig compiler makes assumptions that your code is well-formed: when your code is bad, zig goes off and crashes in weird and wonderful ways
<Kingsquee>
hmmm
<daurnimator>
they're getting less and less frequent though :)
<Kingsquee>
that kind of assumption feels iffy though
<daurnimator>
Kingsquee: essentially missing validation in various stages of the compiler that later stages assume to have occured
<Kingsquee>
whats the turnaround time on fixes like?
<Kingsquee>
and/or how hard is it to fix things
<daurnimator>
anywhere from 10 minutes to 6 months? ;)
<Kingsquee>
. _.
<daurnimator>
(depends on how hard it is to fix it; and who is around with the relevant skills+interests)
<Kingsquee>
what kind of stuff are you working on with zig?
<daurnimator>
good question. I think I've managed to get too absorbed into zig itself and have barely worked on anything *in* zig... instead have been working on zig itself
<Kingsquee>
the hero we need, not the one we deserve
<daurnimator>
I should actually go back and finish some projects
<Kingsquee>
what were you working on?
<Kingsquee>
also I should ask, how's jai's compile time doing
<Kingsquee>
er, zig
<daurnimator>
one project was a decentralised messaging protocol
<Kingsquee>
(they're kinda occupying the same region in my brain)
<daurnimator>
compile time is mostly waiting for LLVM itself: we have plans to one day write our own assembler so we don't have to wait on LLVM; but that's pretty far off
ur5us has quit [Ping timeout: 256 seconds]
<Kingsquee>
not hitting any massive slowdowns with evaluation of comptime stuff?
<daurnimator>
comptime is not fast.... but I think only a couple of people have actually hit real slow paths
<daurnimator>
we have plans to optimise it in future: in theory it shouldn't be any slower than, say, cpython; but bug fixing and language changes take priority
<Kingsquee>
yeah, the issue I see hit in rust occasionally is type recursion and non-obvious compiletime increases from certain comptime programming patterns
<Kingsquee>
have to do weird workarounds like "don't assign to (the rust equivalent of) a comptime variable before returning it, just return the expression immediately"
daex has quit [Ping timeout: 260 seconds]
daex_ has joined #zig
<Snektron>
<Kingsquee "I've been trying to do a thing w"> Arent there const generics by now?
<Kingsquee>
no, we have typenum
<Kingsquee>
monstrous beauty that it is
<Snektron>
Huh
<Snektron>
Weird, i thought they hit stable already
<daurnimator>
Kingsquee: correct answer: panic is unrecoverable. never panic on OOM.
<Kingsquee>
catch_unwind?
<Kingsquee>
like, what are you going to do if you have no more memory, call an x86 intrinsic to pray to the gods
<daurnimator>
i.e. "unable to allocator memory" must be an error returned/thrown by functions. i.e. functions that allocate need to have a way to signal errors
<Snektron>
<Kingsquee "hot take: in any situation you'd"> I think using your own allocator is not very useful in rust, since you can only have one allocator really
<Kingsquee>
daurnimator: fair enough
<Kingsquee>
I actually tried this with writing my own containers, but didn't find it very useful
<daurnimator>
Kingsquee: try using zig ones, we do it right :)
<Kingsquee>
and the OOM error handling everywhere was pretty fugly
<mq32>
we use github issues for tracking proposals
LakeByTheWoods has joined #zig
Patrice_ has joined #zig
FireFox317 has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
frett27_ has quit [Ping timeout: 258 seconds]
tdc has quit [Remote host closed the connection]
tdc has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 260 seconds]
daex_ has quit [Ping timeout: 255 seconds]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
daex has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 240 seconds]
frett27 has joined #zig
daex_ has quit [Ping timeout: 268 seconds]
LakeByTheWoods has quit [Remote host closed the connection]
slurpie has joined #zig
daex has joined #zig
jessermeyer has joined #zig
daex has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
daex has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
slurpie has quit [Ping timeout: 268 seconds]
dddddd has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
mikdusan1 is now known as mikdusan
daex has quit [Ping timeout: 255 seconds]
mahmudov has quit [Ping timeout: 258 seconds]
daex has joined #zig
marmotini_ has joined #zig
<pixelherodev>
... huh. I just realized why I stopped using email to track Zig issues: I filtered Zig emails into a different folder and then forget about it :(
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<TheLemonMan>
andrewrk, ping
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
daex has quit [Ping timeout: 265 seconds]
<pixelherodev>
Anyone have Zig syntax highlighting for kak?
<shakesoda>
not quite a showstopper, but frustrating, I have to modify a bunch of functions to take pointer args instead to workaround whenever I'm up for fixing that build
<jessermeyer>
Huh, That reminds me that I had some issues with DX12 COM that I never got to the bottom of. Possibly related.
<jessermeyer>
I recall passing a struct with an int offset for a heap descriptor and it would always fail. Worked fine compiling in straight C.
<jessermeyer>
Now I'm in Vulkan land, and thankfully the API takes pointers universally from what I can tell.
daex has joined #zig
jjido has joined #zig
<TheLemonMan>
eh fuck this shit, I keep stumbing into LLVM bugs
<pixelherodev>
I configured kak to auto-zig fmt on idle, not realizing how often that was. I hit enter, it hits backspace :P
waleee-cl has joined #zig
<TheLemonMan>
zig fmt is a drug
daex has quit [Ping timeout: 265 seconds]
<pixelherodev>
Yeah
<pixelherodev>
I upped the idle timeout a bit and now it's perfect
<pixelherodev>
Auto-formats nearly the instant I stop typing :)
slurpie has joined #zig
daex has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
marmotini_ has quit [Remote host closed the connection]
<jaredmm>
I'm going through and fixing some translate-c issues and I've started to see a lot of redefinition errors. (pub const __ = @compilerError) that are all identical. One instance of a const and pub const definition with the same @compileError body.
s-ol has quit [Remote host closed the connection]
<jaredmm>
I'm checking without my patch to confirm it didn't create the scenario rather than just being hidden because of all the other errors.
<jaredmm>
(Although looking at an old master I see the issue there, just not reported as an error because of an earlier error, so it doesn't seem to matter for this case)
<frett27>
because of the same name for parameter and global variable
<pixelherodev>
Variables can never shadow other variables
<pixelherodev>
You'll have to rename one
adamkowalski has joined #zig
mahmudov has joined #zig
<adamkowalski>
What is the rule with anonymous struct literals? Sometimes when I call a function it works fine, other times I get `error: TODO: type coercion of anon struct literal to struct`
marijnfs has joined #zig
TheLemonMan has quit [Ping timeout: 240 seconds]
TheLemonMan has joined #zig
frmdstryr has quit [Ping timeout: 255 seconds]
jessermeyer has quit [Remote host closed the connection]
<fengb>
I don't really know much about the compiler either :P
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<adamkowalski>
awesome thanks, I'll get to reading
<andrewrk>
TheLemonMan, yo
<TheLemonMan>
I forgot what the question was heh
<TheLemonMan>
gah I love some more crazy SIMD-related test failures
<andrewrk>
TheLemonMan, I wonder how the llvm10 branch fares
<TheLemonMan>
much better I guess
<TheLemonMan>
the 10 series already fixes a few crazy codegen problems
<pixelherodev>
Just for the record: github.com/pixelherodev/kak-zig
<pixelherodev>
Found a better version, then integrated zig-fmt
<Kingsquee>
considering arbitrary sized numbers, is there any support / libraries for dynamic bitwidth integers that don't overflow? (except when hitting max integer bitwidth)
<TheLemonMan>
the stdlib has "classical" bigints
<Kingsquee>
hmm
<pixelherodev>
Only thing I need to fix for kak-zig is `zig build` integration (which works with my setup, but the commands to go the errors are confused by the zig command line showing up in the output due to verbose mode)
<Kingsquee>
is there a way to disable the implicit conversion from machine sizes to bigints for integers?
<Kingsquee>
i.e. getting a compiler error if I use a u129
<andrewrk>
llvm10 branch passed the full test suite with llvm assertions enabled
<andrewrk>
llvm10 rc4
<Kingsquee>
I imagine if someone starts doing high perf code with type generation one could accidentally tank their perf as complexity increases
<andrewrk>
Kingsquee, there's no implicit conversion from primitive int types to std.math.big.Int
<Kingsquee>
andrewrk: I mean the support for arbitrary i#/u#'s
<Kingsquee>
i512 etc
<Kingsquee>
i7
<Kingsquee>
u9
<andrewrk>
using large fixed width int sizes doesn't necessarily mean tanking perf. it could actually be quite well performing
<andrewrk>
the "maximum machine int size" is different for different targets
<andrewrk>
applications should pick reasonable upper bound limits for integers and then use the appropriate types
<pixelherodev>
Is there an equivalent to __LINE__ / __FILE__ ?
ur5us has joined #zig
<Kingsquee>
andrewrk: I'm just exploring zig now, so sorry for the unfamiliarity, but can the width of a returned integer type be defined using comptime calculations?
<andrewrk>
Kingsquee, yes
<Kingsquee>
conceptually equivalent to concat(u, n+m) -> u#
<fengb>
But FBA has a implementation / test to do an in-place expand if it's the last element
<pixelherodev>
Integrated `zig build` into kakoune :)
<pixelherodev>
It's actually *easier* to jump between errors now than in Vim
<jaredmm>
More "how is it expected to be done" rather than how well does it work. I know clang has definitions for the MSVC intrinsics. Is the expectation that each intrinsic is re-implemented in Zig?
<Kingsquee>
is there a way to define a test should fail?
<Kingsquee>
better yet, fail to compile?
<TheLemonMan>
no
<TheLemonMan>
you can add a @compileError that's only triggered if the code compiles
<andrewrk>
fengb, sounds like FBA would not be elligible for null shrinkfn
<andrewrk>
I don't understand your concern- realloc is non-optional so it's always available
<Kingsquee>
hmm
<Kingsquee>
variables in tests don't seem to be scoped to the test?
<Kingsquee>
test "fooy" { var foo: i32 = 4; } const foo: i32 = 10;
<Kingsquee>
"error: redefinition of foo"
<TheLemonMan>
the local variable is shadowing the global one
alichay has joined #zig
<fengb>
I don't think null shrinkfn should dictate how an expand should work
<andrewrk>
fengb, in what way does null shrinkfn dictate how an expand should work?
<Kingsquee>
oh interesting, it doesn't display the error unless fooy() is used
<andrewrk>
pretend that I have no idea what you are talking about because I wrote that code years ago and don't remember
<TheLemonMan>
everything that's not referenced won't be compiled/analyzed at all
<Kingsquee>
I'm not sure if this is a feature or not
<andrewrk>
it has benefits and problems
<Kingsquee>
yeah
<andrewrk>
this is the same problem as conditional compilation that all languages have, but zig has it for every function
<fengb>
Your old implementation checks if there's a null shrinkfn, it'll automatically do a copy expand for realloc
<TheLemonMan>
it's great when you're refactoring a lot of code
<fengb>
I don't think that should be there, only a special case for a shrink realloc
<TheLemonMan>
it's not great when you discover some code path has bit-rotted
<andrewrk>
yeah. it's not considered to be a "closed" part of the language design
<andrewrk>
still an unsolved problem
<Kingsquee>
noted
<fengb>
I'll make my change and have you review it :P
<andrewrk>
fengb, I think I agree with you that it should call realloc on the underlying implementation
tdc has quit [Ping timeout: 260 seconds]
<Kingsquee>
oh jeez, namespaced_global.zig
<Kingsquee>
mind = blown
<TheLemonMan>
that's a good title for a talk, "Zig blows (your mind)"
<Kingsquee>
this is going to take some getting used to
<andrewrk>
Kingsquee, zig is a Domain Specific Language for generating machine code. if you think of it this way, it may help
<adamkowalski>
andrewrk: is there some guideline on when anonymous struct literals work and don't work? I've had some issues with them today
<Kingsquee>
andrewrk: what else could one want
<adamkowalski>
I'm getting error: TODO: type coercion of anon struct literal to struct
<andrewrk>
adamkowalski, you can avoid this problem by time traveling until the TODO is implemented, or by using @as
<adamkowalski>
Kingsquee: everything is lazy evaluated, which is great, it speeds up compile times. However, something thats a gotcha is tests wont run if they aren't referenced. So if you look at the standard libraries main file is has to "reference all decls" and then it will force evaluation and run your whole test suite
<adamkowalski>
andrewrk: But is there a guideline on when it will work? In other parts of my codebase I am able to use them
<Kingsquee>
interesting
<andrewrk>
adamkowalski, yes, when the result location has a type
<adamkowalski>
So here is the call site: const actual = try minimum(f64, &arena.allocator, x, .{});
<adamkowalski>
and the function prototype: pub fn minimum(comptime T: type, allocator: *Allocator, tensor: CpuTensor(T), parameters: ReduceParameters) !CpuTensor(T) {
<adamkowalski>
shouldn't type inference pick up that parameters is of type ReduceParameters
<adamkowalski>
and then the .{} will be implicitly of type ReduceParameters?
<andrewrk>
yes
<adamkowalski>
so does the result location not have a type in this case? I guess I don't understand what that means
<andrewrk>
TheLemonMan, it's pretty neat how the Target feature set can use SIMD as an actually more convenient way to add/remove items from the set righ? :D
<andrewrk>
idk if the codegen is better or worse, but in theory it should pretty much be the same
<TheLemonMan>
hah yeah, that's what pushed me to implement some other missing ops
<andrewrk>
I need to get the skeleton of stage2 figured out, with async I/O and all that good stuff, so that contributors can have something exciting to work on
<andrewrk>
a big milestone recently is that now the std lib tests build with --test-evented-io
<TheLemonMan>
great! the CI fails because of a QEMU bug :(
<andrewrk>
(but they fail at runtime due to an event loop bug - which is good because that's what I want to be working on now)
adamkowalski has quit [Quit: Lost terminal]
adamkowalski has joined #zig
<TheLemonMan>
andrewrk, do you think it's possible to upgrade qemu in the azure img?
<adamkowalski>
andrewrk: I think there was a break on master last night or today btw./Users/adamkowalski/zig/lib/std/fmt.zig:329:32: error: expected 6 arguments, found 4
<TheLemonMan>
eh, it's not much a matter of type inference being wonky, it's because how expectEqual is defined
<TheLemonMan>
`fn expectEqual(expected: var, actual: @TypeOf(expected))`
<TheLemonMan>
so if `expected => comptime_int` actual has to be comptime_int too...
<TheLemonMan>
andrewrk, yeah it seems the only way to do so is to built it by hand
marijnfs has quit [Quit: Lost terminal]
<Kingsquee>
but we can do 'var a: i64 = 5"
<TheLemonMan>
and?
<Kingsquee>
it just seems like by the expectEqual logic we should have to do `var a: i64 = @as(i64, 5)`
<fengb>
Kingsquee: it's because the args match JUnit, but our type inference needs to be the other way around
<fengb>
So we can only do left to right inferencing, and it doesn't work when comptime literals are on the left side
<TheLemonMan>
that's an implicit cast
<adamkowalski>
I think it's fine as is. you want to make sure expectEqual does not implicitly change types
<adamkowalski>
if it's a literal it will be a compile_int/compile_float unless explictily casted otherwise
<TheLemonMan>
5 is comptime_int, the compiler is smart enough to know it fits into a i64 and so inserts the cast for you
<fengb>
I'd prefer if expected is on the right, and a lot of people on that issue agree :P
<adamkowalski>
having to type a tiny bit more is worth having the power of compile time numbers
<Kingsquee>
TheLemonMan: I'd expect typing a literal into something that has an integer type will be the integer type, no exceptions :V
<adamkowalski>
and if you really care, you can easily write an expect equal which accepts two vars and then does the coercion yoruself
<adamkowalski>
it already does that
<adamkowalski>
if you have a function expected an i32 and you pass a comptime_int it will conver it
<adamkowalski>
but in this case the leftmost argument is a comptime int, and so the right argument (which must match the left most argument) will not be known at comptime
<Kingsquee>
ah, I see
<fengb>
It's really just this one function
<Kingsquee>
yeah lets swap dat order
<fengb>
Most of the other times, it resolves as you expect or it's actually ambiguous
<fengb>
I do kinda like Rust's 1u32 syntax though
<Kingsquee>
I prefer its 'as' syntax, frankly
<Kingsquee>
just wish it doesn't some special snowflake for basetypes
<Kingsquee>
in practice I just write my own `.cast<T>()`'s
<Kingsquee>
so when somethings been added to Milestone 0.7.0 or whatever, does that imply it's accepting PR's?
<fengb>
No, it just means it's planning to be worked on for 0.7 release. You can make PRs for anything at any time
<Kingsquee>
ah, so if someone does it before 0.7, we're not in conflict
<Kingsquee>
just means it's graced awrk's bucket list
<fengb>
Right
<Kingsquee>
nice
<fengb>
Or more likely... he'll look at it 2 months before end of release and push it out again >_>
<fengb>
Release features are rather lax heh
<Kingsquee>
HRMMvibratingface.mov
<adamkowalski>
this is a fun error
<adamkowalski>
./src/eager/cpu_tensor.zig:28:9: note: 'error.NoSpaceLeft' not a member of destination error set
<adamkowalski>
) error{NoSpaceLeft}!void {
<adamkowalski>
am I crazy?
<Kingsquee>
there is no space left in the destination error set, ergo you have caused all possible errors across all time and space axis
<adamkowalski>
I think it's because I'm using recursion and the error set is not properly being inferred. I'll keep digging
<Kingsquee>
huh, this is interesting
slurpie has quit [Ping timeout: 256 seconds]
<Kingsquee>
so without threadlocal storage on the global variable storing 1234, I ran two threads, each incrementing tl_x by 1, and after wait()ing for each thread to finish, I expectEqual'd tl_x to be 1236
slurpie has joined #zig
<Kingsquee>
in practice I get either 1236 or 1237
<Kingsquee>
I'd expect the thread execution order to be nondeterministic, but the value should be deterministic after the wait()s, no?
<fengb>
I wouldn't expect 1237... but 1235 wouldn't surprise me
<adamkowalski>
andrewrk: In the past you mentioned I could use error{}!ReturnType and the compiler will tell me what to put in. It seems like that is no longer the case? Any Ideas
<Kingsquee>
but it's wait'd!
<fengb>
Oh waiting between each thread?
<fengb>
Anyway... not sure how 1237 came out
<Kingsquee>
oh wait, yeah I messed up
<Kingsquee>
it's 1235 or 1236
<Kingsquee>
hol' up
<adamkowalski>
fengb: do you happen to know any code examples with formatting + recursion after the api change?
<fengb>
(tl_x += 1) => (tl_x = tl_x + 1). No guarantees the assignment will happen directly after the add so it's possible both threads picks up 1234 and adds by 1
<fengb>
And one of the assignments is just clobbered
<fengb>
You should be able to just delete the leading Error and inference would just work
<adamkowalski>
not with recursion
<adamkowalski>
./src/eager/cpu_tensor.zig:53:13: error: cannot resolve inferred error set '@TypeOf(src.eager.cpu_tensor.printTensor).ReturnType.ErrorSet': function 'src
<fengb>
Hmm
<fengb>
@TypeOf(out_stream).Error!void
<adamkowalski>
it's trying to infer the error set, which I'm assuming means following each function call to find the error set and then do the union
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<adamkowalski>
and when it follows the recursive call it's realizing it's going into an infinite loop?
<adamkowalski>
Hell yeah!!! that worked, thanks
<fengb>
np
<fengb>
I'll add that to the compile error :)
<fengb>
Maybe I should just add that everywhere in the code. It doesn't need it... but it'll be more obvious looking at the examples
<adamkowalski>
I mean overall it's a much slimmer/cleaner API so I like it
<adamkowalski>
it just took me a second to update to it, so I haven't gotten anything done today haha
<adamkowalski>
I've been adding in all the type names to fix the anonymous struct issue, and then updating the formatted printing
<fengb>
Sure, there's no reason we can't be more helpful (other than I forgot)
<adamkowalski>
overall atomics are fairly straightforward in concept
<adamkowalski>
just like in a database
<adamkowalski>
either the whole transaction succeeds or fails in an atomic unit
<adamkowalski>
keep in mind if your goal is increased performance and so you are trying to move to a multi threaded envirnonment, but your solution is to share mutable state between threads, you may very well be slower then a single threaded solution
<Kingsquee>
yeah, that's intuitive
<adamkowalski>
I recommend only sharing immutable data between threads. Or partition the work so that each thread works on a different section of an array and coordination is not required.
<adamkowalski>
Or use a queue and send messages back and forth between threads. but each thread does not share any data between themselves
<adamkowalski>
mutable data + locks and threads is like a stop light at an intersection. Only one direction can move freely at once
<adamkowalski>
prefer on ramps and off ramps of highways which route traffic to different part of the system uninteruprted
<Kingsquee>
wouldn't you need some sort of lock to stop queues from having race conditions?
<Kingsquee>
eg thread1 writes to queue1, thread2 writes to queue1
<Kingsquee>
then again could just have unidirectional queues
<Kingsquee>
only lock then would technically be a 'being written to' flag
<Kingsquee>
perhaps a 'being read' flag
<adamkowalski>
yes the queue would have to be written in terms of locks and or atomics, but it's much easier to get one part of the system correct and tested and then everybody else just benefits
frett27 has quit [Ping timeout: 256 seconds]
Patrice_ has quit [Ping timeout: 255 seconds]
<adamkowalski>
aditionally you could have three queues one for the writer, which is not locked, and is where you can place things when the middle queue is currently locked
<adamkowalski>
one at the reader which the middle queue can write to when the reader is unaviable, as to not lock the main queue
<adamkowalski>
then the middle queue would require a lock, then read from the write queue, and then put onto the read queue
<adamkowalski>
the point is the complexity is managed once rather then dealing with threading everywhere which becomes really complex really fast