Re: [fpc-pascal] Is there a CSS parser in FPC?
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 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
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 far others dealt with the code in the meantime - so this is my personal view: When I ported the patch to 2.0.8 things looked quite good, the changes needed were very straightforward - and in the end the result was quite usable. But IMO the code itself is / was a big mess and far from being clean readable - which is no bigger problem if 'it simply works' :D Now - I tried a port to latest swig (2.0.10) some months ago [even made a fork on github...], but never released, the reason: it doesn't work any more. I didn't search for the relevant changes in their changelog, but I didn't managed to get it even compiled - too many functions simply were missing. Even worse, the Fortran module (upon which the Delphi module is based) although being in trunk also didn't compile - exactly the same missing functions. In short: IMHO the patch is too much bitrotten to be further used, I think a clean and new implementation from scratch would be the much better way. Maybe this can do the trick, too: https://github.com/swig/swig/wiki/GSoC-2013-ideas#wiki-Support_for_C_as_target_language I mean, h2pas does a decent job... And if it's allowed to dream: one time fpc will simply link against C++ directly :) Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
@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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
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 different compilers involved - is still quite an adventure :D then you could work on that by improving the cppclass code in the compiler Hm, I will at least take a look. d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fcl-xml
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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-xml
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 TDOMParser with different options - but the result is always the same. Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? 2. Is there a way to tell WriteXMLFile *not* to use indentation? 3. What is the state of XPath? The readme says 'Should be fairly completed' - can I assume it works for simple tasks? Many thanks for any hint, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
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; == Just rechecked again... The debugger clearly says, that reader.IDMap / FIDMap is nil... [Before the second assignement - of course :) ] It seems to be started, but not finished. If so, what needs to be done? Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
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 file is actually HTML).
When switching Validate *on*, there are lot of DoError calls - but don't know
if this is related...
From what I see: (trunk)
AddId is only called from ValidateAttrValue
ValidateAttrValue is only called from ValidateCurrentNode
and this is only when the parser does validation...
For me there is missing something in ParseAttribute(ElDef: TElementDecl);
===
if Assigned(ElDef) then
begin
AttDef := ElDef.GetAttrDef(attrName);
// mark attribute as specified
if Assigned(AttDef) then
FAttrDefIndex[AttDef.Index] := FAttrTag;
end
else
AttDef := nil;
===
ElDef is not assigned, so AttDef is nil...
AttDef holds TAttrDataType which should be recognised as dtId...
I hope I got it right so far - but still don't know what the actual problem
is...
-
That't what I'm currently testing with:
=== test.xml ===
?xml version=1.0 encoding=UTF-8?
html
div id=testTest/div
/html
=== test.pas ===
program test;
{$mode objfpc}{$H+}
Uses
Classes, XMLRead, DOM;
Var
Doc : TXMLDocument;
Parser : TDOMParser;
Source : TXMLInputSource;
List : TStringList;
begin
List := TStringList.Create;
List.LoadFromFile('test.xml');
Parser := TDOMParser.Create;
try
Parser.Options.IgnoreComments := true;
//Parser.Options.Validate := true;
Source := TXMLInputSource.Create(List.Text);
try
Parser.Parse(Source, Doc);
finally
Source.Free;
end;
finally
Parser.Free;
end;
WriteLn(assigned(Doc.IDs)); // output: false
List.Free;
end.
==
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
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-attributes-special But that's not the solution to my problem... :( d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
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 anyway. Still I think that TDOMDocument.getElementById is better performance-wise - and I don't see a reason why it shouldn't work if TDOMDocument is created by the XMLParser - even if no definition is given... Is this worth a feature request / bug on mantis? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
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
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
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
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called 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. [Every time a program crashes with segfault or similar, I wish it had been written in Pascal... :) ] But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use. +1 from my side, too. I wouldn't see it as closely. Only dead languages are static - there is no good reason to hinder well thought out features to be added, as long as they support the IMO most important two goals of Pascal: readability, and type safety. BUT: the sheer amount mustn't be decisive - feature bloat can have very negative effects... Optimisation is a topic which really needs to be discussed - maybe when fpc reaches a (temporary) state of temporary 'feature completeness'. [lets 2.X be the feature version, 3.X the optimised version :D ] Especially for mobile targets well optimised / efficient programs have great advantage, but the problem mostly is not speed, but energy consumption. [Btw. big thanks for merging the android branch +100] Nice to hear, that the option to 'detach' from Delphi is considered here as well, as I'm sure there will be no other option sooner or later... Last OT: I wouldn't mind the hell not freezing over [...] Nice... It's pretty damn cold in this area (almost at my front door) for this time of the year, so that's really a valid wish... :) Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation
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/fpc-pascal
[fpc-pascal] Strings - suggestions
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 unfortunately studies take all my time - at
least for one more year - but time will come... :D ]
Nonetheless I would like to make a suggestion:
1.
Make a general String type, with no statement what the internal structure is
like.
Users can define the internal type with e.g. {$STRING UTF8} for their *whole*
project. On compilation now the defined type is used and there should be no
problems as long as the source code does not make any assumptions, what the
internal structure looks like and uses a general string unit (e.g. Sysutils).
External libraries (no source) define their string type accordingly in their
import header [sorry :) ] for their scope, strings are converted based on
this information, if necessary.
If you make it possible for users to define their own string unit (as
override of the general one), many string types are possible.
To clarify (an example; the main program file, not a unit):
...
{$STRING *user defined*}
{$USESTRINGUNIT *some user unit which implements all string ops for the own
string implementation*}
...
The advantage is, that anything compiled from source within a project
(external libraries, too) uses the user defined (=preferred) string type and
no conversion is needed (assuming there is no direct string access, which
should be good programming style nowadays).
[You see, I'm not a friend of the idea, that a string itself contains the
information about its internal type...]
2.
With this design (and most users never thinking about their own string type)
there still should be a defaul fpc string type. This is at least necessary for
string conversions. Any custom string type *must* provide a function to
convert to and from the default fpc string type, but *may* also provide such
to/from other string types.
Now any string can be (automatically) converted to any other, in the worst
case like this:
*user defined* - fpc default - *any other, maybe Ansistring*
There is still the problem, that conversions should be lossless, so the
default string type must be able to handle any character [but that should
obviously be possible anyway]...
... and I really hope that explicit conversions won't be necessary in future
(have I to use GetFilenameUTF8 or GetFilname or ...?? - you know)...
I can't say how much work this would be to implement, but in my eyes a more
complex but flexible solution should be worth it, thats not something you
change everyday...
... with {$STRING ANSI} it would work for any old project, so no problems in
backwards compatibility, although IMO a cut in compatability for the new
string type (supported defines, etc.) - if its necessary and makes things
cleaner - is definitely no problem and even the way to go...
3.
Now, what string type to use as default?
No suggestion from my side, but an suggestion how to quickly and
constructively find the right one.
Make a wiki page e.g. new string type suggestions where within a certain
time, everyone can describe his preferred string type, the best would be a
table with pros/cons...
... the core devs than can decide based on this.
[Basically summarized info of all the posts floating around in the mailing
list]
- So, don't waste your energy one more time, to fight each other in response
to this post, just fill the wiki page :)
[IMHO nobody will ever read all the postings about strings in the mailing
list, there *must* be a summarized overview somewhere]
[Sorry if this wiki page already exists...]
And a last thought from my side:
Please, don't try to stay Delphi compatible no matter what.
IMHO its time for fpc to move forward, not sticking to any (bad) Delphi design
change. Even now its almost impossible to use (modern) Delphi code 1:1 in
fpc, and it certainly won't be better in future. It would be much better to
define a last almost supported Delphi version and then go an own way.
Fpc (and Lazarus even more) shouldn't be reduced to make any Delphi(!)
project crossplatform - and doing the difficult (not to say dirty) work for
Embarcadero to make a Windows-oriented design work on many platforms - it
should be an independant implementation of ObjectPascal (and not Delphi!), in
the optimal case being compatible to Delphi, as long as its possible and makes
sense...
With the above suggestion, it would be even possible to make an own Delphi
compatible string type for Delphi mode.
- And, if the Delphi design really is superior to any other - then lets use it
(unfortunately its not).
Uff, a long post, hopefully at least a little helpful - and constructive.
Certainly many wait for the final decision (including me) - let's hope it will
come in near future... :D
Regards,
d.l.i.w
Re: [fpc-pascal] Strings - suggestions
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
course does only work with {$STRING ANSI} to stay in my example.
Btw.
and uses a general string unit (e.g. Sysutils).
should be (e.g. strutils) :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 the new unicode string. Do you mean really seperated sources or a comiler switch? What's the problem to use the new RTL with Ansistring? I can't see a problem, if it doesn't use direct string access... ... of course you have to compile it accordingly.. so you can choose which string type you need per unit Can a project wide choice override this for *any* unit (3rd party) or will there be conversion going on between the different units? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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 fpc default type? In other words, can I force *all* sources in my project to use the same string type, provided that I know, they don't do direct access? The wiki says [http://wiki.freepascal.org/FPC_Unicode_support], that - shortstring - ansistring - widestring - utf8string - utf16string - utf32string - ucs2string (?) - ucs4string (?) may be supported. So in future I will be able to define any of these for my source (and switch between them), without changing code? Thus: Any function with string as param will be automatically overloaded for all supported string types? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strings - suggestions
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
[fpc-pascal] Documentation
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 strictly limit oneself to 80 chars per line) readability on small screens (mobile). At the same time, I use short single (!) line comments to functions, very much the way pasdoc would use them. For sources in an early state (moving code around etc.) external documentation is really annoying, for the detailed documentation of mature source inline docs are simply unsuitable IMHO. Therefore I would really like to see a feature that combines both approaches, small inline comments, e.g. for IDE tooltips and overview documentation together with the possibility to have more detailed infos in external files. Don't get me wrong, that's not an complaint... ... I don't how much work it would be to extend fpdoc, but I really would like to contribute if I knew where to start [and had some more time...] :) Btw. I really like the lazarus fpdoc GUI... Just my 2 cents, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
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 from ~16MB to ~4MB]. Maybe there is a even stricter make ...-clean, does anybody know? If I find time, I will do this again on trunk and make a proper patch, but I cannot promise and it certainly won't be very soon; if so, I will report it here, anyway. Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
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 will be a working version in swig trunk someday. Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
