Therefore the straightforward way to parse a zip file is to proceed from the beginning and parse out each file sequentially. The End of Central Directory record is then only a redundant convenience to avoid sequentially scanning files e.g. in large zips for random access.
Interesting. It makes sense to be strict when parsing stream input. Skipping the redundant central directory section hadn't even occurred to me. Bonus points for eliminating the stupid comment confusion dilemma!
On second thought, not entirely redundant, as the central directory does contain the file permissions. But those can be parsed and set after file extraction, without increasing the overall memory complexity.
With LetterSnap, take pictures of text and extract the actual text. The app is powered by Google Cloud Vision, which lets it tackle weird fonts, Chinese + Japanese, colored backgrounds, text at an angle, most anything you can throw at it. I also wrote the simplest, fastest workflow I could conceptualise -- one or two taps to get the text, that's it!
You can definitely compose a zip file "on the fly" and stream it out. The central directory at the end of the zip file can be determined from all the content already streamed.
The only wrinkle is that each entry has a header which typically states the compressed size and checksum. Either you have to compress each entry content in some temp buffer or file to figure out the compressed size and checksum, then write out the header and compressed content. Or you write out the header with these fields zeroed, then compress the content on the fly and write it out, then write out a data descriptor with the compressed size and checksum.
What the parent is saying is that the client has to buffer the entire zip file before they receive the index and can begin decompressing it. "Streaming compression" usually implies streaming decompression as well—importantly because a non-negligible use case for streaming compression is sending streams of compressed data that won't fit on the destination together with the decompressed copy; or sending continuous streams of compressed data that could never reach the end to be decompressed. What the parent is saying is that zip cannot work for these use-cases.
I have the book too. It's interesting as a history lesson and initial motivations for Objective-C.
In particular, in the beginning Objective-C was a lot looser typed at compile time than it is now: no NSString* or NSWindow*, it was all just id. It was an attempt to make C look like Smalltalk.
The language eventually evolved more toward the static-typed end of the spectrum, culminating in support for lightweight generics and ostensibly birthing Swift along the way.
I've been a Type 2 diabetic officially for 18 years but impaired glucose tolerance for longer. You're on the right path, there's a lot you can do to slow down the progress of the disease.
I'm not a doctor however so take any advice with a grain of salt. (But not sugar, definitely not that.)
> I keep reading that the problem is carbohydrate overload to my genetics.
Read up on "glycemic index". This index tells you how close your food is to pure glucose e.g. table sugar has a glycemic index of 68 so it has 68% of the insulin response of pure glucose. The index correlates to the type of carbohydrate and how processed it is, although there are some surprises e.g. premium ice cream has a G.I. of 37.
You don't have to commit the entire index to memory. Usually you can come up with several heuristics e.g. tropical fruit tends to have higher G.I. than temperate fruit.
Obviously you should test this with your own blood sugar readings as individual response to a carbohydrate challenge can be quite different.
The other components to a meal also affect blood sugar. For example, acid, protein and fat tend to slow down digestion and thus blood sugar spiking. If you must take pasta for example, take it with a tomato-based sauce (acidic) rather than cream-based. YMMV.
> Unfortunately, my doctor thinks that pushing pills is an adequate response, which I heartily doubt.
It's important, although somewhat depressing, to see this disease as a progression. A progression that you have to slow down as much as possible, but still a progression.
Know that in the future, you may have to resort to the first line of pills, and then possibly stronger ones. Try to slow down the progression as much as possible, and research the pills to see their efficacy and benefit.
Metformin is usually the first line of defence and it has a long history and little side effect. It generally fools your body into thinking it's in starvation mode, which means you can lose weight, both fat and muscle. It actually lowers insulin resistance rather than increasing insulin. Generally in amounts >1g it gives you loose bowels, so when you have to use it keep on low doses as long as possible.
When metformin doesn't work as well, generally you'll get prescribed sulfonylureas. Since they increase insulin secretion, they tend to exacerbate your insulin resistance. There is some inconclusive research that they burn out the pancreatic beta cells. Better to avoid these as long as possible, but if your glucose control is bad you may not have a choice.
I'm currently on an incretin enhancer (gliptin) + metformin.
Also look up supplements on examine.com. It's hard to tell the effectiveness of supplements, the only one that had a distinct effect on me was berberine.
The other thing you can do is exercise. Lots of it. Strength training for more muscle and more insulin receptors. Aerobic exercise to burn/absorb more glucose and lose weight. There's even recent evidence that high-intensity interval training improves diabetic markers more than sustained, low-intensity exercise.
Curcumin is poorly absorbed but there are several ways to increase the bioavailability[1]. Otherwise too little will be absorbed to be effective, and you'd just be ingesting an expensive placebo.
You could
* Combine it with black pepper, warmth and/or oil.
* Use the Meriva or BCM-95 form.
* Use nanoparticles, marketed as Theracurmin/Theracumin.
Most nights, I combine two caps of Theracurmin with fish oil and lukewarm water for my wife to drink. It does seem to help with her arthritis.
It's probably an informal use of the word "lying" prevalent in tech culture. When I was working in a moderately sized software company in Australia, engineers would often say, "xyz. Oops, I lied. It was abc." It's a shorthand for "I made a mistake, what I said before was false, although I believed it true at the time." No actual intention to deceive here.
I suspect this originated with autistic individuals finding it hard to actually lie, i.e deceive. This relates to their shallow theory of mind, or difficulty believing other people have different thoughts and ideas from them or the absolute "truth". This idea has subtly spread through science and tech culture since many practitioners are on the spectrum, where some absolute truth is held up for admiration and significant deviation is uncomfortable.
For example, "code never lies." So if I say "xyz" about the code and it is false, I am "lying".
Hi, this is a full rewrite of my iOS diagram sketcher -- it took 4.5 years, 30 features, 400 commits and lots of prayer. It uses Objective-C, Core Animation, UIKit, the works.
The shape recognition is a custom C++ library I call Recog, based on naive Bayesian classifier on geometric statistics.
The automated layout engine is Graphviz, as is the native file format (wrapped in my open-source zip library zipzap).
The help videos are not embedded in code, but are stored in Amazon S3 fronted by CloudFront. That also fronts a small web service written in node.js + sqlite3 for indexing the videos.
In ARC, all strong pointers may have multiple owners. In C++11 RAII, the typical, defining use is for single owners (std::unique_ptr) but multiple owners are supported too (std::shared_ptr).
In ARC, local pointers may be reclaimed before their scope ends, if the compiler determines no further use of the pointer. In C++11 RAII, all such resources are reclaimed only at scope end.
ARC is not exception-safe by default, you have to compile with -fobjc-arc-exceptions to make it exception safe; however Apple standards have been moving away from using exceptions for recoverable conditions for some time now. C++11 RAII is of course exception-safe by default, it's one of the rationales behind the technique.
http://stackoverflow.com/a/12393597/60910
Therefore the straightforward way to parse a zip file is to proceed from the beginning and parse out each file sequentially. The End of Central Directory record is then only a redundant convenience to avoid sequentially scanning files e.g. in large zips for random access.