Re: compileIt for revolution?
Alex Tweedly wrote: Alex, that's a valuable itemization. I've copied it below in its entirety because it's worth a second read. Has it been logged as a request to BZ? It would be great to see those addressed. This seems like an opportunity here for someone who's worked successfully with the SDK to consider teaming up with others to make a nifty Rev-based IDE specifically for making Rev externals. By taking care of all the tedious stuff, it could make crafting externals a lot more fun -- and you wouldn't have to leave you C environment for testing, since it'd all be under one roof. :) Could this be done by generating make files and running GCC through shell(), or am I dreaming? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com I am working on this project, but the *confusing* Externals SDK doesn't help. What aspects have you found confusing? This is only a start - Doesn't say which compilers should work (tells me some that won't - but doesn't say which ones will - and in particular, doesn't say which free ones will :-) (It kind of implies that many of them will, maybe even most of them - but a short list of a few that are expected to work would eliminate that as a possible explanation for troubles run into) - Includes a number of examples which are fragments of C code, without any comments describing the interface being provided, and without showing the corresponding Transcript - Include samples like XSetArray which is a function using the built-in SetArray - but its parameters are never explained, and still something of a mystery. - It doesn't include a tiny, simple example; I'd like to see a very simple example - e.g. return the string hello program - in a separate directory. Not doing OS specific GetComputerName, not calling QT, not just a very, very simple example. With a correspondingly simple Rev stack, and step-by-step instructions (not as detailed as I sent to this list, but some kind of here's the first thing to do instructions). - it intermingles things which are (apart from exceptional cases) fixed with things which are your own, without distinguishing clearly - e.g. There are two header files you'll need to #include, XCmdGlue.h and external.h. ... But there is no external.h file included in the distribution - it means the header file for your code, which will be anything but external.h In fact, the distribution includes article.c and article.h - what should happen is that article.c should #include the article.h - but it doesn't, it #includes external.h - which is non-existent, so you're guaranteed a compile failure at step 1. Not likely to inspire confidence. - it uses examples where the C functions are named with leading underscores - when prepended underscores was described above as (one of ) the reason(s) why the Borland compiler won't work - it includes extra functions that aren't referenced or used (as far as I can tell). e.g. XGetVar and XGetArray are in convolve_and_life.c - but I can't find anywhere they're used. I wonder if a Rev tool set up for writing C, generating the make file, and running GCC would address a lot of this with very little effort ___ 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: compileIt for revolution?
Richard Gaskin wrote: comments on the externals SDK... snipped Has it been logged as a request to BZ? It would be great to see those addressed. No, it hasn't - but only because Mark has seen it, and responded to me, and I've sent him more suggestions directly, ... and so I'm comfortable they will be incorporated into the next version of the SDK; otherwise I would create a BZ to put them in. This seems like an opportunity here for someone who's worked successfully with the SDK to consider teaming up with others to make a nifty Rev-based IDE specifically for making Rev externals. By taking care of all the tedious stuff, it could make crafting externals a lot more fun -- and you wouldn't have to leave you C environment for testing, since it'd all be under one roof. :) Could this be done by generating make files and running GCC through shell(), or am I dreaming? Yes, I think it could be - though I haven't tried it yet. I'm not so sure about building a useful Rev-based IDE for externals. Such an IDE would need to consist of the following parts: - code editor. Doable - though building a code-aware editor with formatting and color (very useful for C) is far from trivial. Might be possible to hive this off to an external editor (emacs, BBedit, etc.) - create/manage additional files (makefiles, .def files if they're needed, etc.) Definitely doable and useful. - debugger. Probably impossible. The create and manage files part would be useful in itself (though possibly need to handles a number of variants for different compilers); and that might be very helpful for people starting to look at externals. But when writing C externals, I found it pretty easy to follow bad pointers, or all the usual C problems - each resulting in access violations and termination of the Rev IDE. So I believe a useful IDE for C (nowadays) *must* provide a protected environment for running the code, and really should provide integrated debugging. The only way I've found to avoid repeated crashes was to build a small support system to emulate a small part of the Rev interface, and the I can build my external and some test programs in C, test and debug the test prog+external bundle within a real C environment (Bloodshed in my case). Only once I've got that working and at least mostly debugged do I try the external from Rev. This may be purely a result of my poor C programming (although I wrote C full-time for a few years, that was nearly 20 years ago, so I really have forgotten more about writing C than I still remember). But I suspect that most people who aren't experienced, current C programmers would find it much the same. I'd love to hear about the development and testing techniques used by experienced external developers. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/35 - Release Date: 30/06/2005 ___ 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: compileIt for revolution?
Sorry - this was sent yesterday, and has been held up by problems contacting RunRev site - trying again Date: Wed, 29 Jun 2005 22:38:50 +0100 From: Alex Tweedly [EMAIL PROTECTED] Subject: Re: compileIt for revolution? Jon wrote: Derek: Let's put it differently. My real interest is in seeing how to optimize Rev code to access arrays in general, and image data in specific, as rapidly as possible. I trust you've already read all the tricks to optimize code mentioned on the list last week (in particular, the ones from Ken's sonsothunder site) http://www.sonsothunder.com/index2.htm?http://www.sonsothunder.com/devres/revolution/revolution.htm Accessing arrays in Rev is slow-ish because they are associative. They are quick for assoc arrays, but it's still a look-up. Access to numbered chunks (e.g. line 3, item K, ...) is dependent on the number being accessed - because it requires a pass through the variable to count chunks. The one big exception to this is character access - char N is a direct lookup (offset N from the start). So if you can access char N of variable that is much faster So the big message for image processing is - don't access it as an array, access it as chars in a variable. Your Brightness code took (for me, for one med size photo) 8.5 seconds to convert from tImagedata into your arrays another 8 seconds to ComputeHistogram By leaving it as tImageData, I could save the conversion time of 8.5 seconds. *and* I could reduce the ComputeHistogram time from 8 seconds to around 2 seconds, by changing repeat with r = 1 to imH repeat with c = 1 to imW put Brightness(c, r) into i add 1 to histo[i] end repeat end repeat to (NB uses the fact that the spare byte is always zero) repeat for each char c in lImageData add chartonum(c) to temp add 1 to count if count = 4 then add 1 to histo[temp] end if put 0 into temp put 0 into count end repeat I realized that this still requires an access to an array for each increment to histo. It would be great if there were a direct access integer variable type, but there isn't. However, if you are desperate enough to save time, you can use char N accesss to a temp variable, and then you can convert that into array accesses: thus the section if count = 4 then add 1 to histo[temp] end if becomes if count = 4 then add 1 to temp -- because 1:256, not 0:255 put numtochar(chartonum(char temp of mytemp) + 1) into char temp of mytemp if chartonum(char temp of mytemp) = 255 then add 255 to histo[temp-1] put czero into char temp of mytemp end if put 0 into temp put 0 into count end if remembering that at the end you need to roll them up repeat with i = 1 to maxHist+1 add chartonum(char i of mytemp) to histo[i-1] end repeat This rather extreme measure reduces the time to 1.2 seconds. So in some ways that's a good saving 8 seconds to 1.2 - but in other ways it shows that it's probably flogging a dying horse. Although I didn't complete it, I believe this technique applied throughout your example would reduce the overall time for this photo of mine from around 55 seconds to 10 or 12 seconds.But the cost is some ugly, barely maintainable code, and it's still beyond the stretch of what a user would be willing to wait for a simple transformation to be done. -- Alex Tweedly http://www.tweedly.net No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005 ___ 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: compileIt for revolution?
Alex: An excellent post, explaining the theory, showing actual results, and summarizing pros and cons. Thank you! Jon === Jon wrote: Let's put it differently. My real interest is in seeing how to optimize Rev code to access arrays in general, and image data in specific, as rapidly as possible. Alex wrote: snip So the big message for image processing is - don't access it as an array, access it as chars in a variable. snip Although I didn't complete it, I believe this technique applied throughout your example would reduce the overall time for this photo of mine from around 55 seconds to 10 or 12 seconds.But the cost is some ugly, barely maintainable code, and it's still beyond the stretch of what a user would be willing to wait for a simple transformation to be done. ___ 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: compileIt for revolution?
Derek, The reason C is popular is because it is cross-platform... Sorry, just my 2 c's... cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Sent: Wednesday, June 29, 2005 18:32 To: How to use Revolution Subject: Re: compileIt for revolution? Derek: First off, thanks for your help. Secondly, why convert it to C? I have already written it in Delphi/Pascal. The whole point was to make something that was cross-platform. If you create an external on your platform (Window? Mac), would it automatically work on the other platforms? Thirdly, the code I wrote is not at ALL how I wrote it in Delphi: the extra loops to transfer the image data to the R/G/B arrays were not necessary in Delphi (and perhaps not in Rev!). Speaking of which, would a new feature for Rev, like repeat for each pixel in imagedata... be one way to speed image processing up? be helpful for anyone else? :) Jon Derek Bump wrote: Alex Tweedly wrote: There's a problem with RevOnline. Here's the central part of Jon's code Right now I'm working on converting Jon's code to C to include within an external. But if anyone happens to know of an easier way, or of an External that already does this...and cares to share...then that would be great. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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 ___ 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: compileIt for revolution?
The file doesn't appear to be accessible within RevOnline. I get an error message file-not-found when I try it. If the code in question is of a manageable size and format (no really long lines) then posting it here is likely the best option. Otherwise (and in any case), can you re-upload the stack, or make it available some other way? gc On Jun 24, 2005, at 5:29 AM, Jon wrote: If anyone wants to try to help me speed optimize my image processing loops, download the obvious program from my user space. Load an image of your choice (but hopefully larger than your screen, to be realistic), then select Brightness, then Linear. ___ 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: compileIt for revolution?
Geoff: I already posted a message saying that you can find the stack at www.jonbondy.com/jlbimage.rev. Another poster noted that the code has errors in it, and wondered if the code was current. I pointed out that I gave up on Rev for this particular application when it proved to be too slow, and that the errors probably were a result of my dropping the project rather than finishing it. If the errors make it impossible to explore how I used arrays, then let me know and I'll fiddle with it until it works better. As I recall, it does actually run at the moment, but I might be wrong. Thanks for your interest! Perhaps some of you more experienced Rev'ers will be able to demonstrate how to use arrays better for those of us who are newer to Rev. :) Jon Geoff Canyon wrote: The file doesn't appear to be accessible within RevOnline. I get an error message file-not-found when I try it. If the code in question is of a manageable size and format (no really long lines) then posting it here is likely the best option. Otherwise (and in any case), can you re-upload the stack, or make it available some other way? gc On Jun 24, 2005, at 5:29 AM, Jon wrote: If anyone wants to try to help me speed optimize my image processing loops, download the obvious program from my user space. Load an image of your choice (but hopefully larger than your screen, to be realistic), then select Brightness, then Linear. ___ 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: compileIt for revolution?
Geoff Canyon wrote: The file doesn't appear to be accessible within RevOnline. I get an error message file-not-found when I try it. If the code in question is of a manageable size and format (no really long lines) then posting it here is likely the best option. Otherwise (and in any case), can you re-upload the stack, or make it available some other way? There's a problem with RevOnline. Here's the central part of Jon's code -- move image data into im1 repeat with r = 1 to imH repeat with c = 1 to imW #need to reverse for Mac and post MC 2.4.2 engines!! if the platform is MacOS or version()2.4.2 then put charToNum(char tPos + 4 of timagedata) into tB1[r,c] put charToNum(char tPos + 3 of timagedata) into tG1[r,c] put charToNum(char tPos + 2 of timagedata) into tR1[r,c] else put charToNum(char tPos + 1 of timagedata) into tB1[r,c] put charToNum(char tPos + 2 of timagedata) into tG1[r,c] put charToNum(char tPos + 3 of timagedata) into tR1[r,c] end if put tPos + 4 into tPos end repeat end repeat on ComputeHistogram repeat with i = 0 to maxHist put 0 into histo[i] end repeat repeat with r = 1 to imH repeat with c = 1 to imW put Brightness(c, r) into i add 1 to histo[i] end repeat end repeat end ComputeHistogram on ApplyTransferFunction local b repeat with r = 1 to imH repeat with c = 1 to imW put Brightness(c, r) into b put (transfer[b] + 1) / (b + 1) into adjFactor AdjustBrightness(r, c, adjFactor) end repeat end repeat -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005 ___ 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: compileIt for revolution?
Alex Tweedly wrote: There's a problem with RevOnline. Here's the central part of Jon's code Right now I'm working on converting Jon's code to C to include within an external. But if anyone happens to know of an easier way, or of an External that already does this...and cares to share...then that would be great. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Derek: First off, thanks for your help. Secondly, why convert it to C? I have already written it in Delphi/Pascal. The whole point was to make something that was cross-platform. If you create an external on your platform (Window? Mac), would it automatically work on the other platforms? Thirdly, the code I wrote is not at ALL how I wrote it in Delphi: the extra loops to transfer the image data to the R/G/B arrays were not necessary in Delphi (and perhaps not in Rev!). Speaking of which, would a new feature for Rev, like repeat for each pixel in imagedata... be one way to speed image processing up? be helpful for anyone else? :) Jon Derek Bump wrote: Alex Tweedly wrote: There's a problem with RevOnline. Here's the central part of Jon's code Right now I'm working on converting Jon's code to C to include within an external. But if anyone happens to know of an easier way, or of an External that already does this...and cares to share...then that would be great. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Jon wrote: First off, thanks for your help. Not a problem. Secondly, why convert it to C? I have already written it in Delphi/Pascal. The whole point was to make something that was cross-platform. If you create an external on your platform (Window? Mac), would it automatically work on the other platforms? The external I make would be for Windows, but I hope releasing the source will allow someone on another platform to port the code. As far C, it's the only way I know how to make image commands and functions for Revolution that are fast enough to consider using in commercial applications. Thirdly, the code I wrote is not at ALL how I wrote it in Delphi: the extra loops to transfer the image data to the R/G/B arrays were not necessary in Delphi (and perhaps not in Rev!). If it's possible to convert Delphi to a Rev External then that would be a solution, but I know nothing about Delphi. Speaking of which, would a new feature for Rev, like repeat for each pixel in imagedata... be one way to speed image processing up? be helpful for anyone else? I think it would be helpful, but still rather slow. Submit it as an enhancement on RevZilla. If people want it they will vote for it. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Derek: Let's put it differently. My real interest is in seeing how to optimize Rev code to access arrays in general, and image data in specific, as rapidly as possible. If I wanted to code a DLL to do the processing, I know how to do that (theoretically). I was looking at Rev as a way to write portable code (in Rev). So, if you want to port my Rev code to C, please feel free to do so, but it would not be solving the original problem I wanted to solve (optimizing Rev code). Thanks again! :) Jon Derek Bump wrote: Jon wrote: First off, thanks for your help. Not a problem. Secondly, why convert it to C? I have already written it in Delphi/Pascal. The whole point was to make something that was cross-platform. If you create an external on your platform (Window? Mac), would it automatically work on the other platforms? The external I make would be for Windows, but I hope releasing the source will allow someone on another platform to port the code. As far C, it's the only way I know how to make image commands and functions for Revolution that are fast enough to consider using in commercial applications. Thirdly, the code I wrote is not at ALL how I wrote it in Delphi: the extra loops to transfer the image data to the R/G/B arrays were not necessary in Delphi (and perhaps not in Rev!). If it's possible to convert Delphi to a Rev External then that would be a solution, but I know nothing about Delphi. Speaking of which, would a new feature for Rev, like repeat for each pixel in imagedata... be one way to speed image processing up? be helpful for anyone else? I think it would be helpful, but still rather slow. Submit it as an enhancement on RevZilla. If people want it they will vote for it. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Jon wrote: So, if you want to port my Rev code to C, please feel free to do so, but it would not be solving the original problem I wanted to solve (optimizing Rev code). I feel the same way you do. I've always been a fan on Transcript and how easy it is for me to comprehend and it's portability across various platforms. I also, however, get annoyed when I see any type of repeat or loop structure that slows to a crawl when it has to process data thousands upon thousands of times. I tried doing optimizations for images with matchText and replaceText, but only ended up getting less than satisfactory results. Just thought I'd share my results with that. :) In the meantime, if I happen to come up with anything I will definitely let you, and everyone else know. If I do manage to convert your scripts to C they will also be posted, so I thank you. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Maybe there was one better than Mark's! GRIN On Jun 24, 2005, at 2:30 PM, Richard Gaskin wrote: Jerry Daniels wrote: I thought Tom Pittman did a very good job of maintaining the purity of HyperTalk when he did CompileIt! Any future efforts could stand on his shoulders in that regard. Just get an interface more like Mark Hanrek's please. :) So much faster, so much simpler -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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: compileIt for revolution?
Jon wrote: I already posted the code and announced it on this list: look for my image processor in my user space, open a large image (at least 1000x1000), select Bright, and then Linear. Jon - I got an error trying to download your stack from RevOnline. Did you try to upload it (or change its name / description) over the weekend while the servers were dodgy ? Could you maybe either reload it, or if necessary contact Rev support so they know they need to figure out why it won't download (Currently it gives an error File not Found The URL you have entered points to an unknown file. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005 ___ 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: compileIt for revolution?
I already posted the code and announced it on this list: look for my image processor in my user space, open a large image (at least 1000x1000), select Bright, and then Linear. I look forward to seeing what you optimists ... er ... optimizers come up with! :) Jon Geoff Canyon wrote: On Jun 24, 2005, at 4:26 AM, Jon wrote: With all due respect, Jim, if you are trying to do even simple math on a large array of numbers (like computing a histogram of image data), Rev is simply too slow to use. It has nothing to do with data structures: it has to do with slow pCode trying to run tight loops. As stated previously, I cannot accept this statement/conclusion without seeing the code in question. There are simply too many ways to write slow code to assume that Rev can't do a task based solely on a very general description -- unless the description involves real time first-person gaming ;-) ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
At 1:09 PM -0600 6/24/2005, Dar Scott wrote: On Jun 24, 2005, at 12:42 PM, Jim Bufalini wrote: However, the repeat with i = form being slower than the repeat for each was news to me! It should be mentioned in the docs. (And probably is and I don't know where.) In the dictionary for the repeat control structure. ;-) Use the for each form if you want to perform an action on each chunk in a container. This form is much faster than the with countVariable = startValue to endValue form when looping through the chunks of a container. (It doesn't go into detail about why this is so, though, and that would be interesting and perhaps useful information to add.) There also used to be some mentions of this in the cookbook, although the cookbook seems to have gone away. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.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: compileIt for revolution?
I sent this message Saturday, and it just came back to me as bounced (because the list-server was off-line). So here it is again - with an addendum ... Geoff Canyon wrote: On Jun 24, 2005, at 4:26 AM, Jon wrote: With all due respect, Jim, if you are trying to do even simple math on a large array of numbers (like computing a histogram of image data), Rev is simply too slow to use. It has nothing to do with data structures: it has to do with slow pCode trying to run tight loops. As stated previously, I cannot accept this statement/conclusion without seeing the code in question. There are simply too many ways to write slow code to assume that Rev can't do a task based solely on a very general description -- unless the description involves real time first-person gaming ;-) Well, the problem Jon mentioned (histogram of image data) is pretty well defined. To be usable, you need to do it for reasonable size pictures in less than 1-2 secs. (where reasonable is defined to be whatever your camera takes, since that's the data you're most likely to want a histogram of, in preparation for controlling contrast, colour balance, etc.) Naive code to do it is something like put 0 into count repeat for each char c in the imageData of img Image switch count mod 4 case 0 break case 1 add 1 to tRed[chartonum(c)] break case 2 add 1 tGreen[chartonum(c)] break case 3 add 1 to tBlue[chartonum(c)] -- put -1 into count break default put error count into msg end switch add 1 to count end repeat displayHistogram tRed, tGreen, tBlue For me, on my fairly puny laptop, that takes around 175 seconds, so I only need a 300x speedup. And with an equally naive C external, it takes about 400 ms - about a quarter of which is formatting the result back suitable for Rev, and then Rev reformatting it suitable for my displayHistogram function. I tried some other Transcript approaches (I think the fastest one I found was replacing the unused bytes by 'cr's sorting lines by char 1 of each (remembering to set caseSensitive to true first !!) scanning through the lines, counting as you go until char 1 changes, then putting that count into the appropriate array element and repeat the sort + scan for char 2 and char 3 in turn This brought the time needed for a small photo (800x600) from 14 secs down to 7; unfortunately on a large photo that took more than 5 minutes, and increased my Windows Virtual Memory twice. But even on the small photo the time taken is still enough to make it unusable. -- Alex Tweedly http://www.tweedly.net No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005 ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
On Jun 26, 2005, at 4:01 PM, Jeanne A. E. DeVoto wrote: It should be mentioned in the docs. (And probably is and I don't know where.) In the dictionary for the repeat control structure. ;-) I thought it would be, but when I skimmed over that, I missed it. Dar ___ 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: compileIt for Revolution?
How about this: on eq @x,y -- note x is by reference put y into x end eq You can use that in the order you asked for like this: on mouseUp put 0 into b eq b,7 put b -- puts 7 eq b,b+3 put b -- puts 10 end mouseUp ___ 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: compileIt for revolution?
On Jun 22, 2005, at 4:52 PM, Richard Gaskin wrote: And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Actually, I think Tuviah told me that one too. ;-) On the subject of speed, obviously there are things that are more challenging in Revolution. But anyone who says, My task is too complex/slow, needs to post source code here. Applying a few extra brains to the problem often yields impressive results. Slow code can be written in any language. Transcript makes it very easy to write code, but also very easy to write slow code. gc ___ 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: compileIt for revolution?
Geoff Canyon wrote: On Jun 22, 2005, at 4:52 PM, Richard Gaskin wrote: And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Actually, I think Tuviah told me that one too. ;-) On the subject of speed, obviously there are things that are more challenging in Revolution. But anyone who says, My task is too complex/slow, needs to post source code here. Applying a few extra brains to the problem often yields impressive results. Slow code can be written in any language. Transcript makes it very easy to write code, but also very easy to write slow code. I was browsing the DMOZ Transcript listing and just noticed the addition of your Beautiful Transcript page -- so cool: http://www.inspiredlogic.com/beautiful/ -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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: compileIt for revolution?
Hello, Slow code can be written in any language. Transcript makes it very easy to write code, but also very easy to write slow code. Could you, please, give us (newbies/intermediate scriptesr) some examples of fast/slow script code ? Thanks, Christian L. Le 24 juin 05 à 09:27, Geoff Canyon a écrit : On Jun 22, 2005, at 4:52 PM, Richard Gaskin wrote: And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Actually, I think Tuviah told me that one too. ;-) On the subject of speed, obviously there are things that are more challenging in Revolution. But anyone who says, My task is too complex/slow, needs to post source code here. Applying a few extra brains to the problem often yields impressive results. Slow code can be written in any language. Transcript makes it very easy to write code, but also very easy to write slow code. gc ___ 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
Fast/slow code example (was: Re: compileIt for revolution?)
Hi Christian, Le 24 juin 05 à 10:21, Langers Christian a écrit : Could you, please, give us (newbies/intermediate scriptesr) some examples of fast/slow script code ? They would be too many :-) In fact, the problem is often more an architecture issue than a simple code issue. But here is one tiny trivial example among thousands to give you some clues: on CheckList repeat with i = 1 to the number of lines of fld List1 set the itemDel to tab put item 2 of line i of fld List1 cr after fld List2 end repeat end CheckList Main errors in the above 4 lines are: manipulate data directly from a field (a lot of work for the engine) use the repeat with i form slower than the repeat for each form (especially noticeable with long lists) force a screen redraw at each repetition (that's the must for slowing down) set the itemDel unnecessarily at each repetition The result with 1000 lines: more than 13 seconds... Better code: on CheckList local tList, tLine, tNewList - put fld List1 into tList set the itemDel to tab repeat for each line tLine in tList put item 2 of tLine cr after tNewList end repeat put tNewList into fld List2 end CheckList manipulate data into a variable use the repeat for each form use one screen redraw only set the itemDel only when needed The result with 1000 lines: less than 20 milliseconds! 650 times faster... Keep in mind that to answer correctly your request, this post should be a 300 pages book :-) May be Dan wrote it? Best Regards from Paris, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ 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: compileIt for Revolution?
How about this: on eq @x,y -- note x is by reference put y into x end eq You can use that in the order you asked for like this: on mouseUp put 0 into b eq b,7 put b -- puts 7 eq b,b+3 put b -- puts 10 end mouseUp Does Transcript allow pointers?!? If so, big news to me (new in latest engine or something?!?) I tested your handler without the pointer symbol (@) and it seemed to work. If I were to do it that way I would function equals theVar,theVal put theVal into theVar return theVar end equals then in the script equals(b,2) does affect 2 to b. Both seem to work. However it is still not infixing. So its not really what I'm looking for. Also earlier someone suggested you could use == for assignment. I don't think that is the case, but I am no expert in C. I thought that all languages other than basic use two different operators for affectation and comparison to avoid any confusion. Allowing == to operate assignments would be illogical. I'm not sure why I refer to affectation as affectation and not assignment. I speak French and German fluently, maybe that is why? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: Fast/slow code example (was: Re: compileIt for revolution?)
Thanks for your answer, Keep in mind that to answer correctly your request, this post should be a 300 pages book :-) Wouldn't it be time to write that book ? ;-) I see a little bit better how to optimize my scripts... Perhaps, I will find more infos in the online scripting conferences ? Christian from Luxembourg ___ 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: compileIt for revolution?
With all due respect, Jim, if you are trying to do even simple math on a large array of numbers (like computing a histogram of image data), Rev is simply too slow to use. It has nothing to do with data structures: it has to do with slow pCode trying to run tight loops. Jon Jim Bufalini wrote: Guess I'll add my two cents. I'm a newbie to Rev (Revolution) but worked over 25 years in Rev (Revelation), another similar, high-typed, extensible, flexible, run as you program, script language. It's an implementation of Pick on the PC. I was considered an expert. I also owned a company and employed programmers. I too, have heard these discussions hundreds of times, over the years. Speed of execution rarely relates to code, or the language, or whether it's compiled, or in pcode or whatever. It always has to do with data, whether the data is in arrays, or a database, or whatever object. Any language can add 2 to 2 instantly, regardless of the syntax. You don't get speed by changing languages, or writing lengthy workarounds, or complaining about your tools. You get speed by designing, in advance, the layout of your data. This requires straight thinking. 1. Know what you are setting out to accomplish before you type one character of code (what are your client's (your) goals?). 2. Layout and optimize the data you are going to access BEFORE writing any code. How are you indexing the data? Is it real indexing or organization? 3. Now write your code. If you find yourself writing spaghetti code, STOP, go back to step 1. Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dan Shafer Sent: Wednesday, June 22, 2005 12:12 PM To: How to use Revolution Subject: Re: compileIt for revolution? This whole discussion has been revealing and intriguing to me. My favorite programming language is Smalltalk. But before it was possible to create UIs for Smalltalk without writing code, I found it cumbersome. When a product called WindowBuilder came along, I felt like we'd achieved the ultimate development environment. In many ways, I still think that. Smalltalk had other problems, unfortunately, that made it great to code in, difficult to impossible to deploy. Then my second favorite language was Python. The GUI-building tools for Python are pathetic to non-existent. But the language is powerful and elegant and extends naturally. If the PythonCard project I was engaged in before I discovered Revolution had been on a fast track or complete, odds are I'd have never used Rev. Now I favor Transcript and RunRev. Building UIs is all but painless and 95% of what I want or need to do in creating apps is simple inside the elegance of Transcript. But Transcript isn't object- oriented. Two aphorisms came to mind as I read this entire thread again today. One is, No good programmer uses only one tool for everything. The other is, It's a poor workman who blames his tools. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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 ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
I think such a book should make a distinction between slow/fast code in general, and specific Transcript tricks to speed up (or to avoid slowing down) your code. Regarding the later, you can check the following url : http://www.sonsothunder.com/index2.htm?http://www.sonsothunder.com/devres/revolution/revolution.htm under scripting tricks. By following some advices in these 3 papers, I've been able to speed up some script by a factor of 5 to 7, which is greatly apreciated when one has to run heavy tasks online with Rev cgi... JB Thanks for your answer, Keep in mind that to answer correctly your request, this post should be a 300 pages book :-) Wouldn't it be time to write that book ? ;-) I see a little bit better how to optimize my scripts... Perhaps, I will find more infos in the online scripting conferences ? ___ 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: compileIt for Revolution?
I wasn't going to say this before, but I agree that XTalk has NOTHING to do with Pascal. The control structures are entirely different (no FOR, no WHILE, different CASE), there is no type checking, no variable scoping, no procedures. The quotes you provide only illustrate the point that some people who write books are clueless. Jon, in hyper-curmudgeon mode Eric Engle wrote: Message: 2 Date: Thu, 23 Jun 2005 10:15:28 -0400 From: Mikey [EMAIL PROTECTED] Subject: Re: compileIt for Revolution? To: How to use Revolution use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Try not to get your knickers in a twist. In case you haven't noticed, hypertalk/transcript is clearly a Pascal derived language, they just got rid of begin/end, loosely typed it, and made the operator of affectation verbose. ROTFL/ OMG that's funny. Don't forget scoping, and the overarching paradigm of cards, backgrounds, stacks scripts, properties, and messages and an inheritence path, and the vocabulary, and the fact that nobody could describe what it was, and the fact that it was originally intended to be interpreted not compiled, and therefore DO, and oh hell. You weren't serious so I don't have to add anything here. I mean - really - I was pretty sure xTalk was inspired by COBOL's verbose syntax and...and...choking on my beverage/ . Now that I look at it, I'm having a hard time telling the difference between BASIC and LISP and APL. ROTFL/ Dude, you slay me. Ok, now in case you were serious (and if you were I'm sorry for laughing and making fun of your post) xTalk is now a legacy language type with expectations and conventions and philosophy. I'm reasonably sure that := doesn't fit that philosophy, nor does a=b. If you want compact, you need to go somewhere else. xTalk is intentionally verbose. Philosophically, I like it that way. It means that it is much easier for me to read someone else's code, especially since most of you can't write an intelligent comment in your code to save your lives. I'm going to stop reading this thread now before I REALLY get flamed. Well, yes, that might be a good idea actually. Intelligent debates are generally dispassionate and reasonable since intelligent people are after the truth as opposed to stroking their ego. You might have heard of the maxim Fortiter in re , suaviter in modo. If not, look it up. In any event: think about it. Substantively, I stand by my story: xTalk is a scripting language which is clearly derived from Pascal. Don't take my word for it though; get a copy of think pascal (it's free) and look at its debugger and hypercards, its script formatter and hypercards. Or, just read wikipedia. HyperTalk scripts are fairly similar to written English, and use a logic structure similar to the Pascal programming language. http://en.wikipedia.org/wiki/HyperTalk HyperTalk is the scripting language of HyperCard and its clones. It is similar in syntax to Pascal, and includes enough object-like data structures and programming aids to make it a quite useful development environment (Allen 103). http://www.iath.virginia.edu/elab/hfl0133.html There's even an entire article on macTech Comparing HyperTalk to Pascal which says, Both Pascal and HyperTalk provide powerful if-then-else control structures with very similar syntax. The specification and calling of user defined functions in Pascal and HyperTalk is almost identical. http://www.mactech.com/articles/mactech/Vol.04/04.09/HyperTalk,Pascal/ Based on the comparisons presented above between Pascal and HyperTalk, it should be clear that HyperTalk is indeed a powerful language with many similarities to Pascal. I could keep looking, but I think I've made my point. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: compileIt for Revolution?
Le 23 juin 05 à 20:20, Eric Engle a écrit : xTalk is a scripting language which is clearly derived from Pascal. I never think of that... Is it a real scoop I missed since 20 years, only bad news or a weird analysis from some keyhole journalism? :-) Best regards from Paris, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ 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: compileIt for revolution?
Geoff: If anyone wants to try to help me speed optimize my image processing loops, download the obvious program from my user space. Load an image of your choice (but hopefully larger than your screen, to be realistic), then select Brightness, then Linear. Let the optimization wars begin! :) Jon Geoff Canyon wrote: On Jun 22, 2005, at 4:52 PM, Richard Gaskin wrote: And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Actually, I think Tuviah told me that one too. ;-) On the subject of speed, obviously there are things that are more challenging in Revolution. But anyone who says, My task is too complex/slow, needs to post source code here. Applying a few extra brains to the problem often yields impressive results. Slow code can be written in any language. Transcript makes it very easy to write code, but also very easy to write slow code. gc ___ 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: compileIt for revolution?
Jon, My point exactly: a large array of numbers = data So is the photograph you are computing the histogram on. Would either of these change, if you switch languages? Hence, they are external to your language, or data. I write business application software, so I've never had to compute a histogram and admit I have no clue as to what's involved in that process. However, I have to believe that it is no different than someone saying we have over 200,000 lengthy depositions and need to quickly know any deposition where Jon said to Jim with all due respect in the second quarter of the year 2005 while discussing the topic of compilIT for revolution?. And, we don't want any false positives. If you try to brute force this and depend on your language, OS, and platform for speed of execution, you could be waiting minutes, hours or even days for the result. But, if you know the kind of data manipulation you will be doing in advance, you can parse, index, or otherwise reorganize the source data in such a way as to minimize large data sources or large arrays. Now, depending on how well you organized your data, whether your language is in pcode or machine compiled, results in only milliseconds of difference. Believe me, over 25 years of programming experience bears this out. Jim -Original Message- From: Jon [mailto:[EMAIL PROTECTED] Sent: Friday, June 24, 2005 1:27 AM To: [EMAIL PROTECTED]; How to use Revolution Subject: Re: compileIt for revolution? With all due respect, Jim, if you are trying to do even simple math on a large array of numbers (like computing a histogram of image data), Rev is simply too slow to use. It has nothing to do with data structures: it has to do with slow pCode trying to run tight loops. Jon Jim Bufalini wrote: Guess I'll add my two cents. I'm a newbie to Rev (Revolution) but worked over 25 years in Rev (Revelation), another similar, high-typed, extensible, flexible, run as you program, script language. It's an implementation of Pick on the PC. I was considered an expert. I also owned a company and employed programmers. I too, have heard these discussions hundreds of times, over the years. Speed of execution rarely relates to code, or the language, or whether it's compiled, or in pcode or whatever. It always has to do with data, whether the data is in arrays, or a database, or whatever object. Any language can add 2 to 2 instantly, regardless of the syntax. You don't get speed by changing languages, or writing lengthy workarounds, or complaining about your tools. You get speed by designing, in advance, the layout of your data. This requires straight thinking. 1. Know what you are setting out to accomplish before you type one character of code (what are your client's (your) goals?). 2. Layout and optimize the data you are going to access BEFORE writing any code. How are you indexing the data? Is it real indexing or organization? 3. Now write your code. If you find yourself writing spaghetti code, STOP, go back to step 1. Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dan Shafer Sent: Wednesday, June 22, 2005 12:12 PM To: How to use Revolution Subject: Re: compileIt for revolution? This whole discussion has been revealing and intriguing to me. My favorite programming language is Smalltalk. But before it was possible to create UIs for Smalltalk without writing code, I found it cumbersome. When a product called WindowBuilder came along, I felt like we'd achieved the ultimate development environment. In many ways, I still think that. Smalltalk had other problems, unfortunately, that made it great to code in, difficult to impossible to deploy. Then my second favorite language was Python. The GUI-building tools for Python are pathetic to non-existent. But the language is powerful and elegant and extends naturally. If the PythonCard project I was engaged in before I discovered Revolution had been on a fast track or complete, odds are I'd have never used Rev. Now I favor Transcript and RunRev. Building UIs is all but painless and 95% of what I want or need to do in creating apps is simple inside the elegance of Transcript. But Transcript isn't object- oriented. Two aphorisms came to mind as I read this entire thread again today. One is, No good programmer uses only one tool for everything. The other is, It's a poor workman who blames his tools. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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
Re: compileIt for Revolution?
On Jun 24, 2005, at 2:19 AM, Eric Engle wrote: on eq @x,y -- note x is by reference put y into x end eq You can use that in the order you asked for like this: on mouseUp put 0 into b eq b,7 put b -- puts 7 eq b,b+3 put b -- puts 10 end mouseUp Does Transcript allow pointers?!? If so, big news to me (new in latest engine or something?!?) I tested your handler without the pointer symbol (@) and it seemed to work. The @ sign before the variable name implements pass by reference. Without it the two puts would both put 0, because the value of b is unaffected by the calls. With the @ sign, the first time b is 7, the second it is 10. Granted it's not infix, but it is in the order requested: target,value. ___ 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: compileIt for revolution?
Dan, Perhaps we are in perfect agreement, just expressing it differently... I could not argue with the way you have expressed it here. Dennis On Jun 24, 2005, at 1:09 AM, Dan Shafer wrote: Dennis. You make some excellent points. I don't think that *my* programming needs should drive the direction of the language or the tool. And I'm certainly not opposed even to *major* extensions and enhancements of the language. My only real sticking point is that if and when new things are added, they be done in a way that is as cross-platform as possible, as innocuous to coders for other platforms as feasible, and implemented in a way that keeps the consistent flavor and style of xTalk, including its verbosity. Verbosity is a virtue in my mind. Not only does it make code more readable and therefore maintainable, but I can't tell you how many times I've just sort of guessed at what command or property change might have some desired effect only to have it behave exactly as predicted. Only with xTalk and Python have I had that kind of experience. And I love it! ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
Well, _my_ understanding of the online scripting conferences is that they are intended towards newbies; thus they are more about basic functionality and how-to use Rev as opposed to code optimization. Am I wrong Jacque? Judy On Fri, 24 Jun 2005, Langers Christian wrote: Perhaps, I will find more infos in the online scripting conferences ? ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
Eric, For someone moving from other languages (like I am) to Transcript, I believe three of the four errors you point out in your example should be obvious and the same in all languages. Those are: 1. Repeatedly accessing the same data structure (field) instead of first putting it into a variable. 2. Repeatedly updating the screen on a background process. 3. Repeatedly setting a property that only needs to be set once. However, the repeat with i = form being slower than the repeat for each was news to me! There is nothing in the documentation, that I can find, that addresses the most efficient way, from the perspective of the engine, to write a control structure. Apparently, this is particularly true of the repeat structure. Is it also true for say the if..then structure? Is it more efficient to put your conditions into variables and then use the variables as conditions of the if...then? These are the kinds of things a newbie (like myself) would greatly appreciate being documented. This is to say, if there are two or more ways to write the same statement (as with the repeat example), then if someone knows one works faster than the rest, because of their knowledge of the inner workings of the engine, then this would be valuable to document or post. This might cut down the 300 pages. :) Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eric Chatonet Sent: Thursday, June 23, 2005 11:02 PM To: How to use Revolution Subject: Fast/slow code example (was: Re: compileIt for revolution?) Hi Christian, Le 24 juin 05 à 10:21, Langers Christian a écrit : Could you, please, give us (newbies/intermediate scriptesr) some examples of fast/slow script code ? They would be too many :-) In fact, the problem is often more an architecture issue than a simple code issue. But here is one tiny trivial example among thousands to give you some clues: on CheckList repeat with i = 1 to the number of lines of fld List1 set the itemDel to tab put item 2 of line i of fld List1 cr after fld List2 end repeat end CheckList Main errors in the above 4 lines are: manipulate data directly from a field (a lot of work for the engine) use the repeat with i form slower than the repeat for each form (especially noticeable with long lists) force a screen redraw at each repetition (that's the must for slowing down) set the itemDel unnecessarily at each repetition The result with 1000 lines: more than 13 seconds... Better code: on CheckList local tList, tLine, tNewList - put fld List1 into tList set the itemDel to tab repeat for each line tLine in tList put item 2 of tLine cr after tNewList end repeat put tNewList into fld List2 end CheckList manipulate data into a variable use the repeat for each form use one screen redraw only set the itemDel only when needed The result with 1000 lines: less than 20 milliseconds! 650 times faster... Keep in mind that to answer correctly your request, this post should be a 300 pages book :-) May be Dan wrote it? Best Regards from Paris, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ 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: Fast/slow code example (was: Re: compileIt for revolution?)
On Jun 24, 2005, at 12:42 PM, Jim Bufalini wrote: However, the repeat with i = form being slower than the repeat for each was news to me! Upon reflection, you might have wondered about that. The key is that the first uses 'line i of x' in the loop. The length of time to get this value increases with i. Normally, values are simply sequences of characters and values with multiple lines are simply values that contain some line-delimiter characters (coded the same as ASCII LF). Though it is possible that some internal optimization breaks these up into structured data or a line-index table is cached, it is reasonable to suspect that this is not the case. If there is no optimization to finding line n, then all characters form the start of the string to line n must be searched. It is possible that some compiler optimization would look for line n in loops and convert, but our first assumption should be that it probably doesn't. We might assume that 'for each' does not have this limitation. We might assume that 'for each' keeps one or more hidden character indexes in managing the loop. Given such suspicions we might try some timing or ask on the list. This does not currently apply to characters; 'char n of s' executes in constant time. Even so... We all are sometimes surprised by things that should jump out. I am. It should be mentioned in the docs. (And probably is and I don't know where.) Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ 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: compileIt for revolution?
Paul, My thoughts pretty much mirror your own, Paul. First step is environment independent code for parsing, arrays, calculations. No timeline or cost on this yet. Still seeing who's interested. -JD On Jun 23, 2005, at 5:42 PM, [EMAIL PROTECTED] wrote: Jerry, Assuming there is sufficient interest what is the first step, and what would THAT cost? I'm thinking that the initial ScriptCompiler (or some better name) would just turn Transcript into machine code. This would be of interest to me (hopefully others) who want to put guarded code in places other than the standalone (for example a proprietary calculation in an order processing stack - where all the other code is accessible). The next step might be array processing or tool box calls or These could be built later and sold separately; for example ScriptCompiler I, ScriptCompiler II, etc. Paul Looney ___ 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: compileIt for revolution?
Dan, I thought Tom Pittman did a very good job of maintaining the purity of HyperTalk when he did CompileIt! Any future efforts could stand on his shoulders in that regard. -JD On Jun 23, 2005, at 7:26 PM, Dan Shafer wrote: If you can write externals in Transcript syntax and NOT over-extend the language to accommodate this demand, I don't have an issue. But that is not generally the case. When people talk about writing externals they generally (in my experience at least) mean they want to make the tool do something its built-in language does not inherently know how to do. There is in that desire a strong implication of adding features to the language that I believe will ultimately corrupt it to the point of not being accessible to mere mortals. It's what I call the Javazation of Transcript. If you have a need for something in a program that Transcript simply can't do and if the right way to solve that problem is with an external, then it seems to me you should be willing to move outside the boundaries of the language to do that thing, whatever it is. (These multi-dimensional array manipulations, e.g., can apparently not be done satisfactorily in Transcript.) I'm *always* going to come down on the side of keeping the language as simple as possible. In my opinion, it is already too burdened with baggage that is of use to a tiny fraction of its users in order to accommodate a few people with specific programming needs. As it becomes more complex -- even if those complexities are posited as optional alternatives -- it becomes more and more impenetrable to those who do not have a computer science background or formal computer training. Those folks already have enough languages to pick from. I strongly desire for this one to escape the clutches of the Programming Priesthood. On Jun 23, 2005, at 6:35 AM, Rob Cozens wrote: Why would any Transcript scriptor want to write externals in C or Pascal if she could use Transcript syntax instead? ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
Jerry Daniels wrote: I thought Tom Pittman did a very good job of maintaining the purity of HyperTalk when he did CompileIt! Any future efforts could stand on his shoulders in that regard. Just get an interface more like Mark Hanrek's please. :) So much faster, so much simpler -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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: compileIt for revolution?
From: Dan Shafer [EMAIL PROTECTED] [...] Then my second favorite language was Python. The GUI-building tools for Python are pathetic to non-existent. But the language is powerful and elegant and extends naturally. If the PythonCard project I was engaged in before I discovered Revolution had been on a fast track or complete, odds are I'd have never used Rev. Didn't you know about wxDesigner to generate the Python code for GUI? There is also a very new Boa Constructor upgrade... Yes, Python is lacking for an IDE, i.e. Integrated tools for coding and designing GUI! I expect an integrated Python external but as the SDK is so obscure... ___ 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: compileIt for revolution?
On Jun 23, 2005, at 10:09 PM, Dan Shafer wrote: Verbosity is a virtue in my mind. Not only does it make code more readable and therefore maintainable, but I can't tell you how many times I've just sort of guessed at what command or property change might have some desired effect only to have it behave exactly as predicted. Only with xTalk and Python have I had that kind of experience. And I love it! I don't think the two properties you're talking about, clarity and intuit-ability, have anything to do with verbosity. All three are effects related to the english-like nature of Transcript. Anyone who understands English and the concept of variables understands what put 3 into x means. I think the verbosity claim is generally a red herring. Not that you're making that claim, Dan, you just helped me up onto the soap box ;-) The go-to (no pun intended) comparison is put 3 into x vs. x:=3 That comparison is dramatic but misleading. repeat 20 is no more verbose than the equivalent in most other languages. if is still if There are even counter-examples, such as various languages that surround conditional groups with braces or other syntactic sugar. Further, the built-in command set, including things like chunk expressions and url-based filesystem access, lead to there being less overall code in Transcript compared to other options. I have yet to see a systematic comparison of the length of Transcript vs. that of other languages. The clarity of Transcript comes simply from good naming conventions for commands and functions. The intuit-ability is much the same. If good naming happens to lead to slightly longer names, that's not a problem for me. regards, Geoff ___ 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: compileIt for revolution?
On Jun 24, 2005, at 4:26 AM, Jon wrote: With all due respect, Jim, if you are trying to do even simple math on a large array of numbers (like computing a histogram of image data), Rev is simply too slow to use. It has nothing to do with data structures: it has to do with slow pCode trying to run tight loops. As stated previously, I cannot accept this statement/conclusion without seeing the code in question. There are simply too many ways to write slow code to assume that Rev can't do a task based solely on a very general description -- unless the description involves real time first-person gaming ;-) ___ 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: compileIt for revolution?
whatever happened to the old metacard externals example (in the examples in the MCTools menu.)? It had lots of stuff - no explanations but it demoed a lot of good stuff... cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Tweedly Sent: Thursday, June 23, 2005 03:23 To: How to use Revolution Subject: Re: compileIt for revolution? Richard Gaskin wrote: Derek Bump wrote: If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. What aspects have you found confusing? This is only a start - Doesn't say which compilers should work (tells me some that won't - but doesn't say which ones will - and in particular, doesn't say which free ones will :-) (It kind of implies that many of them will, maybe even most of them - but a short list of a few that are expected to work would eliminate that as a possible explanation for troubles run into) - Includes a number of examples which are fragments of C code, without any comments describing the interface being provided, and without showing the corresponding Transcript - Include samples like XSetArray which is a function using the built-in SetArray - but its parameters are never explained, and still something of a mystery. - It doesn't include a tiny, simple example; I'd like to see a very simple example - e.g. return the string hello program - in a separate directory. Not doing OS specific GetComputerName, not calling QT, not just a very, very simple example. With a correspondingly simple Rev stack, and step-by-step instructions (not as detailed as I sent to this list, but some kind of here's the first thing to do instructions). - it intermingles things which are (apart from exceptional cases) fixed with things which are your own, without distinguishing clearly - e.g. There are two header files you'll need to #include, XCmdGlue.h and external.h. ... But there is no external.h file included in the distribution - it means the header file for your code, which will be anything but external.h In fact, the distribution includes article.c and article.h - what should happen is that article.c should #include the article.h - but it doesn't, it #includes external.h - which is non-existent, so you're guaranteed a compile failure at step 1. Not likely to inspire confidence. - it uses examples where the C functions are named with leading underscores - when prepended underscores was described above as (one of ) the reason(s) why the Borland compiler won't work - it includes extra functions that aren't referenced or used (as far as I can tell). e.g. XGetVar and XGetArray are in convolve_and_life.c - but I can't find anywhere they're used. I wonder if a Rev tool set up for writing C, generating the make file, and running GCC would address a lot of this with very little effort -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.8/22 - Release Date: 17/06/2005 ___ 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: compileIt for revolution?
Dan- Wednesday, June 22, 2005, 8:38:36 PM, you wrote: DS I have a hard time seeing where you and I disagree here. I think DS we're saying the same thing differently. Ah... that may be. But I'm pushing *for* a generic external interface, and you're arguing against it. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Dan, et al, programming language that is everything to everyone is nothing to anyone. Not if it does the job. (You'd really like to switch between different programming environments to create bits and pieces of an application?) Isn't C a programming language that is everything to everyone? Is there something one cannot program in C alone? Why would any Transcript scriptor want to write externals in C or Pascal if she could use Transcript syntax instead? I think I've mentioned this before: Dan, I believe you, like moi, have suggested to C programmers new to Transcript that they will find Transcript's verbose syntax to be greatly more productive in terms of lines of code needed to accomplish a given task. So why would you want to use a different, less productive programming language to write externals? Would you feel the same if you had to write externals in Assembler or machine code? Rob Cozens Wisdom entereth not into a malicious mind, and science without conscience is but the ruin of the soul. -- François Rabelais (c. 1494-1553) ___ 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: compileIt for revolution?
Richard, et al: So instead CompileIt! had its own unique syntax and hundreds of symbols one could use to implement things that were algorithmically very much like one would do in Pascal or C. Of course this required a whole other level of knowledge, and for those symbols related to the Mac Toolbox it also required the dozen-volume set of Inside Mac books, and/or the more efficient Think Library (which came with Think C) Are you talking about the same CompileIt! (Rev 2.6.1) I used for years? There was very little difference between HyperTalk and CompileIt! syntax, except for things HyperTalk didn't support: variable typing, record structures, system call glue. My experience is that it is easily an order of magnitude more efficient to write externals in CompileIt! than C or Pascal--and I have professional experience programming in both other languages. If you are programming Mac Toolbox calls, you _will_ have to consult Inside Macintosh regardless of of the language you use. But one doesn't have to consult a dozen volumes unless one is implementing _all_ Toolbox calls. If I want to tap into Mac Program-to-Program Communications, for example, I need one volume: Interprocess Communication. Finally, CompileIt! does not have hundreds of symbols to complete its function...it includes hundreds of symbols that are _already_ defined in Inside Macintosh. If you're programming in another language, you will have to define the same symbols in an include file. I'm really sorry your experience with CompileIt! was such that you didn't get it. Rob Cozens, Staff Conservator Mendonoma Marine Life Conservancy Every so often something strange happens on a stretch of Gulf coast shoreline. Fish, crabs, and shrimp all but throw themselves into the arms, baskets, and hand nets of people wading in the beach surf... In a few hours a single person can collect a hundred pounds of shrimp... Gulf folks call it a ''jubilee.'' The reality, at least for the sea's creatures, is less jubilant. They aren't presenting themselves as gifts to man but trying desperately to escape suffocation. -- Ocean's End ___ 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: compileIt for Revolution?
Try not to get your knickers in a twist. In case you haven't noticed, hypertalk/transcript is clearly a Pascal derived language, they just got rid of begin/end, loosely typed it, and made the operator of affectation verbose. ROTFL/ OMG that's funny. Don't forget scoping, and the overarching paradigm of cards, backgrounds, stacks scripts, properties, and messages and an inheritence path, and the vocabulary, and the fact that nobody could describe what it was, and the fact that it was originally intended to be interpreted not compiled, and therefore DO, and oh hell. You weren't serious so I don't have to add anything here. I mean - really - I was pretty sure xTalk was inspired by COBOL's verbose syntax and...and...choking on my beverage/ . Now that I look at it, I'm having a hard time telling the difference between BASIC and LISP and APL. ROTFL/ Dude, you slay me. Ok, now in case you were serious (and if you were I'm sorry for laughing and making fun of your post) xTalk is now a legacy language type with expectations and conventions and philosophy. I'm reasonably sure that := doesn't fit that philosophy, nor does a=b. If you want compact, you need to go somewhere else. xTalk is intentionally verbose. Philosophically, I like it that way. It means that it is much easier for me to read someone else's code, especially since most of you can't write an intelligent comment in your code to save your lives. I'm going to stop reading this thread now before I REALLY get flamed. -- http://taoofrunrev.blogspot.com http://taoof4d.blogspot.com http://4dwishlist.blogspot.com On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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: compileIt for revolution?
Guess I'll add my two cents. I'm a newbie to Rev (Revolution) but worked over 25 years in Rev (Revelation), another similar, high-typed, extensible, flexible, run as you program, script language. It's an implementation of Pick on the PC. I was considered an expert. I also owned a company and employed programmers. I too, have heard these discussions hundreds of times, over the years. Speed of execution rarely relates to code, or the language, or whether it's compiled, or in pcode or whatever. It always has to do with data, whether the data is in arrays, or a database, or whatever object. Any language can add 2 to 2 instantly, regardless of the syntax. You don't get speed by changing languages, or writing lengthy workarounds, or complaining about your tools. You get speed by designing, in advance, the layout of your data. This requires straight thinking. 1. Know what you are setting out to accomplish before you type one character of code (what are your client's (your) goals?). 2. Layout and optimize the data you are going to access BEFORE writing any code. How are you indexing the data? Is it real indexing or organization? 3. Now write your code. If you find yourself writing spaghetti code, STOP, go back to step 1. Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dan Shafer Sent: Wednesday, June 22, 2005 12:12 PM To: How to use Revolution Subject: Re: compileIt for revolution? This whole discussion has been revealing and intriguing to me. My favorite programming language is Smalltalk. But before it was possible to create UIs for Smalltalk without writing code, I found it cumbersome. When a product called WindowBuilder came along, I felt like we'd achieved the ultimate development environment. In many ways, I still think that. Smalltalk had other problems, unfortunately, that made it great to code in, difficult to impossible to deploy. Then my second favorite language was Python. The GUI-building tools for Python are pathetic to non-existent. But the language is powerful and elegant and extends naturally. If the PythonCard project I was engaged in before I discovered Revolution had been on a fast track or complete, odds are I'd have never used Rev. Now I favor Transcript and RunRev. Building UIs is all but painless and 95% of what I want or need to do in creating apps is simple inside the elegance of Transcript. But Transcript isn't object- oriented. Two aphorisms came to mind as I read this entire thread again today. One is, No good programmer uses only one tool for everything. The other is, It's a poor workman who blames his tools. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for Revolution?
Mikey wrote: Try not to get your knickers in a twist. In case you haven't noticed, hypertalk/transcript is clearly a Pascal derived language, they just got rid of begin/end, loosely typed it, and made the operator of affectation verbose. ROTFL/ OMG that's funny. FWIW, I've read that description almost verbatim from the man who created HyperTalk. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: compileIt for Revolution?
Message: 2 Date: Thu, 23 Jun 2005 10:15:28 -0400 From: Mikey [EMAIL PROTECTED] Subject: Re: compileIt for Revolution? To: How to use Revolution use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Try not to get your knickers in a twist. In case you haven't noticed, hypertalk/transcript is clearly a Pascal derived language, they just got rid of begin/end, loosely typed it, and made the operator of affectation verbose. ROTFL/ OMG that's funny. Don't forget scoping, and the overarching paradigm of cards, backgrounds, stacks scripts, properties, and messages and an inheritence path, and the vocabulary, and the fact that nobody could describe what it was, and the fact that it was originally intended to be interpreted not compiled, and therefore DO, and oh hell. You weren't serious so I don't have to add anything here. I mean - really - I was pretty sure xTalk was inspired by COBOL's verbose syntax and...and...choking on my beverage/ . Now that I look at it, I'm having a hard time telling the difference between BASIC and LISP and APL. ROTFL/ Dude, you slay me. Ok, now in case you were serious (and if you were I'm sorry for laughing and making fun of your post) xTalk is now a legacy language type with expectations and conventions and philosophy. I'm reasonably sure that := doesn't fit that philosophy, nor does a=b. If you want compact, you need to go somewhere else. xTalk is intentionally verbose. Philosophically, I like it that way. It means that it is much easier for me to read someone else's code, especially since most of you can't write an intelligent comment in your code to save your lives. I'm going to stop reading this thread now before I REALLY get flamed. Well, yes, that might be a good idea actually. Intelligent debates are generally dispassionate and reasonable since intelligent people are after the truth as opposed to stroking their ego. You might have heard of the maxim Fortiter in re , suaviter in modo. If not, look it up. In any event: think about it. Substantively, I stand by my story: xTalk is a scripting language which is clearly derived from Pascal. Don't take my word for it though; get a copy of think pascal (it's free) and look at its debugger and hypercards, its script formatter and hypercards. Or, just read wikipedia. HyperTalk scripts are fairly similar to written English, and use a logic structure similar to the Pascal programming language. http://en.wikipedia.org/wiki/HyperTalk HyperTalk is the scripting language of HyperCard and its clones. It is similar in syntax to Pascal, and includes enough object-like data structures and programming aids to make it a quite useful development environment (Allen 103). http://www.iath.virginia.edu/elab/hfl0133.html There's even an entire article on macTech Comparing HyperTalk to Pascal which says, Both Pascal and HyperTalk provide powerful if-then-else control structures with very similar syntax. The specification and calling of user defined functions in Pascal and HyperTalk is almost identical. http://www.mactech.com/articles/mactech/Vol.04/04.09/HyperTalk,Pascal/ Based on the comparisons presented above between Pascal and HyperTalk, it should be clear that HyperTalk is indeed a powerful language with many similarities to Pascal. I could keep looking, but I think I've made my point. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: compileIt for revolution?
CompileIt! lovers and haters... YESTERDAY I would have to agree with Rob, here. I used CompileIt! to the point where I made a small C app that RAN externals only and I would get CompileIt! to compile into that app (called HyperApp). I then wrote a front end (in CompileIt!) to write and manage my code in. I've moved a great deal of my code management features from it into Constellation (www.daniels-mara.com/products). The CompileIt! Xternal performance (if there weren't too many text call backs) was breath-taking. Tom Pittman created a great tool there. The early versions were slow to compile and frustrating, but the the last versions were killer and had a very good debugger. Tom Pittman DID write CompileIt! in 68000 assembler using HyperTalk to do that! He was a purist indeed. I learned a tremendous amount about everyday coding using pointers, handles, bitwise math and bunches of goodies--all in my fav lingua, HyperTalk. As a tool, today it would be tremendously helpful. TODAY Doing CompileIt! today would be challenging in a multiplatform environs, because one of the great parts of CompileIt was its toolbox access. HOWEVER, HyperCard had its own toolbox, too. PERHAPS Rev has such a thing that we could call from externals and shield us from the individual API's for the varous platform. These HyperCard callbacks were binary callbacks with data-typed params, so they were every bit as fast as C or a OS toolbox call. WIth Revolution binary callbacks from XCMDs the task of creating a compiler and debugger might be a bit more manageable and certainly would be a fun project. TOMORROW Enough history and what-if's! BOTTOM LINE: I'm interested. My company (Daniels Mara, creators of Constellation) would be interested in discussing a commercial venture. Not sure I'm all that interested in an open-source, design-by-committee free-for-all, I'd, of course, prefer a real project with direction and technical/financial purpose. There are several large hurdles in the process. Let's keep this discussion going. Best, Jerry On Jun 23, 2005, at 9:00 AM, Rob Cozens wrote: Richard, et al: So instead CompileIt! had its own unique syntax and hundreds of symbols one could use to implement things that were algorithmically very much like one would do in Pascal or C. Of course this required a whole other level of knowledge, and for those symbols related to the Mac Toolbox it also required the dozen-volume set of Inside Mac books, and/or the more efficient Think Library (which came with Think C) Are you talking about the same CompileIt! (Rev 2.6.1) I used for years? There was very little difference between HyperTalk and CompileIt! syntax, except for things HyperTalk didn't support: variable typing, record structures, system call glue. My experience is that it is easily an order of magnitude more efficient to write externals in CompileIt! than C or Pascal--and I have professional experience programming in both other languages. If you are programming Mac Toolbox calls, you _will_ have to consult Inside Macintosh regardless of of the language you use. But one doesn't have to consult a dozen volumes unless one is implementing _all_ Toolbox calls. If I want to tap into Mac Program-to-Program Communications, for example, I need one volume: Interprocess Communication. Finally, CompileIt! does not have hundreds of symbols to complete its function...it includes hundreds of symbols that are _already_ defined in Inside Macintosh. If you're programming in another language, you will have to define the same symbols in an include file. I'm really sorry your experience with CompileIt! was such that you didn't get it. Rob Cozens, Staff Conservator Mendonoma Marine Life Conservancy Every so often something strange happens on a stretch of Gulf coast shoreline. Fish, crabs, and shrimp all but throw themselves into the arms, baskets, and hand nets of people wading in the beach surf... In a few hours a single person can collect a hundred pounds of shrimp... Gulf folks call it a ''jubilee.'' The reality, at least for the sea's creatures, is less jubilant. They aren't presenting themselves as gifts to man but trying desperately to escape suffocation. -- Ocean's End ___ 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: compileIt for Revolution?
Eric- Thursday, June 23, 2005, 11:20:16 AM, you wrote: EE There's even an entire article on macTech Comparing HyperTalk to Pascal which EE says, EE Both Pascal and HyperTalk provide powerful if-then-else control structures EE with very similar syntax. EE The specification and calling of user defined functions in Pascal and EE HyperTalk is almost identical. EE http://www.mactech.com/articles/mactech/Vol.04/04.09/HyperTalk,Pascal/ EE Based on the comparisons presented above between Pascal and HyperTalk, it EE should be clear that HyperTalk is indeed a powerful language with many EE similarities to Pascal. EE I could keep looking, but I think I've made my point. Er... hardly. Conditionals are what makes something a programming language. This is what separates, for example, basic from html. Simply saying that a language has an if-then-else contstruct doesn't make it Pascal. Also, at the time the MacTech article was written Pascal was *the* way to program the Macintosh. Those of us programming in Lightspeed C had to shoehorn our routines in to match the Pascal routines in the toolbox. The articles of that vintage were aimed at the all right... you know how to program the Mac in Pascal, here's where HyperTalk differs from it and how it's similar audience, so the comparisons are de rigeur. *Especially* since the article is titled Comparing HyperTalk to Pascal. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Jerry, Assuming there is sufficient interest what is the first step, and what would THAT cost? I'm thinking that the initial ScriptCompiler (or some better name) would just turn Transcript into machine code. This would be of interest to me (hopefully others) who want to put guarded code in places other than the standalone (for example a proprietary calculation in an order processing stack - where all the other code is accessible). The next step might be array processing or tool box calls or These could be built later and sold separately; for example ScriptCompiler I, ScriptCompiler II, etc. Paul Looney ___ 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: compileIt for revolution?
Maybe that's what I ended up doing but it was accidental! Maybe I fell asleep at some point. My argument is NOT against the ability to build externals to do whatever one wishes to do, including platform-specific things if you want to make your life more complicated and miserable or if you only have to deliver a product to users of a single platform. My argument is against Rev modifying the engine/tool to accommodate platform- specific features in a way that causes the code of those of us who don't want to use such features to break when it runs on other platforms or to jump through a bunch of conditional hoops all the time to get code to run on other platforms to accommodate single- platform features. On Jun 22, 2005, at 11:39 PM, Mark Wieder wrote: Ah... that may be. But I'm pushing *for* a generic external interface, and you're arguing against it. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
If you can write externals in Transcript syntax and NOT over-extend the language to accommodate this demand, I don't have an issue. But that is not generally the case. When people talk about writing externals they generally (in my experience at least) mean they want to make the tool do something its built-in language does not inherently know how to do. There is in that desire a strong implication of adding features to the language that I believe will ultimately corrupt it to the point of not being accessible to mere mortals. It's what I call the Javazation of Transcript. If you have a need for something in a program that Transcript simply can't do and if the right way to solve that problem is with an external, then it seems to me you should be willing to move outside the boundaries of the language to do that thing, whatever it is. (These multi-dimensional array manipulations, e.g., can apparently not be done satisfactorily in Transcript.) I'm *always* going to come down on the side of keeping the language as simple as possible. In my opinion, it is already too burdened with baggage that is of use to a tiny fraction of its users in order to accommodate a few people with specific programming needs. As it becomes more complex -- even if those complexities are posited as optional alternatives -- it becomes more and more impenetrable to those who do not have a computer science background or formal computer training. Those folks already have enough languages to pick from. I strongly desire for this one to escape the clutches of the Programming Priesthood. On Jun 23, 2005, at 6:35 AM, Rob Cozens wrote: Why would any Transcript scriptor want to write externals in C or Pascal if she could use Transcript syntax instead? ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
Dan, Rev is chock full of stuff that I will never use. Perhaps half or more of the commands are irrelevant to my needs. However, I see on this list folks that love those irrelevant things in their applications. You have your ideas about the kind of applications you want to use Rev for. Do you consider everyone else's applications to be irrelevant that do not fit into your concept of what Rev should be used for --dooming them to use tools too arcane to ever accomplish their tasks in a reasonable lifetime? You are not the only one who is too old to spend the rest of his life programming in C ;-) I choose Rev as my language of choice, because I could see accomplishing my ambitious goals in what is left of my expected lifetime. I do not write professionally to sell products to others. I write to solve problems that I want to solve for myself and my friends. I am a renaissance man with many interests and skills. Therefore, my problems are varied and the solutions must be timely for me to have time enjoy them all. Array improvements are a subject near to my heart. Arrays could have been implemented in a way that would make them one or two orders of magnitude faster for the types of applications that need speed. Or, they could have been implemented in a way that would make them more general for other applications. Or, they could do both. In Rev today we sort of have a half attempt at both. You don't have to butcher a language to make it satisfy a large number of needs. A lot of the proposed Butchery that you see on these threads are just a symptom of the needs. The solutions should not to be left unexplored just because the ones with needs are not language architects and make unpalatable suggestions. Rather it should be seen as a call and challenge to the language architects to put their heads together and propose solutions for the needs. Many times the needs can be met by a greater understanding of the more obscure capabilities already in the language. This list is wonderful for getting this kind of help. Many of these obscure capabilities are in fact extensions to the language to provide a low level engine primitive to get around speed issues with doing things in the straight forward algorithmic way. Building special purpose operators to speed up specific applications is how the problems are ultimately solved for everyone. I am all for this, even if I don't need those things for my stuff, because someone else will use those things to make something wonderful that I or others will appreciate and use. I just want the stuff to be useful for at least 5-10% of the folks, and that a good effort is made to make it consistent for the language. I should point out that I agree with 90% of what you say. I just see that you have formed some opinions from you long experience, just as I have from mine. I was involved in the personal computer industry since the first (8008) microprocessor was created. No two persons experience is the same, and therein is the beauty. As a former boss of mine use to say, If you agree with me all the time, one of us is not needed! I too am somewhat disturbed at many commands in the language that seem to specific to a platform or even a database. It is tough to draw the line between the Language and just a package of handlers for your scripting convenience. However, I think a line should be drawn. Core language definitions should be well thought out and not changed. Convenience handlers should be understood as such, bountiful, and improvements permitted. I'm getting too old for these soap boxes --the altitude is getting to me ;-) Dennis On Jun 23, 2005, at 8:26 PM, Dan Shafer wrote: I'm *always* going to come down on the side of keeping the language as simple as possible. In my opinion, it is already too burdened with baggage that is of use to a tiny fraction of its users in order to accommodate a few people with specific programming needs. As it becomes more complex -- even if those complexities are posited as optional alternatives -- it becomes more and more impenetrable to those who do not have a computer science background or formal computer training. Those folks already have enough languages to pick from. I strongly desire for this one to escape the clutches of the Programming Priesthood. ___ 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: compileIt for revolution?
Dan, That's what I got from the first post, exactly. I tend to agree with your statement and your logic is sound. (not that you need me to say so) I just wanted to agree to this and don't want to see Rev changed in another direction. Thanks Tom On Jun 23, 2005, at 8:20 PM, Dan Shafer wrote: My argument is NOT against the ability to build externals to do whatever one wishes to do, including platform-specific things if you want to make your life more complicated and miserable or if you only have to deliver a product to users of a single platform. My argument is against Rev modifying the engine/tool to accommodate platform-specific features in a way that causes the code of those of us who don't want to use such features to break when it runs on other platforms or to jump through a bunch of conditional hoops all the time to get code to run on other platforms to accommodate single-platform features. Thomas J McGrath III [EMAIL PROTECTED] 412-831-3094 220 Drake Road Bethel Park, PA 15102 *)) = Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways - a Cigar in one hand - a large steak in the other - your body thoroughly used up, totally worn out, and screaming - WOO HOO! What a Ride! ___ 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: compileIt for revolution?
Rob Cozens wrote: I'm really sorry your experience with CompileIt! was such that you didn't get it. I believe got it: I wrote a few dozen externals with it, bundled 'em up into a commercial product, and they paid my rent for a year. While I enjoyed it (or more specifically, Mark Hanrek's souped-up version of it), not everyone did. Even at the peak of CompileIt's popularity Rinaldi, Calhoun, and many other prolific externals authors preferred to work in other languages. My point about Compile! is not that it's not a good time, but merely that it's not a panacea. To use it efficiently required lower-level ways of doing things, and after the user has come to understand pointers, handles, data types, and the OS APIs the difference between learning CompileItSpeak and C is indeed there but the gulf isn't very wide. There may be a market for such a compiler and if so I might use it myself. But given what it takes to build such a critter for Rev and what would be required to use it, don't be surprised if it takes a long time to reach a positive ROI. In the meantime there are obvious deficiencies in the current externals package, and I hope they've been brought to RunRev's attention and that they are addressing them. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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: compileIt for revolution?
Dennis. You make some excellent points. I don't think that *my* programming needs should drive the direction of the language or the tool. And I'm certainly not opposed even to *major* extensions and enhancements of the language. My only real sticking point is that if and when new things are added, they be done in a way that is as cross-platform as possible, as innocuous to coders for other platforms as feasible, and implemented in a way that keeps the consistent flavor and style of xTalk, including its verbosity. Verbosity is a virtue in my mind. Not only does it make code more readable and therefore maintainable, but I can't tell you how many times I've just sort of guessed at what command or property change might have some desired effect only to have it behave exactly as predicted. Only with xTalk and Python have I had that kind of experience. And I love it! ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
Dan- No argument from me on that. Maybe I was the one who fell asleep, but I didn't think anyone was arguing for features that would break the cross-platform functionality in that way. If so, that's one of those threads I'm not even going to bother getting involved in. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
MisterX wrote: [ about the need for more speed for some things ] Example: The HotKeyN2O stack stores all properties of all controls in a card when the user opens the card. The props are all in array form which cannot be stored into another array (time based array of object changes). So for each object i have to translate array[key]=data to keydata/key. This in turn is stored into a time-based array. So if i need to restore the property (any) for any object and at any time, it's ultra easy - except that the translation process is so slow after 10 controls trasnlated that it's USELESS if i dont write that into a real-compiled external. I agree with you about the need for more speed for some applications (and sorry Dan, but I've seen requests for more speed a number of times on this list ... sometimes they can be overcome by creative use of Transcript's features in unusual ways, but I'm not convinced that's always possible, nor that it should be necessary to use non-obvious programming tricks, at the cost of loss of readability and maintainability, when some improvements in native performance would do it better) But in this example, there may be a better way to organize your (Mr. X's) data that would be fast enough. 2 possibilities I see 1. data[key] contains time of change, the new value time of change, the new value etc. then you can directly index the individual property, then find the appropriate line entry (which you'd keep sorted). If you needed to, you could then binary search through the lines for the most recent change before the time desired.. 2. the data is in a time-based array, but as a 'combine'd array-as-list. So you'd simply find the array entry based on timeput data[theTime] into myProps split myProps by cr and comma so the value of a property would be myProp[theProp] Not sure which of those would be better - depends on the full set of operations you need to do. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.8/22 - Release Date: 17/06/2005 ___ 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: compileIt for revolution?
Dan, I also would like to speed up array processing. It kills me that my friend won't move from VB to Rev because when I write the same array processing problem that he uses, VB runs 10+ times faster than Rev. I also have had to jump through hoops trying to figure out ways to make my array processing go faster --it usually requires taking a simple script and making it 5 times as complicated as the way you would do it in VB or RB or any other ordinary language. It is not just for the type of math problems that I am dealing with. As visual effects become more important, being able to quickly process numeric arrays like a pixel image array becomes important. However, I don't think compiling scripts is the answer. I love having the interpreted environment for interactive debug and experimentation. The UI is where all the code and debugging time is spent. I don't want to trade that in for anything. Rev is all about UI, but weak on array speed. The language as it is defined would hardly be faster as a compiled version because of the type-less and stringy nature of the variables. Compiled languages get their effeciency by the programmer telling them up front the data type and therefore the correspondence to specific machine code operators. There is no guessing or mixing of types. The processing of numeric (or fixed length strings) hardly needs any checks at runtime. What I advocate is a cross platform runtime package that is a pure fixed type, fixed operator, math orientated array language. It can be PCode or threaded with very low overhead. Languages with no UI considerations are very easy to create and code for a machine code programmer. I would like to see the basic operators and control structures to work on regular arrays of n dimensions. I am not actually referring to array operators, just the ability to apply ordinary operators to one addressable array element at a time with efficient looping structures. That should result in an order of magnitude increase in speed for the stuff that bogs Rev down, and open up Rev as a universal development tool. The key is to have an efficient and elegant way for Rev to interface with such a package. It needs to be able to pass the program code and pass array elements, rows, columns, and whole arrays to the coprocessor (really it just needs to be able to pass pointers to the array memory blocks). As long as Rev has this Achilles heel, it will preclude it's use as a real programming language in the minds of many. I did make a BZ enhancement request, but I think it could benefit from a discussion on this list. Dennis On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote: Xavier I guess we'll just have to agree to disagree about this. How in the world would you expect a compiled script or handler -- if such a thing were possible -- to then be smoothly integrated into a stand-alone app? We needed CompileIt! in HyperCard *far* less for performance than for code protection and the ability to deliver stuff that didn't require the player to be around. Neither of those is an issue today in Revolution. As for performance, tuning for such situations has produced staggering results. I was blown away in Monterey last weekend to watch a dynamically populated menu that was pulling its contents from 100 text files appear in under a second. I've never heard much here in the way of complaints about slow programs written in Rev. Dan On Jun 21, 2005, at 9:31 PM, MisterX wrote: Dan, Creating apps with rev has NOTHING to do with compileIt. I really would like to speed up some scripts to manipulate arrays (where rev has some serious limitations) and the best possible way to do that would be to have something like CompileIt. ___ 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: compileIt for revolution?
I would absolutely echo what Dennis has just said. I was initially really impressed with rev and I should say I still am in certain respects - comfort and ease of use, the elegant and intuitive language and stack/card paradigm etc. etc. But I have been unable to get rev to do what I want it to do behind the scenes (i.e. my application logic) without jumping through the kinds of hoops that Dennis describes - effectively negating all the advantages of programming in Transcript that I just outlined. And even when I could get the code working, man it was SLOW. It was discouraging to see Python easily outrun rev for the equivalent code - I mean I love Python and all, but it's hardly the gold standard for speed. I would think that the stack paradigm would neatly allow for the creation of strongly-typed stacks that could be jumped into from the kind of warm and fuzzy typeless stacks that give rev its wonderful flexibility. The compiler could then insist on declarations for all objects within the typed stack and compile it with far greater optimization than is possible for the typeless stacks, perhaps even going as far as native code compilation :-D Imagine what a superb development environment rev could be with these features. Flexible and typeless for all the UI/scripty/fun parts of the app; more draconian but hellishly fast for the down-to-the-metal hardcore byte-crunching parts of the app. Strong typing would probably also make it a lot easier to automate the process of calling externals from Transcript without all those ghastly, clunky C wrappers and crap. There's a dream - a rev scientific application with a beautiful interface rendering OpenGL objects in real time and a typed, Transcript-coded stack running energy minimization on a separate thread in the background. I doubt I'll put my hands in my pockets again and upgrade my expired rev license just to have deep masks on my GUIs - I'm not knocking it, it's just not a feature I urgently need right now ... but fast compiled stacks, easy access to externals ... now you're talking ... where's my check book? Best Gordon --- Dennis Brown [EMAIL PROTECTED] wrote: Dan, I also would like to speed up array processing. It kills me that my friend won't move from VB to Rev because when I write the same array processing problem that he uses, VB runs 10+ times faster than Rev. I also have had to jump through hoops trying to figure out ways to make my array processing go faster --it usually requires taking a simple script and making it 5 times as complicated as the way you would do it in VB or RB or any other ordinary language. It is not just for the type of math problems that I am dealing with. As visual effects become more important, being able to quickly process numeric arrays like a pixel image array becomes important. However, I don't think compiling scripts is the answer. I love having the interpreted environment for interactive debug and experimentation. The UI is where all the code and debugging time is spent. I don't want to trade that in for anything. Rev is all about UI, but weak on array speed. The language as it is defined would hardly be faster as a compiled version because of the type-less and stringy nature of the variables. Compiled languages get their effeciency by the programmer telling them up front the data type and therefore the correspondence to specific machine code operators. There is no guessing or mixing of types. The processing of numeric (or fixed length strings) hardly needs any checks at runtime. What I advocate is a cross platform runtime package that is a pure fixed type, fixed operator, math orientated array language. It can be PCode or threaded with very low overhead. Languages with no UI considerations are very easy to create and code for a machine code programmer. I would like to see the basic operators and control structures to work on regular arrays of n dimensions. I am not actually referring to array operators, just the ability to apply ordinary operators to one addressable array element at a time with efficient looping structures. That should result in an order of magnitude increase in speed for the stuff that bogs Rev down, and open up Rev as a universal development tool. The key is to have an efficient and elegant way for Rev to interface with such a package. It needs to be able to pass the program code and pass array elements, rows, columns, and whole arrays to the coprocessor (really it just needs to be able to pass pointers to the array memory blocks). As long as Rev has this Achilles heel, it will preclude it's use as a real programming language in the minds of many. I did make a BZ enhancement request, but I think it could benefit from a discussion on this list. Dennis On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote:
Re: compileIt for revolution?
I have spoke with a few individuals in regards to creating a utility for Revolution that would convert Transcript to C. Unfortunately, I know little of C and the individuals I talked with were not ready to start a project such as what you want. But...it is possible. If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. It's pretty bad when I've used about 10 different compilers (including MS Visual C) and I still can't get the samples to compile properly. But that's a whole different issue. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Thanks Alex, I think i did start out the way you mentioned and then got into the objectness of the associative array. That may be my problem... Thanks for the heads up! Xavier -Original Message- From: Alex Tweedly [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 12:21 To: [EMAIL PROTECTED]; How to use Revolution Subject: Re: compileIt for revolution? MisterX wrote: [ about the need for more speed for some things ] Example: The HotKeyN2O stack stores all properties of all controls in a card when the user opens the card. The props are all in array form which cannot be stored into another array (time based array of object changes). So for each object i have to translate array[key]=data to keydata/key. This in turn is stored into a time-based array. So if i need to restore the property (any) for any object and at any time, it's ultra easy - except that the translation process is so slow after 10 controls trasnlated that it's USELESS if i dont write that into a real-compiled external. I agree with you about the need for more speed for some applications (and sorry Dan, but I've seen requests for more speed a number of times on this list ... sometimes they can be overcome by creative use of Transcript's features in unusual ways, but I'm not convinced that's always possible, nor that it should be necessary to use non-obvious programming tricks, at the cost of loss of readability and maintainability, when some improvements in native performance would do it better) But in this example, there may be a better way to organize your (Mr. X's) data that would be fast enough. 2 possibilities I see 1. data[key] contains time of change, the new value time of change, the new value etc. then you can directly index the individual property, then find the appropriate line entry (which you'd keep sorted). If you needed to, you could then binary search through the lines for the most recent change before the time desired.. 2. the data is in a time-based array, but as a 'combine'd array-as-list. So you'd simply find the array entry based on timeput data[theTime] into myProps split myProps by cr and comma so the value of a property would be myProp[theProp] Not sure which of those would be better - depends on the full set of operations you need to do. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.8/22 - Release Date: 17/06/2005 ___ 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: compileIt for revolution?
I have a feeling that there is compiled and then there is compiled. It is my impression (correct me if I'm wrong) that Rev compiles to pCodes (similar to the old pSystem and to Visual Basic), while Delphi and C++ compile to native code. The difference in performance is between one and three orders of magnitude, depending on what you're doing. It is true that Rev is fast enough to do some amazing things (the Nine Ball with Spin stack is a good example of excellent real-time graphic performance), but it is a real dog at compute intensive tasks (processing each pixel in an image). Jon Pat Trendler wrote: Do you have Revolution Dreamcard? You need Revolution Studio, or better, and you can then make a standalone compiled app. Pat [EMAIL PROTECTED] - Original Message - From: Eric Engle [EMAIL PROTECTED] To: use-revolution@lists.runrev.com Sent: Wednesday, June 22, 2005 11:48 AM Subject: compileIt for revolution? Is there any chance that Heizer/Royalsoft (or anyone else for that matter) will make a script compiler for revolution like compileIt? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 ___ 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: compileIt for revolution?
I believe part of the problem is that Revolution doesn't have numerically index arrays. The arrays are associative arrays whose indexes can be any value (including text) so element access is a lookup, rather than an address computation. At 10:07 AM 6/22/2005, you wrote: I have a feeling that there is compiled and then there is compiled. It is my impression (correct me if I'm wrong) that Rev compiles to pCodes (similar to the old pSystem and to Visual Basic), while Delphi and C++ compile to native code. The difference in performance is between one and three orders of magnitude, depending on what you're doing. It is true that Rev is fast enough to do some amazing things (the Nine Ball with Spin stack is a good example of excellent real-time graphic performance), but it is a real dog at compute intensive tasks (processing each pixel in an image). Jon Pat Trendler wrote: Do you have Revolution Dreamcard? You need Revolution Studio, or better, and you can then make a standalone compiled app. Pat [EMAIL PROTECTED] - Original Message - From: Eric Engle [EMAIL PROTECTED] To: use-revolution@lists.runrev.com Sent: Wednesday, June 22, 2005 11:48 AM Subject: compileIt for revolution? Is there any chance that Heizer/Royalsoft (or anyone else for that matter) will make a script compiler for revolution like compileIt? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 ___ 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 Peter T. Evensen http://www.PetersRoadToHealth.com 24-hour recorded info hotline: 1-800-624-7671 ___ 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: compileIt for revolution?
then maybe the key is to have better array handlers like filter does for lines for example... is that what you mean? Note that creating an external is just a function call in any script so the script impact is minimal - actually, it does make scritps simpler... And to rebute another of Dan's points whence we HyperCarders used externals to hide code, this can still apply to rev! You can keep an easy GUI that modifiable by the user but keep the real code away. Here's one idea to give Dan an idea of the speed difference: Sorry for the vetusty of the story: I wrote a codec in HyperTalk that took 24 hours processing in HC on a Powerbook 140. Sorry, i wont test it today in rev and what it did is also irrelevant - too involved. Rewritten in C (6 months time longuer than HCs' script), the code took 16 ticks on the same powerbook. 2 years ago i tried translating some Neural network C code. Same problem: 5 hours to run the runRev example as optimized as i could. In C it would take a big 2 seconds! The whole compileIT is not required but an internal module to create ultra-fast native code would be great. Now that would be a programmer's tool worth any eye candy in RunRev. Dan, at work, i hardly ever treat lists that have less than 3X20X2000 objects imbricated in them. I need to run results on those a lot. Believe me that those 15 seconds required sometimes can even be stressing sometimes (usually friday late afternoons ;) cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Brown Sent: Wednesday, June 22, 2005 15:40 To: How to use Revolution Subject: Re: compileIt for revolution? Dan, I also would like to speed up array processing. It kills me that my friend won't move from VB to Rev because when I write the same array processing problem that he uses, VB runs 10+ times faster than Rev. I also have had to jump through hoops trying to figure out ways to make my array processing go faster --it usually requires taking a simple script and making it 5 times as complicated as the way you would do it in VB or RB or any other ordinary language. It is not just for the type of math problems that I am dealing with. As visual effects become more important, being able to quickly process numeric arrays like a pixel image array becomes important. However, I don't think compiling scripts is the answer. I love having the interpreted environment for interactive debug and experimentation. The UI is where all the code and debugging time is spent. I don't want to trade that in for anything. Rev is all about UI, but weak on array speed. The language as it is defined would hardly be faster as a compiled version because of the type-less and stringy nature of the variables. Compiled languages get their effeciency by the programmer telling them up front the data type and therefore the correspondence to specific machine code operators. There is no guessing or mixing of types. The processing of numeric (or fixed length strings) hardly needs any checks at runtime. What I advocate is a cross platform runtime package that is a pure fixed type, fixed operator, math orientated array language. It can be PCode or threaded with very low overhead. Languages with no UI considerations are very easy to create and code for a machine code programmer. I would like to see the basic operators and control structures to work on regular arrays of n dimensions. I am not actually referring to array operators, just the ability to apply ordinary operators to one addressable array element at a time with efficient looping structures. That should result in an order of magnitude increase in speed for the stuff that bogs Rev down, and open up Rev as a universal development tool. The key is to have an efficient and elegant way for Rev to interface with such a package. It needs to be able to pass the program code and pass array elements, rows, columns, and whole arrays to the coprocessor (really it just needs to be able to pass pointers to the array memory blocks). As long as Rev has this Achilles heel, it will preclude it's use as a real programming language in the minds of many. I did make a BZ enhancement request, but I think it could benefit from a discussion on this list. Dennis On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote: Xavier I guess we'll just have to agree to disagree about this. How in the world would you expect a compiled script or handler -- if such a thing were possible -- to then be smoothly integrated into a stand-alone app? We needed CompileIt! in HyperCard *far* less for performance than for code protection and the ability to deliver stuff that didn't require the player to be around. Neither of those is an issue today in Revolution. As for performance, tuning for such situations has produced
Re: compileIt for revolution?
Dan Shafer wrote: How in the world would you expect a compiled script or handler -- if such a thing were possible -- to then be smoothly integrated into a stand-alone app? Seems trivial to me: that's what traditional object code libraries and DLLs are for. As for performance, tuning for such situations has produced staggering results. I was blown away in Monterey last weekend to watch a dynamically populated menu that was pulling its contents from 100 text files appear in under a second. I've never heard much here in the way of complaints about slow programs written in Rev. I guess I should send some image processing code to Dan for optimization! :) Jon ___ 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: compileIt for revolution?
Derek, Not to mean that i have all the answers (but i've tried to answer all the questions in this respect before). I know C pretty well but i hate it any time you have to debug anything like pointer increments or loookup tables. Note that C compilers (not hte free ones) usually have great debugging tools (no comparison to rev). The translation to C is EASY! To C++, like Java or Javascript is a nightmare however... Add pointers and you got HELL! It's kind of the same problem with dot notation of object-oriented variables object.property-value or all it's variations If you managed it, it could work but would it be optimized? Most compilers use repeated passes to compile to assembler and then again to machine language (if that's still current for some compilers) but for a program to create a more efficient code than a coder, you can forget it. a program in C is NOT like a program in Rev and vice versa - except for a few data crunching routimes. I thought (still haven't stopped) of doing this in Python. It's doable. But i have a vendeta with VBS and Active directory at work to get rid of first. Then i can translate it easier to Python. With the right wrappers we should then have any compiler (python, c, fortran, etc.). But first write the translator translator - eh, language codec ;) What's next, language drivers ? . got those already! These are xtalk-c or c-xtalk compatibility handlers - makes scripts darn easier to translate in the first place - In the xtalk to C example, you just need to #include axtalk.c library in your code. But this is still vapor as i hate the c debugging. cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Bump Sent: Wednesday, June 22, 2005 16:19 To: How to use Revolution Subject: Re: compileIt for revolution? I have spoke with a few individuals in regards to creating a utility for Revolution that would convert Transcript to C. Unfortunately, I know little of C and the individuals I talked with were not ready to start a project such as what you want. But...it is possible. If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. It's pretty bad when I've used about 10 different compilers (including MS Visual C) and I still can't get the samples to compile properly. But that's a whole different issue. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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: compileIt for revolution?
Total agreement... Gordon Webster wrote: I would absolutely echo what Dennis has just said. I was initially really impressed with rev and I should say I still am in certain respects - comfort and ease of use, the elegant and intuitive language and stack/card paradigm etc. etc. But I have been unable to get rev to do what I want it to do behind the scenes (i.e. my application logic) without jumping through the kinds of hoops that Dennis describes - effectively negating all the advantages of programming in Transcript that I just outlined. And even when I could get the code working, man it was SLOW. It was discouraging to see Python easily outrun rev for the equivalent code - I mean I love Python and all, but it's hardly the gold standard for speed. ___ 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: compileIt for revolution?
Well, from what I see here is a business opportunity. If everyone that is interested in achieving this (and willing to pay). Then I would suggest a group should be formed andcreate a well defined set a specifications. I am sure that Chipp at Altuit or someone else would be able to produce the much desired solution but for a price. This would be the quickest way of getting exactly what is being asked for in the shortest period of time. I would be glad to coordinate (off the list ) creating the product specifications and then putting it out to bid. ...any takers? Please contact me off the list. regards, Glen On 6/22/05, MisterX [EMAIL PROTECTED] wrote: Derek, Not to mean that i have all the answers (but i've tried to answer all the questions in this respect before). I know C pretty well but i hate it any time you have to debug anything like pointer increments or loookup tables. Note that C compilers (not hte free ones) usually have great debugging tools (no comparison to rev). The translation to C is EASY! To C++, like Java or Javascript is a nightmare however... Add pointers and you got HELL! It's kind of the same problem with dot notation of object-oriented variables object.property-value or all it's variations If you managed it, it could work but would it be optimized? Most compilers use repeated passes to compile to assembler and then again to machine language (if that's still current for some compilers) but for a program to create a more efficient code than a coder, you can forget it. a program in C is NOT like a program in Rev and vice versa - except for a few data crunching routimes. I thought (still haven't stopped) of doing this in Python. It's doable. But i have a vendeta with VBS and Active directory at work to get rid of first. Then i can translate it easier to Python. With the right wrappers we should then have any compiler (python, c, fortran, etc.). But first write the translator translator - eh, language codec ;) What's next, language drivers ? . got those already! These are xtalk-c or c-xtalk compatibility handlers - makes scripts darn easier to translate in the first place - In the xtalk to C example, you just need to #include axtalk.c library in your code. But this is still vapor as i hate the c debugging. cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Bump Sent: Wednesday, June 22, 2005 16:19 To: How to use Revolution Subject: Re: compileIt for revolution? I have spoke with a few individuals in regards to creating a utility for Revolution that would convert Transcript to C. Unfortunately, I know little of C and the individuals I talked with were not ready to start a project such as what you want. But...it is possible. If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. It's pretty bad when I've used about 10 different compilers (including MS Visual C) and I still can't get the samples to compile properly. But that's a whole different issue. Derek Bump Dreamscape Software ___ Compress Photos for the Web with JPEGCompress http://www.dreamscapesoftware.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 ___ 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: compileIt for revolution?
Mr. X, et al: The whole compileIT is not required but an internal module to create ultra-fast native code would be great. Now that would be a programmer's tool worth any eye candy in RunRev. Add access to system calls, and you have my support. Rob Cozens Wisdom entereth not into a malicious mind, and science without conscience is but the ruin of the soul. -- François Rabelais (c. 1494-1553) ___ 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: compileIt for revolution?
Not forgetting, Brian, just discounting. :-D I avoided that stuff like the plague. Guess I'm a bit of an xtalk purist (or some would say bigot). Transcript isn't going to be THE solution/language for all problems. Every time we try to glue something onto it to solve a problem it wasn't intended to solve, we risk making the stuff it does do easily and well harder. Transcript/Rev aren't a general-purpose environment. There's a whole class of apps for which they are ideally suited. There are also many for which it's not the right tool. I'm in favor of continuing to make it do what it does do better and better. I suspect you are, too, so I'm not being contrary here, just clarifying. On Jun 21, 2005, at 10:31 PM, Brian Yennie wrote: Dan, You're forgetting a huge feature of CompileIt! (in fact, the only one I used it for, I never found much use in trying to just speed up scripts with it)... direct toolbox access. While Rev eliminates a lot of the need, it would certainly be nice to be able to write externals in xTalk- and toolbox access is something a lot of people here want. With that said, I don't think it's happening, and if anything it would come in the form of toolbox access from the engine. - Brian Xavier I guess we'll just have to agree to disagree about this. How in the world would you expect a compiled script or handler -- if such a thing were possible -- to then be smoothly integrated into a stand-alone app? We needed CompileIt! in HyperCard *far* less for performance than for code protection and the ability to deliver stuff that didn't require the player to be around. Neither of those is an issue today in Revolution. As for performance, tuning for such situations has produced staggering results. I was blown away in Monterey last weekend to watch a dynamically populated menu that was pulling its contents from 100 text files appear in under a second. I've never heard much here in the way of complaints about slow programs written in Rev. Dan On Jun 21, 2005, at 9:31 PM, MisterX wrote: Dan, Creating apps with rev has NOTHING to do with compileIt. I really would like to speed up some scripts to manipulate arrays (where rev has some serious limitations) and the best possible way to do that would be to have something like CompileIt. I cannot create DLL to create externals in Rev can i? ;) There's an apparent fan group of CompileIT who would pay dearly to get this functionality back. And I'd rather shell out credits to rev than to Moft or MW for a dll compiler for externals. Meanwhile, in the jungle, any rev app without this and manipulating many lists or very long is definitely a dog compared to any real-compiled application. Rev will never compete in that segment compared to a real compiled app. Although this is apparent, it is not when all of your application runs smooth and fast, until the user enters his real data. Example: The HotKeyN2O stack stores all properties of all controls in a card when the user opens the card. The props are all in array form which cannot be stored into another array (time based array of object changes). So for each object i have to translate array[key]=data to keydata/key. This in turn is stored into a time-based array. So if i need to restore the property (any) for any object and at any time, it's ultra easy - except that the translation process is so slow after 10 controls trasnlated that it's USELESS if i dont write that into a real-compiled external. So CompileIt is needed - and very much so i would say - we all have these uses for it where Rev just doesn't can't perform fast enough. cheers Xavier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Shafer Sent: Wednesday, June 22, 2005 06:10 To: How to use Revolution Subject: Re: compileIt for revolution? I think perhaps you haven't yet understood Revolution very well. That's cool; it takes a while. With Rev, we don't need CompileIt! because Rev produces stand-alone, compiled applications for multiple platforms as part of its way of doing business. On Jun 21, 2005, at 6:48 PM, Eric Engle wrote: Is there any chance that Heizer/Royalsoft (or anyone else for that matter) will make a script compiler for revolution like compileIt? ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From RunRev Store ___ 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
RE: compileIt for revolution?
Gordon, Beware that even i surprise myself with newby tricks. I just posted a slow fractal moire maker. It creates beautiful patterns and the detail is amazing but it does so creating some 4 graphics in a card. For the truely beautiful patterns, it took 30 graphics! The making can still be optimized but deleting images cannot be done like words in a field! Delete graphic 1 to -1 or delete all graphics doesn't work. i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 30 graphics deleted in 2 seconds. Hope this brings insight... Rev does wonders you wouldn't believe - and C optimization is not always the trick - the objects are not the same when it comes to the GUI. But when it comes to doing many of many things in a script that's where it starts showing... Like i said, there's always another way to do it! cheers Xav -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Webster Sent: Wednesday, June 22, 2005 16:14 To: How to use Revolution Subject: Re: compileIt for revolution? I would absolutely echo what Dennis has just said. I was initially really impressed with rev and I should say I still am in certain respects - comfort and ease of use, the elegant and intuitive language and stack/card paradigm etc. etc. But I have been unable to get rev to do what I want it to do behind the scenes (i.e. my application logic) without jumping through the kinds of hoops that Dennis describes - effectively negating all the advantages of programming in Transcript that I just outlined. And even when I could get the code working, man it was SLOW. It was discouraging to see Python easily outrun rev for the equivalent code - I mean I love Python and all, but it's hardly the gold standard for speed. I would think that the stack paradigm would neatly allow for the creation of strongly-typed stacks that could be jumped into from the kind of warm and fuzzy typeless stacks that give rev its wonderful flexibility. The compiler could then insist on declarations for all objects within the typed stack and compile it with far greater optimization than is possible for the typeless stacks, perhaps even going as far as native code compilation :-D Imagine what a superb development environment rev could be with these features. Flexible and typeless for all the UI/scripty/fun parts of the app; more draconian but hellishly fast for the down-to-the-metal hardcore byte-crunching parts of the app. Strong typing would probably also make it a lot easier to automate the process of calling externals from Transcript without all those ghastly, clunky C wrappers and crap. There's a dream - a rev scientific application with a beautiful interface rendering OpenGL objects in real time and a typed, Transcript-coded stack running energy minimization on a separate thread in the background. I doubt I'll put my hands in my pockets again and upgrade my expired rev license just to have deep masks on my GUIs - I'm not knocking it, it's just not a feature I urgently need right now ... but fast compiled stacks, easy access to externals ... now you're talking ... where's my check book? Best Gordon --- Dennis Brown [EMAIL PROTECTED] wrote: Dan, I also would like to speed up array processing. It kills me that my friend won't move from VB to Rev because when I write the same array processing problem that he uses, VB runs 10+ times faster than Rev. I also have had to jump through hoops trying to figure out ways to make my array processing go faster --it usually requires taking a simple script and making it 5 times as complicated as the way you would do it in VB or RB or any other ordinary language. It is not just for the type of math problems that I am dealing with. As visual effects become more important, being able to quickly process numeric arrays like a pixel image array becomes important. However, I don't think compiling scripts is the answer. I love having the interpreted environment for interactive debug and experimentation. The UI is where all the code and debugging time is spent. I don't want to trade that in for anything. Rev is all about UI, but weak on array speed. The language as it is defined would hardly be faster as a compiled version because of the type-less and stringy nature of the variables. Compiled languages get their effeciency by the programmer telling them up front the data type and therefore the correspondence to specific machine code operators. There is no guessing or mixing
RE: compileIt for revolution?
Sweet! But still all UI-related. You'll get no argument from me that rev is great for the UI, but no amount of such trickery will ever allow me to implement an efficient algorithm in Transcript to process large 3-dimensional arrays of floating point numbers ... and have it complete while I'm still young enough to care about the results. ... at least not in the Transcript we currently have ;) Gordon --- MisterX [EMAIL PROTECTED] wrote: Gordon, Beware that even i surprise myself with newby tricks. I just posted a slow fractal moire maker. It creates beautiful patterns and the detail is amazing but it does so creating some 4 graphics in a card. For the truely beautiful patterns, it took 30 graphics! The making can still be optimized but deleting images cannot be done like words in a field! Delete graphic 1 to -1 or delete all graphics doesn't work. i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 30 graphics deleted in 2 seconds. Hope this brings insight... Rev does wonders you wouldn't believe - and C optimization is not always the trick - the objects are not the same when it comes to the GUI. But when it comes to doing many of many things in a script that's where it starts showing... Like i said, there's always another way to do it! cheers Xav -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Webster Sent: Wednesday, June 22, 2005 16:14 To: How to use Revolution Subject: Re: compileIt for revolution? I would absolutely echo what Dennis has just said. I was initially really impressed with rev and I should say I still am in certain respects - comfort and ease of use, the elegant and intuitive language and stack/card paradigm etc. etc. But I have been unable to get rev to do what I want it to do behind the scenes (i.e. my application logic) without jumping through the kinds of hoops that Dennis describes - effectively negating all the advantages of programming in Transcript that I just outlined. And even when I could get the code working, man it was SLOW. It was discouraging to see Python easily outrun rev for the equivalent code - I mean I love Python and all, but it's hardly the gold standard for speed. I would think that the stack paradigm would neatly allow for the creation of strongly-typed stacks that could be jumped into from the kind of warm and fuzzy typeless stacks that give rev its wonderful flexibility. The compiler could then insist on declarations for all objects within the typed stack and compile it with far greater optimization than is possible for the typeless stacks, perhaps even going as far as native code compilation :-D Imagine what a superb development environment rev could be with these features. Flexible and typeless for all the UI/scripty/fun parts of the app; more draconian but hellishly fast for the down-to-the-metal hardcore byte-crunching parts of the app. Strong typing would probably also make it a lot easier to automate the process of calling externals from Transcript without all those ghastly, clunky C wrappers and crap. There's a dream - a rev scientific application with a beautiful interface rendering OpenGL objects in real time and a typed, Transcript-coded stack running energy minimization on a separate thread in the background. I doubt I'll put my hands in my pockets again and upgrade my expired rev license just to have deep masks on my GUIs - I'm not knocking it, it's just not a feature I urgently need right now ... but fast compiled stacks, easy access to externals ... now you're talking ... where's my check book? Best Gordon --- Dennis Brown [EMAIL PROTECTED] wrote: Dan, I also would like to speed up array processing. It kills me that my friend won't move from VB to Rev because when I write the same array processing problem that he uses, VB runs 10+ times faster than Rev. I also have had to jump through hoops trying to figure out ways to make my array processing go faster --it usually requires taking a simple script and making it 5 times as complicated as the way you would do it in VB or RB or any other ordinary language. It is not just for the type of math problems that I am dealing with. As visual effects become more important, being able to quickly process numeric arrays like a pixel image array becomes important. However, I don't think compiling scripts is the answer. I
Re: compileIt for revolution?
I think the issue here is an elegant and efficient way to interface with externals. If we had this, it would solve both problems. When I say efficient, I don't mean pass a 100MB array as a text string to an external that converts it to numbers than does some processing and converts back to a text string and passes the 100MB back, then the 100MB is passed again to the external for the next processing step... NOT the solution! Dennis On Jun 22, 2005, at 12:17 PM, Rob Cozens wrote: Mr. X, et al: The whole compileIT is not required but an internal module to create ultra-fast native code would be great. Now that would be a programmer's tool worth any eye candy in RunRev. Add access to system calls, and you have my support. Rob Cozens Wisdom entereth not into a malicious mind, and science without conscience is but the ruin of the soul. -- François Rabelais (c. 1494-1553) ___ 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: compileIt for revolution?
Transcript/Rev aren't a general-purpose environment. There's a whole class of apps for which they are ideally suited. There are also many for which it's not the right tool. I'm in favor of continuing to make it do what it does do better and better. I suspect you are, too, so I'm not being contrary here, just clarifying. but Dan, adding a external (with just a new transcript handler or function bridges that gap! Isn't that important marketing or userability wise? Best Xavier ___ 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: compileIt for revolution?
The simplest possibility for the external route would be to be able to pass (and use) to and from the external, handles to large RAM-based sets of floating-point numbers; that was the solution I used in Hypercard back when the Earth was still cooling, and it worked very well. On 22-Jun-05, at 10:35 AM, [EMAIL PROTECTED] wrote: I think the issue here is an elegant and efficient way to interface with externals. If we had this, it would solve both problems. When I say efficient, I don't mean pass a 100MB array as a text string to an external that converts it to numbers than does some processing and converts back to a text string and passes the 100MB back, then the 100MB is passed again to the external for the next processing step... NOT the solution! Dennis -- John R. Vokey, PhD Professor B.E.R.G. - Behaviour and Evolution Research Group Micro-Cognition Laboratory Department of Psychology Neuroscience University of Lethbridge Lethbridge, Alberta T1K 3M4 CANADA (403) 329-2409 office/lab (403) 329-2555 FAX ___ 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: compileIt for revolution?
John, I actually had a complete matrix algebra package as an external for Hypercard. I know how to use it, because I cut my teeth on APL. I implemented my complex algorithms and state machines in it. The coding was cumbersome, and it was difficult to debug and handle edge conditions, sparse arrays, etc. And to top it all off, it only ran 25% faster than the simple HyperCard stack even though it could crunch numbers 10 times faster. However, I have to admit that it spent a lot of time converting and passing arrays back and forth to HyperCard. A native engine capability might make a big difference if the internal representation could be typed by making sure you only put all the same type numbers into the array, and if the indexes were truly integers. The both matrix and element by element operations could be mixed and we would have the best of both worlds. Dennis On Jun 22, 2005, at 3:30 PM, Dr.John R.Vokey wrote: It seems to me that the issue of speed applies mostly to the (mathematical) manipulation of numerical arrays; we need a complete matrix algebra package as part of the engine. If we had such, I suspect that virtually all of the desire for CompileIt!, and complaints about speed, would be vitiated. On 22-Jun-05, at 9:51 AM, [EMAIL PROTECTED] wrote: Well, from what I see here is a business opportunity. If everyone that is interested in achieving this (and willing to pay). Then I would suggest a group should be formed andcreate a well defined set a specifications. I am sure that Chipp at Altuit or someone else would be able to produce the much desired solution but for a price. This would be the quickest way of getting exactly what is being asked for in the shortest period of time. I would be glad to coordinate (off the list ) creating the product specifications and then putting it out to bid. ...any takers? Please contact me off the list. regards, Glen On Jun 22, 2005, at 3:45 PM, Dr.John R.Vokey wrote: The simplest possibility for the external route would be to be able to pass (and use) to and from the external, handles to large RAM- based sets of floating-point numbers; that was the solution I used in Hypercard back when the Earth was still cooling, and it worked very well. On 22-Jun-05, at 10:35 AM, [EMAIL PROTECTED] wrote: I think the issue here is an elegant and efficient way to interface with externals. If we had this, it would solve both problems. When I say efficient, I don't mean pass a 100MB array as a text string to an external that converts it to numbers than does some processing and converts back to a text string and passes the 100MB back, then the 100MB is passed again to the external for the next processing step... NOT the solution! Dennis -- John R. Vokey, PhD Professor B.E.R.G. - Behaviour and Evolution Research Group Micro-Cognition Laboratory Department of Psychology Neuroscience University of Lethbridge Lethbridge, Alberta T1K 3M4 CANADA (403) 329-2409 office/lab (403) 329-2555 FAX ___ 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: compileIt for revolution?
If you are mostly writing for yourself, you can, of course, use RR to produce a nice GUI, but pass all the time critical computations to, say Matlab (or Octave, Matlab's GNU equivalent) using the shell commands. But then, if that were the case, why not just use Matlab (or Octave) directly? Incidentally, Smile (the free Applescript program writer) has a brilliant math library (OSAX) attached to it that can be called from RR http://www.satimage.fr/software/en/index.html. BTW, APL was my first programming language, too! Perhaps that is why I tend to think of solutions in matrix linear algebra. On 22-Jun-05, at 2:08 PM, [EMAIL PROTECTED] wrote: John, I actually had a complete matrix algebra package as an external for Hypercard. I know how to use it, because I cut my teeth on APL. I implemented my complex algorithms and state machines in it. The coding was cumbersome, and it was difficult to debug and handle edge conditions, sparse arrays, etc. And to top it all off, it only ran 25% faster than the simple HyperCard stack even though it could crunch numbers 10 times faster. However, I have to admit that it spent a lot of time converting and passing arrays back and forth to HyperCard. A native engine capability might make a big difference if the internal representation could be typed by making sure you only put all the same type numbers into the array, and if the indexes were truly integers. The both matrix and element by element operations could be mixed and we would have the best of both worlds. Dennis -- John R. Vokey, PhD Professor B.E.R.G. - Behaviour and Evolution Research Group Micro-Cognition Laboratory Department of Psychology Neuroscience University of Lethbridge Lethbridge, Alberta T1K 3M4 CANADA (403) 329-2409 office/lab (403) 329-2555 FAX ___ 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: compileIt for revolution?
On Jun 22, 2005, at 1:45 PM, Dr.John R.Vokey wrote: The simplest possibility for the external route would be to be able to pass (and use) to and from the external, handles to large RAM-based sets of floating-point numbers; that was the solution I used in Hypercard back when the Earth was still cooling, and it worked very well. Would either RPN or the use of external-side variables by name be just as usable to you? Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ 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: compileIt for revolution?
Not forgetting, Brian, just discounting. :-D Fair enough. For me, that was the only reason to use CompileIt. Speed of ordinary scripts felt like something I wanted to deal with algorithmically rather than by compiling. After all, compiling the same algorithm was probably going to have less impact than my next processor upgrade! I'm sure there were instances where it was useful, but for me, it was all about writing externals without having to learn C (which I've long since done, but alas...) I avoided that stuff like the plague. Guess I'm a bit of an xtalk purist (or some would say bigot). Transcript isn't going to be THE solution/language for all problems. Every time we try to glue something onto it to solve a problem it wasn't intended to solve, we risk making the stuff it does do easily and well harder. I agree. Transcript/Rev aren't a general-purpose environment. There's a whole class of apps for which they are ideally suited. There are also many for which it's not the right tool. I'm in favor of continuing to make it do what it does do better and better. I suspect you are, too, so I'm not being contrary here, just clarifying. I actually do feel the same way. For me, it's mostly a moot point. I write externals in C when I need them, and if I need a lot of them (or heck, more than 1 of them in a project) then I consider other tools. I believe I'm mostly speaking for others (dangerous, I know!) who have expressed a lot of interest in native access to OS routines. I wouldn't mind seeing a new CompileIt!, just because it would be a cool toy and handy for some - but I wouldn't personally rank it very high on the cost vs. benefit scale. I'm not sure where I would fall if I didn't write externals already, though. - Brian ___ 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: compileIt for revolution?
Dennis. You may well be right. But the definition of this Achilles heel varies all over the map. Revolution is not the best programming language for all classes of problem. Those who choose not to see it as a real programming language because of one perceived lack will often just find another if that one's addressed. And another. I've been through this with a dozen or more languages in my too-many-years in this business. All I'm saying is that rather than spending time and effort to enhance or extend Revolution to solve a set of problems for which another language might be better suited, I'd rather see RunRev work hard to make it easier and easier and more stable for addressing the problems for which it is the ideal solution. There are, I believe, more than enough of those to make Rev successful for many years to come. On Jun 22, 2005, at 6:40 AM, Dennis Brown wrote: As long as Rev has this Achilles heel, it will preclude it's use as a real programming language in the minds of many. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
John, I am not writing just for myself, I use a Mac and my friend uses a PC and he also has to be able to run my stuff. I do not have the budget for Matlab, etc., etc. I buy everything out of my own pocket. I am constrained to exactly what is good about Rev. Dennis On Jun 22, 2005, at 5:15 PM, Dr.John R.Vokey wrote: If you are mostly writing for yourself, you can, of course, use RR to produce a nice GUI, but pass all the time critical computations to, say Matlab (or Octave, Matlab's GNU equivalent) using the shell commands. But then, if that were the case, why not just use Matlab (or Octave) directly? Incidentally, Smile (the free Applescript program writer) has a brilliant math library (OSAX) attached to it that can be called from RR http://www.satimage.fr/software/en/ index.html. BTW, APL was my first programming language, too! Perhaps that is why I tend to think of solutions in matrix linear algebra. On 22-Jun-05, at 2:08 PM, [EMAIL PROTECTED] wrote: John, I actually had a complete matrix algebra package as an external for Hypercard. I know how to use it, because I cut my teeth on APL. I implemented my complex algorithms and state machines in it. The coding was cumbersome, and it was difficult to debug and handle edge conditions, sparse arrays, etc. And to top it all off, it only ran 25% faster than the simple HyperCard stack even though it could crunch numbers 10 times faster. However, I have to admit that it spent a lot of time converting and passing arrays back and forth to HyperCard. A native engine capability might make a big difference if the internal representation could be typed by making sure you only put all the same type numbers into the array, and if the indexes were truly integers. The both matrix and element by element operations could be mixed and we would have the best of both worlds. Dennis -- John R. Vokey, PhD Professor B.E.R.G. - Behaviour and Evolution Research Group Micro-Cognition Laboratory Department of Psychology Neuroscience University of Lethbridge Lethbridge, Alberta T1K 3M4 CANADA (403) 329-2409 office/lab (403) 329-2555 FAX ___ 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: compileIt for revolution?
Precisely my earlier point. Rev is not for everything. If you have an app that needs to engage in this kind of esoteric processing, then you probably need to pick a different tool either for the entire app or to create a whiz-bang external that does this kind of processing fast enough for your needs. We need to resist the temptation to make rev into a panacea. A programming language that is everything to everyone is nothing to anyone. On Jun 22, 2005, at 10:04 AM, Gordon Webster wrote: no amount of such trickery will ever allow me to implement an efficient algorithm in Transcript to process large 3-dimensional arrays of floating point numbers ... and have it complete while I'm still young enough to care about the results. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
I support the notion of making integration of non-platform-specific externals easier. But Rev's biggest win for me other than high-performance coding is cross-platform compatibility and I'm opposed to platform-specific extensions that either break or cause me to write painful conditional code blocks. The way rev implements the OS X-specific stuff is right. On Windows, it is just ignored. It doesn't break and the app still runs. That's all I'm saying here. On Jun 22, 2005, at 10:33 AM, MisterX wrote: but Dan, adding a external (with just a new transcript handler or function bridges that gap! Isn't that important marketing or userability wise? ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
This whole discussion has been revealing and intriguing to me. My favorite programming language is Smalltalk. But before it was possible to create UIs for Smalltalk without writing code, I found it cumbersome. When a product called WindowBuilder came along, I felt like we'd achieved the ultimate development environment. In many ways, I still think that. Smalltalk had other problems, unfortunately, that made it great to code in, difficult to impossible to deploy. Then my second favorite language was Python. The GUI-building tools for Python are pathetic to non-existent. But the language is powerful and elegant and extends naturally. If the PythonCard project I was engaged in before I discovered Revolution had been on a fast track or complete, odds are I'd have never used Rev. Now I favor Transcript and RunRev. Building UIs is all but painless and 95% of what I want or need to do in creating apps is simple inside the elegance of Transcript. But Transcript isn't object- oriented. Two aphorisms came to mind as I read this entire thread again today. One is, No good programmer uses only one tool for everything. The other is, It's a poor workman who blames his tools. ~~ Dan Shafer, Revolution Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermedia.com/revolutionbooks.html ___ 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: compileIt for revolution?
Yes, as long as the constant conversion isn't required; I used handles both within Hypercard and in the XTHNGs, along with two conversion routines (compile hc variables into a floating-point array, and convert a floating-point array into a hc variable); the conversion routines were used sparingly. On Jun 22, 2005, at 1:45 PM, Dr.John R.Vokey wrote: The simplest possibility for the external route would be to be able to pass (and use) to and from the external, handles to large RAM-based sets of floating-point numbers; that was the solution I used in Hypercard back when the Earth was still cooling, and it worked very well. Would either RPN or the use of external-side variables by name be just as usable to you? ___ 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: compileIt for revolution?
Dan- Wednesday, June 22, 2005, 3:11:38 PM, you wrote: DS Two aphorisms came to mind as I read this entire thread again today. DS One is, No good programmer uses only one tool for everything. DS The other is, It's a poor workman who blames his tools. Or, possibly more apropos, No good programmer blames only one tool for everything. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Dan- Wednesday, June 22, 2005, 3:05:06 PM, you wrote: DS The way rev implements the OS X-specific stuff is right. On Windows, DS it is just ignored. It doesn't break and the app still runs. Here's where I think you're off base on this, Dan. I'd like to see runrev spend their time fixing bugs and working on new enhancements rather than chasing after the latest new features in enter name of OS here. The shell command and being able to run AppleScript scripts are examples of being able to extend the language without relying on runrev to add more things to the engine. It's a winning situation for all if a) the runrev team doesn't have to go implementing new solutions every time a particular OS changes; b) developers don't have to wait around for runrev to implement new things; and c) there's an easy way to do these things from Transcript without needing to spawn non-cross-platform external libraries. Sometimes you need to get out of the sandbox (QuickTime, for example) and I don't think it should be the responsibility of the runrev team to keep extending the engine's capabilities. If runrev provides the hooks to allow us to do this then the onus is on us (got kind of a ring to it, doesn't it?) as developers to do what we need. I don't see this as interfering with your, or anyone else's, ability to code. If you need the capability, use it; otherwise just ignore it. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Dennis- Wednesday, June 22, 2005, 1:47:25 PM, you wrote: DB John, DB I actually had a complete matrix algebra package as an external for DB Hypercard. I know how to use it, because I cut my teeth on APL. I DB implemented my complex algorithms and state machines in it. The DB coding was cumbersome, and it was difficult to debug and handle edge DB conditions, sparse arrays, etc. And to top it all off, it only ran DB 25% faster than the simple HyperCard stack even though it could DB crunch numbers 10 times faster. However, I have to admit that it DB spent a lot of time converting and passing arrays back and forth to DB HyperCard. A native engine capability might make a big difference if DB the internal representation could be typed by making sure you only DB put all the same type numbers into the array, and if the indexes were DB truly integers. The both matrix and element by element operations DB could be mixed and we would have the best of both worlds. Couldn't you just recompile this as a runrev external? The GetArray() and SetArray() functions can work with the entire array at once, saving you from having to pass individual array elements. If you really need the speed you could have the external process the array in assembly language, stuffing the values into registers and having the CPU crunch them for you. -- -Mark Wieder [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Derek Bump wrote: If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. It's pretty bad when I've used about 10 different compilers (including MS Visual C) and I still can't get the samples to compile properly. But that's a whole different issue. I had a lot of trouble getting it to work first time. A week later, I had even more trouble getting it to work the second time. (A sure sign that I hadn't really understood what I'd been doing first time not even well enough for my detailed notes to make it repeatable). Third time was better .. it only took me 4 tries and 2 false starts tonight :-) Now I can almost do it reliably. The thing I kept getting wrong was understanding when the binding happens, and what that implies. The FAQ (in the Externals stack that came in the SDK says In order to bind to external libraries the set externals to function must be used. This tells the engine the library or multiple libraries that the engine should bind to the next time it starts up. Multiple libraries should be on separate lines. What I now do (having got it wrong often enough, including right now when I was writing down the step-by-step) is to start the stack up, set the externals, save it, quit Rev. Restart Rev, open the stack, run the script that sets externals again - then check that put the external of this stack and put the externalFunctions of this stack give me what I expect SO you might want to retry your earlier efforts, taking extra care about that step. If it's not that read on. Here's a step-by-step that now works reliably for me (even if I don't properly understand one crucial step :-) I use Bloodshed Dev C++ on Windows XP. I have version 4.9.9.1 (it's GPL - but that doesn't impose GPL restrictions on code compiled with it). 0. Create a directory - keep things simple by making this a top-level directory with no spaces in the name. (That's probably unnecessary, but I had trouble with spaces in file names. I think that was with one of the other compilers I tried earlier - but I haven't gone back to change this and see if everything still works ) 00. unpack or unzip the Rev externals SDK into that directory. 1. make files this.c, this.h, this.def (see the end of the email for their contents) (why this.def ? and how did I figure out what goes into it ? far less what to do with it ??? no idea, but it works now .) 2. open Dev-c++ 3. File / New / Project Select DLLfrom the set of icons Name the project this Select C Project from the radio buttons Click OK In the file save dialog, make sure you select the directory where you are doing this work (not the default), with the name as this (should be default). 4. click on th + beside the Project in the left pane of the window It should expand to show two files - dllmain.c and dllmain.h 5. For each of these, in turn, right click on it, select Remove File (and say no to saving it). 6. Right click on the Project, select Add to Project and in the file dialog select this.c 7. Repeat 6, selecting XCmdGlue.c 8. Menu select Project / Project Options select the Tab for Parameters Go to the 3rd column (Linker) and add to the end of the existing line --def this.def (without the quotes) The line should now read --no-export-all-symbols --add-stdcall-alias --def this.def and click OK 9. Menu select Execute / Compile You'll see a dialog that shows compiling this.c, then compiling XCmdGlue.c, then Linking this.dll Check the log (select the Log tab to see it). If it all looks OK, check that you now have a this.dll file 10. Start Rev, create a new main stack, add one button and one field. Make the button script be on mouseUp put the effective filename of this stack into mVar set the itemDel to / put this.dll into item -1 of mVar set the externals of this stack to mVar put xname() into field Field end mouseUp save it, and then click the button. I think this will fail first time - you need to close the stack and re-open it for the binding to take effect. See above - I actually save it, exit Rev, etc.Probably unnecessary, but I had so much trouble from 'accidental success' the first time I tried all this, and couldn't repeat it second time, that I am just paranoid . With any luck, you now have a working stack+external. So now when you try what you want to do, and it doesn't work, you have a base-line that you can compare against. If you don't have luck, email me off-list and I'll send you all the files involved from my system, and
Re: compileIt for revolution?
MisterX wrote: Gordon, Beware that even i surprise myself with newby tricks. I just posted a slow fractal moire maker. It creates beautiful patterns and the detail is amazing but it does so creating some 4 graphics in a card. For the truely beautiful patterns, it took 30 graphics! The making can still be optimized but deleting images cannot be done like words in a field! Delete graphic 1 to -1 or delete all graphics doesn't work. i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 30 graphics deleted in 2 seconds. And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: compileIt for revolution?
Recently, Richard Gaskin wrote: i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 30 graphics deleted in 2 seconds. And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Unfortunately, this won't work for Xavier's case since each object is shaded with a different color, but it's worth noting as you say that sometimes multiple vector objects can be replaced with one. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.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: compileIt for revolution?
Scott Rossi wrote: Recently, Richard Gaskin wrote: i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 30 graphics deleted in 2 seconds. And as Geoff Canyon discovered, you can go one step further by drawing all polygons as a single object, but just including a blank line in the points property wherever you want a discontiguous object. Unfortunately, this won't work for Xavier's case since each object is shaded with a different color, but it's worth noting as you say that sometimes multiple vector objects can be replaced with one. True. If there are 30,000 different colors being used my hunch is that you could but that in half with very few human eyes able to discern any difference. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: compileIt for revolution?
On Jun 22, 2005, at 4:15 PM, Alex Tweedly wrote: What I now do (having got it wrong often enough, including right now when I was writing down the step-by-step) is to start the stack up, set the externals, save it, quit Rev. Restart Rev, open the stack, run the script that sets externals again - then check that put the external of this stack and put the externalFunctions of this stack give me what I expect ... Alex, To check if an external has successfully loaded you can check for the externalPackages of a stack. When you create the external you define the global char XName[] = My Extension Name; This string will show up in the externalPackages of the stack when it has been successfully loaded. As for when the external loads you can do this: 1) Create a new stack. 2) Set the destroyWindow of the stack to true 3) Set the externals of the stack to whatever. 4) Close the stack window 5) Open the stack window 6) Check the externalPackages. It should have the name of the external. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] ___ 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: compileIt for revolution?
Dennis Brown wrote: I don't think compiling scripts is the answer. It wasn't with CompileIt! either. ;) Yes, it was *possible* to compile straight HyperTalk, but that rarely ran significantly faster than it did in HC's own interpreter, mostly due to the need for callbacks to the engine. So instead CompileIt! had its own unique syntax and hundreds of symbols one could use to implement things that were algorithmically very much like one would do in Pascal or C. Of course this required a whole other level of knowledge, and for those symbols related to the Mac Toolbox it also required the dozen-volume set of Inside Mac books, and/or the more efficient Think Library (which came with Think C). So to use CompileIt! effectively required an understanding of pointers, handles, and the OS API, along with many other low-level things. For many folks the bigger downside to implementing lower-level algorithms in a high-level xTalk variant was that it ultimately resembled neither HyperTalk nor any of the languages used in examples for the OS API. With only 27 keywords in the language, the learning requirement for implementing those sorts of algorithms in C is arguably much lower, and there are infinitely more resources available to get one started with C than with CompileItSpeak. And of course CompileIt! was written for Mac OS/68k only, while Rev runs on a dozen platforms. By the time one could manage to master CompileItSpeak to do effecient work, the amount of forked code needed for all platforms would not likely be much less than is required for C. This is not to suggest that I believe all Rev fans should learn C, so let me please dispel that hyperbole before it arises. All I'm suggesting is that CompileIt! was no panacea, and the effort of using it well was arguably about the same as using existing solutions to make externals in Rev today. -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ 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: compileIt for revolution?
Derek Bump wrote: If one who knows C and could figure out some sort of Transcript wrapper, then it would be possible. There are many freeware and public domain compilers out there, but finding one that successfully compiles DLLs for Revolution is seemingly difficult. I've been trying for a few months now, but with my limited knowledge of C I end up running into errors. I am working on this project, but the *confusing* Externals SDK doesn't help. What aspects have you found confusing? I wonder if a Rev tool set up for writing C, generating the make file, and running GCC would address a lot of this with very little effort -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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
