gmane.comp.ide.revolution.user

Sending an e-mail without a dedicated e-mail client

Charles Szasz — 2008-10-07T19:56:57

Is there a simple way to code to send an e-mail from within Revolution without using an e-mail client such as Apple's Mail? I have a program that is designed to send a report as a text file. I run into a problem with RevMail using an e-mail program when the user uses a web based e-mail program.

Re: [ANN] Site Update - Tactile Media

Judy Perry — 2008-10-07T19:29:33

Scott, Looks awesome! Thanks for this! Judy On Tue, Oct 7, 2008 at 12:10 PM, Scott Rossi public.gmane.org> wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN] Site Update - Tactile Media

Scott Rossi — 2008-10-07T19:10:53

Hello Revolutionaries: Just a quick note to announce the redesign/release of Tactile Media's Web site (www.tactilemedia.com). The site update is not as important as a new Revolution Tutorials/Demos area available in the Software section of the site, which now features 32 free and open stacks, complete with thumbnail previews. As well as offering several new demos, many of the older demos have been rewritten, updated, and commented to be more understandable and flexible for use in your own stacks (for example, our GetInLine drag list reordering demo can now be used as a library and no longer requires screen locking to operate). There are really too many updates to list here. Stacks are still being tested for compatibility with Revolution 3, so you may run into some issues -- just let us know. In any event, I thought this would be worth sharing. Have fun, and keep up the revolution... Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: suggestions for cross-version benchmarking test tool?

Richard Gaskin — 2008-10-07T18:19:17

Interesting test case, Malte. Thanks for that - I just added myself to the CC list there. It'll be interesting to see how how pans out. One of the challenges of the test there is that it's testing many very different things at once: That last bit about needing to use "send" is most curious, seeming to imply that the issue may not have anything to do with the field business, but may instead be limited to the handling of pending messages. It would be helpful if someone could try two breaking that up into two different tests: - One which does the field manipulation in a repeat loop - Another which uses "send" to trigger something presumably innocuous, like "get 1+1" That would seem helpful to isolating the root cause. I've just added that as a note to the report. We'll see how it goes....

Re: Re: Re: suggestions for cross-version benchmarking test tool?

Malte Brill — 2008-10-07T17:52:23

Hi Richard, if you want, please look at http://quality.runrev.com/qacenter/show_bug.cgi?id=7257 I too see leakage and drastic slowdowns under Linux, yet I could not boil it down to something as atomic as in this test case. Cheers, malte _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Convert HC Stack to Rev - Without HC?

J. Landman Gay — 2008-10-07T15:59:43

