This library provides types for working with arrays of Maybe values. The types in this library can be used as replacements for Array (Maybe a) and SmallArray (Maybe a) that consume less memory and have fewer indirections.
so haskell is so slow that you have to optimize array of maybes. And you can't do that properly you have use a totally new array type. It get sworse:
nothingSurrogate :: Any nothingSurrogate = error "nothingSurrogate: This value should not be forced!" {-# NOINLINE nothingSurrogate #-}
unsafeToMaybe :: Any -> Maybe a unsafeToMaybe a = case reallyUnsafePtrEquality# a nothingSurrogate of 0# -> Just (unsafeCoerce a) _ -> Nothing {-# INLINE unsafeToMaybe #-}
newSmallMaybeArray :: PrimMonad m => Int -> Maybe a -> m (SmallMutableMaybeArray (PrimState m) a) {-# INLINE newSmallMaybeArray #-} newSmallMaybeArray i ma = case ma of Just a -> do x do x Maybe a unsafeToMaybe a = case reallyUnsafePtrEquality# a nothingSurrogate of 0# -> Just (unsafeCoerce a) _ -> Nothing {-# INLINE unsafeToMaybe #-}
Hi guys! I'm doing hre some really low-level haskell (manual ptr management). I've got a container, which I created a debug Show instance for: instance Show (SmallVectorA a) where show = show . unsafePerformIO . toList . There is noinline pragma on it. However I observed that somertimes this show prints wrong values in non-threaded env. Coudl anybody tell me why it could happen? O jsut want to understand it
Matthew Bell
practical functional programming == bending over backwards to convince yourself you're not using global mutable state. if you don't tell no one will notice *wink*
Julian Carter
baka baka
Nolan Cook
haskell is gay the more languages developed the more lisp proves it was ahead of its time
1) IO is not the only monad 2) Entire point of IO monad is NOT having side effects in program, but moving them outside (into hypothetical runIO that lies outside main). Otherwise you could just have functions with side effects, like ML
Logan Lopez
Wrong. Monad literally means one or unit.
Lincoln Cruz
bunch of people debugging whether making Either strict or making patter matches lazy would fix a memory leak. nobody knows why its leaking. I Thought this language had GC>
Oliver Watson
Lol
Matthew Robinson
user this is 101 tier programming language shit. Everything has memory leaks GC or no.
Thomas Wood
GCed languages don't leak. I'm aware that webdev shitters have tried redefining what "leak" means to where simply not discarding something is a leak, but the real meaning of leak is that the object has leaked out of the programming environment and is no longer accessible to the program yet is still consuming resources. Allocating unmanaged memory and then losing the reference to GC would be a real leak in a GCed language, like with UnmanagedMemoryStream in C#.
Caleb Scott
There is no "redefining" here retard. Its what it means everywhere.
Yeah I know faggot, I told you it was redefined. We never used to call forgetting to free something a "leak".
Chase Thompson
Memory leak makes no sense if it's just memory you still have control over.
Analogy for the correct use of memory leak: - You fill a sink with water but there's a crack. Some water leaks out into the room. You can no longer remove all water from the room by emptying the sink as it has escaped from the sink.
Retarded modern definition by Java Pajeets: - You fill a sink with water. Pajeet points to the water in the sink and says some of it has leaked, yet it remains in the sink and can be emptied at any time.
In your second analogy you are forgetting the part where the water is overflowing the amount of water the sink can hold spilling out into the room.
Noah Anderson
You worthless goy, you can't even think for yourself, you trust the most manipulative people to decide what's true or false for you even when the correct answer is self-evident. Here's a patent application from 1997 with the definition we used to use of "memory leak" before Javafags co-opted a very old term. This is a legal definition that has been reviewed by a patent reviewer for accuracy. patents.google.com/patent/US6560773B1/en FUCKING OWNED, BITCH. SUCK MY DICK. CHOKE ON IT.
So he uses the same modern definition as wikipedia
Ayden Bell
...
Bentley Evans
...
Jace Ortiz
Haskell is a joke, but you actually have to be a smart person to get the punchline (and that can come at the cost of many months of having being sucked in to a secret club...)
yeah dude we should all have accepted that the earth was flat and was the center of the universe
Elijah Price
the rope awaits your supple neck numale.
Jason Morales
user this is not math
Lincoln Bailey
I'm partial to the "correct" one, but think about it like a cycle of a program not returning resources it's done with. It will take more each time in a way that's unsustainable and doesn't reflect actual resource use.
Luis Perry
"correct" aka the wrong one
Jacob Murphy
...
Mason Parker
Yeah memory usage increasing forever when it should be freed. No way that could be a memory leak.
Christopher Cox
"The toilet leaked" t. Zig Forums user
Jaxon Jenkins
bad analogy We don't call it a garbage collector leak
Anime rotted your brain. Ask your doctor if it's not too late to reattach your balls so you can resist shoddy redefinitions of a phrase that used to make sense.
Austin Reed
LOL
Robert Rivera
You mean the original definition that it has always been used by everyone except for larpers like you.
LOL Memory in C can leak or clog. Memory in a GCed language can only clog. Negligently not cleaning when you should leads to a clog. Losing the ability to clean is a leak. This is superior terminology and I shall use it from now on and you should, too.
This only supports my point, user. There are two issues: - Unreachable memory - Neglected memory In C: - Unreachable memory -> leak - Neglected memory -> clog In Java: - Unreachable memory -> normal operation - Neglected memory -> clog GCed languages CANNOT LEAK! Wikipedia agrees.
Joshua Butler
...
Carter Turner
No you retard. It's that losing a handle in a manual language causes a leak. Where as losing a handle in a managed language does not. Not every leak is caused by losing a handle. JFC what pajeet university did you graduate from. Get off this board kid.
It's not an error as far as the language is concerned. The language is still operating properly and tracking resources in the memory clog scenario. I can even connect in via JPDA and unclog a running instance if really necessary (e.g. a Mars probe). Real memory leaks are legitimate errors at the language level as the ability of the language to ever do anything about it is gone. For implementations of malloc that don't store the metadata necessary to do a heap walk, I couldn't even cure a running instance via hacking outside of the language with ptrace. That Mars probe is fucked. Static analysis cannot identify memory clogs, but it can often identify memory leaks. That's a clue that they're completely different issues. It's never too late to make a change. You just have to persist and not give up. RMS persisted for almost 25 years on the GNU/Linux naming and today many people call it GNU/Linux. Being shut down by a mere wikipedia page where the term is obviously inaccurate is pathetic and shows a lack of necessary autism for programming.
Humm let me google your new shitty term "memory clog"... first result: :^)
Evan Watson
It's disingenuous. GC proponents never mention how severe the penalty of compaction-based GC is in cache-constrained code which is practically everything fast today. And they need it to make their claims about generational collection not being slow. The first rule of optimizing GCed code is to avoid ever freeing anything which should tell you something about how fast GC really is in practice. Meanwhile, fast C code avoids malloc/free, we use slabs. In networking, we do this not just for speed but for reliability - it avoids unpredictable memory use due to fragmentation that could cause a crash. Were GC a better method we'd use boehmgc.
Proper GCed languages (Javalikes) don't have slab allocators as they're limited by type safety. The closest thing without resorting to unsafe code is object caching. Back to India, Pajeet.
Dylan King
what kind of retard faggot are you
Samuel James
You must contribute so much.
Robert Perry
okay rat. more c fags that think they are the only ones that can do pointer arithmetic. it is simply impossible to manipulate the hardware in anything other than c.
I know a lot about everything, qt. I actually program.
Jonathan Edwards
Just make sure to wash your hands before using the computer Aditya then you can continue your Java allocator work.
Mason Barnes
How did you even manage to finish typing this? Who gives a shit what the language thinks? On the many subjects of human error, languages are either helpful or not. Mostly, they're not.
Hunter Thomas
Is it that hard to process? Memory clogs are a significantly different class of error. It's an error that the language cannot tell is an error, and thus static analysis cannot tell is an error, and thus runtime analysis cannot tell is an error, but can be corrected at any time during execution by a sufficiently capable language (many safety-critical languages have facilities that can be used for that purpose). It's impressively stupid to try to roll that up with memory leaks, which are errors according to the language, and thus can often be detected by static analysis, and thus can often be detected by runtime analysis, but might become uncorrectable by any means during execution. Memory leaks are a systemic failure, not just a decision made by the human that is later considered to be a mistake. As such, they are far more dangerous and warrant care to avoid. They're also worth designing automated tools to identify, and doing research on finding the best methods of detection and avoidance. There's no point to doing research on memory clogs as their cause is your programmer is a slob. No automated tool can save them from being a slob. The only tools in this space are heap visualizers which assume your slob is too slovenly to notice a problem without a visualizer rubbing their nose in it until they decide to change.
This is incorrect. Imagine this scenario. When a user connects to the system a user object is created. When the user disconnects this user object should turn into garbage. You can prove that this happens by showing that all the references to it have been removed. I don't get why you think it is impossible. These """clogs""" happen when an object does not turn into garbage at the end of its desired lifetime.
