Re: [revServer] process timeout issue

[Peter W A Wood]

Hi Chipp

On 4 Aug 2010, at 11:14, Chipp Walters wrote:

> I believe I paid something like 500 bucks for it at the beginning and nothing 
> since, so I
> understand the SLA (or lack thereof) I am receiving.

I also bought a founder account and share your sentiment to a large degree. 
However, RunRev appears to be its own worst enemy by making public statements 
such as "Ultra reliable web hosting", "Blistering Performance" and "Server 
Performance - Blistering". Yes, the founder account is good value at the 
current service levels but it doesn't live up to its promises. 

Regards

Peter___
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

currency format

[jim sims]

I don't seem to be able to find any information about currency formatting in 
Rev.

I'm adding up numbers to get a sum for currency use.

So, am I right to assume that when doing something with currency like Sweden 
for example, I would swap the dot (decimal point) for  comma (for decimal 
point) when I display the number (post calculations)?

Same goes for the opposite case if a thousands marker for example - switch it 
to a dot?


sims





___
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: [revServer] process timeout issue

[Jeff Massung]

On Tue, Aug 3, 2010 at 10:14 PM, Chipp Walters  wrote:

> Jeff,
>
> Honestly, how can you expect a company to fix a problem when they can't
> define the bug? Is that too much to ask for before you throw revServer
> under
> the bus?
>
>
I don't and yes, it is. I really don't mean to sound cold or callous.

What I choose do (as a non-hobby) is impacted in the tools I choose to use.
I use Mac over Windows for many similar reasons that are non-asthetic.
Should I sit around waiting for Microsoft to fix a problem that's holding me
up and be actively engaged with them to help fix the problem?

I suppose I could if I just really liked the tool and I had the time/money
to wait. But I don't, and my end goal is to grow _my_ business and make
money - not theirs. Of course, things are best when two people/companies can
mutually benefit each other, and to that end I would obviously take some
time/effort and do just that. But, when it's more advantageous for me to do
so, I will switch to using tools that helps to accomplish my goals without
hesitation.

I do not want to get into any discussions about what problem(s) I had with
On-Rev. I merely wanted to point out that - regarding server response times
and timeouts - I had a very similar issue to Jerry, which did cause me to
switch hosting companies. I'd rather not say any more beyond what I already
have about the issue.

Jeff M.
___
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: [revServer] process timeout issue

[Joe F.]

Very well put Jeff.
I guess I came into Enterprise and On-Rev about the same time and your feelings 
echo my own.
I had no interest in a pre-alpha RevMobile, but I feel like I was penalized 
because of it.
And I have to add that Jerry's tRev has enhanced my Enterprise experience quite 
a bit.

Joe F.

On Aug 3, 2010, at 9:40 PM, Jeff Massung wrote:
> I've tried to hold back from chiming in on yet another "passionate"
> discussion having to do with Rev. Most everyone here is great, and obviously
> there are those here intent on trying to diagnose and fix the problem.
> Bravo.
> 
> Yet, I feel the need to say that I had *extremely* similar issues to Jerry
> for the few months I used On-Rev. I had several emails back and forth with
> Heather regarding extremely sporadic and spotty access to my site given a
> web application I've been developing for quite some time.
> 
> While using On-Rev, my user-base (in pre-pre-alpha) consisted of a whopping
> 8 people, and there would be hours at a time during which my REST API'd
> application was just unavailable to my customers. There'd be times where an
> average command would take milliseconds, and others when socket operations
> would timeout *consistently* (we're talking 20+ second timeouts). This was
> just wholly unacceptable for me - as a paying customer.
> 
> During this time, Heather and Co. were very responsive and - I think -
> understanding of the problem(s) I was facing, but in the end weren't able
> to accommodate me in the way I was hoping they would. And that's 100% okay;
> no company can meet every customers' needs. So I switched to a different
> host, I'm paying more, and have had no problems (other than my own stupid
> bugs) since.
> 
> It's really great that Rev users love their tool of choice. It's even better
> that they want to make it the best it can be. Sometimes I wonder if the Rev
> team realizes just how good of a marketing resource they have in their
> community. I rarely witness it being coddled, nurtured, loved, and even
> taken advantage of (in a good way). If I had such a zealous group behind one
> of my products, I'd be here every day trying to grow it.
> 
> But, in the end, we're customers. We're not paid advocates - at least I'm
> not. If a product I'm paying for isn't working for me, I move on. And - from
> what I've read and discussions had - that very much seems to be what Jerry
> did with On-Rev. We (and our business ventures) don't have infinite amounts
> of time and money in the bank to wait for a product to mature meet our
> needs, no matter how badly we want it to. And, likewise, unless the Rev team
> is aware that there is a serious risk of losing it's [very loyal] customers,
> there's no incentive for them to do better.
> 
> If I may venture a guess, I think what most people like about Jerry, his
> team, and his products are that they are extremely focused and targeted. And
> to make things even better, they eat their own dog food.
> 
>> From the outside, the Rev team feels like the exact opposite. I see
> nearly-zero focus on anything. On-Rev is > 1 years old now and the IDE is
> still something I wouldn't have release to any customer - even as an early
> alpha. There's no way they use that tool in-house, because any programmer
> worth their salt would have screamed out loud and started making it better
> within 48 hours of being forced to use it. And, to distract from that
> product line, there's also RevMobile, RevServer, RevWeb, RevDesktop, and
> whatever the next pre-alpha $400 product is in the pipe.
> 
> That's not to say I don't love the thought of what Rev could be. I want it
> s badly I can taste it. And I'm what you might call a die-hard
> programmer that's programmed everything from 8-bit micro-controllers, Lisp
> compilers, satellite communications, to PS2, Nintendo, 360, and PS3 video
> games for Disney. But, I just love how productive I can be in the 100% live
> environment that Rev provides for me. And, frankly, it's fun as hell and
> even zen-like relaxing at times. ;-)
> 
> But, there have to be consequences for failure. Jerry's a customer. I'm a
> customer. I've been a customer for over a year now, and the bottom line is
> that I've gotten nothing from my maintenance fee for Enterprise except
> continually postponed promises. If it expires before 5.0 comes out, I won't
> renew it. I tried On-Rev and it didn't do what it claimed (for me) either.
> 
> Damn, that was a long-winded way of saying, please cut Jerry some slack.
> He's just another paying customer, and if the service provided doesn't live
> up to his expectations or needs, he moves on. No one should be upset at
> Jerry for any reason at all. If there's anything to be upset about, it would
> be asking one's self, "why on Earth wouldn't Rev do *everything* in their
> power to make such a long-standing customer incredibly happy so he could
> keep advocating Rev and even be able to claim that Rodeo runs on Rev
> servers?"
> 
> Jeff M.
> 
> /emote 

Re: [revServer] process timeout issue

[Chipp Walters]

Jeff,

Honestly, how can you expect a company to fix a problem when they can't
define the bug? Is that too much to ask for before you throw revServer under
the bus?

I, too, have an on-rev account. But I use if for many things outside of
on-rev, including my wordpress blog http://blog.chipp.com along with a
number of SiteGrinder websites including the still in progress Shafer
Walters Group website at:
http://altuit.on-rev.com/swg/swgweb/

(BTW, SiteGrinder rocks!)

I don't use it for Hemingway (our Rev powered CMS) or GadgetPlugins.com
(services all our products and updates to our products). I believe I paid
something like 500 bucks for it at the beginning and nothing since, so I
understand the SLA (or lack thereof) I am receiving. I use dedicated servers
for projects which are, IMO, mission critical to our company and our
clients. Some are hosted at places like Rackspace, other on our own
dedicated hardware at highly secure data centers. And I have some of those
$8.95 a month accounts as well.

I can tell you I've had some lag issues with WordPress and my SiteGrinder
PHP sites at on-rev. When I do, I usually contact Heather or Kevin and
someone somewhere reboots or fixes the machine. That's how it goes at
iPowered and the other hosts as well. I suspect I'm getting about what I
paid for. So, even if the problem is with the on-rev server, it really can't
be fixed until it is identified. That's all I'm saying.
___
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: Harry Potter's magic button - a solution to another tricky group bug

[J. Landman Gay]

On 8/3/10 2:55 PM, Wilhelm Sanke wrote:


1. The magic button - as a workaround - resolves the group bug that

YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER
THAN THE GROUP.

In the case of a smaller image the scriptline "set the loc of image "x"
to the loc of group "y"" will place the image at the topleft corner of
the group instead (unless the loc of the image is already exactly
identical with the group loc).


I downloaded your stack and took a look. The problem isn't an unlocked 
group (your group was locked.) It seems to be the scrollbars around the 
group. If I turn them off, it all works as expected.


