what can I do to help discover why Future stopped working?
From your prior post it seems that Future did not stop working, it was trying to do what you told it to do and raising error messages. I'd bet that if you had the patience to click through many error messages when you clicked on the last one Future would still be there, perfectly alive and ready for your next command. In contrast, crashes are easy: don't do anything else until you create a crash dump (there are threads in this forum that discuss how) and send that in to support as a bug report. The situation is much more difficult in cases where Future hasn't crashed, but is still going through the motions of what it was commanded to do. The way Engineering has to deal with that is to carefully set up a reproducible situation to see what is going on. Sometimes the "going though the motions" bit may reveal a bug in Future and sometimes not. If you can repeat the situation with smaller data, so you don't have to press "OK" to a dialog zillions of times to find out if Future really does surface at the end, ready to go, that would be a good thing. Well, if this is not a crash, then it is the functional equivalent in that the program stopped being useful.
I'd respectfully disagree, in that people can command a program to do things that puts the program, while it is doing what was commanded, in a state that is not useful. You have to drill into it to see what is going on. To improve the quality of a product it is necessary to focus, with precise terminology, on cases where the product itself is at fault. That's one reason why it is important not to use the word "crash" for things that are not crashes. It's not that people freak out over the word, it is just that using the wrong word makes it harder in what is already a complex situation to know what really is going on. Let me try an example to show what I mean: you can command a program like Radian to connect to a web data source in a way that tells Radian to repeatedly try to fetch data in a series of interactions that each can take a long time to time out depending on what that data source is like. Between using Windows facilities and what Radian has been commanded to do it can seem like Radian has locked up, when instead it really is patiently trying to do what it has been ordered. I can see the point of view of someone who says, "well, fine, but in that case I want a Cancel command within Radian that no matter what it is doing will stop what I commanded." That's a great notion but built into that is the unstated desire, "oh, and I don't ever want to pay any performance price or lose capabilities to have such a command." Sometimes, with some connections or some tasks, you don't have that option. A good example is how in Release 8 there are some algorithms that are recursive, that cycle down through levels of recursion and don't surface until they are done. They don't come up from many levels deep every few seconds to see if the user commanded a cancel, either. If they did, they'd run much slower. So in cases like that you don't get a super cancel because the overall judgement is that faster algorithms are better than having a super cancel. A good bit of Radian is like that as well. Start messing with databases and there isn't any "cancel" available because once you get into mucking about with the database you better take what you are doing to completion or you risk leaving it in disordered, partially done state. In other cases Radian might not have prioritized the engineering effort required to do a cancel because there are bigger fish to fry. It all depends. It is not the most elegant way of issuing a super-cancel but if there are better things to invest engineering into the idea there is always a brute force use of task manager as a cancel has a certain practicality about it. My reaction to what you described is simple: If Future was raising dialogs for you it obviously was still alive. Crashed software doesn't do that. If those dialogs were annoying and you preferred a super cancel, I'm with you there. To determine whether it makes sense to implement a super cancel for the specific thing you were doing, Engineering has to know exactly what you were doing and the full context. If you were getting repeated error messages because as Radian was trying to work with temp files or cache you had flatlined on available disk space, well, that's not going to be a front burner item. It's easier just to advise people to not launch such processes when they have insufficient free space. On the other hand if it was just a really stupid way of Radian to announce it can't do what you want or, even worse, a bug, well, then it becomes a front burner issue to be dealt with in the next build. You can help that process by filing a bug report (the web site has tips on that). They have to know everything, all the details, to zero in on any bug. So, things like whether a file has been imported or is linked are important, the sizes of those files, the sizes of the .map file, free space on disk and how that is arranged and all that is key. Some other notes... Y'all have gone on and on about how Radian is crash proof.
In reality, Radian went through the entire beta process and months of release before anyone found a way to crash it. That was fixed right away, but it did mean the web site had to be changed to instead of saying Radian never crashes that "Radian is almost impossible to crash." :-) Future file sizes seem to be a factor of 10 larger after importing a Manifold 8 file
That depends on the content of the file and if you have compression turned on. If you have compression turned on in 8 (everybody does) you are not comparing apples to apples. Zip a Radian file to get a better comparison. And then try opening a multi-billion point project file in Release 8 and see if it opens in under a second... I make that point because nobody cares if a file is five or even ten times larger if that makes a difference between it opening instantly or opening in a half hour. Disk space is almost free. Your time is very valuable, so be happy spending disk space to do in under a second what otherwise takes an hour. There's probably a way to determine how many points are in each file, but I don't see it in Future.
When you import the file the number of points is the number of records in the table. Open the table. Press CTRL-End to jump to the end. You'll see from the mfd_id field how many records there are in the table. That's how many points there are. Using SQL, you can write SELECT Count(*) FROM [TableName]; which will report the number of records in a table. 9 GB is not a big file for Future. But, it may be a big file if you don't have enough free space on disk. Is export file size relevant to the issue? Future seemed to choke after the file export failed and the warning was closed.
No idea without knowing all the details. Could be. Just commenting that if you have a 9 GB file to save that's not going to happen with a shapefile. given that I'm trying to do something that the software is not ready to do yet (or maybe ever),
Don't position it, just report. It's not up to Radian to make it possible for you to save 9 GB to a shapefile, so don't position it as "the software is not ready to do that yet." It's shapefile format that's limited to 2GB, and it is .mdb that limits mfd/mfd to under 2 GB as well. If KML has limits, well, that's KML with limits. Look, I think it is 100% fair to say that if you command Radian to do something not allowed by the formats you are using to ask that Radian decline gracefully. No dispute about that at all. But don't confuse that with the limitations of the formats because that's not something Radian can change. That shapefiles and .mdb and KML are what they are is OK, because there is a lot of industry know-how built around those limitations. Nothing wrong with that. If you want Radian to provide you with a format that can handle bigger data, no problem with that either. In Radian's case it is .map, the best format the engineers know how to provide. If you want big data and interoperability with other software in the same format as well, no problem with that either: use something like PostgreSQL. It's free and it can handle 9 GB. There's nothing wrong with wanting Radian to gracefully decline when it is commanded to do something wrong, or to provide a graceful way to bail out if you command it to do something you regretted (like commanding a very long task). But put the focus on that because there you are in the business of advocating a specific priority ahead of other priorities. Keep in mind there are other users with their priorities who aren't going to have the slightest sympathy if you tried to stuff a 9 GB data set into a shapefile that, by design, can only store 2 GB. They're not going to want Manifold to take time away from their priorities to ensure Radian will decline that gracefully. My own view is that the software should never advise it doesn't like what you ordered by issuing a series of zillions of error dialogs. I'm with you on that. I just hate that stuff and would prefer that if it was unhappy, or if disk resources were used up or whatever it just didn't do what was ordered and left it up to the user to sort out why. But to track down why it is issuing error messages we need to know precisely what was commanded and all details about the context. That's also the only way to discover if it is a bug, which we should know because bugs get fixed instantly with no issues about prioritizing more graceful error messages or a super cancel ahead of other community wishes.
|