Simple Car Crash Mod Car
Cori Lenon
Today, I've tried to place this simple Word file and Affinity Publisher 2.5.0 on Windows crashed. 2.4.2 did not crash, importing the same file. APub 1 does not crash, either. However, if I convert this file into an RTF file, it imports fine, even in Publisher 2.5.0 What goes wrong?
(It was extremely embarrassing because it happened in front of my course participants. I'm currently teaching a typesetting class in Publisher. My participants couldn't import their Word files, either.)
Note: Publisher 1 seems to have been much more robust as far as importing Word files are concerned. I have pretty complex and complicated Word files that nicely import into Publisher 1 but always cause Publisher 2 to crash.
Right you are, Walt. However, you'd expect minor problems, not fundamental things such as placing problems. And, secondly, Publisher practically lures users to immediately switch to the new version. The proof of the pudding: most of my participants came with version 2.5 installed, already! In the light of this, shall I as the teacher base the seminar on an older version?
Strange, do you have an explanation for this? There is nothing wrong with facing pages in Word?! And in my RTF file, I also have those two styles. Anyway, thanks for helping to find a workaround, I very much appreciate your help!
Best I can suggest is that if you're not covering topics that require 2.5 (e.g., new function) then using the older version is safer. If you do require new functions, then you're rather stuck, except that in previewing the seminar before-hand, you would have discovered the problem and known to revert (and suggest reversion to the students).
It's rather unfortunate timing/scheduling, basically. And occasionally this has happened with the Affinity applications. Possibly because we users can't beta test some aspects of it (such as installation from the Mac App Store or the Microsoft Store).
I too am having crash problems - Windows 11 - when placing MS Word content. As most of my contributors (village magazine) use Word it's a real nightmare. I'll keep an eye out for a resolution which I hope comes speedily
I'm new to blender, only my second day, and I am following a tutorial by the Blender Guru. I noticed something wasn't quite right when he had live render running and his blender was running just as usual, however my computer seemed to struggle running blender, and it would also cause youtube to hang up and stutter. However when I go to render a simple scene containing a plate, doughnut, and a mug it crashes. The crash makes both of my monitors go black, except for some noise in the top third of my 2k monitor, little squares of color. Then blender closes. I tried following what other people suggested where it was applicable, making sure my sub-surf was only at 2 for everything when it was rendering and setting my memory usage to zero to allow for unlimited memory. However nothing seems to work. Any help on this would be amazing as I'm hopping to continue using this application into the future.
EDIT: So we just tested it on my s/o's machine and we have the same monitor, ran just fine with hers all the way up to 4k, she has older generation cpu AND a step down in both gpu and memory, memory only 16gb.... what is the deal?
START BLENDER and if you CANT and Blender still crashes, the second thing to check is a FAULTY ADDON. Do you remember having added an ADDON recently? IF so: Please uncheck it and delete it from Blenders addon folders:C:\Users\3DCompositor\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons
Last but not least try to run blender after all of these operations with only 1 monitor (YES ONLY ONE AFTER CLEANING) for a regular 10 minute session. IF you dont notice anything weird, proceed with the SECOND monitor (plug your monitors with your PC OFF!)Work for 10 more minutes using BLENDER. If you didnt have any crashes, Turn off PC, connect 3rd monitor, and work with Blender for 10 more minutes.
I suppose this is a bug in Combine, so I'll also file a bug report to Apple, but if anyone can help me understand this better so that I can work around it that would be great, because it's problematic for me that after awaiting the publisher in this way I can no longer publish to it without provoking a crash.
Got it routed to the right spot; it looks like ObservableObjectPublisher is expecting everything subscribed to it to be unlimited, I would suggest instead to use a PassthroughSubject instead if possible - that will respect demand correctly.
That screenshot does not tell me very much, but the assertion that it is hitting means that the publisher is breaking the rules for Combine; basically it means that it got a value without any demand applied to the subscription. If you are seeing this with composition I would suggest highly to file a feedback and include a detailed reproduction of the failure.
The bug isn't in the AsyncPublisher but in ObservableObjectPublisher; it breaks the rules normally enforced by the rest of Combine (particularly it expects the downstream to request .unlimited). So I would highly suggest that in that case where you are connecting to a objectWillChangePublisher to put a buffer in there to ensure the proper demand.
I am trying to define a function in Mathematica that does a very specific thing, but for some reason Mathematica keeps crashing while testing it. After messing around a bit I have found where the problem lies: when trying to evaluate a simple For loop Mathematica keeps crashing (to the point where I have to force close it with Task Manager). See the image below:
vectorBasis is a function defined below. As you can see, Length[vectorBasis[perm]] is simply the number 3, so I really feel like the For-loop should print the numbers 1, 2, and 3. But this completely crashes Mathematica.
The reason that I hadn't included it is that for this to be evaluate-able you need the function vectorBasis, which relies on functions from the amplituhedronBoundaries package (paper). The definitions might be a bit convoluted, but they seem to work:
Using version 2023, I have observed grompp crash without any further explanation for several of my systems. I could simplify one of the systems so it contains now only 1 single atom, but the crash is still reproduced. Minor modifications (e.g. changing the cell size or switching off the thermostat) make the crash disappear.
I use the following command:
gmx grompp -f run.mdp -c system.gro -p system.top -o run.tp
As a workaround, you can manually shift the system so that it does not have any coordinates less than negative-size (-6.2 in your case). Large positive coordinates or small negative coordinates should not be a problem.
Basically iv created a simple mel script which switches between perspective and orthographic views based on the direction the perspective camera faces, and it was all working perfectly while i was writing it. But then i close down maya for the weekend, and when i try to run my script again today, it just straight up crashes maya every time with no error messages or anything. This alone seems quite odd to me, but as i was trying to figure out what was going on, i realised if i run little bits of my script through the script editor first, and then run the whole thing, it works again, which has only confused me more.
Could you explain how you go about getting that stack trace?
viewAlongAxis i got from the viewport view menu: view > view along axis > (choice of axis), so not really sure why that wouldnt be recognised?
ah id almost forgotten that little trick, thanks for reminding me. After deleting my preferences it seems to have only somewhat fixed the problem. I can now run the script on start-up through the command line without crashing, however as soon as i bind it to a hotkey and try again, its still crashing, even in a totally new default hotkey setup with that single change.
I have a website that is very simple, but very long -- a lot of text that could be scrolled through. It's a documentation site, and considering the nature of the content (a lot of short similar entries) I decided to show everything at once, so the user could either scroll from entry to entry or navigate via a sidebar index. It's a common documentation model that I like (e.g. Underscore, Backbone, and LoDash).
And here's the problem: For a number of users this site consistently crashes their iOS browsers. Not all users (not me); but for those that do experience the crash, it seems to recur consistently. (The site may also crash some people's Android phones, I don't know: haven't heard from any Android users.) I am hoping someone can help me diagnose and possibly fix this problem.
I'm not sure what to try next, and I'm hoping some savvy StackOverflow whizzes have advice. What is it about this site, which seems so simple and basic to my eyes, that is making it so memory-demanding that it is crashing browsers?
These look to me to be the potentially relevant lines of a crash report from an iPhone running Chrome and crashing on the site (I'm not sure whether they are actually relevant or not because I haven't developed iOS apps and don't know the ins-and-outs of these reports):
The problem, as suspected, was rendering/painting caused by CSS layout. At phone-size, I had been hiding the content of each entry until it was selected; and the method I had been using to hide them, and remove any trace of them from the layout, included position: absolute. I didn't initially use display: none because of typical concerns about wanting to not see content but keep it there, for various readers and reasons. I threw those concerns aside and changed the layout so that the entries were hidden with display: none and shown with display: block -- and that seems to have fixed the crashing.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.
93ddb68554