Hello,
Actually it uses both synapse (under unix) and winsock (under Windows).
What should one put in the parameter AHTTPSend: THTTPSend ? Where is
this type declared?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists
OK, it seems that I should take the hardcoder approach :)
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Using-LLVM-with-FPC-tp3199368p3200843.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
_
Local IP without winsock, synapse, indy or lnet:
http://code.google.com/p/lazsolutions/source/browse/trunk/Core/LSHTTPSend.pas#127
2010/10/5 Felipe Monteiro de Carvalho
> hello,
>
> I am searching for a way to get the local IP. I already found examples
> with winsock, synapse and indy. Does anyo
hello,
I am searching for a way to get the local IP. I already found examples
with winsock, synapse and indy. Does anyone know how to do that with
lNet?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
On 05.10.2010 20:55, Bernd Kreuss wrote:
> I see this error message now exactly once, immediately *after* the DLL
> has been unloaded by the host application.
Correction: I see it after my log output within my finalization section,
it might still be in the final stages of DLL_PROCESS_DETACH.
Wher
On 04.10.2010 19:23, Bernd Kreuss wrote:
> C005 at 7C928FEA in C:\WINDOWS\system32\ntdll.dll
>
> 7C928FEA seems to be RtlpWaitForCriticalSection() somewhere deep inside
> the windows kernel.
I see this error message now exactly once, immediately *after* the DLL
has been unloaded by the host
Well, I need to create BMP files with unique name, to be sent to lpr, then
printed.
Instead of using GetTempFileName, I'll use a GUID, with CreateGUID, and
GUIDToString.
Leonardo M. Ramé
http://leonardorame.blogspot.com
--- On Tue, 10/5/10, ik wrote:
From: ik
Subject: Re: [fpc-pascal] GetT
On Tue, Oct 5, 2010 at 17:30, Sven Barth wrote:
> Am 05.10.2010 17:20, schrieb Leonardo M. Ramé:
>
> Hi, if I run this program from command line in Linux, I allways get the
>> same result, "/tmp/TMP0.tmp". Shouldn't it return a different file name
>> each time it's executed?.
>>
>> How can I
On 05 Oct 2010, at 17:38, Michael Van Canneyt wrote:
> On Tue, 5 Oct 2010, Leonardo M. Ramé wrote:
>
>> Hi, if I run this program from command line in Linux, I allways get the same
>> result, "/tmp/TMP0.tmp". Shouldn't it return a different file name each
>> time it's executed?.
>> How ca
On Tue, 5 Oct 2010, Leonardo M. Ramé wrote:
Hi, if I run this program from command line in Linux, I allways get the same result, "/tmp/TMP0.tmp". Shouldn't it return a different file name each time it's executed?.
How can I get different file names?
By actually creating the file. GetTe
Am 05.10.2010 17:20, schrieb Leonardo M. Ramé:
Hi, if I run this program from command line in Linux, I allways get the same result,
"/tmp/TMP0.tmp". Shouldn't it return a different file name each time it's
executed?.
How can I get different file names?
program tempfilename;
uses
sysuti
Hi, if I run this program from command line in Linux, I allways get the same
result, "/tmp/TMP0.tmp". Shouldn't it return a different file name each
time it's executed?.
How can I get different file names?
program tempfilename;
uses
sysutils;
begin
writeln(GetTempFileName);
end.
Leon
Am 05.10.2010 16:58, schrieb Jonas Maebe:
On 05 Oct 2010, at 16:52, Sven Barth wrote:
But do you already generate LLVM code?
No, only translating FPC types into LLVM type definitions has been
implemented (but that's also the part that occasionally crashes since my
last merge from trunk).
O
On 05 Oct 2010, at 16:52, Sven Barth wrote:
But do you already generate LLVM code?
No, only translating FPC types into LLVM type definitions has been
implemented (but that's also the part that occasionally crashes since
my last merge from trunk).
Jonas
_
Am 05.10.2010 16:48, schrieb Jonas Maebe:
On 05 Oct 2010, at 16:41, Sven Barth wrote:
Am 05.10.2010 16:06, schrieb leledumbo:
I believe that producing LLVM assembly is the best solution in the long
run.
That's what I'm going to do if no one else ever started it (I'll try
to make
it as mod
On 05 Oct 2010, at 16:41, Sven Barth wrote:
Am 05.10.2010 16:06, schrieb leledumbo:
I believe that producing LLVM assembly is the best solution in the
long
run.
That's what I'm going to do if no one else ever started it (I'll
try to make
it as modular as possible so it can be used for
Am 05.10.2010 16:06, schrieb leledumbo:
I believe that producing LLVM assembly is the best solution in the long
run.
That's what I'm going to do if no one else ever started it (I'll try to make
it as modular as possible so it can be used for other projects)
I don't know how far Jonas is wit
On Tue, Oct 5, 2010 at 3:57 PM, Jonas Maebe wrote:
>
> On 05 Oct 2010, at 15:40, Matthias K. wrote:
>
>> there is one improvement to this.
>> The first pass for the new compiler doesn't need "make all" which
>> compiles all packages too. This results in
>> duplicate package compilation on changes
> I believe that producing LLVM assembly is the best solution in the long
run.
That's what I'm going to do if no one else ever started it (I'll try to make
it as modular as possible so it can be used for other projects)
--
View this message in context:
http://free-pascal-general.1045716.n5.nabb
On 05 Oct 2010, at 15:40, Matthias K. wrote:
there is one improvement to this.
The first pass for the new compiler doesn't need "make all" which
compiles all packages too. This results in
duplicate package compilation on changes and packages take most time.
The following lines are part of an ol
leledumbo wrote:
Since no one seems to be interested on this in Lazarus forum, I duplicate it
here:
I'm not talking about generating LLVM IR code as FPC backend, instead I'd
like to use it as normal library. Though it's written in C++, it has C
interface, so I think it's possible. It's just, the
Hi,
there is one improvement to this.
The first pass for the new compiler doesn't need "make all" which
compiles all packages too. This results in
duplicate package compilation on changes and packages take most time.
The following lines are part of an old fpc 2.4 gentoo ebuild I use,
which compile
On 04.10.2010 19:23, Bernd Kreuss wrote:
> Hi,
>
> has anybody ever had the problem of TProcess.Free causing
> three exceptions in in ntdll.dll?
>
> C005 at 7C928FEA in C:\WINDOWS\system32\ntdll.dll
Just for the record: It was not TProcess and also not the streams, at
least not directly: Aft
On Tue, 5 Oct 2010, leledumbo wrote:
Since no one seems to be interested on this in Lazarus forum, I duplicate it
here:
I'm not talking about generating LLVM IR code as FPC backend, instead I'd
like to use it as normal library. Though it's written in C++, it has C
interface, so I think it's
Since no one seems to be interested on this in Lazarus forum, I duplicate it
here:
I'm not talking about generating LLVM IR code as FPC backend, instead I'd
like to use it as normal library. Though it's written in C++, it has C
interface, so I think it's possible. It's just, the header has a lot
Op 2010-10-05 11:17, Michael Van Canneyt het geskryf:
>
> so your statement should have been 'debug and line info information is
> incomplete', instead of 'missing'
It was for "dramatic effect" :) You are right, my initial statement
was a bit wrong - I didn't have the code or output in
On Tue, 5 Oct 2010, Graeme Geldenhuys wrote:
Hi Jonas
On 2 October 2010 16:51, Jonas Maebe wrote:
Debug and Line Info information is missing in FPC under 64-bit Linux,
even with -gl parameter enabled.
That's incorrect.
See the bug report for details. Not all the information available
un
Hi Jonas
On 2 October 2010 16:51, Jonas Maebe wrote:
>
> Debug and Line Info information is missing in FPC under 64-bit Linux,
> even with -gl parameter enabled.
>
> That's incorrect.
See the bug report for details. Not all the information available
under 32-bit FPC is available under 64-bit FPC
28 matches
Mail list logo