Yes, though you can't do the (often required) "compact stack" part. You can click the Messages button in Rev's toolbar to turn off messages. This will eliminate any error reports while you go through the stack to remove the handlers that are incompatible. It is very important to compact the HC stack in HC before importing however. You may get lucky and things will run fine. But if you see missing cards, scrambled data, or incorrect images (aside from the alpha problem) then the stack needs compacting. On rare occasions an uncompacted stack may not even import at all. You might look into SheepShaver or vMac -- I have run HyperCard on my OS X Intel machine using both. Neither is a perfect solution, but both run well enough to get the compaction done. I particularly like the suggestion of running vMac/HC from a USB stick that I can just plug in whenever I need it (but I've lost the link to that; maybe someone else here still has it. You could try a Google on "vMac on a stick".) Ken Ray has a tutorial on his web site on how to install SheepShaver, maybe he'll chime in with that link.

Re: suggestions for cross-version benchmarking test tool?

Richard Gaskin — 2008-10-07T15:57:08

I just searched the RQCC for "leak" and couldn't find that one. Of the five results that came up in that search it seems only two have strong evidence of being a leak, and both have workarounds provided to avoid the seeming leak condition. What is the stack doing while it's "leaking" "2mb every 3 seconds"? That seems like a lot. Seeing the scripts in question will be very helpful, esp. if submitted in an RQCC report. It wouldn't surprise me if a code base this complex has a leak or two, but I've noticed that RunRev tends to give priority to leaks, perhaps because of their insidious nature and that they're usually relatively easy to fix. True, much of my benchmarking is to find optimal ways to accomplish a given task, independent of platform. There are so many ways to do things in Rev, and I've found that sometimes what might seem the most obvious may not offer the best performance. One of the conveniences of RevBench (available in RevNet for those who haven't seen it -- in Rev choose Development->Plugins->GoRevNet) is that it can be saved so you can run the same tests across different platforms. But it may be just as simple to just make a fresh stack that tests what you need. What does the project you're working on do? Perhaps we might be able to help make a good test for both benchmarking and honing in on the possible leak. I hadn't noticed that until you brought it to my attention; seems I've been running without icons on my Ubuntu system, so while it's still present it isn't as noticeable. I turned on the icons, and yep, I can see it now. My hunch is that it's doing some redundant checking during boot, or maybe building something dynamically behind the scenese which requires changes to the editGroupControls. It seems limited to that one button, and none of my own stuff seems affected, so it seems to be just a scripting issue in the IDE, and a minor (cosmetic) one at that; the functionality of that button seems unaffected. Given what I can see of it, this flicker doesn't appear to be engine-related and shouldn't affect any projects you make with Rev. I've seen broad variance in performance across platforms. Last time I did any testing of that sort I found that text parsing was much faster on Windows than on Mac, even when the Windows installation was VirtualPC running on a Motorola-powered Mac (!). I asked Scott Raney about that at the time and he said that the biggest difference he's seen for platform-independent tasks like text processing (as opposed to system-specific tasks like object rendering) is with compiler design: he said the MS compiler was just darn good at its job relative to Code Warrior (which he was using at the time). If there is a performance difference between Windows and Linux, I suspect there might also be a similar difference between Windows and OS X. I believe that XCode shares many elements in its compiler with GCC, so it may be the case that benchmarking today would show similar results, with Windows outperforming both OS X and Linux. Some things may be optimizable, and I think Mark Waddingham would agree that there's still much that can be done to refine the integration of Rev's rendering engine with the Linux window manager interfaces. But the differences in how the various OS families render windows and controls are so vast that they don't make for good comparison of Rev engine performance. For those task I would test things as Chipp suggested, with the lockScreen true so we're focusing more on the engine's internals and less on the host OS. Of course, with several thousand tokens it wouldn't be practical to test them all. What sorts of things are you working on? If start with what you need to do at the moment we'll have not only an accomplishable subset of testing tasks, but one which is especially relevant for your current work.

Re: Convert HC Stack to Rev - Without HC?

Mark Schonewille — 2008-10-07T13:53:54

Hi Mark, Just suppress messages before you open the stack and edit the scripts. See the Development menu. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering http://economy-x-talk.com http://www.salery.biz Dutch forum: http://runrev.info/rrforum/ Benefit from our inexpensive hosting services. See http://economy-x-talk.com/server.html for more info. On 7 okt 2008, at 15:49, Mark Srebnik wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Convert HC Stack to Rev - Without HC?

Mark Srebnik — 2008-10-07T13:49:17

Greetings, Would like to convert a HyperCard Stack to Rev if possible. However, from reading Jacqueline's excellent tutorial on this I see the following problems. A) Since I use OSX on my MacBook at home, I don't have ability to run HyperCard; ie, no Classic anymore... B) Since I don't have HC to run and edit scripts before converting I can't 1) comment out XCMD's and FCN's as noted in tutorial... 2) edit script to change menu references.. Given the above, wondering if there's any workaround in order to do conversion??? Thanks for any and all input, Mark Silicone Valley Digerati & Rev/Code Noob _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Why I didn't, and why I may, later.

Bernard Devlin — 2008-10-07T10:58:19

