On 01 Mar 2008, at 02:00, Luiz Americo Pereira Camara wrote:
The question is: using the layout below with packed (i can force the
set size to be equal to Delphi) i still have unaligned memory access?
As long as you record is declared as "packed", all memory accesses are
handled as if they
Jonas Maebe wrote:
On 29 Feb 2008, at 01:55, Luiz Americo Pereira Camara wrote:
One more question:
The VirtualTreeView tries to make the fields of the (packed) record
aligned at dword boundary by grouping together smaller (one or two
byte fields) or adding dummy fields. Does this trick over
Vinzent Hoefler wrote:
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it
looks quite different (and I'm not sure about all the types used here,
some seem to be sets, some enumerations). But at the first glance it
seems, they used both packed records to either ensure minimum
Daniël Mantione wrote:
>
>
> Op Fri, 29 Feb 2008, schreef Christian Iversen:
>
>> Daniël Mantione wrote:
>>>
>>>
>>> Op Fri, 29 Feb 2008, schreef Christian Iversen:
>>>
> Instead "unaligned" will simulate an unaligned load with two loads
> and some rotation etc. On the ARM, where every m
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead "unaligned" will simulate an unaligned load with two loads and
some rotation etc. On the ARM, where every mnemonic can rotate operands,
this is isn't that bad of
Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead "unaligned" will simulate an unaligned load with two loads
and some rotation etc. On the ARM, where every mnemonic can rotate
operands, this is isn't that bad of a penalty.
Therefore, I wouldn't be surprised tha
From: "Daniël Mantione" <[EMAIL PROTECTED]>
Instead "unaligned" will simulate an unaligned load with two loads
and some
rotation etc. On the ARM, where every mnemonic can rotate
operands, this is
isn't that bad of a penalty.
Therefore, I wouldn't be surprised that even on ARM, arrays with
pac
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead "unaligned" will simulate an unaligned load with two loads and some
rotation etc. On the ARM, where every mnemonic can rotate operands, this is
isn't that bad of a penalty.
Therefore, I wouldn't be surprised that even on ARM, arrays wi
Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Memory access. What happens is that the non-packed version causes
more cache misses. A cache miss costs many cycles on a modern cpu, a
misaligned read just costs an extra memory access (which is fast if
cached) on x86, a
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Memory access. What happens is that the non-packed version causes more
cache misses. A cache miss costs many cycles on a modern cpu, a misaligned
read just costs an extra memory access (which is fast if cached) on x86,
and extra load instructio
Martin Schreiber wrote:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Resourcestrings are ansistrings, so the answer is no. This is indeed a
shortcomin
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Luiz Americo Pereira Camara:
Yury Sidorov wrote:
The patch removes packed record for some platforms.
IMO packed can be removed for all platforms. It will gain some speed.
I'd like to understand more this issue.
Why are non packed records
On Friday 29 February 2008 14.16:18 Michael Schnell wrote:
> In fact I still don't know what it really is.
>
> At home I monitored the newsgroup for a while and once same was
> canceled, I thought the thing would be dead. (Like other Delphi related
> project I monitored died: Kylix / Cross-Kylix /
MSEide+MSEgui compiles with Delphi7 with exception of DB components and
therefore the adjacent MSEifi DB components. It should be possible to patch
FPC db.pas in order it can be compiled with Delphi. MSEide uses gdb as
Lazarus does, gdb integration of MSEide is possible a little bit better tha
This has been discussed before. Automatic conversion to/from
ansistrings will always be to/from system encoding. If you want
another encoding than the system encoding you will have to do a manual
conversion.
Actually you as the application developer can control how conversions
between ans
On Friday 29 February 2008 11.27:47 Michael Schnell wrote:
> > Sure, it is the purpose of MSEifi to connect client MSEgui objects and
> > events with server events and data by the use of an universal client
> > program.
>
> Sounds good. Let me elaborate a bit more: The program in question needs
> t
Sure, it is the purpose of MSEifi to connect client MSEgui objects and events
with server events and data by the use of an universal client program.
Sounds good. Let me elaborate a bit more: The program in question needs
to be ported from a a project running in Delphi.
I do know how to p
On Friday 29 February 2008 10.49:11 Michael Schnell wrote:
>
> Before I knew about MSEifi I intended to attach the remote GUI on a
> "per-control" base via a propriety protocol (e.g. using RemObjects). But
> this would imply handling any program done that way individually, which
> of course is not
> On Friday 29 February 2008 10.07:29 Dani?l Mantione wrote:
> Another suggestion:
>
> implementation
>
> resourcestrings
> resstring1 = 'abc';
> resstring2 = '1234';
>
> resourcewidestrings
> resstring3 = 'abc';
> resstring4 = '1234';
I don't like inventing Delphi incompat syntax for it, s
It depends what effort you plan to invest into testing and debugging. ;-)
Missing pieces:
- Documentation.
- SSL on win32.
- Consistent error handling and error recovery.
- Pascalscript import units for complete MSEgui.
- MSEifi webbrowser plugin.
- Some convenience tools in MSEide for MSEifi pr
On 29 Feb 2008, at 09:25, Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Are there plans to implement unicode resourcestrings?
No, but this is just because you are the first one to ask.
There is already a bug report about it:
http://bugs.freepascal.org/view.php?id=6
On 29 Feb 2008, at 01:55, Luiz Americo Pereira Camara wrote:
One more question:
The VirtualTreeView tries to make the fields of the (packed) record
aligned at dword boundary by grouping together smaller (one or two
byte fields) or adding dummy fields. Does this trick overrides the
unalig
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote:
> Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> > On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
> >> Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> >>> On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
> Op F
On Friday 29 February 2008 09.32:23 Michael Schnell wrote:
> This does work nicely !
>
> Any chance to be able to use this in the foreseeable future ?
>
It depends what effort you plan to invest into testing and debugging. ;-)
Missing pieces:
- Documentation.
- SSL on win32.
- Consistent error hand
The VirtualTreeView tries to make the fields of the (packed) record
aligned at dword boundary by grouping together smaller (one or two
byte fields) or adding dummy fields. Does this trick overrides the
unaligned memory access?
Of course it is always a good idea to sort the members of a record
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current F
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
> Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> > On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
> >> Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> >>> Hi,
> >>> Is there a way in current FPC to have unicode or wide resour
On Friday 29 February 2008 09.27:08 Marco van de Voort wrote:
> > On Friday 29 February 2008 09.02:02 Dani?l Mantione wrote:
> > > Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> > > > Hi,
> > > > Is there a way in current FPC to have unicode or wide
> > > > resourcestrings? Thanks,
> > >
> > > Re
This does work nicely !
Any chance to be able to use this in the foreseeable future ?
What kind of license do you intend to use ? (Sourcecode is a must for
us, of course.)
Thanks agian,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal
> On Friday 29 February 2008 09.02:02 Dani?l Mantione wrote:
> > Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> > > Hi,
> > > Is there a way in current FPC to have unicode or wide resourcestrings?
> > > Thanks,
> >
> > Resourcestrings are ansistrings, so the answer is no. This is indeed a
> > sho
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Resourcestrings are ansistrings, so the answer is no.
> Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it
> looks quite different (and I'm not sure about all the types used here,
> some seem to be sets, some enumerations).
Can be configured:
http://lists.freepascal.org/docs-html/prog/progsu50.html
Delphi has the minenumsize o
I made a demo of MSEifi with a server and a client connected by pipes.
Win32 binaries:
http://msedocumenting.svn.sourceforge.net/viewvc/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo/bin/i386-win32/ifipipedemoclient.exe?view=log
and
http://msedocumenting.svn.sourceforge.net/viewvc/m
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
> Op Fri, 29 Feb 2008, schreef Martin Schreiber:
> > Hi,
> > Is there a way in current FPC to have unicode or wide resourcestrings?
> > Thanks,
>
> Resourcestrings are ansistrings, so the answer is no. This is indeed a
> shortcoming in a wi
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Resourcestrings are ansistrings, so the answer is no. This is indeed a
shortcoming in a widestring environment, the only solution is probably to
encode them UT
35 matches
Mail list logo
