Just as a small update for me… I’ve been working with the beta for a while now, since it came out, and while the test project I have that can invoke a crash is still invoking crashes, quite a few others have appeared too. There is no repeatable pattern, but things like trying to open a partial to edit it can cause it, moving even small sections of content around the page can cause it, and even just adding stacks to a page.
I wouldn’t say 4.2 is any worse than 4.1 for me, but it’s certainly not workable I’m afraid. I’ll roll back to 4.0.x and hope the final version of 4.2 has these issues ironed out.
EDIT: It seems 4.2 is no longer in beta but is a final release, which does leave me a bit of a quandary. For reasons, I don’t understand, it is just not working for me beyond 4.0.x. I’ve never had issues with Stacks before, now it’s nothing but issues. I work mostly in Uikit, perhaps this is a trigger? Although I have been using Foundry too and that has crashed also.
Open to suggestions. I can send in projects and stacks (have done that previously, but never heard back) but it’s not isolated to a particular project, nor any particular set of stacks. Needle? Haystack?
Oh my gosh that’s great testing and great news. You can’t imagine how relieved that makes me. Intermittent bugs that I can’t duplicate on my own machine are crazy difficult to fix. It takes a lot of educated guessing and trial and error.
Phew!
This is actually a much more challenging feature request than you might imagine. The entire RapidWeaver text system is all one giant RapidWeaver thing. Stacks relies on that text system for text editing.
The upside of this is that Stacks inherits a lot of great styled-text and markdown exporting for free and we get nice consistent behavior across all of RapidWeaver.
The downside is that a lot of the behavior – including some of the UI – can’t be modified a lot. And since a lot of that system is the core of the oldest bit of RapidWeaver it doesn’t change too much – the older a system is, the harder backward compatibility becomes.
I did find a way that I can affect things – essentially an artificial zoom on the whole view. This comes with some quirks too, so there are limits to how much zoom I can apply. I’ll see what I can do – but I probably can’t make it user configurable (yet!).
(“yet”) means I have some big plans for this in the near(ish) future. Stacks 5 is going to use more of its own text system. The reason: the benefits of consistency grow smaller the more people use Stacks. Many people are using Stacks to build nearly their entire site – so consistency really isn’t worth the tradeoffs.
But this is just a “plan” for now. There’s still a lot of work to do to realize that plan. So please be aware that Stacks 5 may be a long time coming and may only get half way there – perhaps replacing Markdown and HTML editing, but not Styled Text – or maybe vice versa. That said, this is high on my list – some part of this plan will make the cut for sure.
@TemplateRepo: would you mind terribly signing in to my Slack channel. It will be easy to work one-on-one with you there in private, exchange files/builds and RW-environments.
To me it sounds like something in your environment is causing an issue. I’d really like to help you over this hurdle and/or discover the bugs that are causing it.
But here in the forum it’s a no-go. I either get a constant bombardment of false-positive notifications or miss 80% of the things that I should see. And has no easy way to exchange files here either – which can be simply drag-and-dropped in a secure, private chat in Slack.
I’m happy to take input from you anywhere – but I’m confident if that if we only communicate on the forum it will go nowhere.
@Rovertek: I know we tried before via your bespoke setup to exchange files. I want to let you know that although I was not able to ever duplicate any crashes, I did use the reports that you sent. The reports indicate a crash identical to the one that started this thread – and the author, along with three other users – have all indicated that that crash has been eliminated (phew).
However, if you’re still experiencing crashes – especially similar to @TemplateRepo then I’d encourage you to send more info. The info I got from you last time was very useful – as it was one of the first to provide real crash reports from that issue. If you’re still experiencing crashes it means that we’ve shifted the same crash to a different area (not very likely, I think) or there is an additional problem that was hiding behind the first – sometimes fixing things is like peeling an onion, you just have to keep peeling the layers – hopefully there’s something good at the core.
I’d also like to extend the same invitation to Slack. I know it took many tries and in the end literal hours of my time (and surely yours as well) to access the bespoke file server and exchange emails.
Slack provides a way for either real-time chat, or “asynchronous” private messages. It’s very similar to a forum – but also provides a private channel for each user and a way to simply drag and drop large files.
It would likely save both of us a vast amount of time and allow us many more iterations of report-then-fix-then-test-then-repeat.
But of course, I’m happy to work with you other ways too. Really I’m happy for anyone that takes the time out of their day to send me any info.
But also… maybe consider sticking to v4.0 for real work if that version seems to be working for you.
I mean, it’s great (and I’m grateful) to run a test in v4.2 on a test-project. But if it crashes every five minutes, then generate a crash report, send it, and flip back to v4.0. No reason to keep crashing if you know a simple solution.
@isaiah – The main pain for me is not crashing (it was and is only very sporadic, in my case). There are three other bugs that cause a vast waste of time for me:
Disappearing stack labels. If I close a stack that serves as a wrapper for other stacks, save and then reopen that wrapper, all stacks inside it lose their labels, so that I can’t see their names. Between Stacks 4.1.0 and 4.2.0 this was happening in all pages. After updating to version 4.2.0 this does not happen on very simple pages, but unfortunately, it happens all the time in my production process, where pages are not so simple.
Stack settings are losing focus when I type. I have to click multiple times and type very quickly, before input box loses its focus again.
Changes that I make are not registered on ‘Save’. To work around that, I have to save as normal, then make another (random) change, promptly undo that and save again.
I’m afraid that these bugs would be very difficult for you to reproduce in your environment, but—from posts on this forum—I know that I am not alone experiencing them.
Maybe I am totally off mark, but for a long time I’ve been thinking that either RW or Stacks (or both) have a very poor memory management issue that leads to all these problems?
I have a related problem for some time now:
Loosing focus after leaving a input field, e.g. click into one field, enter a value, tab until the next input field and then the focus is lost immediatly, so typing ends up in the Nirvana (with beeping sounds of the Mac). So you have to click with the mouse into every single field you want to modify the value.
Aah, thought this is something you built. If I remember correctly, I didn’t like this new text input box when it was introduced, the pre-3 was a bit more user friendly (in my eyes)
Uhm… To be honest, I can’t remember that I haven’t used any other page type since the release of Stacks. So RW is just a “glorifed stacks container” for me (Yes, probably I should switch to Bootstrap Studio or Pineyard then…)
OK. This one’s a bit long. @Rovertek as usual does not pull punches – this is a good thing, of course, and really appreciated, but it does require some extra typing to respond to.
So grab a drink, get comfortable, and have a read through. And of course, feel free to respond with whatever you’ve got.
Thanks,
Isaiah
This bug is fixed in v4.2. Credit Joe for helping me duplicate the issue. The magic was just that sub-stacks start out hidden in the project. In my test-case projects, things aren’t generally hidden too often, so it was one of those bugs that was right there in plain sight, I just needed that one detail and it took 10 seconds to fix. Woo hoo!
If you’re still experiencing this bug in v4.2 or later, here’s the bug report. Just click “Reopen” and let me know how to make it happen.
I’m not sure I follow you exactly. I do think something maybe similar (???) is fixed in v4.2 – but hard to say for sure without more details.
Is it possible to make a video using v4.2? It sounds like something that might be obvious in a video, right? If not a video, can you tell me what I’d need to do to see the problem – starting with an empty project and using only built-in stacks?
This is probably another one that’s hiding in plain sight. I think a video would definitely help here. (A detailed step by step text description is even better – but usually most people prefer the video route, it’s just easier – but you choose whatever works for you).
But please, for UI stuff like this it’s super important – no, it’s 100% IMPERATIVE – that you start from an empty file and use ONLY built in stacks.
Your goal is not to show me the workaround – I don’t want to see what works. Show me what doesn’t save. Break Stacks as hard as you can – and record a video.
Respectfully, I disagree. These don’t sound challenging in the least – either to reproduce or to fix. They’re all things that seem to happen to often (or you wouldn’t have developed a painful workaround) – so a little video demonstration of what’s going on should be sufficient.
The stuff that’s really impossible to duplicate involves some level of randomness and/or timing. When things only happen once a day or with 20 documents open… those are tough bugs. But if changes fail to save often, then… boom… easy peasy – we’re almost done.
Here, I’ll make one myself and even put it in a gif in this post, to show you how quick it is…
Hit record (Cmd-Shift-5)
Open up RW.
New project + new Stacks page (Cmd-Shift-N + Cmd-N).
Drag a few stacks to the page.
Make one of the changes that Stacks doesn’t save.
Save the project, obviously. (Cmd-S)
Then Quit. Relaunch. Open the file.
Put your cursor on the thing that didn’t save.
Hit stop.
Done! Here’s my quick gif of that – but of course, it does save in my video. Just make the same video, but with the edits that don’t get saved, and we’re all set!
Took me about 5 min. Mostly to clean up my desktop.
The last bit, i’m going to put in a separate response in case someone wants to move it to another thread.
While better memory management is always a good thing – poor memory management rarely leads to problems in today’s world unless it is really very extreme – are happens very fast.
macOS will “page” memory to/from the hard drive if you’re running low. this is slow, but ensures you can run all the way out of memory – and then a bunch more – before the system crashes. and before it runs out of memory and will kill an app if it’s running away using all the memory (and the crash report for that is very very obvious – it’ll say so right at the top). this means for memory leaks to be really problematic you kind of need to run out of memory and hard disk too – it’s a case of extremes, not really something that’s happening to many people day to day.
Most of the stuff you’ve mentioned above is just “oops” I missed a bit of testing and accidentally introduces a strange behavior. Like the hiding titles and losing focus when you type. These are just human error compounded by an piece of software (Stacks) that’s over a decade old now and is trying very hard to hide a decade of complexity behind a facade of user-friendly UI. UI interactions are much more difficult to test in an automated way – so most rely on user testing by me and, to some degree, the stack developers during beta testing.
I think a few UI blemishes like this have always been and will always be a tradeoff of use “indie” software from a single developer or smaller team. The upside is it’s usually cheaper, more fun, and you can communicate directly with the developer (like right now).
But maybe that’s not what you meant…
I don’t want to put words in your mouth, but I do try to look deeply at what people are trying to tell me and see beyond the literal words that are written…
I suspect what you’re trying to tell me is that memory is the root cause of the crashes more than the three UI niggles above.
But… again… (IMHO!!! YMMV!!! ETC. etc. et cetera)… memory is not to blame.
But let’s take a second and talk about memory. And why RW uses SO MUCH more than it did a decade ago.
Today, unlike a decade ago, Stacks pages often contain dozens of huge images. Image memory footprint scales with the SQUARE of the size of the image – it means caching images in memory or on GPU takes A LOT of memory now.
And pages contain megabytes of complex templates, and loads of other things that are all vastly larger than they were.
And Stacks keeps a deep undo history in memory so you can walk many changes back – even when those changes contain big stacks or partials.
All of these things take a bunch of memory. This is not a bug. It’s not because it’s “leaking” (a very abused semi-technical term that now has too many meanings). Stacks stores these things in memory so you don’t have to wait while they read in over and over again from a slow hard-drive – which is usually the alternative.
In short: Stacks trades memory for speed. I use a lot of memory for caching – on purpose, because memory is pretty cheap and everyone likes it when Stacks goes faster. It’s just a tradeoff.
So what is to blame for stability issues?
Other than simple mistakes (which is probably a big percentage) I can think of two things right off the top. But this is a contentious topic, it’s like tossing a hand grenade into a forum thread.
So, if a forum admin wants to set up a separate thread for this whole post – or this part of the post, I don’t blame them.
I’m just going to mention them briefly and ask if anyone wants to debate that, that we create a separate thread.
Threading
RW introduced a new threading model in RW 7.1 in 2016. Threading is hard. Thread safe code is hard. Creating a thread-safe API is hard. This new threading model introduced many hard things all at once. I think this sudden change has been the root cause of many crashes. It seems like all of those things could be better.
Deprecation
Around the same time the way changes were introduced into RW changed dramatically. On many occasions a new version of RW has introduced crash-on-launch problems to over half of my plugins. It seems like this could be better.
One more thing: a decade ago there was lots more and lost more-friendly communication of crash reports and everything else, between YourHead and Realmac. I miss it a lot and look forward to that happening again someday.
@isaiah, while you’re working on Stacks v4.2.1, can you please add a functionality to the Groups settings so that the Groups can be rearranged?
I try to create a Group per project, as it just makes it a lot easier to go back during edits/updates/changes, and it would be a huge timesaver if I could just put whatever Group/Project I’m working on at the moment at the very top–and keep it on top–instead of having to continuously stop and scroll down to a Group to access that Group/Project.
@davidfreels
This is definitely on my to do list, but that’s a bit more than I can add in a point release. This is a highly customize NSOutlineView – notoriously quirky and difficult. I suspect it’s one of the oldest bits of AppKit.
But I will do it. Keep pestering me.
I’m actually trying hard to work just on stability at the moment.
The big push to the very different API of RW 9 is ahead of me. It has taken months, and will take months more, for these last big changes.
I’d love to be able to focus all of my energy on that one thing – or as close to that ideal as I can get while still answering email and paying bills. I’ll get there much faster if I don’t have to jump back to Stacks v4. 2 very often to fix things.
So let’s get the boat in shipshape for this voyage.
I’m not seeing that behavior myself. Or perhaps it’s a different field somewhere in RW that I’m not aware of. But in the Stacks Info Sidebar – where you change the properties of each stack, it should be a “next responder chain” from the top to the bottom. Since it’s all dynamically generated UI, right when you click on the each stack – this bit of code is non-trivial actually. I mean, it’s not super hard either. It just doesn’t come for free.
I did a quick walk through the code and it seems to be working. Here’s a video of what I see when using Stacks v4.2, RW 8.7. This is a built-in button stack. (see video below)
My guess is that something else is stealing the focus. I don’t think anything in your preview windows can steal focus when those windows aren’t the “key window”.
But maybe you have something configured in a non-default way – like maybe you view the info-sidebar as a floating window? Or maybe you have the Stacks Library configured as a popover? Both of those things change the main-window/key-window dynamics a lot. If you let me know how you have it configured, maybe I’ll be able to duplicate the strange behavior.
Or… and now that I’ve written all that and recorded a video… I suspect I know the real culprit. It’s probably a form element in edit mode. Do you have a contact form? or search field?
Something like that?
OK, I can manufacture the problem – but it takes specifically trying to add something to edit-mode that purposefully grabs focus – a very bad idea. LOL.
Frankly I consider this a bug of the stack that’s doing this. However it’s easy enough to add this to the list of disallowed attributes that get filtered from edit mode. I’ve added a bug to our buglist: filter the autofocus attribute from form elements in edit mode (#650) · Issues · YourHead / stacks · GitLab
However… I’d still be interested in knowing what stack is doing this in your design. If you can’t seem to figure out which stack is doing it, can you do me a big favor, jump over to the Slack channel, and dump your project and RW Environment. It only takes about 5 min to do.
And here’s what I need from you. Essentially just a zip of the project, click this button, and just drag-and-drop both in a private message to me in slack. I’d like to find out if there are more ways to steal the insertion point that I don’t know of.
The reason I said these bugs could be difficult to reproduce and that they might have their origin in bad memory management is because they happen to me in complex pages and after an intensive editing. But I agree that comment was a stretch on my part.
Re 1. Disappearing labels – FIXED! Hurray!
Re 2. Input fields in stacks losing focus – this looks like the same bug that @dripple mentioned (BTW, same thing happens to me, too).
Re 3. Changes not registered on “Save” – to put it simpler, I need to save TWICE to have the last purposeful change to be registered. The condition is: make another random change and undo it before the second “Save”. I do not know how to explain it more clearly.
I just tried a blank project with a simple text stack and it works as expected, now I am looking into my projects and check what stacks are causing this issue. I had the “problem” with many project, legacy (theme based) and newer ones (who are all Foundry). I’ll keep you posted on that (heading over to Slack then)
Mine crashes up to 5 times a day. It often seems to relate to using partials, or when copying and pasting stacks. Also the preview is terminally slow. It is sometime quicker (or as quick) to publish a page and preview it live on the site.
8.7 will not run anymore on my Mac. Spin spin spin. Need help please.
Just tested with a backup version of my site, no improvement.
UPDATE… It’s working again. I think it was a problem with resources. I let it spin for a few hours, and then all my site images loaded and now it’s back to working OK. But, my opinion is something was wrong. I sent about 20 crash reports.
(Yes, probably I should switch to Bootstrap Studio or Pineyard then…)
