Symantec Ghost in Windows hangs for mSATA to SATA adapter board Solution: Start Ghost with -NOTRIM

I was trying to image a mSATA SSD with Ghost in Windows (I’m using version 12.0.0.8023 Corporate Edition as I bought the Altiris license) and I ran into internal consistency error 8027 right at the very beginning of the copying process.

For some reason, it doesn’t happen if I boot to the DOS version (provided by Agilent) to do the cloning.

Luckily the status bar tells me what’s going on during the process. I notice it always hangs when ghost tells me that it’s TRIMming the SSD. I looked up the help file (ghost32.exe -help) and noticed that there’s a “-NOTRIM” option. Tried it and the clone completed successfully.

Turns out Symantec is aware of it. The title of the support article is called “Cloning Solid State Disk (SSD) drives fails when using the UEFI 12.0.0.x Ghost executables“.

The summary says it since older versions (11.5.1.x) does not have TRIM, this isn’t a problem, and

“Build 12.0.0.8003 (from GSS 3.0 early build) resolved the issue with the partition restore”

I’m not sure what it means. But the solution is the same as what I did: disable TRIM when copying SSD in Windows (done by the -notrim switch).

1,275 total views, 2 views today

Create user account using email address (like your Microsoft account) in Windows 7/2008

If you live in a mixed environment of Windows 7 and 8/10 computers, you might want to set the usernames to be the same so you can share the files/printers without managing Homegroup.

Nonetheless, in Windows 7/2008, if you try to create a user account using the traditional tool (Local Users and Groups) in Computer Management, you are not allowed to use email address as user name because they banned the at-mark (@):

I searched the web for quite a while, came across stuff like UPN (User Principal Name) without luck (No active directory on Windows 7, nor I want to setup a domain controller in Windows 2008 for home network). Turns out the solution is dead simple: use the “User Account” from Control panel to create the user account. No questions asked!

602 total views, no views today

Switch between 32-bit and 64-bit user written software like CVX

CVX is a very convenient convex optimization package that allows the user to specify the optimization objective and constraints directly instead of manually manipulating them (by various transformations) into forms that are accepted by commonly available software like quadprog().

What I want to show today is not CVX, but a technique to handle the many different versions of the same program targeted at each system architecture (32/64-bit, Windows/Mac/Linux). Here’s a snapshot of what’s available with cvx:

OS 32/64 mexext Download links
Linux 32-bit mexglx cvx-glx.zip
64-bit mexa64 cvx-a64.zip
Mac 32-bit mexmaci cvx-maci.zip
64-bit mexmaci64 cvx-maci64.zip
Windows 32-bit mexw32 cvx-w32.zip
64-bit mexw64 cvx-w64.zip

You can download all packages for different architectures, but make a folder for each of them by their mexext() name. For example, 32-bit Windows’ implementation can go under /mexw32/cvx. Then you can programmatically initialize the right package for say, your startup.m file:

run( fullfile(yourLibrary, mexext(), 'cvx', 'cvx_startup.m') );

I intentionally put the /[mexext()] above /cvx, not the other way round because if you have many different software packages and want to include them in the path, you can do it in one shot without filtering for the platform names:

addpath( genpath( fullfile(yourLibrary, mexext()) ) );

You can consider using computer(‘arch’) in place of mexext(), but the names are different and you have to name your folders accordingly. For CVX, it happens to go by mexext(), so I naturally used mexext() instead.

529 total views, 1 views today

Tektronix S1001 DIP switch: Open pin 3 to boot for fast self-test (TDS 744, 744A, 684A, 784A)

Normally for most TDS 500 series oscilloscopes, the DIP switch (S1001) typically all closed for normal operation. The only described use in the service manual is opening pin 6 and 7 to reveal the hidden composite test pattern screen for display adjustment.

However, I got a TDS 744 scope that boots very slow. Almost 5 mintues! To the extent that it’s unbearable. Initially I thought it’s just the non-A type booting slow. Nonetheless, I got a chance to open up another TDS 744A with boots much faster (in half a minute) with calibration seals on, and I noticed the pin 3 of S1001 is opened. Initially I thought it was out of place so I closed it again. Guess what? A slow 5 minute boot sequence!

I suspected opening pin 3 of S1001 puts the oscilloscope in the quick boot mode. I experimented with the pin 3 opened and manually initiating the full blown self-test (utility menu). Turns out I was correct! The full self-test is 5 minutes!

Since it was the settings from the calibration house, I looked up the TDS 744A/684A/784A service manual and noticed that the factory default is with pin 3 opened, while the old TDS 544A manual says pin 3 is closed. I suspect that the self-test for the new models 744/744A/684A/784A is unbearably long that the Tek decided to have it disabled for boot-up self-test.

In any case, try opening pin 3 to have the scopes boot faster!

 

864 total views, 1 views today

MATLAB Gotchas: Do NOT use getlevels(), getlabels() or categories() for categorical/nominal/ordinal objects Use unique(), unique(cellstr()) instead

I suspect TMW (The MathWorks, maker of MATLAB) hasn’t really thought about dead levels when a categorical object (I mean nominal() and ordinal() as well since they are wrapper child class of categorical()) has elements removed so that some levels doesn’t map to any elements anymore.

For performance reasons, it makes sense to keep the dead levels in because the user can repetitively add and remove the same last level by deleting and adding the same element, causing unnecessary work each time. Naturally, there’s a getlevels()/getlabels()/categories() method in nominal(),ordinal()/categorical() class so you know what raw levels are available. Turns out it’s a horrible idea to expose the raw levels when dead levels are allowed!

