Singpolyma

Priority Continuum Onyx Unboxing and Assembly (Photos)

Posted on

Healthy lifestyle

Posted on

Staying healthy is at the top of nearly everyone’s priority list, and our daily choices can determine just how healthy we are. Not everything is in our control, but the habits and approaches we take to our health can often make a difference between being healthy and unhealthy.

Two areas we have the most control over are our diet and exercise. These can both have huge effects on overall health, and can be some of the main factors in preventing disease and other complications later in life. Preventive healthcare measures like proper diet and exercise can also help your budget. Try out leanbiome.

What are some of the key benefits associated with a good diet and proper exercise? Let’s look at that, but first, let’s start off with some general diet and exercise recommendations.

Recommendations
Exercise: In general, you should be aiming for at least two-and-a-half hours of medium-intensity exercise per week, or a slightly lower amount of high-intensity exercise. Mixing aerobics in with things like weight training or sports is a great way to vary your workouts. Make sure to stretch before and after exercising, and take appropriate safety precautions.

Diet: Dietary needs differ for every person, but in general, some of the best foods you should regularly eat include:

Fruits and vegetables
Protein
Whole grains
Nuts and legumes
Try to balance items like dairy and oils, along with meats and poultry. Try to avoid sweets, overly salty foods, trans fat-heavy foods and overuse of alcohol. Pay attention to calorie count—your needed amount will vary based on your size, age and gender.

Disease Prevention
The largest benefit of a great diet and regular exercise is the way it helps your body stave off diseases and other conditions. Your body’s immune system is a complex machine, and diet and exercise can heavily affect it. Too many of the wrong foods can put you at risk, but the right foods complemented by appropriate exercise can actually boost your body’s ability to fight disease. Check these protetox reviews.

Some of the diseases that a good diet and regular exercise can prevent include:

Heart disease
High blood pressure
High cholesterol
Diabetes
Stroke
Depression
Several types of cancer
Arthritis

Mood and Energy
Both diet and exercise, especially the latter, can have major effects on your mood. Chemicals in the brain called “endorphins” make you feel happy and positive, and these are triggered by most forms of exercise.

Diet can have many of the same effects, and there are indicators out there suggesting that proper diet and exercise are two major factors in overall mental health. Both help reduce stress and can increase brain activity. Endorphin stimulation can also help prevent depression and raise self-esteem.

Weight
Weight is one of the key factors involved in heart disease, high cholesterol or blood pressure and several other conditions. What are the top two factors that influence weight? You got it, diet and exercise.

Sleep
Sleep issues are a concern for millions of people around the globe, and diet and exercise can influence your sleep habits. Exercise, in particular, can directly impact your ability to fall asleep and stay asleep. It’s recommended that you don’t exercise heavily or eat right before bedtime, but proper habits in both areas can turn restless nights into comfortable ones. Improve your results with ikaria lean belly juice.

If you are trying to improve your exercise and dietary habits, consult with your primary care provider. He or she will be able to get you on a plan that’s right for you.

Error Handling in Haskell

Posted on

When I first started learning Haskell, I learned about the Monad instance for Either and immediately got excited. Here, at long last, was a good solution to the error handling problem. When you want exception-like semantics, you can have them, and the rest of the time it’s just a normal value. Later, I learned that the Haskell standard also includes an exception mechanism for the IO type. I was horrified, and confused, but nothing could have prepared me for what I discovered next.

While the standard Haskell exception mechanism infects all of IO it at least has a single, well-defined type for possible errors, with a small number of known cases to handle. GHC extends this with a dynamically typed exception system where any IO value may be hiding any number of unknown and unknowable exception types! Additionally, all manner of programmer errors in pure code (such as pattern match failures and integer division by zero) are thrown into IO when they get used in that context. On top of everything, so-called exceptions can appear that were not thrown by any code you can see but are external to you and your dependencies entirely. There are two classes of these: asynchronous exceptions thrown by the runtime due to a failure in the runtime itself (such as a HeapOverflow) and exceptions thrown due to some impossible-to-meet condition the runtime detects (such as detectable non-termination). Oh, I almost forgot, manually killing a thread or telling the process to exit are also modeled as “exceptions” by GHC.

Once the initial decision to have a dynamically typed exception system was made, everything that could make use of an exception-like semantic in any case was bolted on. What am I going to do, though? Write my own ecosystem and runtime that works how I would prefer? No, I’m going to find a way to make the best of the world I’m in.

When dealing with this situation, there are two separate and equally important things to consider: exception safety, and error handling. Exception safety describes the situation when you are, for example, acquiring and releasing resources (such as file handles). You want to be sure you release the resource, even if the exception system is going to abort your computation unceremoniously. You can never know if this will happen or not, since the runtime can just throw things at you, you always need to wrap resource acquisition/release paths in some exception safety. There are a lot of complex issues here, but it’s not the subject of this post so suffice to say the main pattern of interest for dealing with this is bracket.

Error handling is totally different. This is where you want to be able to recover from possible recoverable errors and do something sensible. Retry, save the task for later, alert the user that their request failed, read from cache when the network is down, whatever.

