When I saw the blog-hosting services, I didn't like it because of inability to keep a local back up. Some seemed to be offering a capability of taking a local back up copies, but then what about restoration? What if they terminate the service? Is it easy to transfer my blog to a different service? Looked to be hell difficult. I didn't buy them. I am stubbornly using an old-school web site.
When I saw Social Network Services like Facebook, MySpace, and Mixi, I wondered why
people do what they can do with a personal web site with less control.
I also am bothered by the
inability to take a local back up and restoration.
The contents of my web site is mine. I sacrificed money, time, youth,
social life, and hair to learn programming. Why do I have to give away my
and let them make money?
I do have a FaceBook account.
But, I'm using it just as an automatically-updating address book. I
will never ever upload anything to FaceBook.
I will never ever upload anything to FaceBook.
When I saw GitHub, I was frightened by every open-source projects concentrated in one web service. If I were an evil programmer, here's what I would do. I would hack into a source repository and then inject a malicious code into a source code of a very popular software title. Next time the build from that repo is released, the official copy of the title will distribute my code for me. Now everyone uploads code to GitHub, such a hacker knows exactly where to target. Therefore I am still stubbornly keeping my own private repository local.
What's common about above my concerns are the centralization.
Everyone tries to lock you in to their service and make hard to leave.
What's common about above my concerns are the centralization. Everyone tries to lock you in to their service and make hard to leave.I was thinking I was only one person who is concerned about the centralization. Surrender of controls over contents, not just private information. The trend was not going to the right direction in my view. People talk about problems of those SNSes, but nobody seemed to be concerned about getting locked in to a specific network.
Apparently, someone else does have concern. A famous guy. I 100% agree with the philosophy of the Solid project. https://solid.mit.edu/ (Hmmm, I cannot agree more to their philosophy, but they are hosting the sources in GitHub.) Right now I have problem in how to make my open-source part of my code public. I haven't been able to release them in a timely fashion because I always get higher-priority tasks than making and testing a release package. I rather want to open read-access to my public repository to public. GitHub for sure will host my open-source projects, but I don't want to be a part of the centralization. I'm looking into the Solid project to see if it can solve my problem.
So, I created my POD, but I haven't been able to do anything useful yet. Maybe it does not work with Firefox.
A lucky day
We often hear a story like someone almost boarded a flight that was going to crash barely missed the flight for survival due to an errand, traffic, or something seemingly a bad luck. Some see them as a miracle, but because an airliner can carry so many people, those kind of story should happen from time to time. Probably one or a few passengers are failing to make a flight in almost all of such flights. If it crashes, a few persons 'luckily' survives. Just a statistics. Therefore, statistically I have a same chance of getting that kind of episode. Well, in my case it was not that dramatic, but I was driving to bowling league yesterday it happened.
I saw a few police cars running toward the direction I was heading, so I presumed there was an accident. It turned out the area was flooded. Police car was running there to block the road. It was temporary just lasting about an hour, but I saw several cars towed out of the area. Probably those cars submerged to the engine level and could not run by itself any more. I didn't hear any fatality in the news. I guess people just got soaked and lost their vehicle.
So, if I left home 5 minutes or so earlier, I could have been submerged. But, since the rain was so hard, I called my wife, she is also working for Carnegie Mellon by the way, and offered a ride home before heading for the bowling league. That delayed my departure by 10 minutes. If I hadn't done that, my car would have been towed out of the flooding area. What a luck!
Due to the road closure until the water flowed down to the nearby Monongahera river, I missed the practice shots, and I had to jump in to the first game without warming up. I left three open frames and bowled 169 in the first game, but I was able to catch up the lane condition in the second game, bowled 211. The last game was frustrating, I was leaving one pin most of the frames. All adjustments didn't work. Nonetheless I picked up one 6-7-10 split, and killed my nemesis of no. 10 pin in all attempts. I guess it was my lucky day after all.
My First Logbook Completed!
I have been fixing YSFLIGHT code cursing macOS 10.14. But, today I took a nice break from a frustrating task and flew from Beaver County, completing my first flight logbook! (Read more)
Looks like I was stepping on another landmine of macOS 10.14, which destroys cached NSMutableDictionary somewhere. I could look into it deeper to pin-point exactly where it is destroyed, but I don't want to waste no more time. My font-renderer was using a cached NSMutableDistionary, but I changed so that my font-rendering function allocates and releases a NSMutableDictionary every time it is called. It is inefficient, but didn't make any visible loss of performance, and works on macOS 10.14.
But, the error was caught during unit tests. I am glad I spent time to set it up.
.... How can I tell if I addressed all undocumented changes in macOS!? I did run my unit tests, but I cannot think my tests cover everything.
Actually, my iPhone 5S no longer charges from PC USB port after upgrading to iOS 12. I need to use a larger-output (like 2.4A) USB charger. I don't think I had a good luck with OS upgrades from Apple this time.
Actually, the fix for macOS 10.14 actually influenced the other part of the code bigger than initially expected. YSFLIGHT is running on macOS 10.14 somewhat ok, but it broke Windows and Linux versions. I think I fixed mostly, and a few more steps to go. But, I'll make another test version before running the pre-release test all over again. I'm going to upload a new test version soon. I wish the new version of macOS hadn't happened.
2018/09/28 Vulkan the future or failure?
The undocumented changes in OpenGL-handling of macOS 10.14 created some extra work for me. I need to modify sample codes for my teaching. Each change is small, but I have many source files. I also need to update explanation on my course notes.
There is no explanation of the changes. If the program is not calling OpenGL functions outside prepareOpenGL and drawRect, it should work fine. Otherwise, the program won't work on macOS 10.14. I can imagine programs registering textures in arbitrary locations. The current official version and the test version of YSFLIGHT does not run on macOS 10.14,either. The new stable version will be out soon, which runs ok on macOS 10.14. I have already fixed my code. YSFLIGHT is running fine on macOS 10.14 running on my mac mini. I originally was planning to push it out by the end of the summer break but couldn't finish pre-release tests in time, and pre-release test is now slowly moving forward. But, it worked out well for macOS 10.14.
But, the removal of OpenGL from macOS is becoming more realistic. To prepare for the transition to Vulkan, I was reviewing my Vulkan test codes that I wrote in July. OK. I was able to do shadow mapping. That refreshed what I studied. I think I can use Vulkan if I choose to.
Yes, I am confident in coding with Vulkan. But, probably only few developers can understand and use this API. Vulkan is an EXTREMELY difficult API. Exponentially more difficult compared to OpenGL. Years ago, we had tough time transition from OpenGL 1.1 regime to OpenGL ES 2.0 regime because ES 2.0 made GLSL mandatory. But, the difficulty of Vulkan is way too much more than that. It requires unreasonably low-level programming and micro-management of GPU. OpenGL somewhat provided the rendering model, but Vulkan gives nothing. Vulkan dumps all the responsibility on the application programmer. Probably less than 1% of the programmers who can write OpenGL ES 2.0 code can develop on Vulkan.
After Vulkan is out, there are so much developers who are worried about the future of OpenGL. Vulkan started as the next-generation OpenGL. It is very much understandable. No matter how loud Khronos shouts that they maintain OpenGL, it is too late to extinguish those anxiety.
I had once used an API called IRIS Performer. I think it was in 1994. IRIS Performer was developed by Silicon Graphics who was the leader in the 3D graphics industry that time. My then advisor wanted to see if IRIS Performer was useful. IRIS Performer was made public when the computer-graphics community came up with an idea of Scenegraph. The idea was that the graphics API can optimize rendering operation if the entire scene structure, rather than a soup of lines and triangles, is registered to the API. But, in IRIS Performer, the registration was difficult like hell. Sure, if I transfer that much rich information to the API, it should be able to fully optimize the rendering operation. But, it was too difficult and impractical. That was our conclusion. Other people soon stopped talking about it, and IRIS Performer was forgotten. Silicon Graphics was wonder-straying off course in developing a scene-graph API, and they then released a new API called Cosmo 3D, which quickly disappeared by itself. Developers lost confidence on Silicon Graphics, and it lost the dominance.
I see so much of similarity between IRIS Performer and Vulkan. Sure, if I go down that low level, I may be able to fully tune the rendering pass for maximum performance. But, virtually nobody will be able to program Vulkan, except handful programmers. People saw IRIS Performer as the next-generation 3D graphics API at first. We thought 3D-graphics then-giant, Silicon Graphics, must have created a very good API. People gave up quickly because it was unreasonably complex and extremely difficult. Because nobody used, people stopped talking about it. It disappeared by itself. My very unscientific survey is indicating that more people are complaining about extreme difficulty of Vulkan than appreciating its performance. If only few people uses it, it would disappear. Just as Silicon Graphics lost trust from developers, people will lose confidence on Khronos. Didn't Khronos learn from the failure of IRIS Performer? .... Maybe young people haven't even heard about IRIS Performer.
As if Khronos totally lost their mind, they started Vulkan Portability Initiative. For many of us, the problem is how we can transition to Vulkan. It is virtually impossible to transition our current code base using OpenGL to Vulkan. It helps nothing about our problem. This portability initiative, for an unknown reason, is done in a programming language called Rust. I've only heard about it. Just skimming the code, I got an impression that it was another lesser copy of C++. New programming languages are irresponsibly created and thrown away. That's a serious problem of computing today. Looks like this portability initiative is not going anywhere. It has been stopping since last year.
The situation, almost 100% re-enactment of IRIS Performer, makes me hesitate to transit my code base to Vulkan. It happened before. I spent quite good amount of time to learn DirectX9, and partially added support in my projects including YSFLIGHT. Then Microsoft dropped the backward compatibility in DirectX10. Learning DirectX9 was made utter waste. I felt so dumb. I'm glad I didn't waste time to learn DirectX10 because Microsoft cut the backward compatibility again in DirectX11. I'm done with DirectX. I don't want to repeat the mistake again. Because at this time I see very good probability of Vulkan to disappear, I cannot invest more time for Vulkan. Well, another reason is it still doesn't run on my ThinkPad X250 and X230T. Is Vulkan cross-platform? No. It's a fake news! There still are very large quantity of Windows PCs that are running on 4th- and 5th-generation Core processors and built-in GPU. Vulkan is failing to reach out to those population.
In my view, there is only one way out for Khronos from the failed attempt of Vulkan. Implement OpenGL on top of Vulkan, release it as a reference code, and maintain it. OpenGL is not that unreasonably crazy low-level as Vulkan. It makes sense to implement OpenGL on top of lower-level API, and it should be very much doable. Of course, the performance will be sacrificed because the GPU and application gets somewhat farther apart by the OpenGL layer.. But, what I am looking for is maintainability and reasonably easy coding. OpenGL, especially 1.1, is so good for quick prototyping. Vulkan is not. OpenGL 1.1 is so nice to get students started. How can I teach Vulkan to my students? It is impossible. I think implementing OpenGL layer on top of Vulkan is the only way for Khronos to re-gain confidence from developers. No matter how much Khronos insists that they continue OpenGL, we won't trust unless they actually act.
macOS Mojave nuisance
One of my students emailed me saying OpenGL stopped functioning when he updated his macOS to 10.14 Mojave. I was caught by surprise because Apple was stating that OpenGL still functions although it is labeled deprecated. Did Apple break promise again? Is it something I was worried about? I also updated my mac mini and confirmed the problem.
It's already almost one month into the semester. I didn't want to tell all my mac-user students to hold off the OS update or use Linux or Windows at this point. After several hours of investigation, I found that all OpenGL drawing outside of drawRect method of NSOpenGLView are ignored in macOS 10.14. (As far as I tested, all OpenGL function calls outside drawRect and prepareOpenGL look to be ignored.)
For example, your program may be calculating one step of the motion and re-drawing at the end of the same function which is outside of drawRect, then your program may stop functioning in 10.14. Or if you are initializing OpenGL states outside of prepareOpenGL, the state may not be initialized at all. The same limitation used to apply only when NSOpenGLView had a sub-view. But, apparently macOS 10.14 applies this limitation regardless of the presence of a sub-view. I am glad at least I knew about the limitation of NSOpenGLWindow with a sub-view. If I didn't know about it, I could have been in the dark now.
I am teaching an introductory programming. I wanted to avoid dealing with call-back functions, but it looks to be unavoidable. I'll explain in class tomorrow.
I hope Apple to support OpenGL longer, but nobody except Apple employees knows how long OpenGL runs on macOS. How can I teach introductory graphics programming with Metal? Metal is useless unless a student is looking to apply for a position in Apple. If I cover up some hard-to-understand part of Vulkan, I think it is possible to go with Vulkan, but Vulkan has its own problem. Vulkan is still not cross-platform yet. I have three computers home, and Vulkan doesn't work on two of them. It is somewhat understandable it doesn't work on 5-year old ThinkPadX230T, but Vulkan doesn't run on my 2.5-year old ThinkPad X250, either. 3-year old computers are still everywhere. If Vulkan doesn't support 3-year old Intel GPUs, it is not yet eligible to be called a cross-platform. Are they going to ignore 3-year old Intel GPUs? Khronos may say it's Intel's problem, not Vulkan's problem. From the user's and developer's point of view, Vulkan is not running on too many computers no matter whose problem it is. I doubt about the seriousness of the people who are working on Vulkan. Vulkan has a good chance of failing. In fact, it is not taking over OpenGL. It may already be failing. Vulkan gave an excuse to Apple for dropping OpenGL. Other operating systems may follow. Then Vulkan itself may disappear. There is a high probability of programmers' dystopia where no cross-platform graphics API exists.
FM TOWNS Resurrection Project: Creating an Emergency GUI Boot Floppy Disk with English Localization
For those who are trying to keep or make vintage FM TOWNS in working condition, I made a batch file to create an emergency GUI boot floppy disk.
FM TOWNS Resurrection Project: Writing a 1.23MB formatted floppy image back to an actual floppy disk in Windows 10
If you acquired a vintage FM TOWNS computer, and if its CD drive is dead, you are left with only one option to start the unit: booting from a bootable floppy disk.
Although it was pretty easy to create a bootable disk image by using an emulator, there was no mean of writing it back to an actual 1.23MB format floppy disk.
So, I made it.
PC-9801 uses the same Japanese-only format. If you are trying to restore a PC-9801, you may be able to use the same method.
How to bug-fix and build an external SCSI CD driver "CDSD.SYS" for Towns OS
There seems to be more than handful of FM TOWNS are kept in working condition. But, many of them are suffering from unstable internal CD drive. An internal CD drive was what characterized and differentiated FM TOWNS from other PCs. FM TOWNS was the very first computer that equipped a CD drive as a standard device. It was not an option. All FM TOWNS came with a CD drive. Therefore, although you still have an option to boot FM TOWNS from a SCSI HD emulator like SCSI2SD, not having a CD drive is very sad condition for a FM TOWNS.
However, miraculously there are two MS-DOS drivers CDSD.SYS and CDISC2.SYS, which substitutes an external SCSI CD drive to the internal CD drive. But, CDSD.SYS binary is documented as a commercial software, and you cannot download from anywhere. And, there is no place you can buy it any more. In addition, the latest version has two bugs that prevents CDSD.SYS from running on Towns OS (although it is advertised to work with Towns.)
I fixed the bug. I made a work flow to build a binary from the source. So I made it public. I have confirmed it to work with actual FM TOWNS 2MX.
Keep FM-TOWNS alive until the last day of the universe!
I bought a classic game called "Dragon Slayer" for my Fujitsu Micro 7 from Yahoo auction. There were two versions of Dragon Slayer for FM-7, one in a floppy disk and the other in an audio cassette tape. The floppy-disk version is nearly impossible to find. The one I bought was in an audio cassette tape.
This game was very famous and popular in Japan back in early 1980s. I did play, but it was too difficult for me. I didn't know that the map is connected left and right. To get a sword visible on the right at the beginning, I was supposed to walk left. I just couldn't find a route to get to the sword then.
I bought the audio cassette media not because I wanted to play again, but I was more interested in restoring it to the working condition. Actually, the restoration to the .WAV file was successful with little difficulty. Once restored, I wanted to confirm it is complete, i.e., that I could play through. But, the audio-cassette version has only one map where the disk version has multiple maps. Then came to my mind was an emulator-based PC port called "Dragon Slayer Chronicle". The package included Dragon Slayer, Xanadu, Xanadu Scenario II, and other Dragon Slayer series titles. I purchased it a few years ago, and played Xanadu and Xanadu Scenario II, but I hadn't played Dragon Slayer. The version in the package was from PC-8801 disk version.
So, it already had nothing to do with the original purpose, but I started Dragon Slayer for PC-8801 that came with "Dragon Slayer Chronicle". I have 2D Retromap Tool. Also I can save the state anywhere since this one is emulator-based. I couldn't finish it back then, but I now should be able to play through.
I didn't know how many stages (called Phase in Dragon Slayer) I needed to go through at the beginning. I was guessing it should be somewhere around 10. But, as I finished phase after phase, I encountered a new phase. I couldn't save looking at a hint online, and knew there were 20 phases in total. I nearly gave up.
But, I finally played through the last phase, 20th, or Phase K today. I played through all variations of the maps. Then the game goes back to phase 1 with slightly stronger enemy monsters, but I'm not interested in playing all over again.
It had some element of puzzle solving, also it needs a strategy. Now I understand why this title made such a big hit. Actually, the sequel title "Xanadu" sold a then-unprecedented copies, many users started with Xanadu. I was one of them. I played Xanadu before Dragon Slayer. But, I regretted that I had never been able to finish Dragon Slayer yet. Now I played through PC88 version. I fulfilled another long-unfinished business.
I've been learning Vulkan API for the last a few weeks. I feel that I have enough knowledge to port YSFLIGHT to Vulkan. When the doomsday comes, when OpenGL is no longer cross platform, I should be able to switch to Vulkan.
That's only if Vulkan gains popularity as advertised. I have a serious doubt if it will be well adapted though. The reason why I am worried about the Vulkan adaption is because it is not taking over OpenGL. It is trying to take over extreme low-level APIs like Direct 3D and Metal. I don't think Microsoft and Apple are happy with Vulkan. Apple is openly unhappy with Vulkan. It also takes over OpenCL, which gives nVidia a reason not to be supportive. If Vulkan takes down OpenCL, and the Vulkan itself fails, nVidia will dominate the GPU processing by CUDA. Those big companies, except Apple, are saying they support Vulkan, but they may just be pretending.
Already I see signs that Vulkan is buckling. Since Apple totally ignored Vulkan, they arranged a deal to get MoltenVK, Vulkan implementation on Metal for Apple platforms, open-sourced. But, it is only a subset of Vulkan. It lacks the Validation layer. Vulkan has too many knobs to control. You cannot tell if you are feeding correct parameters.. The Validation layer will tell you when given parameters are outside of the Vulkan specification. It is virtually impossible to develop without the Validation layer. You may get something working in your environment without the Validation layer, but your program may not work when you take it to another platform.
So what I have been doing is writing code on my Mac mini home, and the next day I test the same code on Windows on my office PC to see a bunch of error messages from Validation layer then only I can correct them. Why can't I debug at home? Because of Intel's reluctance in Vulkan, none of my ThinkPads running Windows 10 can run Vulkan. My ThinkPad X250 is just 3 years old, but it is too old to run Vulkan. In a sense, Vulkan doesn't run on too many integrated GPUs and is nothing cross-platform yet. Since Vulkan runs on those older integrated GPUs on Linux, there is no reason it cannot be done on Windows. I don't know what Intel is holding off.
The shader program of Metal seems to be less capable than SPIR-V. The output from the vertex shader (varying in the OpenGL term) cannot be an array or a matrix. (Come on, Apple!) That is supposed to be a Metal problem, not a Vulkan problem, but MoltenVK inherits the problem since it is implemented on Metal. Therefore, the shader that runs perfectly on Windows may not run on macOS and iOS. Because of this hiccup (plus more hiccups), Khronos is now talking about official Vulkan 'subset'. Aaaagh! What's the point of the standard?
By the way I think GLSL to SPIR-V compiler that comes with the LunarG package has a bug. If I write:
layout(std140,set=0,binding=0) uniform State
// 16-byte alignment
everything works. But, when I was writing it as:
layout(std140,set=0,binding=0) uniform State
// 16-byte alignment
Everything after lightEnable were zero in my shader. Only lightEnabled receives a correct value from my C++ program. I checked every single line in my code, counted bytes to make sure 16-byte alignment, and could not figure why my shader didn't receive any value after lightEnabled. In a desperate attempt, I changed float to vec4, and everything worked. I found no explanation why vec4 worked and float didn't. I hope it is a bug, not a mysterious specification that nobody understands.
Speaking of uniform, to set a uniform value in Vulkan, you need to first copy values to a uniform buffer, which is supposed to be already in the GPU memory, and then uniform buffer "written" to the VkDescriptorSet, which then can finally be bound to a binding point of a VkDescriptorSetLayout and become visible to the shader program (or pipeline in Vulkan term).
My question: Isn't VkDescriptorSet unnecessary?
Although I "write" the content of a uniform buffer to a VkDescriptorSet, a VkDescriptorSet looks to be just a pointer to a uniform buffer or a sampler. I don't see any point to make VkDescriptorSet an allocated resource. It should be possible to bind a uniform buffer or a sampler directly to a VkDescriptorSetLayout.
In the current version of Vulkan, you need two resources, a uniform buffer and a VkDescriptorSet to bind a uniform. (If you count a uniform buffer and a uniform buffer memory separately, three resources.) Since VkDescriptorSet is no more than a pointer, it should be small enough to be carried in a command buffer. Allocation of VkDescriptorSet is a utter waste. I hope the next version of Vulkan includes a function that directly binds a uniform buffer or a sampler to a binding point of a VkDescriptorSetLayout. For the time being, I allocate a uniform buffer and a VkDescriptorSet always as a pair, and my code looks to be working fine.
Anyway, I am hoping one of the two things to happen: (1) Vulkan gains momentum as promised, or (2) someone writes an OpenGL implementation on Metal (actually there is a commercial library called MoltenGL, but I cannot afford.) If Vulkan gets popular, I'm fine. I can continue coding cross-platform with Vulkan. I have already seen some problems, but it also is free from some OpenGL's problems. First of all, I appreciate its type safety. Every object in OpenGL was an unsigned integer. A compiler didn't catch if I was giving a texture name as a vertex-buffer name. It would take several months to a year to port my OpenGL code to Vulkan if I need to, but doable. Or, if OpenGL continues to be available on Apple platforms, it maintains its value and stay alive for longer period.
My worst fear is that Vulkan fails, OpenGL fades, and no cross-platform graphics API. I might look into Unity or Unreal engine, but those are basically for commercial development. I admire Unity's effort to keep backward compatibility, but still there is a license clause saying I need to pay some fraction of earning when the product is commercialized. Some of my research code have been used not as a consumer products, but as a part of the deliverables for industry-sponsored projects. Of course it is a part of an academic research project, but it is somewhat gray area that I don't want to step into. If I code for an industry-sponsored project using Unity or Unreal, I need to talk to an attorney who is specialized in the intellectual property laws to make sure there is no problem, and I don't have money to do so.
I expect Khronos would say something during SIGGRAPH 2018, which will be next month. I keep eye on what they say.
FM-7 Resurrection Utility: I was compiling in Debug mode. I re-compiled in Release mode and updated the binary.
Carnegie Mellon University is in summer break. I was visiting Japan after seeing off my students in the commencement, came back, went to Niagara Falls air show, and back in Pittsburgh. I'm going to Dayton Air Show this weekend, but the weather doesn't look to be promising.
Here's one news. I was porting my libraries to Android. Hopefully I can talk more about mobile programming in the spring semester course. YSFLIGHT kernel runs on Android now. It's not quite playable, but I am thinking to make a YSFLIGHT player for running demos and re-playing what you record in a PC. I set my goals of the summer as:
That's what I was thinking to do, when Apple dropped a bombshell.
OpenGL and OpenGL ES will be unavailable in macOS and iOS in the future OS versions. I was somewhat expecting it when Apple announced Metal. At the same time, I was hoping Apple to maintain relatively higher-level and standard graphics APIs. The expectation was shattered into pieces by this announcement.
Microsoft tried to drop OpenGL in Windows Vista once. Then developers around the world criticized the decision, and Microsoft withdrew the idea. OpenGL is, although officially up to version 1.1, still supported as a part of Win32 API. In Universal Windows Platform Microsoft implemented OpenGL ES 2.0 on top of Direct X and therefore is still part of the Windows API. But, probably Apple won't listen.
At least OpenGL should be available for a while, there is a possibility that YSFLIGHT is not available for Mac and development for iOS suspended at least for a short time.
I'm looking into Vulkan API by the way. One of the big problems of current programming is, in my view, that the graphics API has too much influence on the program and data structures. I see a lot of "to extract the best performance from GPU" while I read through Vulkan documentations and tutorials. Tell you what I want to say to them? "Shut the mouth up." I am not competing a Hollywood movie. I won't need the maximum performance from GPU. I rather want to know cleaner and maintainable way. I personally believe correctness and maintainability is more important than performance.
RAM Smart Phone Yoke Mount
I have tried RAM X-Grip Smart Phone Yoke Mount. (Read more)
I've been asked when I release the next stable version. Sorry. I haven't been able to take time for pre-release test because I spent too much time for retro RPGs. Actually YSFLIGHT grew feature-rich a lot more than I was originally expecting and it is very difficult to manually test many of these features. So, one of the effort I am doing is to automate such tests. I tried several different ways, but the latest scripting is working nicely. For example, now I can automatically select all of the Simulation menus or I can automatically select all of the default aircrafts and fields in the new-flight dialog to make sure the program does not crash. It is amazing to see my test scripts go through many test items for different versions of YSFLIGHT in a few minutes that were taking more than an hour.
Also I am able to test with some different configurations. The work load for the testing will substantially be reduced if I am able to automate tests of many of the configuration items. But it cannot detect the crash, so I need to be in front of the monitor. That's one of the remaining problems.
Looking back, I have added so many features compared to the current stable version. It is a good time to take time for pre-release test and make it official.
I also spend some time occasionally for at least making YSFLIGHT auto-demo for iOS and Android. But, the major road blocking is I need to set up build separately for those two platforms. I cannot really type "cmake ~/development" to set up build environment.
I had a feeling that I forgot something....
Turned out I was totally forgetting about a meeting.
When I am writing a paper or a code it is too easy to forget about time. Also it is easy to lose track of what meetings I got and what meetings are cancelled. If I muted my iPhone for my class and forgot unmuting, things get out of control.
I'm really curious how other people mage their schedule while writing papers and codes, teaching a class, and attending hundreds of meetings.
Closing of Forward Lanes
A bowling alley in Squirrel Hill that I have been bowling for nearly two decades closed the door permanently last weekend. According to a newspaper the place had been open since 1924. So, the place had nearly a century of the history. I visited Forward Lanes for the first time in 1998 when I came to Pittsburgh as a Ph.D student. I was not a frequent bowler while I was a student, but after getting my degree and started as a research associate I moved to an apartment one-minute walk from Forward Lanes. Then I started bowling more frequently.
Bowling is only one sports that I can do better than average people. Though I didn't have an ambition to bowl in a league then. I just wanted to stay above average. I often went there alone and bowled eight games in a row for practice. One day then-owner of Forward Lanes saw me practicing and suggested me to join a league. I never knew it was so easy to join a league. I happily joined the Saturday-Night League, then-called Young Adult League. That was I think in 2004 or 2005. So, I bowled in the league for almost 14 years.
Although it was not a serious league at all I was still honored to be the highest-average bowler for several seasons. Recently Forward Lanes started cutting down oil on the lanes and made the condition favorable for fast and power bowlers. No matter what I tried I never gained my ball speed. My ball was hooking too much in the recent Forward Lanes' oil condition and never bowled as good as before. Which was fine. My primary league nowadays is Thursday Bowlmor Classic at Brunswick Zone Playmor Bowl in West Mifflin. This is a sanctioned league filled with serious bowlers. I bowled 259 (625 series) there yesterday by the way. So I do not lose a place to bowl. But, closure of a bowling alley that I had been bowling such a long time made me sentimental a bit.
By the way this is the score from my last game in Forward Lanes.
FM77AV / AV40 Resurrection Project: Infra-Red wireless keyboard emulator
If you are a classic-computer lover, and if you want to get a FM77AV or FM77AV40 unit from Japan, like Yahoo! Auction, you can often find a unit in a good condition. But, for some reason, most unit doesn't come with a keyboard. In such situations, this Infra-Red wireless keyboard emulator can help. (It is not for FM77AV20EX/40EX/40SX which does not have an Infra-Red sensor.)
FM-7/77 series resurrection utility
If you happen to own a Japanese retro PC called FM-7/77 series with a disk drive, and your original floppy disk went bad but you have a back up disk images in .D77 format, these utilities might help writing disk image back to a fresh floppy disk.
Happy New Year!
I was staying in San Francisco during the break, came back in an overnight red-eye flight, and then caught cold.
We were there to eat fresh seafood there. Typical Japanese tourist visiting San Francisco probably would visit more touristic places, but we were there for food. We are living in Pittsburgh and starving for fresh seafood.
I stayed there for four days, and rented a Cessna 172 on the last day to fly a Bay-Tour course with an instructor. I was unfamiliar with the airspace around SFO, and the airspace is much more complex than Pittsburgh. We have Pittsburgh class B and several class D airspaces with good isolated distance. San Francisco area is covered by entwined class B, C, and D airspaces. It would take several flying with an instructor to be confident in such a complex airspace.
Detail of the flight is here.
|Comments are welcome. Send E-Mail to:|