he results, I'd be grateful.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> Michael Van Canneyt escreveu:
>>
>>
>> On Thu, 20 May 2010, Florian Klaempfl wrote:
>>
>>> I've no opinion if it's usefull to add or not, I use TPersistent+ too
>>> little but my concern is: if I create an observer for an instance, I
I am trying to understand how to work with the various floating point options
available for FPC when running on ARM under Linux. I'm not to familiar with
all this so please bear with me.
Specifically I have a system comprising an TI OMAP3530: ARM CORTEX A8 running
Linaro. /proc/cpuinfo reports
2:55:08 Jeppe Johansen wrote:
> Den 15-03-2011 11:32, michael skrev:
> > I am trying to understand how to work with the various floating point
> > options available for FPC when running on ARM under Linux. I'm not to
> > familiar with all this so please bear with me.
> &
architecture.
On Wednesday 16 March 2011 12:58:00 Jeppe Johansen wrote:
> Den 16-03-2011 11:51, michael skrev:
> > So it seems fpc does not pass the correct options to as. Is there anyway
> > I can make it do so? My approach is obviously something of a hack.
>
> Not as it is currently.
ts.
Thank you again for your help.
On Thursday 17 March 2011 12:30:42 Jonas Maebe wrote:
> On 17 Mar 2011, at 10:14, michael wrote:
> > Is this a situation that is likely to change soon? With the
> > explosive growth
> > of the ARM processor in mobile and embedded devices it
On 2019-05-20 21:59, J. Gareth Moreton wrote:
On 20/05/2019 09:44, Michael Van Canneyt wrote:
On Mon, 20 May 2019, J. Gareth Moreton wrote:
While there is documentation online that can easily explain all of
this, I find it's only truly useful if you are looking up details
on a spe
is located before the company firewall.
Maybe the router drops the icmp packets.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sun, 11 Sep 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I'm a user of fpdoc, not a maintainer, have no idea of the internals.
In that case, please do not say things like
'this extension should not be too hard to implement'
But please, file a bug rep
On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote:
No Latex support here (Win7)
Virtual Box is your friend :-) .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote:
I'd add another 100€ for reasonable debugging support in Lazarus :-)
Could you generate a wish-List ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
would need the debugger to run
the program completely in single step mode and after each step check the
condition.
- Object Pascal expression evaluation
A think object pascal expression evaluator software is available in
Pascal source code so this should be doable.
-Michael
On 09/12/2011 01:15 PM, Martin Schreiber wrote:
gdb uses hardware watchpoint support if available.
That seems hard to beat when doing a new multi-arch debugger
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
y FPC has what kind of
hardware data-breakpoint support. I suppose this is a very complex list).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
under test and communicate via some byte-stream interface
with a user interface. This given, remote debugging should not offer any
additional challenge and a command-line interface is the obvious
starting point before doing a complex GUI (e.g. integrated in an
ming 2.6.0
release.
You can use PtrInt, which has been in FPC since ages and which serves the
same purpsoe.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
lename part' of paramstr(0)
I have adapted the docs.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
g the OnGetApplicationName callback."
It should say 'filename part' of paramstr(0)
I have adapted the docs.
By the way, the second paragraph in the help already contained this info.
But I've been more explicit.
Michael.
___
fpc-dev
arted sitting on the API)
for testing the debugger, for use in a batch, and "just in case"
somebody does not use an IDE, is very appropriate.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailm
work with
the g* team(s) to have gdb (or gcc) provide Object Pascal specific
features :-( .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
is, I would vote for a gdb extension
instead of creating a completely new debugger from scratch .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/13/2011 02:09 PM, Joost van der Sluis wrote:
Very well said !
Thanks,
-Michael (who does a lot more ANSI C than Pascal, as this is necessary
with embedded controllers.)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
Sounds good !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
One with unicode string, one with ansistring. They will have the same code,
but will be compiled twice, each time with a different compiler define to
decide which version it
On Wed, 14 Sep 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
wrote:
Current strategy on fpc core seems to be to have 2 RTLs:
One with unicode string, one with ansistring.
Isn't that somewhat nasty for people currently using UTF-8?
No
.
2. Backwards compatibility is a big concern.
Code that compiled and worked should compile and work.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 14 Sep 2011, Graeme Geldenhuys wrote:
On 13/09/2011 21:23, Michael Van Canneyt wrote:
Current strategy on fpc core seems to be to have 2 RTLs:
One with unicode string, one with ansistring.
Can you clarify a bit. When you say "unicode string" to you mean UTF-16
(Delphi&#x
cess
to a dedicated variable.
Moreover the MMU programming and interrupts will be consumed by the OS
and a user space program can't even see it.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailm
.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
cific information (RTTI...).
If this is true, why discussing replacing gdb ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/14/2011 08:50 AM, Felipe Monteiro de Carvalho wrote:
All Linux distributions that I know use utf-8
Android uses utf-8
Meego uses utf-8
AFAIK, the EXT system does not care about the code the file-name
byte-arrays are done in. only 0x00 (end of name) and '\' are interpreted.
On 09/14/2011 01:01 PM, Michael Schnell wrote:
AFAIK, the EXT system does not care about the code the file-name
byte-arrays are done in. only 0x00 (end of name) and '\' are interpreted.
Sorry, (typing too fast again)
Only 0x00 (end of name) and '/' are interpreted
ith "long filename FAT" I fear it's quite complicated (e.g. short and
long file name of a file need to be recognized as identical). But no
unicode here.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
. e.g.:
Old programs assuming local ANSI 8 bit code retrieved from LCL GUI
components, compiled with the new version don't work (e.g. if doing
myChar := myString[3]; )
Doing My16BitString = 'my constant text containing umlauts as äöü';
provides an erroneou
only the page size.
Do you think this is possible without rewriting the OS (for all
supported OSes)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7, Linux ?)
Thanks,
-Michael
-tools) to make it
usable for their own needs (iDevice debugging support).
Yak !
Is a reunification in progress ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/14/2011 05:02 PM, Hans-Peter Diettrich wrote:
The NT WinAPI (not 9x) *implements* everything in the Wide (UTF-16)
routines
without reference-counting: Yak !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
character coding and just works on byte arrays.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
heir content is done in and do automatic conversion when
necessary.
I was told this does help in many situations but produces confusion and
incompatibilities in others.
The FPC "cpstrnew" implementation seems to be stalled right now.
-Michael
On 09/14/2011 05:19 PM, Hans-Peter Diettrich wrote:
Can you specify, *which* strings ever *require* platform specific
encoding?
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
-Michael
___
fpc-devel maillist -
should not be forced to
know), that (s)he is a "Unicode User".
A good programming system should hide this "deeply technical stuff" as
far as possible. Otherwise we can go back to ASM programming.
-Michael
___
fp
but there still are some hard to
handle double-DWord codes plus the memory usage is huge.
So Delphi NewStrings (cpstrnew) and a 32 Bit Char type seems like the
most user-friendly way to go. (But of course eating a lot of performance.)
-Michael
NewDelphiString" Type or different types for different coding
variants.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/15/2011 10:43 AM, cobines wrote:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of encoding.
MyChar is an 8 bit thingy and thus is not even able to hold a Unicode
'ä' (in what ever UTF).
On 09/15/2011 11:08 AM, Graeme Geldenhuys wrote:
+1 on both counts.
Hoping for complex things to automatically be solved by just ignoring
the complexity usually leads into hell.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
quot; even in times
of Unicode.
How is that 'Öse' entered into the system.
I was assuming a current Lazarus version as an IDE and here UTF-8 is
used. (older Lazarus versions in fact did use locale ANSI code, thus
supporting the "generations of pascal programmers")
-Micha
On 09/14/2011 07:24 PM, Hans-Peter Diettrich wrote:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character.
"Unicode" is 32 Bis and allowing for (nearly) any supported character.
So a 32 Bit UnicodeCharacter in fact is very viable.
stay with Ansi. There is no automatic switch your
application to Unicode.
If thy use Lazarus they are forced to use Unicode unless they wand to
stick with a very old version.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepasca
On 09/15/2011 11:43 AM, Martin wrote:
Which imho makes utf8 far more preferable than utf16
in UTF8 the error is bound to happen
ROFL.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
On 09/15/2011 12:41 PM, cobines wrote:
I don't know if in Delphi you can use just Ansi,
Delphi is a completely different matter as (by default) old versions use
ANSI and new versions use Unicode in NewDelphiStrins with dynamic encoding.
-Mi
type). But I was told there are
some.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
g ANSI.
So the only user friendly solution seems to be _not_ to provide "simple"
language features that deal with code bytes instead of Unicode
characters _at_all_.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/15/2011 07:39 PM, Hans-Peter Diettrich wrote:
Only when an application must *interpret* strings in foreign languages,
With UTF-8 German is such a foreign language :(
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
ot; (as would migrating to cpstrnew, but with less
possible performance degradation).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/16/2011 07:36 AM, cobines wrote:
Currently UTF8String is just an alias for AnsiString,
Which obviously is bound to produce a lot of confusion UTF-8 code in a
thing explicitly called "ANSIString" ???
-Michael
___
fpc-devel mailli
rk in ANSI mode.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ot; (as would migrating to cpstrnew, but with less
possible performance degradation).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ppropriate ANSI variant.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
t not doing new
strings at all, as they don't completely solve the problems they are
supposed to solve. This finally would cancel Delphi compatibility - may
this be a problem or not. )
-Michael
___
fpc-devel maillist - fpc-devel@lists
On 09/18/2011 06:49 PM, DaWorm wrote:
But isn't it O(n^2) only when actually using unicode strings?
Allowing the compiler or library decide _if_ this is a Unicode string
would require either a dedicated sting types for each encoding or "New
Strings" with programmable encod
On 08/05/2011 09:47 PM, Marcus Sackrow wrote:
...
Hi Marcus,.
Any progress ?
I understand that for Amiga you need an 68 K (cross compiler) version
of FPC.
I'd be interested in same, as well.
Any progress here?
___
fpc-devel maillist - fpc-dev
On 09/26/2011 03:21 PM, Sven Barth wrote:
Pre-4.x versions of AmigaOS supported 68k, newer ones support only
PowerPC. Also AROS seems to be mainly based on x86 and PowerPC (a port
to 68k exists though). So 68k does not seem to be necessary.
So I seem to be out of luck :( :)
-Michael
string type, and
then check
a) what is still needed. Maybe we will have solved it for you.
b) whether it should not be put in the RTL instead of a separate package.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
our routines in
lazarus CCR in the meantime.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tue, 4 Oct 2011, Alexander Klenin wrote:
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt
wrote:
There is, again, a continuum between careful development and stangation.
While acknowledging great work that FPC team has done on the former,
I'd venture to say that is came uncomfor
) ?
Do I understand correctly, that with theses strings automatic conversion
between different string encodinge (e.g. locale based ANSI <-> Unicode
and UTF-8 <> UTF-16) is provided in the RTL ?
-Michael
___
fpc-devel maillist - fpc-deve
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
I wonder when Lazarus will be able to follow
ehalf, but I also know that
Delphi provides a lot of traps for users converting their "ANSI"
projects to use NewStrings (even if they don't need Unicode at all).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
ourse auto-conversion in the user code might slow down certain
programs hen the user somehow forces a certain coding. And inappropriate
user code might implicitly rely on a certain internal coding of a string
and work only on a certain OS.
-Michael
__
I understand that Lazarus will not be able to run with the "NewString"
version of FPC.
Semmingly it can't even be compiled.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
current "UTF-8 code stored in a variable of a
type called ANSIString" paradigm" (please correct me if I'm wrong).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
directly at the OS /
Widget-set - interface. Same might or might not be UTF8. I don't see why
the LCL should force anything else to a certain encoding (such as UTF-8).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
all projects and do away with types like ANSIString,
utf8string etc.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/11/2011 12:23 AM, Martin wrote:
Utf8ToLower is, (and should) be declared expecting a Utf8String.
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
With dynamically encoded Strings "ToLower" should work for any encoding.
the byte (or
Word or DWord) array content.
I suppose, as a low-level programmer you can do this in a similar way as
you can access the reference counter.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
user code - hopefully could be
even more compatible to the long gone pre-Unicode version.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ea, the goal should be to
everywhere use the dynamically encoded basic new string type and have
the private type be an alias to same.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
) encoding. When
manipulating partial strings and assignments get the encoding of the
original string, when comparing strings, conversion is done automatically.
For speed, the user might want to do his code appropriately (e.g. by
anticipating conversions).
-Michael
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions are required when used with strings
is bound to happen.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/11/2011 11:05 AM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
Afaik it does, but only for ansistring.
What exactly is "ansis
necessary.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/11/2011 11:30 AM, Paul Ishenin wrote:
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
Encoding RawByte as w
On 10/11/2011 08:52 AM, Hans-Peter Diettrich wrote:
It does *not* help, because SetCodePage does a string *conversion*,
Nope.
procedure SetCodePage(var s : RawByteString; CodePage : TSystemCodePage;
Convert : Boolean = True);
So it can be set to do a conversion or not to do it.
-Michael
g ID has not
been changed ) or by using SetCodePage.) I suppose there also is a
function that is done to do a "pure" code-ID preserving assignment.
I suppose a variable of the type "String" is pre-loaded with the
predefined "System" encoding ID.
-Michael
__
certain
encoding is a lot faster than any re-encoding.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ach string variable has it's own dedicated encoding ID and can't
point to that of another string.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The last answer was to
On 10/11/2011 09:37 PM, Hans-Peter Diettrich wrote:
When a string is assigned to an RawByteString, both point to the
original string, which has a valid (non-raw) encoding.
-Michael
___
fpc-devel maillist - fpc-devel
On 10/12/2011 10:09 AM, Paul Ishenin wrote:
12.10.2011 16:03, Michael Schnell wrote:
I suppose a variable of the type "String" is pre-loaded with the
predefined "System" encoding ID.
If you mean "AnsiString" then it is loaded with encoding 0 which means
defaul
the "TAnsiRec", such a "New String" not only has an
encoding ID, but also an "ElementSize" specification.
So an "ANSIString" that uses the TAnsiRec for it's implementation
obviously is capable of holding of 1, 2 and 4 byte encoded data.
-Michael
On 10/12/2011 01:53 PM, Hans-Peter Diettrich wrote:
All AnsiString types have an element size of 1, UnicodeString has 2
and UCS4String has 4 bytes per element.
Disregarding whether or not this makes sense: what technology enforces
this (e.g. Compiler Magic or RTL) ?
-Michael
On 10/12/2011 01:45 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
So target encoding ID "0" means that " := " will preserve the
encoding of the source and set the target appropriately without doing
a conversion.
No. Codepage 0 stands for the system encodi
rence
counting features) is independent from the encoding ID, that is part of
the string management record and not of the data array.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
source encoding
ID <> 0. (very clever, but not easily understandable)
.-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/12/2011 12:09 PM, Hans-Peter Diettrich wrote:
Right, the new string types are *strict* types,
That does make sense regarding Pascal's general "strict type" paradigm.
-Michael
___
fpc-devel maillist - fpc-devel@lists.free
ask is what happens, if I disregard this, e.g using
the "wrong" String type as a parameter when calling a function or when
using "SetCodePage" in a "creative" way. What about Type casting ?
-Michael
___
fpc-devel maillist
part of the management
record.
That is exactly what I wanted to say.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ch doesn't support these
characters (same as before).
Of course.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
1 - 100 of 5266 matches
Mail list logo
