On 04/08/2013 07:02 PM, Mattias Gaertner wrote:
I guess, you mean encoded string types.
AFAIK, you can just create string variables of the appropriate coding
type and an assignment will do auto-conversion.
-Michael
___
fpc-devel maillist - fpc
he perfectly
normal complexity of Unicode.
If I understand Michael right, there will be some "implicit functions"
for that. I wonder how they work.
This is what Delphi compatibility dictated. (You might read the Delphi
XE Docs on how to code Unicode enabled Delphi source.)
I do hope,
g/devel/fpc/rtl/units/arm-embedded/lpc8xx.s:71: Error: Thumb
does not support conditional execution
Can anybody help?
Thank you,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sorry, please ignore thismail, this is my fault, I have an error in the
cortexm0_start.inc code, sorry!
Am 20.04.13 22:12, schrieb Michael Ring:
I have created some units for nxp cortex-m0 cpu's and have integrated
them into the arm-embedded rtl
but they fail to assemble, seems tha
lso had a look at the changeset for avr-embedded, there were a
lot of changes in the codegen and other places, do you expect that the
same will need to be done for mips or was avr a special case?
Michael
Am 17.02.13 17:44, schrieb Michael Ring:
Your timeline sounds fine to me, I am currently q
Am 13.05.13 20:36, schrieb Florian Klämpfl:
Am 13.05.2013 20:07, schrieb Michael Ring:
OK, I got kind of bored last weekend and started to implement
mips-embedded target. The crosscompiler builds fine and already shows
the list of (not yet implemented) pic32mx controllers, I am now
searching
On 05/13/2013 08:07 PM, Michael Ring wrote:
... pic32mx controllers ...
G R E A T !!!
unfortunately I don't currently do development on PIC32 yet, but I plan
to upgrade our PIC24 based products to PIC32 some day.
I might be able to do some testing once you have a Beta version.
-Mi
On 05/13/2013 08:07 PM, Michael Ring wrote:
... pic32mx controllers ...
BTW.:
AFAIK, the PIC controllers (16 and 32 Bit) use a propriety debug
interface to be accessed by "PICKit" an "ICD-3" adapters. They do use a
gnu based (though propriety made, and payed) C-compile
Am 14.05.13 08:47, schrieb Michael Schnell:
On 05/13/2013 08:07 PM, Michael Ring wrote:
... pic32mx controllers ...
BTW.:
AFAIK, the PIC controllers (16 and 32 Bit) use a propriety debug
interface to be accessed by "PICKit" an "ICD-3" adapters. They do use
a gnu base
On 05/14/2013 10:33 AM, Michael Ring wrote:
my personal goal is not complete coverage of all aspects of a
microcontroller ...
Hmmm.
Regarding PIC, Microchip provides hundreds of variants of PIC32. They
differ in the available I/O elements. The library that comes with MPLab
X provides the
...
That is why my goal would be to be able to call fpc-generated functions
(which should be rather independent of the chip-variant ) from a running
MPLab-X projects, and be able to debug them using Lazarus.
-Michael
___
fpc-devel maillist
Hi Michel!
You are talking about integrating mips into your debugger, what does
this mean? Are you talking about Setedit or something else?
Michael
Am 14.05.13 22:01, schrieb Michel Catudal:
Le 2013-05-14 06:13, Marco van de Voort a écrit :
In our previous episode, Michael Ring said:
I
ither.
I understand that both are used via gdb when accessed by MPLabX, thus
gdb --tui or ddd should work and making Lazarus work should be possible.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/ma
nd I do not want to duplicate this effort with
another, also more or less undocumented tool unless I see no other
choice (because flasing is dog slow, for example)
Michael
Am 15.05.13 11:41, schrieb Michael Schnell:
On 05/14/2013 10:01 PM, Michel Catudal wrote:
I found the interface to open
On 05/15/2013 12:11 PM, Michael Ring wrote:
If you find the time to find out how to actually start up & use their
gdbserver I will be more than happy to integrate it into lazarus,
right now I take what I can get and that seems to be openocd.
Maybe this helps
http://olimex.wordpress
use, AFAIK, PICKit out of the box does not
internally do JTAG, but it can be made to do JTAG, as you can toggle
each single communication pin via USB. OTOH, PICKit hardware is simple
and it contains a PIC chip, so you can create and load your own JTAG
enabled firmware, if you dare.
, that's pretty slow. I will check if a
j-link or st-link work better, but I do not have high hopes.
But perhaps the ejtagproxy or pic32prog can solve this problem, will
keep you posted.
Michael
Am 16.05.13 08:53, schrieb Michael Schnell:
On 05/15/2013 12:11 PM, Michael Ring wrote:
If you
://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle
Michael
Am 15.05.13 23:48, schrieb Michel Catudal:
Le 2013-05-15 06:11, Michael Ring a écrit :
If you find the time to find out how to actually start up & use their gdbserver
I will be more than happy to integrate it
While all this seems to turn out as a major mess, I would like to see
"$ZEROBASEDSTRINGS" in fpc, as well.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
et another
incompatible change will be forced on the users.
I would not dare to decide a direction for Lazarus on that behalf.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 05/16/2013 12:34 PM, Sven Barth wrote:
Was already added by Florian in November (revision 22933)
Great !
He seems to be a very skilled prophet :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
They say the need for supporting limited resources is the motivation for
language changes and then they *force* using UTF16 instead of UTF8 (or
ANSI) as the only possible string code.
Very queer.
-Michael
___
fpc-devel maillist - fpc-devel
They say the need for supporting limited resources is the motivation for
language changes and then they *force* using UTF16 instead of UTF8 (or
ANSI) as the only possible string code.
Very queer.
-Michael
___
fpc-devel maillist - fpc-devel
mance.
Michael
Am 16.05.13 09:55, schrieb Michael Ring:
Nice find, question is why did I not find this link ;-)
I etched some testboards yesterday and connected them to my
ARM-USB-TINY, openocd detects the chip just fine but Michel was right,
flash read performance is a mess, it took two minutes to
h multiple
firmware variants loaded (e.g. as an adapter to attach asynchronous and
SPI data steams to USB.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I did not do anything on PIC32, yet, but using the non-JTAG native PIC
interface with PIC24 and PICKit performance is (AFAIRemenber) something
like one second for 32 K and a fraction of a second using ICD3.
So JTAG with PIC is really disappointing.
-Michael
s transferred in blocks of bytes via USB.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 05/15/2013 12:11 PM, Michael Ring wrote:
If you find the time to find out how to actually start up & use their
gdbserver I will be more than happy to integrate it into lazarus,
right now I take what I can get and that seems to be openocd.
I don't think the term "gdbserver&qu
t support MIPS debug mode.
Does this not help ?
http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf
Another way (without creating hardware) would be to find out how MPLABX
interfaces PICKit or ICD3. I am convinced that they do use gdb in some
way, but I did not easily find out more
ssary
in the adapter. OTOH, I understand that ICD3 has built-in Intelligence
to provide better performance with debugging and Flash programming.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/lis
a PC that - again - provides the command line interface
that can be accessed by a Terminal or by Eclipse and friends.
gdb has to be compiled for the target otherwise it will only support
local opcodes .
Yep.
-Michael
___
fpc-devel maillist - fpc
? Does it come with a
gdbserver type of "driver" on the PC ?
BTW.: can you say anything regarding the PIC32 debugging issue ?
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 05/24/2013 03:56 AM, Michel Catudal wrote:
Some USB message trapping!
Nope. What I would try to do (if having some spare time) would by try to
find out what file might do the gdb functionality (including the dwarf
handling), hoping that same could be accessed by Eclipse as "gdb".
e.
Maybe this is what EJTAGproxy does.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
T=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH CROSSOPT="-godwarfsets -gw2 -O-"
BINUTILSPREFIX=arm-none-eabi-
FPCMAKENEW=/Users/ring/devel/fpc/utils/fpcm/fpcmake
At this point I ask myself if this error exists because I did something
wrong building f
28.05.13 10:59, schrieb Michael Ring:
I was having troubles today installing ppcrossarm from trunk, I have a
workarround for the problem but I question myself how to really fix
the problem:
SUBARCH=armv7m
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH
Thank you!
Michael
Am 28.05.13 14:56, schrieb Yury Sidorov:
Fixed in r24626. Your guesswork is right :)
Yury.
- Original Message - From: Michael Ring
To: fpc-devel@lists.freepascal.org
Sent: Tuesday, May 28, 2013 1:24 PM
Subject: Re: [fpc-devel] Problem with fpcmake when doing
the pic32 chips.
Is it easy to implement those missing op-codes in the internal
assembler, if yes, could some fpc-crack give me a hint on what to change
where?
Those are the missing opcodes:
beqz
ehb
ext
ins
mfc0
mtc0
sdbbp
wrpgpr
Thank you in advance,
Michael
$t2,0
the statements are missing the last param in the generated assembler file:
pic32mx1xxfxxxb.s:87: Error: absolute expression required `li $t2,'
pic32mx1xxfxxxb.s:102: Error: absolute expression required `and $a0,$a0,'
I guess this needs to be fixed in mips/aasmcpu.pas
M
rands `mfc0 $t0,$t4,1'
Any ideas what to do here?
Michael
Index: opcode.inc
===
--- opcode.inc(revision 24626)
+++ opcode.inc(working copy)
@@ -206,4 +206,11 @@
A_SHL64SUB,
A_SHR64SUB,
A_XOR64SUB,
+A_EHB,
+A_EXT,
+A_IN
,19,1'
pic32mx1xxfxxxb.s:49: Error: Opcode not supported on this processor:
mips2 (mips2) `ext $t2,$t1,26,4'
pic32mx1xxfxxxb.s:51: Error: Opcode not supported on this processor:
mips2 (mips2) `ins $t1,$t2,6,4'
Thank you for your help!
Michael
Am 29.05.13 18:13, schrieb Sergei Gorelkin:
29.
/usr/local/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/Users/ring/devel/fpc/rtl/units/i386-darwin -Fii386 -FE.
-FUi386/units/i386-darwin -dRELEASE -gw2 -di386 -dGDB -dBROWSERLOG
-Fux86 -Sew pp.pas
paramgr.pas(620,54) Error: Identifier not found "paracgsize"
paramgr.pas(640) Fatal: There
compiles again, TnX!
Michael
Am 02.06.13 16:37, schrieb Jonas Maebe:
On 02 Jun 2013, at 16:19, Michael Ring wrote:
/usr/local/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/Users/ring/devel/fpc/rtl/units/i386-darwin -Fii386 -FE.
-FUi386/units/i386-darwin -dRELEASE -gw2 -di386 -dGDB
ler file?
TnX,
Michael
PIC32MX FRM - Section 3. Memory Organization PIC32MX FRM - Section 3.
Memory Organization
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
symbols in different segments
the error is from the .size line.
Am 02.06.13 22:51, schrieb Jeppe Græsdal Johansen:
Den 02-06-2013 22:41, Michael Ring skrev:
Hi, perhaps I am overseeing a simple solution for my problem:
On the pic32 there are two flash areas, one at 0x9d00 for the
main pr
This version worked,
thank you for your help!
Michael
Am 02.06.13 23:20, schrieb Jeppe Græsdal Johansen:
Den 02-06-2013 23:15, Michael Ring skrev:
Unfortunately that does not seem to work (or I use it wrong):
This procedure:
procedure _general_exception_handler; assembler; nostackframe
Thank you, the startup code is compiling now, I will send you a patch
with the missing opcodes to have full support of mips32r2 soon.
Michael
Am 03.06.13 22:04, schrieb Sergei Gorelkin:
29.05.2013 21:44, Michael Ring пишет:
This is looking good now on first view, all statements seem to pass
xxx64xxx and xxx32, xxxg and
dxxx, all those do not seem to be valid for mips32 & up, where do those
come from and which of those do I need to add?
There's one very strange entry in opcode.inc: 'b '
there is also 'b', is it necessary to have 'b ' ?
Thank
r in inline assembler?
Something like:
procedure reset; assembler; nostackframe; public name '_reset'; section
'.reset,"ax",@progbits';
???
TnX,
Michael
generated assemblerfile:
.section .text.n_pic32mx1xxfxxxb_$$_reset
.balign 4
.globl PIC32MX1XXFX
I did have a look at mips-opc.c in binutils, this looks easy to parse, I
will give this a try, thank you for the hint!
I will come back to you with a 2nd version, looks like a nice task to
complete while sitting in the train
Michael
Am 17.06.13 08:12, schrieb Sergei Gorelkin
this would be something for the longterm to try to do it
myself, first I would like to get support for pic32mx done, this burns
more under my fingernails and I am still not atb the end of the learning
curve there.
Michael
Am 17.06.13 15:54, schrieb Pierre Free Pascal:
Maybe the section
ing it on
the 'real' linux box. At least not in the beginning of your journey.
Michael
Am 19.06.13 18:10, schrieb Dennis Poon:
I have mostly given up on creating the cross compiler for
MIPSEB-OpenWrt (or DD-WRT) platform.
Now, my plan B is to create a cross compiler (from x86 Linux) t
, if the former version used 1-Byte-Strings (ANSI or UTF-8) and the
new version used 16 or 32 bit Strings (UTF-16 or UTF32) I would expect a
severe performance hit as well because more bytes need to be moved and
because the cache gets a lot more tight because of the double memory us
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
Maybe in that example there's going an (unneeded) conversion?
If you use the same string type all over the place it would be a severe
bug if _any_ conversion is done.
Please check.
-Mi
llphone" use), with 512 MB RAM and additional
"internal SD-Card", and with a HDMI socket.
He is up to try to install and develop with FPC/Lazarus ASAP. (Please
com back with any question on that behalf, I'm going to forward them.)
I definitively
he is going to move his
BBB's to same.
Additionally, I learned that, for embedded use, the DaVinci distribution
also often is recommended.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
d Ref-Count DWords) should not matter
at all.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
(Delphi 7
compatible) String library.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
o more of these calls or why they should be
slower (while using the same encoding.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
to the created binary, in case this helps:
http://temp.michael-ring.org/hello.elf
Michael
--- here are some outputs for your reference
ppcrossmipsel -MObjFPC -Scghi -Ch1024 -Cs1024 -Tembedded -Pmipsel -gw2
-vewnhix -l -Cpmips32r2 -WpPIC32MX220F032C -XPpic32mx-elf32
-FD/usr/local/bin
this clear.
Could you give us a list of the different - legacy and to be supported
- string types we might be seeing including their "official" names to
make the discussion less ambiguous.
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@
ArchLinux, it takes 10.
How long does BeagleBone take to boot to shell?
I'll ask.
Karlheinz right now is doing some experiments with Debian and the
original Angstrom Distribution.
After this he will try to install fpc and Lazarus.
-Michael
__
On 06/21/2013 06:39 PM, Florian Klämpfl wrote:
Does it have an fpu which supports exception handling?
I am not aware of this special issue.
The CPU is a AM 335x by TI. A quick search of the nearly 5000 page Chip
handbook did not reveal anything on that behalf to me.
-Michael
type
ANSIString, even in spite of the naming.
I seem to have read that in Delphi XE the strings also are called
ANSIString, even if they work differently from what (the currently
released) fpc call with that name.
So a decent grid would be very helpful.
-Michael
___
aking any String(x) type
without auto-conversion. I still do hope that fpc will provide this one
day.
Moreover I do hope for RawWordString, RawDwordString and RawQWordeString.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
. _This_ is funny IMHO.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 06/24/2013 04:44 PM, Hans-Peter Diettrich wrote:
Not in Delphi. For binary data TBytes has been added.
Which (AFAIK) is not reference counting can't do "+" and thus much less
versatile.
-Michael
___
fpc-devel maillis
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 - fpc-devel@lists.freepascal.org
http
4 bit SD-Card) and thus is a lot faster when
booting from this chip. Karlheinz at the moment uses an SD-Card to boot
Debian. So Debian Boot-speed might be close to Angstrom's when moving it
to the internal flash.
-Michael
___
fpc-devel mai
On 06/24/2013 05:25 PM, Dennis Poon wrote:
Does have a stable stock supply?
The BBB (Beagle Bone Black - I typed one B to much )seems to be easily
available from multiple resellers. It had been delivered the next day.
-Michael
___
fpc
for you, if you need a greater number.
With the Raspberry the RAM is soldered on top of the CPU, a very
critical technology only a few shops can offer.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/m
ent system should _additionally_ provide completely unencoded 8,
16, 32 and 64 Bit entity Strings for "technical" usage (similar to pipes
etc) (now not using the "RAW" naming :-) .
-Michael
___
fpc-devel maillist - fpc-d
On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
In fact it looks like only the string pointers are copied between
AnsiString and RawByteString, with the refcount changed accordingly.
Supposedly the length and encoding number and code-bytecount is copied,
too.
-Michael
be 8 Bits.
In fact I did ask for a way to distinguish all this verbally (not the
keywords in a source file) to allow for doing a non ambiguous
discussion. This needs Names that denote the version of the library used.
-Michael
___
fpc-devel maillist
the GUI (Gnome) is running. After
stopping the GUI Lazarus can be compiled. So installing new Lazarus
packages (he needs Synapse and maybe Indy) might be a little bit more
work than on a PC.
-Michael
___
fpc-devel maillist - fpc-devel
On 06/25/2013 01:19 PM, Hans-Peter Diettrich wrote:
Efficient code must be based on a single encoding, with conversions
only from and to the outer world (OS, files...).
That does not force to prevent intermediately storing a string in
something that can hold any encoding type.
-Michael
On 06/25/2013 01:20 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Supposedly the length and encoding number and code-bytecount is
copied, too.
Please understand reference counted memory objects :-]
Please check this program I tested with a pre-Unicode Delphi.
It shows that (of
basics. Why don't you start adjusting your weird mind to the
facts, as have been given repeatedly since years? :-(
Sorry again. We are (still) discussing how am implementation in fpc can
potentially be better than that in DXE. Thus the "basics" and the
"facts" are not reall
;s interface to the user
code. This would allow for using greatly the same code for multiple
archs, independent of the user code. IMHO, the performance hit for this
should be small, as these interface functions mostly are not used in
very long close lo
On 06/26/2013 09:41 AM, Michael Schnell wrote:
It shows ... how it is done.
Hi DoDi,
You might be inclined to enhance the test program for me and compile it
with DXE:
AFAI understand the encoding type and as I see in
http://wiki.freepascal.org/FPC_Unicode_support
ce against the (static=dynamic)
encoding type of the target and do a conversion if appropriate. IMHO
this would be a very sensible behavior.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
no auto-conversion is done -
supposedly EncodingType and ElementSize in DXE) being identical for both
strings after the assignment. Thus a RawByteString supposedly will in
fact get the source's encoding type).
(see my mail to Sven).
-Michael
__
hen the user's call provides a string and
during the work in the library it is decided that it is not actually used.)
-Michael (the weird one)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
other
String) is not possible to make use of the encoding type of a String
information that had been assigned to a RawByteString.
Thanks for the affirmation
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
On 06/26/2013 02:08 PM, Sven Barth wrote:
Am 26.06.2013 14:02, schrieb Michael Schnell:
That is what I did assume, but I understood dodi in a way that he
suggested that it (with normal means such as assigning to another
String) is not possible to make use of the encoding type of a String
with the only exception when assigning _to_ a
RawByteString (_static_ encoding Type $). That easily can be decided
by the compiler at compile time (that here and in many other cases does
not even need to call the library, as assigning is simply done by
setting the pointer and increasing th
ng function is a
RawByteString. (In fact it will never be called
with a RawByteString target, when the compiler magic creates the call instead
of manually done by theSetCodePage programming)
I see no problem here either.
-Michael
___
f
normal String when appropriate.
The what _is_ (in DXE) is not discussed here (other than as a subject of
comparing).
- Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
this behavior is a quirk go and
should not be capt just for compatibility. .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
and holds the content
pointer to the String array.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 06/27/2013 09:51 AM, Michael Van Canneyt wrote:
There is no content pointer. The string array is appended to the "record"
I see. Thus the "pointer" is relative and implicate :-P . Silly me.
-Michael
___
fpc-devel ma
ing the name RawByteString back the
meaning, the name suggests.) When doing so assigning a RawByteStrinig to
a normal String could be strictly forbidden (unless some Delphi Quirks
Mode is set). But I do see that the additional complexity of defining
jet another String
uld be erroneous in DXE as well) can't happen.
- for RawByteString, a "normal" dynamic type means: "this is
printable information" and a dynamic type $ (that had been assigned
to the string when instantiating) means: this String just holds just
bytes with no encoding as
a normal String and a RawByteString get together in a
single statement. Regarding that LCL calls are not done in close loops
this would be close to zero.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
compatible to the suggested modification.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 06/26/2013 10:28 PM, Hans-Peter Diettrich wrote:
Please note that I invited Michael Schnell to provide his version of
such RTL routines, compatible with *his* ideas about "better" string
handling.
I would be happy to do this, but unfortunately the modified behavior
would
name suggests - but this
is jet another issue.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
n is done.
To me this seems absolutely silly.
It might be acceptable with Delhi that is Windows-centric and in fact
depreciates the use of codes other than the "System Encoding"
With a cross-platform tool such as fpc, a smarter (though compatible)
implementation should be provided.
-Mich
IMHO we do need an appropriately versatile String type and (a
decently fast) implementation.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
sting program I provided you with appropriately already
some days ago :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
601 - 700 of 5273 matches
Mail list logo
