Wake up Revolution

[Inselfan]

Good morning Revolution!

This morning, it was a nice, sunny morning, I got an E-Mail from you, telling me, that I'm one of the people with a longer experience. For that reason you have a fantastic offer with half the price of RunRev 4.00 Sounds good I thought. But being a carefull person I thought also, better I test befor I buy.

That's what I did this evening.The download was, as expected without any problem. A positive surprise after starting was the new Outfit (still using 2.9) Well done!

But then,after starting an application, the problems also started. The speed is away from all reallity. (orking on Windows) A ^T blocks the computer for mor than 2 (!!!) minutes and the CPU-usage goes to 100%. Jumping from one to another CD leaves time for boiling water for a tea with a CPU usage of again 100%. I stopped further tests.

Dear RunRev Team, I belive, you are working hard and I belive that it is a hard job you do, but you must be joking, if you want to sell this product now! Not for half price and not for less.

I'm really sad that I can't buy such a unfinished product.

Good night Revolution, It's time to start a revolution to fix the handicaps

Kind regards from a still faithfully but sad user

Horst

Not writing my native language, so please smile if you find wrong words :)

[Neal Campbell K3NC]

Its amazing how different experiences can be. I have worked 8 hours straight
today with 4.0.0 without a single hiccup (except the self-inflicted ones).

I think the new release is a major success.

Neal Campbell
Abroham Neal Software
www.dxbase.com
www.abrohamnealsoftware.com
www.sdrsystems.com
[phone]

Amateur Radio: K3NC
Blog: http://www.abrohamnealsoftware.com/blog/
DXBase bug reports: email to [hidden email]
Abroham Neal forums: http:/www.abrohamnealsoftware.com/community/

DX Cluster: dxc.k3nc.com port 23





On Sat, Nov 14, 2009 at 6:16 PM, Inselfan <[hidden email]> wrote:

>
> Good morning Revolution!
>
> This morning, it was a nice, sunny morning, I got an E-Mail from you,
> telling me, that I'm one of the people with a longer experience. For that
> reason you have a fantastic offer with half the price of RunRev 4.00 Sounds
> good I thought. But being a carefull person I thought also, better I test
> befor I buy.
>
> That's what I did this evening.The download was, as expected without any
> problem. A positive surprise after starting was the new Outfit (still using
> 2.9) Well done!
>
> But then,after starting an application, the problems also started. The
> speed
> is away from all reallity. (orking on Windows) A ^T blocks the computer for
> mor than 2 (!!!) minutes and the CPU-usage goes to 100%. Jumping from one
> to
> another CD leaves time for boiling water for a tea with a CPU usage of
> again
> 100%. I stopped further tests.
>
> Dear RunRev Team, I belive, you are working hard and I belive that it is a
> hard job you do, but you must be joking, if you want to sell this product
> now! Not for half price and not for less.
>
> I'm really sad that I can't buy such a unfinished product.
>
> Good night Revolution, It's time to start a revolution to fix the handicaps
>
> Kind regards from a still faithfully but sad user
>
> Horst
>
> Not writing my native language, so please smile if you find wrong words :)
>
> --
> View this message in context:
> http://n4.nabble.com/Wake-up-Revolution-tp621641p621641.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sarah Reichelt-2]

> But then,after starting an application, the problems also started. The speed
> is away from all reallity. (orking on Windows) A ^T blocks the computer for
> mor than 2 (!!!) minutes and the CPU-usage goes to 100%. Jumping from one to
> another CD leaves time for boiling water for a tea with a CPU usage of again
> 100%. I stopped further tests.

Hi Horst,

I am a Mac user but even so, I haven't heard of any such slowness
problems. I find Rev 4 to be faster than ever before.
Is this with an existing stack or are you testing with a new stack?
If an existing stack, does it run perfectly in earlier version of Rev?
Try locking messages before going to a new card - if that fixes the
problem, then there is a script that is causing the delay.

This seems to be a very unusual case, so I am sure we can solve it if
you supply more detail.

Cheers,
Sarah
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[William Marriott]

Control-T and navigating cards works instantly for me. Windows 7 64-bit
and Windows XP (Max OS X Snow Leopard, too.) Haven't heard of this issue
from any other of hundreds of beta testers and users. Need details to
see what's really going on.

Inselfan wrote:
> A ^T blocks the computer for
> mor than 2 (!!!) minutes and the CPU-usage goes to 100%. Jumping from one to
> another CD leaves time for boiling water for a tea with a CPU usage of again
> 100%. I stopped further tests.

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Inselfan]

