Comment #3 on issue 4003 by marcus.d...@gmail.com: Build of Core 1.3 broken because of integration of 13147 http://code.google.com/p/pharo/issues/detail?id=4003 I think I found it. I added CommandLine initialize to the postscript but forgot CodeLoader initialize

Updates: Status: FixToInclude Comment #5 on issue 4003 by marcus.d...@gmail.com: Build of Core 1.3 broken because of integration of 13147 http://code.google.com/p/pharo/issues/detail?id=4003 I think the problem is a exception handler that swallows all Exceptions (ProgressNotification, too) in headless mode. (leftover from before the real headless mode). fix attached. Attachments: SmalltalkImage-sendtoClassesNamedInwith.st 886 bytes

Comment #7 on issue 4003 by siguc...@gmail.com: Build of Core 1.3 broken because of integration of 13147 http://code.google.com/p/pharo/issues/detail?id=4003 here the part of code which responsible for doing startup: self processStartUpList: resuming. resuming ifTrue: [ self recordStartupStamp ]. UIManager default onSnapshot: resuming. "Now it's time to raise an error" as you can see, the process list are ehmm.. processed before UIManager takes a control (and before switching to non-interactive mode). It means that if any startup procedure added by some arbitrary class will fail with error, it will end up using old UIManager, which could open a debugger window and waiting for user's interaction. From other side, im not sure it would be wise to switch UIManager before processing the startup list, because it in own turn could depend on startup of things like Delay etc.