So something about a group with scrollbars is causing the problem but I 
can't tell what. By the way, the image doesn't always pop to the top 
left of the group. If you drag it past the bottom right corner, for 
example, it will go almost to the center (but not quite.) So it's being 
offset to the left and top by some amount. Your scrollbars were 
inactive, but the image is behaving as though the group is scrolled and 
it's looking for the center of the virtual group space. It should, of 
course, look for the group's location on the card instead.


I'm not sure why the extra button makes a difference, unless it simply 
jolts the engine into realizing where the topleft corner of the group is.


The work-around would be to turn off scollbars, set the loc of the 
image, and then turn them on again. It should happen pretty fast, but 
you could lock the screen in case.


It would be good to update the bug report so the team knows what exactly 
to look at.


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

Re: [revServer] process timeout issue

[Jeff Massung]

On Tue, Aug 3, 2010 at 7:26 PM, Chipp Walters  wrote:

>
> Unfortunately, Jerry's team cannot provide a recipe where others can
> replicate the buggy behavior which he says is forcing him to choose another
> platform.
> 
>


I've tried to hold back from chiming in on yet another "passionate"
discussion having to do with Rev. Most everyone here is great, and obviously
there are those here intent on trying to diagnose and fix the problem.
Bravo.

Yet, I feel the need to say that I had *extremely* similar issues to Jerry
for the few months I used On-Rev. I had several emails back and forth with
Heather regarding extremely sporadic and spotty access to my site given a
web application I've been developing for quite some time.

While using On-Rev, my user-base (in pre-pre-alpha) consisted of a whopping
8 people, and there would be hours at a time during which my REST API'd
application was just unavailable to my customers. There'd be times where an
average command would take milliseconds, and others when socket operations
would timeout *consistently* (we're talking 20+ second timeouts). This was
just wholly unacceptable for me - as a paying customer.

During this time, Heather and Co. were very responsive and - I think -
understanding of the problem(s) I was facing, but in the end weren't able
to accommodate me in the way I was hoping they would. And that's 100% okay;
no company can meet every customers' needs. So I switched to a different
host, I'm paying more, and have had no problems (other than my own stupid
bugs) since.

It's really great that Rev users love their tool of choice. It's even better
that they want to make it the best it can be. Sometimes I wonder if the Rev
team realizes just how good of a marketing resource they have in their
community. I rarely witness it being coddled, nurtured, loved, and even
taken advantage of (in a good way). If I had such a zealous group behind one
of my products, I'd be here every day trying to grow it.

But, in the end, we're customers. We're not paid advocates - at least I'm
not. If a product I'm paying for isn't working for me, I move on. And - from
what I've read and discussions had - that very much seems to be what Jerry
did with On-Rev. We (and our business ventures) don't have infinite amounts
of time and money in the bank to wait for a product to mature meet our
needs, no matter how badly we want it to. And, likewise, unless the Rev team
is aware that there is a serious risk of losing it's [very loyal] customers,
there's no incentive for them to do better.

If I may venture a guess, I think what most people like about Jerry, his
team, and his products are that they are extremely focused and targeted. And
to make things even better, they eat their own dog food.

>From the outside, the Rev team feels like the exact opposite. I see
nearly-zero focus on anything. On-Rev is > 1 years old now and the IDE is
still something I wouldn't have release to any customer - even as an early
alpha. There's no way they use that tool in-house, because any programmer
worth their salt would have screamed out loud and started making it better
within 48 hours of being forced to use it. And, to distract from that
product line, there's also RevMobile, RevServer, RevWeb, RevDesktop, and
whatever the next pre-alpha $400 product is in the pipe.

That's not to say I don't love the thought of what Rev could be. I want it
s badly I can taste it. And I'm what you might call a die-hard
programmer that's programmed everything from 8-bit micro-controllers, Lisp
compilers, satellite communications, to PS2, Nintendo, 360, and PS3 video
games for Disney. But, I just love how productive I can be in the 100% live
environment that Rev provides for me. And, frankly, it's fun as hell and
even zen-like relaxing at times. ;-)

But, there have to be consequences for failure. Jerry's a customer. I'm a
customer. I've been a customer for over a year now, and the bottom line is
that I've gotten nothing from my maintenance fee for Enterprise except
continually postponed promises. If it expires before 5.0 comes out, I won't
renew it. I tried On-Rev and it didn't do what it claimed (for me) either.

Damn, that was a long-winded way of saying, please cut Jerry some slack.
He's just another paying customer, and if the service provided doesn't live
up to his expectations or needs, he moves on. No one should be upset at
Jerry for any reason at all. If there's anything to be upset about, it would
be asking one's self, "why on Earth wouldn't Rev do *everything* in their
power to make such a long-standing customer incredibly happy so he could
keep advocating Rev and even be able to claim that Rodeo runs on Rev
servers?"

Jeff M.

/emote hunkers down, waiting to dodge incoming flames...
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subsc

Re: [revServer] process timeout issue

[Michael Kann]

Chip,

Don't forget Mary Jane!

Chip wrote: 

I certainly wish Jerry, Sarah, and their extraordinary effort, RODEO, the best 
of success! I think they are on to something great!


Mike



  
___
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: [revServer] process timeout issue

[Chipp Walters]

I am a friend of Jerry's and of Kevin's. I certainly wish Jerry, Sarah and
their extraordinary effort, RODEO, the best of success! I think they are on
to something great!

Unfortunately, Jerry's team cannot provide a recipe where others can
replicate the buggy behavior which he says is forcing him to choose another
platform. If they could supply such a recipe, I feel certain Kevin would
surely address the issue. Also of note is the fact Jerry's RODEO platform
resides on a shared host, with GOD knows what other processes, daemons, etc.
which could also be interjecting themselves into processor performance. It
happens.

I don't think it was necessary to have made a public spectacle of this
on-rev issue. It only casts doubt on the on-rev server platform which,
without a replicatable recipe, doesn't seem to me the gracious thing to do.
I would encourage Jerry and his team to provide such a recipe, which would
then allow others to test and hopefully fix this issue. I think it would be
a great way to resolve this issue without further escalation.

Jerry introduced me to RunRev and has been an ardent supporter of this
technology, and the company for many years. I've worked on projects with
both he and Sarah, and they're both extraordinary programmers and
individuals of the highest character. I hope they will stay and help resolve
this on-rev server problem.
___
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: Mousemove, Optionkey and Windows

[Terry Judd]

On 3/08/10 11:46 PM, "ron barber"  wrote:
> 
> Terry, were you testing on a windows machine or emulation or some sort?
> 
Hi Ron - I'm running Windows under VMWare Fusion.

Terry...

--
Dr Terry Judd | Senior Lecturer in Medical Education
Medical Education Unit
Melbourne Medical School
The University of Melbourne


___
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: Harry Potter's magic button - a solution to another tricky group bug

[Geoff Canyon Rev]

Not sure, but I'd guess that the OP is falling afoul of the elastic
nature of groups that have lockloc=false. When that is the case,
groups automatically snap to the bounds of whatever they contain
whenever they get the chance -- i.e. when the things they contain move
or are themselves resized (I believe, I haven't tested all the
variations here). That can cause some unexpected behavior if you're
expecting groups to behave as if their lockloc were true, which allows
them to be sized and positioned as most other controls are (whether
those controls have their lockloc set to true or false).

gc

On Tue, Aug 3, 2010 at 3:21 PM,   wrote:
> Me, too, with a group and an even smaller image.
>
> If I set the loc of the image to a point outside the group, the group
> expands to contain it, as usual. If I set it to a point anywhere inside the
> group, again, the group extent adjusts.
>
> On a Mac. Does this matter?
>
> Craig Newman
> ___
> 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: Harry Potter's magic button - a solution to another tricky group bug

[DunbarX]

Me, too, with a group and an even smaller image.

If I set the loc of the image to a point outside the group, the group 
expands to contain it, as usual. If I set it to a point anywhere inside the 
group, again, the group extent adjusts.

On a Mac. Does this matter?

Craig Newman
___
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: Harry Potter's magic button - a solution to another tricky group bug

[J. Landman Gay]

On 8/3/10 2:55 PM, Wilhelm Sanke wrote:


YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER
THAN THE GROUP.

In the case of a smaller image the scriptline "set the loc of image "x"
to the loc of group "y"" will place the image at the topleft corner of
the group instead (unless the loc of the image is already exactly
identical with the group loc).


I haven't looked at your stack yet but I just did a quick test with a 
new stack, new group, and a small image inside the group, and I had no 
trouble setting the image location anywhere from the message box, 
including setting it to the loc of the group. Maybe there is something 
else required for it to fail?