Holá Sarah, holá Bill,

Thanks for offering your high-welcome help.

I'm "testing" RR with the actual version I downloades the night before. I use W2k and XP-professional.
RAM on W2k 2 GB, on XP 1 GB

Yes, I'm using a existing stack wich works fine under 2.9. The application has a size of 16 MB

Here is what I for example do:

By pressing a button, which contains:

on mouseUp
  set cursor to watch
  go cd  "Adressliste_Global"
end mouseUp

On this Card:
on preopencard
  set the visible of btn "weckerli" to false
  set the visible of fld "Alarmliste" to false
  lock screen
  put empty into temp1
  put empty into temp2
  put empty into temp3
  put empty into temp4
  put empty into temp5
  put empty into temp6
  put empty into temp7
  put empty into temp8
  put empty into temp9
  put empty into temp10
  put empty into temp11
  put empty into temp12
  put empty into temp13
  put empty into temp14
  put empty into fld "kndnr1"
  put empty into fld "vorname1"
  put empty into fld "suchname1"
  put empty into fld "aktiv1"
  put empty into fld "kategorie1"
  put empty into fld "ort1"
  put empty into fld "burzeltag1"
  put empty into fld "Telefon1"
  put empty into fld "Telefon2"
  put empty into fld "antwort"
  put empty into fld "phone"
  unlock screen
end preopencard

on opencard
  lock screen
  hide img "up1"
  hide img "up2"
  hide img "up3"
  hide img "up4"
  hide img "up5"
  hide img "up6"
  hide img "up7"
  hide img "up8"
  hide img "up9"
  hide img "down1"
  hide img "down2"
  hide img "down3"
  hide img "down4"
  hide img "down5"
  hide img "down6"
  hide img "down7"
  hide img "down8"
  hide img "down9"
  hide grp "Kategorieauswahl"
  put "A - Z" into Index
  put word 1 of fld "v_feld_01" && benutzer into fld "v_feld_01"
  #zettelkasten  
  #SetTime
  #Termine_machen
  unlock screen
  focus fld "antwort"
end opencard


all variables are defined by Globals or Locals.
This action takes 18545 millisec!!!, the CPU is on 100% and the computer is blocked completly.

Yes, if I'm locking messages, it is fast. But what the hell is wrong with the script above??
Still having the prob with ^T wich also takes until 2 minutes with blocking the Computer for other work.
Still a long delay to open "Tools" in the menu bar,
nearly impossible to open a CD from Application Browser. I crashed RR after waiting 15 minutes to open a card

Whatever I do, the cpu goes to 100%, and the delay is out of discussion.

If you use Team-view and are interested to see, where I'm talking about,please let me know and we'll make an apointment

kind regards

Horst

[Richmond Mathewson-2]

Dear Inselfan,
  I cannot help noticing you are using Windows;

Maybe the problem does not lie with RunRev 4, but
maybe there is a background process (possibly
some sort of virus) that is triggered when you
launch RunRev, that is hogging the memory.

I am running RunRev 4 on a Pentium III Compaq,
256 MB RAM, Windows XP as a test machine (I normally
work with Macintosh) and everything runs very smoothly;
the only problem being if I decide to run another
program at the same time - which, considering the
comparatively small amount of RAM and the fact that
my XP box is headless (i.e. no monitor) and 'bottomless'
(no keyboard and mouse) and I access it using the
Microsoft Remote Desktop Connection Client from my
G4 Mac is unsurprising.

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Inselfan]

Holá Richmond,

Well, running same Stacks with RR-2.9 is OK so far.
I don't think, that my PC's are infected. Not with a Virus or something else.
It is only RR 4.0 which blocks. On all Computers, but thanks for trying to help.

I would love to tell the World, that RunRev 4.0 is the best ever and that everything works as expected, but I think, it's a long way there...

kind regards

Horst



Dear Inselfan,
  I cannot help noticing you are using Windows;

Maybe the problem does not lie with RunRev 4, but
maybe there is a background process (possibly
some sort of virus) that is triggered when you
launch RunRev, that is hogging the memory.

[Richmond Mathewson-2]

Inselfan wrote:

> Holá Richmond,
>
> Well, running same Stacks with RR-2.9 is OK so far.
> I don't think, that my PC's are infected. Not with a Virus or something
> else.
> It is only RR 4.0 which blocks. On all Computers, but thanks for trying to
> help.
>
> I would love to tell the World, that RunRev 4.0 is the best ever and that
> everything works as expected, but I think, it's a long way there...
>
> kind regards
>
> Horst
>
>
>
> Dear Inselfan,
>   I cannot help noticing you are using Windows;
>
> Maybe the problem does not lie with RunRev 4, but
> maybe there is a background process (possibly
> some sort of virus) that is triggered when you
> launch RunRev, that is hogging the memory.
>
>  

I cannot help feeling that there is "something funny" about your
computer; I have RunRev 4 (Studio) running extremely well on the
following machines:

Pentium 3: Windows XP

Hewlett-Packard Pentium 4: Ubuntu 8.04.3

Mac G4: Mac OS 10.5.8

And revMedia 4 running on all of those and:

iMac G3: Mac OS 10.4.11

MacMini PPC: Mac OS 10.4.11

I have about 12 children running revMedia on a variety
of computers running from an old P2 with Windows 98 to
a fancy laptop running Vista all having a lovely time with
revMedia 4.

One boy running Mint Linux with revMedia.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Rick Harrison]

Hi there,

Has anyone been able to read, and write
to a PostgreSQL database located on
the On-Rev server using a revlet?

If you have please let me know.

Thanks,

Rick
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richard Gaskin]

Inselfan wrote:

> Well, running same Stacks with RR-2.9 is OK so far.
> I don't think, that my PC's are infected. Not with a Virus or something
> else.
> It is only RR 4.0 which blocks. On all Computers, but thanks for trying to
> help.
>
> I would love to tell the World, that RunRev 4.0 is the best ever and that
> everything works as expected, but I think, it's a long way there...

If a thousand people experience great performance and one person
experiences very poor performance, would it not seem worthwhile to
consider the cause of the difference may lie with the system's
configuration?

It may not be a virus, but clearly there's something going on which is
very different from what most if not all Rev4 users are experiencing.

The method for solving any problem is to identify the differences
between the working and non-working states.  If you're interested in
enjoying the same Rev 4 performance everyone else here is experiencing,
perhaps we could start by looking at your OS version, RAM, and other
system particulars.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Pierre Sahores-3]

Hi Inselfan,

I use the Rev 4.0 GM1(IDE) to run a stack as a 24/7 long running  
process without any problem on 4+1 different boxes :

The process consist to produce, one grid after an other, crosswords  
games (lexicons + AI outputs the games that are then uploaded to www.woooooooords.com
.

The 4 first boxes are producing the games and the last one is  
uploading them.

Producers Boxes :

- Medion laptop Pentium M 1.6 Ghz with 1 Go RAM Win XP Pro
- Acer AspireOne subnotebook Intel N 270 1.6 Ghz with 1 Go RAM Win XP  
Home
- Asus eeePC 900 subnotebook Intel Pentium Celeron 0.9 Ghz with 1 Go  
RAM - Win XP Home
- Mac Book Pro Core 2 (32 bits) 2 Ghz with 2 Go RAM - Mac OS X 10.5.8

Upload Box ;

PowerBook G4 1Ghz with 1 Go RAM - Mac OS X 10.4.11

Dev. Box :

- Mac Book Pro Core 2 (32 bits) 2 Ghz with 2 Go RAM - Mac OS X 10.5.8

All is working perfectly under all thoses configs.

I use ClamWin 0.95 antivirus on the win boxes.

What i just noticed in switching for Rev 3.5 to Rev 4.0 is that the  
script editor seems 20% more reactive under the dev box. Can't say, at  
this point, if the engine is realy 20% faster too.

Hope this can help.

Best Regards,

P. Sahores


Le 15 nov. 09 à 14:13, Inselfan a écrit :

>
> Holá Richmond,
>
> Well, running same Stacks with RR-2.9 is OK so far.
> I don't think, that my PC's are infected. Not with a Virus or  
> something
> else.
> It is only RR 4.0 which blocks. On all Computers, but thanks for  
> trying to
> help.
>
> I would love to tell the World, that RunRev 4.0 is the best ever and  
> that
> everything works as expected, but I think, it's a long way there...
>
> kind regards
>
> Horst
>
>
>
> Dear Inselfan,
>  I cannot help noticing you are using Windows;
>
> Maybe the problem does not lie with RunRev 4, but
> maybe there is a background process (possibly
> some sort of virus) that is triggered when you
> launch RunRev, that is hogging the memory.
>
> --
> View this message in context: http://n4.nabble.com/Wake-up-Revolution-tp621641p621748.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

--
Pierre Sahores
mobile : [phone]

www.woooooooords.com
www.sahores-conseil.com






_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Mark Schonewille-3]

