I have uploaded a patch[1] to remove the TSaxInputSource, it is
redundant with TXmlInputSource from XmlReader unit.
I believe the TSAXXMLReader.Parse method have almost the same
functionality of xmltextreader.TXMLTextReader.
I would like to know if and how it can be modified. The base class,
On Tue, 11 Mar 2014, Daniel Gaspary wrote:
I have uploaded a patch[1] to remove the TSaxInputSource, it is
redundant with TXmlInputSource from XmlReader unit.
I believe the TSAXXMLReader.Parse method have almost the same
functionality of xmltextreader.TXMLTextReader.
I would like to know if
On 03/11/2014 01:08 PM, Vsevolod Alekseyev wrote:
How interesting. Where's you hear this?
It's an obvious conclusion from your statement that any non-Thumb code
crashes.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 03/11/2014 03:12 PM, Vsevolod Alekseyev wrote:
For the record, all modern mobile SDKs that I know of use Thumb as the
default instruction set for native code compilation. And with Thumb-2
on ARMv7 cores, the performance is on par between ARM and Thumb. The
original Thumb, years ago, was
On 03/11/2014 02:02 PM, Vsevolod Alekseyev wrote:
Just ask Delphi with their funky register-based convention :)
I did a research on many different CPUs for a future project and found
that - like with Delphi - with many modern GNU C compilers registers are
used for the first few function
12.03.2014 1:32, Daniel Gaspary пишет:
I have uploaded a patch[1] to remove the TSaxInputSource, it is
redundant with TXmlInputSource from XmlReader unit.
I believe the TSAXXMLReader.Parse method have almost the same
functionality of xmltextreader.TXMLTextReader.
I would like to know if and
Am 12.03.2014 10:31 schrieb Michael Schnell mschn...@lumino.de:
On 03/11/2014 02:02 PM, Vsevolod Alekseyev wrote:
Just ask Delphi with their funky register-based convention :)
I did a research on many different CPUs for a future project and found
that - like with Delphi - with many modern
On 03/12/2014 12:17 PM, Sven Barth wrote:
(in fact not for 68K :-) ).
Which is a pity as it has a nice amount of registers to spare :P
I suppose nobody wanted to stand up and change the old fashioned
STDCALL default ABI for sake of speed.
-Michael
It's one possible implementation, but hardly the only one. In fact, this
kind of implementation would have testable consequences - specifically, a
*short* amount of ARM would be able to run unmolested in a debuggerless
environment - i. e. if no interrupts come while in ARM mode. I'll try it
when I
On Wed, Mar 12, 2014 at 8:06 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
OTOH, if we go for breaking user's code, then it is much better to drop SAX
altogether and switch over to TXMLTextReader.
From these points of view the best way is probably to document
TXMLTextReader, deprecate SAX
On 03/12/2014 02:17 PM, Vsevolod Alekseyev wrote:
It's one possible implementation, but hardly the only one. In fact, this
kind of implementation would have testable consequences - specifically, a
*short* amount of ARM would be able to run unmolested in a debuggerless
environment - i. e. if no
On Wed, Mar 12, 2014 at 11:04 AM, Daniel Gaspary dgasp...@gmail.com wrote:
On other topic, a new StaX[1] class, using TXMLTextReader,
I mean, *classes*.
Creating the writer part too.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
12.03.2014 18:10, Daniel Gaspary пишет:
On Wed, Mar 12, 2014 at 11:04 AM, Daniel Gaspary dgasp...@gmail.com wrote:
On other topic, a new StaX[1] class, using TXMLTextReader,
I mean, *classes*.
Creating the writer part too.
Why would you want to use S[t]AX approach in the first place? The
On Wed, Mar 12, 2014 at 11:42 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
Why would you want to use S[t]AX approach in the first place?
No special reason at the moment. I didn't examine TXmlTextReader so much yet.
The interface of .net-based XML[Text]Reader and XMLWriter is IMHO
much
12.03.2014 18:58, Daniel Gaspary пишет:
On Wed, Mar 12, 2014 at 11:42 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
Why would you want to use S[t]AX approach in the first place?
No special reason at the moment. I didn't examine TXmlTextReader so much yet.
The interface of .net-based
As there was no reaction I created a patch, question is if this patch
can be generally applied or if this version of patch should be specific
for arm targets. I guess it should be universal because it matches the
other definitions that also use pChar in the same file.
[ring@macbookpro fpc]$
Den 12-03-2014 16:51, Michael Ring skrev:
As there was no reaction I created a patch, question is if this patch
can be generally applied or if this version of patch should be
specific for arm targets. I guess it should be universal because it
matches the other definitions that also use pChar
On Wed, Mar 12, 2014 at 12:18 PM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
Here I fully agree, and in the meantime I've already committed some initial
changes to TXMLWriter to make it function like .net XMLTextWriter.
Are these changes at trunk? Fcl or LazUtils?
About DOM independence...
On Wed, 12 Mar 2014, Daniel Gaspary wrote:
On Wed, Mar 12, 2014 at 12:18 PM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
Here I fully agree, and in the meantime I've already committed some initial
changes to TXMLWriter to make it function like .net XMLTextWriter.
Are these changes at
On Wed, Mar 12, 2014 at 2:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Curious: How can XPath become dom independent ?
I thought the result of XPath was a series of DOM nodes ?
Yes, it is. But I'm thinking about using the XPath expressions in other classes.
Maybe a TXmlTextReader
Thank you Jeppe,
I did not want to look impatient, was just wondering if this problem
somehow did not catch attention... ;-)
Michael
Am 12.03.14 17:41, schrieb Jeppe Græsdal Johansen:
Den 12-03-2014 16:51, Michael Ring skrev:
As there was no reaction I created a patch, question is if this
On Wed, 12 Mar 2014, Daniel Gaspary wrote:
On Wed, Mar 12, 2014 at 2:23 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
Curious: How can XPath become dom independent ?
I thought the result of XPath was a series of DOM nodes ?
Yes, it is. But I'm thinking about using the XPath
On Wed, Mar 12, 2014 at 2:36 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
What can be achieved at the most seems to be the parsing of the expression
and the resulting parse tree.
Is exactly what I'm trying to say(my lack of English grammar skills
doesn't help). :)
I seriously doubt
On Wed, Mar 12, 2014 at 3:23 PM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
A certain subset of expressions (forward iteration only) can be handled that
way, yes.
But in general, XPath requires a source with non-sequential access.
Beyond this use case, could be useful to other
12.03.2014 21:46, Daniel Gaspary пишет:
On Wed, Mar 12, 2014 at 2:36 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
What can be achieved at the most seems to be the parsing of the expression
and the resulting parse tree.
Is exactly what I'm trying to say(my lack of English grammar
From: Michael Van Canneyt mich...@freepascal.org
To: Leonardo M. Ramé martinr...@yahoo.com; FPC developers' list
fpc-devel@lists.freepascal.org
Sent: Sunday, March 9, 2014 6:22 AM
Subject: Re: [fpc-devel] fpHttpClient heartbeat
On Sat, 8 Mar 2014, Leonardo
Am 12.03.2014 18:36 schrieb Michael Ring m...@michael-ring.org:
I did not want to look impatient, was just wondering if this problem
somehow did not catch attention... ;-)
It's usually best to report things like that on the bugtracker.
Regards,
Sven
27 matches
Mail list logo
