Re: Speed differences between MC and Rev and the origin of the English language

[Kevin Miller]

On 21/9/06 22:37, "Richard Gaskin" <[EMAIL PROTECTED]> wrote:

>> I believe the revGeneral library is always included. There is no option
>> to turn it off, which is usually okay, since the majority of Rev users
>> need at least some part of that library.
> 
> What a strange design decision.
> 
> I've helped more than a few people diagnose errors in standalones that
> weren't evident in the IDE because of the additional objects being added
> to their first card.  Such errors are particularly hard to pin down
> because the objects don't exist in the IDE, which is the only
> environment that can run a debugger.
> 
> I can see having an "Include revGeneral" option turned on by default,
> but preventing people from doing anything else seems really odd.
> 
> One more reason to improve MC IDE for the masses:  it's the only way to
> make truly native Rev apps. :)

To suggest that a standalone is not a truly native Revolution application
because it contains Revolution code libraries seems nonsensical.  Does that
mean that a standalone containing libURL is not a truly native Revolution
application?

There is no such library as "revGeneral".  You may be thinking of the
revCommon library.  If this is the library you mean, it seems unlikely that
this library would be responsible for a drop in performance given that the
only system message it intercepts is mouseDoubleUp - sending a mouseUp to
objects, in the same way the MetaCard IDE has done since the dawn of time.
All the other message handlers in there are there to support those terms we
define as part of the language definition and include in the dictionary.
Basics such as revCopyFolder.  Its quite a compact library.  The bigger
libraries are all optional.

Whatever is causing the performance difference is unlikely to be that
library.  But if it is, well its like any other part of the product and
could contain bugs along with the engine, the IDE, the OS, a database
driver, etc.

Errors introduced by including objects on the first card of a standalone are
a pain, I fully agree.  That original design decision historically stems
from the need to deliver extensive functionality libraries (today in
constant use in the vast majority of standalone applications out there), and
not having control over the engine and therefore capability to create an
official place to put them.  Doing this better will come about as we improve
the overall product architecture and create a place for this sort of thing.
It won't come about by us hacking in a quick fix that will doubtless
introduce its own quirkiness.  Relative to the time you have already waited
for this, it won't be much longer.

In the mean time, rather than spending time being surprised that we would
attempt to deliver feature libraries with useful functionality for our user
base to include in standalones, we would as ever welcome constructive
suggestions on how to continue progress on making what we have work better
and more reliably.

Kind regards,

Kevin

Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Ken Ray]

On 9/22/06 4:13 PM, "Wilhelm Sanke" <[EMAIL PROTECTED]> wrote:

> Applying this I get 13 front and back scripts running in the stack and
> nothing of this in the standalone (in the standalone only my script
> library "clib" and the calling button for listing the back and
> frontscripts are listed).

Well, I created a simple standalone with Rev 2.7.4 with just a button that
spat the scripts out, and left the "Search for required inclusions" radio
button on, and it inserted no frontscripts, no libraries, and 2 backscripts:
revLibURL and revCommon.

Just contributing to the discussion...

:-)


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Richard Gaskin]

Wilhelm Sanke wrote:
When I remove these backscripts and frontscripts in the stack no change 
of the slower Rev-IDE speed is effected. So the slower performance in 
Rev must be caused by other scripts.-


Very odd. If the problem is indeed related to Rev's standalones, then I 
would imagine there should be a measurable difference with just about 
any of us who switch between IDEs.


Have any of the rest of you seen performance differences between your 
standalones built with MC and those built with Rev?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Wilhelm Sanke]

On Fri, 22 Sep 2006, Richard Gaskin wrote:

It might be helpful to de-standalone it to take a look at exactly 
what's been included.


Once upon a time someone posted the info needed to strip the 
executable from the stack -- anyone make a utility for that?



In my own collected archives I found this script:

"on mouseUp
 answer file "Standalone"
 if it is "cancel" then exit to top
 put url ("binfile:"&it) into tStack
 repeat forever
   -- there's more than one stackfile in there which isinteresting
   put offset("#!/bin/sh",char 10 to -1 of tStack) into tOff
   if tOff = 0 then exit repeat
   put char tOff+9 to -1 of tStack into tStack
 end repeat
 ask file "Stack"
 if it is "cancel" then exit to top
  set the fileType to "RevoRSTK"
 put tStack into url ("binfile:"&it)
 answer "conversion finished" with "OK"