Richard,

Who says that tousand people experience great performance?! I, for  
one, don't.

I am pretty sure that Inselfan did something that should just work in  
Revolution without problems and figuring out the source of the problem  
is a process that one should not have to go through with a development  
environment like Revolution in the first place!

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Download Strõm Flow Chart Software
http://flowproject.economy-x-talk.com

Op 15 nov 2009, om 17:18 heeft Richard Gaskin het volgende geschreven:

> If a thousand people experience great performance and one person  
> experiences very poor performance, would it not seem worthwhile to  
> consider the cause of the difference may lie with the system's  
> configuration?
>
> It may not be a virus, but clearly there's something going on which  
> is very different from what most if not all Rev4 users are  
> experiencing.
>
> The method for solving any problem is to identify the differences  
> between the working and non-working states.  If you're interested in  
> enjoying the same Rev 4 performance everyone else here is  
> experiencing, perhaps we could start by looking at your OS version,  
> RAM, and other system particulars.

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Pierre Sahores-3]

Hi Rick,

As long as i was'nt able to set up a test db in using the phpPgAdmin  
cPanel's module (early days of may 2009), i didn't go further about  
using PostgreSQL in conjunction with on-rev and switched to MySQL  
instead witch works perfect (both phpMyAdmin and direct localhost irev  
request and queries - revlets untested) about what i need from my irev  
apps.

Best,

Pierre

Le 15 nov. 09 à 17:05, Rick Harrison a écrit :

> Hi there,
>
> Has anyone been able to read, and write
> to a PostgreSQL database located on
> the On-Rev server using a revlet?
>
> If you have please let me know.
>
> Thanks,
>
> Rick
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

--
Pierre Sahores
mobile : [phone]

www.woooooooords.com
www.sahores-conseil.com






_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Colin Holgate-2]

On Nov 15, 2009, at 11:18 AM, Richard Gaskin wrote:

> >If a thousand people experience great performance and one person experiences very poor performance, would it not seem worthwhile to consider the cause of the difference may lie with the system's configuration?

You can't use logic for this case, otherwise you would argue that if on a particular machine you can open and run a stack without any issues in 2.9, and if you open and run the stack in 4.0 you get two minute long lock up of the machine every time you press a certain key, obviously 4.0 is the only thing that was changed in the test, and so must be at fault.

The best test would be to get that stack onto other people's machines, and have them run it in 2.9 and 4.0, and see if the same issue happens. At the same time Inselfan should try further testing of 4.0, with other stacks. If those other stacks all work perfectly, then that helps narrow the problem down to something in that particular stack triggering the issue.


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jan Schenkel]

Hi Horst,

Why don't you do some logging to figure out what's causing the pain?
Just add something like this to the preOpenCard and openCard handlers:
##
on preOpenCard
  put the milliseconds into tStart
  -- now the rest of your handler script
  ...
  -- now put how long it takes at the end of the message box
  put the milliseconds into tEnd
  put merge("preOpenCard: [[tStart]] > [[tEnd]] ([[tEnd - tStart]] millis)") & return after msg
end preOpenCard
##
Now when you move from one card to the next, you should see how long the individual handlers take, but also how much time is between the preOpenCard and openCard events.

If for some reason, the slowdown is inside your own handler, try and narrow it down to the slowest statement. It's not a fun job, but it will give you valuable insight.

Jan Schenkel.
=====
Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)


--- On Sun, 11/15/09, Inselfan <[hidden email]> wrote:

