A bug report (with sample code reproducing the behavior) has been
logged. http://freepascal.org/mantis/view.php?id=9089.
Probably should have done that before I emailed the mailing list. Sorry.
-SG
--
Seth Grover
sethdgrover[at]gmail[dot]com
http://grovers.us/seth
Who is John Galt?
___
I've got a shared library (.so) I wrote in C, with initialization and
finalization code declared by using the GCC attributes constructor and
destructor. These init and fini functions simply print out "start" and
"stop" to stdout. The .so exports one function, which prints out
"Hello".
I've got a
Michael Van Canneyt wrote:
> You would have to test the speed of each of them separately to be able
> to say anything definitive. Like it is now, there is no indication
> that it is the float-to-text routine which is to blame.
So use sprintf in C, and the equivalent in fpc; and rerun the test.
Mi
On 6/15/07, memsom <[EMAIL PROTECTED]> wrote:
Apaprently Troll Tech is unhappy as they use Carbon in their Qt port for
Mac OS X...
Everyone is unhappy. Office, Photoshop, Adobe products, Firefox,
wxWidgets, etc, are all based on Carbon.
Actually to me it seams that Apple is the only entusiasti
On 15/06/07, Jonas Maebe <[EMAIL PROTECTED]> wrote:
You don't really have to do that, Apple already did that:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/
And those routines can be used to build an Objective Pascal on top,
to make interfacing easier. And for inspirat
On 15 jun 2007, at 17:18, Henry Vermaak wrote:
On 15/06/07, Henry Vermaak <[EMAIL PROTECTED]> wrote:
On 15/06/07, memsom <[EMAIL PROTECTED]> wrote:
> allegedly still hear-say. Is it even possible/practical to use
Cocoa to
> build a GUI and then use Pascal code to do the logic?
you can try
On 15/06/07, Henry Vermaak <[EMAIL PROTECTED]> wrote:
On 15/06/07, memsom <[EMAIL PROTECTED]> wrote:
> allegedly still hear-say. Is it even possible/practical to use Cocoa to
> build a GUI and then use Pascal code to do the logic?
you can try and build all your functionality into an fpc dynamic
On 15 jun 2007, at 17:09, Henry Vermaak wrote:
you can try and build all your functionality into an fpc dynamic lib
and then link to it out of xcode. we'll need a layer to export the
objective c in a way that we can use it if we're ever going to use
cocoa directly. i think it contains a gazil
On 15 jun 2007, at 17:00, memsom wrote:
Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon
support
under Intel.
It's not just a rumour, and it's not Intel-only. Several parts of
Carbon will not be 64 bit under Mac OS X 10.5. See the "64-bit
Carbon" and "Is Carbon Viable?" t
memsom schrieb:
> Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support
> under Intel. That means that Intel based Carbon based apps will only ever
> be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will
> be gone.
>
> I know that the FPC GUI ports under Mac
On 15/06/07, memsom <[EMAIL PROTECTED]> wrote:
allegedly still hear-say. Is it even possible/practical to use Cocoa to
build a GUI and then use Pascal code to do the logic?
you can try and build all your functionality into an fpc dynamic lib
and then link to it out of xcode. we'll need a layer
Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support
under Intel. That means that Intel based Carbon based apps will only ever
be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will
be gone.
I know that the FPC GUI ports under Mac OS X tend to use Carbon
On Fri, 15 Jun 2007, Jonas Maebe wrote:
>
> On 15 jun 2007, at 11:44, Michael Van Canneyt wrote:
>
> > >I'm sorry, but you are not providing enough information to give any useful
> > >comments. There is no reason why a generic library would error out because
> > >certain code is "too slow". Is
MSEide+MSEgui version 1.2 has been released:
http://www.homepage.bluewin.ch/msegui/
Have a lot of fun!
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 15 jun 2007, at 11:53, Jonas Maebe wrote:
That's quite unlikely to be the case. settextbuf seldomly makes a
difference for me. Especially if you write to standard output,
which will trigger a flush after every writeln anyway.
(unless you redirect the output to a file, at least under *ni
On 15 jun 2007, at 11:44, Michael Van Canneyt wrote:
I'm sorry, but you are not providing enough information to give
any useful
comments. There is no reason why a generic library would error out
because
certain code is "too slow". Is this a real time application on an
embedded
system or s
On Fri, 15 Jun 2007, Jonas Maebe wrote:
>
> On 15 jun 2007, at 11:24, [EMAIL PROTECTED] wrote:
>
> >Hi Jonas,
> >
> > > >I know, programs with a writeln() have lower performance, but I
> > > >think, printf() and writeln() must do the same. This need time to
> > > >calculate.
> > >
On 15 jun 2007, at 11:24, [EMAIL PROTECTED] wrote:
Hi Jonas,
I know, programs with a writeln() have lower performance, but
I think, printf() and writeln() must do the same. This need time
to calculate.
But the difference between printf() and writeln() are so,
that the fpc program
Hi Jonas,
>> I know, programs with a writeln() have lower performance, but I think,
>> printf() and writeln() must do the same. This need time to calculate.
>> But the difference between printf() and writeln() are so, that the fpc
>> program breaks with errors.
> What kind of errors?
I
19 matches
Mail list logo
