> I know I'm a newbie in fpc, but I don't see backward compatibility a reason
enough to leave to implement some improvements, like organize the
base units of the fpc into proper namespaces.
Backward compatibility is what the market is mostly about, most companies
don't want to change their codebas
Am 26.10.2013 04:18 schrieb "Fabrício Srdic" :
>
> I know I'm a newbie in fpc, but I don't see backward compatibility a
reason enough to leave to implement some improvements, like organize the
> base units of the fpc into proper namespaces.
We value backwards compatibility very high as there is mu
op 24-10-13 13:41, Koenraad Lelong schreef:
But I'm unable to locate where that '--build-id' is generated for the
linker-commandline. If that is removed (only for arm-embedded ?), the
build-id will not be generated, so no wasted memory.
Hi,
I found where the '--build-id' is defined : /etc/fpc.
Sven and Leledumbo,
I agree with the importance of backward compatibility, but I disagree when
it becomes a reason to stop the implementation of improvements in the tool.
I remember the nigthmare of migrating my existing codebase to D2009 because
of your new UnicodeString support. But, with this
Does FPC have any support these days for creating and accessing sparse
files, in particular on Linux? I'm considering a file containing a 2Gb
fixed-size filesystem, with one or more sparse files logging updates.
Obviously I could use something like Qemu's qcow format, but initially
at least I t
Am 26.10.2013 11:39 schrieb "Koenraad Lelong" :
>
> op 24-10-13 13:41, Koenraad Lelong schreef:
>
>> But I'm unable to locate where that '--build-id' is generated for the
>> linker-commandline. If that is removed (only for arm-embedded ?), the
>> build-id will not be generated, so no wasted memory.
In our previous episode, Fabr?cio Srdic said:
> I know I'm a newbie in fpc, but I don't see backward compatibility a reason
> enough to leave to implement some improvements, like organize the
> base units of the fpc into proper namespaces.
It depends on the improvement. And IMHO this is a meagre o
In our previous episode, Dmitry Boyarintsev said:
> Not really namespace related, but:
> Most of the commercial/free/open source Delphi/FPC libraries are backward
> compatible to D7-D6 (including all Delphi-win32 versions)
> That comes with a cost (a bless) of not using new language syntax (as much
The subject already says it:
Why are the API functions CopyFileExA
and CopyFileExW missing from the windows unit?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Sat, Oct 26, 2013 at 7:06 AM, Fabrício Srdic wrote:
>
> I agree with the importance of backward compatibility, but I disagree when
> it becomes a reason to stop the implementation of improvements in the tool.
>
Well, no. You shouldn't say "improvement". Because "improvement" has
positive conte
Am 26.10.2013 11:37, schrieb Koenraad Lelong:
> op 24-10-13 13:41, Koenraad Lelong schreef:
>> But I'm unable to locate where that '--build-id' is generated for the
>> linker-commandline. If that is removed (only for arm-embedded ?), the
>> build-id will not be generated, so no wasted memory.
>>
>
Am 26.10.2013 14:45 schrieb "Jürgen Hestermann" :
>
> The subject already says it:
>
> Why are the API functions CopyFileExA
> and CopyFileExW missing from the windows unit?
Likely because they are newer API functions and just weren't added yet. It
would be nice if you'd do a bug report preferably
They're part of JEDI win base (jwawinbase.pas) though.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx
thanks,
Dmitry
On Sat, Oct 26, 2013 at 10:30 AM, Sven Barth wrote:
> Am 26.10.2013 14:45 schrieb "Jürgen Hestermann" >:
>
> >
> > The subject already says
In our previous episode, Sven Barth said:
> > The subject already says it:
> >
> > Why are the API functions CopyFileExA
> > and CopyFileExW missing from the windows unit?
>
> Likely because they are newer API functions and just weren't added yet. It
> would be nice if you'd do a bug report prefer
2013/10/26 Dmitry Boyarintsev
> On Sat, Oct 26, 2013 at 7:06 AM, Fabrício Srdic
> wrote:
>
>>
>> I agree with the importance of backward compatibility, but I disagree
>> when it becomes a reason to stop the implementation of improvements in the
>> tool.
>>
>
> Well, no. You shouldn't say "improv
On 10/25/2013 10:18 PM, Fabrício Srdic wrote:
I know I'm a newbie in fpc,
myself.. even after almost a decade ;)
As Michael and Sven said, if Delphi itself is not fully compatible among
versions, why should fpc be?
because FPC (and lazarus) strives to be better? and to not alienate those wh
On 10/26/2013 7:06 PM, Fabrício Srdic wrote:
If the namespace feature isn't a improvement, so why was it added to fpc?
compatibility with delphi products that use it??
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
2013/10/25 Michael Van Canneyt
> Why not simply make it a procedure that is called by ver-2 and ver-3.
>
> If it cannot be called directly from external code, and will called only
> from inside a visible consructor, there is simply no reason to make this
> procedure a constructor. A simple proced
2013/10/26 waldo kitty
> On 10/26/2013 7:06 PM, Fabrício Srdic wrote:
>
>> If the namespace feature isn't a improvement, so why was it added to fpc?
>
> because FPC (and lazarus) strives to be better? and to not alienate
> those who use it by forcing them to adjust all their working code when a
2013/10/25 Michael Van Canneyt
> Why not simply make it a procedure that is called by ver-2 and ver-3.
>
> If it cannot be called directly from external code, and will called only
> from inside a visible consructor, there is simply no reason to make this
> procedure a constructor. A simple proced
On Sat, Oct 26, 2013 at 9:17 PM, Fabrício Srdic wrote:
> D2009 "forced" us to adjust our existing code base to its new
> UnicodeString support, but in return it give us internationalization
> support and new possibilities.
>
Again, this is not really accurate. Internationalization is provided by
u
2013/10/27 Dmitry Boyarintsev
> D2010 have introduced the namespace feature and DXE2 "forced" us to
>> adjust our existing code base to its new unit scope names - namespace of
>> its base units - but in return it give us new possibilities to organize our
>> existing code base through namespaces,
On Sat, Oct 26, 2013 at 11:37 PM, Fabrício Srdic
wrote:
.
>
> We can't nest units to form a hierarchical content. With namespaces, we
> can. Furthermore, namespaces can be used to disambiguate identifiers with
> the same name, eliminating the need to prefix our identifiers. It's a pure
> techinica
> Furthermore, namespaces can be used to disambiguate identifiers with the
same name, eliminating the need to prefix our identifiers
How does that differ from existing . solution?
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Namespaces-Support-tp5717153p571
24 matches
Mail list logo