end mouseUp"

This, however, (on Windows) provides me with an extracted stack that is 
flagged as "corrupted", even if I comment out the line about the 
filetype which is probably meant only for MacOS(?)


A simpler diagnostic might be to have your app spit out a list of 
frontScripts, backScripts, and libraries, something like this:


on LogScripts
  put the frontScripts &cr& the stacksInUse &cr& the backScripts \
in url ("file:ScriptList.txt")
end LogScripts



Applying this I get 13 front and back scripts running in the stack and 
nothing of this in the standalone (in the standalone only my script 
library "clib" and the calling button for listing the back and 
frontscripts are listed).


When I remove these backscripts and frontscripts in the stack no change 
of the slower Rev-IDE speed is effected. So the slower performance in 
Rev must be caused by other scripts.-


Unfortunately I cannot follow your other suggestions at the moment 
(startloggingMessages etc.) because I really need to concentrate on 
other things at the moment (and not only, but also, because of that 
voluminous doctoral dissertation on my desk).


I will continue the discussion in about a week and thank all of you in 
the meantime for your interest in this thread.


Best regards,

Wilhelm Sanke

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[J. Landman Gay]

Wilhelm Sanke wrote:

why should anybody refer to stack "home" in a standalone?


In a standalone, the mainstack becomes "home" and the term "home" 
becomes synonymous with the name of the mainstack, so you can use 
either. This doesn't answer the rest of your question, of course.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Dave Cragg]

On 22 Sep 2006, at 16:10, Wilhelm Sanke wrote:


In case my comments were felt to be offensive,


Not in any way. It was only because your comments were so interesting  
that I felt inspired to reply. It's not often we get a thread on  
something so close to home.


Coincidentally, there was a TV show about Nero on the BBC last night.  
(No bagpipes or Rev libraries were featured.)


Cheers
Dave
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Richard Gaskin]

Wilhelm Sanke wrote:
Apart from the parts of my own scripts that are unprotected I see a lot 
of extra code, some of which may belong to CRevGeneral

...
Maybe the last example could be one of the culprits that slow down 
execution (?)


and such as

"on mouseDoubleUp pButtonNo, pTarget
--not been handled
--pTarget set in suppress messages frontscript
if pTarget is empty
then put the long id of the target into pTarget
put revTargetStack(pTarget) into tStack
put the defaultStack into tDefaultStack
set the defaultStack to tStack
if the mode of stack tStack is not 0
then click at the clickLoc
set the defaultStack to tDefaultStack
end mouseDoubleUp"


Good sluething, Wilhelm.

It might be helpful to de-standalone it to take a look at exactly what's 
been included.


Once upon a time someone posted the info needed to strip the executable 
from the stack -- anyone make a utility for that?


A simpler diagnostic might be to have your app spit out a list of 
frontScripts, backScripts, and libraries, something like this:


on LogScripts
  put the frontScripts &cr& the stacksInUse &cr& the backScripts \
in url ("file:ScriptList.txt")
end LogScripts

It might also be helpful to log messages within your standalone using 
the messageHandled message.  This is undocumented, but to have that 
message sent you first turn on the messageMessages global property, then 
get your list of handlers:


on StartLoggingMessages
  set the messageMessages to true
end StartLoggingMessages

In a library somewhere you can include this:

on messageHandled
  global gMessageLog
  put the params && the long name of the target &cr after gMessageLog
  pass messageHandled
end messageHandled

And to dump it just use:

on CloseMessageLog
  global gMessageLog
  put gMessageLog into url ("file:MessageLog.txt")
end CloseMessageLog

These scripts are off the top of my head, so please forgive an errors.

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Wilhelm Sanke]

On Thu, 21 Sep 2006, Richard Gaskin wrote:

That leaves us with the possibility that Rev is including some of its 
scripts even when you tell it not to.


When you pour through the standalone with a raw editor do you see any 
Rev scripts in there?



