ANN: IBX for Lazarus - Call for Testers

[tonyw]

Laguna, if you replace the line with:

Result := semop(FSemaphoreSetID,@sembuf,1);

then it should compile. As the comment suggests, this is a second class solution. It would be interesting to see if it compiled under MAC OS if you add a

{$DEFINE HAS_SEMTIMEDOP}

at the top of IBSQLMonitor.pas

The call to "semtimedop" is a GNU extension and may not be present on the Mac hence this symbol is only defined for platforms that I explicitly knew supported it.

Not compile in Mac Leopard 10.6

Error:
file sv5ipc.inc
row: 350
row code: Result := sem_op(FSemaphoreSetID,@sembuf,1);    {May hang on race condition} 
error message: /Developer/lazarus/components/ibx/runtime/sv5ipc.inc(390,45) Error: Incompatible type for arg no. 2: Got "Pointer", expected "LongInt"

[tonyw]

Thanks for the bug reports received so far. I have uploaded version 0.9.1 to

http://www.mwasoftware.co.uk/ibx

This should fix the issues reported so far.

webpage says 0.9.0 instead of 0.9.1

Fixed - and it was only the title that was wrong. The link was to the correct version.

[Zoran]

Hello, Tony,
The bug with 64-bit Windows reapeared in 0.9.1. Now the assignment

Code: [Select]

cts := PDouble(data)^; cannot be compiled. The compiler says

\ibx\runtime\IBCustomDataSet.pas(2099,37) Error: Incompatible types: got "Double" expected "Int64"

I'll update the bug report.

[tonyw]

I can confirm that both bugs have dissapeared, thanks.

Zoran,

I am not yet sure whether the problem you reported:

ibx\runtime\IBCustomDataSet.pas(2099,50) Error: Incompatible type for arg no. 1: Got "Double", expected "Int64"

has completely gone away. The underlying problem is that the "comp" type only really exists on x86 platforms and is just a redefinition of Int64 on others. A platform independent syntax is needed here. Borrowing from line 638 of dataset.inc (which is doing a similar job), the correct fix at line 2099 of IBCustomDataset.pas is probably:

Qry.Params.AsDateTime :=                         TimeStampToDateTime(MSecsToTimeStamp(trunc(PDouble(data)^)));

where the key addition is the "trunc" call. This certainly works Linux 64-bit - both compiles and correctly updates Timestamp columns. However, I don't have access to a Win64 platform and it would be useful to know if it does work here too.

[tonyw]

Hello, Tony,
The bug with 64-bit Windows reapeared in 0.9.1. Now the assignment

Code: [Select]

cts := PDouble(data)^; cannot be compiled. The compiler says

\ibx\runtime\IBCustomDataSet.pas(2099,37) Error: Incompatible types: got "Double" expected "Int64"

I'll update the bug report.

Looks like we did a simultaneous post  Please check out my proposal

[laguna]

I found this problem in version 0.91.

If you do not have Mac Leopard, can I get with my TeamViewer available to solve the problem.

Thanks

[laguna]

Laguna, if you replace the line with:

Result := semop(FSemaphoreSetID,@sembuf,1);

then it should compile. As the comment suggests, this is a second class solution. It would be interesting to see if it compiled under MAC OS if you add a

{$DEFINE HAS_SEMTIMEDOP}

at the top of IBSQLMonitor.pas

The call to "semtimedop" is a GNU extension and may not be present on the Mac hence this symbol is only defined for platforms that I explicitly knew supported it.

Compile is ok.

Upgrade code with:

{$IFDEF Unix}
    {$IFDEF Darwin}
       // Mac Osx
    {$ELSE}
        //Linux
    {$ENDIF}
{$ENDIF}

[Zoran]

Looks like we did a simultaneous post   Please check out my proposal

Qry.Params.AsDateTime :=                         TimeStampToDateTime(MSecsToTimeStamp(trunc(PDouble(data)^)));

where the key addition is the "trunc" call. This certainly works Linux 64-bit - both compiles and correctly updates Timestamp columns. However, I don't have access to a Win64 platform and it would be useful to know if it does work here too.