The first move in this area that I saw that I liked, was the errors package. Many helpers for dealing with error values, and in earlier versions a helper that would exclude unrecoverable errors and convert the rest to error values. I liked this pattern, but wanted more. This is Haskell! I wanted to know, at a type level, when recoverable errors had already been handled. Of course, programmer errors in pure code and unrecoverable errors from the runtime are always possible, so we can’t say anything about them at the type level, but recoverable errors we could know something about. So I wrote a package, iterated a few times, and eventually became a dependency for the helper in the errors package that I had based my whole idea on. Until very recently, errors and unexceptionalio were the two ways I was aware of to handle recoverable errors (and only recoverable errors) reliably, and know at a type level that you had done so. Recently errors decided to change the semantic to fit the previously-misleading documentation of the helper and so unexceptionalio now stands alone (to my knowledge) in this area.

In light of this new reality, I updated the package to make it much more clear (both in documentation and at a type level) what hole in the ecosystem this fills. I exposed the semantic in a few more ways so it can be useful even to people who don’t care about type-level error information. I also named the unrecoverable errors. Things you might want to be safe from, or maybe log and terminate a thread because of, but never recover from. For now, I call these PseudoException.

UnexceptionalIO (when used on GHC) now exposes four instances of Exception that you can use even if you have no use for the rest of the package: ExternalError (for things the runtime throws at you, asynchronously or not), ProgrammerError (for things raised from mistakes in pure code), PseudoException (includes the above and also requests for the process to exit), and SomeNonPseudoException (the negation of the above). All of these will work with the normal GHC catch mechanisms to allow you to easily separate these different uses for the exception system.

From there, the package builds up a type and typeclass with entry and exit points that ensure that values in this type contain no SomeNonPseudoException. The type is only ever used in argument position, all return types are polymorphic in the typeclass (implemented for both UIO and IO, as well as for all monad transformers in the unexceptional-trans package) so that you can use them without having to commit to UIO for your code. If you use the helpers in a program that is all based on IO still, it will catch the exceptions and continue just fine in that context.

Finally, the latest version of the package also exposes some helpers for those cases where you do want to do something with PseudoException. For exception safety, of course, there is bracket, specialized to UIO. For knowing when a thread has terminated (for any reason, success or failure) there is forkFinally, specialized to UIO and PseudoException. Finally, to make sure you don’t accidentally swallow any PseudoException when running a thread, there is fork which will ignore ThreadKilled (you assumedly did that on purpose) but otherwise rethrow PseudoException that terminate a thread to the parent thread.

This is hardly the final word in error handling, but for me, this provides enough sanity that I can handle what I need to in different applications and express my errors at a type level when I want to.

Haskell2010 Dynamic Cast

Posted on

This post is not meant to be a suggestion that you should use this code for anything. I found the exploration educational and I’m sharing because I find the results interesting. This post is a Literate Haskell file.

Programmers often mean different things when they say “cast”. One thing they sometimes mean is to be able to use a value of one type as another type, converting as possible.

We’ll use dynamic typing to allow us to check the conversions at runtime.

> module DynamicCast (DynamicCastable(..), dynamicCast, Opaque) where
> import Data.Dynamic
> import Data.Void
> import Control.Applicative
> import Control.Monad
> import Data.Typeable
> import Text.Read (readMaybe)
> import Data.Traversable (sequenceA)

But we don’t want to expose the dynamic typing outside of this module, in case people become confused and try to use a Dynamic they got from elsewhere. Really we’re just using the Dynamic as an opaque intermediate step.

> newtype Opaque = Opaque Dynamic

Types can define how they both enter and exit the intermediate representation. This both allows casting existing types to new types, but also can allow casting new types to existing types without changing the instances for those existing types.

> class (Typeable a) => DynamicCastable a where
> 	toOpaque :: a -> Opaque
> 	toOpaque = Opaque . toDyn
>
> 	fromOpaque :: Opaque -> Maybe a
> 	fromOpaque (Opaque dyn) = fromDynamic dyn

And finally the cast itself.

> dynamicCast :: (DynamicCastable a, DynamicCastable b) => a -> Maybe b
> dynamicCast = fromOpaque . toOpaque

Let’s see some examples.

We’ll say that Integer and simple lists (including String) represent themselves and define no specific conversions.

> instance DynamicCastable Integer
> instance (Typeable a) => DynamicCastable [a]

Int is represented however Integer represents itself.

Anything that can convert to Integer can convert to Int.

Any String that parses using read as an Int can also convert to an Int.

> instance DynamicCastable Int where
> 	toOpaque = toOpaque . toInteger
> 	fromOpaque o = fromInteger <$> fromOpaque o <|> (readMaybe =<< fromOpaque o)

And now

dynamicCast (1 :: Int) :: Maybe Integer
Just 1

dynamicCast (1 :: Integer) :: Maybe Int
Just 1

This is pretty obvious and boring, but perhaps it gives us confidence that this is going to work at all. Let’s try something fancier.

Void is the type with no inhabitants, so it can never be converted to.

> instance DynamicCastable Void where
> 	fromOpaque _ = Nothing

Either is represented as just the item it contains, and any item can be contained in an Either.

