Re: Rev 2.7 Editor & stability problems
No, these were actually new stacks created afresh using Rev 2.7. In the course of editing one of them, Rev actually crashed 4 times. It was hard to tell what it was I did that made it crash but it seems like it happened changing focus between some of the open windows - but as I said in my first email, it wasn't a consistent thing. BTW: I am using a vanilla Rev 2.7 installation with no plugins or add-ons of any kind, so at least some fraction of the problems that users are experiencing, would seem to be a feature of the new release rather than some kind of incompatibility problem with plug-ins or older releases. Best Gordon Dave Beck <[EMAIL PROTECTED]> wrote: Gordon, When you are getting these crashes, are you editing a stack that was converted from 2.6.1? Does this happen on multiple stacks or just one? >From the info on this bug so far, it seems as though it is sensitive to particular stacks, as opposed to configurations. That is my personal experience so far with this problem as well. Dave > Like other users on this list, I also see serious stability problems with > Rev 2.7 under WinXP. I have experienced several crashes while editing and > testing scripts, none of which seem to have any consistent pattern. I will > try and figure out what I was doing when the crashes occurred so that I > can provide more information to the list. ___ 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
Rev 2.7 Editor & stability problems
Like other users on this list, I also see serious stability problems with Rev 2.7 under WinXP. I have experienced several crashes while editing and testing scripts, none of which seem to have any consistent pattern. I will try and figure out what I was doing when the crashes occurred so that I can provide more information to the list. The script editor seems to have real problems when you edit "repeat .." loops. If you have a script like this repeat with x = 1 to 10 repeat with y = 1 to 20 ... do something end repeat end repeat and you try to insert a line between the 2 'repeat' statements, the editor tries to insert new 'end repeat' statements and blank lines and it all gets horribly messy. Yes I could use Constellation, or maybe there's an option to switch off the autocomplete feature on the loops, but frankly I would consider this a bug. One of the crashes I experienced was actually while I was trying to clean up after the editor had messed up my code. I am a fan of Rev but I feel compelled to say that it seems like inverted priorities on Runrev's part to add fancy cosmetic features like multiple blend modes on controls before addressing more fundamental issues of Rev's basic stability and user interface, not to mention some of the language features that some of us have been asking for for some time, like support for real arrays and so on. I am rather disappointed that Rev 2.7 is not the big leap forward I had hoped it would be and also, that a considerable portion of its users seem to be experiencing new stability problems that weren't a problem in the previous release. Here's hoping that these things can be fixed pretty soon. Best Gordon ___ 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: Creating cards
It's in the stack script of the stack to which I'm trying to add the card. It's
the only stack in my prototype library at the moment, but in anticipation of it
being used as a library in other applications, I even had some code ahead of
the "add card" line to set the defaultstack and so forth.
If I just use "create card "AnotherCard" in the message box, it works fine,but
when this line is in my function, it creates the card twice. I even tried
cloning the first card and the same duplication occurs with the clone command.
I'm uisng rev 2.7
Best
Gordon
jbv <[EMAIL PROTECTED]> wrote:
Gordon,
in which script is your addCard function located ?
> Dear Revvers
>
> Haven't used rev for a while - what am I doing wrong?
>
> I created a function to add a named card to a stack like this:
>
> function addCard cardname
> create card cardname
> end addCard
>
> When I run it from the message box like this: addCard("AnotherCard"), it
> creates the new card twice!
>
> Before I run this function, the 'cardnames' of my stack looks like this:
>
> MyFirstCard
>
> Afterwards, it looks like this:
>
> MyFirstCard
> AnotherCard
> AnotherCard
>
> Any ideas why it creates the new card twice?
>
> Best
___
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
Creating cards
Dear Revvers
Haven't used rev for a while - what am I doing wrong?
I created a function to add a named card to a stack like this:
function addCard cardname
create card cardname
end addCard
When I run it from the message box like this: addCard("AnotherCard"), it
creates the new card twice!
Before I run this function, the 'cardnames' of my stack looks like this:
MyFirstCard
Afterwards, it looks like this:
MyFirstCard
AnotherCard
AnotherCard
Any ideas why it creates the new card twice?
Best
Gordon
___
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: "There was an error..."
Hi Rob I believe that in keeping with the current geopolitical climate, from version 2.6 onwards rev has implemented error logging that conforms to Department of Homeland Security guidelines for public announcements. The message you received tells you that based upon the best intelligence the compiler has from its credible sources, there is an elevated probability of a non-specific error in your code, whose nature and location are unspecified and about which, you can therefore do very little. You should continue your regular coding activities, visit shopping malls, take your kids to Disney Land etc. while remaining alert to any suspicious activities in your stacks that might be a result of infiltration by evil doers. Failing this, you could try: seal the current stack with DuctTape and plastic Best Gordon Rob Cozens <[EMAIL PROTECTED]> wrote: Hi All, I have a stack that runs fine interpretively on both Win XP (Rev 2.6.1) & Mac OSX (Rev 2.1.2). It also compiles and runs correctly on OSX. The stack is compressed & decompressed with each transfer between platforms. Compiling on Windows gives me "There was an error while saving the standalone application." That's nice to know; but it gives me little to go on to track down the error. Other Windows compiles into the same folder have worked with no problem. Ideas or suggestions, anyone? Rob Cozens, CCW Serendipity Software Company Vive R 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: Hand me the soft cushion! WAS: Items in a group
Klaus I think you mean "THE COMFY CHAIR!" (No no, not the comfy chair!) Gordon Klaus Major <[EMAIL PROTECTED]> wrote: Hi Jonathan, Am 15.12.2005 um 19:07 schrieb Lynch, Jonathan: > We could write an automated inquisition function... > Put TortureMercilessly(control tMyControl of group tMyGroup) into > field "tortured confession" I didn't exspect the spanish inquisition. NOONE exspects the spanish inquisition! The three main weapons... etc... :-D Best Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ 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: Case studies gallery
Wow Mariella, those examples in the case studies gallery are really beautiful - are they rev-built applications? Inspiring stuff! Best Gordon Marielle Lange <[EMAIL PROTECTED]> wrote: As I had at least one request for a case studies gallery, it is now up and running. Have you seen *anything* that good looking in the konfabulator gallery? You would like yours to be added? Simple, you can use the metadata editor for this purpose or you can send me a text file (preferably unix format, utf-8 if it contains non ascii characters) with the following information. For pictures, best are gif (png are a problem for IE) and with a width of 250px. To help you decide between the education and case studies gallery, the "education" gallery links to stacks for which the source is accessible, the "case studies" gallery is for commercial and non commercial applications distributed as compiled applications. revolution case study Short Title Description (basic html tags like can be used) (url to a file on your server or name part of the mtd file + .gif) (url to your website or any other relevant page) your name (first and last name) your email address Cheers, Marielle PS. Sorry for the strange emails from me. I posted them using the wrong email... they ended up in the cue, being published about a after I had sent them. Marielle Lange (PhD), Psycholinguist Alternative emails: [EMAIL PROTECTED], [EMAIL PROTECTED] Homepage http://homepages.lexicall.org/mlange/ Easy access to lexical databaseshttp://lexicall.org Supporting Education Technologists http:// revolution.lexicall.org/wiki ___ 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
[OT] You don't know what you've got 'till it's gone
I have always felt that one of the best things that rev has going for it is its incredible community of users whose collective wit, wisdom, experience and generosity help to make working with rev something out of the ordinary. This list is like the village pump for the rev community - a place where issues get discussed, collaborations get launched, business gets transacted and yes - more than once in a while, even problems get solved. I've seen griping and brainstorming sessions that seed new ideas and collaborations (today's gripe can be tomorrow's must-have Altuit plug-in), I've seen people recruit the services of other revvers, I've heard conference announcements, I've learned about the launch of new rev products ... on more than one occasion, I've even seen the light! (thanks for example, to Richard Gaskin who illuminated the mysteries of the message path for me by pointing me to one of his excellent articles on the subject). Who would want to give all that up just because a very small minority of the crowd that daily throng the village pump occasionally get a litle rowdy or overly sensitive? Not me. Flitting between 10 different lists for my rev content would seem to be far more arduous than just filtering the stuff I read on one list, and as others have pointed out, having multiple lists fragments an already small community. I would submit that if everybody on this list uses helpful, descriptive subject lines on their emails, respects and tolerates the diversity of modes and opinions that our little community encompasses and most importantly of all, extends to all comers the respect and infectious generosity and enthusiasm that has always characterized the rev community - there's no reason at all that this list cannot continue to be the invaluable resource that it always has been. Or we could spoil a good thing by losing sight of what really matters. Joni Mitchell said it better than I could - "You don't know what you've got till it's gone". Best Gordon ___ 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: List Splitting - Idea
I for one would hate to see this list stripped of its "Revolutionary" appeal
by limiting it only to discussions of rev users' technical problems. While
such technical problems may be the primary concern of this list, do they
really have to be it's only concern?
Remember just last month for example - Dan started a discussion on the
disappearance of the application desktop ("The Disappearing Desktop - It's
Real This Time") which turned into a superb debate and "blue skies"
brainstorming session about the future of software that made us all think.
Can I get that kind of mind expanding fare on the RealBasic Users Lists?
Not on your life.
The eclectic vibe on this list also corresponds well with the rather unusual
nature of rev itself and it's all of you that make it happen and help to make
the whole rev experience something kind of organic and out of the ordinary.
On a practical note, I try to discriminate and routinely read the technical
stuff that relates more closely with my own problems, skipping the rest
because there aren't enough hours in a day (or neurons in my skull) to absorb
it all. If I need to, I consult the archives when I wish to revisit stuff that
I skipped the first time around.
IMNSHO, let the lively discussions stay - the world of software development
is already gray enough without stripping this vibrant list of its color.
Best
Gordon
David Burgun <[EMAIL PROTECTED]> wrote: A very sensible approach!
I second the suggestion.
Cheers
Dave
>We have seen a debate here about splitting the list various ways and
>there are pros and cons for most everything.
>
>One many lists there are conventions that posters follow that
>include placing small "category keywords" in brackets before the
>subject line. This can get out of control if everyone makes up
>keywords but what if we use a ready made set? How about the second
>level menu keywords in the "Objects" section of the documentation?
>
>[Player]How do I or [Button]Border color isn't working right.
>or a generic [How] as in [How]do I make sprites?
>
>If we just let people know where to look for their [Keyword] (ie; in
>the documentation under the "Objects" button, then they might even
>find the answer in the docs! In any case it could make it easier to
>search in the archives, sort in our email clients, provide some
>structure for post processing for a wiki and many other benefits.
>
>It's not hard to do and it may provide just enough structure to help us all.
>
>BTW; how many lists do we have now and where are they?
>
>dave
>___
>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?
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 > >
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 discuss
Re: Economics & Eye Candy
Dear Dan Thanks for the reply. Alas, I am one of those colleagues you describe, since the major part of what I want to do simply doesn't work well with rev. Firstly, rev is far too slow for numerical computation. I did some tests and even byte-optimized Python beats rev for speed in most cases and that's hardly a "Gold Standard" for performance. Java, long lambasted for being slow, absolutely leaves rev in the dust as far as performance goes. Try doing a matrix inversion or sorting a huge list in both languages and you'll see what I mean. Granted, the Java development path is somehwat less fun than rev's, but Java is stable mature and truly cross (cross cross cross) platform if you use Swing components (Dan :-D) Now imagine you want to render some complex objects in 3D or visualize 2D or 3D data, both of which are things one might like to do even if you're not a geeky science coder like me (e.g. for games, financial analysis, GIS etc. etc.) All of this kind of stuff would be excruciating and impractical to code in rev unless ... (and here's my second major gripe with rev) ... you're willing to postpone your project for 6 months and write wrappers for a visualization DLL in C ... which is just what you wanted to avoid when you started using Transcript in the first place! With Java or Python, I import OpenGL or whatever visualization package I'm using and my workflow continues in my language of choice. I have access to the collective effort of thousands before me in a huge shared community of code. Java and Python may not be as much fun as rev, but they're like flying a plane compared to knuckle-walking in C. But as I said, I like Transcript and would like to see the evolution of rev steer more towards making the Transcript language really useful. So here's my wishlist for the good folks in Edinburgh ... 1. More comprehensive collection of datatypes (real arrays with ability to nest arrays etc.) 2. Much better performance (should also be enhanced by point 1) 3. Easier access to externals 4. A soild 2D vector graphics package And finally, inspired by Richard Gaskin's suggestion ... Compilation to Java bytecodes and integration of Java class libraries into rev ... Ooooh, you might have something there Richard ... Keep language you love, just swap interpreters (kind of like Jython) I like it :-D Best Gordon --- Dan Shafer <[EMAIL PROTECTED]> wrote: > Gordon. > > While I sympathize with some of your feelings (while > I continue to be > my most productive self when using Rev and grinning > from ear to ear > watching my colleagues who use Python, Java, and > Basic go through > excruciating pains to do what I can do in seconds or > minutes in my > favorite tool!), this notion of integrating > externals is one on which > I have pretty strong opinions. (Yes, I know. That's > unusual for me. NOT) > > The problem, IMNSHO, isn't with Rev, it's with the > fact that as far > as I know there is no single method of creating and > implementing > externals that runs on all platforms. I may be wrong > about that; DLLs > may in fact be more cross-platform than they were > last time I looked, > particularly with the emergence of OS X. But I am > pretty strongly > opposed to Rev spending significant time and > resources extending the > capabilities of the program for *any* > platform-specific > functionality. And, FWIW, that includes when they do > so for MY > favorite platform, OS X. I'd have been delighted to > see 2.6 fix a > bunch more bugs and not implement CoreImage and > DeepMask stuff. Now, > I realize that in saying that I'm in a small > minority and I also > realize that the DeepMask stuff works cross-platform > and will be a > real boon as Longhorn emerges from its near-decade > in cold storage. > But my position remains the same: of all the > development tools from > which I can choose, only two that I know of -- Rev > and Flash -- give > me true cross-platform capability. And because I > choose to work on a > minority platform but want to be able to reach the > majority platform, > cross-platform is my personal number one feature in > Rev. Anything > that detracts from that is just in my way or an > unnecessary appendage. > > So if there is a way to facilitate the incorporation > of cross- > platform external routines relatively transparently > and to give me a > Transcript-level way of dealing with them, I'm happy > to see it > implemented even though I have yet to need such > capability in the > dozens of things I've written. But if supporting > externals must be > done for a specific platform -- or, almost as badly, > differently
RE: Economics & Eye Candy
Mr X has really hit the nail squarely on the head. I often open the rev IDE, wistfully hoping perhaps that somehow it could now magically do what I need it to do. Then I realize it can't and drift away to other development platforms with a sense of regret at what could have been. Now rev 2.6 is out and there are more fancy GUI features than ever (deep masks etc.) but still no real arrays, still no bridge to the vast world of shared libraries that would allow me to integrate external functionality into rev and save me having to either reinvent the wheel or spend my time writing C wrappers (for comparison, look at the Python 'ctypes' module or the 'usedll' type of features that abound in the many versions of Basic). Sigh! Even my licence has expired and I just can't imagine stumping up another $200.00 to have 'deep masks', but still not the features I really need. Transcript has the potential to be so much more than just a cool GUI designer. Gordon --- MisterX <[EMAIL PROTECTED]> wrote: > > > > Surprise: the economics are tied to the eye candy. > > > > Regards, > > > > Scott Rossi > > Good arguments Scott, but i disagree still > > the economics are based on the sales... > marketshare... > Industry standards... > > Sure the mac is prettier, like a bmw, but it's still > not the bmw they lease for the common company > driver. > > No matter how you twist the argument, the law of > supply and demand will rule... More technicians to > managers. > > Rev may be a development management tool, it aint > the common programmer's > heaven... (a thematic hyper-twist between the lines) > > in my company, it's 3000 seats... sun emc and MS. > Major enterprise tools, > the more they cost, the more likely they will be > bought... > > i seriously dont see how apple could vantage one > "enterprise" feature... > even security... You'd have to rely on specific > hardware - not mac os. > Databases? Oracle - Production CPU? Sun or > mainframe. Clients? 3000 PCs or > thin clients (as is now the fashion in reducing > costs in workstation > leases). So if Rev still doesn't work in Metaframe > environments, it's not a > problem but it's still an eye sore for any > developper who can't distribute > 1000 of anything to a larger more enterprise client. > That's economic losses > for (not me) the many PC=rent developpers among you. > > I dont say rev is not capable, it's just not being > done the way i would have > expected in terms of cross-platform or enterprise > "quality and feel" as it's > being done for the "minority" of potential mac > client. The performance and > lack of object/array programming is coming i hope > soon - probably after my > license expires. Meanwhile, i was able to develop > these myself and that's > where i see the eye-candy... The economics of a good > programming design. > After 15 years. How many of you are going to wait to > get these benefits? > That's opportunity cost for all of us... > > cheers > Xavier > http://monsieurx.com/taoo > > > > > > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > http://nulkin.blogspot.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Transitive?
I would say that this is hardly a case of Apple "leading the way". It's a workaround that Apple has been forced to adopt as a result of the already poor strategy of basing their hardware on a Motorola chipset that is evolving so slowly it is threatening to become obsolete. More Jurassic Park than Xerox parc. Apple actually considered migrating their hardware to Intel some years ago, but in spite of seeing an urgent need for it even then, they were unable to pursue the strategy since they considered it would be too disruptive. A major reason for this was the impact that it would have on their developers. Considering how Apple has progressively relinquished its market share to other platforms over the last decade or two, the sad truth of the matter is that they cannot afford to make life harder for the already small number (relatively speaking) of developers who currently target their hardware. The adoption of Transitive's technology is therefore an escape hatch from a poor business strategy rather than any kind of triumph of innovation on Apple's part. It just allows them to transition to Intel chipsets while maintaining backward compatibility with their old hardware for a year or two, to keep their shrinking user base happy. Hardly cause for a parade I think. Before all the Apple afficianado's on this list jump down my throat for this, let me add that I think that Apple has potentially the best home computer products on the market and an OS that is second to none. I am no fan of the MS hegemony either and I would LOVE to see Apple succeed and win the war of the desktop. I would like to be able to own one myself but the simple truth is I get so much more computer for my money using Intel/Linux and so much more choice of software to run on it as well. By analogy perhaps and for those of you who enjoy photography - consider the recent, effective demise of the Leica Camera company. Paraphrasing the Leica chairman: "We're a niche market with a loyal following of more discerning customers" - sounds familiar doesn't it! I pray that Apple will be smarter than this in the future. Gordon --- Dennis Brown <[EMAIL PROTECTED]> wrote: > Richard, > > That is what they do --take an app running on one OS > and one chip and > make it run on another OS and another chip. No > trivial task, but > they can do it. The face of software development > may be about to > open up to all platforms, and the face of hardware > development > opening up to be released from legacy restrictions. > And as usual > Apple will lead the way for the whole industry. > > Dennis ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Infinite-precision arithmetic (getting OT ;-)
...And not forgetting that the old testament shows us that Moses was the first person ever to own a car ... "...and he came down the mountain in his Triumph" Gordon --- Dar Scott <[EMAIL PROTECTED]> wrote: > > On May 24, 2005, at 2:42 PM, Stephen Barncard wrote: > > > but... EVERY platform has limits...eventually - > memory, speed. How can > > any tool be 'infinite'?? Better, bigger, faster, > perhaps, but ... > > infinite? Aren't you instead trying to craft tools > that are... > > scaleable? > > > > We're getting into theoretical physics, cosmology > here whoa... > > And theology. > > From the Psalms we know God's understanding is > infinite. From the > Bible we know He has calculated and has supplied > adders. (OK, those > are serpents, but adders is adders.) And He has > said often that he > will greatly multiply. One such place is in Genesis > 22 after Abraham > and Isaac went up the mountain to perform a > sacrifice. > > Still concerned about memory? > > Well, earlier in the same chapter we see God > supplied the RAM. > > Dar > > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: is there a best anti-viral program for Revolution?
Scanning the Transcript in stacks would not be useful I feel, since it's true purpose could be so easily obfuscated as Dar rightly points out. Also, encrypted stacks would be a major headache. I think that the 'sandbox' has to be at the bytecode level to be truly effective and that means it would probably be best to have this feature built into the runtime engine. I would imagine that this could work in much the same way as the Java security layer that is the default when running applets. Users would have the option to run the stack in 'safe' mode which warns them what the stack wants to do, instead of doing it. The Java folk have 'been there, done that' so perhaps the rev community could borrow from their experience rather than reinventing the wheel. Best Gordon --- Dar Scott <[EMAIL PROTECTED]> wrote: > > On May 25, 2005, at 12:23 AM, Erik Hansen wrote: > > > is there a best anti-viral program > > for Revolution? > > I struck the OT from my response. This is highly > relevant to this list. > > It is very easy to download and run stacks. Often > in mail we find > message-box one-liners to open stacks on the net. > Stacks can be > readily opened from Revolution Online. > > Transcript is very powerful, like fire. And like > fire it is dangerous. > > Stacks can work like applications and can be > libraries that we use in > what we build. > > Stacks can easily be viruses but are even more > likely to be be malware, > spyware, or a wide range of trojan horse bad things. > Like an Borland > Pascal math library, some might work OK for years > before springing on > you and your customers. > > As the Revolution community grows there will be > viruses and cousins and > these might be covered in virus databases. Many > anti-virus programs > look at mail or files. However, many of us run > stacks before they are > saved. > > It would be nice to be able to run stacks in a > sandbox. Do we have > some of this? > > If a stack is not encrypted, it might be possible to > automatically > detect any file i/o or network i/o or shell() if > there was no attempt > to hide that. However, Transcript is very powerful > and it would be > easy to hide those. > > It gets down to trusting your source, trusting that > what you are > getting is really from your source and trusting the > competence of your > source in not including malware in the stack. There > are many folks in > this community that I trust as far as integrity, but > know they can err > as easily as I in making sure a stack is safe. > > Some folks with files that can be downloaded include > MD5 or SHA digests > at the same site as the download or in > announcements. It is safer to > have those in independent sites. Even then there > are vulnerabilities. > Even so, this might be a direction for this > community to go. The > process of downloading a stack might point to two > URLs, one for the > stack and one for the digest. > > Another direction might be the concept of a signed > stack file. That > can be independent of the stack structure, simply a > signed version of > some binary file. However, if RunRev extends the > notion of stack to > include a signed stack and can handle the signature > verification, and > even do signing, that would be cool. > > All of this is a real pain, but I don't know how to > avoid it. Anything > added to Revolution and to Revolution network > services to minimize that > pain would be nice. > > 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 > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Deleting a folder doesn't work!!!
>From this discussion, it seems that there are two nearly identical commands for deleting a folder that have subtly different behaviors. Is this a) an accident, b) a good thing c) something that will be cleaned up in future versions of rev d) none of the above or e) all of the above? Best Gordon Did you get the Nulkin? http://nulkin.blogspot.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: To Rev or not to Rev
I totally agree with Dennis. Efficient arrays are the missing link in rev. Gordon --- Dennis Brown <[EMAIL PROTECTED]> wrote: > > On May 4, 2005, at 10:43 AM, Geoff Canyon wrote: > > > On May 2, 2005, at 8:02 AM, Dennis Brown wrote: > > > > > >> On May 2, 2005, at 10:25 AM, Geoff Canyon wrote: > >> > >> > >> > >>> I'm not sure how to catalog Forth, but it's not > OO (inherently -- > >>> there are OO implementations). It's procedural, > certainly, but > >>> the inherent stack gives it a definite > functional feel. > >>> > >>> > >> > >> Forth is not really a high level language any > more than assembler > >> is. It is an alternative machine language based > on a double stack > >> architecture. There have been hardware > implementations of Forth > >> as the native machine instruction set. When > emulated, the "Code" > >> just consists of a list of addresses to the > actual machine code > >> for the native functions, or addresses of > "higher level" defined > >> function (uses a flag bit to tell which). This > makes it execute > >> much faster than "byte code". You can implement > a higher level > >> language within the syntax of Forth because of > its extensible > >> nature. "Words" are defined from other words in > an interpretive > >> environment. Because of the double stack > architecture, data > >> arguments are passed and returned on one stack > and return > >> addresses are in the other stack. It makes a > very efficient and > >> powerful architecture for developing real time > machine controllers > >> with a tiny amount of memory. You are free to > define "words" that > >> implement an OO environment if you choose. You > could even create > >> Rev using this as the lower level "P code", or an > operating system > >> for that matter. > >> > > > > I understand how Forth works. I'm just not sure > how I would > > categorize it. On further reflection, I would say > that Forth is > > functional in about the same way that Revolution > is Object- > > Oriented. In other words, loosely. ;-) > > > > I disagree that Forth is no more high-level than > assembler is. The > > built-in extensibility of Forth syntax makes it > much more than just > > a convenient way of handling machine language. > > I was referring to the "native" instruction words as > being like > assembler. In fact now days, microprocessors like > the G5 etc. have > much higher level functionality than Forth. Just as > you can write > macros in assembler that implement a pseudo higher > level language of > your design, Forth gives the same ability in a very > convenient > defined way. I liked Forth a lot twenty years ago > when I was playing > with it. If one were to redesign it again today, a > much more robust > set of native words could be created for modern > microprocessors and > methods. But I have found that the UI is really 90% > of programming > these days, and for that you can't beat Rev. I just > want fast fixed > type array processing for the other 10% of the > program with a > seamless interface between the two. Rev is plenty > fast for most > stuff, but an order of magnitude too slow for the > array stuff. > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Internet Time
As I said in my previous post, if you do:
convert the internet date to seconds
it doesn't account for the timezone. However, the
following rev construction:
the last word of the internet date
gives you the correct offset to GMT. Here in
Cambridge, MA, I get '-0400' which is correct since
both Cambridge and London are on DST (local standard
time + 1 hour).
I must therefore add 4 hours (and zero minutes) worth
of seconds onto my local time (taking account of the
sign of the offset).
The complications arise in knowing which countries are
currently using DST and which are not, especially
since even the countries that do use it, do not all
"spring forward" or "fall back" on the same day.
There are databases online that list which countries
use DST and when they change. Perhaps using a cunning
HTTP script, somebody could create a "World Time
Stack" ;-)
Best
Gordon
--- Mikey <[EMAIL PROTECTED]> wrote:
> Expanding on this thought, I don't know off the top
> of my head how you
> would do this, but using the web features of RR, you
> could perhaps use
> the PHP function date to get your offset. In this
> case it would be
> date("Z"), which should return the seconds offset
> from GMT.
>
> Oh, and once again I forgot to add the tao blog to
> the sig. I'm such an idiot.
> --
> 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
>
http://lists.runrev.com/mailman/listinfo/use-revolution
>
:: Gordon Webster ::
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
Frozen Accidents
IMHO, the current state of the OS market for personal computers lends considerable weight to the point that Dan is making. There aren't many, even amongst Windows users, who would seriously argue that Win is a "better" OS than Apple's OSX (myself included). But until the advent of the iPod, Apple had made one marketing misstep after another that eroded their user base, causing fewer people to provide support and software for the Mac, further eroding their user base, causing fewer and fewer and so on and so on. Below some critical threshold, even the "better" product gets used by fewer and fewer people just because it started to be used by fewer and fewer people, in a self-sustaining cycle that's hard to break out of. If the greater computing infrastructure evolves sufficiently around one product to the detriment of others, that product becomes more and more the "best" product for working within that infrastructure, in an almost circular and self-fulfilling fashion. There's are interesting parallels to this in the life sciences. Biologists call them "frozen accidents". How did the four bases in DNA come to be an almost universal genetic code? How did the 20 amino acids that they code for get chosen? For example, why is gamma-aminobutyric acid (GABA), a very common amino acid in a vast range of living organisms, not coded for? The internet was a sea change in the computing "ecosystem" that opened the door for alternative technologies when Microsoft were unable to see the writing on the wall. Apple must probably pray for another such shift and for the ability to be the first to see it coming. They did it for "music on demand", but can they do it for computers? My $0.10 Best Gordon --- Dan Shafer <[EMAIL PROTECTED]> wrote: > Well, Lynn, while I wouldn't disagree with your > perspective, I would > nonetheless argue that a world-class technology > product with few > marketing resources and no legal clout will get > buried by a > competitive product which, though inferior, has more > marketing money > and/or legal backing 99 times out of 100. > > While it's certainly true that you can spend gobs > and gobs of money > and still end up with a total failure, it's less > likely than having a > total failure from *lack* of marketing resources. > And given a market > with two products characterized as I did above, the > one with more > marketing will beat the superior product with > mind-numbing regularity. > > > On May 3, 2005, at 10:28 AM, Lynn Fredricks wrote: > > >> Amen. > >> > >> It's never about the technology. I've seen so > many great > >> technologies buried by inferior products that had > either more > >> marketing money or better lawyers than I've seen > succeed. > >> > > > > Technology isnt usually what wins the day, but > neither is it > > entirely money > > or lawyers, but strategic use of both. Marketing > (and sales) isnt a > > big > > packaging machine that vendors throw money into, > as its very > > possible to > > spend gobs and gobs of money and still end up with > a total failure. > > > > Best regards, > > > > Lynn Fredricks > > President > > Proactive International, LLC > > > > - Because it is about who you know.(tm) > > > > > > > > ___ > > use-revolution mailing list > > use-revolution@lists.runrev.com > > > http://lists.runrev.com/mailman/listinfo/use-revolution > > > > > > > > ~~ > Dan Shafer, Co-Chair > RevConWest '05 > June 17-18, 2005, Monterey, California > http://www.altuit.com/webs/altuit/RevConWest > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Internet Time
Dear Revvers Maybe I'm missing something, but when I convert an internet date like this "Tue, 3 May 2005 14:00:44 -0400" into seconds, it doesn't take account of the time zone component. So for example, if I edit the internet date string to alter the time zone, (e.g. like this "Tue, 3 May 2005 14:00:44 -0300")the "convert" operation gives exactly the same result in seconds. Now I know that it would be a piece of cake to simply subtract an hours worth of seconds for each hour shift in the time zone field, but before I go ahead and write my "AbsoluteWorldTime" function, I just want to be sure that this doesn't already exist via some other means within Rev. Basically I want a time function that is "time-zone aware" and can figure out what order events occurred in, even if they took place in different time zones. Maybe I didn't read the manual thoroughly enough, but I find it hard to believe that this function doesn't already exist in rev, especially for internet applications that must work with different time zones. Am I just being a big doofus here? Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Adding text to fields
Dear Revvers This is probably a very simple question, but when I'm adding text to a scrolled field, how do I make it autoscroll down so that it's always showing the last line of added text? Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Python and Rev
And the proof Dan, that this advertising works ... this is exactly how I came across rev in the first place! Furthermore (irony of ironies) ... I was using Pythoncard heavily at the time and wondering if there were any other Python GUIs out there when I stumbled across this very same advertisement. When I logged on to the rev forum for the first time you can imagine my surprise at discovering that this new development platform also had its own Dan Shafer! It seems there's no escape, they have Dan Shafers everywhere ... Gordon Dan Shafer wrote: I typed "python GUI application" into a search engine (A9.com, which uses google) today while doing some research for a client. Guess what the first sponsored link that came up was? Build your own gui applications, interfaces & more. Free trial! dreamcard.runrev.com :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: ARE YOU SERIOUS REV TEAM? MAJOR SCRIPT EDITOR ISSUES
Dear Peter See what a great group of friendly and helpful people there are using Rev! I would wager that on a lot of lists, your posting would have raised hackles and prompted a lot of less than helpful responses. This list is really one of the strengths of using Rev and if you have any problems, there's always this community of incredibly smart, friendly and helpful people to help you out - I see it happen every day. It sometimes feels like having really good 24/7 tech support - come to think of it, I sometimes wonder when these guys actually sleep! If I were you Peter, I'd give Rev another chance and experience for yourself the excellent support you get from the Rev community by letting them help you work through the problems you described. Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OT: Analyzing competitors - In this case Real Software
Re: rev and RB I like both languages, but I would wager that any rev user that ever attempted to write a math/science based applications in rev, quickly noticed certain significant shortfalls in it. The lack of a real array type or the lack of any decent support for drawing your own graphics, to name but a couple. Rev of course wins hands down if you're building a multimedia or network based application or designing a really wizzy user interface. Transcript is great for high level manipulations of fairly complex objects and if the task/subtask you need is already "pre-cooked" in the Transcript recipe book, you're miles ahead of the competition who are crawling on their hands and knees by comparison. With regard to Rev externals though, I think Runtime are really making a significant marketing gaff by not improving the ability of rev apps to speak to the wider world of code libraries. Consider this - rev is by comparison to other development platforms, a niche market that needs to grow and gain in popularity to really establish itself as a serious alternative. Yet as a rev user, I either have to write tedious wrappers to external libraries or reinvent the wheel. For example, if I want to render objects in 3D, I am effectively cut off from all the wonderful tools (such as OpenGL) that people have already developed for this purpose and might seriously consider looking elsewhere for a platform that plugs me in to this world without me having to write a bunch of C code. Seriously - rev makes it difficult for me to capitalize on the huge collective effort of the software community at large and any gains I might make in writing fewer lines of Transcript compared to say Basic, must be weighed against the purgatory of having to write wrappers for externals in C - which rather defeats the object of using a high level language like Transcript in the first place! So come on Runtime, how about something like: start using external "fabulousexternal.dll" No C, no damn wrappers, just the Transcript we love to speak - just look at the Python "ctypes" for an example of how it could be done. Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Trial software and registering
Trevor makes a good point. Mikey's users might get thoroughly cheesed off if they found they couldn't use their software away from their network connection. Verifying the license each time over the network might also introduce an unnacceptable delay in the startup of the application. To use the "phone home" approach effectively, the application could cache the results of the last license validation along with it's date and time. It could then allow the user to work for a given number of sessions (or a certain elapsed time) without requiring license validation, but during each session, in the background it would silently check the existence of a network connection and update the license validation whenever possible, resetting the "time since last license check" clock each time. If the user used the application for some extended period without revalidating the license and started to get near the allowed limit of sessions (or time elapsed) since the last license validation, the application could warn the user of this when it was launched - something like "You only have n more sessions/days left before this application will require revalidation fo your license". Hope this is helpful Best Gordon --- Trevor DeVore <[EMAIL PROTECTED]> wrote: > On Mar 16, 2005, at 9:18 AM, Mikey wrote: > > > One of the nicer ways to do this now is to have > your application > > "phone home" via a TCP/IP connection. To activate > the software, the > > software has to be able to connect with your > server. Every launch it > > has to reconnect to ensure that it still has > privileges. At the end > > of the time period, it gets notification that its > time is up and > > that's it. > > > > This keeps people from rolling dates back on their > systems. > > But what if I want to use the software on my laptop > with no internet > connection (on a plane, etc.)? I usually try out > new software under > these conditions. It really isn't a problem to > connect the first time > to activate the software but connecting on every > launch would be a > problem. > > > -- > Trevor DeVore > Blue Mango Multimedia > [EMAIL PROTECTED] > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: New Externals...
Dear Frank
I know about Mono and the like, but I said "going to
be cross platform" in the sense of it being a mature
technology for all platforms.
I believe there are still some minor differences
between the Mono CLR and class libraries and the
"official" MS versions (mostly centered around the GUI
components I believe).
BTW: I think the MS team did a great job with C#,
which has a wonderfully clean, consistent and
uncluttered syntax. I have found that the only real
learning curve for C# (if you've programmed in Java or
C++) is in learning the new names of all the base
classes.
Best
Gordon
--- "Frank D. Engel, Jr." <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> "Going to be" cross-platform? Check here:
>
> http://www.mono-project.com/
>
>
> Hmm... what about a Rev runtime for .net? I think
> .net will be
> available for Windows Mobile soon (is it already?),
> so a .net runtime
> version would automatically provide support for
> software on Windows
> Mobile, Windows itself (2000+, correct?), and
> apparently Mono-supported
> platforms as well (various flavors of Linux, plus OS
> X more or less --
> more soon, I hope) -- and possibly even future
> platforms which don't
> even exist yet!
>
>
> On Feb 3, 2005, at 2:01 PM, Gordon Webster wrote:
>
> > Dear Chipp
> >
> > An "externals external" would be great. Something
> that
> > could expose the functions and type requirements
> in
> > standard windows dlls or *nix .so shared library
> (and
> > their OSX equivalents).
> >
> > As is already the case in C#, Java or some of the
> > flavors of Basic, you could then import these
> > functions directly into transcript something like
> ...
> >
> > externalHandle =
> altuitUseExternal("mylib.dll")
> >
> > IMHO runrev really needs a more accessible
> interface
> > to the vast wealth of shared libraries that exist
> out
> > there, without having to write wrappers for every
> new
> > library you want to use. I would love to be able
> to
> > use OpenGL from within rev for example and create
> > interactive 3D viewports on my rev stacks.
> >
> > OT: Wouldn't it be great to have .NET bindings for
> > rev, especially since it seems that .NET is going
> to
> > be a genuinely cross-platform runtime (please no
> Java
> > Vs. .NET flames or any other anti-MS invective -
> I'm
> > no great fan of MS, but it seems that they've
> finally
> > done something right with .NET)
> >
> > Best
> >
> > Gordon
> >
> >
> >
> >
> > --- Chipp Walters <[EMAIL PROTECTED]> wrote:
> >
> >> The recent altBrowser bundle offering was a
> success
> >> thanks to RR users
> >> all over the world. A personal thank-you from
> Chris
> >> and I for all of
> >> your support. And thanks to RunRev for an
> excellent
> >> job of helping to
> >> get the word out.
> >>
> >> We're currently working on a free upgrade for
> >> altBrowser (both Mac and
> >> PC) which we hope will be out next week.
> >>
> >> So, this got Chris and I thinking about other
> >> externals. Before we
> >> started, we wanted to get some feedback from RR
> >> users as which externals
> >> you would like to see. Keep in mind, they need to
> be
> >> cross-platform, and
> >> they need to have some sort of mass market
> appeal.
> >>
> >> Here are a couple of ideas we have:
> >>
> >> 1) USB external support. That about says it all
> >> right there!
> >>
> >> 2) Image Effects library. The ability to
> >> import/export many different
> >> formats, apply special effects like dropped
> shadows,
> >> borders, sharpen
> >> and blur and more.
> >>
> >> If you have any other ideas, please let us know,
> >> either on this list or off.
> >>
> >> Thanks again!
> >>
> >> -Chipp Walters
> >> Altuit, Inc.
> >>
> >>
> >> --
> >> No virus found in this outgoing message.
> >> Checked by AVG Anti-Virus.
> >> Version: 7.0.300 / Virus Database: 265.8.4 -
> Release
> >> Date: 2/1/2005
> >>
> >> ___
> >> use-revolution mailing list
> >> use-revolution@lists.
Re: New Externals...
Dear Chipp
An "externals external" would be great. Something that
could expose the functions and type requirements in
standard windows dlls or *nix .so shared library (and
their OSX equivalents).
As is already the case in C#, Java or some of the
flavors of Basic, you could then import these
functions directly into transcript something like ...
externalHandle = altuitUseExternal("mylib.dll")
IMHO runrev really needs a more accessible interface
to the vast wealth of shared libraries that exist out
there, without having to write wrappers for every new
library you want to use. I would love to be able to
use OpenGL from within rev for example and create
interactive 3D viewports on my rev stacks.
OT: Wouldn't it be great to have .NET bindings for
rev, especially since it seems that .NET is going to
be a genuinely cross-platform runtime (please no Java
Vs. .NET flames or any other anti-MS invective - I'm
no great fan of MS, but it seems that they've finally
done something right with .NET)
Best
Gordon
--- Chipp Walters <[EMAIL PROTECTED]> wrote:
> The recent altBrowser bundle offering was a success
> thanks to RR users
> all over the world. A personal thank-you from Chris
> and I for all of
> your support. And thanks to RunRev for an excellent
> job of helping to
> get the word out.
>
> We're currently working on a free upgrade for
> altBrowser (both Mac and
> PC) which we hope will be out next week.
>
> So, this got Chris and I thinking about other
> externals. Before we
> started, we wanted to get some feedback from RR
> users as which externals
> you would like to see. Keep in mind, they need to be
> cross-platform, and
> they need to have some sort of mass market appeal.
>
> Here are a couple of ideas we have:
>
> 1) USB external support. That about says it all
> right there!
>
> 2) Image Effects library. The ability to
> import/export many different
> formats, apply special effects like dropped shadows,
> borders, sharpen
> and blur and more.
>
> If you have any other ideas, please let us know,
> either on this list or off.
>
> Thanks again!
>
> -Chipp Walters
> Altuit, Inc.
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.4 - Release
> Date: 2/1/2005
>
> _______
> use-revolution mailing list
> use-revolution@lists.runrev.com
>
http://lists.runrev.com/mailman/listinfo/use-revolution
>
=
:: Gordon Webster ::
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: A Collaboration on Shafer's Books?
With regard to making the time-consuming work of producing rev/Transcript programming books financially viable, how about something like this ... A 2-tiered rev wiki would be set up, one tier of which would be open access (gratis) for all registered rev users - the other would be available by yearly subscription and compiled/mediated by Dan (and any other gurus he might need to help him). Here's how it could work ... Any registered rev user could contribute an article to the open wiki. This could be as short as a Q&A about how to place an icon in a button with accompanying code snippets, or as long as an in-depth article about the rev mesage path, XML parsing, the use of sockets etc. etc. Any other registered rev user could read these articles and even edit them to correct errors or ambiguities, or just comment on them and/or polish them up. Naturally this open wiki would be mediated by some of the rev community in the same way that other wikis are, to prevent vandalism or abuse. All submissions to the open wiki would be subject to an agreement on the part of the authors that the submitted material would be posted on the open wiki as a resource for everyone to read and edit as required, in return for the right on the part of the wiki administrators to incorporate the material in whatever form they see fit, into commercial publications. The second tier of the wiki would be more book-like, with articles and code examples organized into comprehensive "chapters" that cover particular areas of rev development. These would have been verified and edited by Dan (and his team) and would/could combine the raw materials from the "open wiki" with more conceptual material and background into the subject, with illustrative figures and tested code examples. This part of the wiki would be accessible by subscription only and although it would not be editable by anybody other than Dan's team of gurus, it could still be in a wiki format to enable Dan and his team to collaborate on the compiling and editing work, or to solict the subscriber's comments on the work. Some limited time access to the "revBbook wiki" could be also be included for purchasers of Rev products to get them going with rev and Transcript. After this initial period (say 3 - 6 months), they would also have to pay a subscription. As a new user to rev, I would love to have been able to have access to something like this. Like the chapters in Dan's book, the revBook wiki would offer a conceptual view of rev and Transcript to show a new user the landscape and get him/her started with good rev/Transcript programming practices. This could also address the common rev newbie gripe about the lack of structured documentation - perhaps making rev more popular in the process, leading to more subscribers to the revBook wiki, making rev more populkar, leading to ... More sophisticated rev users tackling some new project would find articles that introduce them to advanced programming concepts like cryptography, internet authentication, the use of externals etc. The "value" in the revBook wiki would be the access to the organised and authoritative pedagogical "chapters" of the kind that Dan has in his books - perhaps with the option to print them as pdfs. The open access wiki would still be a useful resource, but more like the kind of searchable FAQ stuff that rev users already have access to - but greatly expanded. The hook for getting people to continue subscribing would be the ongoing updates and expansion of the revBook wiki. Unlike a book, it could be updated regularly and could more more closely reflect and respond to the rev community's current issues/obsessions/neuroses. Subscribers to the revBook wiki could even contribute to its evolution e.g. by voting on the chapters that they would most like to see. To improve the fiscal rewards for Dan (and his team), runrev could perhaps offer yearly Revolution upgrades bundled with yearly subscriptions to the revBook wiki. Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The real Challenge for every development platform
As a new user to rev and in spite of the fact that I like it very much, I could see how potential users might be deterred by the lack of a clear roadmap for getting started with Transcript and the whole Hypercard thing. The manuals are well written and replete with detail but it's hard to see the wood for the trees in terms of finding out what you need to know to build good applications with rev. I had to stumble across an article by Richard Gaskin before I understood what the message path is and how it works and somebody else on the mailing list explained to me the advantages of building rev apps from a single standalone splash screen and then dynamically loading the other stacks. The mailing list is a superb resource and the rev community is incredibly helpful, but the information a new user needs is so spread around that finding what you need to know is like panning for gold. Dan's book certainly goes some way to addressing these needs but I think we need more of that kind of pedagogical approach to rev for new users (BTW Dan - I have a fistful of grubby dollars with your name on them for when volumes II and III appear :D) Also, for a development environment that is very GUI centric, there could be better tools for the use of externals. I really like Python because virtually any kind of activity I might need code libraries for, is already catered for and I don't have to reinvent the wheel (e.g. math, cryptography, 3D graphics, data visualization, bioinformatics, COM, email etc. etc.) If the rev community isn't currently large enough to create this, making it easier to use other people's libraries would go some way to addressing this problem. Somebody on this list expressed the fear that critical posts might give newbies to the list a negative or over-critical view of rev, to which I would reply - I think rev is great and my gripes (if you can call them that) are based upon the fact that I like rev so much that I'd like to be able to use it for EVERYTHING! Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Option/combo menus crashing Rev
Dear Revolutionaries As a test I reduced the number of items in each menu so that all items could be displayed in the dropdown view, without scrolling. Now the menus are stable and no amount of clicking in them or selecting items causes rev to crash. The problem seems to be the scrollbars that are needed when there are more items than the dropdrown can display. Is there some scrollbar timimg or delay parameter that can be reset to make the behavior of these menus more stable or are combo/option menus with scrollbars inherently buggy? I guess it could also be some special character that is no longer loaded into the menu list. Is there a problem with certain characters in menus (like @ for example)? Best Gordon --- Gordon Webster <[EMAIL PROTECTED]> wrote: > Dear Revolutionaries > > Working on WinXP with rev 2.5 I have created an > option > menu and a combo box on a substack to set the > fontname > and fontsize respectively, of a scrolling text > window > on the main stack. > > They both work just fine - sometimes ... > > but if I click on them more than once or scroll up > and > down in them too much, they freeze and I get a "Not > Responding" warning followed by a delay and then the > rev runtime crashes completely. > > Am I doing something stupid? > > Here is the code I use in the preOpenStack handler > to > set them up: > > on preOpenStack > put the fontnames into tfonts > sort lines of tfonts > put tfonts into button "Input Fonts" > repeat with fsize = 8 to 48 step 2 > put fsize & cr after fsizes > end repeat > put fsizes into button "Input Font Sizes" > set the menuHistory of button "Input Fonts" to > lineOffset(the CommandWindowFont of stack > "myStack",button "Input Fonts") > set the menuHistory of button "Input Font Sizes" > to > lineOffset(the CommandWindowFontSize of stack > "myStack",button "Input Font Sizes") > end preOpenStack > > This is really weird. Has anyone had any similar > prolems with combo/option menus? > > Best > > Gordon > > > ===== > :: Gordon Webster :: > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Option/combo menus crashing Rev
Dear Revolutionaries Working on WinXP with rev 2.5 I have created an option menu and a combo box on a substack to set the fontname and fontsize respectively, of a scrolling text window on the main stack. They both work just fine - sometimes ... but if I click on them more than once or scroll up and down in them too much, they freeze and I get a "Not Responding" warning followed by a delay and then the rev runtime crashes completely. Am I doing something stupid? Here is the code I use in the preOpenStack handler to set them up: on preOpenStack put the fontnames into tfonts sort lines of tfonts put tfonts into button "Input Fonts" repeat with fsize = 8 to 48 step 2 put fsize & cr after fsizes end repeat put fsizes into button "Input Font Sizes" set the menuHistory of button "Input Fonts" to lineOffset(the CommandWindowFont of stack "myStack",button "Input Fonts") set the menuHistory of button "Input Font Sizes" to lineOffset(the CommandWindowFontSize of stack "myStack",button "Input Font Sizes") end preOpenStack This is really weird. Has anyone had any similar prolems with combo/option menus? Best Gordon = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: copy protection
Dear Byron First off, I would say that 22 out of a class of 33 isn't bad at all - if most students had decided to share a copy of your software and work together in pairs, you might have expected only 50% (or even less if they worked together in larger study groups). I have polled this list about software protection issues and have received some great advice from people who've obviously thought about it a great deal more than I have. I'll bet the essence of the advice you'll get will revolve around the question of how much time you'll want to spend to net that extra 30% of non-payers instead of spending that time improving your software (or developing your next product). If you are interested, I have experimented in rev, to see what kinds of metrics I can extract that can uniquely identify a user's computer. One obvious approach for Windows is to use the serial number of the user's Windows distribution which can be extracted from the registry. This would mean that a thieved copy would not run on another students computer unless they had also cloned the Windows OS as well (or tinkered with the registry which is dangerous and a deterrent for most). I am not that familiar with the MAC OS, but I imagine there is some similar registration code that identifies a user's OS license. In your case, you would have to provide an authorization code for each of your users, but for 70 people it is feasible. I am curious to know what people do for distributions to larger numbers of people. Perhaps some of the gurus on this list would be willing to share their expertise for the current generation of newbs like myself - this topic affects us all as rev developers and I would love to know what approaches people are using (Kee, I still owe you an email about this, I apologise for not having gotten back to you - I haven't forgotten :-) Best Gordon --- Byron Turner <[EMAIL PROTECTED]> wrote: > This week we got the results of the first adoption > of our flagship > product Created Equal: Sex and Gender. The > professor is using it as a > text in a class of 33. Only 22 students bought it. > While a couple > students are sharing materials, the rest I fear is > theft. In 2 weeks > it will be used in another class of 70-100. Any > suggestions about how > to go about copy protecting our product. (It ships > on 2 CDs or a > single DVD in case that's relevant) > > Byron > > H. L. Mencken: > > As democracy is perfected, the office of president > represents, more and > more closely, the inner soul of the people. On some > great and glorious > day the plain folks of the land will reach their > heart's desire at last > and the White House will be adorned by a downright > moron. > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Help! My Rev Runtime Docs Have Died!
Dear Revolutionaries After ignoring this problem and working with rev for a while, closing and saving a few stacks and reopening rev a few times, this problem eventually went away. Bizarre. Has anybody else had these probs with the doc window? G. --- Gordon Webster <[EMAIL PROTECTED]> wrote: > Dear Revolutionaries > > I have a bizarre problem with my Rev Runtime. I am > now > unable to open the rev documentation window in a > normal mode. If I open it with the "Documentation" > button on the rev toolbar, it opens minimized and > refuses to come into view when you click its button > in > the windows toolbar. If I right click on it, I can > only bring it up maximized, but when I try to > restore > it to normal (sizeable) mode, it just minimizes > again. > > I am using WinXP and have tried logging off and on > again, but to no avail. I'm not sure what I did to > cause this. Is this bug reported? > > Best > > Gordon > > > = > :: Gordon Webster :: > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Help! My Rev Runtime Docs Have Died!
Dear Revolutionaries I have a bizarre problem with my Rev Runtime. I am now unable to open the rev documentation window in a normal mode. If I open it with the "Documentation" button on the rev toolbar, it opens minimized and refuses to come into view when you click its button in the windows toolbar. If I right click on it, I can only bring it up maximized, but when I try to restore it to normal (sizeable) mode, it just minimizes again. I am using WinXP and have tried logging off and on again, but to no avail. I'm not sure what I did to cause this. Is this bug reported? Best Gordon ===== :::::: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: 3D Object Viewer (was: Open-source: Presentation software)
A 3D object viewer for rev, now you're talking! My personal dream would be to see a set of openGL bindings for rev that would allow you to create a 3D viewport window on a rev stack - perhaps embedded in an image object the way Chipp's altBrowser is. BTW: OpenGL is cross-platform too :-) Gordon --- "Lynch, Jonathan" <[EMAIL PROTECTED]> wrote: > What kind of objects does your presentation software > use? By that, I > mean, I assume it does fields, pictures, audio, and > video. Any other > types of objects? I have been thinking that a 3-D > object viewer would be > a great object. (I hope no one objects to my overuse > of the word > 'object' here, which, objectively speaking, I am > definitely overusing). > > I also think a 3-D animated character generator that > speaks to the > viewer, using whatever text is sent to it from a > handler, would be > nifty. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Mark > Talluto > Sent: Thursday, January 06, 2005 2:24 PM > To: Revolution use Revolution > Subject: Open-source: Presentation software > > Some time ago I created a commercial product called > Multimedia > Generator. This is presentation software that was > designed for the > education market. We ended up getting users in many > different markets > over time. The software is pretty easy to use, but > does lack some > polish and features from talented folks like you. > > If you are interested in joining an open-source > effort to make a better > presentation tool using Rev, please join the group I > have created at > Yahoo:<http://groups.yahoo.com/group/mmgen/> > > Thanks for taking a look! > > -- > Best regards, > Mark Talluto > http://www.canelasoftware.com > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Open-source: Presentation software
Mark I checked out your Yahoo groups page - the project sounds potentially interesting but it's hard to know how interesting in the absence of more info. Best Gordon --- Mark Talluto <[EMAIL PROTECTED]> wrote: > Some time ago I created a commercial product called > Multimedia > Generator. This is presentation software that was > designed for the > education market. We ended up getting users in many > different markets > over time. The software is pretty easy to use, but > does lack some > polish and features from talented folks like you. > > If you are interested in joining an open-source > effort to make a better > presentation tool using Rev, please join the group I > have created at > Yahoo:<http://groups.yahoo.com/group/mmgen/> > > Thanks for taking a look! > > -- > Best regards, > Mark Talluto > http://www.canelasoftware.com > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: altBrowser
Dear Chipp Now I understand - the same folder as the rev runtime application, NOT the demo application! altBrowser looks really cool, I can't wait to get into it. Thanks so much for your help! Gordon --- Chipp Walters <[EMAIL PROTECTED]> wrote: > Hi Gordon, > > You need to put a copy of the external in the same > folder as the > Revolution Application when editing in the IDE. I'll > add this to the > FAQ. Thanks for purchasing altBrowser :-) !! > > Also, the extra special pricing expires on the 19th > of January. Those of > you who have purchased a previous version of > altBrowser can get a > discount code from Heather. > > best, > > Chipp > > Gordon Webster wrote: > > What am I doing wrong? > > > > I just downloaded Chipp's altBrowser, and I have > the > > demo stack and the dll in the same directory on my > PC. > > When I run the stack though, anything I click on > the > > demo stack gives me a "handler not found" error, > as if > > the dll isn't being seen. > > > > I believe I have the dll in the same directory as > the > > application (which I presume to mean the demo > stack in > > this case) - am I missing something? > > > > I'm sure I'm being a big doofus here. > > > > Best > > > > Gordon > > > > ___ > > use-revolution mailing list > > use-revolution@lists.runrev.com > > > http://lists.runrev.com/mailman/listinfo/use-revolution > > > > > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
altBrowser
What am I doing wrong? I just downloaded Chipp's altBrowser, and I have the demo stack and the dll in the same directory on my PC. When I run the stack though, anything I click on the demo stack gives me a "handler not found" error, as if the dll isn't being seen. I believe I have the dll in the same directory as the application (which I presume to mean the demo stack in this case) - am I missing something? I'm sure I'm being a big doofus here. Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Externals written in not(c)
Dear Dar Thanks for the response. Yes, it's mostly matrix-type math for 3D systems that I want to do and some of the calculations will take some time to complete, even as native code. I'm not clear from your reply though, what it is I actually need in my DLL ... let's say I just want to write a single test function for multiplying two numbers together - I will export this in my DLL, but what else do I need? > You need > to export a single function that provides all the > calling info. Could you elaborate? Best Gordon --- Dar Scott <[EMAIL PROTECTED]> wrote: > > On Jan 4, 2005, at 3:29 PM, Gordon Webster wrote: > > > It > > clearly says that you can write an external in any > > language of your choosing provided that the > > compilation supports certain features that are > > essential for the rev interface. > > Yes, it can be done if your dll can handle the > C-style calls. You need > to export a single function that provides all the > calling info. > > However, it might be easier to create a glue dll. I > do that for C++. > > If you're just doing some math, you might want to > consider just doing > it in C. > > There is an overhead for external calls, so you want > to do many > primitive math operations per call. > > Rev is pretty fast at math. You might want to run > some tests to see if > this is worthwhile. Maybe it will be in some > complicated formulas or > in matrix operations. > > Dar > > ** > DSC (Dar Scott Consulting & Dar's Lab) > http://www.swcp.com/dsc/ > Programming Services and Software > ** > > _______ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Externals written in not(c)
Dear Revolutionaries I have downloaded the externals SDK from the rr website and I have trawled through the docs. It clearly says that you can write an external in any language of your choosing provided that the compilation supports certain features that are essential for the rev interface. The docs describe in great details what is needed to create an external in C, but what if I was doing it in another language whose compiler can produce the kind of standard "vanilla" DLLs that rev needs? I can see that I need something called XTable that defines the separate XCMDs and XFCNs, but I can't figure out how much of the C header files I need just to do the simple "feasibility study" of writing a DLL that say - exports a simple function that reads 2 params, multiplies them together and returns the result. I guess what I'm after is a basic minimal list of features that rev needs in my DLL to be able to do this simple test - just enough to get me started and see how it all works. I would like to understand the process by which the rev engine and the DLL "shake hands", i.e. initiate their interaction and share data. I was thinking of trying a dialect of Basic which can produce native DLLs - anybody out there have any insights? Can rev read/write data in specific areas of memory? I am presuming that sharing memory between processes is a no-no and that all the rev gurus on this list are muttering and shaking their heads in disapproval right now at the very mention of it. I ask because many languages have the capability to allocate and read/write in specific areas of memory and it is another way to communicate between processes. I'm not even sure that rev can do this - can it? My goal in all of this? Having natively compiled scientific/math libraries that run at blazing speed behind my rev app, doing the donkey work on the numbers while rev seduces the user with its enchanting interface. All help would be greatly appreciated. Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic
--- Michael D Mays <[EMAIL PROTECTED]> wrote: > > What is running so slow in Revolution? > I think that rev is great, but there are certain areas in which its functionality is rather limited. Speaking for myself, I am involved in a lot of scientific computation and I would love to be able to use rev for more than just the user interface. Yes, I could use externals or you could argue that rev is UI/multimedia-centric and not intended for serious scientific computing, but does that have to mean that it could never be? Here's my little wish-list of rev enhancements that would make it more amenable for numeric/scientific computing ... - Arrays of arrays (of arrays, of arrays ...) - The option to create "typed" stacks that could be either natively compiled or extensively bytecode optimized (a la Psyco optimizer for python) - More graphics abstraction - built-in 2D and 3D mapping and transformations and a richer set of built-in graphic objects such as splines, beziers etc. - Easier interfacing to externals (DLLs, COM objects etc. etc.) Here's to the evolution of Revolution! Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: RunRev vs RealBasic
I really like what Frank is contemplating ... It would be ganz wunderbar if rev users had the option to create stacks that were destined to be natively compiled as externals. I guess that rev would have to insist on some sort of type declarations in such a case to get optimal performance, but this could be done only in the stacks that are to be compiled, allowing rev users to keep a flexible, typeless environment except for the parts of the app that needed compiled performance. Naturally, the runtime would produce all the necessary boilerplate code for the interface between the rev runtime+bytecode app and the new external :-) BTW: I purchased rev because I was tired of working on my hands and knees pushing heavy boulders with my nose, writing in C (or doing the same with a hippo on my back, writing in C++). Isn't there some way that rev could free us from the hell of having to write externals in C? I also use PowerBasic, which allows you to declare the functions exported by a DLL in your code and then simply use them as if they were an "Include". How about it rr - something like: revDeclareExternal someFunction in "C:\something.dll" Wouldn't that be sweet :-) Best Gordon --- "Frank D. Engel, Jr." <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Dec 31, 2004, at 5:04 PM, Chipp Walters wrote: > > > > > On Fri, 31 Dec 2004 2:40 pm, Ken Ray wrote: > >> That's one of the beauties of Rev... data can be > stored *inside* the > >> stack > >> files, either as data in fields that have been > saved, or as custom > >> properties that are stored with the stack itself. > > > > A great point. I recently was able to create a > compressed, encrypted > > binary data storage file using a stack and a > single line of code. This > > data file stores text data along with imades in 3 > different formats. > > > > This data file is actually a stack with no > business logic and is > > opened by my app invisibly and data selectively > moved to the gui, > > edited there and then moved back to the inv stack > to save. Talk about > > simple. Doing the same in VB would be very > complicated. I imagine RB > > too. > > > > Btw, regarding speed issues, I think there have > been a number of speed > > coding challenges between RB and RR with no > conclusive winner. Perhaps > > Frank can be more specific with regard to areas he > feels RR runs slow? > > Again, CPU-Intensive routines, such as processing > each byte of a long > string individually. Most of the more "stock" > operations run quite > well in Rev, but when doing intensive, custom > CPU-intensive routines, > it generally pays to write an external, particularly > when targeting > older hardware. > > > Also, last time I looked, RR compiles scripts 'on > the fly' like Java. > > Didn't know RB was a compiler. Must be tough on > edit/compile/run/debug > > cycles. Perhaps it's an interpreter like RR and > compiles during > > runtime? I don't know. > > Rev "compiles" scripts into a bytecode format which > is later > interpreted by the runtime environment. Faster than > a "pure" > interpreter, but still slower than compiled code. > > Java code gets run through a compiler which > translates it into a Java > bytecode. That bytecode is then interpreted at > runtime, much as is Rev > code. However, some Java runtime environments > (JREs) will actually > "recompile" the bytecode into native code for the > platform. This is > slower than compiling code directly for the > hardware, but adds the > write-one-run-anywhere flexibility of Java (and to > some degree of Rev), > and the result of this (sometimes referred to as > "Just-In-Time" > compilation) is much closer in speed to native > compiled code. > > Real Basic is a true compiler, which translates code > into instructions > for the actual hardware on which it is run. This is > the fastest > solution, since the computer hardware does virtually > *all* of the work > of figuring out how to execute each instruction, and > there is no > runtime translation step. However, this also locks > the compiled > version to the platform for which it was compiled > (similarly to a > standalone produced by Rev), and it causes a > Compile-Run-Debug cycle to > be introduced. Visual Basic (M$ product) is also a > true compiler. > > I personally wonder what it would take to create a > true compiler for > Rev stacks? Obviously this would introduce some > limitations on certain > operations, but for stacks which don't use those > operations, it could > substantially increase performance... > > > Best, > > Chipp > > Chipp Walters, Altuit.com > > Sent from my Sidekick > > ___ > > use-revolution mailing list > > use-revolution@lists.runrev.com > > > http://lists.runrev.com/mailman/listinfo/use-revolution > > > > > - > --- > Frank D. Engel, Jr. <[EMAIL PROTECTED]> >
Inter-process communication
Dear Revolutionaries Is it sensible/feasible to use the clipboard for communicating between rev and other processes? e.g. suppose I want to pass control to another process that does a large, numerically intensive calculation and then passes the result back to the rev app by writing to the clipboard. This assumes that the overhead of parsing the result on the clipboard is more than offset by the time saved by doing the calculation in a separate, natively compiled process. Would this be quicker than communicating using files? Is there a way in rev to get a message when the clipboard's contents change? - something like "on clipboardUpdated" Of course, using the externals SDK to access a DLL would be optimal - is there a tutorial somewhere on how to access the functions in a DLL from within rev? Would I have to write a C program to do this? Best Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Graphic Objects & Memory Use
Dear Revolutionaries I have a question or two about rev's graphic objects ... Since the rev graphic objects such as lines and shapes are objects that can have their own properties, styles etc., is there a big memory overhead in using them to create complicated graphics? What would be the best way in rev to do the equivalent of double-buffering the graphics i.e. invisibly drawing the next frame of a complex graphic in background and then displaying it? Happy New Year to you and yours. Gordon ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Setting Pixels
Dear Revolutionaries I hope you are all having a happy holiday. Mine started really well as the copy of Dan Shafer's book I had ordered, arrived the day I was leaving for the holidays :-) I have thoroughly enjoyed reading it these last few days and recommend it whole-heartedly to any fellow rev newbies (it's available on the runrev website) - so when do the next two volumes come out? Here is my question - Dan's book describes the use of the 'mouseColor' handler to get the color value of the pixel that is below the mouse - is there any way in rev, to set the value of an individual pixel? Best Gordon = :: Gordon Webster :: ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DreamCard Review-PCPLUS
I have used both VB and rev and while they both effectively do the same thing, I have to say that VB is rather gray and uninspiring by comparison. I find that the so called "cosmetic details" of a language or a development platform are in reality way more than merely cosmetic - it's like a car you drive every day wherein even the little things that niggle can eventually make your life miserable - you want the controls on the dash to look great and be easy on the eye and the doors to shut easily with a nice solid clunk, the steering wheel to feel good in your hands as you're zooming effortlessly along etc. etc. VB may have been some hot s**t in its day, but now it justs reminds me of my old Fiat. We should concede them a minor point about the rev documentation though. Yes, all the info is there - somewhere - but it's arranged more like a jigsaw puzzle than a book and when I'm trying to learn a new programming language, a book is a whole lot easier. All that said, IMHO rev wins hand down! Gordon ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: the secrets of Monks
Congratulations on "If Monks" Brian .. I have already spent several happy hours engrossed in its cloister - and newly annointed to the rev order, I will definitely download the demo stacks and try to learn from them. Gordon --- Brian Thomas <[EMAIL PROTECTED]> wrote: > > At last, the conclusion to the longest running > project in the history > of interactive media. Thanks again to everyone who > helped build the > If Monks had Macs (or Windows) library. > > Runtime Revolution has just released a stack of > scripts and tips as > to using Revolution/Dreamcard for multimedia. The > stack may not be of > much help to the wizards on this site who have been > so helpful to > over the years that I have been working on Monks. > Nonetheless, it is > a good resource for you to know about and point out > to new multimedia > developers. And the stack does share a wonderful > technique that > Jeanne A.E. deVoto worked out for me so Monks could > display life-size > (museum sized) paintings on small computer screens. > You can download > the demo/codeshare tutorial through revOnline or by > using this link: > > http://revonline.runrev.com/resources/coding/monks-demo.zip > > The two main differences between the new edition of > Monks and last > year's is that: > > 1). Sophie, our ebook reader is now compatible with > Mac OS 10.3. Also > all the ebooks have been revised and a new one > added. The new ebook > is H.G.Wells The War of the Worlds. (I haven't tried > to make it as > compelling as Orson Wells did, but I have added an > introduction that > argues that the story is as timely at today's > headlines.) This new > version of Sophie and all the ebooks is a free > download from Richard > Gaskin's web site. If you already have a copy of > Monks you can just > replace the old Sophie folder with the new one > (being careful not to > toss any notebooks you may have created out. > > http://fourthworld.com/products/sophie/download.html > > 2). I have included all my latest experiments in > digital video and > photography -- all my efforts to take the ideals out > of the library > and into the streets. > > These additions are all available on my web sites. > > http://rivertext.smugmug.com/ > > http://rivertext.com/stuff.html > > --- > > For those of you who may not know what the hell this > post has been > about, here is a brief timeline of "the longest > running project in > the history of interactive media": > > The first library of fun and games and serious ideas > that was called > If Monks had Macs was built with Apple Computer's > HyperCard, > compressed onto two floppy disks and released as > freeware in 1988. > That was before the creative success of the CD-ROM > (which began the > following year with the Voyager Company's release of > "Beethoven's > Ninth.") In 1995 when the Voyager Company published > the first > commercial version of Monks I made the mistake of > requesting that > they add this line to the back of the package: > > "Brian Thomas is currently working on If Monks had > Windows." > > I failed to achieve this goal three times -- I > failed in: Oracle > Media Objects, SuperCard, and mTropolis. > Nonetheless, all that time I > was re-working the library's provocative text to > make it beautifully > illustrated, quick and deep. Now I have succeeded in > bringing If > Monks had Macs to Windows as well as to Mac OS X > thanks to > "Revolution." > > For more info see my web site. > > http://rivertext.com/ > > -- > Brian > ___ > use-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution > = :: Gordon Webster :: ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
