RE: [fpc-pascal] PowerPC: zipper streaming error
http://bugs.freepascal.org Jonas Thanks Jonas, I didn't notice the tabs above until yesterday, so I thought it was a Lazarus only bugtracker. Best regards, Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PowerPC: zipper streaming error
Hi all, Is anyone working on the unit zipper? I came across a problem when using the zip objects on PowerPC - they don't like files zipped on i386, and i386 don't like files zipped with PowerPC, but the PowerPC can zip its own files and read those again. I guess the zipper unit is lacking a check for big endian processor. Where can I report a bug for FPC? Btw, I'm using FPC 2.2.2. Thanks, and best regards Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Chinese/Japanese codepages to UTF8
Hi, The unit LConvEncoding has some functions to convert between codepages and UTF8, like CP1252ToUTF8 and UTF8ToCP1252, but codepages for Chinese or Japanese isn't supported. What do others use to convert text with these codepages to UTF8? Best regards, Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Carbon: i386 and PPC API differences
-Original Message-
From: [EMAIL PROTECTED] [mailto:fpc-pascal-
[EMAIL PROTECTED] On Behalf Of Jonas Maebe
Sent: 29. september 2008 16:26
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Carbon: i386 and PPC API differences
const inDescription: ComponentDescription is wrong, because FPC does
not guarantee that this will be passed by reference (especially in
case of C imports, because in C const also means pass by value).
Either use a pointer type, or use var instead. There is no constvar
or similar specifier.
Also add {$packrecords C} to your source to ensure that the records
are properly packed, and translate unsigned long using the culong
type from the ctypes unit rather than using uint32 (unsigned long is
not the same as uint32 on all platforms, e.g. it's different on 64 bit
Mac OS X).
Thanks for the input, Jonas, and I went through all the declarations and
found that AUNode from the AUGraph.h was wrongly specified as Integer, and
should be SInt32 as used in the C sample.
That did a huge difference, and the sample is now works.
Thanks again,
Normann
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Carbon: i386 vs PPC API's
Hi all, Is there any precautions one should make when sharing FPC codes between i386 and PowerPC? I've few calls to AudioToolbox API's which works fine under i386, but crashes in PPC - the exact API call is AudioConverterNew, and the records passed to the API looks good, and is also returned by AudioToolbox itself. It doesn't return an error code - just crashes with EXC_ARITHMETIC error in a procedure called SincKernel::CalculateFilterCoefficients. Any hints will be much appreciated. Best regards, Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Carbon: i386 vs PPC API's
-Original Message- From: [EMAIL PROTECTED] [mailto:fpc-pascal- [EMAIL PROTECTED] On Behalf Of Jonas Maebe Sent: 29. september 2008 10:46 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Carbon: i386 vs PPC API's On 29 Sep 2008, at 09:27, EarMaster - Bent Olsen wrote: Is there any precautions one should make when sharing FPC codes between i386 and PowerPC? I've few calls to AudioToolbox API's which works fine under i386, but crashes in PPC - the exact API call is AudioConverterNew, and the records passed to the API looks good, and is also returned by AudioToolbox itself. It doesn't return an error code - just crashes with EXC_ARITHMETIC error in a procedure called SincKernel::CalculateFilterCoefficients. First of all: when starting a new thread, please write a new message to the mailing list rather than replying to an existing one and changing the subject. Such replies mess up automatic threading both in the web archive and in various mail clients. Noted! Sorry, I wasn't aware of this. That said, the crash you get is caused by a floating point arithmetic error (one of many) in Apple's system frameworks (which also exist in several OpenGL implementations for Windows, in GTK2 etc). These do not cause any problems in most C programs, because in C programs by default all floating point exceptions are masked (and hence no one ever notices such errors). You can mask them in FPC as well by adding the math unit to your uses clause and performing the following call at the start of your program: Thanks! I did this, and it works like a charm ;-) SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]) Note that this will mask all floating point exceptions everywhere, i.e., also in your Pascal code. The only alternative is to save, change and restore the floating point exception mask around every call to a system routine directly or indirectly related to audio or graphics. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Carbon: i386 and PPC API differences
Hi all,
I use Xcode to find samples of codes and try to make it work on FPC/Lazarus.
One example opens an AUGraph and send MIDI messages - a small sample. It
calls AUGraphNewNode which returns a node from 1 to n, and it works
perfectly in FPC on Carbon/i386, and of course for Xcode on the same
machine.
The same code works fine in Xcode on Carbon/PowerPC, but does not return any
nodes in FPC on Carbon/PowerPC.
I've just started on working with PowerPC, so I thought I'm obviously is
missing out something vital, perhaps with the record definition used by
AUGraphNewNode.
I've learned about SetExceptionMask and floating points today when using
PowerPC, so maybe I need to handle the records differently also? I know
about little and big endian, but this shouldn't be necessary?
Or perhaps I should define the external call differently on PowerPC?
I've include code snips below, and any hints will be much appreciated.
TIA, and best regards,
Normann
// Code snips
// Pascal
type
ComponentDescription = record
componentType: OSType;
componentSubType: OSType;
componentManufacturer: OSType;
componentFlags: UInt32;
componentFlagMask: UInt32;
end;
function AUGraphNewNode(inGraph: AUGraph; const inDescription:
ComponentDescription;
inClassDataSize: LongWord; inClassData : Pointer; var outNode : AUNode):
OSStatus;
external name '_AUGraphNewNode'; mwpascal; //
AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;
var
_Graph: AUGraph;
_CD: ComponentDescription;
_Node: AUNode;
begin
NewAUGraph(_Graph);
_CD.componentType := kAudioUnitComponentType;
_CD.componentSubType := kAudioUnitSubType_MusicDevice;
_CD.componentManufacturer := kAudioUnitID_DLSSynth;
_CD.componentFlags := 0;
_CD.componentFlagsMask := 0;
AUGraphNewNode(_Graph, _CD, 0, nil, _Node); // Node returns zero, but no
OSError
// C++
struct ComponentDescription {
OSType componentType; /* A unique 4-byte code
indentifying the command set */
OSType componentSubType; /* Particular flavor of this
instance */
OSType componentManufacturer; /* Vendor indentification */
unsigned long componentFlags; /* 8 each for
Component,Type,SubType,Manuf/revision */
unsigned long componentFlagsMask; /* Mask for specifying which
flags to consider in search, zero during registration */
};
extern OSStatus AUGraphNewNode(AUGraph inGraph, const ComponentDescription
*inDescription,
UInt32 inClassDataSize, const void *inClassData, AUNode *outNode)
AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;
{
AUGraph _Graph;
ComponentDescription _CD;
AUNode _Node;
NewAUGraph(@_Graph);
_CD.componentType = kAudioUnitComponentType;
_CD.componentSubType = kAudioUnitSubType_MusicDevice;
_CD.componentManufacturer = kAudioUnitID_DLSSynth;
_CD.componentFlags = 0;
_CD.componentFlagsMask = 0;
AUGraphNewNode(_Graph, _CD, 0, NULL, _Node); /* Node returns 1
}
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Mac OSX API call
Hi all, I've been playing with audio unit framework on Mac OSX 10.4, and trying to make a sample from Xcode (PlayAudioFileLite) running on Lazarus 0.9.25/rev 15279 with FPC 2.2.0. I'm nearly done, and I'm only getting an error -50 (error in user parameter list) on the last API call from the callback process. I don't have the sufficient experience with C/C++ vs. Pascal calling conventions, but I've been lucky with other API calls, except for the last one. I'm hoping one of you can help translate this call, which btw the way works fine in Xcode - the sample is playing an audio file. The API call is in the AudioFile.h: Extern OSStatus AudioFileReadPackets ( AudioFileID inAudioFile, Boolean inUseCache, UInt32*outNumBytes, AudioStreamPacketDescription *outPacketDescriptions, SInt64inStartingPacket, UInt32*ioNumPacket, void *outBuffer) AVAILABLE_MAC_OS_X_VERSION_10_2_AND_LATER; I've translated this to: function AudioFileReadPacket(inAudioFile: AudioFileID; inUseCache: Boolean; var outNumBytes: UInt32; var outPacketDescriptions: AudioStreamPacketDescription; //also tried Pointer inStartingPacket: SInt64; var ioNumPacket: UInt32; var outBuffer: Pointer): OSStatus; external name '_AudioFileReadPackets'; mwpascal; I've tried to change the types of parameters in various combination, but yet it didn't give me a clue on which of the parameters is in a wrong type. I'm sorry if this off topic, but I'll be happy if one of you can tell me what I'm translating wrong. Best regards, Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Mac OSX API call
-Original Message- From: [EMAIL PROTECTED] [mailto:fpc-pascal- [EMAIL PROTECTED] On Behalf Of Vincent Snijders Sent: 29. august 2008 12:27 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Mac OSX API call I think it should be (no var for the pointer): I tried, and same result. Could a Mac OSX API call return -50 even though the types are correct, but the contents of them are not what it expected? I would assume -50 is only after a check for types in the parameter list, and check is done before even calling the API. Thanks, Normann function AudioFileReadPacket(inAudioFile: AudioFileID; inUseCache: Boolean; var outNumBytes: UInt32; var outPacketDescriptions: AudioStreamPacketDescription; //also tried Pointer inStartingPacket: SInt64; var ioNumPacket: UInt32; outBuffer: Pointer): OSStatus; external name '_AudioFileReadPackets'; mwpascal; Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Mac OSX API call
-Original Message- From: [EMAIL PROTECTED] [mailto:fpc-pascal- [EMAIL PROTECTED] On Behalf Of Marco van de Voort Sent: 29. august 2008 12:39 To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Mac OSX API call In our previous episode, Vincent Snijders said: I think it should be (no var for the pointer): ... and if ObjC's concept of a boolean is the same as FPC's. Maybe longbool ? I did thought the boolean type could have a different size, and I did make a sizeof in Xcode and in FPC, and the both returned a size of 1. This don't mean, there's an alignment issue? Thanks, Normann ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
