Hi,
here it is:
http://downloadit.pf-control.de/dl.php?ref=swig
Unfortunately I made the mistake and did the work on a non version controlled
folder - therefore it is whole swig and not just a patch :(
Feel free to move the file to any other - possibly more "central" - place and
hopefully there
Hi,
> http://members.upc.nl/s.grewar/swig_2.0.8_to_swig_delphi.diff
Hm, this really doesnt look good.. :(
I did run "make maintainer-clean" before packing - and hoped this would remove
all this autogenerated stuff - apparently this wasn't the case [although the
size of the whole thing went down
Hi,
as the question whether inline or external source docs are the way to go
(again?) came up, here are my thoughts (currently searching for the "best"
solution :) ):
I personally prefer external docs (and thus started to use fpdoc);
reasons are uncluttered source, less scrolling and (if you str
> Well, I have planned a inline-to-external conversion for fpdoc for exactly
> this reason.
That's nice to hear...
[Sorry for late reply]
d.l.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/f
Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis;
TP experience ~ average user) there really should be an decision what way to
go as early as possible.
I'm not ranting and I know, that I'm not in the position to demand anything...
[I would really like to help, but
Hi,
> > Users can define the internal type with e.g. {$STRING UTF8} for their
> > *whole* project.
>
> Should that (*whole* project) include also the "3rd party" units (with
> available sourcecode)?
Yes, that's the idea...
... the only problem is, that many still use old style "hacking", this of
Hi,
thanks for the quick reply.
So the direction seems to be quite clear...
... unfortunately this seemingly wasn't communicated clearly enough to the
surroundings.
>Because of the requirement for backwards compatibility with FPC itself,
>we'll make 2 RTLs: one backwards compatible, one with th
Hi,
thx, got it...
> There will always be conversion if
> 1) a unit specifies a string type by itself.
> 2) the unit comes in compiled form.
One more question:
If a particular unit (maybe 3rd party) does not define its string type, what
string type is used:
(a) the type defined in project,
(b) a
Hi,
that's great news...
Thanks for the effort to clarify,
d.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
first of all: no matter what - stay with 'Free Pascal' - I don't think there
would be any advantage renaming a project - except for the whole project
loosing its identity.
My experience is that most people don't even know Pascal - I wouldn't say
Pascal as a language has a bad reputation.
[Ev
> We were only joking around with the name. :)
Fully understood, but just to be sure :D
d.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
working with fcl-xml some questions came together. Every hint is appreciated.
1.
No matter what I do and which (short & valid) xml file I use - getElementById
is always nil (tested with trunk and latest stable 2.6.2) and the same applies
to TXMLDocument.IDs.
I tried with ReadXMLFile and TDOM
Hi,
> The XMLTextReader creates the map, and passes it on to the final document.
// Trunk
procedure TLoader.ProcessXML(ADoc: TDOMDocument; AReader: TXMLTextReader);
begin
[...]
doc.IDs := reader.IDMap;
reader.IDMap := nil;
end;
// 2.6.2
=== snip ===
doc.IDs := FIDMap;
FIDMap := nil;
> Maybe the bug is that it checks case sensitive:
>
> procedure TXMLTextReader.ParseAttlistDecl;
> ...
> Found := FSource.Matches(AttrDataTypeNames[dt]);
ParseAttlistDecl isn't called a single time...
- to me it sounds like "Parse Attribute *declaration*" - and I don't have a
DTD (the
A little side note to my statement:
> and I don't have a DTD
In this case the behaviour of the parser is even right...
W3C:
Note: Attributes with the name "ID" or "id" are not of type ID unless so
defined
--
http://stackoverflow.com/questions/3423430/java-xml-dom-how-are-id-a
> > Using Xpath I believe would be something like this:
> I was missing an If:
>
> function ElementById(id: string; doc: TXMLDocument): TDOMElement;
> var
>v: TXPathVariable;
> begin
>[..]
> end;
This does indeed work - thank you :)
It's an acceptable solution for me, as I will need XPath any
> > Is this worth a feature request / bug on mantis?
>
> Yes.
Issue #24032
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
> If you need xpath, you might also want to look at my Internet Tools (
> (http://benibela.de/sources_en.html#internettools), they contain a basically
> complete XPath 2 implementation
I already implemented all I need with fcl-xml, but thanks for the hint anyway.
:)
d.l.i.w
Hi,
> FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle
> information.
>It would of course be very welcome if somebody got the current version into
>main SWIG so it is more easily usable
The wiki page is a good idea, things have to be clarified though.
I don't know in how
> @dliw: wasn't the Object Pascal module based on the Modula 3 module?
> IIRC recent posts on the swig mailing lists did indeed indicate the
> Modula 3 module was buggy in current SWIG.
Sorry, you're right - it was based on Modula - I did mix it up.
Thanks for this correction.
> Important point for variant 2: less overhead.
Right, that's the biggest plus in my eyes.
>Or is this meanwhile standardized ?
Unfortunately not. It starts in different name mangling - as already said here
- and other (small) differences.
So working on a cross-platform project in C++ with differ
Hi,
you might also want to take a look at https://code.google.com/p/thtmlviewer
It's still actively developed, so the CSS parser should be more advanced than
the one of TurboPower IP.
dliw
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
ht
22 matches
Mail list logo
