17.05.2013 8:59, Paul Ishenin пишет:
Yes. The RTTI for that type seems to be completely messed up in
current trunk. Probably caused by r24458.
Dynamic arrays were not touched by this revision. I only changed RTTI
for non-dynamic array types.
Heh. But in the Martic example was "array[...] of
17.05.2013 0:24, Jonas Maebe пишет:
On 16 May 2013, at 17:43, Martin wrote:
using rev 24475 the below fails. It works using 2.6.0
Afaik it should work? dynamic types (such as TDynIntArray ) should be
initialized?
Yes. The RTTI for that type seems to be completely messed up in current trunk
Le 2013-05-16 02:53, Michael Schnell a
écrit :
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 laza
Le 2013-05-16 03:19, Michael Schnell a écrit :
> On 05/15/2013 11:48 PM, Michel Catudal wrote:
>>
>> As I mentioned earlier, I have enough information from Microchip to make a
>> fast programmer. What I will need to add is debugging.
>
> I would rather use PickIT or ICD3 than build my own hardware
Le 2013-05-16 04:39, Sven Barth a écrit :
> Am 15.05.2013 23:35, schrieb Michel Catudal:
>> When I used the fpcbuild.zip snapshot it would crash when starting to
>> compile the RTL, much like it does for my AVR32 pascal compiler.
>> On the other hand when I use the fpc.zip snapshot it compiles bea
Michael Ring wrote:
I finished first tests on memory read performance fot jtag probes/pic32,
all on my Mac except the raspberry test:
Olimex TINY-H with openocd:120 Seconds for 32k of data
Olimex TINY-H with ejtagproxy: 10 Seconds for 1k of data, I did not have
the patience to wait for the
I finished first tests on memory read performance fot jtag probes/pic32,
all on my Mac except the raspberry test:
Olimex TINY-H with openocd:120 Seconds for 32k of data
Olimex TINY-H with ejtagproxy: 10 Seconds for 1k of data, I did not have
the patience to wait for the transfer of 32k ;-)
On 16/05/2013 17:24, Jonas Maebe wrote:
On 16 May 2013, at 17:43, Martin wrote:
using rev 24475 the below fails. It works using 2.6.0
Afaik it should work? dynamic types (such as TDynIntArray ) should be
initialized?
Yes. The RTTI for that type seems to be completely messed up in current tru
On 16 May 2013, at 17:43, Martin wrote:
> using rev 24475 the below fails. It works using 2.6.0
>
> Afaik it should work? dynamic types (such as TDynIntArray ) should be
> initialized?
Yes. The RTTI for that type seems to be completely messed up in current trunk.
Probably caused by r24458.
forgot: win32 vista
On 16/05/2013 16:43, Martin wrote:
using rev 24475 the below fails. It works using 2.6.0
Afaik it should work? dynamic types (such as TDynIntArray ) should be
initialized?
Checking in the debugger it looks like VarStatIntArray2A[5] is not
initialized.
program Project1
using rev 24475 the below fails. It works using 2.6.0
Afaik it should work? dynamic types (such as TDynIntArray ) should be
initialized?
Checking in the debugger it looks like VarStatIntArray2A[5] is not
initialized.
program Project1;
type
TDynIntArray = Array of Integer;
procedure Foo
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@lists.fr
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@lists.fr
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/mailm
In our previous episode, Sven Barth said:
> > Especially the points about (currently) different features for
> > different compilers and again ignored backwards compatibility annoy
> > the hell out of me...
> And somehow I have the feeling that we should discuss the topic of
> Delphi compatibili
On 05/16/2013 12:32 PM, Hans-Peter Diettrich wrote:
. Some of the changes (from Ansi to Unicode, from VCL to FM, from one-
to zero-based strings...) require different RTL/FCL/LCL versions,
which cannot be covered in a single FPC/Lazarus version.
I did not expect that after Delphi introduced
Am 16.05.2013 12:32, schrieb Hans-Peter Diettrich:
Michael Schnell schrieb:
While all this seems to turn out as a major mess, I would like to see
"$ZEROBASEDSTRINGS" in fpc, as well.
In fact we should provide as many FPC/Lazarus versions *as* new Delphi
versions introduce breaking changes. So
Michael Schnell schrieb:
While all this seems to turn out as a major mess, I would like to see
"$ZEROBASEDSTRINGS" in fpc, as well.
In fact we should provide as many FPC/Lazarus versions *as* new Delphi
versions introduce breaking changes. Some of the changes (from Ansi to
Unicode, from VCL t
Am 16.05.2013 11:44, schrieb Michael Schnell:
While all this seems to turn out as a major mess, I would like to see
"$ZEROBASEDSTRINGS" in fpc, as well.
Was already added by Florian in November (revision 22933)
Regards,
Sven
___
fpc-devel maillist -
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
Am 16.05.2013 10:54, schrieb Sven Barth:
Hello together!
I've just found the following blog article by the mORMot developer
which links to an article by Marco Cantu about language changes
introduced in the new iOS compiler and further upcoming changes.
Blog article:
http://blog.synopse.info
Hello together!
I've just found the following blog article by the mORMot developer which
links to an article by Marco Cantu about language changes introduced in
the new iOS compiler and further upcoming changes.
Blog article:
http://blog.synopse.info/post/2013/05/11/Delphi-XE4-NextGen-compil
Am 15.05.2013 23:35, schrieb Michel Catudal:
When I used the fpcbuild.zip snapshot it would crash when starting to compile
the RTL, much like it does for my AVR32 pascal compiler.
On the other hand when I use the fpc.zip snapshot it compiles beautifully and
lazarus works great. I did have to co
I read some threads a frew days ago that openocd already works on
Raspberry Pi over gpio, this might be just what you need if I understand
you correctly. Fortunately I have still one Pi left @home to also try
this..
http://code.google.com/p/picnc/wiki/OpenOCD_PIC32_Programmer
and
https:/
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 read out the
32k flash of my pic32mx220 chip, that
On 05/15/2013 11:48 PM, Michel Catudal wrote:
As I mentioned earlier, I have enough information from Microchip to make a fast
programmer. What I will need to add is debugging.
I would rather use PickIT or ICD3 than build my own hardware (in fact
this would help those PIC users that can't do
26 matches
Mail list logo
