Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About excbv

  • Rank
  • Birthday 01/01/01
  1. Hello, I wrote the following program in Oberon-2: <* MAIN+ *> MODULE Test; (* why doesn't "Test 2>blabla.txt" work? *) IMPORT S:=SYSTEM,Txt:=TextIO,Sq:=SeqFile,St:=StdChans; BEGIN (*Sq.OpenWrite(cid,"blabla.txt",Sq.write,res); St.SetErrChan(cid);*) Txt.WriteString(St.ErrChan(),"bla bla bla") END Test. and found that the command line call "Test 2>blabla.txt" doesn't work (blabla.txt does not contain the string "bla bla bla"). Can someone explain why? Regards, excbv
  2. Hello, I just realized that I did not post a program example for the problem I described. Here it is: <*+ MAIN *> MODULE Test; (* Testing RegComp module; srcxp gives error output *) IMPORT In,Out,RegComp,Wh:=WholeStr; CONST backSl=134C; srcxp="([0-9,A-Z,a-z,_]{0-9,A-Z,a-z,_})$1.*"; VAR re:RegComp.Expr; res:LONGINT; ch:CHAR; str: ARRAY 32 OF CHAR; BEGIN In.Open; Out.Open; RegComp.Compile(srcxp,re,res); IF res>=0 THEN Out.String("OK") ELSE Wh.IntToStr(-res,str); Out.String("error in position "); Out.String(str) END; Out.Ln; Out.String("press RETURN to terminate"); In.Char(ch) END Test. The program indicates an error in position 34 of srcxp Any answer would be appreciated. Regards, excbv
  3. Hello, I haven't used the RegComp module very much so I'm not familiar with it. However, recently I began using it, and I encountered problems. For example, the following regular expression, which seems to conform to the user manual specs ([0-9,A-Z,a-z,_]{0-9,A-Z,a-z,_})$1.* results in a compilation error (when the Compile procedure is applied) in the next to last position. Can someone explain? Regards, excbv
  4. Running XDS M2 on Win7 6bit

    > I have recently tried to install 2.51 and 2.60 on a couple of different Win7 64bit boxes and run into trouble. > I tried 2.51 first on one followed by 2.60 (and vice versa on the other). Same outcome both times. Strange! I've never encountered problems with either 32-bit or 64-bit Windows 7. I install XDS in %USERPROFILE%\AppData\Local\Xds, and everything seems to work. > The compiler doesn't like source files on paths containing space characters " ". eg in "My Documents" > This is easily worked around. (it truncates the source file path at the first blank space) If you think that is the problem, try using an 8.3 name (see http://support.microsoft.com/kb/142982) > Unfortunately then the link step fails with "Severe Error: file open error: "xc.tem" no such file. > I have made the file xc.tem in \bin world r/w/m/e and tried running as full admin but no joy. > It all works fine under XP, but it would be nice to have it run on Win7 64 bit. I haven't tried it on 32bit Win7. > I also found a minor bug in the TS compatibility library for FIO but it can be worked around using XDS\FileSys (the FIO.ReadFirstEntry() call dies horribly if the wildcard pattern matches no files) > Thanks for any enlightenment or suggestions how to get it working. > Martin Brown Regards, excbv
  5. Hello, Recently I encountered a curious bug (?) in the RndFile module. I am attaching a demo program which exhibits the bug. I hope someone can verify it (or explain it away). Regards, excbv TestRndFile.zip
  6. Another remark concerning ProgExec.Execute: I thought that replacing ProgExec.Execute with ProgExec.ExecuteNoWindow (which had been added to the corresponding .def file in v. 2.60 beta 2) at a certain place in my program would prevent the crash that I mentioned in my previous post. However, after this change I discovered that the linker in XDS v. 2.60 beta 2 cannot find ProgExec.ExecuteNoWindow. I then searched the lib/x86/xds26i.lib file and, in fact, could not find that name. Again, is this a bug, or am I not understanding something? Regards, excbv
  7. Hello, I have installed XDS Native v. 2.60 beta 2 under Windows 7. When recompiled with v. 2.60 most of my Oberon2 stuff works OK; however, I have encountered a problem with XDS, v. 2.60 beta 2, that was not present in v. 2.51. I have a large program that uses ProgExec.Execute (and it works perfectly when built with XDS Nativ v. 2.51), and it apparently crashed on calling this function. Unfortunately, I wasn't able to get more details because the smaller examples that I tried worked OK. I also tried to use the debugger on the larger program, but the crash came rather abruptly with the program only showing some assembly code. The crash itself produced the following data: #RTS: unhandled exception #3: invalid location File errinfo.$$$ created. EAX = 00000000 EBX = 00000000 ECX = 00000000 EDX = 0000001C ESI = 0006F7E4 EDI = 0006F858 EBP = 0006F7D0 ESP = 0006F7CC EIP = 002875D7 STACK: 0006F7CC: 00000000 0006F7DC 0028E36E 00000000 0006F7DC: 0006F888 0028E32F 7A20432F 652E7069 0006F7EC: 20206578 6E203E32 20206C75 5C3A4D22 0006F7FC: 68637241 5C657669 6B636142 5C737075 0006F80C: 706D6574 6E706B62 2220226D 2D202022 0006F81C: 203C2040 5C3A4322 72657355 6F425C73 0006F82C: 616A7473 6F4C5C6E 206C6163 74746553 0006F83C: 73676E69 6D65545C 6D745C70 34393170 C:\Users\Bostjan\Documents>type errinfo.$$$ C:\Users\Bostjan\AppData\Local\Bin\Brst.exe @ #RTS: unhandled exception #3: invalid location 000065D7 00000000 C:\Users\Bostjan\AppData\Local\Bin\XDS26.DLL 0000D369 00000000 C:\Users\Bostjan\AppData\Local\Bin\XDS26.DLL 0000D32A 00000000 C:\Users\Bostjan\AppData\Local\Bin\XDS26.DLL 00004B3F 00000000 C:\Users\Bostjan\AppData\Local\Bin\STD.DLL 00006A83 00000000 C:\Users\Bostjan\AppData\Local\Bin\STD.DLL 0000716A 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 000046E4 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 0000CD5E 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 0000A9B0 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 0000E8B9 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 0000EEDA 00000000 C:\Users\Bostjan\AppData\Local\Bin\Brst.exe 0000B54A 00000000 C:\Users\Bostjan\AppData\Local\Bin\STD.DLL 00001DCD 00000000 C:\Users\Bostjan\AppData\Local\Bin\STD.DLL Regarding more information, as I have already mentioned the procedure ProgExec.Execute works OK on smaller examples; therefore, the problem is pretty tricky from my standpoint. However, if you can give me instructions on how to gather more information, I could do that. Regards, excbv
  8. Hello, Thanks for producing XDS Native v. 2.60 beta 2. I have compiled all my Oberon2 programs with it and they seem to run OK. However, I noticed that some bugs that I have reported in the past did not get fixed. I am including a short description and the relevant source & project files. BUG-1 XDS Native permits comments of type (** that get exported into .odf files. However, some time ago I noticed that occasionally a lot of these comments get copied a second time somewhere in the middle of the file (please run Test.ob2 and Test.prj enclosed in BUG-1.zip to get example). Although one of the forum correspondents pointed out that this bug can be worked around by replacing all procedure declarations of the form PROCEDURE P; with PROCEDURE P(); it would be nice if this were fixed. BUG-2 This bug involves the use of VAR [NIL] parameters. The program file Bug.ob2 as well as the project file Bug.prj which exhibits the bug is enclosed within the attached BUG-2.zip. The bug is also explained in greater detail in the comments within the program text Regards, excbv BUG-1.zip BUG-2.zip
  9. Hello, (compilation error? YES) Thanks for your answer. I suppose you are right. I guess I assumed that the with statement WITH v:T DO allowed v to be a _designator_ rather than _variable_ (as is stated in the report). When one thinks about this limitation, it is probably due to the fact that allowing designators would require too much run-time information (e.g., for every element of an array). Regards, excbv
  10. The following produces a compiler error: <* MAIN+ *> MODULE Test; IMPORT D:=DStrings; TYPE PRec0=POINTER TO Rec0; Rec0=RECORD next:PRec0 END; PArray1=POINTER TO Array1; Array1=ARRAY OF PRec0; PRec1=POINTER TO Rec1; Rec1=RECORD(Rec0) pPR:PArray1 END; PRec2=POINTER TO Rec2; Rec2=RECORD(Rec0) d:D.String END; PROCEDURE DemError(); VAR v:PRec1; BEGIN WITH v.pPR[0] : PRec1 DO (*!!! repl with ln below, and no error*) (*IF v.pPR[0] IS PRec1 THEN*) | v.pPR[0] : PRec2 DO (*!!! repl with ln below, and no error*) (*ELSIF v.pPR[0] IS PRec2 THEN*) ELSE END END DemError; END Test. project file: -gendebug+ -lineno+ -o2extensions+ -m2extensions+ -o2addkwd+ -m2addtypes+ -USEDLL+ -GENDLL- -IMPLIB- -MINCPU=PENTIUM -CPU=PENTIUM -MAKEDEF- -XCOMMENTS- -O2ISOPRAGMA+ -PROCINLINE+ !module Test Can someone verify and comment? Regards, excbv
  11. A Bug in XDS x-86 Native V. 2.51?

    Hello, The situation is somewhat changed. It turns out that this is an XDS debugger bug(?). If the debugger is not used, the program apparently works OK. Regards, excbv
  12. Hello, I think I have discovered a curious bug in the V. 2.51 X-86 Native Oberon compiler, and I wonder whether an Excelsior person could comment it with hopefully a precise description so that one can avoid writing code where this bug can occur. - The bug is illustrated with the files LifoInsertBug.ob2 and LifoInsertBug.prj - the program defines the types Lifo, T1, T2, and T3 where Lifo is the usual Lifo list, T1 and T3 are extensions of the Lifo record, and T2 is an extension of T1 - when the procedure ShowBug is called, the code inside the procedure creates records pt2^ of type T2 and pt3^ of type T3, and then inserts pt3 into the pc component of pt2. Note that pt2 is a Lifo list element while pt2.pc is the head of a Lifo list - The bug consists of the fact that pt3 gets assigned to the pt2.next component instead of the pt2.pc.next component. - The simplest way to see the bug in action is to use the debugger, stop before pt2.pc.Insert is executed, examine the pt2 variable, then execute pt2.pc.Insert, and examine pt2 again. Note: the program is a simplification of a real life program, and perhaps it could be made still simpler; however, I hope that it can be understood without too much difficulty. Regards, excbv LifoInsertBug.prj LifoInsertBug.ob2
  13. Thanks for the additional information. Regards excbv
  14. Just to conclude this topic: I found xrc pretty useless (perhaps it is just a question of a lack of documentation); however, the following can be used to build .res files that can participate in the XDS build system: (a) Download ResEdit ( http://www.resedit.net/ ) to create .rc files, and use ( windres, which is a part of MinGW ( http://www.mingw.org/ ) to create .res files. Regards, excbv
  15. Hello, I used xrc in building the sample Generic, and it worked. However, after copying another .rc file from a tutorial on Win32 (see below), which presumably worked in another context, I got error messages. Is it possible to obtain information on the exact version of rc syntax that xrc works with? Regards, excbv HEADER FILE #define IDI_MYICON 201 #define IDD_ABOUT 301 RC FILE (Generic.rc) /*#include "windows.h"*/ #include "generic.h" IDI_MYICON ICON "GENERIC.ICO" IDD_ABOUT DIALOG DISCARDABLE 0, 0, 239, 66 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU CAPTION "My About Box" FONT 8, "MS Sans Serif" BEGIN DEFPUSHBUTTON "&OK", IDOK,174,18,50,14 PUSHBUTTON "&Cancel",IDCANCEL,174,35,50,14 GROUPBOX "About this program...",IDC_STATIC,7,7,225,52 CTEXT "An example program showing how to use Dialog Boxes \r\n\r\nby the Forger", IDC_STATIC,16,18,144,33 END ERROR MESSAGES Generic.rc(7) : Error -- Number expected Generic.rc(7) : Error -- "BEGIN" expected Generic.rc(7) : Fatal error -- Can't open file | (Invalid argument)