Before anyone else jumps in. Richmond, it seems I'm the only one having issues with 2.9 and 3.0. It might be useful for you to download the evaluation versions (particularly if you are using Linux), to see if the product is buggy for you. If not, you've got a good reason to fill the jar asap. Bernard On Tue, Oct 7, 2008 at 11:04 AM, Richmond Mathewson public.gmane.org>wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Why I didn't, and why I may, later.

Richmond Mathewson — 2008-10-07T10:04:32

1. A bit short of money right now. 2. For reasons that have been confirmed in the Use-List since RR 3 was released: the very same reason why I bought a Mac G4 two weeks after they released the G5s. Microsoft and Apple have been slammed time and time again for releasing software (operating systems or other) which still looks Beta-ish. There is a school of thought that Mac OS X is still a bit tatty round the edges (v.g. the inconsistencies that abound in the behaviour of the Finder). Probably why quite a lot of people with PPC Macs feel cheesed-off about being excluded from 10.6. There are folk who will claim that firms release Beta-ish software to raise money to continue work; this has always struck me as a bit disingenuous. Hundreds of people who bought themselves PCs with "Vista" installed are returning to XP because the view is a bit foggy. I am now popping pennies (quite literally) in a jam jar with "3.x" written on it. sincerely, Richmond Mathewson. ____________________________________________________________ A Thorn in the flesh is better than a failed Systems Development Life Cycle. ____________________________________________________________ _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: 3.0 for Linux is 8% slower than 2.6.1 ? (Bernard Devlin)

Bernard Devlin — 2008-10-07T09:47:19

Wilhelm, thanks for this suggestion. I've posted a new request to the list explaining why I would hesitate to use this with Linux. Bernard On Mon, Oct 6, 2008 at 11:44 PM, Wilhelm Sanke, FB01 < sanke-AX8O2M9OGI1D9Q66CtUtOrNAH6kLmebB< at >public.gmane.org> wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

suggestions for cross-version benchmarking test tool?

Bernard Devlin — 2008-10-07T09:46:35

