Error with IStream.Seek() - ole

I have a very old piece of code to handle Excel files in Delphi 5, which I adapted to work with Delphi 2005, which I used professionally until 2010. Since then, there was no reasonable free version of Delphi. Therefore, it is only now that using Delphi 10.2.3 Tokyo I would like to adapt it once again.
A problem that I was not able to solve is related to the use of OleStream.Seek(...) in the function given below, where I get a fatal error with all expressions in OleCheck(...).
Also, I didn't find any hint on a similar problem searching for the function OleStream.Seek(...) on the Internet.
The code is the following
function Streamseek(offset : longint; origin: word):string;
var
Pos : longInt ; // Pos: largeint;
begin
if FBIFFVersion > biff4 then begin
case Origin of
soFromBeginning:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_SET,Pos)); // ENUM: set =0
soFromCurrent:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_CUR,Pos)); /// 1 cur
soFromEnd:
OleCheck(OStream.Seek(Offset,STREAM_SEEK_END,Pos)); // 2 end
end;
Of course, it is just one function in a much bigger program, which is not relevant here.
My problem is: I searched for
OStream.Seek(Offset,STREAM_SEEK_SET,Pos) on the Internet, but I could only find OleStream.seek(offset : longint; origin: word):string; except for one webpage, but there the same types were used.
Working with IStream in Delphi
So, I wonder what parameter types need to be used.
In the German version of Delphi 10.2.3, I get the error:
[dcc32 Fehler] line(878): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
In English:
The types of the real and the formal var parameters must be the same.
It is clear that largeint is not a modern parameter type, and I only see the possibility that, instead of Integer, LongInt, Int64 or else is needed since the number of parameters should be OK.
LongInt instead of Integer for offset does not work, Longint instead of LargeInt does not work for pos.
Has anyone an idea what might be the reason for the error? What are the required types of this function in Delphi 10.2.3?

Related

DateTimeParseException while trying to perform ZonedDateTime.parse

Using Java 8u222, I've been trying a silly operation and it incurs in an error that I'm not being able to fully understand. The line code:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Asia/Qostanay]");
The error:
java.time.format.DateTimeParseException: Text '2011-07-03T02:20:46+06:00[Asia/Qostanay]' could not be parsed, unparsed text found at index 25
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1952)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:597)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:582)
Using the same date (although the timezone could be incorrect, the intention is just testing here), I changed the square bracket's value and it works, I mean:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Europe/Busingen]);
It works as expected, as well as other values such:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Asia/Ulan_Bator]")
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[SystemV/CST6CDT]")
I found some similar questions such as the one below, but not precisely the same usage that I'm trying / facing.
Error java.time.format.DateTimeParseException: could not be parsed, unparsed text found at index 10
Does someone have an understanding of Java Date API to help me out to grasp what I'm doing wrong here?
Thanks.
Asia/Qostanay is a zone which doesn't exist in the JDK8's list of timezones. It was added later.
If you don't care about the location of the timezone then just splice the [...] part of the string off the end before parsing. Knowing that the time is +06:00 is going to sufficient for almost all purposes.
Alternatively, upgrade to a more recent version of Java.

Sage TypeError positive characteristics not allowed in symbolic computations

