compileIt for revolution?

[Gordon Webster]

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 <b.xavier at internet.lu> 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 40000 graphics in a
> card. For the truely beautiful patterns, it took
> 300000 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. 
> 
> 300000 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: use-revolution-bounces at lists.runrev.com 
> > [mailto:use-revolution-bounces at lists.runrev.com]
> On Behalf Of 
> > Gordon Webster
> > Sent: Wednesday, June 22, 2005 16:14
> > To: How to use Revolution
> > Subject: Re: compileIt for revolution?
> > 
> > I would absolutely echo what Dennis has just said.
> I was 
> > initially really impressed with rev and I should
> say I still 
> > am in certain respects - comfort and ease of use,
> the elegant 
> > and intuitive language and stack/card paradigm
> etc. etc.
> > 
> > But I have been unable to get rev to do what I
> want it to do 
> > behind the scenes (i.e. my application logic)
> without jumping 
> > through the kinds of hoops that Dennis describes -
> 
> > effectively negating all the advantages of
> programming in 
> > Transcript that I just outlined.
> > 
> > And even when I could get the code working, man it
> was SLOW. 
> > It was discouraging to see Python easily outrun
> rev for the 
> > equivalent code - I mean I love Python and all,
> but it's 
> > hardly the gold standard for speed.
> > 
> > I would think that the stack paradigm would neatly
> allow for 
> > the creation of strongly-typed stacks that could
> be jumped 
> > into from the kind of warm and fuzzy typeless
> stacks that 
> > give rev its wonderful flexibility. The compiler
> could then 
> > insist on declarations for all objects within the
> typed stack 
> > and compile it with far greater optimization than
> is possible 
> > for the typeless stacks, perhaps even going as far
> as native 
> > code compilation :-D 
> > 
> > Imagine what a superb development environment rev
> could be 
> > with these features. Flexible and typeless for all
> the 
> > UI/scripty/fun parts of the app; more draconian
> but hellishly 
> > fast for the down-to-the-metal hardcore
> byte-crunching parts 
> > of the app. Strong typing would probably also make
> it a lot 
> > easier to automate the process of calling
> externals from 
> > Transcript without all those ghastly, clunky C
> wrappers and crap.
> > 
> > There's a dream - a rev scientific application
> with a 
> > beautiful interface rendering OpenGL objects in
> real time and 
> > a typed, Transcript-coded stack running energy
> minimization 
> > on a separate thread in the background.
> > 
> > I doubt I'll put my hands in my pockets again and
> upgrade my 
> > expired rev license just to have "deep masks" on
> my GUIs - 
> > I'm not knocking it, it's just not a feature I
> urgently need 
> > right now ... but fast compiled stacks, easy
> access to 
> > externals ... now you're talking ... where's my
> check book?
> > 
> > Best
> > 
> > Gordon
> > 
> > --- Dennis Brown <see3d at writeme.com> 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. 
=== message truncated ===