> instance (DynamicCastable a, DynamicCastable b) => DynamicCastable (Either a b) where
> 	toOpaque (Left x) = toOpaque x
> 	toOpaque (Right x) = toOpaque x
>
> 	fromOpaque o = Left <$> fromOpaque o <|> Right <$> fromOpaque o

And now

dynamicCast 1 :: Maybe (Either Int Void)
Just (Left 1)

dynamicCast 1 :: Maybe (Either Void Int)
Just (Right 1)

dynamicCast (Left 1 :: Either Int Void) :: Maybe Int
Just 1

Maybe is very similar, store the Just as the unwrapped value, and store Nothing as Void.

> instance (DynamicCastable a) => DynamicCastable (Maybe a) where
> 	toOpaque (Just x) = toOpaque x
> 	toOpaque Nothing = toOpaque (undefined :: Void)
>
> 	fromOpaque = fmap Just . fromOpaque

dynamicCast (Left 1 :: Either Int Void) :: Maybe (Maybe Int)
Just (Just 1)

To be able to cast the contents of a Functor, the possible failure also lives in the Functor, so we need a wrapper.

> newtype FunctorCast f a = FunctorCast (f (Maybe a))

> mkFunctorCast :: (Functor f) => f a -> FunctorCast f a
> mkFunctorCast = FunctorCast . fmap Just

> runFunctorCast :: FunctorCast f a -> f (Maybe a)
> runFunctorCast (FunctorCast x) = x

> runTraversableFunctorCast :: (Traversable f) => Maybe (FunctorCast f a) -> Maybe (f a)
> runTraversableFunctorCast = join . fmap (sequenceA . runFunctorCast)

> instance (Functor f, DynamicCastable a, Typeable f) => DynamicCastable (FunctorCast f a) where
> 	toOpaque = Opaque . toDyn . fmap toOpaque . runFunctorCast
> 	fromOpaque (Opaque dyn) = FunctorCast . fmap fromOpaque <$> fromDynamic dyn

runTraversableFunctorCast $ dynamicCast (mkFunctorCast ["1"]) :: Maybe [Either Void Integer]
Just [Right 1]

Thoughts After #ccsummit

Posted on

This year I again attended the Creative Commons Global Summit. There were many great sessions and participants both last year and this year, but I’ve had this growing feeling I can’t shake.

My emotions were best summed up by a conversation I had with a friend just after the conference had ended. “How was your conference?” he asked. “Oh, it was good.” I replied. “Lots of Free Culture?” he asked. There was an awkward pause, “Uh… not really.” “Yeah,” he said, “Free Culture is dead. We lost.”

That’s not to say the the causes of Libraries, Museums, Open Access, Open Science, and Open Data are not good. It’s not to say the conference wasn’t full of many noble things that I support. But Free Culture is just not on anyone’s agenda.

I’ve been saying for awhile that it seems like the Free Culture community has lost leadership and momentum, that there is no rally point, no meeting place. But the truth may be that this is just the symptom of having moved on.

I think there are a couple of reasons for this. One is that the Free Culture movement was always born out of a desire to access *existing* cultural resources, and not to replace them. This means that Free Culture advocates are more likely to spend effort advocating for Fair Dealing / Fair Use, exceptions to copyright, and “balance” rather than promoting Free Culture artists and works. There has also just been more success with education. No work of Free Culture (unless you stretch to include Wikipedia) has had any mainstream cultural impact. The Open Access and OER movements by contrast are changing the face of education around the world. It’s also just a function of students and others who were heavily involved maturing and losing the free time they had to spend on movement activities.

But what could it mean for Free Culture to be “dead”? According to last year’s State of the Commons report, there are on the order of 780 million Free Culture works on the Internet, and the number is growing daily. The licenses are alive and well, and while this report may over-count some things (due to user error, etc, when marking the license of a work) it seems like there is a lot of Free Culture out there. I think, however, that the movement has stalled. Free Culture is just an option in a dropdown on a hosting platform now.

Some might see this as a sign of success. At one point, no one had heard of Free Culture or Creative Commons, now many major hosting platforms offer the licenses as an option. I think it depends on what you see as the goal, and what you think of as success.

For me, right now, short-term success is getting to the point where at least one body of Free Cultural work (needs to be more than a standalone work, probably, to have staying power) achieves mainstream cultural impact. Where I could mention this body of work to someone totally unrelated to the movement and they would have at least a halfway chance of having heard of it.

Awhile ago now the main Vlogbrothers channel went CC-BY. This is certainly a body of work with a reasonable amount of success, and so is very good progress in this area.

However, my favourite to support for this remains Pepper & Carrot a born-free, community-supported webcomic by David Revoy. Revoy is a Free Culture and Free Software supported, and he really seems to understand why this sort of thing is necessary, and how to go about it. He not only embraces, but encourages and promotes all kinds of derivative works both non-commercial and commercial in nature. I think this may be a real shot to have a somewhat-well-known, ongoing franchise with only loose central management. I will continue to do what I can, and continue to remain hopeful.

If you want to connect with like-minded Free Culture enthusiasts, I recommend joining the WIFO Forum.