Re: [fpc-pascal] Please someone explain this to me
Michael, a question:
How much of the interface section of units differ per platform? Is it 1% of
the code? Is it 5% of the code? With the xml2 unit it's 0%, yet all of the
declarations are nested in several layers of include files:
http://cache.getlazarus.org/images/xml2-unit.gif
http://cache.getlazarus.org/images/xml2-include.gif
At what point does putting every interface declaration a {$i
includemeh.inc} stop making sense?
Okay, so why do I care? Because I want to be able to read what "stuff" is
in a unit by the normal means, and that is to scroll through the
declarations of a unit and not be forced to open 40 or more {$i
includemeh.inc} files. I want to be able to Ctrl+F in a file and find
stuff. I appreciate being able to just read interface declarations to
learn/understand what exactly a unit is declaring. Multiple nested includes
and no real unit interface declarations is to antithetical most all users
ability to learn or understand what is available.
With regards to regions and the RTL, if you for some reason are not using
Lazarus they don't hurt anything. Instead they would act like a comment
saying "Hey, these declarations are implemented in sysint.inc", which has
the same impact as saying {$i sysinth.inc}. The difference is you can
actually read the declarations.
And then there is the LCL, which seems to have borrowed the idea of {$i
includemeh.inc}. The first declarations of the Controls unit does a {$I
controlconsts.inc} and simply lists constant component message identifiers.
Why does this need to be an include file? Put it in the Controls unit
interface section, and if you want throw a region around it as a comment.
You get the added bonus to be able to fold if you're using Lazarus, but if
not, hey you get a nice comment.
I have a feeling that if I ran some analytics on the interface section of
the RTL I would find > 99.5% of the interface section declarations remain
the same across all platforms. I also have the feeling that if an accurate
99.5% analysis was presented here some of you would remain adamant that
unit interface declarations should NOT contain actual interface
declarations, rather multiple nested include files should contain them.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016, Graeme Geldenhuys wrote: On 2016-02-10 19:20, Michael Van Canneyt wrote: You just need to look at the system or sysutils units from recent delphis to see why include files are the better option, As someone that doesn't have access to recent Delphi versions, would you mind sharing a small example if you can. I'm not at all surprised by your comment though. From the messages I have seen about Delphi these days, not many customers are happy with Delphi's "progress". It sounds like every release is more like a patch-job to get the next set of bullet points filled for the next release. No regard for the language or quality control. I cannot share code, obviously, but I'll say that the code is a big mess of IFDEFS, used in what seems to me an inconsistent manner (if there is any logic, I fail to see it). Lazarus has understanding of IFDefs, but the Delphi IDE does not (just as it does not understand include files), killing the code navigation, making it hard to navigate or understand these unit. I normally do not visit these units, so it doesn't harm me, but when I by accident ended up there I remarked it... I think the problem is more on the poor guys that must maintain it :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016, Anthony Walter wrote:
What about the interface section includes and {$region} option I described.
Does anyone care to discuss that option? Please go back a few messages and
read what I wrote.
It is not an option.
As said: not everyone uses lazarus.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016, Anthony Walter wrote: For those who didn't understand what I meant by using regions in the interface section rather than include files, here is an image of what is essentially in SysUtils currently: You are forgetting that not everyone uses Lazarus. The RTL is part of Free Pascal. For RTL work, I never use lazarus, but a plain old text editor, joe. It doesn't know regions, it doesn't know mainunit etc. The RTL is organized for the benefit of its maintainers, not the users. It's a proven design since 20 years as explained by Marco and Sven. The fact that you're the first to complain in 20 years (at least I cannot remember any others, and I've been around for a while) gives you an indication of the relative importance of your problem. Lazarus IDE shows a tooltip when you hover over an identifier with the mouse. I suspect it will take one on the team less than 10-minutes to add the unit name to the tooltip, in addition to the package and source file name. Which is, after all, your original problem which is then solved ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
On 11/02/2016 02:47, Luiz Americo Pereira Camara wrote: I compiled a program with -Xg (generating an external debug info file *.dbg) And deployed the executable without the debug info When an exception occurs i get a backtrace with only addresses How to get the line number, method names of the backtrace using the external debug file? I don't know how to do it with an external dbg file. (though gdb might be able do to that) But the following works (at least if the exe is not compiled for dynamic relocation) - Build an exe with debug in the exe. - Make a copy and strip debug from the copy - Ship the copy Lazarus has "Leaks and Traces" in the view menu. Paste the trace, and then use the Button "Resolve" to load the exe with symbols. That should do. It uses a copy of the code found in infodwrf and "whatever the name of the unit reading stabs". Both of them (afaik) dont do dbg files. If someone has info how to add that, well as for gdb, you can open your exe (and if gdb finds the dbg file, then that should be fine.) if gdb loaded your dbg info, then you can do something (not tested/from memory) info symbol 0x54320 and it prints what is at that address. Do that for each address in the trace. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
2016-02-10 23:59 GMT-03:00 : > On 02/10/2016 09:47 PM, Luiz Americo Pereira Camara wrote: > >> >> How to get the line number, method names of the backtrace using the >> external >> debug file? >> > > my first eWAG gut response is to distribute the DBG file with the > executable... > > Thanks But that will not help, the backtrace will still be generated without info, just address Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
On 02/10/2016 09:47 PM, Luiz Americo Pereira Camara wrote: Hi, I compiled a program with -Xg (generating an external debug info file *.dbg) And deployed the executable without the debug info When an exception occurs i get a backtrace with only addresses How to get the line number, method names of the backtrace using the external debug file? my first eWAG gut response is to distribute the DBG file with the executable... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Recovering info from a backtrace with an external debug file
Hi, I compiled a program with -Xg (generating an external debug info file *.dbg) And deployed the executable without the debug info When an exception occurs i get a backtrace with only addresses How to get the line number, method names of the backtrace using the external debug file? Thanks in advance Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
For those who didn't understand what I meant by using regions in the
interface section rather than include files, here is an image of what is
essentially in SysUtils currently:
http://cache.getlazarus.org/images/sysutils-include.gif
Notice the unit file is opened the almost none of what it declares is
visible. Instead the declarations are hidden in layers of header include
files. This makes it difficult to open a file and see what functions,
variables, classes, or types are available and can be used. And I might add
that this is problem isn't exclusive to the SysUtils unit.
Now here is an example where the interface section includes are moved to
regions:
http://cache.getlazarus.org/images/sysutils-region.gif
Notice you can actually browse through the types and other declarations by
simply scrolling down. I understand there might be situations where the
interface of a unit might differ per platform, but surely those situations
are in the minority, and they could either be placed in {$IFDEF} directives
or just those parts could be put in include files. As it is right now
nearly everything is is include files and nested include files making
browsing source code declarations more difficult than it should be.
It seems like this {$I sysinth.inc} for a header and {$I sysint.inc} for an
implementation harkens to C headers and C implementations, something which
Pascal is supposed to have done away with.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 10.02.2016 21:03 schrieb "Anthony Walter" :
> But to ask again, what's the purpose of using include files for the
interface section of units when most everything in the interface sections
remain unchanged among different platforms? Surely we can move all those
the parts back to the unit interface sections. Perhaps if you want to match
up a single interface declaration with a several include implementations, I
can see that as one method of organization, but wouldn't {$region names} in
the interface declarations {$endregion} would be an improvement over many
interface section include files? This way I can actually scroll through the
interface, ctrl+f through the interface, and not be forced to ctrl+enter on
interface section includes to see what is being declared.
Looks like you haven't actually looked at how the RTL is structured. It is
the way it is for a reason and that is both maintainability and
extensibility and yes that also includes the interface. You just need to
look at the TJumpBuf record used for setjump()/longjump(), it must be
different for each target processor and I honestly don't want that clutter
in the interface section, because when you need to work at those parts
you'll lose the overview and code folding won't help you then.
In short: the RTL will stay as it is, because it's a proven design without
better alternatives available.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
In our previous episode, Tomas Hajny said: > at platform level, sometimes it makes sense to use a common include file > for a set of targets sharing a common set of characteristics (various MS > Windows targets or Unix targets) in order to simplify the maintenance, > etc. Trying to cover that in one common place would result in something > completely unreadable and unmaintainable - actually much worse compared to > the current situation. Indeed, the include stuff is not a linear thing. Generic Unix includes include (are parameterized) by target specific includes like the earlier named ptypes.inc. And then you get to the bit that the syscall targets are switchable to libc etc. The original design document for the *nix RTL (originally (c) dec 2002) already had a section about why includefiles: http://www.stack.nl/~marcov/unixrtl.pdf One thing to particularly highlight: many *nix includefiles are used in the /implementation/ of units below the baseunix unit level, while they only become public on the unixtype/baseunix level and below (see pic in above doc) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, February 10, 2016 22:04, Anthony Walter wrote:
> What about the interface section includes and {$region} option I
> described.
> Does anyone care to discuss that option? Please go back a few messages and
> read what I wrote.
I don't get your $region idea, but as a maintainer of one of the FPC
targets, I can tell you that there are differences also in the interface
sections. Just as an example - unit system needs to combine parts which
are completely common (solved using common include files) with parts which
are platform-specific (take e.g. the DirectorySeparator or LineEnding as
examples). Sometimes there are differences at the target level, sometimes
at platform level, sometimes it makes sense to use a common include file
for a set of targets sharing a common set of characteristics (various MS
Windows targets or Unix targets) in order to simplify the maintenance,
etc. Trying to cover that in one common place would result in something
completely unreadable and unmaintainable - actually much worse compared to
the current situation.
Tomas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
What about the interface section includes and {$region} option I described.
Does anyone care to discuss that option? Please go back a few messages and
read what I wrote.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 2016-02-10 19:45, Juha Manninen wrote: > Thus, Lazarus editor fully understands include files unlike Delphi' editor. The knock-on affect of include files, is that pascal parsers are much more complex to write. Luckily we already have quite a few pascal parsers available, which already work with include files and search paths etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, Feb 10, 2016 at 3:32 PM, Graeme Geldenhuys < mailingli...@geldenhuys.co.uk> wrote: > On 2016-02-10 19:20, Michael Van Canneyt wrote: > > You just need to look at the system or sysutils units from recent > delphis to > > see why include files are the better option, > As someone that doesn't have access to recent Delphi versions, would you > mind sharing a small example if you can. > It would be odd if they're using includes heavily. It feels like namespaces should've resolved the problem. Thus includes are replaced by namespaces, since it **should** keep unit-like code structure. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 2016-02-10 19:12, Anthony Walter wrote: > I think the thing is I can't help but feel there should be a better system > for organizing implementations for different systems. Often some clever usage of design patterns can help, but more often than not, using include files are just a faster and easier solution to implement. Make no mistake, include files (when used correctly) is a pretty powerful option too. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 2016-02-10 19:20, Michael Van Canneyt wrote: > You just need to look at the system or sysutils units from recent delphis to > see why include files are the better option, As someone that doesn't have access to recent Delphi versions, would you mind sharing a small example if you can. I'm not at all surprised by your comment though. From the messages I have seen about Delphi these days, not many customers are happy with Delphi's "progress". It sounds like every release is more like a patch-job to get the next set of bullet points filled for the next release. No regard for the language or quality control. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
> Sven Barth hat am 10. Februar 2016 um 15:09
> geschrieben:
> [...]
> > The {%...} directive is a comment in other contexts and can be used safely.
>
> What about include files included by other include files?
That is no problem for the MainUnit directive.
The directive tells the codetools the default start file of the scattered unit.
If the IDE has parsed a unit which uses the include file, the MainUnit directive
is ignored.
If a file is included by multiple units, you can give a common unit.
Basically it is just a convenient fallback.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Oh and when the MainUnit directive is included at the top of an include file, how does this affect include files where the declaration is another include files, or include files which next other include files? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Juha,
Okay then, maybe everyone should make a mental note and remember add the
MainUnit directive to the include files they are editing if it doesn't
already exist.
But to ask again, what's the purpose of using include files for the
interface section of units when most everything in the interface sections
remain unchanged among different platforms? Surely we can move all those
the parts back to the unit interface sections. Perhaps if you want to match
up a single interface declaration with a several include implementations, I
can see that as one method of organization, but wouldn't {$region names} in
the interface declarations {$endregion} would be an improvement over many
interface section include files? This way I can actually scroll through the
interface, ctrl+f through the interface, and not be forced to ctrl+enter on
interface section includes to see what is being declared.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, Feb 10, 2016 at 9:12 PM, Anthony Walter wrote: > And could the IDE be enhanced to should which unit is > ultimately including a file? Obviously the CodeTools already knows, it was > able to deduce the identifier exists and that it has a declaration by > looking through the units in the uses clause in the current unit. Couldn't > something therefore display the unit name in IDE, possibly in the include > file's source code tab (e.g. system.pas - dynlibh.inc)? Maybe you did not fully understand what the MainUnit directive does. It allows you to jump between the Pascal unit and the include file in any situation, just as if they were one single file. It works also if you opened first an include file from a search window. The other way around (unit -> include file) it works even without a MainUnit directive. Thus, Lazarus editor fully understands include files unlike Delphi' editor. In other words you can always do Ctrl-Shift-Up in a method / function and it does the right thing. You don't need to worry about if your cursor is on a unit or include file source. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016, Anthony Walter wrote: Thanks everyone for taking notice in the include file problem. I'm note sure about other people, but to me its a problem that sometimes limits me from following the source code. Ideally there should be one file per unit with an interface section and an implementation section and no include files, but I can understand how the multi-platform features of FPC and Lazarus necessitate using include files. You just need to look at the system or sysutils units from recent delphis to see why include files are the better option, if you consider that FPC has far more platforms to support. That said, the MainUnit directive is easily added to the sources. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Thanks everyone for taking notice in the include file problem. I'm note sure about other people, but to me its a problem that sometimes limits me from following the source code. Ideally there should be one file per unit with an interface section and an implementation section and no include files, but I can understand how the multi-platform features of FPC and Lazarus necessitate using include files. I think the thing is I can't help but feel there should be a better system for organizing implementations for different systems. For example, many units use include file in their interface sections. Is that really necessary and what does that achieve other than making it more difficult to understand what's being declared? And could the IDE be enhanced to should which unit is ultimately including a file? Obviously the CodeTools already knows, it was able to deduce the identifier exists and that it has a declaration by looking through the units in the uses clause in the current unit. Couldn't something therefore display the unit name in IDE, possibly in the include file's source code tab (e.g. system.pas - dynlibh.inc)? Thanks for considering this as an issue. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 10.02.2016 15:55 schrieb "Juha Manninen" : > > On Wed, Feb 10, 2016 at 4:09 PM, Sven Barth wrote: > > What about include files included by other include files? > > Ok, that is a nasty situation. I think it should be avoided. Welcome to the RTL. ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
On Wed, 10 Feb 2016, Felipe Monteiro de Carvalho wrote:
Hello,
Taking advantage that we are already talking about SQL how to
upload the contents of a blob field?
I tried using a SELECT to get the field +
TBlobField(FQuery.FieldByName('Data')).LoadFromStream but it raises an
exception that "Dataset is not in insert or edit mode"
I see that I could write the data in hexadecimal in the SQL query, but
that would be slow...
So what is the proper way to use TBlobField.LoadFromStream?
Or should I use params + an SQL statement with question mark:
lSQL := Format('UPDATE %s SET ? WHERE ID=''%d''', [lTableName, AItemNr]);
Both ways are possible.
Qry.sql.text:='your select';
Qry.Open;
// Navigate to record you want to modify
Qry.Edit; // Go to edit mode.
TBlobField(FQuery.FieldByName('Data')).LoadFromStream(YourStream))
Qry.Post; // Save changes
Or
Qry.Sql.Text:='update tablename set (yourfield=:yourfield) where ID=something';
Qry.ParamByName('yourfield').LoadFromStream(YourStream)
Qry.ExecSQL;
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
Hello,
Taking advantage that we are already talking about SQL how to
upload the contents of a blob field?
I tried using a SELECT to get the field +
TBlobField(FQuery.FieldByName('Data')).LoadFromStream but it raises an
exception that "Dataset is not in insert or edit mode"
I see that I could write the data in hexadecimal in the SQL query, but
that would be slow...
So what is the proper way to use TBlobField.LoadFromStream?
Or should I use params + an SQL statement with question mark:
lSQL := Format('UPDATE %s SET ? WHERE ID=''%d''', [lTableName, AItemNr]);
?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
Nevermind... Ninja'd. On Wed, Feb 10, 2016 at 10:36 AM, Stephen Chrzanowski wrote: > Did you output the iSQL string to a console or a text file or even a > message box to verify that what you're passing in is actually what you > expect? > > If the engine is coming back with a problem "Near Select" then there is > something wrong either before the string, or after Select. GetTableName > may be returning something the query isn't expecting. > > On Wed, Feb 10, 2016 at 10:00 AM, Felipe Monteiro de Carvalho < > felipemonteiro.carva...@gmail.com> wrote: > >> Result in sqlite3 console: >> >> sqlite> SELECT * FROM "Header_0" WHERE ID=0; >> 0|0|0|0|18| >> >> -- >> Felipe Monteiro de Carvalho >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
Did you output the iSQL string to a console or a text file or even a message box to verify that what you're passing in is actually what you expect? If the engine is coming back with a problem "Near Select" then there is something wrong either before the string, or after Select. GetTableName may be returning something the query isn't expecting. On Wed, Feb 10, 2016 at 10:00 AM, Felipe Monteiro de Carvalho < felipemonteiro.carva...@gmail.com> wrote: > Result in sqlite3 console: > > sqlite> SELECT * FROM "Header_0" WHERE ID=0; > 0|0|0|0|18| > > -- > Felipe Monteiro de Carvalho > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
On Wed, Feb 10, 2016 at 1:20 PM, Michael Van Canneyt wrote: > You used sql.add. Did you do sql.clear first ? > Otherwise you'll be sending 2 sql statements as 1. ok, that fixed the issue, thanks! -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016, Juha Manninen wrote: On Wed, Feb 10, 2016 at 4:09 PM, Sven Barth wrote: What about include files included by other include files? Ok, that is a nasty situation. I think it should be avoided. Happens regularly in the RTL units, though. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
On Wed, 10 Feb 2016, Felipe Monteiro de Carvalho wrote: On Wed, Feb 10, 2016 at 12:45 PM, Michael Van Canneyt wrote: Did you try clearing SQL first ? What do you mean? You used sql.add. Did you do sql.clear first ? Otherwise you'll be sending 2 sql statements as 1. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
Result in sqlite3 console: sqlite> SELECT * FROM "Header_0" WHERE ID=0; 0|0|0|0|18| -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
On Wed, Feb 10, 2016 at 12:45 PM, Michael Van Canneyt wrote: > Did you try clearing SQL first ? What do you mean? -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, Feb 10, 2016 at 4:09 PM, Sven Barth wrote: > What about include files included by other include files? Ok, that is a nasty situation. I think it should be avoided. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EDatabaseError on SELECT
On Wed, 10 Feb 2016, Felipe Monteiro de Carvalho wrote:
Hello,
I'm posting here because this seams to be an issue with using sqldb,
my SQL seams to be ok.
I create a table and add a row to it, but when trying to read that
same row using SELECT I get EDatabase error with message "Syntax error
near SELECT".
That means the engine throws an error, this is not SQLDB throwing an error.
I create the Table and add a row to it like this:
FSQLConn := TSQLite3Connection.Create(nil);
FSQLTran := TSQLTransaction.Create(nil);
FQuery := TSQLQuery.Create(nil);
FQuery.DataBase := FSQLConn;
FQuery.Transaction := FSQLTran;
.
lTableName := GetTableName(AListNr, dtkHeader);
lSQL := Format('CREATE TABLE "%s"( "ID" INTEGER,'+
' "Block_NrOfItems" INTEGER, "Block_ParentList" INTEGER,'+
' "Block_IndexIn_ParentList" INTEGER, "Block_Kind" INTEGER,'+
' "Block_Name" TEXT);', [lTableName]);
FSQLConn.ExecuteDirect(lSQL);
lSQL := Format('INSERT INTO %s (ID, Block_NrOfItems, Block_ParentList,'+
' Block_IndexIn_ParentList, Block_Kind, Block_Name)'+
' VALUES (%u, %u, %u, %s, %u, ''%s'')',
[lTableName, UINT32_ID_SINGLE_ROW_TABLE,
AData.NrOfItems, AData.ParentList,
IntToStr(AData.IndexIn_ParentList),
AData.Kind, AData.Name]);
FSQLConn.ExecuteDirect(lSQL);
FSQLTran.Commit;
Here is the SELECT with error:
lTableName := GetTableName(AListNr, dtkHeader);
lSQL := Format('SELECT * FROM "%s" WHERE ID=%u', [lTableName,
UINT32_ID_SINGLE_ROW_TABLE]);
FQuery.SQL.Add(lSQL);
Did you try clearing SQL first ?
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] EDatabaseError on SELECT
Hello,
I'm posting here because this seams to be an issue with using sqldb,
my SQL seams to be ok.
I create a table and add a row to it, but when trying to read that
same row using SELECT I get EDatabase error with message "Syntax error
near SELECT".
I create the Table and add a row to it like this:
FSQLConn := TSQLite3Connection.Create(nil);
FSQLTran := TSQLTransaction.Create(nil);
FQuery := TSQLQuery.Create(nil);
FQuery.DataBase := FSQLConn;
FQuery.Transaction := FSQLTran;
.
lTableName := GetTableName(AListNr, dtkHeader);
lSQL := Format('CREATE TABLE "%s"( "ID" INTEGER,'+
' "Block_NrOfItems" INTEGER, "Block_ParentList" INTEGER,'+
' "Block_IndexIn_ParentList" INTEGER, "Block_Kind" INTEGER,'+
' "Block_Name" TEXT);', [lTableName]);
FSQLConn.ExecuteDirect(lSQL);
lSQL := Format('INSERT INTO %s (ID, Block_NrOfItems, Block_ParentList,'+
' Block_IndexIn_ParentList, Block_Kind, Block_Name)'+
' VALUES (%u, %u, %u, %s, %u, ''%s'')',
[lTableName, UINT32_ID_SINGLE_ROW_TABLE,
AData.NrOfItems, AData.ParentList,
IntToStr(AData.IndexIn_ParentList),
AData.Kind, AData.Name]);
FSQLConn.ExecuteDirect(lSQL);
FSQLTran.Commit;
Here is the SELECT with error:
lTableName := GetTableName(AListNr, dtkHeader);
lSQL := Format('SELECT * FROM "%s" WHERE ID=%u', [lTableName,
UINT32_ID_SINGLE_ROW_TABLE]);
FQuery.SQL.Add(lSQL);
FQuery.Open; // <- EDatabaseError
I tested with sqlite3 command line and the same statement issues no
syntax error ...
Any ideas???
lTableName = Header_0
UINT32_ID_SINGLE_ROW_TABLE=0
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Format and Cardinal
Felipe Monteiro de Carvalho wrote on Wed, 10 Feb 2016: lol, thanks for the comprehensive reply, if no one objects I will add a note about this in http://www.freepascal.org/docs-html/rtl/sysutils/format.html That is the wrong place. It has nothing to do with format, it's about the "array of const" construct and applies to any routine accepting such parameters. I just noticed there's an error in the array of const documentation though: at the bottom of http://www.freepascal.org/docs-html/ref/refsu70.html it says that there is no support for qword in array of const, but that's wrong. It's cardinal that is not supported. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
In our previous episode, Juha Manninen said:
[ Charset UTF-8 unsupported, converting... ]
> On Wed, Feb 10, 2016 at 2:01 AM, Vojt?ch ?ih?k wrote:
> > There exists IDE directive
> >
> > {%MainUnit ***.pas}
> >
> > and include files should contain it.
>
> Yes, that is the solution for Anthony's problem. Most include files
> used by LCL units have it but FPC libraries may not.
I think it would be good to add that to most FPC inc files in rtl and fcl
too.
Most usage is straightforward, and can be solved using the directive. Some,
like ptypes.inc are more complicated.
I'll see if I can add some directives in the coming weeks.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Format and Cardinal
Hello, lol, thanks for the comprehensive reply, if no one objects I will add a note about this in http://www.freepascal.org/docs-html/rtl/sysutils/format.html -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 10.02.2016 14:09 schrieb "Juha Manninen" :
>
> On Wed, Feb 10, 2016 at 2:01 AM, Vojtěch Čihák
wrote:
> > There exists IDE directive
> >
> > {%MainUnit ***.pas}
> >
> > and include files should contain it.
>
> Yes, that is the solution for Anthony's problem. Most include files
> used by LCL units have it but FPC libraries may not.
> When the directive is set, Lazarus IDE always knows how to jump
> between interface in Pascal unit and implementation in an include
> file.
> The {%...} directive is a comment in other contexts and can be used
safely.
What about include files included by other include files?
> > But I don't know if there are more units containing the same include
file.
>
> When a big Pascal unit is split into include files then an include
> file is referred from one place only.
> The directive is not meant for generic include files.
>
> The original question about dynlibs remains. I understood with FPC 3.0
> it is not needed but I could not compile without it.
> This has nothing to do with cross-platform code. I am testing with
> Xubuntu + GTK2 as the code is part of LCL-GTK2.
> Actually I still have the RC1 version here:
> $ fpc
> Free Pascal Compiler version 3.0.0rc1 [2015/08/07] for x86_64
> ...
> Could there be such a difference between RC1 and the release?
> Anyway, I added dynlibs there. It is needed at least by FPC 2.6.4
> which we still support for some time.
> Ubuntu people, please test the Unity TTrayIcon feature. I have only
> tested it does not break LCL-GTK2 in other systems. I will install
> Ubuntu + Unity soon.
I must check whether I had done that change before or after the branch...
On non-Windows systems you'll need to include dynlibs at least in the main
project anyway as it is needed to initialize the library manager (just like
cthreads and cwstring).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, Feb 10, 2016 at 2:01 AM, Vojtěch Čihák wrote:
> There exists IDE directive
>
> {%MainUnit ***.pas}
>
> and include files should contain it.
Yes, that is the solution for Anthony's problem. Most include files
used by LCL units have it but FPC libraries may not.
When the directive is set, Lazarus IDE always knows how to jump
between interface in Pascal unit and implementation in an include
file.
The {%...} directive is a comment in other contexts and can be used safely.
> But I don't know if there are more units containing the same include file.
When a big Pascal unit is split into include files then an include
file is referred from one place only.
The directive is not meant for generic include files.
The original question about dynlibs remains. I understood with FPC 3.0
it is not needed but I could not compile without it.
This has nothing to do with cross-platform code. I am testing with
Xubuntu + GTK2 as the code is part of LCL-GTK2.
Actually I still have the RC1 version here:
$ fpc
Free Pascal Compiler version 3.0.0rc1 [2015/08/07] for x86_64
...
Could there be such a difference between RC1 and the release?
Anyway, I added dynlibs there. It is needed at least by FPC 2.6.4
which we still support for some time.
Ubuntu people, please test the Unity TTrayIcon feature. I have only
tested it does not break LCL-GTK2 in other systems. I will install
Ubuntu + Unity soon.
Juha
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Format and Cardinal
Felipe Monteiro de Carvalho wrote on Wed, 10 Feb 2016:
Why does this trigger an range check exception:
var
lNum: Cardinal;
lStr: string;
begin
lNum := High(Cardinal);
lStr := Format('Num=%u', [lNum]);
Format doesn't support integer numbers above High(Integer) ?
Array of const supports longint, int64 and qword, but no cardinal
(Delphi compatibility, and adding it would also mean that all callee
side code for array of const would have to be adapted to deal with
vtCardinal). Cardinal is passed as longint and not as int64, again for
Delphi compatibility and because existing code may behave unexpectedly
should this be changed.
In Delphi modes, for Delphi compatibility, we don't perform range
checking when passing a cardinal to an array of const. In FPC modes,
we do.
I really need to use IntToStr?
That, or typecast the cardinal either to longint or int64, or locally
disable range checking.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Format and Cardinal
Hello,
Why does this trigger an range check exception:
var
lNum: Cardinal;
lStr: string;
begin
lNum := High(Cardinal);
lStr := Format('Num=%u', [lNum]);
Format doesn't support integer numbers above High(Integer) ?
I really need to use IntToStr?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
> So my question is, how do the rest of you deal with include files and
locating the unit including them?
I don't know what "deal" here refers to, so I can't answer that. I seldom
use include files except when I have to deal with what the compiler/rtl
face: platform dependent implementation of certain API in a platform
independent unit. Sometimes I use it to have multiple classes in the same
unit but I want each class to be in their own (include) file. Condition
compilation is used to have interface and implementation in one file and is
included twice in each respective section in the unit.
I use grep to locate the units including them (the directive is either {$I
or {$INCLUDE, no other possibilites), nothing special or complex.
> And also can this system for including files be better implemented, for
> example by some IDE feature to figure this out for you and displaying the
> "owning" units.
For IDE, it's up to them of course. For instance, Lazarus uses its own
codetools for source navigation, nothing from the compiler, if that's what
you mean. It already indexes identifiers where they reside, it won't be
difficult to index all {$I and {$INCLUDE as well. It's just since include
files may be included by more than one files, the navigation must be altered
somehow.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Please-someone-explain-this-to-me-tp5724028p5724039.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Mi, 2016-02-10 at 05:10 -0500, Anthony Walter wrote: > Marc, > > Your suggestions only work if a unit declaring the function is in your uses > clauses. In the scenario I described that is clearly not the case. > > Additionally, and in a different scenario, when the identifier IS defined > and several units are in the uses clause the goto declaration can jump to > an include file without any information pertaining to which of the units is > including the file. To the best of my knowledge there isn't a straight > forward way to figure this out, unless the author add that text to a > comment in the included file which often is not the case. What use case do you plan to handle? If things are so weird as they are reagrding your requirements then build up a search index, there are many crawlers, search engines and the like available. -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 10.02.2016 11:11 schrieb "Anthony Walter" : > > Marc, > > Your suggestions only work if a unit declaring the function is in your uses clauses. In the scenario I described that is clearly not the case. > > Additionally, and in a different scenario, when the identifier IS defined and several units are in the uses clause the goto declaration can jump to an include file without any information pertaining to which of the units is including the file. To the best of my knowledge there isn't a straight forward way to figure this out, unless the author add that text to a comment in the included file which often is not the case. You can alternatively simply try F1, at least as long as you know the identifier. That will either take you to the help or it will open the Code Browser which will search for the identifier. This was also discussed in the following thread on the Lazarus mailing list: http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-February/085631.html Maybe this will help in at least some situations :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Marc, Your suggestions only work if a unit declaring the function is in your uses clauses. In the scenario I described that is clearly not the case. Additionally, and in a different scenario, when the identifier IS defined and several units are in the uses clause the goto declaration can jump to an include file without any information pertaining to which of the units is including the file. To the best of my knowledge there isn't a straight forward way to figure this out, unless the author add that text to a comment in the included file which often is not the case. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 2016-02-10 00:01, Vojtěch Čihák wrote:
> There exists IDE directive
> {%MainUnit ***.pas}
> and include files should contain it.
That is not an include file requirement, plus that functionality is a
Lazarus-only trick. Any other editor and the FPC compiler sees that as a
simple code comment. Plus not all include files include that information
- in fact most I've seen don't.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
My public PGP key: http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Di, 2016-02-09 at 18:46 -0500, Anthony Walter wrote: > Ralf, > > A couple of points. > > 1) As I explained there are times when I, and probably other people as > well, need to find the declaration of a function, constant, record, or some > other identifier. We may not know if the function even exists or has been > declared in Pascal, for example when attempting to use specific APIs > dependent on some external library. In those case my approach is often to > search (grep) files under either my lazarus or fpc folder. If there is some > better way please to find these identifiers, which are not in the help > systems, please let me know. If you are using Lazarus: - put the cursor inside the indentifier - use right mouse key - klick "find declaration of ..." or use key combination ALT-UpArrow When on the console, I don't know. Searching would have to be done with the OS and target cpu in mind, because in many cases that's what switches included files. I did not try yet. There hsa been a thread on the lazaurs list lately, handling the topic of "navigating huge files" or similar. There is a lot of info about what lazarus can do for you regarding search and navigation. -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
