A new variable scope

[G Gabriel]

Re: A new variable scope

Ken:
Glad you could see things with clarity.

Dave:

G,
I believe it can be done in shared memory. Ever hear of a ram drive?

Yes, but I am not sure how remote users will have access to the RAM derive in the server?

[DaveM]

Re: A new variable scope

ram drive could be on the server and have a drive letter(going on memory here) and users could map a drive to the ram. Just one thought.

a text/table/adb/adb with script/whatever could be sitting there to be used as needed. Think about an adb that could save the variable contents to someplace on the server HD for later retrieval.

Did you ever load a whole program into a ram drive and run it? I have and the speed difference is amazing.

One word though, when the contents of a variable is saved or not and the variable is destroyed, there is no variable to worry about.

You could posibly save the var in a web space outside the lan system but inside the wan. Retrievable by all?? this one is way out, HUH?

Dave

[csda1]

Re: A new variable scope

Hi Dave,

Did you ever load a whole program into a ram drive and run it? I have and the speed difference is amazing.

Actually, I have. And surprisingly, Alpha 5 ran slower than with the hard drive. Explaining this is difficult, when it seems intuitively obvious that it should be the other way. I had tried several Ram disk drivers with similar results

The cause may be fast 7200 rpm drives with big caches (16Meg+) and DMA (Not a RAID setup), and the fact that Windows & Alpha both cache as well. The program, scripts and other support files could all be sitting in main memory, which means that only the data processing would be faster if true. However, my tests indicated that this wasn't either. It may be that the RAM drive driver was not as highly optimized as the current hard drive drivers/hardware DMA combinations.

You indicated you had tried this with clipper in the past, but have you run timing tests recently, with Alpha, modern hard drives and interfaces?

If you can re-run any tests, listing which RAM disk drivers and what you are doing, that might be indicative if the slowness was system/driver specific or generically a truism for typical machines today.

[DaveM]

Re: A new variable scope

Ira,

I did do it with Alpha, but is was Alpha 4 on eide drives versus ram drive. I loaded the whole program and the app onto the ram drive and it was at lease 3 times as fast(I think faster). It was just a hassel doing it, but I had a lot of time to play then. I do not remember which ramdisk drivers I used.

I don't know how Gabe's idea will totally unfold, but if we all toss ideas(like the ram drive) out there, it may something be viable.

I have no need for an autoincremented variable over a lan, but maybe others do. The field rules see quite good for that and they work well in shadow.

All could become moot if Alpha ever changes the methods for connecting to the server.

Right now we could have a need for something generated by the app on server that all could share without reshadowing. I think this is what G is thinking. NOt sure of that and he may have just stumbled over the fringes in his thinking.

Dave

[csda1]

Re: A new variable scope

Hi Dave,

I did do it with Alpha, but is was Alpha 4 on eide drives versus ram drive. I loaded the whole program and the app onto the ram drive and it was at lease 3 times as fast(I think faster). It was just a hassel doing it, but I had a lot of time to play then. I do not remember which ramdisk drivers I used.

Unfortunately, Alpha 4, eide drives (and older OS's?) does not compare to DMA drives (now standard, although it wasn't in the past), Gigabytes of memory, extremely fast hard drives with caches etc. So it needs a revisit by many under various environments to validate my results. I'd love for it to turn out in Ram disks favor, but based upon my tests, wishing will not make it so.

I have no need for an autoincremented variable over a lan, but maybe others do. The field rules see quite good for that and they work well in shadow.

The auto-increment of field rules are very good today (there were issues in earlier versions years ago), but they don't fit everyone's incrementing needs. Hence the need for another method. The same method can also be used to control resources, Version control (Check-in/check-out) etc. It's basically the process of doing an "Atomic" Operation. See Resources below for basic info

Deadlock
Atomic operation

[dpawley]

Re: A new variable scope

Alpha4 had script functions VSAVE & VRESTORE that would write/read an ASCII file with a .VAR extension to a specified path and name for specified script variables. This has worked well for me in the past in Alpha4. I have not needed a use for it in Alpha5 yet, but a quick search of the help file yields the SAVE_TO_FILE() and GET_FROM_FILE() which at first glance appears to be similar to the A4 function. IMHO this would be more straight forward than modifying a script. If the contents of the variables are not user dependent the file could be saved to a network location and if user dependent can be saved to a local drive.

[G Gabriel]

Re: A new variable scope

It just dawned on me as I was thinking about a reponse regarding yet another thread that could use this idea of dynamically changing a script with a script and updating the base value of the variables.

To those who think that changing the script is a dangerous thing: just how do you propose that alpha does that all the time and every time you modify your script manually?