Unless you are dealing with the internals of categorical objects, there’s very little reason why one would care or want to know about the dead levels (it’s just a cache for performance). It’s the active levels that are currently mapped to some elements that matters when user make such queries, which is handled correctly by unique().

If there are no dead levels, getlevels() is equivalent to unique(), while categorical() and getlabels() are equivalent to unique(cellstr()), but I’m very likely to run into dead levels because I delete rows of data when I filter by certain criterion.

My first take on it would be to hide getlevels()/getlabels()/categories() from users. But over the years, I’ve grown from a conservative software point of view to accepting more liberal approach, especially after exposure to functional programming ideas. That means I’d rather have a way to know what’s going on inside (keep those functions there), but I’d like to be warned that it’s an evil feature that shouldn’t be used lightly.

Yes, I’m dissing the use of getlevels()/getlabels()/categories() like the infamous eval(). Once in a long while, it might be a legitimate neat approach. But for 99% of the time, it’s a strictly worse solution that causes a lot of damages. It’s way more unlikely that getlevels()/getlabels()/categories() will yield what you really mean with dead levels than multiple inheritance in C++ being the right approach on the first try.

If I use unique() all the time, why would I even bother to talk about getlevels()/getlabels()/categories() since I never used them? It’s because TMW didn’t warn users about the dangers in their documentation. These methods looks legit and innocent, but it’s a usage trap like returning stack pointers in C/C++ (you can technically do it, but with almost 100% certainty, you are telling the computer to do something you don’t mean to, in short: wrong).

I have two encounters that other people using the raw categorical levels that harmed me:

  1. One of my coworkers spoke against upgrading our MATLAB licenses (later withdrew his opposition) because the new versions breaks his old code involving nominal()/ordinal() objects.I was perplexed because it didn’t break any of my code despite I used more nominal() and ordinal() objects than anybody in my vicinity. On close inspection, he was using getlevels() and getlabels() all over the place instead of unique(), which works seamlessly in the new MATLAB.

    Remember I mentioned that the internal design/implementation details of nominal()/ordinal() changed in MATLAB R2013a? The internal treatment of dead levels has changed. The change was supposed to be irrelevant to end-users by design if getlevels()/getlabels() had not expose dead levels to end-users. Because of the oversight, users have written code that depends on how dead levels are internally handled!

  2. The default factory-shipped grpstats() is still ‘broken’ as of R2015b! If you feed grpstats() with a nominal grouping variable, it will give you lines of NaN because it was programmed to spit out one row for each level (dead or alive) in the grouping variable. Since the dead levels has nothing to group by the reduction function (@mean if not specified), it spits out multiple NaNs as by definition NaN do not equal to anything else, including NaN itself. This is traced to how grp2idx() is used internally: If the grouping variable is a cellstr() or double(), the groups are generated by using unique(), so there are no dead levels whatsoever. But if the grouping variable is a categorical, the developers thought their job is done already and just took it directly from the categorical object’s properties by calling getlabels() and getlevels():
    gidx = double(s);
    ...
    gnames = getlabels(s)';
    glevels = getlevels(s)';

    Apparently the author of the factory-shipped code forgot that there’s a reason why the categorical/unique() has the same function name as double/unique() and cellstr/unique(): the point of overloading is to have the same function name for the same intention! The intention of unique() should be uniformly applied across all the data types applicable. Think twice before relying on language support for type info (like type traits in C++) to switch code when you can use overloading(MATLAB)/polymorphism(C++). A good architecture should lead you to the correct code logic without the need of overriding good practices.

    Rants aside, grpstats() will work as intended if those lines in grp2idx() are changed to:

    gidx = double(s);
    ...
    glevels = unique(s(:));
    gnames = cellstr(glevels);
    

    A higher level fix would be applying grp2idx() to the grouping variable before it was fed into grpstats():

    grpstats(X, grp2idx(g), ...)

    The rationale is that the underlying contents doesn’t matter for grouping variables as long as each of them uniquely stand for the group they represent! In other words, categorical() objects are seen as nothing but a bunch of integers, which can be obtained by casting it to double():

    gidx = double(s);
    grpstats(X, gidx, ...)

    This is what grp2idx() calls under the hood anyway when it sees a categorical. The grp2idx() called from grpstats() will see a bunch of integers, which will correctly apply unique() to them, thus removing all dead levels.

    Of course, use grp2idx() instead of double() because it works across all data types that applies. Why future-constrain yourself when a more generic implementation is already available?

    The sin committed by grpstats() over nominal() is that the variables in glevels and gnames shouldn’t get involved in the first place because they don’t matter and shouldn’t even show up in the outputs. This is what’s fundamentally wrong about it:

    [group,...,ngroups] = mgrp2idx(group,rows);
    ...
    // This code assumes there are no gaps in group levels (gnum), which is not always true.
    for gnum = 1:ngroups
        groups{gnum} = find(group==gnum);
    end

    We can either blame the for-loop for not skipping dead levels, or blame mgrp2idx (a wrapper of grp2idx) for spitting out the dead levels. It doesn’t really matter which way it is. The most important thing is that dead levels were let loose, and nobody in the developer-user chain understand the implications enough to stop the problem from propagating to the final output.

To summarize, the raw levels in categorical objects is a dirty cache including junk you do not want 99.99% of the time. Use unique() to get the meaningful unique levels instead.

686 total views, no views today