- CoCreate Modeling: Changing the current directory during startup (02 Nov 2015)
- Macbook hangs after installing OS X 10.11.1 (31 Oct 2015)
- "Disk FOO wasn't ejected because one or more programs may be using it!" (25 Oct 2015)
- Spätsommerputz auf meinem Samsung Galaxy S2 (07 Sep 2015)
- Flache Hierarchien (04 Apr 2015)
- External monitor versus wifi (11 Jan 2015)
- Older topics...
CoCreate Modeling: Changing the current directory during startup (02 Nov 2015)
sd-set-current-working-directory API.
But when you call this function during startup (i.e. from
code in sd_customize, or in code loaded from there), you may find that other customization code or even CoCreate Modeling itself
changes the current directory after your code runs. This is because CoCreate Modeling remembers the directory which was current
before the user closed the last session. When you restart the application, it will try to "wake up" in precisely that working directory.
To override this behavior, here's a simple trick:
- In
sd_customize(or, preferably, in code loaded from there), register an event handler for theSD-INTERACTIVE-EVENT. - This event will be fired when startup has completed and the application becomes interactive.
- In the event handler:
- Set the current working directory as you see fit
- Unregister from the event (we want one-shot behavior here)
(in-package :de.clausbrod) (use-package :oli) (defun interactive-event-handler(&rest r) (sd-set-current-working-directory (user-homedir-pathname)) (sd-unsubscribe-event *SD-INTERACTIVE-EVENT* 'interactive-event-handler)) (sd-subscribe-event *SD-INTERACTIVE-EVENT* 'interactive-event-handler)This particular event handler sets the current working directory to the user's home directory, but this is of course just an example for a reasonable default.
Macbook hangs after installing OS X 10.11.1 (31 Oct 2015)
- ⌘+V during reboot: Boot in verbose mode, showing the boot messages instead of the Apple logo and progress bar. I noticed that the boot process hung after a message saying pci pause: SDXC.
- ⌘+R during reboot: Boots into recovery mode, which offers tools for disk and networking diagnosis, as well as the option to open a terminal as a superuser.
- Reset the System Management Controller (SMC)
- Reset the NVRAM - this actually changed the behavior; the progress bar would
now fill up to 100%, but then nothing happened anymore. When booting in verbose mode (showing all the boot messages),
startup continued past the pci pause message, but stalled later in what looked like a loop involving
messages liked
IO80211AWDLPeerManager::setAwdlOperatingMode Setting the AWDL operation mode from SUSPENDED to AUTOandIO80211AWDLPeerManager::setAwdlAutoMode Resuming AWDL. (See also http://superuser.com/questions/917220/macbook-can-not-boot-os-x-yosemite-as-it-hangs for a description of similar symptoms.) - Repair my SSD in recovery mode - this found a number of issues on the disk and repaired them, but did not fix the hang-up issue.
- Fix permissions using the recovery mode resetpassword utility
- Boot info safe mode - this did not work at all, as the hang-up apparently affected safe mode as well.
$ mount -rw / $ cd /Volumes/Macintosh\ HD $ cd Library/Extensions $ ls ACS6x.kext HighPointIOP.kext ATTOCelerityFC8.kext HighPointRR.kext ATTOExpressSASHBA2.kext PromiseSTEX.kext ATTOExpressSASRAID2.kext SoftRAID.kext AX88179_178A.kext hp_io_enabler_compound.kext ArcMSR.kext hp_io_printerclassdriver_enabler.kext CalDigitHDProDrv.kextFollowing Justin's advice, I moved all kernel extensions out of
/Library/Extensions to disable them temporarily, and
then rebooted. Lo and behold, the login screen appeared! After a few such rounds of moving kernel extensions back to
/Library/Extensions and rebooting, the root cause of my startup issues turned out to be those HP printer extensions.
Phew.
The HP kernel extensions had been on my system for quite some time, of course, and had never caused any problems like this before.
So there are still open questions about what exactly had happened here. To be solved on a rainy day.
Other related links:
- http://apple.stackexchange.com/questions/163059/how-can-i-disable-kext-signing-in-mac-os-x-10-10-yosemite
- http://superuser.com/questions/917220/macbook-can-not-boot-os-x-yosemite-as-it-hangs
- https://jamfnation.jamfsoftware.com/discussion.html?id=12589
- El Capitan update won't boot (Apple Support Communities)
Update January 2nd, 2016: Today it happened again - the MacBook hung at the same point during reboot. I remember I installed an HP scanner driver roughly a week ago, and I probably did not reboot since then. The above recipe worked for me this time again.
Update November 2016: Apparently, the printer driver reinstalls itself automatically:
See also https://support.apple.com/en-us/HT201465. Which explains the many times I have had to re-apply the workaround described above.
I guess it is about time to look for and eliminate the root cause of all this.
"Disk FOO wasn't ejected because one or more programs may be using it!" (25 Oct 2015)
sudo lsof | grep /Volumes/FOOIn my case, this produced a list of files opened by a process called
mds_store which, apparently, is used
to produce the Spotlight search index:
mds_store 42059 root txt REG 1,6 3277 8832664 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexGroups mds_store 42059 root txt REG 1,6 32768 8832663 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexIds mds_store 42059 root txt REG 1,6 8192 8832666 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexTermIds mds_store 42059 root txt REG 1,6 8192 8832668 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexPositionTable mds_store 42059 root txt REG 1,6 8224 8832669 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexDirectory mds_store 42059 root txt REG 1,6 1024 8832670 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexCompactDirectory mds_store 42059 root txt REG 1,6 65536 8832671 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexArrays mds_store 42059 root 5r DIR 1,6 2074 8832643 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842 mds_store 42059 root 11r DIR 1,6 2074 8832643 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842 mds_store 42059 root 47u REG 1,6 28 8832650 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/indexState mds_store 42059 root 49u REG 1,6 118784 8832674 /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/.store.db backupd 42148 root 4w REG 1,6 1300 8832803 /Volumes/FOO/Backups.backupdb/Claus/2015-10-25-175619.inProgress/.Backup.467484979.422497.logThe fun part was that I had explicitly configured Spotlight to ignore that particular external disk - and yet, it was still trying to index it! Turns out that I am not alone with this. "Disable Spotlight on a FAT32 external drive" provides the best summary I could find. Apparently, the type of file system on the external drive plays a role. I was somewhat skeptical about this claim, but then, all my external drives had FAT32 file systems on them, and so I followed the instructions in the article. I was still somewhat incredulous, as this seemed to be such a basic issue and the article is rather old. But then, following the instructions indeed seemed to be successful, at least initially. The magic ingredient in the sauce was to create a top-level file called
.metadata_never_index on
the affected drive:
touch /Volumes/FOO/.metadata_never_indexI was too impatient to wait for existing instances of
mds_store to finish their work,
and did not care about the consistency of the Spotlight index on the external drive anyway.
So I killed the mds_store process right away, then unplugged the drive and plugged it in again.
From there, indeed I had no issues anymore with ejecting the external disk. Hmmm...
Other related articles and discussions:
- http://apple.stackexchange.com/questions/104842/the-volume-cant-be-ejected-because-its-currently-in-use
- http://apple.stackexchange.com/questions/29580/how-do-i-make-spotlight-stop-indexing-my-backup-drive/211616#211616
- http://apple.stackexchange.com/questions/142459/how-to-eject-my-external-drive-when-my-mac-refuses-because-of-spotlight
Spätsommerputz auf meinem Samsung Galaxy S2 (07 Sep 2015)
/data nur noch wenige Prozent frei waren. Ich hatte mir vorher
angelesen, dass Android-Applikationen sich normalerweise hier installieren. Man kann Applikationen zwar auch auf die SD-Karte
schieben, aber - so warnten die einschlägigen Artikel - dennoch könnte es sein, dass die verschobenen Applikationen
Teile ihrer Daten weiter unter /data ablegten.
Ebenfalls erwähnenswert ist in diesem Zusammenhang das kleine, aber feine Diskusage, das
schnell einen grafischen Überblick der Speichersituation verschafft.
Methode 2: adb shell
Vor zwei Jahren hatte ich mir Android-Entwicklergrundwissen angelesen und dabei auch das Android SDK installiert,
zu dem auch adb gehört. Nach Aktivieren des "USB debugging" in den Developer Options meines Telefons
entspann sich folgender, eher unbefriedigender Dialog mit meinem Telefon:
clausb:platform-tools clausb$ ./adb shell shell@android:/ $ ls /data opendir failed, Permission denied"Think, McFly, think!" Eigentlich klar. Ohne Rootrechte auf dem Telefon geht halt auch mittels
adb nicht viel. Hmpf.
(Guter Grundlagenartikel zum Thema: http://techblogon.com/android-file-system-structure-architecture-layout-details/)
/data frei!
Bei der Recherche kam mir auch
Root Cleaner unter. Das ist eine
Applikation, die sich eigens auf das Aufräumen von Systemdaten spezialisiert und vermutlich deutlich über das
Löschen von Dumpfiles hinausgeht. Guter Ansatz - aber auch diese App braucht Root-Rechte.
Methode 4: Applikationen deinstallieren
Nicht originell, aber der Vollständigkeit halber muss es erwähnt werden: Natürlich fanden sich auch auf meinem
Telefon Apps, die ich so gut wie nie nutze, so dass sie verzichtbar waren.
Methode 5: Applikationen abspecken
Praktisch alle Apps legen lokal Cachedaten an und verbrauchen damit eventuell Platz in /data. Der Applikationsmanager
von Android bietet für jede Applikation Optionen zum Löschen lokaler App-Daten an. Besonders ausgeprägt ist der
App-Cache natürlich bei Webbrowsern wie Firefox. Hier verstecken sich die Optionen zum Löschen des Caches in
den privacy options.
/data wieder fast 40% freien Speicher.
Mit der Folge, dass etliche automatische App-Updates losrappelten, die schon lange sehnsüchtig darauf gewartet hatten,
dass sich ihnen der entsprechende Platz böte - und diesmal erfolgreich waren.
Flache Hierarchien (04 Apr 2015)
node:
(defstruct node (name "" :type string) (children nil :type list))Das reicht, um einen einfachen Teilebaum abzubilden. Ein Knoten kann entweder ein einfaches Teil repräsentieren - in diesem Fall hat er nur einen Namen. Wenn es sich um eine Baugruppe handelt, hält der Knoten eine Liste von Kindknoten in
children.
(defmethod print-object ((node node) stream)
(format stream "~A [~A] "
(node-name node)
(if (node-children node) "asm" "part")))
Damit man einen node halbwegs kompakt ausgeben kann, definieren wir uns
ein zur Struktur passendes generisches print-object. Aus der etwas langatmigen Darstellung
einer Strukturinstanz wie
#S(NODE :NAME "42" :CHILDREN (#S(NODE :NAME "p42" :CHILDREN NIL)))wird dadurch
42 [asm]Testbaugruppen baut man sich einfach per Strukturliteral. Beispiel:
(let ((tree #S(NODE :NAME "a1"
:CHILDREN (#S(NODE :NAME "p1")
#S(NODE :NAME "p2")
#S(NODE :NAME "a11"
:CHILDREN (#S(NODE :NAME "p11")
#S(NODE :NAME "p12")))
#S(NODE :NAME "a12"
:CHILDREN (#S(NODE :NAME "p13")
#S(NODE :NAME "p14")))))))
Mit dieser Vorbereitung können wir nun endlich des Kollegen Codeschnippsel betrachten.
Naja, eine leicht angepasste Variante davon jedenfalls:
(defun flatten-assembly-apply-nconc(node)
(cons node
(apply #'nconc (mapcar #'flatten-assembly-apply-nconc (node-children node)))))
Ruft man flatten-assembly-apply-nconc für die obige Testbaugruppe (flatten-assembly-apply-nconc tree), erhält man
dank des von uns definierten print-object in der REPL in etwa folgendes:
(a1 [asm] p1 [part] p2 [part] a11 [asm] p11 [part] p12 [part] a12 [asm] p13 [part] p14 [part])Es entsteht also in der Tat eine flache Liste - wie schön. Sich zu verbildlichen, warum die Funktion die gewünschten Effekt hat, braucht schon einen kleinen Moment - und vielleicht auch den einen oder anderen Blick ins Lisp-Manual, um sich der genauen Funktionsweise von nconc oder mapcar zu vergewissern. Entscheidend ist unter anderem, dass Lisp-Listen letztlich Ketten von cons-Zellen sind, deren letztes Element auf
nil verweist, und dass node-children genau solche nil-Werte passend liefert, die
von mapcar und nconc auch brav durchgeschleust werden.
flatten-assembly-apply-nconc setzt das "destruktive" nconc ein, um weniger
Speicher allozieren zu müssen. Was mich gleich zu der Frage geführt hat, ob es vielleicht noch effizienter geht,
und so entstanden folgende Varianten:
(defun flatten-assembly-apply-append(node)
(cons node
(apply #'append (mapcar #'flatten-assembly-apply-append (node-children node)))))
(defun flatten-assembly-mapcan(node)
(cons node
(mapcan #'flatten-assembly-mapcan (node-children node))))
;; version using an accumulator
(defun flatten-assembly-accumulator(node &optional acc)
(cond
((null node) acc)
((listp node) (flatten-assembly-accumulator (first node) (flatten-assembly-accumulator (rest node) acc)))
((null (node-children node)) (cons node acc))
;; assembly case, i.e. a node with children
(t (cons node (flatten-assembly-accumulator (node-children node) acc)))))
Diese Varianten habe ich hintereinander in drei Lisp-Implementierungen ausgemessen, und zwar in
CLISP 2.49, Clozure CL 1.1 und
SBCL 1.2.10. Weil SBCL sich zumindest auf Mac OS
bei kurzläufigen Tests zickig
anstellt und keine Messdaten liefert, habe ich die jeweilige Testfunktion in einer Schleife 100000mal aufgerufen:
(let ((tree #S(NODE :NAME "a1"
:CHILDREN (#S(NODE :NAME "p1")
#S(NODE :NAME "p2")
#S(NODE :NAME "a11"
:CHILDREN (#S(NODE :NAME "p11")
#S(NODE :NAME "p12")))
#S(NODE :NAME "a12"
:CHILDREN (#S(NODE :NAME "p13")
#S(NODE :NAME "a121"
:CHILDREN (#S(NODE :NAME "a1211"
:CHILDREN (#S(NODE :NAME "p1211")))))
#S(NODE :NAME "p14")))))))
(defun run-test(function-symbol)
(gc)
(format t "~%Test function: ~A~%" (symbol-name function-symbol))
(print (time (dotimes (i 100000) (run-test-raw function-symbol)))))
)
(run-test 'flatten-assembly-apply-append)
(run-test 'flatten-assembly-apply-nconc)
(run-test 'flatten-assembly-mapcan)
(run-test 'flatten-assembly-accumulator)
| Variante | Lisp-Implementierung | Laufzeit (µs) | Allokation (Bytes) |
|---|---|---|---|
| flatten-assembly-apply-append | CLISP | 3173017 | 72000000 |
| flatten-assembly-apply-nconc | CLISP | 3034901 | 56000000 |
| flatten-assembly-mapcan | CLISP | 2639819 | 38400000 |
| flatten-assembly-accumulator | CLISP | 4959644 | 46400000 |
| flatten-assembly-apply-append | CCL | 70407 | 52800000 |
| flatten-assembly-apply-nconc | CCL | 54713 | 36800000 |
| flatten-assembly-mapcan | CCL | 128232 | 19200000 |
| flatten-assembly-accumulator | CCL | 20997 | 19200000 |
| flatten-assembly-apply-append | SBCL | 37000 | 52768224 |
| flatten-assembly-apply-nconc | SBCL | 25000 | 36798464 |
| flatten-assembly-mapcan | SBCL | 29000 | 19169280 |
| flatten-assembly-accumulator | SBCL | 22000 | 19169280 |
PS: Natürlich ist das hier beschriebene Problem eine Variante der Aufgabe, eine verschachtelte Liste
plattzuklopfen. http://rosettacode.org/wiki/Flatten_a_list#Common_Lisp hält einschlägige Lösungen
hierfür parat.
PS/2: In der Lisp-Implementierung HCL, die in CoCreate Modeling verwendet wird, schneiden
flatten-assembly-apply-nconc und flatten-assembly-mapcan am besten ab. Dies ist aber mit Vorbehalt
gesagt, denn in HCL musste ich den Code - mangels Compiler-Lizenz - interpretiert ablaufen lassen,
was das Performancebild vermutlich stark verfälscht.
External monitor versus wifi (11 Jan 2015)
Older topics...
Add a new blog entry.Revision: r1.1 - 06 Mar 2016 - 21:49 - ClausBrod