> Holá Sarah, holá Bill,
>
> Thanks for offering your high-welcome help.
>
> I'm "testing" RR with the actual version I downloades the
> night before. I
> use W2k and XP-professional.
> RAM on W2k 2 GB, on XP 1 GB
>
> Yes, I'm using a existing stack wich works fine under 2.9.
> The application
> has a size of 16 MB
>
> Here is what I for example do:
>
> By pressing a button, which contains:
>
> on mouseUp
>   set cursor to watch
>   go cd  "Adressliste_Global"
> end mouseUp
>
> On this Card:
> on preopencard
>   set the visible of btn "weckerli" to false
>   set the visible of fld "Alarmliste" to false
>   lock screen
>   put empty into temp1
>   put empty into temp2
>   put empty into temp3
>   put empty into temp4
>   put empty into temp5
>   put empty into temp6
>   put empty into temp7
>   put empty into temp8
>   put empty into temp9
>   put empty into temp10
>   put empty into temp11
>   put empty into temp12
>   put empty into temp13
>   put empty into temp14
>   put empty into fld "kndnr1"
>   put empty into fld "vorname1"
>   put empty into fld "suchname1"
>   put empty into fld "aktiv1"
>   put empty into fld "kategorie1"
>   put empty into fld "ort1"
>   put empty into fld "burzeltag1"
>   put empty into fld "Telefon1"
>   put empty into fld "Telefon2"
>   put empty into fld "antwort"
>   put empty into fld "phone"
>   unlock screen
> end preopencard
>
> on opencard
>   lock screen
>   hide img "up1"
>   hide img "up2"
>   hide img "up3"
>   hide img "up4"
>   hide img "up5"
>   hide img "up6"
>   hide img "up7"
>   hide img "up8"
>   hide img "up9"
>   hide img "down1"
>   hide img "down2"
>   hide img "down3"
>   hide img "down4"
>   hide img "down5"
>   hide img "down6"
>   hide img "down7"
>   hide img "down8"
>   hide img "down9"
>   hide grp "Kategorieauswahl"
>   put "A - Z" into Index
>   put word 1 of fld "v_feld_01" && benutzer
> into fld "v_feld_01"
>   #zettelkasten 
>   #SetTime
>   #Termine_machen
>   unlock screen
>   focus fld "antwort"
> end opencard
>
>
> all variables are defined by Globals or Locals.
> This action takes 18545 millisec!!!, the CPU is on 100% and
> the computer is
> blocked completly.
>
> Yes, if I'm locking messages, it is fast. But what the hell
> is wrong with
> the script above??
> Still having the prob with ^T wich also takes until 2
> minutes with blocking
> the Computer for other work.
> Still a long delay to open "Tools" in the menu bar,
> nearly impossible to open a CD from Application Browser. I
> crashed RR after
> waiting 15 minutes to open a card
>
> Whatever I do, the cpu goes to 100%, and the delay is out
> of discussion.
>
> If you use Team-view and are interested to see, where I'm
> talking
> about,please let me know and we'll make an apointment
>
> kind regards
>
> Horst
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[J. Landman Gay]

Inselfan wrote:

> Here is what I for example do:
>
> By pressing a button, which contains:
>
> on mouseUp
>   set cursor to watch
>   go cd  "Adressliste_Global"
> end mouseUp
>
> On this Card:
> on preopencard
>   set the visible of btn "weckerli" to false
>   set the visible of fld "Alarmliste" to false
>   lock screen
>   put empty into temp1
>   put empty into temp2
>   put empty into temp3
>   put empty into temp4
>   put empty into temp5
>   put empty into temp6
>   put empty into temp7
>   put empty into temp8
>   put empty into temp9
>   put empty into temp10
>   put empty into temp11
>   put empty into temp12
>   put empty into temp13
>   put empty into temp14
>   put empty into fld "kndnr1"
>   put empty into fld "vorname1"
>   put empty into fld "suchname1"
>   put empty into fld "aktiv1"
>   put empty into fld "kategorie1"
>   put empty into fld "ort1"
>   put empty into fld "burzeltag1"
>   put empty into fld "Telefon1"
>   put empty into fld "Telefon2"
>   put empty into fld "antwort"
>   put empty into fld "phone"
>   unlock screen
> end preopencard
>
> on opencard
>   lock screen
>   hide img "up1"
>   hide img "up2"
>   hide img "up3"
>   hide img "up4"
>   hide img "up5"
>   hide img "up6"
>   hide img "up7"
>   hide img "up8"
>   hide img "up9"
>   hide img "down1"
>   hide img "down2"
>   hide img "down3"
>   hide img "down4"
>   hide img "down5"
>   hide img "down6"
>   hide img "down7"
>   hide img "down8"
>   hide img "down9"
>   hide grp "Kategorieauswahl"
>   put "A - Z" into Index
>   put word 1 of fld "v_feld_01" && benutzer into fld "v_feld_01"
>   #zettelkasten  
>   #SetTime
>   #Termine_machen
>   unlock screen
>   focus fld "antwort"
> end opencard

There is nothing here that would cause a slowdown, it should be
instantaneous. These are very simple commands.

>
> Yes, if I'm locking messages, it is fast. But what the hell is wrong with
> the script above??

This is a clue. If the handlers run fast with messages locked, that
means there is another handler somewhere that is taking all the CPU
time. Often this is caused by a repeat loop that doesn't exit, or some
other command that does not release control to Rev. Look for other
stacks that are in use, scripts inserted into the back, plugins that are
running, or something else that is using CPU time.