I am new to sage and have got a code (link to code) which should run.
I am still getting an error message in the decoding part. The error trace looks like this:
in decode(y)
--> sigma[i+1+1] = sigma[i+1]*(z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1]*(z);
in sage.structure.element.Element.__mul__
if BOTH_ARE_ELEMNT(cl):
--> return coercion_model.bin_op(left, right, mul)
in sage.structure.coerce.CoercionModel_cache_maps.bin_op
--> action = self.get_action(xp,yp,op,x,y)
...... some more traces (don't actually know if they are important)
TypeError: positive characteristics not allowed in symbolic computations
Does anybody know if there is something wrong in this code snipped? Due to previous errors, I changed the following to get to where I am at the moment:
.coeffs() changed to .coefficients(sparse=False) due to a warning message.
in the code line sigma[i+1+1] = sigma[i+1](z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1](z); where the error occurs, i needed to insert * eg. sigma[i+1]*(z)
I would be grateful for any guess what could be wrong!
Your issue is that you are multiplying things not of characteristic zero (like elements related to Phi.<x> = GF(2^m)) with elements of symbolic computation like z which you have explicitly defined as a symbolic variable
Phi.<x> = GF(2^m)
PR = PolynomialRing(Phi,'z')
z = var('z')
Basically, the z you get from PR is not the same one as from var('z'). I recommend naming it something else. You should be able to access this with PR.gen() or maybe PR(z).
I'd be able to be more detailed, but I encourage you next time to paste a fully (non-)working example; trying to slog through a big worksheet is not the easiest thing to track all this down. Finally, good luck, hope Sage ends up being useful for you!

OpenCL compiler white-space problems

I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..

running COBOL program error - mfcobol, CALL ... RETURNING

i got a problem with simple cobol call - returning test program.
I am using micro focus cobol.
here are my 2 codes.
***************** CALLING PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. callreturning.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 VA PIC S9(8) USAGE DISPLAY.
01 VB PIC S9(8) USAGE DISPLAY.
01 VC PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION.
MOVE 1 TO VA.
MOVE 2 TO VB.
move 3 to VC.
CALL "add_two" USING VA VB returning VC.
* DISPLAY VA VB VC.
EXIT PROGRAM.
END PROGRAM callreturning.
*********CALLED PROGRAM
IDENTIFICATION DIVISION.
PROGRAM-ID. add_two.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 PARM_A PIC S9(8) USAGE DISPLAY.
01 PARM_B PIC S9(8) USAGE DISPLAY.
01 PARM_C PIC 9(4) USAGE DISPLAY value 0.
PROCEDURE DIVISION USING PARM_A PARM_B returning PARM_C.
move 3 to PARM_C.
* ADD PARM_A TO PARM_B GIVING PARM_C.
goback.
END PROGRAM add_two.
CALLING program simply calls the second program with using returing value.
But when i compile both program and run, error happens.
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)
Did i make a wrong code? or other problem? please help me :)
I am testing 'RETURNING' phrase
Your program compiles and works just fine if you get rid of the returning statement.
Background
01 levels defined in the linkage section are more like pointers in a C program. For normal parameters they are set by the calling program. But returning parameters will be unassigned.
The error is probably caused by trying to use an unallocated pointer.
Solution
Do not use returning as it is for working with languages like java.
Allocate storage to the return-value before using it.
See:
Microfocus Manual, Look at the returning example
IBM Manual Look at the Returning Phrase Section
Finally, returning is for working with java. Anything "type" defined on returning should be java compatible (i.e. binary-long and not 9(4)). I strongly suggest not using Returning in Cobol unless you are calling other languages.
Old Question, so i try a short Answer:
First, there is nothing wrong with using returning in MF-COBOL.
So, this is native COBOL (NetExpress as IDE, i assume). To correct ist just change the second Program:
Move PARM_C from the linkage to the working-storage section
The Procedure Division doesn't get the returning Phrase in its opening declaration. Move it instead to the goback phrase:
PROCEDURE DIVISION USING PARM_A PARM_B.
*>...
goback returning PARM_C.

ActionScript 3.0 integer overflow?

I have an old AIR file that works fine. I tried to recompile it but the resulting airfile is buggy.
After digging in the code, i found that at some place strings are parsed to ints, and that the resulting int does not correspond to the string.
So i made a simple Actionscript file and executed the code:
var test:int = parseInt("3710835714");
and the variable will have the value
-584131582
So this looks like an overflow. But i'm surprised that the air file i have (which i didn't compile myself) runs just fine. So I wonder - does the internal representation of int somehow depend on what version of the Flex or AIR sdk libraries one is using for compiling?
//edit: it seems it boils down to this test:
var obj:Object = new Object();
obj.val="3710835714";
var test1:Boolean = (obj.val==-584131582);
var test2:Boolean = (int(obj.val)==-584131582);
this evaluates for me to
test1=false;
test2=true;
however - the this old AIR file seems to evaluate both cases to true. How can that be?
It is happening due to Give number exceeds ActionsScript Int limit
The int data type is stored internally as a 32-bit integer and comprises the set of integers from -2,147,483,648 (-231) to 2,147,483,647 (231 - 1),
and number 3,710,835,714 exceeds it by 1563352067
but your parse result shows compiler is considering it as Uint, whose Max limit is 4,294,967,295 i.e
-584131581 = 3,710,835,714 - 4,294,967,295
You should use Uint or Number for big whole-numbers/integers
this blog may helps you
ActionScript 3 Number data type problem with long integer values
Hopes that works

Resources