Yes, now it compiles on both 32-bit and 64-bit Lazarus, thank you!

[marcov]

Did you plan to support Mac?

I don't have a Mac and never have had one - so don't really have the means to support Mac OSX. The main issue is probably over whether the SV5 IPC component in IBSQLMonitor will work -especially as this has to use libc in order to work around a bug in the RTL. You could always compile it and post the result.

Which bug? What is the mantis # ?

[marcov]

{$IFDEF Unix}
    {$IFDEF Darwin}
       // Mac Osx
    {$ELSE}
        //Linux
    {$ENDIF}
{$ENDIF}

This is wrong. Never assume anything about ELSE. 

The else lumps together beos, freebsd, solaris etc. While the package might not support those yet, lumping them together is very dangerous, since it is easily overlooked when porting. See also http://www.stack.nl/~marcov/porting.pdf

[marcov]

Laguna, if you replace the line with:

Result := semop(FSemaphoreSetID,@sembuf,1);

then it should compile. As the comment suggests, this is a second class solution. It would be interesting to see if it compiled under MAC OS if you add a

{$DEFINE HAS_SEMTIMEDOP}

It won't. That call is linux specific. In my 2.4.4 it is therefore flagged with "platform" for that reason.

The call to "semtimedop" is a GNU extension

It is Linux functionality btw, not GNU functionality.

Sometimes that means though that it will be added by other platforms in the future. It seems that Linux has a tendency to add calls when the standards are not finalized, and most other targets only add them when the standard is finalized.

If you plan to support FreebSD or Mac OS X, make sure you use the types for handles from the relevant FPC units as much as possible. Otherwise you'll get into trouble on 64-bit versions of these systems, since many handletypes are "pointer" on BSD derivates that are "int" on Linux.

[tonyw]

Did you plan to support Mac?

I don't have a Mac and never have had one - so don't really have the means to support Mac OSX. The main issue is probably over whether the SV5 IPC component in IBSQLMonitor will work -especially as this has to use libc in order to work around a bug in the RTL. You could always compile it and post the result.

Which bug? What is the mantis # ?

See bug report #0014075 and this discussion:

http://community.freepascal.org:10000/bboards/message?message_id=414420&forum_id=24083#414429

as a result, my sv5ipc.inc module checks the compiler version and if 2.4.2 or below will use libc for ipc calls. For later versions, it will use the rtl.

[laguna]

This is wrong. Never assume anything about ELSE. 

The else lumps together beos, freebsd, solaris etc. While the package might not support those yet, lumping them together is very dangerous, since it is easily overlooked when porting. See also http://www.stack.nl/~marcov/porting.pdf

Duble IF
{$IFDEF Unix}
    {$IFDEF Darwin}
       // Mac Osx
    {$ENDIF}
    {$IFDEF Linux}
       // Linux
    {$ENDIF}
{$ENDIF}

[marcov]

Which bug? What is the mantis # ?

See bug report #0014075 and this discussion:

http://community.freepascal.org:10000/bboards/message?message_id=414420&forum_id=24083#414429

as a result, my sv5ipc.inc module checks the compiler version and if 2.4.2 or below will use libc for ipc calls. For later versions, it will use the rtl.

As you can see that bug has been set resolved in 2.4.4 by me a few days ago.  Releasing 2.4.4 is hopefully only a matter of days. (it is already uploaded).

But I think it will be a few weeks, maybe even one or two months for a new _official_ Lazarus version (0.9.30.2 I think). But 2.4.4 snapshots will be out very soon, and current 2.4.3 snapshot are virtually the same as 2.4.4.

I assume with libc you mean an own interface to libc, since the unit libc kylix interface is not supported on 64-bit, so that would not fix it.

[tonyw]

I assume with libc you mean an own interface to libc, since the unit libc kylix interface is not supported on 64-bit, so that would not fix it.

You are correct. The libc interface is embeded in the module and should automatically be ignored once 2.4.4 is used to compile ... hopefully it will still work...