So I'm trying to figure out a way to see if we have any uncompiled
code on our D3 (unix) system.

My first thought is to see if there is a way to get the compiled bytes
existing and checksum against a new compile to see if there is a
change.

Second was a hope of an uncompile option which I don't see.

Third option would be if there is a way to see the last filed date.
Then I could compare that to the LIST-OBJ output and narrow down when
a change could have happened. I email the old files to myself now but
there is a lot of history to go back over so a quicker way would help.

A) How do i go about reading the raw frame data if the first option is
possible?
B) Any other thoughts on ways I could do this? Going forward I'm going
to add a CALLX in the dictionary and capture a copy of the old version
so I can follow differences/dates.

I don't believe you can check source against an object module, and I
don't think you can checksum two object modules to see if they are the
same. So I don't think you have a way of knowing if your source
matches what's in the object. It's been a long time since I've looked
in that area.

However, you can easily see if you're missing object for a given
source item:

SELECT BP
SELECT DICT BP

The missing items have no object, but they could be Include items or
others that aren't intended to compile. You'll have to look through
those one by one. I use a naming convention to identify Include
items:
some.name.INC.01
and Equates:
some.name.EQU.01
So I can select these out for compiling and other operations:
SELECT BP NOT [.INC.] AND NOT [.EQU.]
You may be lucky in this area.

As to seeing when programs were compiled and other data, for now I
suggest you simply SORT-ITEM DICT BP to see the data that's available.

To see if there is source that doesn't match the object, I have
appointments today but I'll look at this more closely tonight. Yes,
the checksum in the dict might do this, and your first thought below
might be the right approach.

HTH

Sean wrote:

"Sean" wrote
you could __maybe__ look at using DUMP on what you think are the
frames the compiled program lives in, but who really knows what tricky
exceptional cases exist on how d3 organizes the frames used, or maybe
have semirandom padding in the frames, or subdivides frames to hold
parts of more than one compiled program?

You likewise could scavenge the binary from a pseudo-floppy t-dump
of dict myfile myprog but again, there may be semirandom padding say
at the end of the t-dump to make up some preferred buffer size,
or as part of a 'marker' string between items of a t-dump, or to signal
an 'end-of-file' mark at end of t-dump regardless of buffer sizing.
Dunno, just haven't tried it, myself...

