|
lol at anyone unfortunate enough to work directly with hardware
|
#
?
Feb 26, 2019 01:04
|
|
|
|
| # ? May 23, 2024 10:36 |
|
|
eschaton posted:
no promises, I'll see the CA offices maybe once a year, and while they're in bay, they're not in SF. but a solid "maybe" jit bull transpile posted:you guys are idiots. hack bunny is in Italy and we should be organizing gooncon Roma asap we have a C++ conference  https://www.italiancpp.org/carry on then posted:and now every goon in yospos will rush in to insist they too know prolog because in nerd land the worst thing in the world is to admit you lack some piece of knowledge that others posess no but I wish I did because I know it can be used to solve those annoying logical puzzles, and sudokus, and because I want a thing that aggregates facts from multiple sources and detects inconsistencies (which is probably an abuse of prolog, idk) also I bet you lack a piece of knowledge that I possess: there is a Prolog engine in window nt 4. it's used as a constraint solver to build the network configuration from a set of network interfaces, drivers, protocols, user settings etc. and since later windows versions retained the transactional ui (but disguised it as a regular property sheet dialog that curiously lacks an "apply" button), I can't help but wonder if it's still there in some form microsoft's code analysis tool (prefast) was also originally written in prolog. again no idea if it still is Suspicious Dish posted:Pinging slurps mad rips or hackbunny or jmccall. Did they actually fix modules before ship? sorry, was too busy salivating over the inspect statement  and variadic foreach and coroutines, and being disappointed with the monadic operations for optional, and haven't started reading about modules yetSlurps Mad Rips posted:honestly people seemed more upset about contracts than modules. misread this as concepts at first but being upset at contracts doesn't make sense either hackbunny fucked around with this message at 01:29 on Feb 26, 2019 |
|
#
?
Feb 26, 2019 01:15
|
|
|
DONT THREAD ON ME posted:every programming language is type safe if you program on a kinesis advantage strong typing is when you press the keys very hard
|
|
#
?
Feb 26, 2019 01:22
|
|
|
hackbunny posted:strong typing is when you press the keys very hard my office has astroturf, trust me you do a lot of static typing nobody wants to be the one to touch the door handle to open it on the way out
|
|
#
?
Feb 26, 2019 01:26
|
|
|
DONT THREAD ON ME posted:every programming language is type safe if you program on a kinesis advantage post of the day right here
|
|
#
?
Feb 26, 2019 02:06
|
|
|
Suspicious Dish posted:The reason I ask is because you wrote a very impassioned blog post about his modules wouldn't solve any of the problems that people thought they would. I assume some of those concerns no longer apply to the new proposal? that post was about the Modules TS. what we ended up getting was a combination of the ATOM modules proposal and the TS with a few additions since San Diego. so merged modules are quite different. if you’re ok with reading legalese checkout the latest draft at https://wg21.link/N4800 (PDF link) and read up on some modules wording for a better idea on what it’ll entail.
|
|
#
?
Feb 26, 2019 04:08
|
|
|
gonadic io posted:I tried [bool; u32] and that did not work lol, std::mem::size_of::<[bool; 32]>() gives 32 bytes (thanks llvm) C++ tried making a 32-element vector<bool> into an 8-byte object, and it is widely considered to be one of the biggest mistakes in the standard. The root of the problem is that you cannot take the address of an individual bit, so you can't have references to the array elements. The lesson Rust rightfully took from this is that [bool; 32] should be 32 bytes, just like [char; 32] is 128 bytes. Instead of special-casing these array types, it makes more sense to have separate space-efficient bitset and &str types with more appropriate APIs.
|
|
#
?
Feb 26, 2019 09:58
|
|
|
gonadic io posted:my office has astroturf, trust me you do a lot of static typing um what what would make someone decide to install astroturf in an office
|
|
#
?
Feb 26, 2019 19:48
|
|
|
Plorkyeran posted:um what It also has a table tennis table, bouncy hoppers, and a hammock. loving startups. At least those things don't actively impede work like the static from the astroturf does. I wonder if the failure rate of laptops is noticibly higher here due to it
|
|
#
?
Feb 26, 2019 19:54
|
|
|
VikingofRock posted:The root of the problem is that you cannot take the address of an individual bit, so you can't have references to the array elements with every other place that C++ seems content to take a comparison and turn it into a callsite, i don't get why this would be a sticky situation? you can't have a uintptr_t as a backing store or w/e, but you can take a fat reference around and still have something usable
|
|
#
?
Feb 26, 2019 20:55
|
|
|
JawnV6 posted:with every other place that C++ seems content to take a comparison and turn it into a callsite, i don't get why this would be a sticky situation? you can't have a uintptr_t as a backing store or w/e, but you can take a fat reference around and still have something usable Yeah, I think what they should have done is make a separate bitvector class, with a fat reference returned by indexing. This well-known blog post basically makes the same argument, but unfortunately that's not what the standards committee did and now we are stuck with it unless they decide to break backwards compatibility.
|
|
#
?
Feb 26, 2019 21:48
|
|
|
VikingofRock posted:C++ tried making a 32-element vector<bool> into an 8-byte object, and it is widely considered to be one of the biggest mistakes in the standard. The root of the problem is that you cannot take the address of an individual bit, so you can't have references to the array elements. The lesson Rust rightfully took from this is that [bool; 32] should be 32 bytes, just like [char; 32] is 128 bytes. Instead of special-casing these array types, it makes more sense to have separate space-efficient bitset and &str types with more appropriate APIs. some people at work got burned hard by this recently. they were writing to the elements in a vector<bool> on different threads. this is fine on every other type of vector (as long as different threads access different elements), but because the c++ spec special cases vector<bool> this way, writing requires reading, flipping the bit, and then writing again, which isn't thread safe (the spec goes out of it's way to specify that vector<bool> isn't thread safe like the other vectors), causing non-deterministic behavior. i was the office hero for a week when i overheard them talking about it and after some questions found out that this was the root cause.
|
|
#
?
Feb 26, 2019 21:55
|
|
|
this is one of those things that got done because someone thought it would be cute, and of course it turns out to be a disaster
|
|
#
?
Feb 26, 2019 21:58
|
|
|
crazypenguin posted:this is one of those things that got done because someone thought it would be cute, and of course it turns out to be a disaster so ... programming?
|
|
#
?
Feb 26, 2019 22:07
|
|
|
JawnV6 posted:with every other place that C++ seems content to take a comparison and turn it into a callsite, i don't get why this would be a sticky situation? you can't have a uintptr_t as a backing store or w/e, but you can take a fat reference around and still have something usable vector<bool> does return a reference wrapper type that behaves like a normal reference 90% of the time. the problem is just that other 10% of the time where it behaves differently from any other vector<T>. vector<bool> would be a pretty good data structure if it was named bitvector
|
|
#
?
Feb 26, 2019 22:19
|
|
|
HappyHippo posted:some people at work got burned hard by this recently. they were writing to the elements in a vector<bool> on different threads. this is fine on every other type of vector (as long as different threads access different elements), but because the c++ spec special cases vector<bool> this way, writing requires reading, flipping the bit, and then writing again, which isn't thread safe (the spec goes out of it's way to specify that vector<bool> isn't thread safe like the other vectors), causing non-deterministic behavior. i was the office hero for a week when i overheard them talking about it and after some questions found out that this was the root cause. this is probably not a good idea anyway because of cache contention
|
|
#
?
Feb 26, 2019 23:17
|
|
|
that reminds me, is there a type system that can express "one consumer on this bus is really lovely and can't make guarantees about false sharing for an entire cache line. oh, and the next one too lol almost forgot"
|
|
#
?
Feb 26, 2019 23:34
|
|
|
rjmccall posted:this is probably not a good idea anyway because of cache contention I'm not super clear on the thing that they work on, but I believe it's a situation where there's a long calculation to produce a few values that are then written to the respective arrays.
|
|
#
?
Feb 26, 2019 23:37
|
|
|
JawnV6 posted:that reminds me, is there a type system that can express "one consumer on this bus is really lovely and can't make guarantees about false sharing for an entire cache line. oh, and the next one too lol almost forgot" I would love the ability to reason about caches in a programming language. it's so loving mysterious and magical.
|
|
#
?
Feb 26, 2019 23:42
|
|
|
gonadic io posted:I would love the ability to reason about caches in a programming language. it's so loving mysterious and magical. lots of reasoning about caches and invalidation more or less required, boatloads of fun
|
|
#
?
Feb 26, 2019 23:45
|
|
|
In case you're interested there's a bunch of work done in the distributed systems space, though it has more to do with abstractions around failure modes than "typechecking" aspects of your system https://www.youtube.com/watch?v=eAcDWcaezXY
|
|
#
?
Feb 26, 2019 23:50
|
|
|
HappyHippo posted:I'm not super clear on the thing that they work on, but I believe it's a situation where there's a long calculation to produce a few values that are then written to the respective arrays. okay, that’s basically the situation where it might be fine
|
|
#
?
Feb 26, 2019 23:53
|
|
|
gonadic io posted:I would love the ability to reason about caches in a programming language. it's so loving mysterious and magical. i have a similar problem with laziness in haskell: it's entirely invisible at compile-time, has the possibility to gently caress things up at runtime, and promotes cargo culting and random guesswork because even when you know what you're looking for it's not always obvious if it has the behaviour you want or not. it was why this paper which makes a unit test framework for specifying the laziness properties of your functions was so interesting: http://very.science/pdf/StrictCheck.pdf not that i really write any haskell any more, when i can just use similar langs that don't have this entire class of runtime gotchas. say what you want about lifetimes but at least they make it very clear at compile time if you hosed them up
|
|
#
?
Feb 26, 2019 23:58
|
|
|
It would be really cool if you could specify cache constraints for pieces of code in <programming language> and get warnings or errors when certain sizes are exceeded.
|
|
#
?
Feb 27, 2019 00:08
|
|
|
taqueso posted:It would be really cool if you could specify cache constraints for pieces of code in <programming language> and get warnings or errors when certain sizes are exceeded. well, except that cache sizes vary with same-isa systems, drastically
|
|
#
?
Feb 27, 2019 00:55
|
|
|
none of this makes any sense to me but please, carry on
|
|
#
?
Feb 27, 2019 03:22
|
|
|
Blinkz0rz posted:does rust have a usable http server yet? the linkerd2 proxy is written in rust, and while not a server, is still a major http implementation
|
|
#
?
Feb 27, 2019 03:35
|
|
|
JawnV6 posted:that reminds me, is there a type system that can express "one consumer on this bus is really lovely and can't make guarantees about false sharing for an entire cache line. oh, and the next one too lol almost forgot" why are you so obsessed with the idea that type systems are bad if they don't account for some arbitrary hardware behavior that you thought about 2 minutes ago
|
|
#
?
Feb 27, 2019 03:42
|
|
|
Phobeste posted:well, except that cache sizes vary with same-isa systems, drastically Lutha Mahtin posted:why are you so obsessed with the idea that type systems are bad if they don't account for some arbitrary hardware behavior that you thought about 2 minutes ago functional folks take the idea that "C is Bad" and run with it, assuring me that type systems obviate whole classes of bugs that they're certain fill up C programmer's days. im describing actual honest to god hardware that i've used C to interact with as examples of constraints that I sure would like some help with! im typing this post on a two-cache-line system irl right now, these are not fictional examples
|
|
#
?
Feb 27, 2019 03:52
|
|
|
i get that you know how hardware works but it's kind of tiresome itt to see someone post about a lang and then "oh but does your type system account for this  "
|
|
#
?
Feb 27, 2019 03:56
|
|
|
will your type system consider “8008135” as a number or the string “boobies”
|
|
#
?
Feb 27, 2019 04:15
|
|
|
probably no ordinary programming language is ever going to have a type system for dealing with weird hardware quirks ever. The closest is maybe static analysis tools. Now, the hardware poking bits could absolutely be done better. I think it was BlueSpec demonstrated the ability to write a big pile of code that did a thing, then draw a line down the middle to say "this part gets synthesized into hardware" and "this part gets generated as a driver for that hardware." of course, I think that was mostly an academic demonstration, not something they thought was ready for prime time. Plus, programming languages people and hardware design people have a long and bitter history of hating each other and calling each other stupid morons, so there's essentially no progress on this front ever. But I think that demonstration is evidence that improvements in driver writing pain-points will probably come from improvements in hardware description languages, not regular programming languages for writing software. assuming hardware description languages ever improve, ever
|
|
#
?
Feb 27, 2019 04:20
|
|
|
JawnV6 posted:arm has CLIDR and friends, x86 you could bodge together a monstrous LUT from ARK if you have to. didn't say they had to be compile-time warnings or errors have you considered trying out monads, op?
|
|
#
?
Feb 27, 2019 04:28
|
|
|
or sucking on these gonads
|
|
#
?
Feb 27, 2019 04:44
|
|
|
the price for being a hardware weenie is awful langs like c and vhdl are the problems horrible? yes. could pl folks potentially contribute better solutions? yes. shall the twain ever meet? NEIN
|
|
#
?
Feb 27, 2019 06:59
|
|
|
what if there were a language that let you do gross C things, but had nice modern features that let you build something non-terrible on top?
|
|
#
?
Feb 27, 2019 07:02
|
|
|
most modern langs are already like that: you can do the gross C stuff in an unsafe block, then build your nice modern poo poo on top of it. but then the modern lang isn't helping you with the gross C stuff, which is where many of the problems arise, so if you're doing primarily gross C stuff then why bother? hence people still program in C
|
|
#
?
Feb 27, 2019 07:10
|
|
|
Phobeste posted:well, except that cache sizes vary with same-isa systems, drastically but imagine your environment knew your targets sufficiently that when a new one with different behavior was added, you got a warning and could code for that too, selecting at runtime what to use running old code on a new implementation of an architecture might be suboptimal, but could also generate a warning or something so you know and could address in a subsequent release too
|
|
#
?
Feb 27, 2019 08:19
|
|
|
Lutha Mahtin posted:i get that you know how hardware works but it's kind of tiresome itt to see someone post about a lang and then "oh but does your type system account for this of course whenever people chime in with “the best way to do anything in any problem domain is via a sufficiently strong and parameterized type system,” … eschaton fucked around with this message at 09:40 on Feb 27, 2019 |
|
#
?
Feb 27, 2019 09:36
|
|
|
|
| # ? May 23, 2024 10:36 |
|
|
my new academic fp lang will make working with hardware trivial first, consider a spherical cpu in a vacuum;
|
|
#
?
Feb 27, 2019 10:08
|
|