On 3-10-2011 13:45, Felipe Monteiro de Carvalho wrote:
Also not a solution, because then fpvectorial and fpspreadsheet would
not be able to compile in other RTL modes.
What? You mean you are seeking the solution upstream? Seems
the design of those units is lacking.
_
On 9-10-2011 22:34, Martin wrote:
-gc, is apparently only useful in very limited scenarios, such as
applications, that have no interaction with the OS at all, or can
otherwise gurantee, never to access any memory that was returned by
(and therefore allocated by) the OS.
No, it only means allo
On 1-11-2011 15:07, Jonas Maebe wrote:
On 01 Nov 2011, at 12:30, Michael Van Canneyt wrote:
The timezone itself does not change, unless you physically move the machine
from, say, Belgium to Russia.
This happens regularly with laptops (and at least I almost never shut down my
laptop when trav
Gentlemen, gentlemen,
Stop this.
Every proper software clock == UTC, not local time.
The local time should always be on read time, on the fly.
Thaddy
On 2-11-2011 11:48, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
Anyway: a function that reports the local time is
Did anybody mention gettickcount is documented as microtiming?
And should not be expanded?
On 3-11-2011 9:57, Marco van de Voort wrote:
In our previous episode, zeljko said:
So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
linux, bsd and others, and in that case we can have
Withdrawn.
It is only partially true.
Still it can not be expanded and can overflow easily.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
mode?
Or with a bit more logic, shouldn't those options be excluded by $mode
delphi and -Mdelphi?
Or if this is inconvenient something like $mode strictdelphi?
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
On 29-11-2011 15:46, Jonas Maebe wrote:
Possibly, but it would also require RTL changes (the FPC system unit
contains many types, constants, variables and functions that do not
exist in Delphi -- and for programmers the difference between the
language and the system unit is often not very clear
BTW I am aware I can solve this at the sourcecode level with defines - I
just did that -, but would prefer one of my suggestions.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 29-11-2011 16:54, Felipe Monteiro de Carvalho wrote:
mode delphi is used in a huge amount of code, so any break in
backwards compatibility here would be extremely unwelcome. It surely
would break a lot of code that I wrote. But yes, $mode strictdelphi
looks like a good idea if you want to im
On 29-11-2011 18:49, Tomas Hajny wrote:
Which Delphi version would be the supposedly supported one? If this is
not explicitly defined, compilation might still fail when people using
lower Delphi versions try to compile the code. Do you really want to
track the feature set (especially for smalle
On 29-11-2011 21:53, Jonas Maebe wrote:
It actually perfectly describes what you want to do, be it only
regarding things that can be checked by only relying on the compiler.
I'm not sure whether the limited applicability of such a feature
(mainly usable if you don't use, like you, the standard
A region is not a rect. A rect is a special case of a region.
The question was about the rect. There are region manipulators
Xplatform, I think.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-
On 9-12-2011 14:02, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce
it
On 27-1-2012 17:25, Marco van de Voort wrote:
In our previous episode, Kornel Kisielewicz said:
{$apptype console}
Type
TLIST=class
end;
type
Ta= TLIST;
TB= TLIST;
This may very well be a (semantics) bug in Delphi.
Did you put this to Embarcadero?
IMO a type Ta<..> should
On 6-2-2012 17:54, Felipe Monteiro de Carvalho wrote:
The related bug tracker item is:
http://mantis.freepascal.org/view.php?id=21114
IMO This should not be done that way (at all):
MS does it by respecting the PE flag for unicode and expects strings
accordingly: If the PE says it's unicode, a
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote:
The Microsoft way is not the same as the Free Pascal way. We are not
required to immitate them when implementing our routines. The
Microsoft way has nasty side effects: 1> makes it impossible to
support Unicode and support Windows 9x at the
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote:
The Microsoft way is not the same as the Free Pascal way. We are not
required to immitate them when implementing our routines. The
Microsoft way has nasty side effects: 1> makes it impossible to
support Unicode and support Windows 9x at the
On 6-2-2012 20:21, Sven Barth wrote:
Out of interest: Which flag are you talking about? Because I'm not
aware of any such flag.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
On 6-2-2012 21:04, Craig Peterson wrote:
In C on Windows the UNICODE symbol controls whether undecorated
functions should use the A or W versions, and what the TCHAR symbol
translates to.
This exactly the case and I do noy suggest this to be dropped. (This is
not only C but also FP-C btw)
The
On 6-2-2012 21:07, Sven Barth wrote:
The check you are talking about in C++ is a compile time define that
just switches the defines for e.g. CreateProcess to CreateProcessW or
CreateProcessA (depending on whether UNICODE is defined or not when
including the Windows headers).
There is no oth
On 6-2-2012 21:04, Craig Peterson wrote:
Delphi does the same thing, except the change was built into the
language, rather than done using a conditional symbol, and the A or W
decision was hard-coded rather than wrapping them in {$IFDEF UNICODE}
blocks.
I am not sure about this, (I do not know
On 6-2-2012 21:35, Sergei Gorelkin wrote:
06.02.2012 20:39, Felipe Monteiro de Carvalho пишет:
So, this is basically a first step of locking Windows RTL to use utf-8
by default and reducing chances it ever will call 'W' API without
conversions?
That is another point that worries me too. Windo
Of course, KOL is a framework, not a compiler.
I merely want to state it can be done in a proper way.
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/l
On 6-2-2012 21:41, Sven Barth wrote:
But in FPC you'll need to recompile the Windows RTL if you want to
have UNICODE defined (thus having e.g. CreateProcess default to
CreateProcessW instead of CreateProcessA). In C you just include the
header with the define either defined or not.
Nope, aga
On 6-2-2012 22:14, Sergei Gorelkin wrote:
under 10KBytes
Any decent code under 10k is interesting
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/
On 6-2-2012 21:30, Thaddy wrote:
UNICODE} blocks. I propose FPC follows a similar strategy.
We already did it for Kol, which has a (almost) totally opaque
KOLstring/char type depending on switching on
Meaning/implies: when you are the compiler guardian/owner you can simply
enforce string to
On 7-2-2012 12:20, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
That depends on decisions still to be made. If we also support 1-byte
RTL, it will still be on the level of winNT. But I do think that a
win9x vs winnt split is unavoidable in time. Specially since
AFAIK! and tested today, and only for kolce and fpc 2.5.1 wince works.
Anything newer doesn't. (No wince above 6.5)
I have no clue if it is the compiler or the libraries yet.
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel mailli
On 11-1-2013 11:54, Jy V wrote:
So the options are either to do cross compiling (with Lazarus) or
to install FPC on the target and compile the code there.
What is the more viable way ?
IMHO use virtual machines:
Most of my customers run vmware sphere on their servers. I only have
On 11-1-2013 12:07, Michael Schnell wrote:
I don't see how I could install Lazarus on the QNAP, as there is no
GUI / Widget system at all.
I was told that on the Raspberry Pi, QT can be run, but that it is
dead slow.
-Michael
___
fpc-devel maillis
On 6-2-2013 12:13, Henry Vermaak wrote:
What I'm trying to say with this (admittedly contrived) example is
that when you are forced to read the docs to find out which functions
you can use for converting numbers to strings, you'll probably
discover functions like Format. At least in my case, th
{$MODE SUBJECTIVE} is more appropriate in this discussion.
But i am by -first - education a political scientist.
On 6-3-2013 15:44, Michael Schnell wrote:
On 03/06/2013 02:37 PM, Sven Barth wrote:
What exactly do you mean?
we already have:
{$MODE FPC}
{$MODE OBTP}
{$MODE DELPHI}
{$MODE OBJFP
On 8-4-2013 14:49, peter green wrote:
Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine
on Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have
compiled it on g
For example a good breakdown in
http://blog.synopse.info/post/2013/05/11/Delphi-XE4-NextGen-compiler-is-disapointing
This is by no means the only complaint about the latest "string"
whatever it is supposed to be. ;)
Thaddy
___
fpc-dev
On 24-6-2013 17:15, Michael Schnell wrote:
Karlheinz said on the Phone that the boots in some 10 seconds to
the command line when using the original Angstrom Distribution and at
least 20 seconds when using Debian.
-Michael
___
fpc-devel maillist
On 2-7-2013 0:47, Michel Catudal wrote:
I find smaller devices like the AVR32 and PIC32 more appropriate for embedded
system. ARM devices with Linux are more for use with video. The Pi is a bit
slow on graphics so I came to the same conclusion as many that it is more
usefull using ssh. I can r
t don't forget FPC is a viable compiler and
Lazarus is a viable IDE for the Raspberry Pi. And the history of Pascal
has a strong educational background.
And on the RPi it has about 2.000.000 times more potential to find
Pascal converts then the measely sales figure
On 2-7-2013 13:52, Jonas Maebe wrote:
Hi,
Can this discussion about the pros and cons of various ARM-based
boards please be moved to fpc-devel? This discussion is completely
unrelated to developing FPC itself.
Thanks,
Jonas
FPC mailing lists admin
_
On 2-9-2013 19:51, Sven Barth wrote:
Every other developer of FPC will tell you the same: The only
supported version for compiling a development (2.7.1) or fixes (2.6.3)
version is either the last release (2.6.2) or a development/fixes
version of the same revision and nothing else.
2.7.1 de
On 3-9-2013 12:06, Jonas Maebe wrote:
On 03 Sep 2013, at 11:56, Thaddy wrote:
For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap
with OVERRIDEVERSIONCHECK=1
I think that is a perfectly viable option.
It is not, as evidenced by the fact that about 99% of this t
On 3-9-2013 12:24, Marco van de Voort wrote:
In our previous episode, Thaddy said:
Your answer is to the point and right.
It is of ultimate importance, though, that the compiler options for
armXX have changed considerably since 2.6.2/3.
For my Friday toys (Pi's) I use 2.7.1 with the ne
On 13-9-2013 16:19, Michael Schnell wrote:
OK. So no technical problem, just some silent days :-) .
-Michael
I may suggest a currently non-unicode encodable code page was used for
the mailing list since the major change?
EBCDIC?
smime.p7s
Description: S/MIME Cryptographic Signature
_
On 18-9-2013 10:08, Michael Schnell wrote:
*If the event queue is empty, **CheckSynchronize w**aits for an event
to be pushed by a TThread or for /timeout/ Milliseconds to pass. If
timeout is 0, it waits forever.*
In the context of a wait a wait forever given a value of naught , this
is pretty
Even that is TSR based, not a real multi-tasker.
Under DOS a process can be swapped out and re-activated by a hardware
interupt, either f.e. a timer or the keyboard.
So, at most, co-operative multi-tasking in the sense that multiple
processes can run at the same time.
Because DOS is non-re entra
Marco van de Voort wrote:
Neither do I.
While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.
Just to make a small point: the choice
Jonas Maebe wrote:
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler
Giuliano Colla wrote:
I've never found the C++ way (Button->Click) more telling than FPC way
(Button.Click), on the contrary I find it cumbersome, but of course
you're free to think otherwise.
Huh? Button.Click is perfectly legal in C++... Although it does not mean
a dereference, but a dire
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Yes, but.. As I hinted before that is because COM is reference counted
on an intermediate level by a certain OS. A simple (but performance
cost) change of the memorymanager can fix that for th
Jonas Maebe wrote:
If you change the behaviour of "out" so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the "out rec"
parameter into "var rec".
Then this is definitely not a sextopod but
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between "var" and "out" then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
Yup.
___
fpc-devel maillist - fpc-devel@lists.freepascal.
Nikolai Zhubr wrote:
I'd guess this would require huge work and substantial modifications
to the language though.
The compiler then has to assert all possible codepaths... Do you think
that's a viable option?
___
fpc-devel maillist - fpc-devel@lists
How does your patch handle this? :
if a then
if b then
DoSomething;
else
DoOtherThing;
Syntax error
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Aleksa Todorovic wrote:
else is handled as part of "if b then" -> the closest preceeding if:
This would break almost all my code.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
As well as both
if a then
DoSomething
else
DoOtherThing;
and
if a then
DoSomething;
else
DoOtherThing;
At least to me they are :-)
This "feature" is so unclean and so poorly informed about WHY the ; is
a part of the language.
First of all, Pascal is not a line based language.
On 6/9/2010 9:26 AM, Graeme Geldenhuys wrote:
In the bug report is a patch.
http://bugs.freepascal.org/view.php?id=16682
Regards,
- Graeme -
It's not a bug. Plz withdraw (0..9)(1..10?)
___
fpc-devel maillist - fpc-devel@lists.free
On 6/9/2010 5:07 PM, Mattias Gärtner wrote:
* KOL probably has it's own too
no
Yup, no.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hans-Peter Diettrich wrote:
Memory management can not normally be parallelized.
What's this then: http://topsoftwaresite.nl/ You are talking cows dung.
It is actually in production at one of the largest stockbrokers in Europe.
You should have written : "It is hard to do parallization"
The lin
Michael Schnell wrote:
On 07/13/2010 06:27 PM, Jonas Maebe wrote:
b) indeed also because of the searching for filenames with different
cases.
It might sometimes indeed make sens to not be forced to use the same
name for the unit and the file containing it's source code.
So using "in" with ju
Marco van de Voort wrote:
In our previous episode, Thaddy said:
Ok, you write always cheerful, I was merely pointing out it is not
clean, but useful :))
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
A fact has nothing to do with emotions. Check that code. Then write a
review.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
That's not a test. A) 32/64 and B) You should test parallelization, i.e.
threads over multi processors (pref quadcore or more) to see the effect
of topmemory vs the rest.
Try the included test from topmemory. It is in no way biased, but shows
what every manamers bottleneck is.
__
On 27-10-2010 14:32, Birger Jansen wrote:
Hi all,
I have the following code that throws an error in FPC and runs fine in Delphi:
procedure TForm1.BitBtn1Click(Sender: TObject);
var
MyStringGrid: TStringGrid;
begin
MyStringGrid := TStringGrid.Create(nil);
try
MyStringGrid.RowCount
at is syntactically correct for
Delphi.
Btw, I have worked around it by changing this for kol.pas by hand.
Is this a documented issue or should I submit a bugreport?
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Is this a documented issue or should I submit a bugreport?
Can you please provide an example? The following code compiles for
2.4.0, 2.4.2rc1 and 2.5.1 (from the weekend):
Regards,
Sven
I will try to isolate it. kol.pas is a little fat bastard :)
_
Small example, 2.5.1 trunk from today
---
program Project2;
{$APPTYPE CONSOLE}
uses windows;
{$DEFINE SHOULD_COMPILE_IN_FPC } // add dot after "{"
{$IFDEF SHOULD_COMPILE_IN_FPC}
type
PPValueA = ^TPValueA;
PPValue = PPValueA;
pvalueA = packed record
pv_valuename: PAnsiChar;
efforts, I will report the actual cause of the issue.
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ith FPC, you can do something about it, like with the GNU
compiler set. That one is also prone to a lot of "features", btw,
especially cross platform.
Just my two cents. Euro cents are used only virtual anyway.
Thaddy
___
fpc-devel mai
Marco, there has been a Bhoem GC for delphi on my website for many years
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12-11-2010 13:07, Marco van de Voort wrote:
In our previous episode, Thaddy said:
Marco, there has been a Bhoem GC for delphi on my website for many years
Please add it to the wiki, together with whatever experiences you have with
it.
___
fpc
On 13-11-2010 20:56, Hans-Peter Diettrich wrote:
The comparison in the UTF-8 string example is very questionable. First
ch(i) is not equivalent to ch, not even closely related, and the claim
of O(N^2) operations deserves an proof - IMO it's simply wrong.
Yes, this caught my eye as well: O(N^
On 14-11-2010 13:22, Vincent Snijders wrote:
would be evaluated every time. S
the O(N^2) stems from the fact that it is hard to get the ith
character in a a UTF8String in O(1). Suppose it is o(N), then the loop
is O(n^2).
Vincent
"Hard to" is implementation detail and not part of any algorithm.
finalization and adapt
heap.inc and do a make clean/make all?
Tobject descendants may require finalization before the garbage
collector cleans them, hence my question.
Or do I need more steps?
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel
On 15-11-2010 10:22, Vincent Snijders wrote:
Maybe I did not understand Thaddy, but to give you O(1) access to the
ith character, I was thinking about a a translation table of the utf8
string, with key=index (1..length) and value=offset in bytes to the
ith character. Such a translation table
On 15-11-2010 14:50, Marco van de Voort wrote:
Oh. Am I supposed to do that? :-)
Yes, please :-) , but others are welcome...
(I just collect info about this subject because it is a recurring white
elephant. Regularly there is talk about it, but nobody has seen a working
implementation, and no
On 15-11-2010 14:59, Michael Van Canneyt wrote:
You must finalize, because ref. counting of interfaces etc. need to be
taken
care of. Interfaces may live outside the FPC memory space, and are
therefor
not accessible to the GC. If you want to let the GC collector handle all
that, you're in ess
GC'ing (my rather ambitious goal) FPC version.
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
even in a
asynchroneous context..
On 16-11-2010 4:12, Hans-Peter Diettrich wrote:
Thaddy schrieb:
Actually, I am *calling* the destructor in the finalizer, not copying
it. AFAIK this should take care of it.
IMO destructors and finalizers are mutually exclusive, I remember a
note like &quo
On 17-11-2010 10:01, Michael Schnell wrote:
On 11/15/2010 02:04 PM, Thaddy wrote: ...
If you want to extend a compiler to allow for garbage collection,
would it not be appropriate to have it manage an additional type of
variables that is supposed to be "garbage collection enabled"
ace
and I would not be surprised at all if the Boehm GC would perform equal
or better after the removal of this sub allocator.
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
suggests something like we have in KOL. But that is there
for other reasons: no class ;-)
Is anyone doing anything in converting KOL to 64 on their own? We would
be interested and share our efforts, since there is a lot of demand from
the community.
Regards,
Thaddy
On 24-11-2010 21:32, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Anton Kavalenka wrote: Get stdout handle
(duplicate it under linux),
create pipe,
replace the stdout (keeping the old stdout) for current process with
write handle of pipe,
There are following problems with FPC
Under Wind
No, it will not be thread-safe. You'll have to do it over and over
again for
each thread.
I have some code by Peter Below on archive for that, that also works
on FPC win. The implementation part of that unit can be adapted for
nixen.
the file is called streamio.pas and can be easily found on
On 25-11-2010 9:21, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
No, it will not be thread-safe. You'll have to do it over and over again for
each thread.
Just curious:Why not? I thought it was safe if you flushed before you created
threads?
Writing to t
On 25-11-2010 9:49, Marco van de Voort wrote:
solid solution. *without* the rewrites :)
IIRC there is a pointer in the filetype that points into the buffer.
(bufptr). Just copying that means they still point into the same pointer.
___
Yes, They (input,
On 25-11-2010 10:24, michael.vancann...@wisa.be wrote:
They are threadvars in trunk:
ThreadVar
ThreadID: TThreadID;
{ Standard In- and Output }
ErrOutput,
Output,
Input,
StdOut,
StdErr : Text;
Michael.
___
That's not Delphi co
On 25-11-2010 10:46, Anton Kavalenka wrote:
How to reinitialize RTL to have new threads started with working
output file (i.e. without need of rewrite).
regards,
Anton
In Delphi it works - with a critical section - without re-initialization
because it's var,
In FPC there's no easy work-aro
On 25-11-2010 10:52, Anton Kavalenka wrote:
?? 25.11.2010 11:39, Thaddy ???(??):
Yes, How "standard" is standard? when you make it a threadvar.
Should I submit a bug report? It seems like I should:
Because the file drivers allow for redirection anyway and with g
On 25-11-2010 11:01, Jonas Maebe wrote:
On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
Due to incompatibility of RTL between FPC and Delphi my capturing
tricks not work.
BTW what the real reason to make these files as threadvar?
To prevent multiple threads writing to stdin/stdout/sterr at
To quote some fiction: "There can be only one."
In the context of stdxxx.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25-11-2010 11:08, Michael Schnell wrote:
But what are the instances for threads connected to ?
This is - should be - opaque.
Regard,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
al to ask
for FPC compliance.
AFAIK it should be a lock, and a lock written by the programmer.
It should definitely not be a threadvar in my opinion.
Hey, It's Friday!
Regards,
Thaddy
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25-11-2010 20:15, Anton Kavalenka wrote:
At 25.11.2010 19:57, Jonas Maebe wrote:
On 25 Nov 2010, at 13:21, Jonas Maebe wrote:
the std streams should be on a per process basis (implementation as
var), not on a per thread basis (Iimplementation as threadvar).
Not only is this not Delphi compl
On 25-11-2010 18:57, Jonas Maebe wrote:
Actually, that won't work because the different threads will then work on a
common buffer but with distinct pointers into it. A better solution is probably
to do this in the intialisation code of each thread instead:
{$ifdef unix}
fpclose(ttextrec(st
On 29-11-2010 10:36, Michael Schnell wrote:
On 11/29/2010 10:25 AM, Marco van de Voort wrote:
Do you use 2.4.2 as starting compiler?
I used the latest compiler I was able to install successfully:
Free Pascal Compiler version 2.5.1 [2010/11/22] for i386
Trunk (i.e. 2.5.1 and higher) should be
On 29-11-2010 19:33, Sven Barth wrote:
Just thinking: wouldn't objects in FPC achieve the same as
records-with-methods in Delphi? If objects would be extended with
"sealed" even the "sudden vmt" problems mentioned some time ago would
be gone with simple objects-simulating-delphi-records-with-
On 29-11-2010 20:31, Sven Barth wrote:
You are aware that I'm talking about "object" (the old TP style OOP)
not "class" (the Delphi style OOP)? "object" is deprecated in Delphi
since I don't know how long, but in FPC it's still maintained and even
extended.
But what do you mean with "elegan
There seem to be a couple of stringresources missing in sqldb.pp latest
checkout, make clean, make all
/FPC/2.5.1/packages/fcl-db/units/i386-win32 -di386 -dRELEASE sqldb.pp
sqldb.pp(765,32) Error: Identifier not found "SCommitting"
sqldb.pp(779,37) Error: Identifier not found "SCommitRetaining"
The resourcestrings are in dbconst, and I forgot to commit that. This
has been fixed meanwhile.
Tnx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sorry if this is already picked up as it IMHO should have been. I missed
some mails due to a server crash.
Today I encountered a similar issue with using threadvars for the input,
output and err variables in system when trying to use the input as a
win32 sync handle with the CreateFile API. Fa
1 - 100 of 216 matches
Mail list logo