My group had 2 buttons and a small image, and the lockloc was set to 
true. The group was the normal default size that encompassed the 2 
buttons which served as "anchors" at the top left and lower right of the 
group.


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

Harry Potter's magic button: link to sample stack

[Wilhelm Sanke]

I see that the link provided for the sample stack lacked an underscore. This 
should work:



Wilhelm Sanke

___
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

Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

I was so intrigued by the various effects of the workaround that I 
included "magic" in the subject line. Bringing Harry Potter into play 
may also help to start  the process of improvements for Revolution 
announced by Kevin last week, namely - among them - better communication 
with users and the total overhaul of the Revolution bug management 
system along with quicker bug fixes (after all,. the "Hogwarts School of 
Witchcraft and Wizardry" is located not far from Edinburgh, which will 
facilitate the exchange of ideas).
Once the Revolution programmers responsible for bug fixes will have 
analysed and understood what is going on behind the scenes - in the 
engine - concerning this bug and the workaround, they will be much 
better equipped to tackle the 9 remaining bugs associated with groups, too.


A sample stack that demonstrates bug and workaround can be downloaded 
from here:




There are basically four aspects to this magic:

1. The magic button - as a workaround - resolves the group bug that

YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER 
THAN THE GROUP.


In the case of a smaller image the scriptline "set the loc of image "x" 
to the loc of group "y"" will place the image at the topleft corner of 
the group instead (unless the loc of the image is already exactly 
identical with the group loc).


Now, after you put Harry Potter's button into the upperleft corner of 
the group, the above scriptline with "set the loc" will now work as it 
should. It is essential here that the magic button is visible in the 
sense that its visibility is set to true. But you could shove the button 
under the topleft corner of the group so that it actually becomes 
invisible and it will nevertheless continue to exert its spell.


The moment you hide the button, i.e. with "hide" or "set the vis to 
false", the image will snap again to a topleft position in the group.


2. The magic button can be moved across the visible part of the group 
area by script - diagonally, horizontally, vertically - without being 
addressed with its name or any other identifier. One precondition for 
this to happen is that the image is at least 1 pixel off the loc of the 
group.


 Place the button anywhere in the group, press button "center image 
using "set the loc"" repeatedly, and the magic button will move in steps 
until it reaches the upperleft corner of the group. The first time you 
press the button the image will be also be placed at the topleft of the 
group with only one step.


The distance the magic button will move vertically and horizontally with 
a step is different with image size and dependent on the height and 
width of the image, e.g. with a broader image the horizontal steps will 
be much smaller, with a smaller height the steps will be bigger. You can 
see this best with image "Steve and friend" (Steve Jobs, the iPhone, and 
Medwedjew), but I recommend to try out the options of the sample stack 
with image "Red Square" first.


3. An interesting variant of 2. is the "split button":

Place the magic button at the bottomleft corner of the group. Make sure 
the image is at least 1 pixel off the loc of the group (Both the button 
and the image have a "grab me" script, so you can do this manually with 
mousedown).


Now, as above in "2." press button "center image using "set the loc"" . 
The magic button will move upwards in steps. When it has reached the 
area of the image the button will "split". The part of the button 
intersecting with the image will continue to move upwards. The left part 
of the button will remain in place until the right part of the button 
has reached the top of the group. At that moment the two separate parts 
of the magic button will re-unite.


If you place the button to the right of the group, the splitting of the 
button will occur horizontally.--


There are three special buttons in the sample stack that demonstrate 
these effects (2. and 3.) automated with repeat loops.
At the top of these scripts for the automated demonstrations I make use 
of the move command (which is not broken)  to make sure image and magic 
button are placed at the appropriate places, but for creating the 
effects the broken "set" command is used inside the repeat loops.



4. Button "reset image" will restore the original imagedata stored in a 
custom property and center the image using the "move" command.


When you have placed the magic button somewhere on the group area like 
above in points 2. and 3. and you then press the "reset image" button 
repeatedly the magic button will also move in steps towards the topleft 
of the group, but without producing the "split" effect.




A few more particulars and peculiarities for those interested in getting 
a broader picture:


If the magic button is absent or hidden and you have managed to center 
the image (either by using the "move" command or by dragging the image 
man

Re: Order layer of image in a group ...

[DunbarX]

Check out the "relayerGroupControls" property. You need to set it to 
"true". Check out the dictionary. There are a few hints and caveats.

Craig Newman
___
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: Setting Cookies and On-rev

[Pierre Sahores]

Andre,

Well done ! Your revSpark "partition" is realy amazing !

Kind Regards,

Pierre

> Gregory,
> 
> check out http://hg.andregarzia.com/revspark/src/tip/revspark.inc and check
> setCookie and getCookies handlers
> 
> Andre

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.wrds.com
www.sahores-conseil.com




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Order layer of image in a group ...

[Jean-Pierre Soto]

Hello

how can I order layer of a newly created image inside a group ?

Thanks


___
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: Setting Cookies and On-rev

[Pierre Sahores]

Hello Gregory,

Out of the wrds.com irev lib :

1.- To retrieve the cookies datas :

put item itemoffset("firstcookie",$_SERVER[HTTP_COOKIE]) of 
$_SERVER[HTTP_COOKIE] into rusersid
split rusersid by ";" and "="
etc...

2.- To store new cookies along the page to output to the end-user browser 
(javascript) dynamically populated by the irev lib:

replace "###scwordscawayasid###" with "45485ui5i85485ti5on5545ti57" in tvar (in 
the reality, some kind of encrypted datas)

2.1.- where tvar contains, at least :





Best Regards,

Pierre


Le 3 août 2010 à 21:03, Gregory Lypny a écrit :

> Hello everyone,
> 
> I want to create a simple login form and was wondering whether we have any 
> examples of setting and getting cookies.  I did find a discussion of this on 
> the On-Rev forum dated August 2009, but I'm not sure whether there is 
> anything more recent I should be reading.
> 
> Regards,
> 
> Gregory
> 
> 
> ___
> 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
> 

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.wrds.com
www.sahores-conseil.com






___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Setting Cookies and On-rev

[Andre Garzia]

Gregory,

check out http://hg.andregarzia.com/revspark/src/tip/revspark.inc and check
setCookie and getCookies handlers

Andre

On Tue, Aug 3, 2010 at 4:03 PM, Gregory Lypny wrote:

> Hello everyone,
>
> I want to create a simple login form and was wondering whether we have any
> examples of setting and getting cookies.  I did find a discussion of this on
> the On-Rev forum dated August 2009, but I'm not sure whether there is
> anything more recent I should be reading.
>
> Regards,
>
> Gregory
>
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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

Setting Cookies and On-rev

[Gregory Lypny]

Hello everyone,

I want to create a simple login form and was wondering whether we have any 
examples of setting and getting cookies.  I did find a discussion of this on 
the On-Rev forum dated August 2009, but I'm not sure whether there is anything 
more recent I should be reading.

Regards,

Gregory


___
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: [revServer] process timeout issue

[Pierre Sahores]

Good, is'nt it ? Thanks for your participation, Mark.

Best,

Pierre

Le 3 août 2010 à 18:52, Mark Wieder a écrit :

> hi-
> 
> I'm late to the party, I know, but I wanted to post that my results
> were similar within the 99% range, with the longest taking just a
> shade over two seconds and 75% of the requests coming in under 100
> milliseconds. And that's *very* impressive considering the fact that
> if I ping wrds.com I get an 86 millisecond response, so the
> server overhead in processing my response accounts for some 14
> milliseconds in most cases.
> 
> I launched the two tests concurrently to stress things
> out a bit more, but that didn't seem to affect the results.
> 
> ---
> 
> Benchmarking wrds.com (be patient)
> Finished 2975 requests
> 
> 
> Server Software:Apache/2.0.63
> Server Hostname:wrds.com
> Server Port:80
> 
> Document Path:  /index.html
> Document Length:417 bytes
> 
> Concurrency Level:  10
> Time taken for tests:   30.001 seconds
> Complete requests:  2975
> Failed requests:0
> Write errors:   0
> Non-2xx responses:  2975
> Keep-Alive requests:2953
> Total transferred:  2322450 bytes
> HTML transferred:   1240575 bytes
> Requests per second:99.16 [#/sec] (mean)
> Time per request:   100.844 [ms] (mean)
> Time per request:   10.084 [ms] (mean, across all concurrent requests)
> Transfer rate:  75.60 [Kbytes/sec] received
> 
> Connection Times (ms)
>  min  mean[+/-sd] median   max
> Connect:01  10.7  0 124
> Processing:92  100  47.8 971845
> Waiting:   92  100  47.8 971845
> Total: 92  101  52.6 971964
> 
> Percentage of the requests served within a certain time (ms)
>  50% 97
>  66% 98
>  75% 99
>  80%100
>  90%102
>  95%108
>  98%122
>  99%185
> 100%   1964 (longest request)
> 
> Benchmarking wrds.com (be patient)
> Finished 2835 requests
> 
> 
> Server Software:Apache/2.0.63
> Server Hostname:wrds.com
> Server Port:80
> 
> Document Path:  /index.irev
> Document Length:417 bytes
> 
> Concurrency Level:  10
> Time taken for tests:   30.002 seconds
> Complete requests:  2835
> Failed requests:0
> Write errors:   0
> Non-2xx responses:  2835
> Keep-Alive requests:2815
> Total transferred:  2213245 bytes
> HTML transferred:   1182195 bytes
> Requests per second:94.49 [#/sec] (mean)
> Time per request:   105.829 [ms] (mean)
> Time per request:   10.583 [ms] (mean, across all concurrent requests)
> Transfer rate:  72.04 [Kbytes/sec] received
> 
> Connection Times (ms)
>  min  mean[+/-sd] median   max
> Connect:01  12.0  0 145
> Processing:92  104 106.2 972069
> Waiting:   92  104 106.2 972069
> Total: 92  106 113.3 972191
> 
> Percentage of the requests served within a certain time (ms)
>  50% 97
>  66% 98
>  75% 99
>  80%100
>  90%103
>  95%110
>  98%117
>  99%197
> 100%   2191 (longest request)
> 
> -- 
> -Mark Wieder
> mwie...@ahsoftware.net
> 
> ___
> 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
> 

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.wrds.com
www.sahores-conseil.com






___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [revServer] process timeout issue

[Richard Gaskin]

Andre Garzia wrote:


oh that is *fast* :-O


Last year I had one of my fits of obsession about performance and began 
experimenting with Dreamhost's FastCGI interface for the Rev CGI.  It 
was complicated to set up, and for all the reasons you noted here at the 
time it was very complicated to write for.


So instead I decided to set it aside and go back to the straight CGI 
interface to see if I found any serious bottlenecks.  I found none, and 
the clarity of writing for a non-persistent process kept everything 
simple.  I added a reasonably simple token file+cookie scheme for 
persistent data when needed, but for most uses I don't even need that, 
and with or without that it's been quite speedy.


On the desktop the engine loads faster than most other apps, and on the 
server - without needing to initialize the GUI -- it loads about as fast 
as a server can pull its mere 2.5 MB executable up from the 7200 RPM disk.


I've not done much in the way of formal testing because I haven't yet 
found a good means of accounting for sever/transfer latency as distinct 
from the Rev process itself.  But the server-side testing I've done 
shows the CGI engine running at speeds better than on my Mac (not 
surprising; Dreamhost uses some good systems), and the subjective 
experience of the overall throughput has been quite satisfying for 
myself and my site's visitors.


--
 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



On Tue, Aug 3, 2010 at 1:52 PM, Mark Wieder  wrote:


hi-

I'm late to the party, I know, but I wanted to post that my resultsat
were similar within the 99% range, with the longest taking just a
shade over two seconds and 75% of the requests coming in under 100
milliseconds. And that's *very* impressive considering the fact that
if I ping wrds.com I get an 86 millisecond response, so the
server overhead in processing my response accounts for some 14
milliseconds in most cases.

I launched the two tests concurrently to stress things
out a bit more, but that didn't seem to affect the results.

---

Benchmarking wrds.com (be patient)
Finished 2975 requests


Server Software:Apache/2.0.63
Server Hostname:wrds.com
Server Port:80

Document Path:  /index.html
Document Length:417 bytes

Concurrency Level:  10
Time taken for tests:   30.001 seconds
Complete requests:  2975
Failed requests:0
Write errors:   0
Non-2xx responses:  2975
Keep-Alive requests:2953
Total transferred:  2322450 bytes
HTML transferred:   1240575 bytes
Requests per second:99.16 [#/sec] (mean)
Time per request:   100.844 [ms] (mean)
Time per request:   10.084 [ms] (mean, across all concurrent requests)
Transfer rate:  75.60 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:01  10.7  0 124
Processing:92  100  47.8 971845
Waiting:   92  100  47.8 971845
Total: 92  101  52.6 971964

Percentage of the requests served within a certain time (ms)
  50% 97
 66% 98
 75% 99
 80%100
 90%102
 95%108
 98%122
 99%185
 100%   1964 (longest request)

Benchmarking wrds.com (be patient)
Finished 2835 requests


Server Software:Apache/2.0.63
Server Hostname:wrds.com
Server Port:80

Document Path:  /index.irev
Document Length:417 bytes

Concurrency Level:  10
Time taken for tests:   30.002 seconds
Complete requests:  2835
Failed requests:0
Write errors:   0
Non-2xx responses:  2835
Keep-Alive requests:2815
Total transferred:  2213245 bytes
HTML transferred:   1182195 bytes
Requests per second:94.49 [#/sec] (mean)
Time per request:   105.829 [ms] (mean)
Time per request:   10.583 [ms] (mean, across all concurrent requests)
Transfer rate:  72.04 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:01  12.0  0 145
Processing:92  104 106.2 972069
Waiting:   92  104 106.2 972069
Total: 92  106 113.3 972191

Percentage of the requests served within a certain time (ms)
  50% 97
 66% 98
 75% 99
 80%100
 90%103
 95%110
 98%117
 99%197
 100%   2191 (longest request)

--
-Mark Wieder
 mwieder at ahsoftware.net

___
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution





--
http://www.andregarzia.com All We Do Is Code.


___
use-revolution mailing li

Re: [revServer] process timeout issue

[Andre Garzia]

this would not work here in Brazil, the bugs would shot back...

On Tue, Aug 3, 2010 at 1:54 PM, Bob Sneidar  wrote:

> Little too complicated for me. I just shoot at problems with a shotgun and
> then check to see if I hit anything.
>
> Bob
>
>
> On Aug 3, 2010, at 6:47 AM, Andre Garzia wrote:
>
> > Folks,
> >
> > I never seen a RevServer bug like those timeouts and stuff and of course
> > Jerry is not making it up, so the logical conclusion is that there's some
> > specific case(s) where a RevServer script can go loco and fail.
> >
> > After that conclusion, our first requirement is to draw a mental map of
> what
> > is involved. Now repeat after me SETUP
> >
> > S - Scenario (what are they building)
> > E - Environment (what is the surrounding environment)
> > T - Technology (what are they using)
> > U - Usage Case (what happened/when happened)
> > P - Possible Points of Failure (critical things that need assessment)
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: [revServer] process timeout issue

[Mark Wieder]

Andre-

Tuesday, August 3, 2010, 9:54:15 AM, you wrote:

> oh that is *fast* :-O

...and I should point out that it's an on-rev server...

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: [revServer] process timeout issue

[Bob Sneidar]

Little too complicated for me. I just shoot at problems with a shotgun and then 
check to see if I hit anything. 

Bob


On Aug 3, 2010, at 6:47 AM, Andre Garzia wrote:

> Folks,
> 
> I never seen a RevServer bug like those timeouts and stuff and of course
> Jerry is not making it up, so the logical conclusion is that there's some
> specific case(s) where a RevServer script can go loco and fail.
> 
> After that conclusion, our first requirement is to draw a mental map of what
> is involved. Now repeat after me SETUP
> 
> S - Scenario (what are they building)
> E - Environment (what is the surrounding environment)
> T - Technology (what are they using)
> U - Usage Case (what happened/when happened)
> P - Possible Points of Failure (critical things that need assessment)

___
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: [revServer] process timeout issue

[Andre Garzia]

oh that is *fast* :-O

On Tue, Aug 3, 2010 at 1:52 PM, Mark Wieder  wrote:

> hi-
>
> I'm late to the party, I know, but I wanted to post that my resultsat
> were similar within the 99% range, with the longest taking just a
> shade over two seconds and 75% of the requests coming in under 100
> milliseconds. And that's *very* impressive considering the fact that
> if I ping wrds.com I get an 86 millisecond response, so the
> server overhead in processing my response accounts for some 14
> milliseconds in most cases.
>
> I launched the two tests concurrently to stress things
> out a bit more, but that didn't seem to affect the results.
>
> ---
>
> Benchmarking wrds.com (be patient)
> Finished 2975 requests
>
>
> Server Software:Apache/2.0.63
> Server Hostname:wrds.com
> Server Port:80
>
> Document Path:  /index.html
> Document Length:417 bytes
>
> Concurrency Level:  10
> Time taken for tests:   30.001 seconds
> Complete requests:  2975
> Failed requests:0
> Write errors:   0
> Non-2xx responses:  2975
> Keep-Alive requests:2953
> Total transferred:  2322450 bytes
> HTML transferred:   1240575 bytes
> Requests per second:99.16 [#/sec] (mean)
> Time per request:   100.844 [ms] (mean)
> Time per request:   10.084 [ms] (mean, across all concurrent requests)
> Transfer rate:  75.60 [Kbytes/sec] received
>
> Connection Times (ms)
>  min  mean[+/-sd] median   max
> Connect:01  10.7  0 124
> Processing:92  100  47.8 971845
> Waiting:   92  100  47.8 971845
> Total: 92  101  52.6 971964
>
> Percentage of the requests served within a certain time (ms)
>   50% 97
>  66% 98
>  75% 99
>  80%100
>  90%102
>  95%108
>  98%122
>  99%185
>  100%   1964 (longest request)
>
> Benchmarking wrds.com (be patient)
> Finished 2835 requests
>
>
> Server Software:Apache/2.0.63
> Server Hostname:wrds.com
> Server Port:80
>
> Document Path:  /index.irev
> Document Length:417 bytes
>
> Concurrency Level:  10
> Time taken for tests:   30.002 seconds
> Complete requests:  2835
> Failed requests:0
> Write errors:   0
> Non-2xx responses:  2835
> Keep-Alive requests:2815
> Total transferred:  2213245 bytes
> HTML transferred:   1182195 bytes
> Requests per second:94.49 [#/sec] (mean)
> Time per request:   105.829 [ms] (mean)
> Time per request:   10.583 [ms] (mean, across all concurrent requests)
> Transfer rate:  72.04 [Kbytes/sec] received
>
> Connection Times (ms)
>  min  mean[+/-sd] median   max
> Connect:01  12.0  0 145
> Processing:92  104 106.2 972069
> Waiting:   92  104 106.2 972069
> Total: 92  106 113.3 972191
>
> Percentage of the requests served within a certain time (ms)
>   50% 97
>  66% 98
>  75% 99
>  80%100
>  90%103
>  95%110
>  98%117
>  99%197
>  100%   2191 (longest request)
>
> --
> -Mark Wieder
>  mwie...@ahsoftware.net
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: [revServer] process timeout issue

[Bob Sneidar]

Men have been flogged for less. ;-)

Bob


On Aug 2, 2010, at 7:20 PM, Jerry Daniels wrote:

> I just said "yes"
> 
> On Aug 2, 2010, at 9:19 PM, Michael Kann wrote:
> 
>> Jerry and Robert,
>> 
>> To summarize:
>> 
>> Austin and Edinburgh got into a pissing match.
>> 
>> Mike
> 

___
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: [revServer] process timeout issue

[Mark Wieder]

hi-

I'm late to the party, I know, but I wanted to post that my results
were similar within the 99% range, with the longest taking just a
shade over two seconds and 75% of the requests coming in under 100
milliseconds. And that's *very* impressive considering the fact that
if I ping wrds.com I get an 86 millisecond response, so the
server overhead in processing my response accounts for some 14
milliseconds in most cases.

I launched the two tests concurrently to stress things
out a bit more, but that didn't seem to affect the results.

---

Benchmarking wrds.com (be patient)
Finished 2975 requests


Server Software:Apache/2.0.63
Server Hostname:wrds.com
Server Port:80

Document Path:  /index.html
Document Length:417 bytes

Concurrency Level:  10
Time taken for tests:   30.001 seconds
Complete requests:  2975
Failed requests:0
Write errors:   0
Non-2xx responses:  2975
Keep-Alive requests:2953
Total transferred:  2322450 bytes
HTML transferred:   1240575 bytes
Requests per second:99.16 [#/sec] (mean)
Time per request:   100.844 [ms] (mean)
Time per request:   10.084 [ms] (mean, across all concurrent requests)
Transfer rate:  75.60 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:01  10.7  0 124
Processing:92  100  47.8 971845
Waiting:   92  100  47.8 971845
Total: 92  101  52.6 971964

Percentage of the requests served within a certain time (ms)
  50% 97
  66% 98
  75% 99
  80%100
  90%102
  95%108
  98%122
  99%185
 100%   1964 (longest request)

Benchmarking wrds.com (be patient)
Finished 2835 requests


Server Software:Apache/2.0.63
Server Hostname:wrds.com
Server Port:80

Document Path:  /index.irev
Document Length:417 bytes

Concurrency Level:  10
Time taken for tests:   30.002 seconds
Complete requests:  2835
Failed requests:0
Write errors:   0
Non-2xx responses:  2835
Keep-Alive requests:2815
Total transferred:  2213245 bytes
HTML transferred:   1182195 bytes
Requests per second:94.49 [#/sec] (mean)
Time per request:   105.829 [ms] (mean)
Time per request:   10.583 [ms] (mean, across all concurrent requests)
Transfer rate:  72.04 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:01  12.0  0 145
Processing:92  104 106.2 972069
Waiting:   92  104 106.2 972069
Total: 92  106 113.3 972191

Percentage of the requests served within a certain time (ms)
  50% 97
  66% 98
  75% 99
  80%100
  90%103
  95%110
  98%117
  99%197
 100%   2191 (longest request)
 
-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: [revServer] process timeout issue

[Richard Gaskin]

Jerry Daniels wrote:

> This thread has repeatedly gone from the revServer timeout issue
> to personalities, Rodeo and its choice of technologies.

Respectfully, may I note that the last several posts on this (from Sean, 
Andre, Michael, and myself) have attempted to help focus the discussion 
on a rational analysis of the problem suggested, looking at this as a 
RevServer issue and not a Rodeo-specific one.  Given the potential 
usefulness of this new product, I think it's helpful to continue its 
exploration along these lines.


If Oliver's comment about "iRev" meant to refer to on-rev.com (which it 
turns out was the subject of that thread -- see 
), the 
situation is readily understandable and poses no problem to anyone 
wanting to use RevServer on a dedicated server.  Shared-hosting servers 
commonly impose such limits on all processes, including PHP, and for 
good reason.  Anyone wanting to dominate a machine's CPU would expect to 
use a dedicated server.


If instead Oliver's comment was referring to the RevServer engine itself 
then it would indeed limit the appeal of the product for use on 
dedicated servers, but we have yet to determine:


a) whether that's the case.

b) if it is, whether that's the intended behavior when using RevServer 
on a dedicated server or is merely a bug which could be fixed in the 
next build.


c) how it's even possible for a single child process to govern aggregate 
server-wide limits (if it is there may be some useful hacks and/or 
interesting security exposures worth exploring).


So far the analysis provided by Andre and Pierre suggests that any 
limits on cycles or memory exit only in the common configs for shared 
hosting services such as on-rev.com and are not specific to the 
RevServer engine itself.  Andrew Dickey's astute comments in the forum 
and the improve-rev list refer only to on-rev.com; I haven't yet seen 
claims that such limits have been observed on a dedicated server.


For my own part, while I have no experience with RevServer itself yet 
I've done enough work on public sites using Rev CGI that I know the 
RunRev team is capable of delivering a robust, flexible engine that 
performs on par or better than many alternatives (Rev's well-optimized 
chunk expressions rule for many server tasks).  One of the systems I've 
developed is used by hundreds of hospitals worldwide with Rev-based CGIs 
handling login, registration, and even a custom search engine and it's 
held up quite well, so I feel we all have good reason expect the same of 
at least the release version of RevServer if not the version we have 
available now.


I have no opinion about Rodeo or its choice of technologies, and as far 
as personalities go I like yours a lot and like many here regard Sarah 
as a generous code goddess. :)


My interest here is simply that I have a lot of resources invested in 
the Rev CGI and may migrate some of those to RevServer, so it's useful 
for me and anyone else here considering RevServer to pursue a solid 
understanding of that engine.


--
 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
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: [revServer] process timeout issue

[Pierre Sahores]

Andre,

Your 3 tests are running 100% successfully from there, too :-)

All the best,

Pierre 



Le 3 août 2010 à 16:54, Andre Garzia a écrit :

> Thanks for the kind words Jerry! :D
> 
> Folks,
> 
> Moving this back onto RevServer, here goes a cross-post from the improve
> list:
> 
> I believe the limits are not on RevServer itself but on the virtualization
> stack used on On-Rev. I have RevServer running on my own web server here and
> I just did two tests:
> 
> * A RevServer script that takes 40 seconds to load.
> * A RevServer script that uses 90MB of memory.
> * A RevServer script that uses 225MB and takes 40 seconds to load.
> 
> http://andregarzia.com/memory.irev
> http://andregarzia.com/40secs.irev
> http://andregarzia.com/supertest.irev
> 
> Then I've run 30 requests at 5 concurrency level against memory.irev. The
> memory one completed without a single failure, it completed in 7 seconds for
> all the 30 requests, no errors, timeouts or hiccups.
> 
> I could not use "ab" to test the ones with a wait in them because my "ab" is
> not honoring the timeout settings. So if I set the timeout to 2 minutes, it
> still timeout at couple seconds. Bug on my side not the RevServer side, all
> pages load fine on the web.
> 
> So now we know scripts can take forever to run (40 seconds is forever) and
> use big amount of RAM (225MB). I am using http://jaguarpc.com with their VPS
> TWO plan.
> 
> 
> 
> -- 
> http://www.andregarzia.com All We Do Is Code.
> ___
> 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
> 

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.wrds.com
www.sahores-conseil.com





___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [revServer] process timeout issue

[Michael Kann]

Jerry,

That new site looks sharp.

Mike

--- On Tue, 8/3/10, Jerry Daniels  wrote:

From: Jerry Daniels 
Subject: Re: [revServer] process timeout issue
To: "How to use Revolution" 
Date: Tuesday, August 3, 2010, 9:37 AM

Andre,

I have to say, I love your attitude, helpfulness and person. It seems that 
Rodeo would make an excellent case study for fixing and diagnosing revServer. 
However, actual experience right here in this thread tells you otherwise.

Our decisions about using a technology are not just about technology itself. 
They are about business, money, time and people as well. 

I think the Rodeo team has made good decisions so far. Why? We've met and 
exceeded our publicized milestones. We've also hit our revenue/subscription 
goals today--four weeks early. That means a lot of people agree with our 
decisions.

This thread has repeatedly gone from the revServer timeout issue to 
personalities, Rodeo and its choice of technologies. And my attempts at humor 
(to get folks to lighten up) actually had the opposite effect.

We will not be answering direct, indirect, implied or other questions about 
Rodeo here on this list. 

We've gotten a new site to deliver the intellectual property Daniels & Mara has 
created. It has better threaded discussions, mail notifications, etc., so 
there's no reason to use this list to discuss Rodeo-related matters.

Here's the place:

http://alltiera.com/discussion

Best,

Jerry Daniels

On Aug 3, 2010, at 8:47 AM, Andre Garzia wrote:

> Folks,
> 
> I never seen a RevServer bug like those timeouts and stuff and of course
> Jerry is not making it up, so the logical conclusion is that there's some
> specific case(s) where a RevServer script can go loco and fail.
> 
> After that conclusion, our first requirement is to draw a mental map of what
> is involved. Now repeat after me SETUP
> 
> S - Scenario (what are they building)
> E - Environment (what is the surrounding environment)
> T - Technology (what are they using)
> U - Usage Case (what happened/when happened)
> P - Possible Points of Failure (critical things that need assessment)
> 
> === Scenario ===
> Jerry, Sarah and Mary are building some amazing tools. They have a new
> development tool that is powered by new xTalk like language called LIST.
> Their system works by doing conversions on that LIST language to present
> HTML5, Javascript, CSS web application. Their applications are AJAX powered
> and a round trip to the server is needed to execute LIST ACTIONS (is this
> true?)
> 
> === Environment ===
> Rodeo server was a RevServer built solution hosted at a datacenter. Is it
> hosted at On-Rev or is it hosted privatelly? Where is it hosted?
> 
> === Technology ===
> Is Rodeo on virtualized hardware? Shared accounts? VPS? Which database was
> used? Is it being served with Apache?
> 
> === Usage Case ===
> Can RevServer timeout be narrowed to some usage scenario? For example did it
> happened while  huge conversions of LIST were taking place? Did it happen
> while complex database calls were being executed? Was it completelly random?
> 
> === Possible Points of Failure ===
> If RevServer failed for a SANE REASON, meaning, it didn't simply exploded
> out of nowhere then the most probable causes are:
> * Memory Exaustion: RevServer script took more than it was allowed to chew
> and was terminated.
> * CPU Thief: RevServer script decided that the CPU was his alone and maxed
> it for more time than allowed. Terminated with prejudice.
> * Timeout: RevServer script started ponderating on the meaning of life while
> doing its chores, takes forever, terminated by virtualization police.
> 
> These are the sane reasons for a process to be terminated by the system.
> Could it be that RevServer is crashing, crashing is not the same as being
> terminated. Being terminated means that you are working correctly but for
> some reason or policy your process is terminated, crashing means somewhere
> inside RevServer engine something went nuts and it died.
> 
> Now we don't know the answers to those questions but those are questions
> that all should ask while facing problems with server side stuff. Server
> side is hard and while on the Desktop is OK to make a little standalone that
> allocated half a gig of memory, at the server side there's a big change that
> you will not be allowed to do that.
> 
> There are to many possible points of failures and things to keep attention
> specially when you are building something as big as Rodeo. I am sure that
> Jerry and Sarah investigated their possibilities and reasoned what to do. In
> the end it is just a compromise about where you want to stop and work. They
> decided to move that technology to other engine. It is OK. Had they decided
> otherwise it would be OK too.
> 
> Yesterday me and Pierre did some stress testing on his site. I've run 25
> concurrent access for 30 secs on his site, of course I've run it from a
> single machine and thus it is not the best benchmark possible but I d

Re: [revServer] process timeout issue

[Andre Garzia]

Thanks for the kind words Jerry! :D

Folks,

Moving this back onto RevServer, here goes a cross-post from the improve
list:

I believe the limits are not on RevServer itself but on the virtualization
stack used on On-Rev. I have RevServer running on my own web server here and
I just did two tests:

* A RevServer script that takes 40 seconds to load.
* A RevServer script that uses 90MB of memory.
* A RevServer script that uses 225MB and takes 40 seconds to load.

http://andregarzia.com/memory.irev
http://andregarzia.com/40secs.irev
http://andregarzia.com/supertest.irev

Then I've run 30 requests at 5 concurrency level against memory.irev. The
memory one completed without a single failure, it completed in 7 seconds for
all the 30 requests, no errors, timeouts or hiccups.

I could not use "ab" to test the ones with a wait in them because my "ab" is
not honoring the timeout settings. So if I set the timeout to 2 minutes, it
still timeout at couple seconds. Bug on my side not the RevServer side, all
pages load fine on the web.

So now we know scripts can take forever to run (40 seconds is forever) and
use big amount of RAM (225MB). I am using http://jaguarpc.com with their VPS
TWO plan.



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: [revServer] process timeout issue

[Jerry Daniels]

Andre,

I have to say, I love your attitude, helpfulness and person. It seems that 
Rodeo would make an excellent case study for fixing and diagnosing revServer. 
However, actual experience right here in this thread tells you otherwise.

Our decisions about using a technology are not just about technology itself. 
They are about business, money, time and people as well. 

I think the Rodeo team has made good decisions so far. Why? We've met and 
exceeded our publicized milestones. We've also hit our revenue/subscription 
goals today--four weeks early. That means a lot of people agree with our 
decisions.

This thread has repeatedly gone from the revServer timeout issue to 
personalities, Rodeo and its choice of technologies. And my attempts at humor 
(to get folks to lighten up) actually had the opposite effect.

We will not be answering direct, indirect, implied or other questions about 
Rodeo here on this list. 

We've gotten a new site to deliver the intellectual property Daniels & Mara has 
created. It has better threaded discussions, mail notifications, etc., so 
there's no reason to use this list to discuss Rodeo-related matters.

Here's the place:

http://alltiera.com/discussion

Best,

Jerry Daniels

On Aug 3, 2010, at 8:47 AM, Andre Garzia wrote:

> Folks,
> 
> I never seen a RevServer bug like those timeouts and stuff and of course
> Jerry is not making it up, so the logical conclusion is that there's some
> specific case(s) where a RevServer script can go loco and fail.
> 
> After that conclusion, our first requirement is to draw a mental map of what
> is involved. Now repeat after me SETUP
> 
> S - Scenario (what are they building)
> E - Environment (what is the surrounding environment)
> T - Technology (what are they using)
> U - Usage Case (what happened/when happened)
> P - Possible Points of Failure (critical things that need assessment)
> 
> === Scenario ===
> Jerry, Sarah and Mary are building some amazing tools. They have a new
> development tool that is powered by new xTalk like language called LIST.
> Their system works by doing conversions on that LIST language to present
> HTML5, Javascript, CSS web application. Their applications are AJAX powered
> and a round trip to the server is needed to execute LIST ACTIONS (is this
> true?)
> 
> === Environment ===
> Rodeo server was a RevServer built solution hosted at a datacenter. Is it
> hosted at On-Rev or is it hosted privatelly? Where is it hosted?
> 
> === Technology ===
> Is Rodeo on virtualized hardware? Shared accounts? VPS? Which database was
> used? Is it being served with Apache?
> 
> === Usage Case ===
> Can RevServer timeout be narrowed to some usage scenario? For example did it
> happened while  huge conversions of LIST were taking place? Did it happen
> while complex database calls were being executed? Was it completelly random?
> 
> === Possible Points of Failure ===
> If RevServer failed for a SANE REASON, meaning, it didn't simply exploded
> out of nowhere then the most probable causes are:
> * Memory Exaustion: RevServer script took more than it was allowed to chew
> and was terminated.
> * CPU Thief: RevServer script decided that the CPU was his alone and maxed
> it for more time than allowed. Terminated with prejudice.
> * Timeout: RevServer script started ponderating on the meaning of life while
> doing its chores, takes forever, terminated by virtualization police.
> 
> These are the sane reasons for a process to be terminated by the system.
> Could it be that RevServer is crashing, crashing is not the same as being
> terminated. Being terminated means that you are working correctly but for
> some reason or policy your process is terminated, crashing means somewhere
> inside RevServer engine something went nuts and it died.
> 
> Now we don't know the answers to those questions but those are questions
> that all should ask while facing problems with server side stuff. Server
> side is hard and while on the Desktop is OK to make a little standalone that
> allocated half a gig of memory, at the server side there's a big change that
> you will not be allowed to do that.
> 
> There are to many possible points of failures and things to keep attention
> specially when you are building something as big as Rodeo. I am sure that
> Jerry and Sarah investigated their possibilities and reasoned what to do. In
> the end it is just a compromise about where you want to stop and work. They
> decided to move that technology to other engine. It is OK. Had they decided
> otherwise it would be OK too.
> 
> Yesterday me and Pierre did some stress testing on his site. I've run 25
> concurrent access for 30 secs on his site, of course I've run it from a
> single machine and thus it is not the best benchmark possible but I did this
> multiple times and his did it at the same time as well and maybe others did
> to. On my tests there was not a single error. Some requests took longer
> thant others but this can happen for many resons including p

Re: [revServer] process timeout issue

[Richard Gaskin]

I've been thinking about this and I just can't wrap my head around it:

How can a single non-persistent child process like a CGI or RevServer 
govern server-wide settings like aggregate multi-process memory and time 
limits?


Such limits are common on shared servers like on-rev.com and easy to set 
up in Apache configs, but I can't figure out how an ephemeral process 
like RevServer could affect it, esp. given the suggestion that these 
limits are somehow imposed across multiple instances.


To distinguish whether the source of this issue is simply normal 
settings on on-rev.com or the RevServer engine itself, one would need 
need to test on a dedicated server outside of the on-rev.com hosting setup.


What else was installed on the dedicated private server on which this 
behavior was observed, and what would I need to install to see the same 
behavior on my server PC here?


--
 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
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: [revServer] process timeout issue

[Michael Kann]

Andre,

In your tests you've  found cases where there is no timeout problem. What we 
need now are cases where there is a timeout problem. Then we (meaning you, 
Pierre, Oliver, Jerry and others) can figure out what triggers the problem.

As the great American philosopher, Rodney King, asked:

"Why can't we all just get along?"

Mike



--- On Tue, 8/3/10, Andre Garzia  wrote:

From: Andre Garzia 
Subject: Re: [revServer] process timeout issue
To: "How to use Revolution" 
Date: Tuesday, August 3, 2010, 8:47 AM

Folks,

I never seen a RevServer bug like those timeouts and stuff and of course
Jerry is not making it up, so the logical conclusion is that there's some
specific case(s) where a RevServer script can go loco and fail.

After that conclusion, our first requirement is to draw a mental map of what
is involved. Now repeat after me SETUP

S - Scenario (what are they building)
E - Environment (what is the surrounding environment)
T - Technology (what are they using)
U - Usage Case (what happened/when happened)
P - Possible Points of Failure (critical things that need assessment)

=== Scenario ===
Jerry, Sarah and Mary are building some amazing tools. They have a new
development tool that is powered by new xTalk like language called LIST.
Their system works by doing conversions on that LIST language to present
HTML5, Javascript, CSS web application. Their applications are AJAX powered
and a round trip to the server is needed to execute LIST ACTIONS (is this
true?)

=== Environment ===
Rodeo server was a RevServer built solution hosted at a datacenter. Is it
hosted at On-Rev or is it hosted privatelly? Where is it hosted?

=== Technology ===
Is Rodeo on virtualized hardware? Shared accounts? VPS? Which database was
used? Is it being served with Apache?

=== Usage Case ===
Can RevServer timeout be narrowed to some usage scenario? For example did it
happened while  huge conversions of LIST were taking place? Did it happen
while complex database calls were being executed? Was it completelly random?

=== Possible Points of Failure ===
If RevServer failed for a SANE REASON, meaning, it didn't simply exploded
out of nowhere then the most probable causes are:
* Memory Exaustion: RevServer script took more than it was allowed to chew
and was terminated.
* CPU Thief: RevServer script decided that the CPU was his alone and maxed
it for more time than allowed. Terminated with prejudice.
* Timeout: RevServer script started ponderating on the meaning of life while
doing its chores, takes forever, terminated by virtualization police.

These are the sane reasons for a process to be terminated by the system.
Could it be that RevServer is crashing, crashing is not the same as being
terminated. Being terminated means that you are working correctly but for
some reason or policy your process is terminated, crashing means somewhere
inside RevServer engine something went nuts and it died.

Now we don't know the answers to those questions but those are questions
that all should ask while facing problems with server side stuff. Server
side is hard and while on the Desktop is OK to make a little standalone that
allocated half a gig of memory, at the server side there's a big change that
you will not be allowed to do that.

There are to many possible points of failures and things to keep attention
specially when you are building something as big as Rodeo. I am sure that
Jerry and Sarah investigated their possibilities and reasoned what to do. In
the end it is just a compromise about where you want to stop and work. They
decided to move that technology to other engine. It is OK. Had they decided
otherwise it would be OK too.

Yesterday me and Pierre did some stress testing on his site. I've run 25
concurrent access for 30 secs on his site, of course I've run it from a
single machine and thus it is not the best benchmark possible but I did this
multiple times and his did it at the same time as well and maybe others did
to. On my tests there was not a single error. Some requests took longer
thant others but this can happen for many resons including problems on my
machine and network, after all I am on a lousy VPN.

I am now building some huge RevServer based solutions and I am yet to face
those problems, thats why I believe there's a recipe for them or that they
are caused by a combination of factors related to the virtualization stack
(if the server was indeed virtualized). Remember folks, virtualization is
cool but nothing beats a real machine.

Sorry for the long post
andre






-- 
http://www.andregarzia.com All We Do Is Code.
___
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, unsubsc

Re: [revServer] process timeout issue

[Andre Garzia]

Folks,

I never seen a RevServer bug like those timeouts and stuff and of course
Jerry is not making it up, so the logical conclusion is that there's some
specific case(s) where a RevServer script can go loco and fail.

After that conclusion, our first requirement is to draw a mental map of what
is involved. Now repeat after me SETUP

S - Scenario (what are they building)
E - Environment (what is the surrounding environment)
T - Technology (what are they using)
U - Usage Case (what happened/when happened)
P - Possible Points of Failure (critical things that need assessment)

=== Scenario ===
Jerry, Sarah and Mary are building some amazing tools. They have a new
development tool that is powered by new xTalk like language called LIST.
Their system works by doing conversions on that LIST language to present
HTML5, Javascript, CSS web application. Their applications are AJAX powered
and a round trip to the server is needed to execute LIST ACTIONS (is this
true?)

=== Environment ===
Rodeo server was a RevServer built solution hosted at a datacenter. Is it
hosted at On-Rev or is it hosted privatelly? Where is it hosted?

=== Technology ===
Is Rodeo on virtualized hardware? Shared accounts? VPS? Which database was
used? Is it being served with Apache?

=== Usage Case ===
Can RevServer timeout be narrowed to some usage scenario? For example did it
happened while  huge conversions of LIST were taking place? Did it happen
while complex database calls were being executed? Was it completelly random?

=== Possible Points of Failure ===
If RevServer failed for a SANE REASON, meaning, it didn't simply exploded
out of nowhere then the most probable causes are:
* Memory Exaustion: RevServer script took more than it was allowed to chew
and was terminated.
* CPU Thief: RevServer script decided that the CPU was his alone and maxed
it for more time than allowed. Terminated with prejudice.
* Timeout: RevServer script started ponderating on the meaning of life while
doing its chores, takes forever, terminated by virtualization police.

These are the sane reasons for a process to be terminated by the system.
Could it be that RevServer is crashing, crashing is not the same as being
terminated. Being terminated means that you are working correctly but for
some reason or policy your process is terminated, crashing means somewhere
inside RevServer engine something went nuts and it died.

Now we don't know the answers to those questions but those are questions
that all should ask while facing problems with server side stuff. Server
side is hard and while on the Desktop is OK to make a little standalone that
allocated half a gig of memory, at the server side there's a big change that
you will not be allowed to do that.

There are to many possible points of failures and things to keep attention
specially when you are building something as big as Rodeo. I am sure that
Jerry and Sarah investigated their possibilities and reasoned what to do. In
the end it is just a compromise about where you want to stop and work. They
decided to move that technology to other engine. It is OK. Had they decided
otherwise it would be OK too.

Yesterday me and Pierre did some stress testing on his site. I've run 25
concurrent access for 30 secs on his site, of course I've run it from a
single machine and thus it is not the best benchmark possible but I did this
multiple times and his did it at the same time as well and maybe others did
to. On my tests there was not a single error. Some requests took longer
thant others but this can happen for many resons including problems on my
machine and network, after all I am on a lousy VPN.

I am now building some huge RevServer based solutions and I am yet to face
those problems, thats why I believe there's a recipe for them or that they
are caused by a combination of factors related to the virtualization stack
(if the server was indeed virtualized). Remember folks, virtualization is
cool but nothing beats a real machine.

Sorry for the long post
andre






-- 
http://www.andregarzia.com All We Do Is Code.
___
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: Mousemove, Optionkey and Windows

[ron barber]

Terry, Jan
Thanks for checking on this.


On Aug 3, 2010, at 9:17 PM, Jan Schenkel wrote:

--- On Mon, 8/2/10, ron barber  wrote:
Greetings

Works for me under Windows XP - though if I hold down the
optionKey/altKey I first have to move the mouse to actually see the
change in the message box. The change in status of a key will not
trigger the mouseMove event.

Jan, just to be clear, I am not looking for the key down to trigger a
mousemove. I am trying to respond to the mouse moving within a fld
when the optionkey goes down. Specifically I am getting the mousetext
and displaying related data to that text e.g. a dictionary entry.

Terry, were you testing on a windows machine or emulation or some sort?

Thanks
Ron
___
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: A real problem with Prefs!!

[charles61]

Hi Mark,

I tried your suggestion and it works on both my windows and mac apps!!

Here is my revised stack script of my app stack:

on preOpenStack
   set the loc of this stack to the screenloc
   loadPrefs
end preOpenStack

on loadPrefs pFilename
   local tPrefs
   
   --   put url ("binfile:" & pFilename) into tPrefs
   IF the platform is "MacOS" then 
  if there is a file (specialFolderPath(26) & "/" & "S504_prefs") then
 put url ("binfile:" & specialFolderPath("preferences") & "/" &
"S504_prefs") into tPrefs
 
 put arrayDecode(tPrefs) into tPrefs

 -- now fill in all my data...
 put tPrefs["school"] into field "mySchool" of card id 1002 of stack
"prefs"
 put tPrefs["contact"] into field "contact" of card id 1002 of stack
"prefs"
 put tPrefs["email"] into field "email" of card id 1002 of stack
"prefs"
  end if
   end if
   
   IF the platform is "win32" then
  if there is a file (specialFolderPath(26) & "/" & "S504_prefs") then 
 put url ("binfile:" & specialFolderPath(26) & "/" & "S504_prefs")
into tPrefs
 
 put arrayDecode(tPrefs) into tPrefs

 -- now fill in all my data...
 put tPrefs["school"] into field "mySchool" of card id 1002 of stack
"prefs"
 put tPrefs["contact"] into field "contact" of card id 1002 of stack
"prefs"
 put tPrefs["email"] into field "email" of card id 1002 of stack
"prefs"
  end if
   end if
   
end loadPrefs

Please feel free to make any additional comments. This is my first app that
employs a prefs stack. My experience with this have been frustrating at time
but invaluable for future apps. I am posting this code so that it will be
helpful to others.
-- 
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/A-real-problem-with-Prefs-tp2311179p2311755.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Mousemove, Optionkey and Windows

[Jan Schenkel]

--- On Mon, 8/2/10, ron barber  wrote:
> Greetings
> 
> I encountered a problem and would appreciate confirmation
> and a work
> around if needed.
> 
> The problem is: the state of the optionkey is not reported
> in a
> mousemove handler on windows (tried on 7 only)
> 
> Simply create a new stack with a single fld. Set the script
> of the fld to
> 
> on mousemove
>    put the optionkey
> end mousemove
> 
> this always reports up in my cases but perhaps something
> else is going on.
> 
> Thanks
> Ron
> 

Works for me under Windows XP - though if I hold down the optionKey/altKey I 
first have to move the mouse to actually see the change in the message box. The 
change in status of a key will not trigger the mouseMove event.

Jan Schenkel
=
Quartam Reports & PDF Library for Revolution


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



   

___
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: Standalone Creation - Windows "Externals" Sub-folder

[Mark Schonewille]

Hi Francis,

The externals folder contains files If you include externals :-) For  
example if you include the browser library or the revFont library or  
if you include a database driver.


--
Kind regards,

Mark Schonewille
Economy-x-Talk
Http://economy-x-talk.com

Share the clipboard of your computer over a local network with  
Clipboard Link http://clipboardlink.economy-x-talk.com



Op 3 aug 2010 om 13:27 heeft Francis Nugent Dixon   
het volgende geschreven:\



Hi from Beautiful Brittany,

When creating a Windows Standalone Application,
the generated Windows folder contains a sub-folder
called "Externals". For my stacks, this folder has
always been empty. This is convenient for me, because
I can take the .exe file out of its environment,
and put it anywhere for execution.

I would surmise that if the sub-folder contained
anything, I would always have to keep the .exe
file and the Externals folder in the same folder.

However, always curious, I would like to know
under what circumstances does this sub-folder
contain anything ?

-Francis

"Nothing should ever be done for the first time !"


___
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

Standalone Creation - Windows "Externals" Sub-folder

[Francis Nugent Dixon]

Hi from Beautiful Brittany,

When creating a Windows Standalone Application,
the generated Windows folder contains a sub-folder
called "Externals". For my stacks, this folder has
always been empty. This is convenient for me, because
I can take the .exe file out of its environment,
and put it anywhere for execution.

I would surmise that if the sub-folder contained
anything, I would always have to keep the .exe
file and the Externals folder in the same folder.

However, always curious, I would like to know
under what circumstances does this sub-folder
contain anything ?

-Francis

"Nothing should ever be done for the first time !"


___
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: A real problem with Prefs!!

[charles61]

Mark,

Thanks for your suggestion. Here is what I am trying to do. My app has a
preferences for the user to complete. It includes the name of the user,
telephone number and e-mail address that are used on a couple of cards as
part of a document that is later printed out. When the app is first
launched, the preferences are empty, waiting to be filled by the user. I
will try your suggestion! Again thanks for your time!
-- 
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/A-real-problem-with-Prefs-tp2311179p2311653.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [revServer] process timeout issue

[Shao Sean]

Robert this is a lo-o-o-o-ong post.


and that was a useless post..

Robert did raise a few valid points:
- revServer was originally going to be released for free (I can  
understand needing some funds after the revMobile fiasco)

- "consequently what precautions have revServer developpers to take"
- "do we have to postpone any serious launch of revServer, on-rev  
services until the beta test ends and a version one is officially  
launched?"


While it is never good to release services or applications built with  
alpha/beta pieces of software, the need to build with them to release  
when they are released is a valid use..
If the revServer cannot handle the load during development what will  
happen when revServer is officially released?
What happens if the web service becomes more popular than originally  
estimated?

What happens if the web service gets slash dotted?

I understand that even PHP has memory limits and script execution  
times (ahh.. good old infinite loops) but they are configurable (will  
the final version of revServer be?)..
Load times of a page are not a huge deal and cannot be blamed on  
revServer as I have gone to my bank's site and have waited for quite  
some time only to hit the refresh button to have it pop up (happens at  
Hotmail too)..


And I was looking forward to playing with the new revServer technology  
but looks like I will be stuck with the old revCGI for now.. :(


-Sean
___
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