{T-dumps don't truncate output linux file to actual data size, so
before you set-device that 'tape', do echo hi > /tmp/pickbu1
or whatever to truncate it. Or rm it then touch it.

Assume any dict item with LIST ... SIZE
smaller than say 4008 bytes is not a compiled program.

Here is what I tried yesterday

From the D3 refman

c/bytes
Displays attribute 11 of compiled binary items through the list-obj
TCL command. This is the number of bytes of object code. It is also
available to AQL.
This attribute holds the number of bytes of the actual compiled object
code within the frames that hold the binary item. This information is
useful to estimate the number of frames that are necessary to
FlashBASIC compile standard object code. This is typically 4 times the
size in bytes, but is dependent on implementation, optimization level
and related options, such as f. This byte count does not include the
symbol table, FlashBASIC code or the size of the compile date-time
stamp.

I ran this on the existing file that contains the code. I then copied
that file and recompiled everything in a new file.

Commands
SORT DICT <FILE> C/BYTES
SORT DICT <COPIEDFILE> C/BYTES

Wrote up a quick app that ran these and dumped out:
Program name + Bytes for each list.

Copied into excel. The compiled bytes on all the program names seemed
to match up. I think this means we're okay unless someone can tell me
otherwise. I would assume that any program change made would have
either added or removed characters so the byte count would be
different on a change.


On Nov 1, 9:43*am, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:

Just a note.
I just tried a quick test of this and it seemed to reflect the change
correctly so I do think I'm ok now.

Going to run this on a new file with suspected uncompiled stuff to see
what turns up.

On Nov 1, 10:25*am, Sean <sean.chap... (AT) gmail (DOT) com> wrote:

"Frank Winans" wrote
Doh! You can formulate a gratuitous extra compiled program entry in a
trigger routine, placing it out on the linux filesystem. Sadly I doubt you
can
use the COPY verb to import it to dict myfile afterwards...

!mkdir /tmp/.DICT

copy myfile myprog
to: (unix:/tmp

compile unix:/tmp myprog
{This feature of the unix: driver is documented if you do the verb
HELP unix files and page down to the tree diagrams part.
Control-x then e gets you back out of the HELP command.}

now you can checksum that binary linux file /tmp/.DICT/myprog
I highly recommend md5sum for such things; even if you take just the first
umpteen nybbles of the resulting sum, it still is a great checksum.

If your monitor is dirty, note there is a period between /tmp/ and DICT
above, and that there is a colon between unix and /tmp

"Frank Winans" wrote
/tmp/.DICT/myprog has not just your compiled program code
but also stuff like what pick port you did the compile on, time and
date stamps of the compile. All of which will warp the checksum
versus later/prior compiles of same source text. If you were
expert in the internal format of the compiled program structure you
could use linux dd with skip {or is it seek} to stomp those few
non-program-related bytes prior to doing the checksum, but is it
really worth all the bother figuring that out? Just fall back on plan
"b" and keep timestamped checksums of the program source code
instead...

I'm not sure that the suggestion that follows will satisfy your goal,
but here is what I did on our recent migration to Reality, from D3/NT.

On D3, we had "compile-catalog" verb, which would do both the compile
and the catalog (of a "clean" compile, anyway). Reality had
individual COMPILE / BASIC / CATALOG verbs, but not the "combo"
verb. Besides, I wanted to have some history of my compile/catalog
activity. My solution was to write a simple "shell", a BASIC program
that I named "C-C". I also created a PROGRAM.CATALOG file for
tracking history.

The program, "C-C", used SENTENCE (a form of the TCL command in D3
basic) to disect the command being fed to C-C. And, I require a full-
path (standard syntax ACCOUNTNAME,FILENAME, PROGRAMNAME) in the
syntax of the command, thus assuring all programs are compiled and
cataloged with full-path. Within C-C, I execute the COMPILE command
with the fully-pathed program, and CAPTURE the "errmsg". If the
"errmsg" indicates a "clean compile", I move to the CATALOG of the
same full path.

Lastly, while still in C-C, and with a "clean compile", I form an item-
ID of the syntax, ACCOUNTNAME~FILENAME~PROGRAMNAME, then write out the
pertinent information that I want to track (date, time, user).
Although I haven't done so yet, I could easily track byte count of the
source code by reading the item form the path supplied. And, all of
the information tracked could be "appended" rather than over-
written. Both of these ideas are ones that I have planned to add to
the history being kept. Obviously, as long as you are in control of
what the "shell" (i.e., C-C) does, you can do whatever you wish in
terms of gathering history.

Now, I can search out any program that has been C-C'd, and see the
information I desire.

Don't know if this helps, but it works for my needs.


Jim Cronin
Kittery Trading Post

JJCSR wrote:

Jim - Good for you! I have a program called WED.COMPILE that does
exactly what you describe above, called from AccuTerm wED (Windows
Editor). I use this to do a C-C on all platforms, flash-compile in
D3, etc. It seems whenever I suggest here that people create verb
overloads like this that people scream from the rafters about how
terrible that is and how such things should come from the vendor.
(Ignore for a moment how many convenience functions like this Do come
from the vendors but people don't bother to read the documentation to
find them. *ahem*) This is the very nature of the Linux platform
which people pretend to love so much, and yet somehow for Pick it's
not acceptable. Use it and abuse it, I say!
[snip]

On Nov 1, 7:31*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:

Sometimes, its just seems to relate to the age-old axiom, "necessity
is the mother of invention". First, I needed to have a way to
compile/catalog, with as little effort as possible. I had literally
thousands of programs that needed to be moved from D3 to Reality. "C-
C" was the answer.

One thing I failed to mention, earlier, is that C-C works off a
"readnext", so I can have an active list to work from; if any compiles
fail, the C-C will pause and let me know. I can make note of the
program(s) in error, make repairs, and then re"C-C". Where this
feature comes in handy is in situations that I just experienced,
recently. I had a "legacy" program, inherited with the package we
purchased some 27 years ago. I was having to make major
modifications to this 1100+ line program, so I decided to break it up
into subroutines.

First there was the need to create a set of commons. Another
"invention", "CREATE-COMMONS", a program that: 1) create-file b-sym
("c-sym" in Reality); 2) clear-file data b-sym; 3) compile with "(x"
option. CREATE-COMMONS finds all "dim" and "file opens", builds the
commons, accordingly, then reads all of the alpha-variables created in
c-sym and sets up the common statements, in alpha sequence. This
operation to build commons is really fast and easy.

Once the commons are built, I can then use wED to cut-paste portions
of the original program into subroutines, and insert the "INCLUDE
COMMONS". As I proceeded to make changes to the subroutines (now
numbering about 13), there were occasional additions to the commons.
I used a macro to select the programs/commons, and "C-C" them all at
once, thereby keeping all programs compliant with the current set of
commons.

So much for programming - I gotta go do some painting.

Have a great November, everyone.

Jim Cronin
Kittery Trading Post



I