r webmodules is OK.
Something like 'OnInitModule' or so ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner;
If it gets a free notification, it should pass it to all the children.
Michael.
On 08/03/2012 09:56, Martin wrote:
I found a
this quite annoying. Can someone please extend the manager to handle a
GetReaderByExt(sExt) ? Thanks!
I would be willing to do it myself but don't know if it would be accepted.
It would be accepted.
Michael.
___
fpc-devel maillist - fpc-
l-db then you can place files for example into src/sqldb/mssql folder
;-)
I will have a look and include both units.
And the dream will become true... Thanks Michael.
Any chance to merge in fixes_2_6 in short time?
Marcos Douglas
Hi Michael,
Do you have some prediction to include the sources?
w stuff ;-)
6. if there is any problem please let us know. If you decide to include
it
into fcl-db then you can place files for example into src/sqldb/mssql
folder
;-)
I will have a look and include both units.
And the dream will become true... Thanks Michael.
Any chance to merge in fixes_2_6
On Mon, 19 Mar 2012, LacaK wrote:
Hi Michael,
splitting files into two packages was unavoidable?
Yes.
As you can see for the other databases, we always keep the header imports
separate from the components. Standard time-tested practice.
Hm, although I am not happy with this, I can do
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
No.
Anyway, I change the colum names (id,name to col1, col2)
The error is:
"Cannot insert the value NULL into column 'col', t
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 8:12 PM, wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
No.
Anyway, I change the colum names (id,name to
type,
with different FPC versions.
{$H} is documented, {$IFOPT} is documented.
That's all there is.
As soon as the rest is implemented, it will be documented as well.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
se also)
L.
Yes, of course... you're right.
I have this code that worked before so, I thought something broked.
I had tested before in a different machine with other installation of
MSSQL. My mistake, sorry.
If I find some problems I can post in bugtracker or still early to do this?
--
Michael,
On Thu, 22 Mar 2012, LacaK wrote:
And will you apply also diffs to fcl-db tests ? So we can run complete
test suite ...
I will do so later today.
Michael,
I updated patch for fcl-db test suite. See:
http://bugs.freepascal.org/view.php?id=17303
Would you be so glad and will you
On Fri, 23 Mar 2012, LacaK wrote:
Michael,
I updated patch for fcl-db test suite. See:
http://bugs.freepascal.org/view.php?id=17303
Would you be so glad and will you apply them please ?
Done, rev. 20572.
As I wrote yesterday, I uploaded last patch for fcl-db test suite to
http
is issue :( How this can be? I use latest fpc trunk with no
self-made modifications, and it thinks that -Sc is not the default. Please
enlighten me on this.
As far as I can see from the source the default should be "not enabled".
I had the same problems.
C style operators are
On Sun, 1 Apr 2012, Andrew Haines wrote:
On 04/01/12 05:13, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
I was thinking about TStrings possibly having an overloaded function Add
or AddStrings where the argument is an array of string?
procedure Add(strs
ds:
{$ifdef Android}
libsqlite3 = '/system/lib/libsqlite.so';
{$else}
This is the most practical solution, just redefine the constant.
The SQLiteDefaultLibrary variable is initialized from this constant.
In case a private library is used, users can always explicitl
brary uses threads, and if a SQLite callback
is done from a different thread, then the RTL may present you with a nice error.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
et as not-modified.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
QLTypes )
But because this change is not unavoidable I am not sure if go this way or
leave it as is and definitely abandon that stSelect is 'SELECT ...' ?
What do you think ?
It is not clear to me what are you trying to accomplish with this change ?
Michael.
_
nce you don't know in detail what the statement does.
Maybe Joost can comment on this.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
einforces this hypothesis.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
matter is still under discussion on core.
Michael.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 2 May 2012, Martin Schreiber wrote:
On 01.05.2012 17:37, Michael Van Canneyt wrote:
As written before, in MSEgui I'll define a "bookmarkty" type, so
MSEgui users
have "bookmarkty" in order to avoid the warning. FPC and Lazarus
probably
can't
cheap (up from some $2.-).
And they also have very cheap development boards.
This should be perfect to test the compiler and some parts of the RTL.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
On 05/29/2012 01:20 PM, Fuxin Zhang wrote:
> By the way, I find that qemu is really very handy for test.
Great !
In fact I might be going to o projects with PIC32 some day soon. I'd be
happy to use FPC for that.
-Michael
___
fpc-devel maillist
-wise) somewhat sub-optimal (regarding most C compilers)
implementation of (on some processors/OSes) threadvars might be improved.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
to have in fpc by default, so
maybe they should be added.
What do you think?
Pending language support for parallellism, I think this is a good idea.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
I meant is that the RTL should implement e.g. TCriticalSection (and
whatever might be used to provide multi-thread libraries and/or language
extensions) using the FUTEX mechanism without needing the pthread libc
library. (Maybe this already is done.)
-Michael
__
application.
It makes you wonder why they created 2 systems in the first place...
Michael.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
resting to have a method to do this. :/
Presumably a ExpireCookie method can be added to TCookie.
This simply sets the date to the correct value.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
On Sun, 15 Jul 2012, Martin Schreiber wrote:
On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote:
On Sun, 15 Jul 2012, Martin Schreiber wrote:
Currently I need access to the following private FCL class fields because
of MSEide+MSEgui extensions:
I have looked at your list. (I sent
pport
this. Lazarus artificially forbids this too. Internally most code
supports this.
I see no reason why TWriter would not support this, because it uses
GetChildren to get the list of children ? There must be something else.
Michael.
___
fpc-devel mailli
code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should be enough to remove the need for the TFieldCracker ?
Michael.
___
fpc-devel mailli
is basically the same problem), in that case you would not need the
internal fields of TField at all ?
If that is not possible, it means you need a mechanism to 'finalize' the record
buffer
whenever it is re-filled or goes out of scope ?
Michael.
___
ed in the buffer.
The speed performance penalty of this system should be negligable, since you
assume all records are in memory anyway.
And: everything can be done without meddling with the internals of TField.
Michael.
___
fpc-devel maillis
constructed class
hierarchy.
If you don't give a detailed explanation why you need to manipulate
all these private fields outside of the proper methods, then I cannot
help you find solutions for the problems you experience, so please:
elaborate.
Michael.
__
variable ParamsClass : TParamsClass and use that whenever a
TParams instance is created.
* Or have a virtual function CreateParams which is used everywhere.
There are always other solutions.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
e, so please:
elaborate.
If I only could be sure that it is worth the effort...
Does this mean you're not even going to try ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
, FreePascal can truly shiny.
This exists already. fmpake and fppkg.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
write FCapacity; deprecated;
" to TMemoryStream?
TMemoryStream.Capacity is already read/write.
Why do you think you need direct access to the field ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
r
easier to use that technique than to request this change. There is nothing
magical about TMemoryStream.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
and you can always ask for changes that
would make this possible.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
till use ifdefs for debug messages, and have a template to quickly insert :
{$ifdef debugmsg}SendDebug('|');{$endif debugmsg}
This way, there is no extra code in my final build.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 08/15/2012 06:03 PM, Michael Van Canneyt wrote:
Fixed in rev. 22092.
22097:
Since several versions I get multiple of those:
make -C linux all
make[7]: Entering directory
`/home/mschnell/Downloads/svn/fpc/trunk/rtl/linux'
/bin/mkdir -p /home/mschnell/Downloads/svn/fpc/trunk/rtl/
On 08/16/2012 09:37 AM, Michael Van Canneyt wrote:
You must do a "make cycle" in the main or compiler directory, with as
a starting compiler version 2.6.0.
Never heard of this one =-O
What does it do ?
Usually, I do a
make cycle PP=ppcx64-2.6.0
should I PP the compiler to
On 08/16/2012 09:57 AM, Graeme Geldenhuys wrote:
ALWAYS, ALWAYS, ALWAYS USE THE LATEST ***RELEASED*** FPC TO COMPILE
TRUNK.
I see that does make sense.
Is there a chance to just put the appropriate executable somewhere
without doing a real installation ?
Thanks,
-Michael
what I did until my rather old installation of the
was not able any more to compile the sources.
But I just did not know how to get the and
install it in some other location than /usr/local/bin/fpc
-Michael
___
fpc-devel maillist - fpc-devel@lists
ith Lazarus
This does work, but i understand that this does not do any compiling.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 08/16/2012 10:27 AM, Michael Van Canneyt wrote:
Install in a temp location from the tar.gz archive, copy binary to the
place of your choice.
This one for X86 Linux?
http://sourceforge.net/projects/freepascal/files/Linux/2.6.0/fpc-2.6.0.i386-linux.tar/download
I'll give it
On 08/16/2012 10:34 AM, Michael Schnell wrote:
I'll give it a try.
Using fpc 2.6.0 I could compile the compiler, but now it does not
compile Lazarus any more :(.
I'll wait some revisions and retry...
-Michael
___
fpc-devel maillist -
s now exiting the v0.xxx state not a good omen.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 08/20/2012 11:30 AM, Mark Morgan Lloyd wrote:
for basic two-byte Unicode handling, what types should be used?
:-) *That* is part of the problem :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
On 08/20/2012 10:46 AM, Michael Schnell wrote:
long winding discussion in this forum
.. and on the Lazarus forum ...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ers regard as "equal").
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 08/20/2012 08:53 PM, Ivanko B wrote:
Really the team seems to fights to FPC + Lazarus be capable of
building thousands of Delphi based components - archivers, cyphers,
audio processors etc things which people mostly like Delphi for and
which seldom use specific Delphi features causing problems
exiting the OS / GUI
framework calls. I understand this does not happen too often.
Of course it is really nice to provide support for any Unicode encoding,
but I don't think it does not harm to use UTF-16 as a default.
-Michael (who doe not usually advocate Windows-centric develo
Sorry:
I do think it would not harm to use UTF-16 as a default.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
why I did not start porting (the said
parts of) AsyncPro.
Not to mention that sometimes things are just easier when you start
an implementation from scratch
You may be right on this.
-Michael
___
fpc-devel maillist - fpc-devel@lists
the user code. So the compiler can't force using complex stuff like that
all over the place.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Lazarus forces 8 Bits :( .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
work with any
encoding (and can be called with any encoding) without the need to do
overloaded functions or do conversions under the hood.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinf
On 08/21/2012 01:09 PM, Graeme Geldenhuys wrote:
Maybe so, but it does debunk the statement "does not happen too often".
With "not so often" I meant program runtime: it is usually not called
in a close long running loop.
-Michael
_
t use Unicode). So maybe it should not
compile myString[i] at all which will not work as expected in most cases
(at least with UTF8 and Unicode agnostic users).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
On 08/21/2012 02:11 PM, Michael Schnell wrote:
So maybe it should not compile myString[i] at all
... and provide a decent enumerator syntax instead.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
se the RTL
does not use it.
AFAIK, all the GUI related LCL calls use UTF8 in the parameters and
results. OTOH all Delphi VCL GUI calls use 16 bit string encoding in the
parameters and results.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepasca
on is String, and String is 16 Bit, so catch 21.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
zarus form some time ago I learned that there are supposed to
be decent arguments for keeping the LCL in 8 bit mode (speed with GUI
transactions in Linux) so the a move to 16 bit (or dynamically encoded)
strings is not intended.
- Michael
___
fpc-deve
lete (like with Prism). Without assessment -
this is a huge move for a native code compiler. If FPC will follow, this
sounds like a lot of work.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
the way it is.
But many LCL applications and packages would suffer.
Same issue as when Delphi made this move.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
futures, which would also be a
really advantageous feature and supposedly unique with a native code
compiler)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ts of internal
ROM and RAM and thus allows for creating a very cheap controller with a
very small chip count.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ernal work with the most
appropriate encoding.
BTW.: if the files are done in many different encodings, even using a
String type with fully dynamical encoding might be the most appropriate
solution. Another argument not completely forget about an (optional)
fully dynamically encoded string type.
On 08/22/2012 08:23 PM, Joost van der Sluis wrote:
I thought that it was possible to use environment-variables in fpc.cfg.
Sounds like a good idea :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
On 08/22/2012 07:30 PM, Ivanko B wrote:
...
You need to stop your mailer from all the time replying to the wrong
message. This makes the forum rather unreadable.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
On 08/23/2012 01:30 PM, Anton Kavalenka wrote:
It DOES NOT matter what unicode string (UTF-8 or UTF-16) would be
implemented in runtime.
OK. Lets do all in in ASM. Here a human can show his skills.
-Michael
___
fpc-devel maillist - fpc-devel
more), it seems very appropriate to have
String be a sibling of TObject.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 27.08.2012 10:51, schrieb Michael Schnell:
> If in future TObject is reference (as it might be in a future Delphi
> version, according to an Embarcadero blog) counting (and thus using
> .Free is not mandatory any more), [...]
I hope this will never happen.
ingList, TCollection)
That's a matter of documentation.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
. The answer was yes.
I've emailed Michael 2-3 weeks ago about a previous mailing list discussion
about Observer support too - which I concluded as will be accepted, Michael
just needs time to commit his changes. Adding support for Observer into base
RTL classes (not FCL). Any extra resources
ple, on my 'doubtful' list I had "ooPropertyChange", to be used in
combination with the GetPropInfo() and a call in TPersistent:
FPOPropertyChanged(Const APropName : String);
I'm still not 100 % sure what to do with that.
As for the preterit in ooChang
from
a setter.
I imagine that this could be protected with a
if not (csLoading in ComponentState) then
FPOPropertyChanged(APropName);
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ontrols in the LCL with just
the 4 messages ooChange,ooFree,ooItemAdd and ooItemDelete; That included
observing a tree.
Today or tomorrow I will commit the fpObserver unit, which contains a
basic mediator factory which I used to implement just that
"up to date" fpc compiler for as well 68K as PIC32
(AFAIK identical to a certain version of MIPS32). I doubt that I would
even be able to start, unless an up-to-date documentation of the
appropriate parts of the docu is available.
-Michael
_
Regarding the discussion of potentially providing the Delphi compatible
"String" type with 16 bit characters: What is in this case happening to
Short strings. I don't know how Delphi handles this.
-Michael
___
fpc-devel maillis
On 08/31/2012 03:21 PM, Tomas Hajny wrote:
Type ShortString stays unchanged (locale specific 8-bit character set).
Thus there will be auto-conversion when doing MyShortString := MyString; ?
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel
could follow
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
source diff. Sure it will be considered one way or
another..
That is a valid argument against improving the existing ASM code.
OTOH, for such a low-level stuff ASM _might_ provide a speed advantage.
-Michael
___
fpc-devel maillist - fpc-devel@lists
reate a descendent of TBufDataset: it is in
itself a full TDataset.
You'll have to implement the least amount of methods there, and you can see
in TSQLQuery which ones.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepasca
t, you can also look at the JSON Dataset. That is quite simple.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
to take care of everything by itself. How it
does this is ruled by custom only.
In short: Windows doesn't cater very well for the command-line.
What quoting may work for application 1, may not work for application 2.
Michael.
___
fpc-devel maillist
ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
Note that the API does not mention anywhere how quotes or spaces should be
handled.
I should specify here: for parameters. For the binary, it is specified,
because of th
ss.
On the contrary: CommandLine is marked deprecated becase it will disappear.
I have explained what to do, I will check if the documentation needs
some enhancements. But you must use parameters correctly.
Michael.
___
fpc-devel maillist - fpc-devel@lists
something else again.
Users also seemed to be unable to handle the difference between api and
shell, which also caused constant confusion.
Exactly.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
slow memory interface (regarding CPU speed) Thumb
might be faster, too.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ing code.
So I think if we go after strict RFC compliance, we should introduce a new
unit and deprecate an old one.
I agree.
Michael.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In the RTL, is there an encapsulation for finding the inode number of a
file in an extX file system ? Or dis anybody already do code for this ?
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
On Mon, 24 Sep 2012, Michael Schnell wrote:
In the RTL, is there an encapsulation for finding the inode number of a file
in an extX file system ? Or dis anybody already do code for this ?
You need to use the fpstat function for this. The stat record contains the
inode number.
Michael
On 09/24/2012 10:33 AM, michael.vancann...@wisa.be wrote:
On Mon, 24 Sep 2012, Michael Schnell wrote:
In the RTL, is there an encapsulation for finding the inode number of
a file in an extX file system ? Or dis anybody already do code for
this ?
You need to use the fpstat function for
used there is supposed to be.
Thanks again,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I did find the definition of the stat record in stat.inc, but I'm still
not unclear how to make use of it.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
OK, I did find that I need to "use" baseunix.
Funny that fpstat is there and it's not necessary for fpstatfs...
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
301 - 400 of 5273 matches
Mail list logo
