Am 30.07.2011 17:05, schrieb Jürgen Hestermann:
Say for instance you are working on Galois fields and you have to do
arithmetic on the elements like this:
g1 + g2 / g3
If you don't have operator overloading, you have to do it with
functions, like this:
gf_add(g1, gf_div(g2, g3))
This
Am 29.07.2011 13:43, schrieb Bernd:
With interfaces and their reference counting it can be made to work
but the cost of doing this seems so immense that I don't believe it is
justifiable in many real world applications (at least not in my
application).
The automatic constructor/destructor
Am 19.10.2011 23:28, schrieb Andrew Pennebaker:
From what I gather, procedure variables can indeed be referenced and
passed around, etc.
However, procedures do not return anything, so it's hard to chain them.
They are called procedure variables but can also contain functions.
In functional
Am 21.10.2011 03:49, schrieb Andrew Pennebaker:
Lisp used for nuclear fail-safe systems
I doubt languages without /map/ are up to the job.
Great, why don't you continue to use lisp then? If pascal does not
offers the language concepts you are used to, pascal is the wrong
language for you.
Am 08.11.2011 07:20, schrieb Jürgen Hestermann:
Jonas Maebe schrieb:
That's exactly what he said: you are free to create a fork
This argument is pulled out each time someone suggest things that the
main developers don't like.
The reason that this argument is always used is simply because that
Am 08.11.2011 07:35, schrieb Graeme Geldenhuys:
On 7 November 2011 20:41, Marco van de Voort wrote:
That current is added by you. FPC strives to do that of course, but never
had the illusion it was near enough to claim something like that. Not now,
and not in the past.
So what exactly is
Am 08.11.2011 09:37, schrieb Graeme Geldenhuys:
2011/11/8 Tomas Hajny :
Examples?
I can list them all, but I'm not going to waist my time on them again.
Search the mailing list or Mantis.
But to humour you, here is just one of many examples: THelpEvent in
the RTL. I proposed a patch to
Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:
On 7 December 2011 14:54, Jonas Maebe jonas.maebe@ wrote:
That's correct. We use the mersenne twister, Delphi probably a linear
congruential generator. The mersenne twister has a much larger period.
I was reading a bit more about this.
Am 08.12.2011 08:25, schrieb Felipe Monteiro de Carvalho:
On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
juergen.hesterm...@gmx.de wrote:
Fully agree. Especially, because ex Delphi (and ex Turbo Pascal) users would
expect it like that. And most of them (coming from Delphi/TP) believe that
Am 08.12.2011 08:48, schrieb Graeme Geldenhuys:
[like what was told to me numerous times before] They (FPC users)
should speak up now,
Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
___
Am 08.12.2011 09:03, schrieb Graeme Geldenhuys:
On 8 December 2011 09:50, Florian Klaempfl wrote:
Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
I for one did not even know about the existence of Free Pascal 10 year
ago. I don't believe
Am 09.12.2011 07:27, schrieb Jürgen Hestermann:
Reimar Grabowski schrieb:
The parameter should default to FALSE to not break existing code
relying on FPCs random function
And what about existing code coming from Delphi/Turbo Pascal? This was a
strong argument in the past for doing even
Am 09.12.2011 09:02, schrieb Vincent Snijders:
2011/12/7 Graeme Geldenhuys graemeg.li...@gmail.com:
Hi,
I did a simple GetTickCount() timing around this loop. Delphi executes
the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
loop runs 200400 iterations. The types for
Am 26.04.2012 14:57, schrieb OBones:
Jonas Maebe wrote:
OBones wrote on Mon, 23 Apr 2012:
And because I have to split my generated files so that FPC does not
hit the 2GB memory limit (which it does for a 15M source file)
What is the structure of that source code? (a few giant routines,
Am 08.06.2012 14:37, schrieb Jeppe Græsdal Johansen:
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would do the alignment, the
loss
can also be up to
Am 11.06.2012 12:03, schrieb Mattias Gaertner:
Hi,
Has someone already implemented a fpimage reader for jpeg2000?
Probably not due to the patent situation?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Am 12.06.2012 09:50, schrieb Koenraad Lelong:
On 08-06-12 14:37, Jeppe Græsdal Johansen wrote:
Den 08-06-2012 14:28, Ludo Brands skrev:
Thanks Ludo,
I'll take that as a starting point. I hope I will not need the lost
256 bytes in the future.
I could be wrong but AFAIK if the compiler would
Am 11.06.2012 13:46, schrieb alrieckert:
Hi Jeppe,
I've been using the actual ROM based interrupt table for the past
month now in freepascal ad it seems to work great. No need to declare
a block of RAM and pointing the interrupt table to it.
You can code any procedure and just give it the
Am 22.02.2013 15:36, schrieb Refr Bruhl:
http://www...p2t
Please do not click the link in this mail, it is probably malware/spam.
I have set the moderation flag for Refr Bruhl. Sorry for any
inconvenience caused by this.
___
fpc-pascal maillist -
Am 05.03.2013 22:36, schrieb Dimitri Smits:
- Oorspronkelijk e-mail -
Van: Florian Klämpfl flor...@freepascal.org Aan: FPC-Pascal
users discussions fpc-pascal@lists.freepascal.org Verzonden:
Maandag 4 maart 2013 21:00:10
And how does this change the fact that it is an external cg
Am 09.03.2013 08:49, schrieb Reinier Olislagers:
Sergei Gorelkin enabled Win64 SEH support in trunk r23732:
* Make Win64 SEH support enabled by default. If necessary to disable,
compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012.
Is it usefull to make DISABLE_WIN64_SEH a
Graeme Geldenhuys schrieb:
Vincent Snijders wrote:
I disagree. It would be backwards incompatible with existing objfpc
programs. That decision should have been made 10 (?) years ago, when
mode objfpc was introduced.
Not everything was done correctly 10 years ago (or first time round).
Jonas Maebe schrieb:
On 28 Jun 2009, at 11:59, Graeme Geldenhuys wrote:
Does FPC support the above OS?
I don't think so. Some Symbian support was committed a long time ago,
but I don't think it was ever finished.
Making a Symbian tool chain is unfortunatly a real pain.
There is still a 1k Bounty for an FPC Symbian port ;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Vincent Snijders schrieb:
Jürgen Hestermann schreef:
Still I am wondering why the directory Local Settings is used and
not Application Data as all other applications do. Then it would
be saved with roaming profiles too.
Luca Olivetti schrieb:
http://bugs.freepascal.org/view.php?id=13908
Mattias Gärtner schrieb:
Zitat von Florian Klaempfl flor...@freepascal.org:
Mattias Gaertner schrieb:
On Thu, 16 Jul 2009 10:30:23 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Jürgen Hestermann, how often do you change your working machine?
Well, I seldom change it [...]
If I
Mattias Gärtner schrieb:
Zitat von Florian Klaempfl flor...@freepascal.org:
Mattias Gärtner schrieb:
Zitat von Florian Klaempfl flor...@freepascal.org:
[...]
A network file system is too slow for developing. Compiling anything
via nfs or smb is a nightmare speedwise.
NFS over gigabit
Micha Nelissen schrieb:
Florian Klaempfl wrote:
Roaming profiles using auto copy/delete are not the best choice for
that.
For me it works fine for years ;)
Then you must be the only one since everybody I know despises it. We use
multiple times login sometimes and then the settings
Soon or later fpc 2.4.0 will be released so it would be nice to have
updated translations of the compiler message files. So if anybody
volounteers to update the message files for a certain language, please
tell us, the decription how to do so can be found here:
theo schrieb:
If somebody is still interested in HAL (I know that DeviceKit ist coming):
I've made a header translation and a demo (translation of lshal.c)
yesterday.
It seems to work for me. http://www.theo.ch/lazarus/dbus/hal.tar.gz
Please create and attach it to an issue report so we don't
theo schrieb:
Florian Klaempfl schrieb:
Please create and attach it to an issue report so we don't forget it.
You mean using the bugtracker?
Yes.
If you like, you could also add the files to packages/dbus
What do you prefer?
Bug tracker, simply because somebody with at least some
theo schrieb:
Florian Klaempfl schrieb:
You mean using the bugtracker?
Yes.
OK, I can do that.
Bug tracker, simply because somebody with at least some knowledge
about dbus should review. My knowledge about dbus is close to zero :)
I know it's name and that's it :)
Maybe the subject
Nataraj S Narayan schrieb:
Hi
Fpc compiled binary:-
r...@at91sam9263ek:~$ readelf -h firework
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version:
Graeme Geldenhuys schrieb:
Hi,
What is the use of the fpc/compiler/*.lpi files? Is that another way
of building a new compiler version using Lazarus IDE (instead of 'make'
from the command line?
They can be used for FPC (compiler) development with lazarus.
Graeme Geldenhuys schrieb:
Michael Van Canneyt wrote:
Because I want a FPC program to depend only on the Linux kernel,
not on the C library.
OK.
There are FPC programs from 8 years back that still work with the current
kernel. Try that with a program that depends on the C library.
Henry Vermaak schrieb:
2009/8/27 Michael Van Canneyt mich...@freepascal.org:
Because I want a FPC program to depend only on the Linux kernel, not on the
C library.
There are FPC programs from 8 years back that still work with the current
kernel. Try that with a program that depends on the C
Jonas Maebe schrieb:
On 27 Aug 2009, at 12:49, Graeme Geldenhuys wrote:
Is this an issue, even if your program doesn't use any
procedures/functions from the dynamically linked C library. For example,
a console application that includes the cthreads unit (which dynamically
links to C
Graeme Geldenhuys schrieb:
Hi,
The current TMultiReadExclusiveWriteSynchronizer as implemented in FPC
2.3.1 is wrong. It use Critical Sections in a standard way which means
it blocks all other threads while one thread is doing a Read. This is
wrong. It is a MULTI read, SINGLE write
Jonas Maebe schrieb:
On 28 Aug 2009, at 10:35, Florian Klaempfl wrote:
If you have a better for unix this will be fine. IIRC it is not easy (if
possible after all?) to implement TMultiReadExclusiveWriteSynchronizer
for unix systems.
What's wrong with these routines: pthread_rwlock_init
Jonas Maebe schrieb:
On 18 Sep 2009, at 16:24, Dariusz Mazur wrote:
I use own lockfree FIFO http://www.emadar.com/fpc/lockfree.htm to
distribute task between threads
its much faster and well scaling on multicore.
Note that it won't work as is on non-x86 machines, because it's missing
Graeme Geldenhuys schrieb:
2009/9/29 Marco van de Voort mar...@stack.nl:
No.
So why is the function called MOVE instead of COPY? :-)
Because it doesn't copy your ram modules ;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Graeme Geldenhuys schrieb:
2009/9/29 Florian Klaempfl flor...@freepascal.org:
Because it doesn't copy your ram modules ;)
Well, if I move something (no matter what it is), it doesn't exist in
the original location any more. Hence my confusion about the Move()
procedure.
Indeed, the serious
Jonas Maebe schrieb:
On 29 Sep 2009, at 15:46, Graeme Geldenhuys wrote:
Windows has 'memcpy()', not 'memcopy()' ;-)
memcpy() is from the C library. And the C library also has memmove(),
for that matter.
The difference between memcpy() and memmove() is that memcpy() has
undefined
Graeme Geldenhuys schrieb:
2009/9/29 Florian Klaempfl flor...@freepascal.org:
Indeed, the serious answer is:
move handles overlapping memory blocks correctly (so the data might not
existing anymore at the old location), memcpy doesn't do this and screws
things up when handling overlapping
Michael Green schrieb:
Quick question: Is there any particular reason why the system function
ror() (in /fpc/rtl/inc/systemh.inc) has been divided up into rorbyte,
rordword and rorqword (and respectively for rol() ) instead of being
overloaded?
Ror/rol are very sensitive against data type
Vincent Snijders schrieb:
Jonas Maebe schreef:
On 07 Oct 2009, at 09:19, Vincent Snijders wrote:
IIRC, there is a difference. With the second declaration the compiler
can add a run-time check that the correct memebrs are accessed based
on the value of X.
Unfortunately, I cannot find the
Jonas Maebe schrieb:
On 07 Oct 2009, at 17:39, Jürgen Hestermann wrote:
And I don't know any other Pascal Compiler who does any checks in this
direction. Do some?
I don't know, but ADA reportedly does. Such a feature definitely seems
useful to me.
Afaik GPC does as well?
Graeme Geldenhuys schrieb:
1) Why would you use a pointer to an array and not simply a variable
what IS the array? In the program I am porting the following field
variable is defined.
FLines: ^TLinesArray;
Why couldn't I simply say:
FLines: TLinesArray;
Because this array
Henry Vermaak schrieb:
2009/10/11 Vinzent Höfler jellyfish.softw...@gmx.net:
Henry Vermaak henry.verm...@gmail.com:
Thanks for the explanation, I was under the impression that arrays in
Pascal were similar to C. How do you explain the automatic
dereferencing with a pointer to an array that
Jürgen Hestermann schrieb:
As said it depends from your viewpoint. C's original viewpoint was to
keep
the state of a compilation unit as small as possible, to maximize the
size
of a program with limited memory.
You mean they gave saving one character in the source code a higher
priority
Jürgen Hestermann schrieb:
No, it happens with static arrays, if you set pia := @ia, ia[x] and
pia[x] will give you the same result (in delphi mode, at least).
It's simply more readable and a shortcut.
It's definitely the opposite: It is *less* readable
This is your opinion :) To my
Jürgen Hestermann schrieb:
Yes, but you cannot avoid it, if you work with dynamic arrays. You are
not even told that it's a pointer. That's just the problem.
The problem is that one is playing with stuff he doesn't understand.
Explict use of pointers is always dangerous and one should really
Great power comes with great responsibility.
Yes. Then use C or assembler. You are responsible for everything and
you cannot expect any help from the compiler.
So the consequence would be to forbid pointers/@-operator/type casts et.
al. If you want pointers and all dirty stuff, use C or
Jürgen Hestermann schrieb:
Florian Klaempfl schrieb:
Great power comes with great responsibility.
Yes. Then use C or assembler. You are responsible for everything and
you cannot expect any help from the compiler.
So the consequence would be to forbid pointers/@-operator/type casts et.
al
Jonas Maebe schrieb:
Florian Klaempfl wrote on Tue, 13 Oct 2009:
When messing with pointers you've to know what to write because pointers
allow unlimited access to internal data structures. Sorry, but I can't
help you if you guess wrong while playing with dangerous stuff (and the
original
Graeme Geldenhuys schrieb:
What if I don't pass in a size to
FreeMem(), will it know how much to free?
Yes (as long as you don't mess with internal heap structures ;)).
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Graeme Geldenhuys schrieb:
Hi,
Which of these should I use in new projects? I read somewhere that
GetMem/FreeMem is actually compatibility methods from Turbo Pascal
days, yet I have seen lots of new code that uses it, so I guess it's
still ok to use?
GetMem/FreeMem are lower level than
Marco van de Voort schrieb:
In our previous episode, J�rgen Hestermann said:
There is not even a proper open one for Delphi. At least there wasn't till a
while back.
That may be because it is no longer possible to write a BNF grammar for
these compilers due to the c-style extensions.
Odd
Frank Peelo schrieb:
Is the problem that you start off with a grammar, write the parser, then
maintain the parser without updating the grammar?
Every early FPC (FPK Pascal) prototypes in 1993 used yacc as well but it
was simply too slow and also memory consuming at these days.
Florian Klaempfl schrieb:
Frank Peelo schrieb:
Is the problem that you start off with a grammar, write the parser, then
maintain the parser without updating the grammar?
Every early FPC (FPK Pascal) prototypes in 1993 used yacc as well but it
Very early
Jonas Maebe schrieb:
ik wrote on Fri, 23 Oct 2009:
You can use bitpacked records:
http://www.google.com/codesearch?hl=enlr=q=bitpacked+record+package%3Ahttp%3A%2F%2Fpasxlibbind
\.googlecode\.comsbtn=Search
Here is an example on how I use it :)
No, you cannot use bitpacked records for
Holger Bruns schrieb:
Holger Bruns schrieb:
I try to implement a direct port access. If this also leads to access
errors, I should give it up. Embarassing.
Accessing ports is limited to ports 03ffh, more ports cannot be
released with fpioperm. This means to me, successful serial port access
Marc Santhoff schrieb:
Hi,
after finding the floating point calculations implementation for fpc[1]
I'm asking myself if it is possible to force fpc to use it although the
CPU does actually have a FPU built in.
How can this be done?
Try to build the rtl with OPT=-Cfsoft, it might work,
Jonas Maebe schrieb:
On 09 Nov 2009, at 13:49, Graeme Geldenhuys wrote:
See the output below. The 32bit Linux FPC can target 32bit 64bit
platforms. But 64bit Linux FPC cannot target 32bit platforms. The later
can only cross-compile to other 64bit platforms.
I guess you mean this:
In my opinion, there is an incompatibility. Fix it.
If you care about it, provide a usable patch.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Graeme Geldenhuys schrieb:
Marco van de Voort wrote:
But I agree with Jonas. The problem is the obsession to eliminate
each and every warning, not the hint/warning.
I fully agree with JoshyFun. It's nothing to do with obsession. I you
keep getting thousands of useless hints you will
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
If hints are really important, they would be warnings.
And working with a uninitialized data structure is a good thing? I think
not. So, like everybody else, I manually initialise my data structures -
and because of my efforts to write
Graeme Geldenhuys schrieb:
Jonas Maebe wrote:
It's not about it not being a high priority problem, it's about it
being fundamentally unfixable (except by using a completely different
See my reply in fpc-devel mailing list.
Bottom line is, I don't think it's right for a project that
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Out is not made to solve such problems but plainly to work with
COM/Corba.
Really? Well, that's not what the FPC manual says:
And? Is there a different reason written? And even if it is:
documentation writer know less than
Anthony Walter schrieb:
type generic TListT = class end;
See, we started a block {type} and introduced a keyword {generic}
before the identifier {TList}. This unnecessarily breaks the pattern
and is inconsistent.
It is a compromise made by the implementor. The proper solution would
have
Denis Golovan schrieb:
Hi all
I've got a non-obvious class hierarchy with interfaces involved.
The problem is that, I thought property ... implements ...;
construction fully substitute for implementing interface methods in
class itself, but now it's just not true.
I get different results
Schatzl Thomas schrieb:
Hi again
What about making it an FPC package?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Anthony Walter schrieb:
Okay, I am going to call bullshit on you.
What about just unsubscribing from the list? Nobody needs you here. MvC
did an incredible job on FPC docs, you just waste our time.
___
fpc-pascal maillist -
Felipe Monteiro de Carvalho schrieb:
Hello,
I've noticed that few people use the FPC Forum and questions often
stay months without answer. I would answer more questions, but
monitoring 2 forums is too much work. We have already merged the
wikis, what about merging the forums? I would
Bee Jay schrieb:
We have already merged the wikis, what about merging the forums?
I would propose merging into the Lazarus forum.
Why don't we make our own forum application using fpWeb (or Powtils or
ExtPascal)?
Time?
___
fpc-pascal maillist -
Bee Jay schrieb:
Hi all,
I just knew recently that Midlet Pascal went open source, through FPC
wiki. Quite a good news, IMO. Since it's now open source, is it possible
to start working on java byte code generator in FPC based on Midlet
Pascal code? This will help FPC targetting mobile
Paul Nicholls schrieb:
For me, i like to see Pascal generate good web application, especially
if it had Right To Left support :)
What is right to left support?
Bidi support as e.g. semitic languages require.
___
fpc-pascal maillist -
Doug Chamberlin schrieb:
Jonas Maebe wrote:
On 02 Jan 2010, at 21:56, Doug Chamberlin wrote:
1) Yes, the Users Guide has installation instructions in Chapter 2.
However, it warns only to not install the software into directories
that contain embedded spaces. It does NOT warn about untarring
Lou James schrieb:
I still didn't find out where to get the 2.4.0 version for iphone..
Shouldn't it be under ARM/Mac OS X?
No. The directories are named by host operating system so the arm-macosx
cross compiler is in
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/i386-macosx/
Peter W A Wood schrieb:
Jonas Maebe wrote:
http://edn.embarcadero.com/article/6
Note that even Delphi doesn't have them yet (it might also turn
up in Delphi in the future).
Looks as something related to:
http://en.wikipedia.org/wiki/Anonymous_function#Delphi ? If so then
this is
John Youngquist schrieb:
Interesting response.
I routinely implement large systems on the 8051 chip in assembly language
which I can write faster than Pascal. Assembly is a minimum of 500%
faster than
C on the 8051. I hate C anyway.
FPC runs also on embedded arm systems so this might be
As you might have noticed, the server running the wiki (lazarus and
fpc), the mailing lists (lazarus and fpc) and being ftp master (fpc and
lazarus snapshots) had some hick ups during the last months due to
hardware problems so we want to replace it by something more reliable
because this is one
Flávio Etrusco schrieb:
From the wiki, it's more interesting to pay in Euros, right?
Is the German PayPal only a localized version, or are they separate
corporations and I'd have to create a different account? And is there
a way to use the German site in English? ;)
Afaik not, it's a german
Thank you for all your contributions, I ordered a HP ML110 today. I'll
equip it with more hard disks and memory and by the end of march,
Charlie will pick it up so it can be installed in April.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Florian Klaempfl schrieb:
Thank you for all your contributions, I ordered a HP ML110 today. I'll
equip it with more hard disks and memory and by the end of march,
Charlie will pick it up so it can be installed in April.
Sorry for the apparently strange sending time (I just sent the mail a
few
As you can (probably) see, I would like t_barnyard to be able to create
any descendant of t_mammal. In the above example, I want it to create a
brown pig if it doesn't find one, so I tried to pass the t_pig
constructor, along with the brown parameter that said constructor will
require.
Jürgen Hestermann schrieb:
David Emerson schrieb:
I *am* checking sizes before the move, which is why it surprised me
that things were going out of bounds -- the trouble is I forgot the
array index [0]
Yes, that happens quite often. Unfortunately, Borland gave up the clear
und predictable
Jürgen Hestermann schrieb:
Florian Klaempfl schrieb:
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storage
Juha Manninen schrieb:
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the data, no more no less.
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental
Jürgen Hestermann schrieb:
Then it should be possible to use MyArray as a parameter for
move/fillchar but obviously this is not the case.
No. Because it does not mean the *array's data* but the *array*.
So it doesn't mean anything? What exactly is the *array* if not it's data?
A variable
I would suggest you checkout the latest copy of the documentation
SubVersion repository:
http://svn.freepascal.org/svn/fpcdocs/trunk
No git mirror ;)? I think the docs are one of the fpc related
repositories where using a dvcs might be useful. The entry barrier to
make changes is a lot
Felipe Monteiro de Carvalho schrieb:
Really?
Command line and OpenGL applications are no problem and even now
possible with fpc afaik. Only full gui access might require
investigation how and if fully possible.
___
fpc-pascal maillist -
But does this mean you have decided to pursue GIT if there is a DVCS to be
used at all?
No. Git was just an example.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Jürgen Hestermann schrieb:
There is a lot of ambigouity with dynamic arrays.
There certainly is if you expect them to work like regular arrays.
They are a quite different datatype.
At least it should always mean the same independent from context.
It does always mean the same, just like a
David Emerson schrieb:
I'm far more comfortable using git than svn, and if there was such a repo it
would help lower the barrier to entry for me at least.
I created a mercurial mirror: http://florianklaempfl.de:8000/fpcdocs/
___
fpc-pascal maillist
Jürgen Hestermann schrieb:
A file type is actually also a record and you cannot access the fields
without an explict type cast.
At least a file identifier always means the same memory address (where
the record data is stored). If needed (for some special purpose) I *can*
typecast it because
Frank Church schrieb:
What project management tool does FPC and Lazarus developers use? I
mean besides mantis for bug tracking?
None, simply because we don't have any time budgets/resources but people
are working as soon as they find time.
I am thinking along the lines of JIRA, Redmine,
Anthony Walter schrieb:
I was on freenode irc #fpc earlier and asked some questions but not
enough people were online to get an answer.
My question was/is:
Will there ever again come a point where FPC attempts to bring in
more compatibility with Delphi?
Nobody can predict if
Anthony Walter schrieb:
When I google search for FPC generics tohe top result links here:
http://wiki.freepascal.org/Generics
Two cases:
1) type generic TListT = class // ... as is now, the word generic is
redundant
2) type TListT = class // ... better and in line with Delphi
It
Anthony Walter schrieb:
Technical limitations aside, at this point what would be needed from the
community to get the generic syntax changed?
1) Delphi mode only
2) not breaking old code i.e. accepting both variants
3) more Delphi generic compatibility
Supposing I had the soruce
code
1 - 100 of 638 matches
Mail list logo