I was thinking about a script that will dynamically add or delete controls to an xdlg, then it dawned on me, doesn't alpha use xdlg for just about any and everything?

If you write a script using AS, what happens? alpha takes your parameters and translates that to xbasic and saves that script. Now, I want you to create a script using AS, save it, then change your mind 50 times editing the script each time and save it, what happens? alpha saves it even if you change your mind a thousand times and I never heard of any one complaining that they were having any problem with that.

"Action Scripting" is nothing but an intermediary application (made with xdlg's) between alpha and the developer in as much as your application is an intermediary between the end user and alpha, and when you do your modification to your own script in Action Script, what does alpha do? I never had Aaron Brown or Lenny Forzati come to my office to replace the script! although I welcome the opportunity! alpha dynamically changes and saves your script. If alpha does that day and night, why can't you? and if it is dangerous, how come we never heard about that Tsunami?

[MikeC]

Re: A new variable scope

G,
You can no longer say you haven't heard of anyone having this problem now...

alpha saves it even if you change your mind a thousand times and I never heard of any one complaining that they were having any problem with that.

I have mentioned several times on various threads about what happens when things are changed in Alpha scripts many times and do believe that is why so many novices have more problems with "losing" forms, crashes, and general corruption than say someone much more versed in xbasic.

I have found that there are sometimes "leftovers" from script that has been changed or even deleted that Alpha will leave--just not reproducible most of the time (I did have one, confirmed and submitted as bug).

I would think that if this is a viable way though that a database compact would be in order wouldn't it??? Something that normally would not have to be done in a runtime situation but if scripts are being changed then think this is a necessity--correct me if not thinking clearly.

[G Gabriel]

Re: A new variable scope

Mike:
People write scripts all day long using AS. Point me to where you created a script and by EDITING & SAVING the script, you had problems with the dictionary or adb file somehow?

I am not talking about people writing bad scripts and I am not talking about AS as being perfect. I don't have much use for AS. I am only here talking about the process of editing then saving your script, did you encounter problems just by doing that? if so, where when and how?

[MikeC]

Re: A new variable scope

G,

Two things,


http://msgboard.alphasoftware.com/al...ad.php?t=69913


One, here is a link to the bug I referred to...makes no difference that it happened in Action Script as it shows that it CAN happen ......and does--which brings me to point Two,

A certain level or modicum of trust is appreciated on this board (or anywhere else for that matter)---if some things simply cannot be proved (yet) due to not being able to reproduce it on demand does Not mean it does not happen. For you to suggest that if not proven then it can't happen simply tells me that you somehow have developed a closed mind in regard to this which surprises me.

[G Gabriel]

Re: A new variable scope

One, here is a link to the bug I referred to

Where is the link?

No, I haven't developed a closed mind.. but I don't necessarily believe in UFO simply because somebody tells they saw one.

Several people propagated the argument that repeated saving of a script "could be dangerous". I am asking, how do you know? and to me, it defies logic, because that's what alpha does each and every time you make any modification to your script, only difference here, I am going to do it myself.

[MikeC]

Re: A new variable scope

I added some space between the link and the message. You may have caught me in the few seconds I submitted the message and went back and added the link.

[G Gabriel]

Re: A new variable scope

Mike:
I see you added te link..
Serioiusly Mike, what does this have to do with editing & saving? it's a bug in the condtional AS..

One more time, let me bring you to focus. The issue is: does repeated editing/saving of a script present "danger"?

How is it different if you edit/save a script than when alpha does it?
That is the question.

[michaelwpayton]

Re: A new variable scope

There are a number of reports, on this forum, which I and others at the time, believe could/should be attributed to A5's "data stores" becoming corrupted. And no, I won't point anyone to those specific threads, lol, find them yourself if you don't believe me :)

This happens, from time to time, within ALL development environments... especially those which, like A5, do not contain robust "team development functions/features" like code check in/out, code locking, etc.

The bottom line, I believe, is that while there are always any number of ways to do things... we (my developer's) always error of the side of what is considered to be the "best practice approach," which I do not believe is to use a development environment's internal data stores for purposes they were not designed for.

[MikeC]

Re: A new variable scope

G,
Surprised you cannot see the relevance. But will try one last time.

In my bug report thread, if deleting this condition can leave a remnant "End If" statement it follows that deleting or modifying other script in various ways can also leave remnants---which it has done to me several (read as more than 5 times...so far) times. Perhaps it has something to do with Action Script alone, who knows. It has not happened to me now in many months and believe it is one of two possibilites--that I am getting better in script writing (less errors) or am using Action Scripting much less. Time will tell perhaps.