DVD List View is a working program which demonstrates the use of
Microsoft .NET WinForms DataTable, DataView and DataGrid controls to
display, filter and modify Region 1 DVD Catalog data stored in a CSV
(comma-separated values) text format file.
A screenshot is at:
http://www.cfbsoftware.com/gpcp/DVDListView.gif
Built-in features of the DataGrid control and additional functions
implemented in the program enable it to be used to:
* Load and store a CSV text file to / from a DataGrid control
* Edit the contents of cells in the grid
* Delete and append rows
* Sort the data by any of the columns in ascending or descending
order by clicking on the column headings
* Filter the data by a selection of values for a combination of
fields within a date range, with exact match and case sensitivity
options
* Save modified data or the current filtered view as a CSV text file
The full Component Pascal source code of DVD List View is included.
It is designed to be readily modified to be used with any single-
file CSV (or similar delimited text format) set of data.
For more details and to download a copy go to:
http://www.cfbsoftware.com/gpcp
Chris Burrows
CFB Software
hi John,
Thanks for your response. I have written my own versions of
RealToString and StringToReal procedures. Therefore, the problem is
no longer annoying me.
thanks again,
panda
--- In GPCP@yahoogroups.com, "K John Gough" <john@S...> wrote:
> Hi panda, hi All
>
> This is not an error, it is just a warning message.
> In Modula-2 definition modules cannot be imported in a cycle.
However
> the implementation modules CAN have circular imports. If you have
> initialization sections in such modules that depend on the
> initialization of each other then you can have unexpected
behaviour.
> That is why the warning message tells you the arbitrary order that
the
> build program has chosen, in which the module bodies will actually
be
> initialized. In this case it is impossible for there to be a
problem
> since RealStr has no module initialization (as shown by the "(empty
> body)" note. I guess we could have made it so that you don't get
the
> warning if at least one module in the cycle has an empty body.
<sigh>
> maybe if we were designing it now instead of 1990 </sigh>
>
> Cheers
> John
>
> -----Original Message-----
> From: GPCP@yahoogroups.com [mailto:GPCP@yahoogroups.com] On Behalf
Of
> ooo_colour_panda_ooo
> Sent: Thursday, 28 July 2005 3:44 AM
> To: GPCP@yahoogroups.com
> Subject: [GPCP] need help!! circular imports error when using
RealStr
>
>
> hi all,
> I am using GPM Modula-2 redhat 7 version compiler on my redhat 9
> machine. Everything seem to be Okay, but when I attampt to build
a
> program which import a procedure from RealStr in ISOlib; I get an
> error message:
> Circular imports, initialization order is
> <RealConv>
> <RealStr> (empty body)
>
> Is there any solution for this problem?
>
> I appreciate if anyone can help.
>
> panda
>
>
>
>
>
>
>
> Yahoo! Groups Links
Hi panda, hi All
This is not an error, it is just a warning message.
In Modula-2 definition modules cannot be imported in a cycle. However
the implementation modules CAN have circular imports. If you have
initialization sections in such modules that depend on the
initialization of each other then you can have unexpected behaviour.
That is why the warning message tells you the arbitrary order that the
build program has chosen, in which the module bodies will actually be
initialized. In this case it is impossible for there to be a problem
since RealStr has no module initialization (as shown by the "(empty
body)" note. I guess we could have made it so that you don't get the
warning if at least one module in the cycle has an empty body. <sigh>
maybe if we were designing it now instead of 1990 </sigh>
Cheers
John
-----Original Message-----
From: GPCP@yahoogroups.com [mailto:GPCP@yahoogroups.com] On Behalf Of
ooo_colour_panda_ooo
Sent: Thursday, 28 July 2005 3:44 AM
To: GPCP@yahoogroups.com
Subject: [GPCP] need help!! circular imports error when using RealStr
hi all,
I am using GPM Modula-2 redhat 7 version compiler on my redhat 9
machine. Everything seem to be Okay, but when I attampt to build a
program which import a procedure from RealStr in ISOlib; I get an
error message:
Circular imports, initialization order is
<RealConv>
<RealStr> (empty body)
Is there any solution for this problem?
I appreciate if anyone can help.
panda
Yahoo! Groups Links
hi all,
I am using GPM Modula-2 redhat 7 version compiler on my redhat 9
machine. Everything seem to be Okay, but when I attampt to build a
program which import a procedure from RealStr in ISOlib; I get an
error message:
Circular imports, initialization order is
<RealConv>
<RealStr> (empty body)
Is there any solution for this problem?
I appreciate if anyone can help.
panda
Hi Chris, hi all
Sorry about the glitch. The following applies to the
.NET V1.1 version only, the "Whidbey" version is complete.
In the V1.1 version the file SymFileRW.cp is missing from
the source, and SymFileRW.dll is missing from the bin directory.
However, "OldSymFileRW.cp" is the same file except for naming.
The fix:
Copy all of source\gpcp\*.cp to the working directory.
Copy OldSymFileRW.cp to SymFileRW.
Edit the module name to "SymFileRW" (two occurrences).
You then need to recompile SymFileRW, which means you need
the symbol files of all the other modules. The symbol files produced
by PeToCps use different naming conventions, unfortunately. The
quickest is to use a 1.3.1 version to do this, using a working CPMake.
$> \prevGPCP\bin\CPMake /nocode /all gpcp
$> ilasm /dll /debug SymFileRW.il
Other methods are rather tedious.
In any case, just copy the new SymFileRW.dll file to the bin directory
of the new distribution.
I will get a fixed distribution up very soon.
Cheers
John
At 10:28 AM 20/06/2005, you wrote:
>I have checked out v1.3.2.0 (.NET Everett version) and am pleased to
>report that all of the issues that I previously reported with v1.3.1.x
>have now been fixed.
>
>The only problem I have currently is that CPMake is not working. It is
>still trying to access SymFileRW rather than Old/NewSymFileRW.
>
>I tried to modify and rebuild this myself but when I try to compile
>CPMake, gpcp objects to the the cps files produced by PeToCps:
>
>e.g.
>
>Wrong name in symbol file. Expected <GPCPcopyright>, found
><GPCPcopyright_>
>
>Chris Burrows
>CFB Software
>http://www.cfbsoftware.com/gpcp
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
I have checked out v1.3.2.0 (.NET Everett version) and am pleased to
report that all of the issues that I previously reported with v1.3.1.x
have now been fixed.
The only problem I have currently is that CPMake is not working. It is
still trying to access SymFileRW rather than Old/NewSymFileRW.
I tried to modify and rebuild this myself but when I try to compile
CPMake, gpcp objects to the the cps files produced by PeToCps:
e.g.
Wrong name in symbol file. Expected <GPCPcopyright>, found
<GPCPcopyright_>
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
I just downloaded the source code for GPCP.
Is everything available to build the complete compiler (gpcp.exe +
plus most of the .dlls)?
I would like to step through parts of the program to gain
understanding, but I don't see an easy way to build everything, so
that I can trace through the code with Visual Studio.
Am I on a path to failure?
Zumbas
Hi John,
Thanks for the detailed explanation concerning the primitive types -
sounds like a good idea. Fortunately I only have to make a couple of
source code changes.
I've now downloaded 1.3.1.2 GPCP for .NET and retested. All problems
I found previously have now been fixed - if only some of vendors of
the commercial development tools that I use were as responsive as
you guys!
Now that I've been able to proceed further with compiling some other
projects, I've come across a few additional issues:
------------------------------------------
1. Compiling the following test results in the compiler panic:
error : Exception: System.NullReferenceException: Object reference
not set to an instance of an object.
at CPascalP.CPascalP.findMatchingProcs(OvlId oId, ExprSeq actuals,
PrcSeq& rslt)
MODULE TestInit;
IMPORT
Wfm := System_Windows_Forms_;
PROCEDURE AddSubMenuItem* (VAR item: Wfm.MenuItem);
BEGIN
item := Wfm.MenuItem.init()
END;
END TestInit.
------------------------------------------
2. Compiling the following test results in the compiler panic:
Test3.cp(1,255) : error : Exception: System.NullReferenceException:
Object reference not set to an instance of an object.
at TypeDesc.Record.isBaseOf(Type e)
MODULE Test3;
IMPORT
Wfm := System_Windows_Forms_,
Str := System__Collections_Specialized,
CPmain;
PROCEDURE UpdateEntry*(ListView: Wfm.ListView);
VAR
items: Str.StringCollection;
BEGIN
items := ListView.get_Items();
END UpdateEntry;
END Test3.
------------------------------------------
3. Running PeToCps on some dll's (compiled with VS2003.NET C#) fails
with the error:
PeToCps: version 1.3.1.2 of 10 April 2005
PeToCps: System.ArgumentOutOfRangeException: Index and length must
refer to a location within the string.
Parameter name: length
at System.String.Substring(Int32 startIndex, Int32 length)
at PeToCps.PeToCps.GetVersionInfo(PEFile pef, Int32[]& inf)
at PeToCps.PeToCps.Process(Char[] nam, Int32& rVl)
PeToCps: Input file <RTBExCs.dll> error
If you want to try to reproduce this one, you will find a copy of
RTBExCs.dll included in my Winforms demo:
http://cfbsoftware.com/files/GPCPWinFormDemo.zip
------------------------------------------
Regards,
Chris
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
--- In GPCP@yahoogroups.com, "K John Gough" <john@S...> wrote:
>
> In version 1.3.1 this problem is "solved" by keeping System.Char
and
> CHAR completely separate. So all of the static methods of all of
these
> types are now accessible.
Hi All
Chris's issue is a change in version 1.3.1 that did not receive
sufficient of a highlight in the CLR release notes. In version 1.3.0
and earlier the primitive types such as System.Char were just synonyms
for the corresponding Component Pascal types such as CHAR. (Look at the
V1.3.0 version of mscorlib_System.html to see this.) This choice had the
unfortunate effect of making it impossible to access the useful static
methods of these types such as
PROCEDURE IsPunctuation*(c : CHAR) : BOOLEAN;
Since Sys.Char.IsPunctuation(ch) would get an error since Sys.Char is
not a record type.
In version 1.3.1 this problem is "solved" by keeping System.Char and
CHAR completely separate. So all of the static methods of all of these
types are now accessible. For example, the above method would be invoked
as
Sys.Char.IsPunctuation(ch).
The price that is paid, until I can do a lot more hacking on the type
system, is that the System type and the builtin type are incompatible.
So in order to avoid really hard to diagnose bugs I have made the system
primitives appear to be ABSTRACT. So you can't declare a variable of
these types. All parameters to system methods and return types are the
builtin types such as CHAR. The System name can only appear as a prefix
in a static method invocation, and since you cannot have a variable of
these types the *virtual* methods on these types are still unavailable.
Here is the declaration of the Int32 type as it appears in the V1.3.1
mscorlib_System.html
Int32* = ABSTRACT RECORD (* Typebound Procedures *)
STATIC
MaxValue* = 2147483647;
MinValue* = -2147483648;
PROCEDURE Parse*(s : String;
provider : IFormatProvider) : INTEGER;
PROCEDURE Parse*(s : String;
style :
mscorlib_System_Globalization.NumberStyles;
provider : IFormatProvider) : INTEGER;
PROCEDURE Parse*(s : String) : INTEGER;
PROCEDURE Parse*(s : String;
style :
mscorlib_System_Globalization.NumberStyles) : INTEGER;
END;
I realise that this is a breaking change, but the previous semantics are
captured exactly by replacing the V1.3.0 types such as Sys.Int32 by the
builtin type that they *used* to be an alias for, INTEGER in this case.
I am really sorry that I missed the importance of this in the
documentation. I shall fix it for the next refresh.
Cheers
John
-----Original Message-----
From: GPCP@yahoogroups.com [mailto:GPCP@yahoogroups.com] On Behalf Of
cfbsoftware1
Sent: Tuesday, 19 April 2005 11:06 AM
To: GPCP@yahoogroups.com
Subject: [GPCP] V1.3.1 Error message
When compiling the following global declaration using v1.3.1 GPCP
for .NET:
VAR
i: Sys.Int32;
(Sys is an alias for the imported mscorlib_System)
I get the following error message:
"Variables of ABSTRACT type cannot be instantiated."
It compiles without an error on v1.3.0. Is this related to the other
issues with v1.3.1 or is it something else?
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
Yahoo! Groups Links
When compiling the following global declaration using v1.3.1 GPCP
for .NET:
VAR
i: Sys.Int32;
(Sys is an alias for the imported mscorlib_System)
I get the following error message:
"Variables of ABSTRACT type cannot be instantiated."
It compiles without an error on v1.3.0. Is this related to the other
issues with v1.3.1 or is it something else?
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
Hi John,
the Compiler Panic Message I reported in my last mail this afternoon
seems to be due to the naming of the type PredPntr in the LpsPredicate
Module. PredPntr doesn’t work. ( Predpntr too doesn’t).
But it works if it is named Pred or Predpppp and so on.
MODULE LpsPredicate;
IMPORT InterfacecpStringPntr,Interface_InfoAboutFile,
SivQueues,
LpsType,LpsInit, LpsKante,LpsClass;
TYPE PredPntr* = POINTER TO ABSTRACT RECORD (LpsKante.lpsPntrType)
END;
BEGIN
END LpsPredicate.
----------------------------------------------------------
MODULE LpsMethod;
IMPORT LpsKante,LpsPredicate;
TYPE ArgumentList=ARRAY 3 OF LpsKante.lpsPntrType;
BEGIN
END LpsMethod.
C:\Programme\Eclipse\eclipse-SDK-3.0.1-win32\eclipse\LpsSwt-workspace\LpsSWT>cpr
un gpcp -dostats -verbose Lps\LpsMethod.CP
[GC 508K->97K(1984K), 0.0027297 secs]
#gpcp: opened local file <Lps\LpsMethod.CP>
[GC 608K->171K(1984K), 0.0015650 secs]
#gpcp: Starting Parse
[GC 680K->226K(1984K), 0.0016796 secs]
#gpcp: Opened LpsKante.cps
[GC 738K->614K(1984K), 0.0025925 secs]
#gpcp: Ended LpsKante.cps, Key: -304892923
#gpcp: Opened LpsPredicate.cps
[GC 1126K->1062K(1984K), 0.0029279 secs]
[GC 1574K->1532K(2112K), 0.0023070 secs]
[Full GC 1532K->1532K(2112K), 0.0126533 secs]
#gpcp: Ended LpsPredicate.cps, Key: 1967030271
#gpcp: << COMPILER PANIC >>
Error 299@ line: 1, col: 1
Compiler raised an internal exception
1 MODULE LpsMethod;
**** ^ Compiler raised an internal exception
**** Exception: java.lang.NullPointerException
#gpcp: <LpsMethod> There was one error
And now the working example:
MODULE LpsPredicate;
IMPORT InterfacecpStringPntr,Interface_InfoAboutFile,
SivQueues,
LpsType,LpsInit, LpsKante,LpsClass;
TYPE Pred* = POINTER TO ABSTRACT RECORD (LpsKante.lpsPntrType)
END;
BEGIN
END LpsPredicate.
----------------------------------------------------------
MODULE LpsMethod;
IMPORT LpsKante,LpsPredicate;
TYPE ArgumentList=ARRAY 3 OF LpsKante.lpsPntrType;
BEGIN
END LpsMethod.
------------------------------------------------------------------------.
…..
#gpcp: Created LpsMethod.cps
#gpcp: Emitting assembler
Creating file CP\LpsMethod\LpsMethod.class
#gpcp: Created CP/LpsMethod/LpsMethod.class
[GC 2186K->1692K(3132K), 0.0017597 secs]
#gpcp: <LpsMethod> No errors
#gpcp: jvm version 1.3.1 of 12 February 2005
#gpcp: 10 source lines
#gpcp: import recursion depth 1
#gpcp: 391 entries in hashtable of size 8209
#gpcp: import time 391mSec
#gpcp: source time 109mSec
#gpcp: parse time 172mSec
#gpcp: analysis time 0mSec
#gpcp: symWrite time 15mSec
#gpcp: asmWrite time 63mSec
#gpcp: assemble time 0mSec
#gpcp: total time 750mSec
Perhaps there might be some hints to circumvent the problem I encountered.
ThanX + Cheers
Juergen
Hi John,
I got a compiler panic message from your 1.3.1 compiler in the adjoined
program example:
The error does not occur if LpsPredicate is not imported . It occurs
only if there is some reference to a type in LpsKante. If LpsKante is
imported, but without any reference to its types, there is no error.
Thanks & Cheers
Juergen
MODULE LpsMethod;
IMPORT LpsKante,LpsPredicate;
TYPE ArgumentListType =ARRAY 3 OF LpsKante.lpsPntrType;
BEGIN
END LpsMethod.
C:\Programme\Eclipse\eclipse-SDK-3.0.1-win32\eclipse\LpsSwt-workspace\LpsSWT>cpr
un gpcp -dostats -verbose Lps\LpsMethod.CP
[GC 508K->97K(1984K), 0.0026876 secs]
#gpcp: opened local file <Lps\LpsMethod.CP>
[GC 608K->171K(1984K), 0.0015335 secs]
#gpcp: Starting Parse
[GC 680K->226K(1984K), 0.0019447 secs]
#gpcp: Opened LpsKante.cps
[GC 738K->614K(1984K), 0.0026104 secs]
#gpcp: Ended LpsKante.cps, Key: -304892923
#gpcp: Opened LpsPredicate.cps
[GC 1126K->1067K(1984K), 0.0029137 secs]
[GC 1579K->1538K(2112K), 0.0023651 secs]
[Full GC 1538K->1538K(2112K), 0.0127932 secs]
#gpcp: Ended LpsPredicate.cps, Key: 1791083445
#gpcp: << COMPILER PANIC >>
Error 299@ line: 1, col: 1
Compiler raised an internal exception
1 MODULE LpsMethod;
**** ^ Compiler raised an internal exception
**** Exception: java.lang.NullPointerException
#gpcp: <LpsMethod> There was one error
Hi John,
The new GPCP 1.3.1 for .NET installer (5 April) fixed that
particular problem but I still have been unable to compile my
WinForms RichText example project. Try building it yourself from the
source:
http://cfbsoftware.com/gpcp/GPCPWinformDemo.zip
to see if you can duplicate the problems I have encountered:
1. PEToCps gives an 'Argument out of range' exception when producing
a new cps file for RTBExCs.dll
2. Form.set_AcceptButton now expects an 'IButtonControl' parameter
instead of 'Button'.
3. The statement 'REGISTER(frm.lblWebsite.LinkClicked,
frm.lblWebsiteClicked)' objects to the first parameter with the
error message:
'error : REGISTER expects an EVENT type here'
Regards,
Chris
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> Hi All
>
> As Chris has detected, the symbol files in the directory
> $CPROOT/libs/NetSystem
> are missing all of their event fields. We have fixed it, and
> should get the new installers up on the website tomorrow.
> We will get the broken link to the JVM version fixed at
> the same time.
>
> Cheers
> John
>
>
> At 07:36 AM 3/04/2005 +0000, you wrote:
>
>
> >Hi John,
> >
> >The 1.3.1 GPCP/CLR 1.1 compiler reports that the click event
> >handlers for controls are missing. e.g. in Systems_Windows_Forms_
in
> >1.3.0,
> >
> >LinkLabel had a field
LinkClicked* :LinkLabelLinkClickedEventHandler;
> >
> >MenuItem had a field Click* : mscorlib_System.EventHandler;
> >
> >Also, I can't see these fields defined in the html versions of the
> >1.3.1 cps files.
> >
> >Chris Burrows
> >CFB Software
> >http://www.cfbsoftware.com/gpcp
> >
Hi All
As Chris has detected, the symbol files in the directory
$CPROOT/libs/NetSystem
are missing all of their event fields. We have fixed it, and
should get the new installers up on the website tomorrow.
We will get the broken link to the JVM version fixed at
the same time.
Cheers
John
At 07:36 AM 3/04/2005 +0000, you wrote:
>Hi John,
>
>The 1.3.1 GPCP/CLR 1.1 compiler reports that the click event
>handlers for controls are missing. e.g. in Systems_Windows_Forms_ in
>1.3.0,
>
>LinkLabel had a field LinkClicked* :LinkLabelLinkClickedEventHandler;
>
>MenuItem had a field Click* : mscorlib_System.EventHandler;
>
>Also, I can't see these fields defined in the html versions of the
>1.3.1 cps files.
>
>Chris Burrows
>CFB Software
>http://www.cfbsoftware.com/gpcp
>
>--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> > Hi All
> >
> > version 1.3.1 of GPCP is now up, but you will need a new URL.
> >
> > http://plas.fit.qut.edu.au/gpcp/
> >
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
Hi All
As Chris has detected, the symbol files in the directory
$CPROOT/libs/NetSystem
are missing all of their event fields. We have fixed it, and
should get the new installers up on the website tomorrow.
We will get the broken link to the JVM version fixed at
the same time.
Cheers
John
At 07:36 AM 3/04/2005 +0000, you wrote:
>Hi John,
>
>The 1.3.1 GPCP/CLR 1.1 compiler reports that the click event
>handlers for controls are missing. e.g. in Systems_Windows_Forms_ in
>1.3.0,
>
>LinkLabel had a field LinkClicked* :LinkLabelLinkClickedEventHandler;
>
>MenuItem had a field Click* : mscorlib_System.EventHandler;
>
>Also, I can't see these fields defined in the html versions of the
>1.3.1 cps files.
>
>Chris Burrows
>CFB Software
>http://www.cfbsoftware.com/gpcp
>
>--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> > Hi All
> >
> > version 1.3.1 of GPCP is now up, but you will need a new URL.
> >
> > http://plas.fit.qut.edu.au/gpcp/
> >
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
Hi John,
The 1.3.1 GPCP/CLR 1.1 compiler reports that the click event
handlers for controls are missing. e.g. in Systems_Windows_Forms_ in
1.3.0,
LinkLabel had a field LinkClicked* :LinkLabelLinkClickedEventHandler;
MenuItem had a field Click* : mscorlib_System.EventHandler;
Also, I can't see these fields defined in the html versions of the
1.3.1 cps files.
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> Hi All
>
> version 1.3.1 of GPCP is now up, but you will need a new URL.
>
> http://plas.fit.qut.edu.au/gpcp/
>
Hi All
As Russell points out, the download page for the JVM/Win32 seems to be
broken. Profuse apologies. We will try to find out what happened
Monday.
Cheers
John
Thanks! Especially for the updated zip version.
Small problem - trying to get the installer JVM version shows a
heading "Downloading GPCP 1.3.1-NET 1.0" on the URL
http://plas.fit.qut.edu.au/gpcp/gpcp_download.aspx?downloadID=GPCP131JVM
and the download does not initiate.
Where can I find out more about generics?
Regards,
Russell
--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> Hi All
>
> version 1.3.1 of GPCP is now up, but you will need a new URL.
>
> http://plas.fit.qut.edu.au/gpcp/
>
> is the place to start, then to the downloads page. This page
> is NOT yet linked from the old page.
>
> Version 1.3.1 comes in four flavours:
> GPCP/CLR 1.1 (Everett) Installer
> GPCP/CLR 2.0 (Whidbey) installer
> GPCP/JVM/Win32 installer
> GPCP/JVM/Unix gzip distribution
>
> This version resolves most known issues, and has new
> documentation detailing the changes. It also contains a
> new PE to CPS tool replacing N2CPS. The new tool is
> "PeToCps", and does not barf on Whidbey PE files.
>
> There is also a rather cool "online" compiler for some
> experimental subsets of "Mini GPCP", including some
> generics experiments. We still expect to do generics
> at least on the CLR for version 1.4.*
>
> Enjoy
> John
Hi All
should have also mentioned:
Diane Corney's PE Reader Writer, aka PERWAPI
in available starting from the same URL ---
http://plas.fit.qut.edu.au/gpcp/
This component will replace PEAPI for *writing* PE files
and can also *read* PE files in a compatible way.
The reading side is the basis of the new PeToCps
application, while the writing side is now robust enough
to bootstrap the 1.4.* prototype of gpcp.
Anyone using PEAPI who is moving to Whidbey will
need to switch to PERWAPI, as we will not be upgrading
the older program to read the new version of the metadata
in the Whidbey release.
Cheers
John
Hi All
version 1.3.1 of GPCP is now up, but you will need a new URL.
http://plas.fit.qut.edu.au/gpcp/
is the place to start, then to the downloads page. This page
is NOT yet linked from the old page.
Version 1.3.1 comes in four flavours:
GPCP/CLR 1.1 (Everett) Installer
GPCP/CLR 2.0 (Whidbey) installer
GPCP/JVM/Win32 installer
GPCP/JVM/Unix gzip distribution
This version resolves most known issues, and has new
documentation detailing the changes. It also contains a
new PE to CPS tool replacing N2CPS. The new tool is
"PeToCps", and does not barf on Whidbey PE files.
There is also a rather cool "online" compiler for some
experimental subsets of "Mini GPCP", including some
generics experiments. We still expect to do generics
at least on the CLR for version 1.4.*
Enjoy
John
Hi Juergen
This looks really interesting. I have not seen such large heap usage
before, particularly as this appears to be just the imports. The
abstract program representation is pretty wasteful, typically about ten
bytes of heap space for every byte of source program.
I have seen cases where the number of identifiers in an imported module
overflows the hash table so that the "-hsize=NNNN" option is needed, so
I am suspicious if memory runs out first. As well, it seems suspicious
if a module can compile without running out of memory if just the
*exports* of the module exhaust the memory of compilation that imports
it. Does anyone else on the list have any experience of this?
As an experiment, could you try compiling empty programs that import
just one of the other modules, using the "verbose:gc" option. The idea
is to extablish the demands of each of the imported modules separately.
It would be interesting to find the memory demands of each of these
programs when they are compiled. I am suggesting three metrics for each
module:
(1) memory used during compilation
(2) size of symbol (cps) file produced
(3) memory used by empty module importing this module.
Good luck with it.
John
-----Original Message-----
From: Jürgen Rolshoven [mailto:rols@...]
Sent: Monday, 14 March 2005 7:29 PM
To: GPCP@yahoogroups.com
Subject: [GPCP] More memory?
Hi John,
I try to compile a rather complex program for machine translation of
natural language. When GPCP parses the import list of a module, I got a
OutOfMemory error.
Are there any means (other than buying more memory (more than 512 MB) to
reduce the demand of memory? Please see included list produced by the
verbose:gc option.
Thanks & cheers
Jürgen
C:\Programme\Eclipse\eclipse\LpsSwt-workspace\LpsSWT>cprun gpcp -warn-
-verbose
-version Lps\LpsPrsHl.CP
[GC 511K->96K(1984K), 0.0029850 secs]
#gpcp: jvm version 1.3.0 of 16 September 2004
#gpcp: opened local file <Lps\LpsPrsHl.CP>
[GC 608K->170K(1984K), 0.0018449 secs]
#gpcp: Starting Parse
[GC 681K->292K(1984K), 0.0020765 secs]
#gpcp: Opened SivQueues.cps
#gpcp: Ended SivQueues.cps, Key: 624375872
#gpcp: Opened SivRefQueues.cps
#gpcp: Ended SivRefQueues.cps, Key: 1268498086
#gpcp: Opened LpsType.cps
#gpcp: Ended LpsType.cps, Key: 1375846592
#gpcp: Opened LpsKante.cps
[GC 804K->678K(1984K), 0.0029789 secs]
#gpcp: Ended LpsKante.cps, Key: 1578917014
#gpcp: Opened LpsPredicate.cps
[GC 1190K->1130K(1984K), 0.0032485 secs]
#gpcp: Ended LpsPredicate.cps, Key: 2107979898
#gpcp: Opened LpsSharing.cps
[GC 1642K->1583K(2112K), 0.0033426 secs]
[Full GC 1583K->1583K(2112K), 0.0146764 secs]
[GC 2047K->1999K(3136K), 0.0075132 secs]
[GC 2511K->2472K(3136K), 0.0022648 secs]
#gpcp: Ended LpsSharing.cps, Key: 838867866
#gpcp: Opened SemTree.cps
[GC 2984K->2935K(3520K), 0.0049727 secs]
[Full GC 2935K->2935K(3520K), 0.0211027 secs]
[GC 3447K->3385K(5472K), 0.0019776 secs]
[GC 3897K->3858K(5472K), 0.0025059 secs]
[GC 4370K->4330K(5472K), 0.0025621 secs]
[GC 4842K->4803K(5472K), 0.0022503 secs]
[GC 5315K->5280K(5856K), 0.0022539 secs]
[Full GC 5280K->5280K(5856K), 0.0331380 secs]
#gpcp: Ended SemTree.cps, Key: -1381528676
#gpcp: Opened LpsOOP.cps
[GC 5919K->5858K(9504K), 0.0128480 secs]
[GC 6498K->6351K(9504K), 0.0026274 secs]
[GC 6991K->6934K(9504K), 0.0032490 secs]
[GC 7574K->7518K(9504K), 0.0028319 secs]
[GC 8158K->8109K(9504K), 0.0030325 secs]
[GC 8749K->8700K(9504K), 0.0028593 secs]
[GC 9340K->9291K(10016K), 0.0028579 secs]
[Full GC 9291K->9185K(10016K), 0.0796073 secs]
[GC 10179K->10103K(16464K), 0.0045511 secs]
[GC 11127K->11058K(16464K), 0.0046766 secs]
[GC 12082K->12004K(16464K), 0.0051624 secs]
[GC 13028K->12950K(16464K), 0.0050484 secs]
[GC 13974K->13895K(16464K), 0.0052116 secs]
#gpcp: Ended LpsOOP.cps, Key: 83093640
#gpcp: Opened LpsLex.cps
[GC 14919K->14813K(16464K), 0.0202543 secs]
[GC 15837K->15389K(16464K), 0.0033577 secs]
[GC 16413K->16344K(17488K), 0.0051607 secs]
[Full GC 16344K->16344K(17488K), 0.0893658 secs]
[GC 18255K->18123K(29340K), 0.0347189 secs]
[GC 20043K->19882K(29340K), 0.0107637 secs]
[GC 21802K->21675K(29340K), 0.0102463 secs]
[GC 23595K->23448K(29340K), 0.0110045 secs]
[GC 25368K->25222K(29340K), 0.0111151 secs]
[GC 27142K->26995K(29340K), 0.0110025 secs]
[GC 28915K->28768K(30748K), 0.0111889 secs]
[Full GC 28768K->28768K(30748K), 0.1514681 secs]
[GC 31899K->31660K(51376K), 0.0579568 secs]
[GC 34924K->34714K(51376K), 0.0185356 secs]
[GC 37978K->37729K(51376K), 0.0203233 secs]
[GC 40993K->40743K(51376K), 0.0194860 secs]
[GC 44007K->43758K(51376K), 0.0197154 secs]
[GC 47022K->46704K(51376K), 0.0187309 secs]
#gpcp: Ended LpsLex.cps, Key: 377225571
#gpcp: Opened LpsInfer.cps
[GC 49968K->49708K(53040K), 0.0714127 secs]
[Full GC 49708K->49708K(53040K), 0.2563465 secs]
[GC 55023K->53249K(88592K), 0.0907931 secs]
[GC 58881K->58498K(88592K), 0.0365639 secs]
[GC 64130K->63687K(88592K), 0.0350145 secs]
[GC 69319K->68876K(88592K), 0.0356987 secs]
[GC 74508K->74078K(88592K), 0.0380713 secs]
[GC 79710K->79358K(88592K), 0.0320960 secs]
[GC 84990K->84560K(90256K), 0.0353492 secs]
[Full GC 84560K->83347K(90256K), 0.6132592 secs]
[GC 92627K->91918K(149348K), 0.0544460 secs]
[GC 101198K->100489K(149348K), 0.0589025 secs]
[GC 109769K->109060K(149348K), 0.0583499 secs]
[GC 118340K->117632K(149348K), 0.0579982 secs]
[GC 126912K->126203K(149348K), 0.0565427 secs]
[GC 135483K->134930K(149348K), 0.0524874 secs]
[GC 144210K->143501K(152804K), 0.0589488 secs]
[Full GC 143501K->143501K(152804K), 0.7247460 secs]
[GC 158243K->157117K(255144K), 0.2763823 secs]
[GC 172989K->171777K(255144K), 0.1039367 secs]
[GC 187649K->186436K(255144K), 0.0983776 secs]
[GC 202308K->200745K(255144K), 0.0947338 secs]
#gpcp: Ended LpsInfer.cps, Key: 317821821
#gpcp: Opened LpsDoMethods.cps
[GC 216617K->213836K(255144K), 0.3136946 secs]
[GC 229708K->228505K(255144K), 0.1010905 secs]
[GC 244377K->243165K(259112K), 0.1039247 secs]
[Full GC 243165K->243165K(259112K), 1.2333453 secs]
[GC 264426K->262802K(432304K), 0.4507003 secs]
[GC 289682K->287941K(432304K), 0.1734377 secs]
[GC 314821K->312768K(432304K), 0.1868087 secs]
[GC 339648K->337595K(432304K), 0.1921909 secs]
[GC 364475K->362304K(432304K), 0.9417772 secs]
#gpcp: Ended LpsDoMethods.cps, Key: -363362136
#gpcp: Opened TreeModels.cps
[GC 389184K->385243K(432304K), 1.6765215 secs]
[GC 412123K->410069K(437040K), 2.4450761 secs]
[Full GC 410069K->410069K(437040K), 36.0429879 secs]
[GC 437039K->434979K(487744K), 3.8781680 secs]
[Full GC 465187K->458792K(487744K), 166.3777958 secs]
[Full GC 487743K->485532K(487744K), 204.4186468 secs]
[Full GC 485532K->485532K(487744K), 221.0470065 secs]
Exception in thread "main" java.lang.OutOfMemoryError
Yahoo! Groups Links
Hi All
Yes N2CPS has a difficulties with the 1.3.0 release. We have replaced
it with
A new program PeToCps which will be going out with the 1.3.1 release
this week.
The new program works for Whidbey (2.0) as well as Everett (1.1) and is
based on
The new PE Reader/Writer API "PERWAPI".
Sorry for the glitch. Watch out for the new release, I will post when
it is up.
Cheers
John
-----Original Message-----
From: Anes Sadikovic [mailto:asadik@...]
Sent: Tuesday, 8 March 2005 2:34 PM
To: GPCP@yahoogroups.com
Subject: [GPCP] N2cps crashes
I am using .NET version 1.1 and the latest version of GPCP for it.
Everything is working fine, except n2cps. It is crashing giving
unhandled exception in MetaParser.MetaParser.
I remember this one use to be working fine under .NET 1.0 and one of the
previous versions of GPCP.
Does anyone else has the same experience?
Anes Sadikovic
Yahoo! Groups Links
I am using .NET version 1.1 and the latest version of GPCP for it.
Everything is working fine, except n2cps. It is crashing giving
unhandled exception in MetaParser.MetaParser.
I remember this one use to be working fine under .NET 1.0 and one of
the previous versions of GPCP.
Does anyone else has the same experience?
Anes Sadikovic
if you look at the CPRUN.bat script, you will see how to set the search path for the java system. The flag is
-DCPSYM=.;%JRoot%\libs;%JRoot%\libs\JvmSystem
Cheers
John
By the way, the error with the method with four VAR params was a simple buffer overflow in ClassUtil.cp, caused by the length of the method signature in the constant pool of the class file. We have a fix which will go out with version 1.3.1, early next week. If you are confident to recompile the compiler, the buffer, length 256, in procedure
PROCEDURE (u : UTF8)Dump(...)
can be increased to 512 to get you going. Our real fix uses a dynamically resized buffer, but its a bit harder for users to fix themselves.
Cheers
John
-----Original Message----- From: Jürgen Rolshoven [mailto:rols@...] Sent: Tuesday, 15 February 2005 7:15 AM To: GPCP@yahoogroups.com Subject: [GPCP] OutOfMemory
Hi All,
working with gpcp (under MS-Windows) I encountered two problems related both to each other. When importing a quite large CPS-file, I got an an OutOfMemoryError during compilation:
C:\LpsSWT>cprun gpcp Lps\LpsBaum.CP Exception in thread "main" java.lang.OutOfMemoryError.
Is there a possibility to increase heap space in the cprun script?
Then I tried to compile my module directly; I augmented heap space to 128 M. I got a compiler panic message. The compiler did not find the cps-files which should be imported. There is - I presume - a path to be set, but I don't know how to do.
C:\LpsSWT>java -Xmx128 CP.gpcp.gpcp Lps\LpsBaum.CP #gpcp: << COMPILER PANIC >> 1 MODULE LpsBaum; **** ^ Compiler raised an internal exception **** Exception: java.lang.NullPointerException #gpcp: <LpsBaum> There was one error
working with gpcp (under MS-Windows) I encountered two problems related
both to each other.
When importing a quite large CPS-file, I got an an OutOfMemoryError
during compilation:
C:\LpsSWT>cprun gpcp
Lps\LpsBaum.CP
Exception in thread "main" java.lang.OutOfMemoryError.
Is there a possibility to increase heap space in the cprun
script?
Then I tried to compile my module directly; I augmented heap space to
128 M.
I got a compiler panic message. The compiler did not find the cps-files
which should be imported.
There is - I presume - a path to be set, but I don't know how to do.
C:\LpsSWT>java -Xmx128 CP.gpcp.gpcp
Lps\LpsBaum.CP
#gpcp: << COMPILER PANIC >>
1 MODULE LpsBaum;
**** ^ Compiler raised an internal exception
**** Exception: java.lang.NullPointerException
#gpcp: <LpsBaum> There was one error
--- In GPCP@yahoogroups.com, John Gough <j.gough@q...> wrote:
> For those who can't wait, here is the fix.
> ...
> Recompile TypeDesc.cp and move the resulting class files into your
> $CPROOT/CP/TypeDesc directory.
Can't recompile. There are no cps files for <gpcp> modules in my
distribution, so this modules don't want to be imported.
I'v tried to recompile all needed modules but was stopped at this point:
===
C:\Apps\gpcp\work\temp>cprun gpcp LitValue.cp
15 CPascalS;
**** ----------------^ Inconsistent module keys
**** Module <GPTextFiles> already imported with different key
#gpcp: <LitValue> There was one error
===
So I better wait for new version.
Thanks anyway.
At 09:49 AM 1/02/2005 +0000, fatlion2 wrote:
> > Ok, got it. The nested class Jtree$EmptySelectionNode declares a static
> > field and a static method with the same name ... "sharedInstance". I'll
> > see about a fix or workaround and post later. Cheers
> > John
>
>Thanks for quick answer.
>
>One more question. Why there are no fresh versions in zipped form?
>That's a boring problem for everybody who don't use windows.
Ok, here is the drum on the overloaded names in Javax/Swing
There is no workaround with the current javax_swing.cps file unfortunately.
However there is a simple edit to the compiler source that fixes it. We
will incorporate the fix into release 1.3.1, due out later this month. For
those who can't wait, here is the fix.
Take the source of TypeDesc.cp, find procedure InsertInRec(), here is my
edited version of the relevant lines
WITH existingId : Id.Procs DO
IF ~existingId.type.sigsMatch(id.type) THEN
oId := newOvlIdent(existingId,rec);
AddToOvlIdent(id,oId,doKindCheck,ok);
rec.symTb.Overwrite(oId.hash,oId);
END; (* and ok stays true! *)
(*
* | existingId : Id.FldId DO -- previous code
*)
| existingId : Id.AbVar DO (* new code *)
oId := newOvlIdent(existingId,rec);
The typecase selector "existingId : Id.FldId" is changed to "existingId :
Id.AbVar"
Recompile TypeDesc.cp and move the resulting class files into your
$CPROOT/CP/TypeDesc directory.
Please note that you will not have access to the overloaded field, but at
least the compiler will not barf when it reads the symbol file. We will
try to get access to the overloaded field fixed for either 1.3.1 or the
next. Inside swing this is not an issue since the method that overloads
the name is a public method returning the value of the protected field so
you don't need the field anyway.
Cheers
John
p.s. Oh, and yes, we are planning a zip / unix version of the new release.
>
John Gough
Professor
Faculty of Information Technology
Queensland University of Technology
VOX (61 7) 38649334
CRICOS No 00213J
> Ok, got it. The nested class Jtree$EmptySelectionNode declares a static
> field and a static method with the same name ... "sharedInstance". I'll
> see about a fix or workaround and post later. Cheers
> John
Thanks for quick answer.
One more question. Why there are no fresh versions in zipped form?
That's a boring problem for everybody who don't use windows.
Ok, got it. The nested class Jtree$EmptySelectionNode declares a static
field and a static method with the same name ... "sharedInstance". I'll
see about a fix or workaround and post later. Cheers
John
-----Original Message-----
From: fatlion2 [mailto:fatlion2@...]
Sent: Monday, 31 January 2005 10:13 PM
To: GPCP@yahoogroups.com
Subject: [GPCP] gpcp4JVM - what's wrong with swing?
Hi.
Can't import swing.
===
Test.cp:
MODULE Test;
IMPORT
CPmain,
java_awt,
javax_swing;
BEGIN
END Test.
Output:
C:\OOP>cprun gpcp Test.cp
5 javax_swing;
**** -------------------^ Name clash in imported scope
**** -------------------^ Name <sharedInstance> clashes in scope
<Anon-record>
#gpcp: <Test> There was one error
===
Why?
Yahoo! Groups Links