CSV writing bug and some documentation
John Bridges
http://www.aftergrasp.com/download/agsetup_20080219.exe
----------------------------------------------------------------------------
Tue, 19 February 2008
The FILEPUTARRAY and FILEPUTARRAYNAMED commands were not putting quotes
around text which did not have a comma, but did cross lines. It now
puts quotes around text with any control character including CR, LF
and TAB.
Code example/documentation on arrays:
Given a CSV file where one of the fields looks like
"Collection:19/04/2008", sort the
CSV and write it back out.
drawclear white
set texthtml on
text "<html>"
textln "starting"
; Read the csv into an array
global newres filegetarray("newres.csv")
global res0 strlist(@newres[0])
; Searche for which field is the collections field
global collections strlinenumber(@res0,strsearch(@res0, "Collection:"))-1
for i inarray array(arrayindex(newres))
cdate = strreplace(@newres[@i][@collections], "Collection:", "")
; Parses the date
lpos = strsearch(@cdate, "/")
rpos = strsearchreverse(@cdate, "/")
cday = strleft(@cdate,@lpos-1)
cmonth = strleft(strleftright(@cdate,@lpos+1), (@rpos-@lpos)-1)*100
cyear = strleftright(@cdate,@rpos+1)*10000
; Create a YYYYMMDDIIIIII index
cdate = (@cyear+@cmonth+@cday)*100000+@i
resindex[@cdate] = @i
next
count = 0
; Create an array sorted on that YYYYMMDDIIIII index
for i inarray array(arrayindex(resindex))
sortres[@count] = &newres[@resindex[@i]]
inc count
next
count = resindex->size
; Create an array sorted in reverse on that same YYYYMMDDIIIII index
for i inarray array(arrayindex(resindex))
dec count
reversesortres[@count] = &newres[@resindex[@i]]
next
; resindex is no longer needed at this point and can be freed
free resindex
fileputarray sortres.csv sortres
textln "done"
set variables on
wait
exitnow
----------------------------
AfterGRASP supports what are called sparse arrays, so you can do this:
a[10] = a
a[50] = b
a[2000] = c
This array has only 3 items in it.
If you did strlist(arrayindex(a)) you would get
10
50
2000
If you did
for i inarray array(arrayindex(a))
textln @a[@i]
next
you would get
a
b
c
So if you do
a[2008012300001] = 1
a[2007010100002] = 2
a[2008012200003] = 3
You would get strlist(arrayindex(a)) displaying
2007010100003
2008012200002
2008012300001
if you did this loop to the date indexed array
for i inarray array(arrayindex(a))
textln @a[@i]
next
you would get
3
2
1
What is the difference between array(arrayindex(a)) and strlist(arrayindex(a)) ?
array(arrayindex(a)) returns an array, for example:
global hello array(arrayindex(a))
textln @hello[2]
strlist(arrayindex(a)) returns a string, where each item is seperated by a CR LF
In the example above, you could use for i in strlist(arrayindex(a))
but it's less
efficient, and forces everything to be converted to a string and back
to a number
multiple times.
Using for i inarray array(arrayindex(a)) leaves everything as a number leaving
out all the string conversions and string searches.
----------------------------------------------------------------------------
Dick Trump
I sent a private message last week and haven't heard anything from either of you. I've been having trouble with some of my emails getting kicked out by some servers, so you might not have received my message.
Please let me know.
--
Regards
Dick Trump
Triad AV Services
1910 Ingersoll Ave.
Des Moines, IA 50309
515-243-2125
515-243-2055 (fax)
http://www.triadav.com
dtr...@triadav.com
David Boyland (Digi-products Ltd)
Sorry we did get your email.
However I am on leave this week and John is exceptionally busy.
Promise we will come back to you next week.
Sorry this is so brief...
sent from my mobile phone.
Kind regards,
David Boyland
Digi-products Ltd
"Automated Digital Marketing"
www.digi-products.com
John Bridges
We got the message, and discussed it briefly over the weekend in email.
As David said, he's away this week, and I'm very tied up with a long
term project that is running behind schedule.
In the meanwhile I did consider your question about line drawing
speed, and did come up with a way to speed up AG's drawing to screen.
There is an experimental command in the latest AG build (not
documented in UPDATE.TXT), called WINDOWSET.
It works much like PRINTSET, in that is redirects all drawing
commands, except that in instead of redirecting them to a printer, it
redirects them to the current window.
Normally AfterGRASP buffers all window updates in a offscreen image
buffer. Without this buffer, AG would not be able to refresh the
window if requested to do so by Windows.
Because WINDOWSET bypasses this buffer, it should give much faster
results, but will also have some odd side effects including incorrect
window updates if Windows requests a redraw.
Feel free to experiment and let us know if it helps in your particular
situation.
Dick Trump
> In the meanwhile I did consider your question about line drawing
> speed, and did come up with a way to speed up AG's drawing to screen.
I'll try to take a look at that tonight. I assume you were referring to my discussion about the benchmark methodology. I didn't realize that AG had no direct screen writing mechanism. Presumably WINDOWSET would take care of that issue. I had seen the raw execution speed of AG being more of a factor in improving any benchmark. But that isn't a big concern since the benchmark is really just an "extra" in the program.
I am curious if you considered my interest in being able to direct the application to any specific monitor in a multi-monitor setup. Being able to do that would be a significant benefit to users in certain situations.
Since writing my original email, I spent about an hour bringing in the latest version (as of a few days ago) to AG. Although I got it functional, there was something very sluggish about it that I'm unsure of the cause. Since I consider AG to be a much speedier environment, I'm sure it's because I'm using some specific function that is gumming up execution speed. I'll try to find time to whittle things down to a point that I can spot it.
-
Dick Trump
> Since writing my original email, I spent about an hour bringing in
> the latest version (as of a few days ago) to AG. Although I got it
> functional, there was something very sluggish about it that I'm
> unsure of the cause. Since I consider AG to be a much speedier
> environment, I'm sure it's because I'm using some specific function
> that is gumming up execution speed. I'll try to find time to
> whittle things down to a point that I can spot it.
I did a little playing around and it appears that it is the number of WHEN statements that is the culprit.
I have a total of 28 WHEN statements, most of them active most of the time handling some keyboard commands that aren't essential to the core of the program. When I cut the number of them to about 20, things get better. If I take it down to about 12, it gets even better, but still not quite as responsive as the same script in GLpro. When all of them are active some strange things happen after a mouse click (which triggers a rebuild of the screen). The whole window will start sliding down the screen, a pixel at a time. I do use the window drag routines that date back from GLpro days, so part of the answer is probably in there.
I'm working with the 1/3/08 release. I don't see anything in more recent notes that would lead me to believe you have made changes that would affect this. But I suppose I could try.
I am not desperate to get this to work, so I'm happy to do my own chasing as time allows.
Regards
--
Dick
dtr...@triadav.com
John Bridges
> John Bridges wrote:
> > In the meanwhile I did consider your question about line drawing
> > speed, and did come up with a way to speed up AG's drawing to screen.
>
> I'll try to take a look at that tonight. I assume you were referring to my discussion about the
> benchmark methodology. I didn't realize that AG had no direct screen writing mechanism.
> Presumably WINDOWSET would take care of that issue. I had seen the raw execution speed
> of AG being more of a factor in improving any benchmark. But that isn't a big concern since
> the benchmark is really just an "extra" in the program.
You will find that GLPRO also double buffered everything, and actually
used no Windows APIs for drawing anything since the code was ported
from the DOS version of GLPRO.
This is why the printing in GLPRO is so weak. It only allowed you to
print a image buffer because all the drawing commands including text
were image buffer specific, none could be redirected to a printer.
>
> I am curious if you considered my interest in being able to direct the application to any specific
> monitor in a multi-monitor setup. Being able to do that would be a significant benefit to users
> in certain situations.
Can't you just define all the video cards as a single screen, and put
each window in a different section of the screen?
John Bridges
>
> I did a little playing around and it appears that it is the number of WHEN statements that is the culprit.
>
> I have a total of 28 WHEN statements, most of them active most of the time handling some
> keyboard commands that aren't essential to the core of the program. When I cut the number
> of them to about 20, things get better. If I take it down to about 12, it gets even better, but still
> not quite as responsive as the same script in GLpro. When all of them are active some
> strange things happen after a mouse click (which triggers a rebuild of the screen). The whole
> window will start sliding down the screen, a pixel at a time. I do use the window drag routines
> that date back from GLpro days, so part of the answer is probably in there.
AG uses WHENs extensively, for instance the HOTSPOT command generates
a whole bunch of them. I've never noticed any performance issues with
their use.
In GLPRO all the logic for WHEN is handled in the main loop. The more
WHENs, the more that is checked each time a command is started. But in
AG most of the logic for WHEN is handled in a window message thread
since WHENs are generally triggered by a message (mouse moved, key
pressed, and so on). This means there is very little beyond a check in
the interpreter thread which says "Has a WHEN triggered?". So the
number of WHENs would normally have no effect on the speed of the main
interpreter.
This makes me think there is a bug somewhere that is constantly
triggering a WHEN or you are using an unusual set of WHEN parameters
that I have not tested.
> I'm working with the 1/3/08 release. I don't see anything in more recent notes that would lead
> me to believe you have made changes that would affect this. But I suppose I could try.
No.
> I am not desperate to get this to work, so I'm happy to do my own chasing as time allows.
When you have a runable small example, sent it to me. But I cannot
look at it seriously until around a month from now.
Dick Trump
> Can't you just define all the video cards as a single screen, and put
> each window in a different section of the screen?
This is to be a "portable" application to be used on an ad hoc basis without any prior installation or setup to the computer. So it isn't practical to force the user to define the card setup.
I have programmed the capability to change the window after startup to any of the commonly available screen resolutions or to enter any arbitrary resolution as needed. So the user can force the application to be 2048x768 (spanning two equal monitors), or they could resize and reposition to any auxiliary monitor as desired. 2048x1536 is already a preprogrammed selection, so a 4 screen setup is a snap. I could do the same for any common combinations of 2 to 4 monitors. I'd just like to be able to do the individual monitors in a more automated fashion by selecting the monitor number as needed for the current use.
Since it sounds like AG doesn't have any unique capability for that, I'll probably eventually roll up my sleeves and figure out how to do it with calls to the API.
At this point, printing is not an issue and I'm OK with it not being available.
--
Dick Trump
> When you have a runable small example, sent it to me. But I cannot
> look at it seriously until around a month from now.
I'll do that. It should be relatively easy to strip it down to something that exhibits the observed problem without having to wade through too much code.
--
Dick Trump
> When you have a runable small example, sent it to me. But I cannot
> look at it seriously until around a month from now.
FYI, I took the time to strip things down tonight to the point that I could see what was going on. I can't say that I completely understand why it was doing what it was doing but it boiled down to a single WHEN statement that I was reasserting without freeing it first. It was causing some other WHEN statements (keystroke) to misbehave which was leading me in the wrong direction.
Adding a WHENFREE just before restarting the WHEN solved the problem.
There are plenty of other things I would need to fix to move to AG, but that one would put the system into a real funk.
At this point, I'm going to stay with GLpro. It's performing just fine for my needs.
--
Dick
dtr...@triadav.com