obby", that
could go down to 50 or so. But still, it would take quite some more effort than
"a few 1000 euro's" in manhours, especially for those "programmers with
experience" (whom have a higher "cost" ofcourse).
I don't disagree with the
ave to allow explicitly
(checkbox) calling functions.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
t like a string - only a small string.
errrm, utf-8 can have 6 octets representing one character, not forgetting those
dioretics that are separate characters. (so I doubt representing it as above is
so correct, with a short(ansi)string)
kind regards,
Dimitri Smits
___
hat
is not always enough.
but I digress...
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
- "Graeme Geldenhuys" schreef:
> On 16/09/2011 00:01, Dimitri Smits wrote:
> >
> > errrm, utf-8 can have 6 octets representing one character,
>
> Last time I checked, that was only in the very early stages of
> developing the utf-8 specification. Since th
- Oorspronkelijk e-mail -
> Van: "Graeme Geldenhuys"
> Aan: fpc-devel@lists.freepascal.org
> Verzonden: Maandag 3 september 2012 12:42:11
> Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr
>
> On 03/09/12 10:19, Daniël Mantione wrote:
> >
> > Certainly, but the code used
- Oorspronkelijk e-mail -
> Van: "Graeme Geldenhuys"
> Aan: fpc-devel@lists.freepascal.org
> Verzonden: Maandag 3 september 2012 16:06:14
> Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr
>
> On 03/09/12 14:05, Mark Morgan Lloyd wrote:
> >
> > Except that modifying the
if
you count Win32 and Win64 as separate :-))
That said, what is stopping us (the community) to at least start on this? a
branch? core-buy-in?
kind regards,
Dimitri Smits
- Oorspronkelijk e-mail -
> Van: "Hans-Peter Diettrich"
> Aan: "FPC developers
v?, intel x86, powerpc,
motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or
custom backend)
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
faster, so will the compiler
itself after the recursive build.
or one would think so :-)
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Paul,
I think the OP meant the unit called 'rtti' in recent XE versions of Delphi.
kind regards,
Dimitri Smits
- Oorspronkelijk e-mail -
> Van: "Paul Ishenin"
> Aan: "FPC developers' list"
> Verzonden: Maandag 27 mei 2013 02:30:40
> Ond
)Watcom/Digital Mars/Microsoft/... on Windows and some on other
systems => same there.
there are some ABI's, but they do not contain name-mangling conventions.
ps: sorry to mess up your thread. I'm using digest.
kind regards,
Dimitri Smits
k.
sorry for the rambling/hard-to-follow(/read)-train-of-though, but the A/C seems
broken here today in the "factory" and hot+humidity is not a way to think
clearly. :-)
sorry also for the conversation disruption, but I read digests on the list and
can only reply accordingly.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ad could then do the marshalling over
the available pool of workerthreads and tasks.
Mind you, in this approach you can NOT use "threadvars" for workertasks' data
since you do not know if/when the task is resubmitted/remarshalled on other
thre
lem does not exist on *nix, just open another terminal and problem solved"
discussion of a few weeks back.
ps: will check if my problems still exist with more current Lazarus (latest
trunk update was 3 or 4 months ago) and if so, will "complain" in mantis :-)
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ze to the developer who is supposed to know
what (s)he is doing.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
methods and a method sink?)
Anyway, if so, would this "profiling" stuff be optional, on/off all or on/off
for a specific method/class/unit/package/program?
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
er makefile, please
redirect me to more information. (mainly for testing-app, I guess)
Anyhow, the first question is the more crucial one. If anybody is interested in
the (public) interfaces of the tobjecttypes, I can provide those. If there
needs to be a debate first, fin
copyright
violation?
ie: the "interface" is the same, the implementation is different (unless
trivial).
Is this, or is this not an issue?
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.free
- "Marco van de Voort" schreef:
> In our previous episode, Dani?l Mantione said:
> > > and C++ you can get hell when you change the order of elements,
> > > with interleaved #defines and #ifs (what's possible in Pascal as
> > > well).
> >
> > If the order of elements is enforced, it is no
Michael, thank you for the reply. It makes a few things a lot clearer for me.
I'll comment a bit more below.
- "Michael Van Canneyt" schreef:
> On Sat, 28 Aug 2010, Dimitri Smits wrote:
> > What I want to do:
> > Since Delphi 2010, there is a new unit in the
Hi Paul,
thanks for the input.
- "Paul Ishenin" schreef:
> 29.08.2010 3:46, Dimitri Smits wrote:
>> What I want to do:
>> Since Delphi 2010, there is a new unit in the RTL that makes RTTI
>> more of a breeze. I'd like to port (meaning: compatible interfa
occasion (when I had
the chance).
Was full of MACOS and Linux IFDEF's already!
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ould be nice to know who wrote/compiled the packages page in the fpc wiki
and to get in contact with ppl that want to discuss/implement "delphi packages".
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
dline tool. Unfortunately the DLL is not linked from the cmdline tool,
so it seems those 2 are separately compiled and statically linked with 'the
same' code.
Donno for sure if that still is the case with 2010/XE.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ad of scanning the whole search paths.
>
> I used the IDE always when working with Delphi and don't really know
> dcc32.
> Guessing only.
>
no, the bin directory of D7 is filled with extra .exe's (tlib, tasm32, ...) and
the dcc32.exe is < 800K big.
kind regard
ows 'ant')
it implies though that you can merely compile your .dpk and .dpr files to get
everything compiled ;-)
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
mp for all .ppu files or .pas files first.
3) It is my understanding that the .ppu structures are written with
size-footprint in mind, not processing efficiency? Maybe the structures need
changing too?
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
- Most profiling recently afaik has been done by Jonas, and thus not
> on Windows. Yet the delphi comparisons are on windows.
> - Actually linking should be avoided in the test. It might obscure
> things.
in that case, all "external tools" should be avoided.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> >
> > I assume dcc.exe uses more data than code :-)
>
> CPU caches do not work FIFO.
> If FPC does not fit into the CPU cache, then the CPU has to
> constantly
> load code mem additionally to the data.
>
in that case, can splitting up the .ex
addmoduleunloadproc/removemoduleunloadproc are invoked either by unloadpackage
or by unregistermodule.
---
as said before, inspiration can be had from how they do it, but that doesn't
mean fpc should do it that way. Especially in a crossplatform context, and more
so cross-architecture, it is not a one-size fits all per se.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
- "Sven Barth" schreef:
> Am 13.09.2010 14:46, schrieb Dimitri Smits:
> > as said before, inspiration can be had from how they do it, but that
> doesn't mean fpc should do it that way. Especially in a crossplatform
> context, and more so cross-architecture,
ce strings because FPC resource strings are not
> unicode
> > capable AFAIK.
> > In MSEgui there are many local classdefs in the form of
> > "
> > type
> > ttheclass1 = class(ttheclass);
> > "
> > in order
appareantly this one didn't get through
- "Sven Barth" schreef:
> Am 13.09.2010 14:46, schrieb Dimitri Smits:
> > as said before, inspiration can be had from how they do it, but that
> doesn't mean fpc should do it that way. Especially in a crossplatf
ll have the vclXXX.dcp statically linked into your executable when
you use a TForm and include the Forms unit somewhere in your code.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
eplacing "RTTI_" with "@xp@" or something you are more
familiar with for starters?
RTTI is already provided. Try building with retaining assembler output to see
what I mean.
Some link-names are indeed easily becoming too long, others would think the
"all uppercase" i
bad ;-)
> > However, at the moment I don't see why this is better than shipping
> all
> > necessary ppl files. BTW: I realize that ppl might be a bad TLA -
> since
> > it probably means "people" for quite a number of ppl ;-)
>
> Nah. Just wonder if tha
- "Hans-Peter Diettrich" schreef:
> Dimitri Smits schrieb:
>
> > It is therefore simple to say in delphi that you want to build with
> > rtlXXX.bpl only, but still have the vclXXX.dcp statically linked
> into
> > your executable when you use a TForm and
ent, but then your fpc-compiled c++ will be incompatible with
everything else. Come to think of it, no 2 C++ compilers mangle the same due to
VMT and other abi-stuff anyway.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
d that is mainly for lazarus. The fpc-ide debugger for
instance is the only way to get assembler-viewing+stepping to work. (to some
extend)
at least on win32
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
stem, most of the "complaints" I have about missing
features are not inherent to fpc, but more to the tools around it (like lazarus
with it's subpar debugging compared to D7).
I guess it's time to put my code where my mouth is, bu
64bit in this
special case.
As I understand its mostly used use case is for zero'ing memory when used in
compiler/runtime memory initialization/finalization, it might bring a small
upgrade in speed (more so if it is for lots of small memory-block zer
as well with a Delphi interface. Maybe it can be made portable as well
to fpc and x-platform.
http://tracetool.sourceforge.net/
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ok, answering my own mail after a small test below
- "Dimitri Smits" schreef:
> what I DON'T do is use it like in your example, Graeme. I always
> assign the result to a local variable, which goes out of scope in an
> implicit finally block at method-exit. Haven
- "Thomas Schatzl" schreef:
> Hi,
>
> On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits
> wrote:
> >
> > it seems that the stackvariables are NOT unloaded in the correct
> order
> > (ie: reverse order of declaration).
> > It shouldn
e and even invite bad programming.
> We'll fix the issue as the upcoming Delphi 64-bit - unfortunately -
> forces us
> to follow suit.
sad to read this part though...
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
that comes with Delphi XE. It can also be on a per
instance base (as opposed to on a per type) if I've read up on it correctly.
I'd say that would be a better candidate for that purpose/intent/use case.
kind regards,
Dimitri Smits
___
fp
owledge and we could get
rid of the comments "delphi compiler is x times faster than fpc" that pop up
every once in a while. :-)
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ient, ie: yourself)
btw, I even believe that you can devise a licence that is GPL compatible
(copyleft), but that disallows redistribution/resell. Like a bit of an NDA.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal
f module/package<->units<->typeinfos working, I
intend to go on with the RTTI unit implementation and subsequent questions on
that topic.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
- "Sven Barth" schreef:
> Am 11.08.2011 16:38, schrieb Dimitri Smits:
> > once I get a tree-hierarchy of module/package<->units<->typeinfos
> > working, I intend to go on with the RTTI unit implementation and
> > subsequent questions on th
way your resulting html is structured.
>xslt could be a natural fit in this respect. In most browsers you can open
>the/a xml then with a stylesheet. Another way to generate with fpdoc could be
>using some html-snippets/html-templates if they are too overrideable.
kind r
52 matches
Mail list logo
