LiveCode Forums.

Thanks for the reply. Sounds like some interesting stuff you're doing.

Yes, I agree that the issues you encountered probably weren't caused by what you were doing per se, just looking for ways to help you find other less troublesome ways to get those done.

FWIW, I have a friend here in LA who's published quite a number of commercial products with Director and at least two with Rev, and I asked him:

"On the a scale of 1 to 10, where user perceptions of bugginess in Rev would be a 10, where would you rate developer perceptions of Director in terms perceived bugginess?"

He replied: "On your scale, I would rate Director at 12 - 15."



In all fairness, he also noted that he's let his Director work lapse a few versions since he picked up Rev, and I understand the latest upgrade from Adobe is a pretty good one.

If you decide to give Rev another go, please consider posting issues you find here. What you're doing is not at all out of the ordinary, and given how many people are able to take advantage of the unique productivity Rev offers, I'd like to believe your experience could be made as productive.

I don't do much work with MySQL, so others here will have to help with that. But there are many here who have a lot of experience with Rev and MySQL, and the only reason I don't use it is that with Rev I've been able to craft my own custom data management solutions so easily that I've not needed a DBMS yet.

Keep us posted with what you find in your evaluation. I'm always happy to learn about progress with other tools.

I'd rate the latest version of Adobe Director 11 the same as your friend. It feels like a beta and runs like one. The recent hotfix has improved it a bit, but it's still not as stable as MX 2004 was.

Paul

Andreas-

You have my sympathy for the problems you're running into. I should say that I've written a unit-test stack for rev with an SQLite backend that I use quite often without running into the sorts of problems you're encountering. If I can help work through these problems, let's see what happens. I fully support and encourage test-first development.

...and I'm quite interested that you've managed to do this in only 50 handlers. That's not by any means a "medium-sized application". I can regularly exceed that by an order of magnitude in a good sized application.

I am a little disappointed that RR hasn't come out with a quick fix for this problem: anybody who has a stack that is doing real-time display of information in fields will be bitten by this critical bug in Linux. It's got to be a little thing to fix, and I dare say if RR were open source, it would be repaired already, just because I would have done it. The only way I can use RR is with the older engine. This bug simply makes Linux RR unusable for a lot of customers! I'd rather have fewer features and more reliability.

We have discovered this memory leak problem in rev v 2.9.
Nothing improved through to 3.5.

Test were conducted on several Linux distros and various hardware.
It is very noticeable when you just scroll text field (longer -> the worse), also move/scroll graphic or other objects. Rev is just "pumping-up" X-Server until all RAM is gone then your system stalls.

HOWEVER recent discovery shows that if you run your rev app on Linux with only XServer installed and no Desktop (Gnome/KDE/XFCE/...), then its fine - no memory leaks.
Rev starting from v 2.9 up made changes in the engine to support native Desktop appearance and that is probably what causes memory leak. It looks like Rev engine has problem with Desktop environments, not XServer directly.

Practically it is unsafe to use Rev built app on Linux Desktop, and unfortunately the only usable Rev for Linux is v. 2.6.1 so far.

Great - it sounds like this is getting narrowed down. The scrolling thing is just what I've been running into. Have you reported this in bugzilla?

This bug was reported a while ago:
http://quality.runrev.com/qacenter/show_bug.cgi?id=7257
so you may want to give your vote there as well.
Surprisingly current status is still "Unconfirmed", so I don't know how many votes it needs to be noticed at least.

Thanks. It looks like #7162, 7216, and 7257 might all deal with the same issue. They're all, of course, "Unconfirmed", and marked either "blocker" or "critical" status.