Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On Fri Jun 25, 2010, Ben Rubinstein benr_mc at cogapp.com wrote: On 25/06/2010 17:36, Wilhelm Sanke wrote: And, if someone finds out that you can crash Rev with only four lines of script this should definitely arouse the attention of the responsible members of the Rev team, irrespective whether the bug report is multi-faceted or concentrated on one single sub-point. The Rev team should be competent enough to deal with a number of related troubles at the same time, or deal with them step by step. I believe that they are basically capable to handle also complicated issues, they are not first-graders in computer science. But they are busy people, who have to choose where to put their time. So are we!. My time is equally valuable. I think the relationship between the Rev team and their customers, supporters, cooperators etc. is one of mutual acknowledgement and respect without any trace of a hierarchy. I believe the unresponsiveness of the people from Rev in this case - an unresponsiveness which happily does not happen all the time, I indeed did have quite a number of normal and positive experiences - is mainly an organisational problem. If you set up a bug database for Rev users, you have also to develop regular procedures to communicate with the sender of a bug report in a narrow time frame. If there are open questions concerning a report - facts and arguments that may be totally clear in the mind of the sender, but actually need extra clarifications and additional information for the member of the Rev team that is assigned to the bug - then there is the need (and there should be the time) to contact the sender about it. Just staying mute for 9 months, doing nothing, is not appropriate and helpful - and certainly counterproductive to the goals of further development and improvement of Revolution and establishing a good working relationship with its users. I took some time to work through the bug, which is actually called Groups: Bugs and features (last group broken)?. It refers to a way of crashing Rev, but doesn't give enough information. I tried, yesterday, to reproduce the bug using the script fragment in the bug report, but without success. However, that may be because I didn't know the definition of 'pre-PNG'. Perhaps I would have discovered that by following the clue of my recent post to this list, but that was more time than I had. I tried with a PNG, and it didn't crash. As I had stated in the bug report, the crash occurs with what I have called and defined as Pre-PNGs, PNG images created inside Revolution, but apparently differing from PNGs created with other image tools. This in itself may be a bug. I will quote here from the relevant links for the definition of Pre-PNGs which I had supplied in my bug report (My post to the use-revolution list How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines of August 26, 2009, and the introduction to stack More about Masks http://www.sanke.org/Software/MoreAboutMasksRev3.zip): Pre-PNG images are basically those that are created or modified (as to their imagedata) in Revolution and have not yet been saved as external files and then been re-imported. Even if you export a snapshot using to image x as PNG (image x being an image already existing on the card), the resulting image will remain a Pre-PNG, also copying and pasting the Pre-PNG to another card or stack preserves the quality of the Pre-PNGs which behave differently in some respects. For details see my comments in More about Masks. From the introduction to stack More about Masks: A final observation concerning the creation of masks inside Revolution and using the import snapshot format: If the resulting mask image is not first saved as an external file and then imported again, meaning if it remains as freshly created inside a stack or was just copied from another mask-producing stack, then this mask image will have a different quality, which we might call a pre-PNG. Pre-PNGs behave somewhat differently than normal PNGs: You cannot transfer its alphamask to the image-to-be-masked when the pre-PNG is hidden, at least not several times with resizing. After you have resized a pre-PNG during the masking process, you might find that it is suddenly empty, but it can be restored when you copy and paste it (it then appears in its original size and shape). A workaround to overcome this problem is to store the mask in a custom property of its own and then to initialize the mask each time before it is used in the calling script: put the CPimg of img transition into img transition But of course you can easily convert a pre-PNG to a full PNG by saving the image as an external file. There are more peculiarities of these Pre-PNGs than I have described here. Again, I share your frustration that reports can be left 'unconfirmed' (and for much longer than a year - my oldest 'unconfirmed' bug report is more than
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On Thu, 24 Jun 2010, Ben Rubinstein benr...@cogapp.com wrote: On 22/06/2010 16:01, Wilhelm Sanke wrote: Apparently he had taken a look at the Revolution bug database with its enormous lags in fixing even fatal bugs, e.g. Report #8275 Groups: Bugs and features (last group broken)? of Sept 16, 2009, which astonishingly is still listed as unconfirmed although it contains a recipe to crash Revolution with only 4 lines of script. Wilhelm, I share your frustration with bug reports remaining uncomfirmed for long periods, although I also agree with others (and perhaps you) that an absolutist approach of no-new-features-until-every-bug-is-fixed is not sensible. However, taking a look at the report you mention, #8275, I can't find the recipe for crashing Revolution with only 4 lines of script. There are references in that report, to another report How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines, but from various searches in Bugzilla I am unable to find it. Can you give me the report number? Many thanks, Ben PS Thank you for taking the trouble to report issues in Bugzilla as I know it takes effort and it is a service to the community. But I would recommend, to get the maximum value in return for your trouble, creating separate reports for each issue so that each can be understood as simply as possible, rather than creating one very long report that ties together several issues. Ben, Thank you for looking into this matter. You are certainly right when you recommend filing separate bug reports. One thought that led me to put together a more comprehensive report is the assumption that at least some of the listed bugs are somehow related to each other. And, if someone finds out that you can crash Rev with only four lines of script this should definitely arouse the attention of the responsible members of the Rev team, irrespective whether the bug report is multi-faceted or concentrated on one single sub-point. The Rev team should be competent enough to deal with a number of related troubles at the same time, or deal with them step by step. I believe that they are basically capable to handle also complicated issues, they are not first-graders in computer science. There were 5 to 6 more sub-points concerning groups I was going to add to that report, but I had waited for a first response - which never was sent.up to now. The four-liner is contained in point 5 of my bug report - see below - and the post I mentioned there How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines was sent to the use-revolution list on August 26, 2009 - and can be found in the archives. 5. Groups belong to the factors in an already reported scenario for safely crashing Rev I have described this in detail in my recent post to this list How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines. Here I just point out that group is among the elements causing to crash Rev and refer you to my original post for more details. The following script assumes that you have set the angle of img test to an angle other than 0, that img test is ungrouped, and that img Test belongs in the category of Pre-PNGs. lock screen select img Test group set the angle of img Test to 0 For the definition of Pre-PNGs see my above-mentioned post or the introduction of my stack http://www.sanke.org/Software/MoreAboutMasksRev3.zip in the text brought up on the menu card from the topright introduction button. Best regards, Wilhelm Sanke ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On 25/06/2010 17:36, Wilhelm Sanke wrote: One thought that led me to put together a more comprehensive report is the assumption that at least some of the listed bugs are somehow related to each other. You can always create five separate reports, and then create a sixth one suggesting that there are a nest of issues relating to groups, giving the id of each. (Bugzilla is designed to support this kind of usage: if you refer to bug nnn or bug #nnn in the text of the description or a comment it is automatically recognised, and made into a link to the other bug report, with a tool-tip giving the bug status and title.) And, if someone finds out that you can crash Rev with only four lines of script this should definitely arouse the attention of the responsible members of the Rev team, irrespective whether the bug report is multi-faceted or concentrated on one single sub-point. The Rev team should be competent enough to deal with a number of related troubles at the same time, or deal with them step by step. I believe that they are basically capable to handle also complicated issues, they are not first-graders in computer science. But they are busy people, who have to choose where to put their time. I took some time to work through the bug, which is actually called Groups: Bugs and features (last group broken)?. It refers to a way of crashing Rev, but doesn't give enough information. I tried, yesterday, to reproduce the bug using the script fragment in the bug report, but without success. However, that may be because I didn't know the definition of 'pre-PNG'. Perhaps I would have discovered that by following the clue of my recent post to this list, but that was more time than I had. I tried with a PNG, and it didn't crash. Again, I share your frustration that reports can be left 'unconfirmed' (and for much longer than a year - my oldest 'unconfirmed' bug report is more than three years old, my oldest unconfirmed enhancement request more than six years old! (and I still want it)). But that's not to say that those guys aren't working. Of the reports I've opened in Bugzilla over the years, 155 of them have been resolved - some as duplicate, can't resolve, or not a bug, but the vast majority as fixed. That leaves 34 unconfirmed, and 24 in the limbo state between unconfirmed and resolved. That's not a great result: I'd much prefer things at least came off the 'unconfirmed' list faster, even if they were then consigned to a black hole of low priority; but it's not awful. (I also know that some bugs have been fixed although the entry in Bugzilla hasn't been addressed. That may be because the bug was found independantly either by RR directly or because of a duplicate report, and it's just annoying that they've never noticed my report; or it may be that someone read my report, fixed the bug, but for some reason didn't follow the process to resolve it.) If you think that RR should be aware of this crashing bug, you would do them a big favour by opening a report with the title you mention, with severity 'critical' or 'blocker' (if the latter can be justified), with the version 4.5.0 dp3 (having verified that the bug is still reproducible in the latest version), and with _all the information that RR need to reproduce the bug in one place_ (and as little other information to obscure that as possible). If there's a particularly variety of PNG that is involved, please include all the details needed to understand that in the bug report (as well as attaching a sample image to the report). Ben ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
Ben Rubinstein wrote: (I also know that some bugs have been fixed although the entry in Bugzilla hasn't been addressed. That may be because the bug was found independantly either by RR directly or because of a duplicate report, and it's just annoying that they've never noticed my report; or it may be that someone read my report, fixed the bug, but for some reason didn't follow the process to resolve it.) That happens more than we'd like, actually. They fix stuff and then forget to update the database. Or they fix stuff they didn't know was in the database. I suppose we could complain about engineers who don't keep up with paperwork, but you know how that goes. I'm kind of like that myself. Thanks for a thoughtful post on writing effective bug reports. You made some good points. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
The most dangerous argument any company can entertain on this subject. The question is, how the company handles reported product defects, what sort of quality control it operates, whether the result of its resource allocations is to end up doing many things badly, because it has taken on too much. Does the fact, and it probably is one, that you can fix time, cost or quality, but not all three at once, mean that its OK to have reported bugs hanging around for years at a time undealt with? Not necessarily unfixed, but not dealt with and disposed of one way or another? No. In the end that is the route to failure. Do whatever you do to appropriate and justifiable quality standards, and if that means you have no resources left for the new products you would like to introduce, tough. Because you are not going to succeed as a company by introducing them at the expense of overall quality, anyway. There is no better alternative on this than doing what you do, right. And not doing the things you do not have the resources to do right. -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/OT-Computer-news-from-Kassel-tp2264252p2266644.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
Because you are not going to succeed as a company by introducing them at the expense of overall quality, anyway. Maybe someone forgot to explain that to a little outfit called Microsoft... They seem to have succeeded pretty well over the years, publishing products with thousands upon thousands of known bugs, not to mention the all too often sub-standard quality. A company that would forfeit the introduction of new ideas and innovation in a highly competitive arena, just so they can perfect an already successful product, seems like a sure fire path to failure to me. Seems to be less than a smart business strategy, IMO. Best regards, David C. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
Again, we are using the word bugs here on a one dimensional sense, as though all bugs were created equal. Is it reasonable to expect Adobe to fix a bug that deselects an object when I alt-shift-control-right-click on a menu? No, it's not. Is it reasonable to expect them to fix it when it crashes to desktop corrupting the file I had open? Absolutely. If we are going to have any kind of honest discussion about the subject, we have to make this distinction. Also, many bugs are not fixed or dealt with in the minor releases, but are addresses in the major ones. I find that entirely reasonable as well. Bob On Jun 24, 2010, at 1:55 AM, Peter Alcibiades wrote: Does the fact, and it probably is one, that you can fix time, cost or quality, but not all three at once, mean that its OK to have reported bugs hanging around for years at a time undealt with? Not necessarily unfixed, but not dealt with and disposed of one way or another? No. In the end that is the route to failure. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On 06/24/2010 03:31 PM, David C. wrote: Because you are not going to succeed as a company by introducing them at the expense of overall quality, anyway. Maybe someone forgot to explain that to a little outfit called Microsoft... They seem to have succeeded pretty well over the years, publishing products with thousands upon thousands of known bugs, not to mention the all too often sub-standard quality. A company that would forfeit the introduction of new ideas and innovation in a highly competitive arena, just so they can perfect an already successful product, seems like a sure fire path to failure to me. These types of discussions can go on and on forever; but they are really caused by the fact that RunRev have given many users the impression that they are not JUST a commercial company (and to a certain extent that is true); this has led many people (myself included) to expect that because RunRev does takes its existing customers' opinions into consideration, it won't behave like a commercial company. Now the hard, couldn't give a # for your feelings company, and more customer-friendly ones (such as RunRev) run by businessmen with consciences, are different beasts; notwithstanding that, they are both businesses that, at the end of the day, have to worry about how to pay for the bread and cheese, the next patch of R-and-D, and keep their shareholders happy. The road to hell is paved with good intentions; and normally those intentions are of the altruistic kind. The new Apple OS and its WIMP GUI is 'still' a horrible mess and is only reasonably intuitive because we have grown up with the thing. Apple made a lot of ballyhoo about Snow Leopard; but not to sort out the GUI; but to slim down their code so that the system made systems look faster than they did when running the previous OS. Frankly I'm glad I'm not working for RunRev (come to think of it, they're probably extremely gald I'm not working for them . . . . kisses, Richmond); because they must have all sorts of pressures impinging on them from all directions. I may be at least 10 years older than Kevin Miller; but I am sure he is more likely to develop stress-related stomach ulcers than I am. I fool around with my programs for funny Indian writing systems (and I find that extremely mentally stimulating) and so far I have earned the princely sum of 8 Euros because I am not dependent of the computer world for my bread and cheese, and because in terms of programming I am answerable to myself alone. Kevin Miller is right, slap-bang in the middle of a socking great spider's web; a place I would not like to be; and perhaps, knowing that we should be a little less hard on him and his company. Seems to be less than a smart business strategy, IMO. Best regards, David C. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On 06/24/2010 07:02 PM, Bob Sneidar wrote: Again, we are using the word bugs here on a one dimensional sense, as though all bugs were created equal. Is it reasonable to expect Adobe to fix a bug that deselects an object when I alt-shift-control-right-click on a menu? No, it's not. Is it reasonable to expect them to fix it when it crashes to desktop corrupting the file I had open? Absolutely. If we are going to have any kind of honest discussion about the subject, we have to make this distinction. Also, many bugs are not fixed or dealt with in the minor releases, but are addresses in the major ones. I find that entirely reasonable as well. Bob However, a problem that was found in RunRev 2.5 not having been fixed by 4.0 is a bit . . . . . ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)
On 22/06/2010 16:01, Wilhelm Sanke wrote: It is as yet unknown whether during his stay in Edinburgh the new professor had come into contact with Revolution or the Revolution team, but considering the topic of his work this seems to be highly probable. Apparently he had taken a look at the Revolution bug database with its enormous lags in fixing even fatal bugs, e.g. Report #8275 Groups: Bugs and features (last group broken)? of Sept 16, 2009, which astonishingly is still listed as unconfirmed although it contains a recipe to crash Revolution with only 4 lines of script. Wilhelm, I share your frustration with bug reports remaining uncomfirmed for long periods, although I also agree with others (and perhaps you) that an absolutist approach of no-new-features-until-every-bug-is-fixed is not sensible. However, taking a look at the report you mention, #8275, I can't find the recipe for crashing Revolution with only 4 lines of script. There are references in that report, to another report How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines, but from various searches in Bugzilla I am unable to find it. Can you give me the report number? Many thanks, Ben PS Thank you for taking the trouble to report issues in Bugzilla as I know it takes effort and it is a service to the community. But I would recommend, to get the maximum value in return for your trouble, creating separate reports for each issue so that each can be understood as simply as possible, rather than creating one very long report that ties together several issues. Combining many issues in one report makes it hard for the developers to confirm, respond to, or fix any of the elements individually. For example in the report #8275: your item 1 describes a bug (which you mention may be related to a crash) which I can't reproduce, so the bug may or may not have been fixed; your item 2 describes some behaviour which is probably a feature (I've made use of it in the past, though for the unwary it could be a trap); item 3 is a feature request (one I happen to disagree with); your item 4 may be a bug or a feature, but if it is a bug it is one with an easy workaround; your item 5 apparently describes a crashing bug, but is an incomplete recipe. The entire report is set with the severity 'blocker' (Blocks development and/or testing work) - but only item 5 could possibly fit that description (you give a workaround for item 1). ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
To some extent you have a point, but software bugs are a bit trickier. What some people call bugs are really not. Some bugs are extremely obscure, and only affect a very small number of people. Some bugs have a workaround, and so are not critical. For a company to devote all their resources to resolving these kinds of bugs is NOT good business, ESPECIALLY when the sales model is subscription based. People want to see at least one good release each year because they are paying for free upgrades. I recall an old saying that there's no such thing as bug free software. Or to put it another way, to try and make software bug free would cost too much. Bob On Jun 22, 2010, at 8:31 PM, Peter Alcibiades wrote: The price of doing some things well, if you are a company with limited resources, is refusing to do everything badly. Or put it the other way, the price of trying to do too much is that you will not do anything properly or well. In the end, this is company wrecking. Its a life and death issue. If Rev is really as overstretched as it looks, the first step is to close down some stuff until they arrive at a smaller set of things that can be done properly and to quality standards. If you can't fix the bugs in what you have, don't try to introduce more products, as you will then be unable to fix the bugs in them also. In the common phrase, when in a hole, stop digging. A common reaction to this situation is to deny it exists. This is one of the clearest symptoms of the illness. The cure begins with acceptance and acknowledgment of the problem. -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/OT-Computer-news-from-Kassel-tp2264252p2265064.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On Wed, Jun 23, 2010 at 11:07 AM, Bob Sneidar b...@twft.com wrote: [...] they are paying for free upgrades. I'm sorry. I laughed out loud when I read that. Talk about the definition of an oxymoron. ;-) Jeff M. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
Heh heh. Listen to what I mean, not what I say. ;-) Bob On Jun 23, 2010, at 9:13 AM, Jeff Massung wrote: On Wed, Jun 23, 2010 at 11:07 AM, Bob Sneidar b...@twft.com wrote: [...] they are paying for free upgrades. I'm sorry. I laughed out loud when I read that. Talk about the definition of an oxymoron. ;-) Jeff M. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On budget On time Bug free Pick any two. /H ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
Hugh- Wednesday, June 23, 2010, 10:07:57 AM, you wrote: On budget On time Bug free Pick any two. I have enough trouble just picking *one*... -- -Mark Wieder mwie...@ahsoftware.net ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On Wed, Jun 23, 2010 at 2:16 PM, Mark Wieder mwie...@ahsoftware.net wrote: Hugh- Wednesday, June 23, 2010, 10:07:57 AM, you wrote: On budget On time Bug free Pick any two. I have enough trouble just picking *one*... I've mixed them and end up picking budget free... -- -Mark Wieder mwie...@ahsoftware.net ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- http://www.andregarzia.com All We Do Is Code. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
I am very much aware of the fact that software is almost never bug-free. Apart from the first part - where I wanted to direct your attention to the computer pioneer Konrad Zuse - the rest of my post was written with some degree of tongue-in-cheek (both in its positive and negative denotations), which some of you may have overlooked. Also, I consider it an ironic coincidence in itself that we have got a new colleague with a doctorate from Edinburgh University that specializes in software trouble-shooting.- I have been less complaining that there are bugs in Revolution, the main point was my irritation that a bug report can still be listed as unconfirmed after 9 months. What use is a bug database when it is looked at only selectively? And in case described bugs could not be replicated then I expect some follow-up communication from the side of the Rev team. For your convinience I re-quote my post below. Regards, Wilhelm Sanke === 1. People around Kassel - and elsewhere - today celebrate the 100th birthday of Konrad Zuse, the inventor of the first programmable computer. Some extracts from Wikipedia: Konrad Zuse ( 22 June 1910) was a German engineer and computer pioneer. His greatest achievem was the world's first functional program-controlled Turing-complete computer, the Z3, in 1941 (the program was stored on a punched tape). Zuse also designed the first high-level programming language, Plankalkül, first published in 1948. Zuse developed his computer living in a small town near Kassel. His Z3-Computer is one of the exhibits in the Technikmuseum of Kassel. 2. The University of Kassel this semester added another position of a Junior Professor in Computational Sciences to the faculty of its IT-Department. The first holder of this position got his doctorate at the University of Edinburgh. His special field in research and teaching is The structure of programming - trouble-shooting and avoidance. It is as yet unknown whether during his stay in Edinburgh the new professor had come into contact with Revolution or the Revolution team, but considering the topic of his work this seems to be highly probable. Apparently he had taken a look at the Revolution bug database with its enormous lags in fixing even fatal bugs, e.g. Report #8275 Groups: Bugs and features (last group broken)? of Sept 16, 2009, which astonishingly is still listed as unconfirmed although it contains a recipe to crash Revolution with only 4 lines of script. Although this report is now almost one year old, apparently nobody from Revolution so far has bothered to take a look at this bug report. It might be a wise move from the side of the Revolution team to enlist the support and cooperation of our new professor.-- ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
On Wed, Jun 23, 2010 at 4:33 PM, Wilhelm Sanke sa...@hrz.uni-kassel.dewrote: I am very much aware of the fact that software is almost never bug-free. It is not that software is never bug-free... software is only ready when it is bug free, the problem is that software is never ready (or at least I used to repeat that to Dan Shafer while in Monterey). :D -- http://www.andregarzia.com All We Do Is Code. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: [OT] Computer news from Kassel
The price of doing some things well, if you are a company with limited resources, is refusing to do everything badly. Or put it the other way, the price of trying to do too much is that you will not do anything properly or well. In the end, this is company wrecking. Its a life and death issue. If Rev is really as overstretched as it looks, the first step is to close down some stuff until they arrive at a smaller set of things that can be done properly and to quality standards. If you can't fix the bugs in what you have, don't try to introduce more products, as you will then be unable to fix the bugs in them also. In the common phrase, when in a hole, stop digging. A common reaction to this situation is to deny it exists. This is one of the clearest symptoms of the illness. The cure begins with acceptance and acknowledgment of the problem. -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/OT-Computer-news-from-Kassel-tp2264252p2265064.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