Ok, so since Chipp thinks my benchmark is pretty crummy (which I'm happy to believe), can someone provide me with what they think would be a better way to benchmark the speed of the different engines? I'm reluctant to use Wilhelm's suggestion on Linux, since there is a known memory leak to do with the interaction of Rev and XWindows on Rev 2.9 and Rev 3.0 (by my observation Rev causes X to leak about 2mb every 3 seconds whilst the stack that demonstrates the leak runs). So, I think it's best if any benchmark tries to limit any use of graphics, so that we can try to eliminate/minimize this known bug. As Chipp suggested, I searched the archive for 'benchmarks gaskin' but didn't come up with anything that seemed like a test of the engine rather than a test of a specific feature e.g. regex, filter, offset. I had a look at Richard's revBench but that seems to be a tool designed to just compare two different scripts within the same version of Revolution. I'm looking for something to explain why there are noticeable flickers (for me) in various components of the Rev 3.0 IDE (elements within the menu bar and within property inspectors). As I've mentioned there is a known bug with X, but equally these flickers may be nothing to do with that bug. I think that Rev 3.0 on Linux is just running slower than it is on Windows. If the Linux engines is running slower, whilst the Windows (and maybe OS X) engines have had a significant speed increase, then this could be useful information for the Runrev developers. This speed issue is not merely a cosmetic issue (even though it does help make Rev on Linux look amateurish). Furthermore, the script editor of Rev 3.0 is also quite unusable, since it slows down to a crawl with a script with 2000 lines (it's even noticeably slow on a script of 36 lines). I know my Linux laptop is not the fastest (1.6ghz intel atom), but the flickers are also evident on Linux running inside virtual machines. The flickers aren't there in 2.6.1 on my laptop. Bernard _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: 3.0 for Linux is 8% slower than 2.6.1 ?

Chipp Walters — 2008-10-07T05:09:52

Bernard, Regarding your test stack. (Bottom of message is your test script) I'm not sure what the 'send in time' helps test? I think it better to just repeat your test as many times as you wish and not use 'send in time'. It adds another variable to the process. I can see where this test can be setup to run for a couple of hours using 'send in time'. But, running this test for a long period of time will not take into account any other background processes which may be taking place--thus slowing down the test and providing inaccurate results when compared to another test--even if on the same machine. It appears the only thing you are testing is the random() function, or perhaps I am missing something? Wilhelm's stack is a good benchmark example as it states and tests a specific function. Unless you are only trying to test the speed of the random() function, this test does not provide an overall speed test for Rev. Also, as a note, I typically try not to update the screen on benchmarks (writing to fields or message box) during the time calculation-- as these can represent yet another variable to the test criteria. Also, you are using the round function to calculate your times: put round ((the milliseconds - tStartMS)/1000) into tElapsed This has the possibility of introducing significant error. For instance, when I run your default setting of a 15 seed (on my basic speed desktop), it takes 21.48 seconds to run, but you round that number up or down (in this case it becomes 21) thus introducing a greater than 2% error. If I run a seed of 11 or below, it registers as taking 0 seconds, though it actually takes close to .4 seconds. This is also a significant error percentage-wise (infinity?). If I were to run this on a faster machine (like many of the Macs out there), the potential error would be even greater. Not to mention this error can be compounded by the number of tests you run in your repeat measure field-- which the default is 5-- so on my machine it is theoretically possible to have close to +- 10% difference in actual times vs reported times based upon the default settings. Not very reliable. Your throw commands are a nice trick to exit a handler: if fld "repeat measure" is not a number then throw "repeat needs a number" And I suppose you already know this, but for others reading, you may wish to provide the below errorDialog handler in your button script as well. Of course, it will only display when script debug mode is turned off. on errorDialog pExecutionError answer pExecutionError end errorDialog I hope this helps you understand why you may be having some problems. FYI, Richard Gaskin, a very experienced Rev user and benchmarking guru, has some good benchmarking tools which you might ask about, or search the archives here for. I'd suggest using a proven tool to help you get a grasp on this situation. --->BERNARD's BENCHMARK CODE ----- on mouseUp if fld "repeat measure" is not a number then throw "repeat needs a number" if fld "send delay seconds" is not a number then throw "send delay needs a number" put round(fld "send delay seconds") into tSendDelaySize repeat with tCounter = 1 to (round(fld "repeat measure")) put tSendDelaySize * tCounter into tNextSend send "doTest" to me in tNextSend seconds end repeat end mouseUp on doTest put the long time && the pendingMessages put the milliseconds into tStartMS if fld "seed" is not a number then throw "need a number to kick things off" put round(exp(fld "seed")) into tLimit repeat with tCounter = 1 to tLimit put random(100) & comma & random(100) & comma & tLimit & return after tItemList end repeat put line 1 to 5 of tItemList into tNewItemList put round ((the milliseconds - tStartMS)/1000) into tElapsed put tElapsed & return & tNewItemLIst & return & the long time into fld "result" set the itemDel to "." if item 1 of version() < 3 then put "old" into tVersion else put "new" into tVersion end if set the itemDel to comma put tElapsed & comma after fld tVersion put fld tVersion into tRunningScore if char -1 of tRunningScore is comma then put empty into char -1 of tRunningScore put (tVersion & "avg") into tVersionAvg put avg(tRunningScore) into fld tVersionAvg end doTest _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Thrift library?

Trevor DeVore — 2008-10-07T01:54:40

The main Thrift library is written in C++ and that could be wrapped up in an external if that would be easier then having a native Revolution library. I think creating an external may be the way to go since it would be easier to keep a Thrift external in sync with the current Thrift library (drop in latest C++ files, recompile). Once we have a Revolution Thrift library (external or pure Revolution) then creating Revolution source code from IDL files shouldn't be too bad. The problem is that I don't think companies necessarily distribute their IDL files. I think they just distribute the source created from the IDL files; at least I didn't see any IDL files in the Evernote API distribution. Perhaps a Revolution program that could parse the C++ files generated by Thrift and automatically create an external project might be appropriate. Regards,

Re: [ANN] VisualHubbaHubba utility (Mac)

Howard Bornstein — 2008-10-07T01:40:01

Yes, I was very sad to hear this as they were a responsive small company with great tech support who made an excellent product. Sigh.

Re: more rev 3.0 woes - losing the will to live

Thomas McGrath III — 2008-10-06T22:36:34

Jim, I agree, I thought it was damn funny...... I feel this way every couple of months right before a big break through.... Glad you're here... Tom McGrath On Oct 6, 2008, at 6:15 PM, Jim McNeely wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: more rev 3.0 woes - losing the will to live

Jim McNeely — 2008-10-06T22:15:33

I'm very new here and I thought it was pretty funny. Every tool has its drawbacks. Jim McNeely On Oct 6, 2008, at 12:23 PM, Chipp Walters wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution

Re: 3.0 for Linux is 8% slower than 2.6.1 ? (Bernard Devlin)

Wilhelm Sanke, FB01 — 2008-10-06T22:44:29

"If anyone else has any other benchmarks, I'd be grateful to see them. Mine s3.0 for Linux is 8% slower than 2.6.1 ? eems pretty simple to me, and tests nothing more than a few functions, looping and adding to lists. It will only make any sense if you run the script on the same hardware, using a version of Rev >= 3 and a version of Rev < 3. Bernard" Another test stack - also attached to bug report 5113 of the Rev Quality Center - has been around for some time: Although partly focusing on questions of paintcompression, it provides the possibility to compare engine and IDE speeds of different versions of Metacard and Revolution. One of the results measured by this test stack is that version 2.6.1 of the Rev engine has been the fastest so far when measuring imagedata processing. Other later versions have been shown to be up to 30 - 40 % slower than 2.6.1 in this respect - see the "result page" of the test stack. The new 3.0 Rev engine version has improved considerably over previous versions, but has not yet fully reached the level present in 2.6.1. Measuring speed differences with this stack is a very fast process, as scripts with a duration between few milliseconds and about 50 seconds at the utmost can be easily compared. Regards, Wilhelm Sanke

Re: Thrift library?

Andre Garzia — 2008-10-06T20:53:21

Trevor, I am also using Evernote, I have it on all my computers and my iPhone. I checked the Thrift Wiki and found no information on how to generate your own language. It may be easier to parse the Thrifit IDL file from Revolution and generate the code than add the necessary bits to the Thrift own code base to generate Revolution code. I wish we could create externals from other languages, like python or ruby. Andre On Mon, Oct 6, 2008 at 3:02 PM, Trevor DeVore public.gmane.org> wrote:

Re: more rev 3.0 woes - losing the will to live

Chipp Walters — 2008-10-06T19:23:25

Thanks Joe, A most welcome point. I'm using Rev 3.0 on Vista and XP for some mission critical applications, and have not found any significant problems. I agree a title like this one can put others off. Bernard, I suspect your save issue has to do with some plugin doing an auto-save. I've always disliked the 'auto-save' types of plugins as you never know exactly what and when you're saving. You're welcome to use my altArchive plugin, which saves and creates a serialized backup. Also, I have a stackFormat plugin I wrote awhile back which also saves in legacy format. Note, these have not been tested on Linux that I'm aware of. Just enter into msg: go URL "http://www.gadgetplugins.com/altplugins/StackFormat.rev" and go URL "http://www.altuit.com/hemtools/altPlugin/revAltArchive.rev" HTH, Chipp On Mon, Oct 6, 2008 at 12:25 PM, Joe Lewis Wilkins public.gmane.org> wrote: _______________________________________________ use-revolution mailing list use-revolution-1W37MKcQCpJ21N0xZs15Ng< at >public.gmane.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution