J. Gareth Moreton via fpc-devel schrieb am
Sa., 25. Mai 2024, 10:49:
> Thought I'd give a small update.
>
> I was distracted over the past month with work, the arm-linux blocking
> bug and a couple of merge requests which were much easier to develop!
> I'm now having a solid bash at getting Windo
J. Gareth Moreton via fpc-devel schrieb am
Sa., 25. Mai 2024, 22:18:
> Indeed - I'm not giving up! I installed Clang via LLVM. Which of the EXE
> files is actually the assembler? It's not entirely clear (no "clang-as",
> for example). (Although I trust it works!)
>
Simply check what FPC call
Virgo Pärna via fpc-devel schrieb am Fr.,
28. Juni 2024, 08:41:
> On Fri, 21 Jun 2024 20:03:56 +0200, Marco van de Voort via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> > Probably terminate with a heap out of memory error.
>
> Also depends of platform...
>
> program tests;
> var
> s,
Martin Frb via fpc-devel schrieb am Mi.,
10. Juli 2024, 19:21:
> Any hints on using unit SoftFpu? (or any alternative)
>
> I have an 80 bit float (from an external source) that needs to be
> converted to double.
>
> But if I do
>uses softfpu, ufloatx80
>
> then I get
>Error: Multiple defi
Am 14.03.2017 14:33 schrieb "Sven Barth" :
>
> Am 14.03.2017 13:30 schrieb "LacaK" :
> >
> > Hi,
> >
> > I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
Intel IPP package (they distribute ".lib" and also ".dll" for Windows and
".a" for Linux)
> >
> > Can I link in FPC (on Windows
Am 14.03.2017 13:30 schrieb "LacaK" :
>
> Hi,
>
> I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
>
> Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possibl
Am 15.03.2017 13:56 schrieb "LacaK" :
>
> Dňa 15.3.2017 o 12:54 Yury Sidorov napísal(a):
>
>> On 3/14/2017 4:47 PM, Ladislav Karrach wrote:
>>>
>>>
Did you try this:
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: I
Am 15.03.2017 17:06 schrieb "LacaK" :
> But this can be because probably "libippcore.a" is for Linux 64 ...
Yes, the Windows one only supports PE, not ELF.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.o
Am 17.03.2017 08:08 schrieb "Bishop via fpc-devel" <
fpc-devel@lists.freepascal.org>:
>
> I have some questions about compiler work on x86_64-win64.
>
> 1) EXE-file contained .CRT section. As i understand it contained one
pointer to _FPC_Tls_Callback functions from RTL. Is it used only for this?
C
Am 17.03.2017 22:16 schrieb "Bishop" :
>
> 03/17/17 11:56:47, Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
>
> >> 1) EXE-file contained .CRT section. As i understand it contained one
pointer to _FPC_Tls_Callback functions from RTL. Is it used only
Am 18.03.2017 23:11 schrieb "Bishop" :
>
> 03/18/17 00:51:05, Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
>
>
> > Bo, the main sense of this is to detect when a new thread is started
and more importantly terminated cause only with this we can fre
Am 19.03.2017 04:53 schrieb "silvioprog" :
>
> On Wed, Mar 15, 2017 at 4:38 AM, LacaK wrote:
>>>
>>> I forgot a question, could you send your ippi .a files for us? If so, I
can try a test here. :-)
>>
>>
>> Yes of course: I have uploaded them here
http://uschovna.zoznam.sk/download?code=1342688547
Am 01.04.2017 10:53 schrieb "C Western" :
> Is this a sensible change?
I'd say so. If no other core dev complains during the day I'll commit it
tomorrow.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
Am 04.04.2017 08:52 schrieb "Martok" :
>
> >> Does it is possible that the LineInfo trace (-gl option) are broken
(no output)
> >> in 3.0.2 version on Linux (at least)?
> >
> > Hm. Indeed. I can reproduce the issue :/
> AFAIR lineinfo.pp only works with Stabs? Didn't the default change to
Dwarf?
A
Am 04.04.2017 10:42 schrieb "Tomas Hajny" :
>
> On Tue, April 4, 2017 10:21, Michael Van Canneyt wrote:
> > On Tue, 4 Apr 2017, Sven Barth via fpc-devel wrote:
> >> Am 04.04.2017 08:52 schrieb "Martok" :
> >>>
> >>>>> Does
Am 13.04.2017 08:44 schrieb "Bishop via fpc-devel" <
fpc-devel@lists.freepascal.org>:
> At first I would like to designate a circle of tasks which in principle
can effectively decide by means of system of dynamic packets. Lets remember
for what DLL`s and SO`s was be created. It was for memory savin
Am 13.04.2017 12:03 schrieb "Mattias Gaertner" :
>
> On Thu, 13 Apr 2017 11:28:02 +0200
> Sven Barth via fpc-devel wrote:
>
> >[...]
> > The intended purpose of dynamic packages (and libraries in general) is
not
> > to save memory (in fact a binary plus pa
them (e.g. inside the same unit) it already tries to.
And for global variables you can use {$importdata off}.
Please not that our threadvars are *not* allocated by the linker. Each
access to a threadvar goes through the fpc_relocate_threadvar function
(just check the assembler code to see what I
Am 13.04.2017 23:54 schrieb "gabor" :
>
>
>
> W dniu 2017-04-13 o 22:27, Sven Barth via fpc-devel pisze:
>
>> And it's not about saving RAM or disk memory! It's about *binary code
>> reuse*, the ability to fix a bug in multiple executables by merely
&
On 03.05.2017 09:06, Michael Van Canneyt wrote:
>
>
> On Wed, 3 May 2017, Tomas Hajny wrote:
>
>> On Wed, May 3, 2017 00:33, Michael Van Canneyt wrote:
>>> On Tue, 2 May 2017, Martin wrote:
On 02/05/2017 22:59, Michael Van Canneyt wrote:
>
>> That's probably good as the fastest / sh
Am 05.05.2017 16:03 schrieb "Juha Manninen" :
>
> On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner
> wrote:
> > 1. When using a character outside BMP FPC stops with:
> > Error: UTF-8 code greater than 65535 found
> > For example:
> > const Eyes = '👀';
>
> I copy a related post from Lazarus list by
Am 05.05.2017 15:55 schrieb "Michael Van Canneyt" :
>
>
>
> On Fri, 5 May 2017, Mattias Gaertner wrote:
>
>> On Fri, 5 May 2017 14:30:32 +0200 (CEST)
>> Michael Van Canneyt wrote:
>>
>>> [...]
>>> > AFAIK FPC stores UTF-8 string literals (-Fcutf8) as widestrings
>>> > instead of UTF8String. Please
Am 06.05.2017 08:18 schrieb "Martok" :
> PS: adding to the discussion over on the Lazarus ML: I just found a
fourth wiki
> page describing a slightly different Unicode support. This is getting
ridiculous.
That might be the one from Michael Schnell. Probably it should be marked
with a big, fat warn
Am 05.05.2017 16:08 schrieb "Sven Barth" :
>
> Am 05.05.2017 16:03 schrieb "Juha Manninen" :
> >
> > On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner
> > wrote:
> > > 1. When using a character outside BMP FPC stops with:
> > > Error: UTF-8 code greater than 65535 found
> > > For example:
> > > con
On 07.05.2017 14:16, Marco van de Voort wrote:
> In our previous episode, Sven Barth via fpc-devel said:
>>>> Is there a plan to fix it?
>>>
>>> Now it is fixed :D (revision 36116; maybe we should merge that to fixes
>> once I or someone else tested a
On 05.06.2017 20:37, Denis Kozlov wrote:
>
> I just wanted to highlight that these cases as legal and I presume not
> uncommon, particularly if values are deserialized and typecasted.
They are legal in the sense that they result in undefined behavior and
in that case the compiler is free to act a
Am 19.08.2017 09:12 schrieb "Ondrej Pokorny" :
>
> Hello!
>
> Has anybody thought about multiple inheritance in object pascal? I am now
working on a client-server service that entirely uses ORM. I have several
patterns that repeat all over and some of them do not match into the direct
inheritance s
On 21.08.2017 13:22, Michael Van Canneyt wrote:
>
>
> On Mon, 21 Aug 2017, Benito van der Zander wrote:
>
>> Hi,
>>
>>> This pattern is not inherently efficient. Why should it be ?
>>
>>
>> It is not efficient, because of the pointless instruction!
>
> I am not speaking of the current FPC impl
On 21.08.2017 21:15, Marco van de Voort wrote:
> In our previous episode, Sven Barth via fpc-devel said:
>>> I am asking, why do you think *this pattern* (of always returning self)
>>> should be inherently more efficient ?
>>
>> The pattern definitely has its us
Am 22.08.2017 13:15 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 22 Aug 2017, Thaddy de Koning wrote:
>
>>> On 21.08.2017 13:22, Michael Van Canneyt wrote:
On Mon, 21 Aug 2017, Benito van der Zander wrote:
> Hi,
>
>> This pattern is not inherently efficient.
Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" :
>
> Hello!
>
> I find it unnecessary to disable record helper inheritance in Delphi
mode. Due to this artificial limitation I have to change unit mode from
Delphi to ObjFPC.
>
> Reasons:
> 1.) It's a limitation of a feature that FPC already has.
> 2.)
Am 29.08.2017 08:47 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
>
>> Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" :
>>>
>>>
>>> Hello!
>>>
>>> I find it unnecess
Am 29.08.2017 10:37 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 8:47, Michael Van Canneyt wrote:
>>
>> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
>>
>>> Suggested name is "NonDelphiExtensions".
>>
>>
>> W
Am 29.08.2017 12:44 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 11:48, Sven Barth via fpc-devel wrote:
>>
>> The idea is okay as well, but I'd name it RecordHelperInheritance, cause
if we'd allow "type helper" in mode Delphi (as Maciej asks) then th
Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" :
> So yes, your description of {$modeswitch typehelpers} makes sense for
3.0.0 but not for trunk any more. So what is your intention - 3.0.0
behavior or trunk behavior?
Maybe it would indeed make more sense to adjust the meaning of the
typehelpers mode
Am 31.08.2017 12:07 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 22:30, Maciej Izak wrote:
>>
>>
>>>
>>> Btw. record helpers support inheritance in all modes but Delphi. It
doesn't make sense to disallow it for record helpers but allow it for type
helpers... Too overcomplicated without any plus val
Am 31.08.2017 15:55 schrieb "Ondrej Pokorny" :
>
> On 31.08.2017 14:55, Sven Barth via fpc-devel wrote:
>>
>>
>> > Yeah, they might enable record helper inheritance for example :P
(Record helper inheritance was documented to work for about 7 y
Am 31.08.2017 17:48 schrieb "Ondrej Pokorny" :
>
> On 31.08.2017 17:22, Sven Barth via fpc-devel wrote:
>>
>> > I remember a compiler bug in class destructor order call in Delphi:
https://stackoverflow.com/questions/19332847/delphi-class-variable-going-out-of-s
Am 01.09.2017 08:47 schrieb "Stefan Glienke" :
> Therefor I argue that the "only the last one in scope is applied"
restriction should be removed.
> If there are any clashes because two helpers introduce a any ambiguity
well then it is the compilers job to warn or error about those and provide
a way
Am 01.09.2017 11:51 schrieb "Stefan Glienke" :
>
> What I am lobbying for in Delphi are interface helpers and helpers for
generic types in general.
>
> I just saw that FPC currently has the same limitation. That also on your
list?
>
Interface helpers are implemented in trunk for around two weeks n
Am 01.09.2017 12:15 schrieb "Maciej Izak" :
>
> 2017-09-01 11:41 GMT+02:00 Stefan Glienke :
>>
>> Again you will cause unnecessary headaches because now your helper has
the dependency of the builtin and the third party one.
>> How would third party one and third party two implement them? They both
Am 01.09.2017 14:41 schrieb "Maciej Izak" :
>
> 2017-09-01 14:30 GMT+02:00 Michael Van Canneyt :
>>>
>>>
>>> No, directives won't be abused for something like that.
>>
>>
>> I am glad I am not the only one who thins so :)
>
>
> I like experiments as you know. Thanks for critical words as always :P.
Am 01.09.2017 14:50 schrieb "Stefan Glienke" :
>
> > For generics the only way to support them is that you must explicitly
specialize a generic helper type. The compiler won't do any type inference
for you.
>
> IMO this makes them rather useless. Is that a technical limitation or
just something you
Am 01.09.2017 21:07 schrieb "Ondrej Pokorny" :
>
> On 01.09.2017 18:38, Sven Barth via fpc-devel wrote:
>>
>> What if I do the initial specialization in a unit that does not know
about the helper? It can't just do speculative specialization once both the
specializ
Am 02.09.2017 17:06 schrieb "Karoly Balogh (Charlie/SGR)" <
char...@scenergy.dfmk.hu>:
>
> Hi,
>
> On Sat, 2 Sep 2017, Marco van de Voort wrote:
>
> > The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because
it
> > defines an array with texpropcode as range.
> >
> > This prohibits bu
On 02.09.2017 20:01, Benito van der Zander wrote:
> Hi,
>
> trunk is always broken, is it not?
Huh? It's rather seldom that we have real build breakages and even then
more often than not only on certain systems.
Regards,
Sven
___
fpc-devel maillist -
On 12.09.2017 22:21, Ondrej Pokorny wrote:
> On 29.08.2017 7:54, Sven Barth via fpc-devel wrote:
>> This will not be enabled by default. If anything a modeswitch will be
>> added so that users are aware that what they'll write will not be
>> compatible with Delphi.
>
Am 13.09.2017 22:21 schrieb "Ondrej Pokorny" :
>
> On 13.09.2017 22:08, Sven Barth via fpc-devel wrote:
>>
>> Anyway, I had looked at your patch last Friday, but after some thinking
>> I came to the conclusion that I definitely don't want the typehelpers
Am 29.09.2017 22:14 schrieb "Ondrej Pokorny" :
>
> Hello,
>
> I can't compile latest trunk for x86_64-win64: the first error message is:
>
> system.pp(136,18) Error: invalid register name
>
> i386-win32 compiles fine.
Are you sure that you're compiling with the correct compiler? Cause that
sounds
Am 30.09.2017 07:37 schrieb "Ondrej Pokorny" :
>
> On 30.09.2017 0:10, Sven Barth via fpc-devel wrote:
>>
>> Are you sure that you're compiling with the correct compiler? Cause that
sounds quite like you're trying to compile the Win64 RTL with a i386
compile
Am 16.10.2017 23:04 schrieb "Markus Beth" :
>
> On 16.10.2017 22:41, Florian Klämpfl wrote:
>> BTW: I would really like to see a PCMPSTR based implementation :)
>
> PCMPSTR is (at the moment) out of my scope. I thought PCMPSTR is part of
SSE4.2. How would you deal with Intel core microarchitecture
Am 31.10.2017 10:47 schrieb "Michael Van Canneyt" :
On Tue, 31 Oct 2017, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
>
>>
>> With your extended "forward type resolution" this would no longer be
>> possible.
>> Theoretically it probably can, but multiple passes w
Am 01.11.2017 05:58 schrieb "J. Gareth Moreton" :
Would it be worth opening up a bug report for this, with the attached
assembler routines as suggestions? I
haven't worked out how to implement internal functions into the compiler
yet, and I rather clear it with you
guys first before I make such an
Am 09.12.2017 14:57 schrieb "Benito van der Zander" :
Hi,
how do you recompile fpc after making a small change in the compiler, like
enabling the debugmsg define in x86/aoptx86.pas?
make buildbase says nothing was changed, and make clean; make buildbase
recompiles not just the compiler, but also
Am 10.12.2017 20:01 schrieb "J. Gareth Moreton" :
The idea I had currently (this is without
looking at any previous theory) was to use
a kind of sliding window, similar to how
ZIP and other LZ77-based algorithms work
when compressing repeating strings, to
look backwards in the current block for a
Am 14.12.2017 09:37 schrieb "Petr Kristan" :
Hi.
I compile whole project with -FcUTF8, but sometimes should be useful
to define string constant with CP_NONE to prevent conversions.
Example:
DefaultSystemCodePage:=1250
variable s contains text with cp=1250
s := s + '#'; //conversion because '#'
Am 18.12.2017 14:56 schrieb "Benito van der Zander" :
Isn't speed the main idea of using pointers?
It would be to port all existing pascal code
But that isn't the goal of pas2js. That is what WebAsm is for.
You may want to take a look at asm.js, which has a working
model for emulating pointe
Am 23.12.2017 11:01 schrieb "Adriaan van Os" :
J. Gareth Moreton wrote:
> Hey Adriaan,
>
> I dare ask - did the patch help out your issue at all? I did supply it to
> Florian as well, although he has his own work in progress for
> vectorization, so whether my code is compatible or not waits to b
Am 26.12.2017 14:44 schrieb "Thorsten Engler" :
> Item: BYTE BASED ItemPtr;
Ignoring any other considerations for now, I would have at least used a
logical extension derived from already supported syntax:
Item: Byte absolute ItemPtr^;
I agree, as it avoids adding a new keyword (even if it is
Am 26.12.2017 13:33 schrieb "Giuliano Colla" :
If the idea is not rejected, then a number of refinements (which I'm ready
to implement) are required to make the feature generally available:
My following remarks are independent of an eventual acceptance of the
feature :
- All architectures shoul
Am 27.12.2017 00:54 schrieb "Giuliano Colla" :
Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:
Am 26.12.2017 13:33 schrieb "Giuliano Colla" :
If the idea is not rejected, then a number of refinements (which I'm ready
to implement) are required to make the fe
Am 28.12.2017 11:30 schrieb "Giuliano Colla" :
Hi fpc developers,
I'm playing a bit with the compiler. In order to debug my changes I need to
compile some test programs.
To stay on the safe side, currently when I modify something I rebuild
everything (make all - make install) in order to provide
Am 11.01.2018 21:46 schrieb "J. Gareth Moreton" :
Possibly related, but the compiler automatically treats numbers larger than
or equal to $8000 as
signed (Int64) regardless of the context or what it's being assigned to
(this usually involves compiler
warnings, but also involves causing
Am 15.01.2018 10:14 schrieb "Mattias Gaertner" :
Hi,
Using fpc trunk. What means error
Error: Internal error 2018011401
?
Seems like the addition of that code wasn't as thought out by me as I hoped
it was...
You can remove the internal error and the check that leads to it in your
checkout. I'll
Am 01.02.2018 14:08 schrieb "Denis Kozlov" :
A proposal:
1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more
backwards compatible SHGetFolderPath().
2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer
SHGetKnownFolderPath() when it is available.
If this is su
Am 01.02.2018 14:31 schrieb "Michael Van Canneyt" :
On Thu, 1 Feb 2018, Denis Kozlov wrote:
A proposal:
> 1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more
> backwards compatible SHGetFolderPath().
> 2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer
> S
On 03.02.2018 17:39, Martin wrote:
> All based on win32
>
> Pretext:
> I have an issue with a crash in PopThreadQueueHead called by
> CheckSynchronize. (3.0.2)
> It happens in the Lazarus IDE, but at a low percentage only. (And not
> yet in the debugger)
> I don't think the below is related, but
On 04.02.2018 20:37, Martin wrote:
> On 04/02/2018 19:17, Sven Barth via fpc-devel wrote:
>> On 03.02.2018 17:39, Martin wrote:
>>> All based on win32
>>>
>>> Pretext:
>>> I have an issue with a crash in PopThreadQueueHead called by
>>> CheckS
On 05.02.2018 03:03, Martin wrote:
> Ok, I got it again in the debugger.
>
> Since it is nor reproducible all the times, I am using auto continue
> breakpoints, and just record that they were hit. So I have limited data.
>
> - After a long series of syncs ThreadQueueTail is nil.
> - A thread call
Am 19.02.2018 11:01 schrieb "Ondrej Pokorny" :
On 19.02.2018 10:25, Anton Shepelev wrote:
> Simon Ameis:
>
> However I think, FPC should generate the profiling
>> code itself. Then there is no need to modify the
>> code before and after the compilation.
>>
> Not, I think, for the naive ligh
On 19.02.2018 12:17, Ondrej Pokorny wrote:
> On 19.02.2018 11:14, Sven Barth via fpc-devel wrote:
>> Am 19.02.2018 11:01 schrieb "Ondrej Pokorny" > <mailto:laza...@kluug.net>>:
>>
>> I agree with Simon here. It's a similar scenario like heaptr
Am 24.02.2018 17:07 schrieb "Giuliano Colla" :
Attn. Sven Bart
Hi,
on jan 14 I had told you that I had to postpone further work on the
https://bugs.freepascal.org/view.php?id=33007 issue, because I was going to
be abroad for a couple af weeks.
Then I came back, I put in practice your suggestion
Am 25.02.2018 03:01 schrieb "Ozz Nixon" :
{$MACRO ON}
{$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}
Begin
_CTASSERT(1,1,'Constant failed.');
end.
Macros with arguments are not supported.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.free
Am 25.02.2018 12:14 schrieb "Mark Morgan Lloyd" <
markmll.fpc-de...@telemetry.co.uk>:
On 25/02/18 10:30, Florian Klämpfl wrote:
> Am 25.02.2018 um 11:12 schrieb Mark Morgan Lloyd:> On 25/02/18 02:15, Ozz
> Nixon wrote:>> {$MACRO ON}>> {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}>>
> Begin _CTASSE
Mark Morgan Lloyd schrieb am Do., 22.
März 2018, 17:57:
> On 22/03/18 15:30, Juha Manninen wrote:
> > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov
> wrote:> Please do... It has caused enough eye (OCD) stress over the years ;)
> > +1Yes, it has bothered also me a lot. I use code completion to ge
R0b0t1 schrieb am Fr., 23. März 2018, 16:07:
> >
> > IMHO preferably not the unit names (as in 'unit XxX') - with case
> > sensitive file names on Unix, this change might increase time for
> > searching the respective file (somewhat). Obviously, all further
> > references of the unit (as in 'SysU
Anthony Walter schrieb am Sa., 24. März 2018, 14:51:
> If you were going to patch I'd also consider allowing:
>
> program Test;
> var
> B, C: Integer = 0, 1; // sets B = 0, and C = 1
> begin
> end.
>
No, that is only confusing.
Regards,
Sven
___
fp
Ondrej Pokorny schrieb am Sa., 24. März 2018, 20:49:
> This is not correct. Global simple variables are always initialized. At
> least in Delphi it is so:
> http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If
> you do not explicitly initialize a global variable, the compiler
NetSpirit schrieb am Mo., 26. März 2018, 16:10:
> packages\pasjpeg
>
> Error usage after compile in -Mdelphiunicode mode.
> In file 'packages\pasjpeg\src\jpeglib.pas' member
> jpeg_error_mgr.format_message still uses AnsiString which is wrong.
> Because at the end of file 'packages\pasjpeg\src\jc
Martok schrieb am Do., 5. Apr. 2018, 16:29:
> > From this rule, it follows that every variable must be explicitly
> initialized [...]
> > Be it with an assignment or an 'var a: type = someonstant;'.
> ... for which the syntactic sugar was rejected not two weeks ago.
>
Did we read the same thread
Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 12:52:
> On 02.07.2017 18:55, Ondrej Pokorny wrote:
>
> On 02.07.2017 18:49, Jonas Maebe wrote:
>
> No, there is no built-in checked conversion from integer to arbitrary
> enumeration types. That's why I suggested in the bug report that started
> this
Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 21:16:
> On 13.04.2018 14:08, Sven Barth via fpc-devel wrote:
>
> Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 12:52:
>
>> I introduced the AS operator for enumerations in
>> https://bugs.freepascal.org/view.php?id=33603
Ben Grasset schrieb am So., 15. Apr. 2018, 09:05:
> AFAIK it's been working for over a year in a separate branch. The smart
> pointer example demos worked perfectly as far as I could tell. Is there a
> particular reason it hasn't been added to the main codebase the way
> management operators were
Amir schrieb am So., 15. Apr. 2018, 23:51:
> Hi all,
>
>Currently, FPC allows declaring objects as
> var
>MyMap: specialize TFPGMap;
>
> This is very nice feature since I do not need define every Map/List/etc
> as a separate type.
>
> But to create MyMap object, one has to write somethin
Bart schrieb am Mo., 16. Apr. 2018, 12:18:
> On Mon, Apr 16, 2018 at 7:53 AM, Sven Barth via fpc-devel
> wrote:
>
> >> This is very nice feature since I do not need define every Map/List/etc
> >> as a separate type.
>
> > Just declare a type for the speciali
Thorsten Engler schrieb am Sa., 21. Apr. 2018,
14:12:
> > -Original Message-
> > From: fpc-devel On Behalf Of
> > Martok
> > Sent: Saturday, 21 April 2018 21:39
> > To: fpc-devel@lists.freepascal.org
> > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF
> >
> > Am 20.04.2018 um
Alexander Grotewohl schrieb am Sa., 21. Apr. 2018, 16:40:
> To be honest I agree with what he's saying. We're bending enums to do
> things normal people just wouldn't (and shouldn't) do.
>
> And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for
> something a little better and make t
Bart schrieb am Fr., 27. Apr. 2018, 13:42:
> On Wed, Apr 25, 2018 at 11:04 AM, wrote:
>
> > If you compile and run this 64-bit program on Win 64 you get a crash
>
> And AFAICS your analysis of the cause (see bugtracker) is correct as well.
>
> function fpc_frac_real(d: ValReal) : ValReal;compil
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
16:09:
> Highest integer that fits in a Int64:
>
> 9223372036854775808
>
> 1e20:
>
> 1
>
>
>
> Your Int is overflowing.
>
>
>
> You can’t implement Frac by going through an Integer, that will never
> work. Except if you have an in
Bart schrieb am Do., 26. Apr. 2018, 19:29:
> Is this a bug, or was it changed by design?
>
It's a bug due to refactoring. I'll commit the fix once I got to run the
testsuite.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
17:47:
> > That's true for i386. But on x86_64 cvt(t)sd2si instuctions can
> > deal with int64 range, if destination register is a 64-bit one.
>
> You are still going to be at least 960-bit short...
>
I've disabled the SSE variant for now again till
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
18:48:
> For what it’s worth, Delphi simply decided to give up on doing it
> correctly and silently fail if the double is too large to fit in an Int64.
>
>
>
> WriteLn(Frac(1e15+0.5));
>
> WriteLn(Frac(1e16+0.5));
>
>
>
> When executed in 32bit code,
Am 27.04.2018 um 22:48 schrieb Bart:
On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel
wrote:
It's a bug due to refactoring. I'll commit the fix once I got to run the
testsuite.
So, I need not file a bugreport then?
Nope, fixed in r38860. :)
Reg
Am 28.04.2018 um 10:11 schrieb Thorsten Engler:
Oops, small mistake caused by last minute change (I replaced rol with
shl): it needs to be shr (or ror or rol, they all perform about the
same on my cpu).
And in case anyone wonders, the first cmp and branch returns 0 for
numbers that would ca
Am 28.04.2018 um 11:28 schrieb Thorsten Engler:
Basically that.
For doubles that don't fit into an Int64, any fraction is beyond the
significant number of digits that the double can store anyway, so 0 is the
valid and correct result for Frac in that case.
Since a float only stores the highe
Anthony Walter schrieb am So., 29. Apr. 2018, 21:27:
> I've run into an almost must have use case for FPC smart pointers as
> described and implemented by Maciej. I wanted to know from the people who
> make decision about what to merge, what's the status of rolling his
> enhancements at following
J. Gareth Moreton schrieb am Di., 1. Mai 2018,
23:39:
> It turns out I did over-engineer the solution somewhat - this version is
> far more efficient, honours NaNs and triggers SIGFPE if infinity is passed
> in (subsd triggers it), hence there are no regressions.
>
>
>
> function fpc_frac_re
J. Gareth Moreton schrieb am Mi., 2. Mai 2018,
11:10:
>
>
>
>
> On Wed 02/05/18 06:55 , Sven Barth pascaldra...@googlemail.com sent:
>
> ...
> Thank you for the work so far. Does it also work correctly when exceptions
> are disabled?
>
> Regards,
> Sven
>
>
> I confess I haven't tested that - I k
Maciej Izak schrieb am Mi., 2. Mai 2018, 18:21:
> I will continue my all work as much as possible with NewPascal (which will
> be synced with FPC trunk few times in the year - or more often if needed),
> I mean here all stuff, including updates for Generics.Collections library,
> bug fixes for co
J. Gareth Moreton schrieb am Do., 3. Mai 2018,
04:55:
> Tests complete! It turns out that I was using SetExceptionMask wrong and
> subtracting rather than adding exInvalidOp.
>
> When exceptions are disabled, this new Frac function returns NaN when you
> pass in plus or minus infinity. This is c
1 - 100 of 724 matches
Mail list logo
