Just wondering if anyone had any thoughts on my idea to use
LIST DICT <PROGFILE> <PROGFILE> C/BYTES and compare that with a new
compile

"Sean" wrote
Yes it should catch major code changes, but it doesn't seem it would
spot minor bug fixes where you correct a logic flaw like

myvar = 1

getting corrected to be

myvar = 0

I've done some successful testing. While there isn't a checksum
built-in to the D3 object, a checksum can be programmatically
generated from the bytes of the object code. A simple dump of bytes
won't work because there is some housekeeping data that's embedded in
the object, and recompiling code with no changes will change the
object. Two programs with exactly the same source will have exactly
the same object, apart from that housekeeping data.

Note: I believe the above approach is only possible in the D3 VME in
*nix/Win, not in the Win/FSI. This can still be done for FSI but the
approach would be much more involved.

Since this is the kind of thing I do for a living, I'll be happy to
provide your company with a utility as part of a development project.
Someone who has another source of income might offer to try publishing
some code for free. My public contribution is simply to confirm that
you can do what you want with the information you have available.

HTH
T

"Frank Winans" wrote
One of the nicest ways to display binary files is with hexdump -C
myfile
of linux or of the free-download cygwin package. Three-pane output
similar to the old CP/M dump {or was it hexdump?} command output.
Won't help for this thread, but really nice for debugging laserjet esc codes
in 'print to file' files. And bvi is a binary-capable cousin of
vi editor...

Just for the record, you Can store, view, and edit binary data in D3,
including images and audio, and you can do this with BASIC. People
just ... don't.

T

"Tony Gravagno" wrote
precious I want to keep the file-save output trim and easy to carry
around on a dvd or usb memory stick{"thumb drive" or "flash drive"}
And small file-saves mean really quick full file restores, a real plus if
your
whole company is twiddling their thumbs after a server meltdown. I guess
I could do something elaborate to provide multiple categories of file saves,
but have no real incentive when just leaving the binary files out on windows
or linux is so easy in the first place. With d3/nt {or samba and
d3/linux}
all the staff can stick with the windows apps they're so happy to use on
'em...

I'd like to step back to a bigger concept here.

"We don't do X because of Y"
When Y is invalid, X is also invalid.

You suggested we can't use hexdump for D3 binary data, but we can.
And I further noted that we can go the other way and view and modify
binary data in D3.

You counter that to cite that you don't want file-saves inflated with
binary data. Sure, that's valid, but I didn't say it was a good idea
to store binary data in MV, just that you Can. And for purposes of
modifying binary data you don't need to store it in the DBMS just
because you're making use of that data there, and it would be a bad
idea to do so, so that's not what I suggested.

What I'm getting at here is that people have a tendency to cite all
the reasons why we can't or shouldn't do things for all of the wrong
reasons. You're right, the MV DBMS isn't a good place to store lots
of binary data, in part because of saves but also because of the way
the environment manages memory and frames - and it's not an ideal
place to do a lot of binary manipulation either. But the environment
IS good for doing a LOT of things if proper consideration is given to
details. Don't let potential abuse or stupid use of the platform
preclude doing something that's actually useful.

As usual, the best advocates of this platform are often its worst
enemies. You (anyone who does this) discourage people from doing new
and interesting things because you "know" it simply can't be done.
You (anyone who does this) are just wrong and hurting the market in
the process. Please take your wisdom from the last millennium
elsewhere.

T

"Frank Winans" wrote:

On Oct 31, 10:55*am, Sean <sean.chap... (AT) gmail (DOT) com> wrote:
Sean,

A callx trigger will allow you to track changes, but you can also do
that with the D3 file header info.

Add "yupt" to attribute <8> of the D pointer to data portion of your
bp file (I also added it to the pointer-file, so I can see when and
who made save-lists). The compile date, time, flash-compile [(0)
option] frames used, and user are in the object-code pointer in the
dict of the bp file. You could therefore compare the last time the
source code was updated to the last time it was compiled. Not exactly
what you were looking for, but it's close.

Here is the d3.ref help item for the Y file-defining-item processing
code:

:help y

d3.doc pc.y.stamp
token y
syntax y{u}{p}{t}
category Processing Codes
type Processing Code
terse stamps user, pib, and time/date update information into
an
internal item header from all processors.
desc stamps user, pib, and/or time/date update information
into an
internal item header from all processors.

To be effective, the "y" must be followed by one or more
of the
following letters to stamp information at update time:

u User ID
p User Pib
t Time/Date Information

Unlike the "x" code, the "y" code updates stamp
information when
an item is updated from any processor. Additionally,
this stamp
information is stored outside the normal item body in a
special
textual header.

To read the stamp information generated by the "y" code,
prefix
the filename with the word "hdr:". The header
information can
then be examined from FlashBASIC, Access, or any other
processor. Note that the stamp information CANNOT be
written
outside of the normal update mechanism.

The "save" verb saves all header information on the save
tape,
and "restore" automatically restores this information.
However,
"t-dump" and "t-load" do not save/restore the header.
Instead,
"t-load" generates new header information as if the items
were
being updated normally.


Here are my attribute definition items that I use to see the compiled
date, time user, and number of flash frames used (zero if not flash-
compiled) by a compiled basic program:

:ct md cdate ctime cuser flash

cdate
001 S date compiled
002 4
003
004
005
006
007 D2-
008
009 R
010 8

ctime
001 S time compiled
002 5
003
004
005
006
007 mt
008
009 R
010 5

cuser
001 S user id that compiled program
002 7
003
004
005
006
007
008
009 l
010 4

flash
001 s flash size
002 12
003
004
005
006
007
008
009 r
010 5


And here are the attribute defining items I use to see who last
changed an item in a file:

:ct md hdr.date hdr.time hdr.user hdr.port

hdr.date
001 a update date for yupt hdr: lookup
002 3
003
004
005
006
007 d2-
008 a;3(mcxd)/"86400"
009 r
010 8

hdr.time
001 a update time for yupt hdr: lookup
002 3
003 hdr ]time
004
005
006
007 mt
008 a;r(3(mcxd),"86400")
009 r
010 5

hdr.user
001 a update user for yupt hdr: lookup
002 1
003 hdr]user
004
005
006
007
008
009 l
010 5

hdr.port
001 a update port for yupt hdr: lookup
002 2
003 hdr]port
004
005
006
007 mcxd
008
009 r
010 4

So all you need to do is compare...

:list dict bp cdate ctime cwho flash

....with

:list hdr:bp hdr.date hdr.time hdr.user hdr.port


/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On 11/05/2011 06:08 PM, Scott Ballinger wrote:
[snip]

That is a very useful and helpful post, Scott.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk

Honestly it a lot of work for little payoff. Your best bet is to
simple create a simple way to track compilation by writing a wrapper
for the BASIC verb, capturing data when ever a program is complied.
Assume you are working from a TEST.BP and moving to a live BP file,
Ex: Create a file called "COMPLIED", update it with a key
PROGRAM.NAME*TIMESTAMP and populate is with a few fields, like who did
it, and any other data you like. Also have the wrapper back up and
existing OBJs or source code if you haven't already done that.

Then just reselect the whole file and compile it. It' simple, it gets
it done and you never need to worry about who di what where and what
changes where done, It's all backed up.