[oops, this went out from the wrong email address the first time I tried
to send. Let me try this again, with the address I'm subscribed under]
I'm using a snapshot version of Lazarus, so I have the latest updates to
TAchart including tatools.
I only mention it since it may affect the answers
Hello Developers
I'm a bit puzzled there're 2 units in fpc-xml: xmlcfg and xmlconfg
Both of them declare TXMLConfig class. The interfaces of both classes
seems to be quite identical.
If one of them is up-kept for backward compatibility, shouldn't it be like:
[code]
unit
xmlcfg;
uses
Adem schrieb:
Trouble is, I am not familiar enough with the internals of FPC source
tree; meaning I don't even know where to begin looking for the relevant
files in the FPC tree.
Could someone point me in the right direction please.
I had the same question some time ago, and was told that
Graeme Geldenhuys schrieb:
It should be per user, regardless of files. But that may result in conflicts
with SVN, even if only tabs are used to indicate indentation levels.
And that is one of the things Elastic Tabstops will resolve (prevent).
Yet each developer will have there preferred
Sven Barth schrieb:
But you might try the parser in packages/fcl-passrc which is used inside
the fpdoc tool. It also has it's own (small) wiki page here:
http://wiki.freepascal.org/fcl-passrc
Is it a bug in the source or in the wiki engine, that the first
essential links are for
Adem schrieb:
That means that as soon as an error is encountered, the parser stops
parsing. That in turn means that everything below the error will not be
formatted.
I am aware of that.
But, I am hoping to modify the FPC parser/tokenizer so that instead of
it deciding whether to stop, it
Michael Van Canneyt schrieb:
Using the parser/scanner from the compiler is an impossible task,
they are impossible to separate.
There's nothing impossible in software ;-)
It's a matter of refactoring, and whether the refactored code will be
accepted by the FPC team. First expected rejection
Florian Klaempfl schrieb:
Would I have your blessing if I proposed a bounty to unentwine them so
that each one of those major modules becomes objects in tehir own right
--commnicating with one another through public/published events and
properties.
15 years ago I had similiar dreams. Within
Adem schrieb:
Maybe someone would step in to modularize the scanner and the parser
functionalities (maybe the compiler too).
It looks feasable to me, starting with fpc/compiler/parser.pas.
DoDi
--
___
Lazarus mailing list
Florian Klaempfl schrieb:
BTW: We had this discussion ten years ago already when fpdoc was made
and it was decided to write a separate parser after failed attempts to
use fpc's frontend.
Just a question: AFAIR at that time the parser was an automaton, created
by some lex/yacc port. At that
dmitry boyarintsev wrote:
Hello Developers
I'm a bit puzzled there're 2 units in fpc-xml: xmlcfg and xmlconfg
xmlconf is the actual one. xmlcfg is unable to properly handle non-ascii data.
Maybe it's a good idea to declare it deprecated by now.
Both of them declare TXMLConfig class. The
On 2010-05-29 06:42, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Using the parser/scanner from the compiler is an impossible task,
they are impossible to separate.
There's nothing impossible in software ;-)
It's a matter of refactoring, and whether the refactored code will be
Hans-Peter Diettrich schrieb:
Florian Klaempfl schrieb:
BTW: We had this discussion ten years ago already when fpdoc was made
and it was decided to write a separate parser after failed attempts to
use fpc's frontend.
Just a question: AFAIR at that time the parser was an automaton, created
On Sat, 29 May 2010, Hans-Peter Diettrich wrote:
So I simply don't think
that this can be achieved in a reasonable time. IMO the effort to do so
should be spent in existing pascal parsers.
Just the number of existing Pascal parsers suggests to me that time is spent
*better* in a front-end
Hans-Peter Diettrich schrieb:
Michael Van Canneyt schrieb:
Using the parser/scanner from the compiler is an impossible task,
they are impossible to separate.
There's nothing impossible in software ;-)
Yes, but within a reasonable time and without other penalties :)
It's a matter of
On 28 Mei 2010, at 17:07, Joost van der Sluis wrote:
But they allow you to run a separate application as a daemon? Strange...
That's why I asked for autoshutdown feature in another mail in the other list
(since it's not about lazarus).
Or do you forward requests to another host?
Yes, that's
Marcos Douglas wrote:
On Fri, May 28, 2010 at 12:21 PM, Marco van de Voort mar...@stack.nl wrote:
In the case of FPC on windows, best to install the last release
(2.4.0/win32), take a copy of that dir, and copy the handcompiled snapshot
over it.
On *nix you don't need the release so much, and
On 29 May 2010 06:41, Hans-Peter Diettrich wrote:
for documentation or other purposes. But when this is no more true, the
discussion could be resurrected?
So what are the main reasons nobody wants to use the fcl-passrc
parser? Except the obviously lack of some language syntax - which I
think
On 29 May 2010 05:02, Hans-Peter Diettrich wrote:
And that is one of the things Elastic Tabstops will resolve (prevent).
Yet each developer will have there preferred indentation amount.
I doubt that elastic tabstops really can do that. It must be context
sensitive, what introduces
Adem,
fpc-passrc was recommended by many. Is there some reason you don't want to use
it? It can parse all fcl sources which proves it is good. Or, maybe I have
missed something here...
There is one more parser around, in codetools. It is scanning and parsing code
in the background when you
On Sat, May 29, 2010 at 2:30 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
So what are the main reasons nobody wants to use the fcl-passrc
parser?
Lack of the expression parser?
thanks,
dmitry
--
___
Lazarus mailing list
On 28 May 2010 21:38, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 28 May 2010 18:15, waldo kitty wrote:
i don't know if i can retrain my thumb to hit the TAB instead of the space
bar as it has been trained to do these past 30+ years i've been coding :? :P
:-)
The sad thing is, the
On 29 May 2010 14:53, Henry Vermaak wrote:
I use the tab key for indentation, never alignment (after text). This
way it always looks good for everyone's tab-space settings. In the
very rare case I need alignment, I'll use spaces. You are writing
code, after all, not designing a powerpoint
On Fri, May 28, 2010 at 11:48:45AM -0400, waldo kitty wrote:
On 5/28/2010 05:03, Bee Jay wrote:
On 27 Mei 2010, at 18:56, Michael Van Canneyt wrote:
I don't think we will do this. It will require too many changes.
Yes, I've seen the code. fpWeb has a very tight dependency to other fcl
On Sat, May 29, 2010 at 12:43:48AM +0400, dmitry boyarintsev wrote:
On Fri, May 28, 2010 at 11:06 PM, Adem listmem...@letterboxes.org wrote:
Would I have your blessing if I proposed a bounty to unentwine them so that
each one of those major modules becomes objects in tehir own right
On Sat, May 29, 2010 at 06:41:12AM +0200, Hans-Peter Diettrich wrote:
Florian Klaempfl schrieb:
BTW: We had this discussion ten years ago already when fpdoc was made
and it was decided to write a separate parser after failed attempts to
use fpc's frontend.
Just a question: AFAIR at
On 29 May 2010 15:20, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 29 May 2010 14:53, Henry Vermaak wrote:
I use the tab key for indentation, never alignment (after text). This
way it always looks good for everyone's tab-space settings. In the
very rare case I need alignment, I'll
On Sat, May 29, 2010 at 12:30:44PM +0200, Graeme Geldenhuys wrote:
On 29 May 2010 06:41, Hans-Peter Diettrich wrote:
for documentation or other purposes. But when this is no more true, the
discussion could be resurrected?
So what are the main reasons nobody wants to use the fcl-passrc
On Fri, May 28, 2010 at 10:06:37PM +0300, Adem wrote:
On 2010-05-28 21:50, Florian Klaempfl wrote:
It might be possible but the fpc scanner/parser are rather interwinded
with other parts of the compiler, just to name an example: pmodules.pas
parses units and programs but controls also
On 29 May 2010 16:20, Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 29 May 2010 17:08, Henry Vermaak wrote:
if you do this. Personal preference, of course The elastic tab stops
are clever, but you are limiting yourself to editors that support
them.
A rather weak statement I think.
On Fri, 2010-05-28 at 22:23 +0200, Graeme Geldenhuys wrote:
On 28 May 2010 21:06, Adem wrote:
I can guess that it would be hard to do, but I feel it will be absolutely
impossible without your (and the rest of compiler team's) blessing.
All I can say is: Good Luck!
I found a Oil
On 2010-05-29 18:14, Marco van de Voort wrote:
On Fri, May 28, 2010 at 10:06:37PM +0300, Adem wrote:
On 2010-05-28 21:50, Florian Klaempfl wrote:
It might be possible but the fpc scanner/parser are rather interwinded
with other parts of the compiler, just to name an example:
On Sat, May 29, 2010 at 17:00, Rick r...@sloservers.com wrote:
There are several things I'd like to do with tachart that I have not yet
been able to figure out how to do.
Easy one: how can I change the thickness and color of the reticule?
Not so easy, unfortunately.
Currently, you can hack in
On Sat, 29 May 2010, Marco van de Voort wrote:
On Fri, May 28, 2010 at 10:06:37PM +0300, Adem wrote:
On 2010-05-28 21:50, Florian Klaempfl wrote:
It might be possible but the fpc scanner/parser are rather interwinded
with other parts of the compiler, just to name an example: pmodules.pas
On 05/29/2010 09:35 AM, dmitry boyarintsev wrote:
I'm a bit puzzled there're 2 units in fpc-xml: xmlcfg and xmlconfg
Both of them declare TXMLConfig class. The interfaces of both classes
seems to be quite identical.
snip
LCL also provides its own TXMLConfig at Laz_XMLCfg (with the same
Hello Dmitry,
Shouldn't this thread be on fpc-devel?
And also, I would recommend removing the obsolete unit completely.
thanks,
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Thanks Sergei for the explanation.
On Sat, May 29, 2010 at 9:11 PM, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
Shouldn't this thread be on fpc-devel?
Yes and no. I was interested about what to use for LCL development.
Also attn at the subject also denotes to fpc-devel
On Sat, May 29, 2010 at 07:05:31PM +0300, Adem wrote:
That doesn't mean the various parsers could be better synchronized, and I
think something can be done there. But I think it would yield more to
integrating fcl-passrc into the testsuite, and thus document the boundery
conditions of
On 29 May 2010 17:52, Henry Vermaak wrote:
Wtf? It's hundred percent true. Is that your definition of weak?
If your editor doesn't support elastic tabstops, and you rely on
elastic tabstops for alignment, the code won't line up properly.
What I am saying is that Tab characters are supported
Please excuse a dumb question, but I've done very little graphics
programming and so far haven't found an answer in the docs or via Google.
I want to be able to save a bitmap representation of a form's client
area, i.e. including status line at the bottom but excluding main menu
and frame, to
I don't think you will find a solution using only LCL code, because
the canvas doesn't include child windowed controls. You could even try
to rebuild the image using the canvases, but that won't guarantee that
it is the exact image on the screen.
I did a short googling and there is a Qt routine
On 29 May 2010 23:20, Felipe Monteiro de Carvalho wrote:
http://stackoverflow.com/questions/1774222/taking-screenshot-of-a-specific-window-c-qt
You could see the Qt source code to check what this does for the
Windows part of the solution.
Here is another way of doing it under Windows - as
Waldo Kitty wrote:
On 5/28/2010 05:03, Bee Jay wrote:
On 27 Mei 2010, at 18:56, Michael Van Canneyt wrote:
I don't think we will do this. It will require too many changes.
Yes, I've seen the code. fpWeb has a very tight dependency to other fcl
packages. Poor Delphi people. ;)
serve's'em
dmitry boyarintsev schrieb:
And also, I would recommend removing the obsolete unit completely.
I must agree that marking the unit as deprecated should be enough.
It won't break the existing code using the old file, but would also
notify maintainers that they should update.
I'd move such
Graeme Geldenhuys schrieb:
A very common case where comments are used after code is in file
structures and header translation.
Which can hardly be automized for any real class, having methods with
argument lists, properties etc.
I don't want to change my coding style for the sake of using
Michael Van Canneyt schrieb:
Well, given the recent breakage because of the support for 'deprecated',
I started on a test file, but I think that a better and more fundamental
approach is needed. My idea was to create a large number of small files
with code fragments. The test application reads
Alexander Klenin wrote:
So let's take you as a representative sample ;-)
Do you feel it is justified to remove these
properties to get multiple reticules and TReticule.Pen property instead?
As I was browsing through the code last night, I was actually surprised
that the reticule pen property
Alexander Klenin wrote:
so I implemented it now -- see TConstantLineDragTool
and toolsdemo at r25751
I just checked it out and played with the demo.
WOW! I like :) The tools add-on was a brilliant idea, if these recent
tools are any indication.
I tried vertical and horizontal lines,
On 30 Mei 2010, at 07:30, Dimitri Smits wrote:
and that was just in D7 already!
Does it support Linux? Kylix? What about 64 bit servers? :P
God (and Delphi 2010 buyers) know(s) what they have in there nowadays!
Are they using those tools? No? Why?
On the other hand, why anybody would want
On Sun, May 30, 2010 at 14:02, Rick r...@sloservers.com wrote:
I am concerned about one thing, though: It looks like the tool will move
ANY TConstantLine series
on the chart. I would suggest a property in the drag tool that is a list of
movable lines. Perhaps
if empty, the default could
On Sun, May 30, 2010 at 12:13, Rick r...@sloservers.com wrote:
Alexander Klenin wrote:
As I was browsing through the code last night, I was actually surprised that
the reticule pen property
was not already made public in TAChart. I'll have the check out the
LineDragTool--it sounds like it
51 matches
Mail list logo
