> Sales of JR East's Suica card (image of a penguin on the front) will be discontinued for the time being as of June 8 due to a worldwide semiconductor shortage. [1]
Welcome Suica (for short-term visits):
> Welcome Suica sales will be limited to the following for the time being from December 18th:
> * JR EAST Travel Service Center, Haneda Airport Terminal 3 Station
> * Welcome Suica exclusive vending machine, Tokyo Monorail Haneda Airport Line Haneda Airport Terminal 3 Station
> Please note that only one Welcome Suica will be sold per person.
> Please note that IC cards will not be sold at Narita Airport after the 18th. [2]
PASMO:
> The sale of blank PASMO has been temporarily suspended.
> The sale of Personalized PASMO has been temporarily suspended. [3]
PASMO PASSPORT (for short-term visits):
> The card is available for purchase at 21 locations. [4]
This is partly misleading and partly out of date: Welcome Suicas have been available at the airport throughput, and regular Suicas are available again at major JR East stations.
Thanks for the additional info. I didn’t intend to mislead; the quoted passages are straight off the Suica and PASMO websites, so they are only outdated insofar as those websites are outdated.
If you have an iPhone, just change your phone region to Japan, and use wallet app to add Suica card to your apple wallet. You can charge whatever amount to your Suica card using Apple pay and it's good to go.
There’s no need to change any region; just open Wallet, press the + sign in upper right corner, scroll down to transit cards, and scroll down to Japan section to find Suica as well as PASMO and ICOCA.
I love org mode for writing and that side of org is brilliant. It’s not just a task manager. In fact I’d love just a note taking tool that doesn’t care as much about tasks but focuses on a outstanding org mode note taking experience on mobile.
Disagree. Type erasure is actually one of th best possible decisions made by the java designers.
Languages that have higher kinded types (Haskell, Scala)are virtually impossible to implement without type erasure. This is why the .net runtime doesn’t have languages with HKT
I don't see how the absence of type erasure could possibly be a restriction. Cast everything to object if you must.
I've literally never run into a situation where I wished type erasure was there but didn't have it, but I've ran into situations where type erasure caused problems in Java and where the absence of type erasure let me do things the way I wanted in C#. typeof(T), new T[], new T(), default(T), etc.
> I don't see how the absence of type erasure could possibly be a restriction. Cast everything to object if you must.
Erasure can be nicer than casting to object everywhere, especially when dealing with interfaces. It means you don't have to define separate interfaces for the erased and specialized cases.
e.g. in Java, implementing List<T> means you also implement List. Meanwhile, in C#, you have to implement both IList and IList<T> if you want to be able to use a collection in an erased context (and even then, the interfaces don't provide exactly the same functionality). Implementing both IList<T> and IList<object> isn't much of an improvement.
> I've literally never run into a situation where I wished type erasure was there but didn't have it, but I've ran into situations where type erasure caused problems in Java and where the absence of type erasure let me do things the way I wanted in C#. typeof(T), new T[], new T(), default(T), etc.
IMO most of these aren't too bad to work around. Although, sometimes erasure can cause problems with reflection and you have to use Guava's TypeToken or something similar.
One definite problem with erasure is that it doesn't play nice with unboxed value types.
Sure, good interface design can ease things, but it doesn't really solve the problem I'm talking about.
In Java, List<Foo> and List<Bar> are the same interface. In C#, IList<Foo> and IList<Bar> are different interfaces that just happen to have similar properties/methods.
Right, but again, it means you're implementing two separate interfaces. You can implement IList without implementing IList<T>, and you can implement IList<T> without implementing IList.
> Of course it could be implemented type-erased style, but that's an unpleasant can of worms.
> If it were implemented like C++ templates, it would be a source level feature, meaning you can't have higher kinded polymorphic methods in assemblies. I think we can reach consensus that such a feature would only pollute the language.
> If it were implemented like Java generics, it would lead to all sorts of nonsense. For example you couldn't do typeof(M<>) inside the hkpm, since the type has been erased.
And then a complex-but-good implementation idea follows. Type erasure is not necessary in this case.
The complexity is exactly is issue. So while it’s possible to implement on the .net runtime without type erasure, it’s hard.
Plus the only reason type erasure is bad is if you want reflection. Which in FP languages with a solid type system isnt idiomatic and safe anyway.
Edit: value types are one other reason for not using erasure but Can be done other ways
They aren't that well trained either. And most well trained people will never clean and jerk 300+lbs. Even if every single kid who tried a 300lbs+ clean and jerk died from it on the spot, that still wouldn't make enough of a dent to make lifting a high risk sport.
The thing worth keeping in mind that people forget when questioning whether kids should lift, is that kids lift, or try to lift large percentages of their body weight to failure all the time during normal play. They have a training capacity and recovery ability that makes me insanely jealous as someone who's turned 40.
If lifting the weights they are physically able to is dangerous for them, then so is a lot of their regular playing.
Is there a way to do XMonad style layouts with this system? Since moving to OSX, I've missed Xmonad badly. The big thing that has been lacking is the ability for newly opened windows to automatically be placed into a grid, according to the layout that is currently defined, and then have the ability to shuffle windows around within that layout.
That should be a really easy config, especially after events are added in 1.1; I'll see what I can do it create it and add it to the wiki, unless someone beats me to it :)
reply