and Jacqueline had confirmed in the meantime:


I believe the revGeneral library is always included.



Yes, I do see that in the Windows standalone built with Rev 2.7.3 -gm1.

Apart from the parts of my own scripts that are unprotected I see a lot 
of extra code, some of which may belong to CRevGeneral, but other 
scripts certainly could not belong there, like:


"set the mainStack of the topStack to "Home"
modal "Stack Properties"
if it is not empty then
set the cursor to watch
topLevel it
end ifgo to prev card ùA ûA ÖA üA ïA‘? AB B" etc.

The above is definitely not *my* code - and why should anybody refer to 
stack "home" in a standalone?


Other functions seem to belong to CRevGeneral like

- "function revPoints pGraphic"

- "function revApplescriptFull pfunction,pSrc,pDest"

Why should this be included in a Windows standalone?

- "on revMail pTo, pCC, pSubject, pBody"

- "setProp cREVGeneral[pWhichProp] pWhichProfile
put the long id of the target into tTarget
put tTarget into tTargetLongID
if pWhichProp is not "profile" and pWhichProp is not "inLineImages" and 
pWhichProp is not "virtualWidth" and pWhichProp is not "virtualHeight" 
and pWhichProp is not "breakPoints" then pass cREVGeneral"

etc.

Maybe the last example could be one of the culprits that slow down 
execution (?)


and such as

"on mouseDoubleUp pButtonNo, pTarget
--not been handled
--pTarget set in suppress messages frontscript
if pTarget is empty
then put the long id of the target into pTarget
put revTargetStack(pTarget) into tStack
put the defaultStack into tDefaultStack
set the defaultStack to tStack
if the mode of stack tStack is not 0
then click at the clickLoc
set the defaultStack to tDefaultStack
end mouseDoubleUp"

Best regards,

Wilhelm Sanke






___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Speed differences between MC and Rev and the origin of the English language

[Wilhelm Sanke]

On Fri, 22 Sep 2006, Dave Cragg <[EMAIL PROTECTED]>, wrote:

The people of Edinburgh and the area to the south east did fight with  
the Angles of Northumbria. But these were neither Picts nor Scots.  
They were Britons who spoke what today would be recognised as Welsh.  
Interestingly, these battles are more remembered in Welsh history  
than in Scottish history. (Also, some people think Arthur was the  
leader of a tribe of Scottish Britons, and that he fought against  
both Angles and Picts.) Eventually, the Angles dominated south east  
Scotland and the Scots and Picts dominated the remainder of the  
country. The use of "Welsh" in Scotland died out.



The database I based my judgment on was small, and I had warned you that 
only about 99% of my story was true. There were so many different 
kingdoms or territories governed by warlords at that time that one can 
easily become confused.


But I think the general picture is true.

It is rumoured that there are many missing libraries of that period,  
thought to be hidden in southern Scotland somewhere. It may be that  
one of these libraries has got buried in the Rev IDE. (Some of those  
scripts look like Welsh to me.)


I also read somehwere that the Romans introduced the bagpipes to  
Scotland, but left before they taught people how to tune them.


Cheers
Dave 



It could well be that the Romans instroduced the instrument to Scotland, 
but did not particularly like the sounds coming out of it.

A quote from Wikipedia:
"Nero is reported to have said he would play them (bagpipe is plural in 
Latin) in public as a penance for not winning a poetry contest".-


In case my comments were felt to be offensive, I apologize to the 
Scottish branch of my family, who are however living more near Glasgow.


Cheers,

Wilhelm


___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: metacard Digest, Vol 36, Issue 17

[Scott Rossi]

Recently, John Vokey wrote:

> As a Canadian Scot, I take serious offence at this comment: Bagpipes
> by definition are always in tune; it is the ignorant listeners who
> aren't.  Besides, I heard the Romans left because of the advent of
> the accordian...  Now, as a one time player of same, that is an
> instrument deserving of opprobrium.

Play the accordion.
Go to jail.
That's the law.

[ found on bumper stickers in the US ]

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-
E: [EMAIL PROTECTED]
W: http://www.tactilemedia.com


___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard