On Sun, 22 May 2005, Michalis Kamburelis wrote:
> Hi
>
> Compilation of fpimgcmn.pp is broken starting from revision 33 (some part of
> code that was $ifdefed earlier by VER1_0 stayed), I'm attaching a trivial
> patch.
You must have missed my fix then, because it is already fixed since revisio
On Sun, 22 May 2005, Michalis Kamburelis wrote:
> Hi
>
> I'm attaching a trivial patch for OpenGL bindings that
>
> 1. Fixes declarations of glGetMapiv, glGetMaterialiv and glLightiv to take
> pointer as the last parameter.
>
> 2. Changes glGetString, gluErrorString and gluGetString to return
Michael Van Canneyt wrote:
On Sun, 22 May 2005, Michalis Kamburelis wrote:
Hi
Compilation of fpimgcmn.pp is broken starting from revision 33 (some part of
code that was $ifdefed earlier by VER1_0 stayed), I'm attaching a trivial
patch.
You must have missed my fix then, because it is alrea
> You can also download fpc.zip from ftp.freepascal.org\fpc\snapshot\v20 or
> v21\source- that way you get everything (from the prev. night) in one
> go...John
Well, now it is worked. But where is any 'whatsnew' files or another log of
changes?
___
f
What's about Go32v2 or some other DOS port?
Will it supported in 2.0.x branch?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
At 11:46 22-5-2005, you wrote:
What's about Go32v2 or some other DOS port?
Will it supported in 2.0.x branch?
There is no maintainer for go32v2. Unless there is an user that steps
forward to be the maintainer for go32v2 there will be no DOS release anymore.
Peter
_
Date sent: Sun, 22 May 2005 12:03:37 +0200
To: Ivan Shikhalev <[EMAIL PROTECTED]>,
"FPC developers' list"
From: Peter Vreman <[EMAIL PROTECTED]>
Subject:Re: [fpc-devel] DOS Platforms
Copies to: Send reply to:
Date sent: Sun, 22 May 2005 12:03:37 +0200
To: Ivan Shikhalev <[EMAIL PROTECTED]>,
"FPC developers' list"
From: Peter Vreman <[EMAIL PROTECTED]>
Subject: Re: [fpc-devel] DOS Platforms
> At 11:46 22-5-2005, you wrote:
> >What's about Go32v2 or some other DOS port?
> >Will it supported in
Hi,
In order to create the rtl docs for sourceforge (
http://lazarus-ccr.sourceforge.net/docs/rtl/ ) I needed to pass the
--footer=xxx to fpdoc. Because I wanted to use make, for creating these
docs, I modified the Makefile (see attached diff). I also needed a
content file as input for generat
Hi everybody!
Why in fact were MaxAvail,MemAvail,HeapSize removed from the RTL? The
explanation in install/doc/whatsnew.txt is puzzling me a bit:
- Removed MaxAvail, MemAvail, HeapSize due to their unreliability
(bogus/misleading return values) in multitasking environment with
swapping
Is
Konstantin Münning wrote:
> Hi everybody!
>
> Why in fact were MaxAvail,MemAvail,HeapSize removed from the RTL? The
> explanation in install/doc/whatsnew.txt is puzzling me a bit:
>
> - Removed MaxAvail, MemAvail, HeapSize due to their unreliability
> (bogus/misleading return values) in mu
Florian Klaempfl wrote:
> Konstantin Münning wrote:
>
>
>>Hi everybody!
>>
>>Why in fact were MaxAvail,MemAvail,HeapSize removed from the RTL? The
>>explanation in install/doc/whatsnew.txt is puzzling me a bit:
>>
>> - Removed MaxAvail, MemAvail, HeapSize due to their unreliability
>>(bogus/
Konstantin Münning wrote:
> Florian Klaempfl wrote:
>
>>Konstantin Münning wrote:
>>
>>
>>
>>>Hi everybody!
>>>
>>>Why in fact were MaxAvail,MemAvail,HeapSize removed from the RTL? The
>>>explanation in install/doc/whatsnew.txt is puzzling me a bit:
>>>
>>> - Removed MaxAvail, MemAvail, HeapSize
On 22 May 2005, at 20:07, Konstantin Münning wrote:
When you skip the check and allocate always then the program will
crash anyway when there is not enough memory.
No. Either you catch exceptions resulting from a lack of memory and
recover, and then you have the same checking as before, ex
Bram Kuijvenhoven wrote:
>
> The storage specifiers are not explained in the FPC reference manual as
> far as I know, though they are in the syntaxis diagram of course.
Michael?
>
> And somehow FPC allows default values for singles.
... because they have a size of 4 which is required for a def
Jonas Maebe wrote:
>
> On 22 May 2005, at 20:07, Konstantin Münning wrote:
>
>> When you skip the check and allocate always then the program will
>> crash anyway when there is not enough memory.
>
> No. Either you catch exceptions resulting from a lack of memory and
> recover, and then you hav
On 23 May 2005, at 00:56, Konstantin Münning wrote:
No. Either you catch exceptions resulting from a lack of memory and
recover, and then you have the same checking as before, except
that the
check happens atomically (by the OS: you ask for more memory and if
there is no more memory, you g
Jonas Maebe wrote:
>
> On 23 May 2005, at 00:56, Konstantin Münning wrote:
>
>>> No. Either you catch exceptions resulting from a lack of memory and
>>> recover, and then you have the same checking as before, except that
>>> the
>>> check happens atomically (by the OS: you ask for more memory a
Konstantin Münning wrote:
>>And in all cases, the program will still crash occasionally because it
>>runs out of memory in certain cases, because the check and the
>>allocation do not happen atomically. You can't put something into the
>>standard Run Time Library which works "most of the time, e
19 matches
Mail list logo