Try choosing "suspend development environment" from the Tools menu and
then run your script. If that works, then check the plugins carefully,
particularly any third-party plugins you might have installed. If that
does not work, it means a handler in your stack somewhere is running
without releasing time to the CPU.

If you would like to send me your stack off-list, I will look at it.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Malte Pfaff-Brill]

Horst,

it might be that your preferences stack broke in the update. try this  
in msg:

put the effective filename of stack "revPreferences"

Note that path and quit rev. Remove the file from there and relaunch  
rev. Does it make things any better?

Also, if that doesn´t help, what does

put the messageMessages

return for you?

Cheers,

Malte_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richard Gaskin]

Mark Schonewille wrote:

> Who says that tousand people experience great performance?! I, for  
> one, don't.

I haven't seen your RQCC report on this.  What's the #?

After reading the messages here, in the forum, and other venues, yours
and Inselfan's posts are the first I've come across during the long
preview cycle which report that there's something wrong with v4's
performance.

Now that we have a second data point reflecting similar results we can
modify the analysis of the problem, but the basic principle remains the
same:  identify the differences between the working and non-working states.

> I am pretty sure that Inselfan did something that should just work in  
> Revolution without problems and figuring out the source of the problem  
> is a process that one should not have to go through with a development  
> environment like Revolution in the first place!

I wholeheartedly agree, and share the desire for an ideal world in which
everything always works perfectly.

But in our imperfect world all processes have a failure rate, and the
software development process is no exception.

If the good folks at RunRev are aware of this issue I doubt they
consider it acceptable, and are likely working on it I write this.

But if they're not yet aware of it they may require some assistance to
be able to replicate it.  That's where we come in:  when we see a
problem, we try arrive at a recipe for reproducing it and report it to
the RQCC.


Colin's suggestion seems useful for doing so:

> The best test would be to get that stack onto other people's machines,
> and have them run it in 2.9 and 4.0, and see if the same issue happens.
> At the same time Inselfan should try further testing of 4.0, with other
> stacks. If those other stacks all work perfectly, then that helps narrow
> the problem down to something in that particular stack triggering the issue.


Jacque's comments honed this analysis even further:

> Try choosing "suspend development environment" from the Tools menu and
> then run your script. If that works, then check the plugins carefully,
> particularly any third-party plugins you might have installed. If that
> does not work, it means a handler in your stack somewhere is running
> without releasing time to the CPU.
>
> If you would like to send me your stack off-list, I will look at it.

I would be interested in learning what you find, Jacque.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richmond Mathewson-2]

Richard Gaskin wrote:

> Mark Schonewille wrote:
>
>> Who says that tousand people experience great performance?! I, for  
>> one, don't.
>
> I haven't seen your RQCC report on this.  What's the #?
>
> After reading the messages here, in the forum, and other venues, yours
> and Inselfan's posts are the first I've come across during the long
> preview cycle which report that there's something wrong with v4's
> performance.
>
> Now that we have a second data point reflecting similar results we can
> modify the analysis of the problem, but the basic principle remains
> the same:  identify the differences between the working and
> non-working states.
>
>> I am pretty sure that Inselfan did something that should just work
>> in  Revolution without problems and figuring out the source of the
>> problem  is a process that one should not have to go through with a
>> development  environment like Revolution in the first place!
>
> I wholeheartedly agree,

There is a school of thought that RunRev have tried to expand the
capabilities of Revolution rather too
rapidly, without taking care of some 'nuts-and-bolts' glitches that have
been around for some time.

There is a risk, as one runs for the finish line, with one's eye on the
prize, that one doesn't see the
banana skin on the track.

> and share the desire for an ideal world in which everything always
> works perfectly.
>
> But in our imperfect world all processes have a failure rate, and the
> software development process is no exception.
>
> If the good folks at RunRev are aware of this issue I doubt they
> consider it acceptable, and are likely working on it I write this.
>
> But if they're not yet aware of it they may require some assistance to
> be able to replicate it.  That's where we come in:  when we see a
> problem, we try arrive at a recipe for reproducing it and report it to
> the RQCC.
>
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Thomas McGrath III-3]

I hate those f_cking banana skins.



On Nov 15, 2009, at 3:30 PM, Richmond Mathewson wrote:
>
> There is a risk, as one runs for the finish line, with one's eye on  
> the prize, that one doesn't see the
> banana skin on the track.
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution