Re: [fpc-pascal] ObjectBinaryToText - how to write only selected property?
On 5 May 2012 18:15, Krzysztof wrote: > I could use RTTI and TypeInfo, but > ObjectBinaryToText can parse property hierarchy > (Propery1.Subproperty1.Color etc). Out of interest, I have written an "extended" RTTI unit which is used in the tiOPF project. All the functions in that unit support what I call "property paths", which means you can get and set properties like 'myobject.Propery1.Subproperty1.Color' on a object. The unit is called tiRTTI.pas, and tiOPF is hosted on SourceForge. The unit handles nil valued sub-properties correctly as well. The tiRTTI unit has minimal dependency on the other tiOPF units, so it will be very easy to make it a pure stand-alone unit. http://sourceforge.net/projects/tiopf/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ObjectBinaryToText - how to write only selected property?
Hi, > @Graeme. I tried download tiOPS source but can't extract archive on > linux. I never had problems with compressed files on linux. Which > format is this? I meant you should be able to simply check-out the tiRTTI.pas unit form the SubVersion source code repository, or browse the repository with your web browser and save the unit to file. I'm not sure what archive you are referring to. > Can you send mi tiRTTI file via e-mail? Done. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit v0.8 release for FPC 2.4.4 & 2.6.0-rc
On 25 May 2012 18:14, Paul Breneman wrote: > I've recently added new releases for Linux and ARM Linux on this page: > http://www.turbocontrol.com/easyfpgui.htm Excellent stuff, thanks Paul. I am planning on getting an Android based smart phone in the next few months. I hope to start looking into Android development too. Your releases have come in very handy for WinCE, and I'm sure the same would apply for the Android platform. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpimage blur
On 31 May 2012 09:06, Mattias Gaertner wrote: > Hi, > > Is there a function to blur an entire fpimage or a rectangular > area? Not a direct function of Tfpimage, but is very easily accomplished using fpcanvas and the various Interpolation methods. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpimage blur
On 31 May 2012 12:35, Mattias Gaertner wrote:
>
> Can you give an example or some pseudocode?
I just moved country, so don't have access to my development pc yet
(still in shipping), so can't get hold of a working code example. So
best I can do is code example from memory... it was something like
this.
Untested code follows...
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, fpcanvas, fpimage, FPReadBMP, FPWriteBMP;
{$R *.res}
type
{ to make Initialize public, though FImage field variable is all we
need access to }
TMyInterpolation = class(TMitchelInterpolation)
public
procedure Initialize(aimage: TFPCustomImage; acanvas: TFPCustomCanvas);
override;
end;
var
img: TFPMemoryImage;
inter: TMyInterpolation;
{ TMyInterpolation }
procedure TMyInterpolation.Initialize(aimage: TFPCustomImage;
acanvas: TFPCustomCanvas);
begin
inherited Initialize(aimage, acanvas);
end;
begin
img := TFPMemoryImage.Create(32, 32);
inter := TMyInterpolation.Create;
try
img.LoadFromFile('testin.bmp');
inter.Initialize(img, nil); { associate the memory image to
interpolation class }
inter.Execute(0, 0, 32, 32); { define rectangle or whole image
and exec interpolation }
img.SaveToFile('testout.bmp');
finally
inter.Free;
img.Free;
end;
end.
-
I hope this gives you the general idea. As I mentioned, I have done
something similar before, and from what I remember, it wasn't to hard
to get working.
Alternatively, AggPas also has many filter/blur/interpolation
functions available. There are a few AggPas demos showing this in
action.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Playing sounds with standard components
Our company uses SDL with good results in our cross-platform projects. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
On 12 June 2012 09:49, wrote: > > > SDL is so easy, it's hardly necessary to create a wrapper. +1 And because SDL is a cross platform framework, there is nothing special to do in your code to get it to work on multiple platforms. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
On 12 June 2012 16:17, silvioprog wrote:
>
> So, how to play audio (wav/mp3) with only SDL framework in Free Pascal?
Simply reading a SDL tutorial or two, will quickly let you understand
the following code. TSoundEngine is just an convenience class we
created to add extra sound events and possibly swap out sound library
frameworks in future - without needing to change our application code.
Simple design pattern practices to simply your application code and
hide complexity.
This is not the complete code, but is the gist of it.
uses
sdl_mixer,
sdl;
const
// Global default extension for sound files. Set up as needed.
SoundExt = '.wav';
type
PSoundBlock = {$IFDEF UseMusic}PMIX_Music{$ELSE}PMIX_Chunk{$ENDIF};
...
{ in our project, this code is in a TSoundPlayer class. Result is of
type PSoundBlock }
Result := {$IFDEF
UseMusic}Mix_LoadMUS{$ELSE}Mix_LoadWAV{$ENDIF}(PChar(aFilename));
if not Assigned(Result) then
SoundEngine.MixError;
...
constructor TSoundEngine.Create;
begin
if SDL_Init(SDL_INIT_AUDIO or SDL_INIT_TIMER) = -1 then
SDLError;
if Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT,
MIX_DEFAULT_CHANNELS, 1024) = -1 then
MixError;
{$IFDEF
UseMusic}Mix_HookMusicFinished{$ELSE}Mix_ChannelFinished{$ENDIF}(@MusicFinished);
end;
destructor TSoundEngine.Destroy;
begin
PlayingStop;
MIX_CloseAudio;
SDL_Quit;
inherited Destroy;
end;
procedure TSoundEngine.PlayingStop;
begin
{$IFDEF UseMusic}
Mix_HaltMusic;
{$ELSE}
Mix_HaltChannel(1);
{$ENDIF}
end;
procedure TSoundEngine.PlayingStart(aMusic: PSoundBlock);
begin
{$IFDEF UseMusic}
if Mix_PlayMusic(aMusic, 0) <> 0 then
MixError;
{$ELSE}
Mix_PlayChannel(1,aMusic, 0)
{$ENDIF}
end;
procedure TSoundEngine.PlayingPause;
begin
{$IFDEF UseMusic}
Mix_PauseMusic;
{$ELSE}
Mix_Pause (1);
{$ENDIF}
end;
procedure TSoundEngine.PlayingContinue;
begin
{$IFDEF UseMusic}
Mix_ResumeMusic;
{$ELSE}
Mix_Resume (1);
{$ENDIF}
end;
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
On 13 June 2012 04:26, silvioprog wrote: > > I tried playing a wav file with this demo in attached, no errors, but > no sound came out. :( You are releasing the TSoundEngine instance to quickly, and don't give SDL chance to initialize fully and play the sound. Simply add a sleep(1000) call [just for demonstration purposes] after you called PlayingStart(), then you will hear the sound. A better idea would be to change your code as the attached unit. Keep the TSoundEngine instance in the form (or as a global variable), so then playing any sounds are instant. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net unit1.pas Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
On 13 June 2012 11:36, silvioprog wrote:
>
> With:
>
> {.$define UseMusic}
>
> I do not hear sound ... :/
I don't know what to say, other than It works here - with or
without the UseMusic define. And as I mentioned, we have a project
that uses SDL a lot, on Linux and Windows, and tested on many versions
of each of those OS'es.
I'm not on my normal development PC now - I'm using a 8 year old P4
Dell laptop with the following setup
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
c:\dev\fpc\2.5.1\bin\i386-win32>fpc -i
Free Pascal Compiler version 2.5.1
Compiler Date : 2011/11/26
Compiler CPU Target: i386
I'm also using Lazarus 0.9.30, but the version of Lazarus shouldn't
make any difference with the SDL support.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
Hi, On 14 June 2012 02:19, silvioprog wrote: > Y!! > > Worked fine with this demo in attached! Glad you got it working in the end. > I found this demo in: ...and if you look carefully, my sample code called the exact same SDL API's in the same order as the demo link your referenced. Anyway, glad you got the sound playing going. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OAuthv1/Twitter library/application ready; was: EncodeURLElement, underscore and RFC3986?
On Thursday, 21 June 2012, Marcos Douglas wrote: > > > I can't clone the sources: > $ git clone https://bitbucket.org/reiniero/fpctwit > Cloning into fpctwit... > fatal: https://bitbucket.org/reiniero/fpctwit/info/refs not found: did > you run git update-server-info on the server? He did say he was using a mercurial repository, not a git one. Regards, Graeme -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Small and not instalable web server for a local Pascal CGI application
On 12 July 2012 15:20, luciano de souza wrote: > localhost, I would like indications about small, not instalable web > servers, ideal for my simple and sharable Pascal CGIs! Does someone > know something about this? Have a look an nYume. It is a small and easy, but fully functional HTTP-server. Multi-threaded, supports CGI and Virtual Hosts. It consists of 4 object pascal units and a total of 1000 lines of code. That's small, and very functional. There is also the HttpServ example of Synapse. Then there is the Aservia project from Powtils. It is based on nYume, but I don't actually know what they changed. http://powtils.googlecode.com/svn/dev/tools/aservia/ I've personally had good success with the nYume project. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
On 16 July 2012 12:16, wrote: > > I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense > to compile in firebird support on that platform. Wrong! >From the Firebird website: "Firebird 2.5 runs on Windows (32- and 64-bit), various Linux versions (32- and 64- bit), Solaris (Sparc and Intel), HP-UX (PA-Risc) and MacOS X. Main development is done on Windows and Linux, so new releases are usually offered first for these platforms, followed by other platforms after a few weeks." http://www.firebirdsql.org/en/downloads/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : Database problem on Solaris SPARC
Hi, On 16 July 2012 12:29, Reinier Olislagers wrote: >> > Yep, and there's a 2.1.4 download at > http://www.firebirdsql.org/en/news/firebird-2-1-4-builds-for-solaris-intel-x86-32-and-64-bits-available-12615/ On a side note: My quoted paragraph doesn't mention FreeBSD, but I have successfully ran Firebird Server & clients under FreeBSD 9.0 on x86, and there are FreeBSD downloads on the Firebird website for 2.1.x and older. So just because the latest version doesn't contain a download for a specific OS+CPU, doesn't make it "not supported". Firebird rocks! :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic messaging in Delphi
On 24 July 2012 15:13, Ryan Joseph wrote:
> procedure InvokeDelegate (delegate: TObject);
> var
> intfDelegate: IMyInterface;
> begin
> ERROR > intfDelegate := IMyInterface(delegate);
> intfDelegate.DoThis(1);
> end;
You could also try the Supports() method. eg:
if Supports(delegate, IMyInterface, intfDelegate) then
intfDelegate.DoThis(1);
>
> {$mode delphi}
> {$interfaces corba}
>
> program Main;
> uses
> MyInterface;
>
> type
> TMyDelegate = class (TInterfacedObject, IMyDelegate)
> procedure DoThis (value: integer);
> end;
By the way, as far as I know TInterfacedObject is a COM Interface
class only. You are telling the compiler that you want to use CORBA
style interfaces, which don't support IUnknown, thus you shouldn't
(can't) use TInterfaceObject which implements IUnknown.
Change that class definition to something like the following if you
are using CORBA interfaces.
TMyDelegate = class(TObject, MyDelegate)
...
end;
And that should work correctly with CORBA style interfaces (which
don't have reference counting built-in).
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling on Raspberry Pi
Hi, On 7 August 2012 11:54, Koenraad Lelong wrote: > The rest of the apps compile fine although I had no possibility to test them > since I don't yet have a suitable video-cable. I had to delay my Raspberry Pi order until I moved to the UK. I can't wait to receive mine now. :-D You mention you compiled all other apps fine. Does that mean including the fpGUI apps? Is so, brilliant - all without me having to do anything in fpGUI. :) As for your problem about compiler defines. I'm not sure, but maybe you could take a look at Lazarus code (if you have Lazarus available). Lazarus has a dialog that shows active compiler defines, but I don't know if they somehow query FPC, or if it is just a bunch of hard-coded compiler defines. Lets hope its not the latter. Anyway to get to that dialog in Lazarus you do: Right click in editor window -> Source -> Unit Information -> Show Codetools Values. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to find a graphic element in the form editor?
On 7 August 2012 13:20, Howard Page-Clark wrote: > Use View | Components (shortcut Ctrl Alt P), and type 'filen' in the filter > edit. Wow, and so we learn something new. :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14 August 2012 09:37, Reinier Olislagers wrote: > Very well, how many people do you think use fpdoc *and* customize > fpdoc.css? Even then, copying fpdoc.css to the bin directory would give > a sensible default, no? I fully agree. I know you are allowed to customise the CSS file, but i don't know of a single project or person that actually done that. The fpdoc program should at least copy in the default fpdoc.css file - because it looks a damn lot better with the default fpdoc.css than without. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14 August 2012 09:43, wrote: > > That we should distribute the file somewhere is something I agree on, but I > do not think it should be in the bin directory; it's not a binary, after > all. +1 Isn't the fpdoc.css auto generated by the fpdoc executable? For some reason I though it was. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
Hi On 14 August 2012 09:54, Reinier Olislagers wrote: > Neither are > fp.ans > fpc.cfg > yylex.cod > program.pt > cvsup.tdf > ... but they still live in my fpc bin directory... :-) Good point. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, This issue has come up before in a fcl-db discussion regarding the Firebird Database, where the libfbclient.so was missing from many Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was available instead. FCL-DB only checks for the unversioned shared libraries, thus your application will probably not run out of the box. I've stumbled across this problem again today with OpenSUSE 12.1 and Synapse where I send emails from inside my applications via a secure SMTP connection. The Synapse library is looking for libssl.so, but by default OpenSUSE only has libssl.so.1.0.0. In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this. Does any body know what is the "most correct" way of handling this? Am I supposed to modify my copies of fcl-db and synapse to look for specific versions of these shared libraries, or should I somehow add a function in my application installation that checks in unversioned shared libraries exist, and if not, try and create those (which would require root access - and might cause problems an client installs). Anybody know of any Linux documentation URL that explain when unversioned shared libraries are used and when not, and how applications are supposed to handle this? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:10, Jonas Maebe wrote: > > The official way to get the unversioned symbolic links is to install the -dev > or > -devel package for that library. Of course, you're not supposed to require > end-users to do that. Yes, I know that bit, but even as a developer, if I don't do actual Firebird or OpenSSL development (I don't work on those project, I simply use there libraries), I don't need to install those libraries. That is why my Ubuntu and OpenSUSE system didn't have the -devel packages for them installed. FCL-db and Synapse dynamically load those libraries on my development machines, so no -devel package requirement. > ... that the linker will hardcode in your application. The reasoning is that > your > application was written and tested against that version of the library, so > letting > it use arbitrary other versions is not a good idea. In a way I understand the reasoning for the unversioned symlink, I just don't know how best to handle it in my apps. I also don't know the rules as to which version the unversioned symlib will normally point to.I know my apps work with Firebird 2.1 and Firebird 2.5, so should I then change fcl-db to look for libfbclient.so.2 or libfbclient.so.2.0 - instead of the unversioned default. Because the unversioned default could very easily point to a v1.x library of Firebird, and that would be untested with my app (it will probably not work). > If you can work with multiple major versions, you can try to dynamically > load them all until you have found one that exists. OK, I'll take a look at this idea. That seems better, because then I know I am trying to load library versions my app is known to work with. I'm not so much concerned about my development system (I can fix that) - I am thinking more in line of when I deploy my apps. I want them to obviously work as easily as possible. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:27, Mark Morgan Lloyd wrote: > Quite a long way from ideal, since it implies that an administrator has to > be involved even if the program is only sitting in an unprivileged user's > home directory (or is a symlink in ~ good enough?). Correct, definitely not ideal. I was just thinking about the $HOME directory. I'll try and play with that now, and see what happens to my apps. Maybe my apps should all have startup scripts that define local LD_LIBRARY_PATH options? > I'm tempted to say that this is a distro issue, and that if an upstream > project (FireBird, OpenSSL, PostgreSQL) normally publishes an unversioned > library that a distro is at fault if it "decorates" it with an appended > version number without providing a symlink chain. They explicitly mention that general runtime libraries should not include the unversioned symlink. Only the -devel packages should include those. That makes me think, why do we then need the unversioned symlink in the first place! Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages OpenSUSE: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Unversioned_packages Ubuntu/Debian: ?? I can't remember the URL now. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:49, Jonas Maebe wrote: > You said that you manually created the symbolic link. I simply explained that > you should > never do that, and instead install the development packages because they will > do that > (correctly) for you. So my applications that I deploy to clients will now require -devel packages? This just doesn't sound sane, sorry. Maybe there is just a fundamental flaw in all distros and how they package software. Initially a great idea (in theory), but in reality it is seriously flawed. > Whether or not it is desirable for the FCL/Synapse units to require an > unversioned > symlink to be present is a separate issue. FCL-DB uses dynamic linking by default, and looks for the unversioned shared library. So what specific Firebird version is the FCL-DB coded too? Because remember, libfbclient.so can point to a v1.x or a v2.x - depending on what -devel package was installed. This uncertain (version mismatch) is what I would like to avoid, plus the fact that my clients now need to install -devel packages too. Maybe I should simply install my apps into /home//. My installer would then ship the required/expected *.so files, and setup the unversioned symlink. My app would then be launched via a script which sets the LD_LIBRARY_PATH to the application directory. My app would then be totally self-contained. This seems like the only way to get around these flawed package management rules and dependencies. > It will point to the library of the version corresponding to the dev/devel > package that has been installed. So one minute it could point to a v1.x library, and the next it could point to a v2.x library. This will surely break many apps that only look at the unversioned symlink. > libfbclient.so.2.0 means Firebird 2.0.x. libfbclient.so.2 means Firebird 2.x. OK, thanks for that. My apps are tiOPF based, and tiOPF uses the bare minimum functionality from each backend database server. Basically just the CRUD (create, read, update and delete) functions. So even though I say our apps use Firebird DB v2.x, it will most probably run on a v1.x system too, but like I said, that would be untested. We only test with v2.x Firebird servers. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 14:39, Jonas Maebe wrote: >> FCL-DB uses dynamic linking by default, and looks for the unversioned >> shared library. So what specific Firebird version is the FCL-DB coded >> too? > > I have no idea, which is why I also said in my first reply: Umm, so ideally the ibconnection.pp unit should really be split into various units with version numbers in their names. That way we will know to which Firebird version they are referring too. eg: ibconnection.pp // old interbase only (eg: Delphi 7) firebird-1.x.pp firebird-2.1.pp firebird-2.5.pp Include files could probably be used to reduce some duplication of code. > As mentioned in my previous replies, applications should never look at the > unversioned link in the first place when dynamically loading a library. OK, for now I'll modify my fcl-db and synapse code to look for the versioned shared libraries that I know I have tested with. eg: libfbclient.so.2 Thanks for all the help guys. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 15:32, Reinier Olislagers wrote: > And you can use the (Firebird/Interbase Services IIRC) API to get the > server version. I seem to remember Ludo's recent addition to FPC has > this functionality. Yes, but you are jumping the gun here! My problem is that I can't even start my app, because the libfbclient.so is missing in every distro I tried. Linux distros (on client PC's at least), do not include the -devel packages by default, so they only have the versioned shared libraries setup. I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package. So why does FCL-DB look at the unversioned *.so by default? Wouldn't it make more sense to change FCL-DB to look for libfbclient.so.2 instead? 2 being the latest major version of Firebird DB, and that is also the latest version that ibconnection.pp was written for. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: linux: should we hard-code versionedorunversioned shared libraries in our apps?
On 15 August 2012 17:42, Ludo Brands wrote: > You can't be connected the 2 at the > same time but that is a run-time issue, not design time. I'm not sure I'm following. Do you mean SqlDB can't connect to two different database at the same time? I can't think that is true, so could you explain this limitation you are talking about. For example, in tiOPF I often connect to multiple databases - migrating data from one database to another. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi,
On 15 August 2012 19:02, Marco van de Voort wrote:
>
> Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ?
I'm sure I can add that, and I'm sure it will work for my Firebird
connections, but other libraries I use don't have such functionality.
I'm trying to get to the bottom of
* Why must developers jump through hoops to get there DB apps to work
* Why did FPC decide to use unversioned shared libraries under linux when
they (fpc developers) clearly know than those -devel packages are
not installed
as standard - thus making deployment of FPC+DB apps unnecessary complex.
Yes it's great that the Firebird dynamic linking unit supports passing
in aditional library names, but why not simply use the correct name as
standard. Other apps that talk to Firebird link to libfbclient.so.2
because that is the latest version of Firebird, and when you install
the standard Firebird Client libraries, only the versioned ones are
installed.
I also believe that the ibconnection.pp unit is coded for Firebird 2.1
and 2.5, so assuming the default shared library (libfbclient.so.2) is
really not a great leap.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 21:53, Sven Barth wrote: > Did you look at the source/makefile or the binary? If the latter then this > is exactly what FPC (or more precisely the linker) does when you statically > link to a shared library Yes, FlameRobin was statically linked. But that's beside the point. It works in FPC is you statically like your SqlDB+Firebird application (though I had a libfbclient.so symlink already), but it fails if you dynamically link that same app. Not to mention that SqlDB defaults to dynamically linked - something myself and others seem to prefer. I just think ibconnection.pp should rather look at the versioned shared library, just like the linker does with static linking. Thus making applications easier to deploy. Is that too much to ask? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 22:10, Marco van de Voort wrote: > Blend perfectly with the distro they are build for, but if changes occur > chances on recovery are slim. Be more specific, what changes? Dynamic linking and Static linking both have there pros and cons. Most seem to prefer dynamic linking, that is why it is the default in ibconnection.pp. Only problem at the moment in FPC is, with dynamic linking it is looking for an unversioned library instead of libfbclient.so.2 (the latest major version of Firebird DB). Making that simple change means apps that are dynamically linked can be just as easily deployed as apps with static linking. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 16 August 2012 04:31, Marco van de Voort wrote: > > It's not a FPC problem, it is a linux problem that apps are not > crossdistribution distributable. My applications ARE all cross-dirstro capable. And they are damn good at running on new and old distros. eg: I have compiled an fpGUI app 6 months ago on Ubuntu 10.04 (32-bit), and ran that app without problems on a 10 year old distro (SUSE 9.0). That should be good enough for most don't you think. Also says a lot about your "fear" regarding Linux library API/Naming/Versioning changes. > Creating a lot of drama if you see a > minor discrepancy here 6 months after release won't benefit anyone. Coming from someone that admitted that they don't release any commercial FPC based applications and only work with Delphi in commercial environment Excuse me if I take whatever you say with a large pinch of salt. > months ago, we'll just rehash this charade in 9 months for some other > library where a new version came out or where naming changed. Library naming seem to be the ONLY consistent thing here. From what I have seen, and what Jonas mentioned, there are well established rules for naming libraries and versioning. So it should be perfectly fine and cross-distro compatible to look for libfbclient.so.2 - which has been the latest Firebird major version for a few years now. If Firebird 3.0 gets released, ibconnection.pp must be upgraded anyway, then the searched library name could be updated at the same time. There is no problem in this working. > Because it is the _only_ fixed point in this whole mess. This sounds all > very smart now, but once .2 will start changing you can explain people how > to fix everything so that designtime components keep working. (and Once again very vague. What do you mean by changing a new v3 Firebird release? In that case libfbclient.so could just as easily point to the .3 library, and any applications which only support 2.x firebird might not work. As Michael stated, unlike other database vendors, Firebird is pretty good at keeping backward/forwards API compatibility, so in theory the v2.x firebird apps should work, but one never knows when it comes to major version number changes. Minor version number changes is a whole different game. Anyway, why bother arguing with someone that doesn't distribute FPC based apps at all. FPC might only be a hobby to you, but for others it is there bread and butter. We need to support apps as best we can, and with that make them run as easily as possible on all supported platforms. This is what I am trying to do here. Anyway, Michael van Canneyt seems to have agreed with my suggestion (if I understood his email correctly) of adding '.2' to the Linux-only library name. Michael is a lot more involved in FPC database work than you. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 16 August 2012 04:39, Marco van de Voort wrote: > > Change in naming, (either root (gds->fbclient) or version numbers) For God's sake!!! The gds -> fbclient was a once off deal after Interbase was released to the open-source world and shortly thereafter retracted that decision. The open source project continued (to Borlands detriment), but to differentiate their work from the commercial Interbase, they changed the library name. A once of deal - as if this happens even second day! F*cken ridiculous argument. As for version numbers... Major version numbers also take long to change. How long has v2 been the major version number in Firebird, FPC, etc? > non > standard directories (the $prefix/lib/mysql/ has been a problem in the > past). MYSQL is a mess, and my discussion about database libraries are limited to Firebird only, as that is the only database we use in commercial work. As for the location of 99.99% of libraries under Linux that is defined by the OS and normally falls under /usr/lib or /usr/lib64, and it has been like that since forever! > And always, always, we work with 6 months to an year latency. If we were > finalizing 2.6.2 now, and a distro had already changed in some devel > version, it will probably not make 2.6.2. Yes, and if you know anything amount maintaining commercial software, you would know that NOBODY (in there right mind) would instantly jump onto a new major version library change. It will probably require some software update, lots of testing, new installs being generated, more testing etc... another 6+ months latency. So again you "fear" something that is not really an issue at all. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 16 August 2012 08:50, Michael Van Canneyt wrote: > The list is endless. So yes, dynamically loading is a good thing. Indeed. I much rather prefer dynamic linking. > So, what is the problem, and what started the whole discussion: the FPC team > (i.e. us) simply chose a poor default for the default library name in > several cases. > > That's all that needs to be changed to get rid of most of the problems and > discussions. Thank you someone understands. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Re: linux: shouldwehard-codeversionedorunversionedshared libraries in our apps?
Hi Michael, On 16 August 2012 14:11, Michael Van Canneyt wrote: > We'll solve the problem, thereby improving sqldb. I will implement it myself > next week: > > * Change default library names to make more sense. > * Implement library loader for cases where the default library > name is not the correct one. I was about to create a patch for ibconnection.pp to add the '.2' part to the *nix (excluding Mac OSX - as per Jonas comment) library name. But from your message you seem to have other ideas too. So should I rather leave it up to you to fix the library name issue with other other modifications? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : [fpc-pascal] Re: linux: shouldwehard-codeversionedorunversioned shared libraries in our apps?
Hi, On 16 August 2012 14:39, Marco van de Voort wrote: > > Then changing the simple default to libfbclient.so.2 is a problem for > designtime, since designtime code doesn't even have the emergency > initializeibase60 workarounds as option. Lazarus will also start to look for > .2. I thought this is the FPC mailing list?? Lets not bring the Lazarus IDE limitations/usage into this discussion. Not everybody here uses Lazarus IDE, and definitely not the RAD-style dropping components on forms, and hard-coding field names into your GUI layer. > Assume that at some point a distro decides to call it .2.1 or something, Please re-read Jona's earlier reply. There is a set naming standard for libraries in Linux (yes their does actually seem to be some standards that distros adhere too). I can confirm what Jonas said. I searched multiple Firebird client library *.rpm, *.debs and *.txz packages. Any Firefbird 2.x client library sets up the .2 and .2.m where m is the minor version number names. The one thing they DON'T do is the unversioned name - my issue with FPC, but which will luckily be fixed soon. So using your example, there WILL be the following files. libfbclient.so.2.1.5<- the actual library file libfbclient.so.2.1 <- symlink to above (this does seem optional) libfbclient.so.2 <- symblink to above (always there) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: shouldwehard-codeversionedorunversionedshared libraries in our apps?
On 16 August 2012 17:33, Jonas Maebe wrote: >> My plan (for linux) was: >> Search fbclient.so search fbclient.so.2 (2.x series of firebird) >> search fbclient.so.1 (1.x series of Firebird) if the library name has not >> been specified. > > fbclient.so should not be searched. It could point to anything, including > versions of the library not supported by the unit. @Michael I have to agree with Jonas here. The unversioned symlink is potential trouble. Other than that, your solution sounds fine. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Malformed email messages
Hi, On 16 August 2012 15:49, Sven Barth wrote: > The missing spaces where a topic some time ago already on one of the fpc or > lazarus lists... I don't know what the outcome was though. AFAIK Graeme was > the one who pointed it out that time. I'm using Gmail (forced to plain/text) for years I do remember when using other mailers that I often saw the TAB character being inserted into the subject line. Gmail was hiding that fact as it only shows the top level subject. I think that was because the subject went over 65 characters, or something like that. I can't remember who was to blame for the inserting of TAB characters. One will have to check the message archives. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: shouldwehard-codeversionedorunversionedshared libraries in our apps?
On 16 August 2012 18:41, Michael Van Canneyt wrote: > Potential trouble ? After we have been loading it for the past 10 years ? > Let's not get carried away... I simply meant Firebird DB v3 has been in development for ages so could be released around the corner. It will be a major version change, so there is every chance that the API could change - though the Firebird project has been pretty good at not doing that. Anyway, at some point libfbclient.so could point to a v3 library, and all our apps are coded for a v2 library. That's all I meant. But thanks again for being understand. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: shouldwehard-codeversionedorunversionedshared libraries in our apps?
Hi Reinier, On 16 August 2012 22:25, Reinier Olislagers wrote: > Presumably the sqldb would be changed for the v3 library then? Yes, but that will only be in Trunk, and could take up to a year before the next FPC "stable" release. I only deploy my commercial apps with stable FPC releases. In the mean time Linux distros get released about twice a year now. So distros will be ahead of FPC, and during that time libfbclient.so could be point at a version our software (and FPC) doesn't support. I hope that makes it clear now. > Regardless, as mentioned, the Firebird services API allows you to find > out what version a server is running. Yes, but as someone else also did the same thing as you. You are jumping the gun. You assume a database connection can be established. My problem was that the app can't even run because the libfbclient.so is missing in every standard Linux install, and that symlink is not included in the standard Firebird Client library package. Anyway, I got the answer to my question, and the next FPC release will be fixed. Plus I now also know how to modify my copy of FPC 2.6.1 so our products can be deployed with ease. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re : [fpc-pascal] Malformed email messages
On 17/08/12 09:49, Ludo Brands wrote: I wrote a little VBA module in Outlook that modifies the RE: back to Re: before sending the message and that seems to solve the problem. Almost. You now have an "Re :" in the front, and not a "Re:". Removing the space before the colon should fix it completely I think. Notice: I just switched from Gmail (web interface) to Gmail (via IMAP and Thunderbird). You are correct in what you said. Thunderbird is looks as specific text "Re:" and if it doesn't find it, it prefixes it, thus this message will show "Re: Re :". Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Interbase vs Firebird header translation
I started a new message thread, as it doesn't really relate to the origin thread any more. On 17/08/12 06:50, LacaK wrote: > BTW: packages/ibase is intended to be translation of Firebird client > API not Interbase, right ? Yeah, the unit naming scheme is a bit dodgy at the moment. At one point in history (Firebird v1.x days) the two products, Firebird and Interbase, were similar, thus the combined header translation unit. But yes, their development paths have diverged, supporting different features, using different client libraries etc. So really the SqlDB code should probably be split into Interbase support and another unit for Firebird support. I know Firebird did try and stay Interbase API compatible in the v1.x days, but I don't know if that is still true in v2.5+ days. Anybody have more detailed info on this? I can add that I have a commercial database design tool that I use, and when generating DDL from my designs, there is a Interbase option and a Firebird option - so clearly enough has changed in the last 10 years to consider them separate products now. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re : [fpc-pascal] Malformed email messages
On 17/08/12 11:17, Ludo Brands wrote: Well spotted. Outlook indeed generates "RE :" with the additional space. This should be fixed now. Well done, it seems to work 100% now. :-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Interbase vs Firebird header translation
On 17/08/12 13:58, LacaK wrote: Or split header files ... but then we must also create TFBConnection (like TIBConnection) ? ... it seems to me more complicated ATM Correct. And it is only going to get more complicated and messy as time goes by. So fixing it in the correct manner is best in the long term. Thanks for the examples, that confirms of what we expected. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC vs Delphi's unicode string support questions
Hi, In the tiOPF project the v3 branch is a Delphi Unicode String enabled version of tiOPF, thus it only supports Delphi 2009/2010 and newer. A while back I had some discussion with Michael van Canneyt, and he believes FPC is sufficiently compatible to Delphi 2010 and later, so the tiOPF3 port should be possible. So today I started taking a look to see what would be involved in getting tiOPF3 compatible with FPC. Off the bat, I have a lot of compiler errors with latest FPC 2.7.1 but I'll push ahead and see how far I get. I haven't been following the latest 2.7.1 development in detail, so I have a couple of questions... all relating to FPC 2.7.1 (trunk) only: 0) Am I jumping the gun here, and FPC is not nearly compatible enough to port a Delphi 2010, XE, XE2 project to FPC 2.7.1? 1) Is it correct that String <> AnsiString any more? 2) If true, what is String an alias of? UnicodeString, WideString, something else? 3) If false, what must I enable/toggle to say that String must now be a Delphi unicode-type string. 4) What Unicode encoding is used? UTF-8 or UTF-16? 5) Is it only the compiler that has unicode string type support. Has anything been done or started in the RTL? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
Hi,
On 18 August 2012 15:05, Marco van de Voort wrote:
>
> If it relies heavily on unicodestring, IMHO yes.
Well, there is a clear distinction being made between AnsiString and
String in many classes.
For example:
TtiCompressAbs = class(TObject)
public
function CompressString( const AFrom : string; var ATo :
string): Extended; overload; virtual; abstract;
function CompressString( const AFrom : AnsiString; var ATo :
AnsiString) : Extended; overload; virtual; abstract;
...
end;
This gives a compiler error in 2.7.1
> My guess is that you mistook a comment that confirmed the base
> implementation of the variable stringtype to be compatible for a
> confirmation that the whole project is ready.
The conversation was about many D2009+ features, but I think the main
feature tiOPF v3 uses is the Unicode string.
>> 2) If true, what is String an alias of? UnicodeString, WideString,
>> something else?
>
> ansistring or shortstring, depending on {$H+}. What to do with the D2009+
> change in this regard has been discussed, but opinions varied.
OK, all projects I work on always have {$H+} defined, so for me (in
2.6.1 and earlier), String always means AnsiString.
I guess from the rest of your reply, I am jumping the gun here...
Clearly 2.7.1 is not nearly ready yet for such a Delphi port.
Thanks for all the info.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
Hi,
On 18 August 2012 15:15, Jürgen Hestermann wrote:
>
>> 1) Is it correct that String <> AnsiString any more?
>
> Well, it never was. At least "string" could also be a shortstring, maybe
> other strings too meanwhile (I don't know).
I guess I was a bit vague. All projects I work on and see these days
use {$H+} by default. In fact I don't know why FPC's hasn't changed
{$mode objfpc} to default to String = AnsiString a long time ago, but
that is another battle to fight another day.
>> 3) If false, what must I enable/toggle to say that String must now be a
>> Delphi unicode-type string.
>
> I don't know what a Delphi unicode-type string is exactly.
Please read the Delphi 2009 announcements. It was the biggest code
breaking change in Delphi in years! I have no idea how you could have
missed that. Anyway, String = Unicode UTF-16 in Delphi 2009 and
newer. If you want the old behaviour, you have to explicitly define
each string variable as AnsiString.
> AFAIK UTF-8 is the prefered unicode string as it is used in the IDE and also
This is the FPC mailing list. The only IDE FPC has is the Free Pascal
Text IDE, and that definitely doesn't use UTF-8. ;-)
Anyway, thanks for your response. I'll hold off on the tiOPF v3 port
for now. There are too many undecided factors in FPC 2.7.1 at the
moment.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
Hi,
On 18 August 2012 16:11, Jonas Maebe wrote:
>
>> 1) Is it correct that String <> AnsiString any more?
>
> Only in {$mode delphiunicode} (which is what you should use if you want to
> compile code written for a Delphi version in which string=unicodestring).
OK, that would help. I'll try that now in tiOPF v3. When specifying
that mode, do I still need to specify {$H+}? What happens when I
don't specify {$H+}?
>> 4) What Unicode encoding is used? UTF-8 or UTF-16?
>
> The same as in Delphi: utf-16
Wasn't there lots of "votes" from many that string is UTF-8 encode
under Linux, Unix, MacOSX, and UTF-16 under Windows? Thus avoiding any
conversion speed penalties on all non-Windows platforms. Or is
defaulting to UTF-16 just the first step of implementing Unicode
support, and UTF-8 will follow for all non-Windows platforms later?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
On 18 August 2012 16:11, Jonas Maebe wrote:
>> 1) Is it correct that String <> AnsiString any more?
>
>
> Only in {$mode delphiunicode} (which is what you should use if you want to
> compile code written for a Delphi version in which string=unicodestring).
I've enabled that new compiler mode... Any idea what the following
warning means?
-
/home/graemeg/devel/tiOPF3/src/Core/tiDefines.inc(42,4) Warning:
Current system codepage "0" is not available for the compiler.
Switching default codepage back to "28591".
-
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
On 18 August 2012 21:33, Sven Barth wrote: > "String" can mean either "ShortString", "AnsiString" or "UnicodeString" > depending on the compiler settings: > > Non-Delphi modes and $H- (default): ShortString > Delphi mode: AnsiString > DelphiUnicode mode: UnicodeString > Non-Delphi modes and $H+: AnsiString > Non-Delphi modes and $H- and modeswitch "unicodestrings": (AFAIK) > ShortString > Non—Delphi modes and $H+ and modeswitch "unicodestrings": UnicodeString @Michael van Canneyt Now there is a good table to add to the Lang Ref or some other FPC documentation. [...thinking out loudly...] Oh how I yearn for the Java string handling simplicity - compared to the mess Delphi and FPC is in. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
Hi On 18 August 2012 22:44, Jonas Maebe wrote: > The mode is called "delphiunicode" and in Delphi unicode versions, string = > unicodestring. Not to get this thread into one of those heated unicode discussions again, but couldn't FPC at least do one better that Delphi. "Unicode" means a string in UTF-8 or UTF-16 or UTF-32 encoding - this is how the unicode standard is defined. Why must FPC fall into the same shit habit of Delphi where "unicode" means _only_ UTF-16 (which by definition is wrong!) Maybe "UnicodeString" should be reserved for the true meaning. And for DelphiUnicode mode do something like String = DelphiString where DelphiString is a UTF-16 only string [or String = CodePageString(utf-16) or whatever you want to call it]. Anyway, just my 2¢ worth. no need for any reply. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC vs Delphi's unicode string support questions
Hi,
On 18 August 2012 22:50, Jonas Maebe wrote:
> If you don't want this code page behaviour anyway, you can use the following
>
> {$mode delphiunicode}
> {$modeswitch systemcodepage-}
OK, I think I got my final answer on this FPC is definitely not
ready to port any Delphi 2009+ projects. I fix one error, and get 30+
new errors over and over... The RTL _must_ also be unicode aware
for any delphi unicode project to be ported. For example, you can't
currently do something as simple as defining your own exception
classes based on the RTL's Exception class, because the FPC 2.7.1 RTL
defines the Message property as AnsiString at the moment, and doing a
UnicodeString to AnsiString conversion will give you data loss. This
is a critical issue, and appears all over the RTL at the moment.
So for anybody thinking of trying what I did.. DON'T BOTHER AT THIS TIME.
But thanks to everybody that offered information on this... it was
educational. :-)
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit testing aid...
On 22 August 2012 18:47, Daniel Gaspary wrote: > The obvious example: insert calls to logging procedures at the enter > and exit of each method, procedure or function of a unit. This is already possible for some time. Take a look at the 'fpprofiler' project. I have a version of it that I worked on at: https://github.com/graemeg/fpprofiler But I think there is a newer fpprofiler repository hosted somewhere else now... -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker speed
On 24 August 2012 10:11, Rainer Stratmann wrote: > Sometimes there is the message: > /urs/bin/ld: warning: link.res contains output sections; did you forget -T? The latest FPC under Linux now always produces this message. Search the message archives... I asked this question before and somebody explained what is causing it, but basically nothing really to worry about. Though I must admit, I don't like such message either. :) > Where can I see and/or configure if an internal or external linker is used? > I assume it is an external linker because of the message (/urs/bin/ld ...). Linux doesn't have an internal linker, so it that case it is always external. Only FPC under Windows has an internal linker as far as I know. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Policy regarding HTML messages
To the mailing list admin, What is the policy with HTML messages in this mailing list? I find it very annoying when messages to mailing lists are in HTML - this seems to be the general consensus in most mailing lists. I was under the impression that only plain text message was allowed in this list too. Could you please clarify this. Regards, G. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Policy regarding HTML messages
On 25/08/12 23:14, Graeme Geldenhuys wrote: What is the policy with HTML messages in this mailing list? Ah, I found the following page which describes just that... http://lists.freepascal.org/mailman/listinfo/fpc-pascal "3) Do not use HTML mail, or worse RTF mail. Some mailreaders don't read them, or start up slow programs to process them." So could the mailing list admin please notify the people to change their email clients to NOT send HTML message. For example, all messages from "ido...@gmail.com" Thanks, G. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] GDB help needed please
Hi, I hope somebody knows more about GDB that I. I'm trying to debug an error in one of our Master Maths projects. This error only occurs under Windows, where it bombs out at random times (in a specific section of our product) with a "Segmentation Fault" error. GDB pauses the program at that point, and the stack trace gives me the follow information (shown below). That output unfortunately doesn't tell me much at all. :-( Any idea how I can get more information from GDB? I have enabled the following FPC compiler options: -l -Mobjfpc -Sch -g -gl -gw -O- -godwarfsets My fpc.cfg file is also set to NOT strip debug information (just in case). I'm using FPC 2.6.0 (32-bit) released version to make sure I'm on a stable FPC (I recently had issues with 2.6.1). I've also tried various GDB versions (6.8, 7.2 & 7.4) under Windows, thinking that newer versions might give me more information, but in all versions the crash output is exactly the same. --- Signal received. Signal: SIGSEGV, Segmentation fault. #0 0040E1BB :0 SYSTEM_WAITFREE_FIXED$PMEMCHUNK_FIXED$POSCHUNK() #1 01FB8D3C :0 ??() #2 0040C51A :0 fpc_finalize() #3 0001 :0 ??() #4 0040AD2A :0 SYSTEM_TOBJECT_$__CLEANUPINSTANCE() #5 00520D80 :0 $MDLEXERCISE$_Ld37() #6 0001 :0 ??() #7 01F0D888 :0 ??() #8 :0 ??() --- I've spent two days on this already and about to loose my mind. :-/ From the stacktrace above the only thing I can recognise, is the 'mdlexercise' text, which is a unit in our project. But without any line numbers it is like looking for a needle in a very large haystack. Any GDB tips somebody can share, that could help me get GDB to reveal more debug information? Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GDB help needed please
On 29/08/12 23:23, Jonas Maebe wrote: The first thing you can try is to compile with -gh, hoping that it will abort in a place closer to the cause of the problem. -CRr is also a very useful debugging switch. Thanks for the detailed information. The bug is not fixed yet, but I did eventually get GDB to give me a more detailed backtrace. :) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Identifier not found "result"
On 30/08/12 17:07, Jonas Maebe wrote: Turbo Pascal does not support the "result" alias for the function result. Yup, I can confirm that. I just tested with Turbo Pascal 5.5 :) Wow, that brought back memories. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Identifier not found "result"
On 31/08/12 09:27, Rainer Stratmann wrote: I could swear that it supports it... I thought the same, and that is why I tried it myself. :) I guess we have been with Object Pascal for too long, and forgot the difference between Pascal and Object Pascal. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Editing resource of executable
On 31/08/12 21:18, Mark Morgan Lloyd wrote: Of course, an even safer way would be to leave the executable alone and to put an early check in the startup code that a subsidiary key file existed, and for that key to include something that identified the machine or site on which the program was entitled to run. Take a look at OnGaurd. It has many ways of doing this. We use it in our commercial software (linux and windows) to lease our software on a yearly basis, or to enabled a 1 month trial etc. You can even lock your application down to a specific PC. https://github.com/graemeg/onguard Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Resource compiler under Linux - windres?
Hi, Does anybody know if there is a 'winres' for non-Windows platforms? How do I compile *.rc files into *.res files under Linux, FreeBSD etc? Or does Linux/*BSD executables simply not support such resources? Or can FPC somehow compile/convert *.rc files into *.res files for all non-Windows platforms? If so, how do I do it. A developer in the fpgui.support newsgroup mentioned the following, but I can't find any such executables for OpenSUSE 12.1 64-bit. -[ forward ]- On windows windres is in fpc bin folder. On linux windres is part of mingw32-binutils package (to install on ubuntu: sudo apt-get install mingw32-binutils) But notice that by default name can have some prefix. After install call this commands: 1. sudo updatedb 2. locate *windres* This return me: /usr/bin/amd64-mingw32msvc-windres /usr/bin/i586-mingw32msvc-windres -- Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Editing resource of executable
On 01/09/12 01:18, waldo kitty wrote: true... but as i recall, one of the goals of this capability was to not have extra files laying about... i remember the days of dongles and never liked them at all... +1 I hated those dongles too. The OnGuard code we use, I simply store the unique unlock code in the same .ini file I store other application settings like window position and size in the GetAppConfigDir() location. You can even have a site unlock key, where the unlock code is then stored in the database (if your app is a Client/Server app). Thus if one client is unlocked, all other clients are automatically good to go. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resource compiler under Linux - windres?
On 01/09/12 09:24, Giulio Bernardi wrote: Just compiling windres from binutils sources should be enough. Thanks, I did that and it worked fine. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to compiler's internal data structures
On 31/08/12 19:48, Kenneth Cochran wrote: So I'm finding myself in need of a parser for object pascal. The FPC compiler has it's own built-in parser that is optimised for its needs. There is a more general purpose object pascal compiler included in FCL (part of FPC too), in the 'fcl-passrc' directory. The 'fpdoc' tool uses it, and I think a few others too. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird: bulk insert performance: suggestions?
On 07/09/12 12:12, michael.vancann...@wisa.be wrote: I once did tests with that (600.000 records) and did not notice any influence of the transaction control. Same here... I've imported 100's of thousands of records with SqlDB+Firebird with no serious speed issues. Also from CSV files. Transactions are always used. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird: bulk insert performance: suggestions?
On 08/09/12 06:31, Martin Schreiber wrote: It depends on the reaction time of the network because AFAIK there is a roundtrip for every inserted record... I didn't commit the transaction after every record. I first tried in a batch of 1 records per transaction. Later I even bumped that up more, and still no problems. Anyway, that code isn't used too much in our product - it is only used for data conversion from our old system to our new system. So normally only needed once per setup. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
Hi, I received my Raspberry Pi today, and had a bit of a play. I'm using the Debian 6 OS with my Pi. I downloaded the FPC+fpGUI ARM archive (only a 3.5MB download), packaged by Paul Breneman. http://www.turbocontrol.com/easyfpgui.htm [Awesome work there, Paul. You can get much easier than than. Just unpack and you are ready to work.] It works fantastically well. I could compile all the fpGUI demos without me having to do anything extra in fpGUI. How cool is that! :-) All I had to do to get my projects to link successfully, was to install a few missing packages, which were not included with the Debian 6 distro for the Pi. sudo apt-get update sudo apt-get install libX11-dev libXft-dev I'll have to speak to somebody to see if they could include it as standard - after all, the Pi is meant for developers to play with. If anybody has contacts, please let me know. I even compiled and ran the more complex fpGUI apps like the GUI Forms Designer, DocView (help viewer), and Maximus (a sample fpGUI IDE). Even FPTest (my Free Pascal Unit Testing project works). We (our company) have some big plans for the Raspberry Pi, with a potentially huge deployment. The first tests with this device is very promising. Kudos must also go to the FPC team, for supporting ARM so well! Maybe with the Raspberry Pi and Free Pascal, we can get Object Pascal back on the map, and in the hands of young developers. After all, Pascal was initially designed as a teaching language - easy to learn, read and write. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 13/09/12 17:19, Mark Morgan Lloyd wrote: I think I've had to install those on any Debian system I've used for development, so for any change you'd be up against the entire Debian philosophy. Good luck. I don't think one needs to approach the Debian guys directly. I think one should only need to speak to the people that put together the "pre packaged" Debian 6 for Pi OS image. That OS image comes pre-configured with a 'pi' user, and the desktop already contains icons for Python development, and some sample Python games. I bought the OS image on a 4GB SD card, but there is about 2GB free on that SD card. So ample space for the libX11-dev and libXft-dev packages, and the 5MB needed for the FPC+fpGUI archive. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 13/09/12 17:35, Johann Glaser wrote: I also played with it, but only did a small "Hello World!" program. :-) :-) http://johann-glaser.blogspot.co.at/2012/06/raspberry-pi.html Thanks for the hint on your blog about making screenshots. I was just about to Google on how to do that from inside 'Debian 6 for Pi'. The normal 'xwd' or 'import' applications where not available (the latter one pulls in too much dependencies). I'll try 'scrot' now. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 13/09/12 22:20, Marco van de Voort wrote: Is that the old squeeze or Raspbian? I have the "wheezy" one, which I believe is Raspbian? Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 13/09/12 23:02, Marco van de Voort wrote: But the images from the PI website with "Wheezy" in their name are v5, and thus not hf. A month or so back, the PI foundation changed their default distro from "wheezy" (eabi,v5) to raspbian. Thanks for the info. I'll take a look of the foundation website. Mounting my SD card in my normal PC, it seem my Pi OS images is dated 2012-06-17 (based on /etc/rpi-issue file). Also many of the /etc/ files are dated 17 June 2012. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 13/09/12 23:02, Marco van de Voort wrote: thus not hf. A month or so back, the PI foundation changed their default distro from "wheezy" (eabi,v5) to raspbian. So far the Raspbian image is pretty rubbish, compared to the pre-configure one I bought on my SD card. I guess the "raspbian" it too much "bleeding egde" (read super unstable). The Raspbian one has errors in raspi-config, so I can set my Dvorak keyboard layout. Eventually figuring out where the keys are in Qwerty, I managed to start X. The desktop that loads has NO icons, no menu items, and the menu items that do exist don't work. I couldn't even manage to run a lxterminal. I can't even exit the OpenBox session that is running - I had to Ctrl+Alt+F1 and then Ctrl+C to kill the X server. The mouse pointer is also really slugish in the X session, and freezes for a split second every 2-3 seconds. It's like something is polling the system every 2-3 seconds, and freezing the UI while it does. So for now, I'll restore back to my original Debian 6 "wheezy" (thank goodness I took a backup) where things worked much smoother. It might not be the most optimised OS for the Raspberry Pi, but it works much better. I'll report my problems, so hopefully in the next Raspbian release things will work better. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 14/09/12 10:13, Marco van de Voort wrote: Did you get the foundation recommended image, or did you get some daily build or so? The recommended image on this page: Raspbian "wheezy" 2012-08-16 http://www.raspberrypi.org/downloads I've just installed the "Pisces" image from the raspbian.org website. So I'm about to test that one now, and see how it goes. http://www.raspbian.org/PiscesImages Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 14/09/12 09:10, Mark Morgan Lloyd wrote: I don't believe you've mentioned Maximus here before, does it pull in the form designer etc.? Maximus is very basic at the moment. A project manager, syntax highlighting in editor, macro support in the settings dialogs, Find and Procedure List (filtered searching of current unit), build groups etc. No debugging, code completion, code templates or code navigation yet. I still need to figure out how to integrate fcl-passrc parser to enable such features. At the moment the goal of Maximus is more an "advanced demo", than a full feature IDE. I like the idea of fpGUI being independent of any IDE. I wonder whether it would run on Solaris 8 which doesn't have some of the libraries required for Lazarus? I've tested in OpenSolaris 2009 release, but I don't have Solaris 8 to try. I can say that I have run fpGUI executables under Linux SUSE 9.0 (almost 10 year old distro) too, without any issues. fpGUI only needs the most basic X11 and Xft libraries - nothing else. This makes it work on just about any system that can run X11. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function for checking correct file name
On 12/09/12 19:51, Krzysztof wrote: Hi, Exists any multiplatform function which check if string contains not allowed characters (like < > / \ on windows) for filename? Nothing in FPC as far as I know, but once again tiOPF does provide that. Have a look at the tiUtils.pas unit in tiOPF v2. tiOPF is hosted on SourceForge.net. You can browse the repository code online with a web browser if you must. The function you are looking for is tiIsFileNameValid() I had a quick look. It can be copied and pasted (with one helper function). There are no other tiOPF dependencies. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function for checking correct file name
On 14/09/12 13:48, Krzysztof wrote: I just quicky googled not allowed characters and wrote this simple function: Also in Windows (as far as I know), file names my not be longer than 255 characters. So you will have to check the length of AFilename parameter too. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function for checking correct file name
On 14/09/12 15:02, Howard Page-Clark wrote: As is so often the case, a truly cross-platform solution requires a good... Under linux such a check is easy. Everything is accepted, expect for the NUL character. :-) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 14/09/12 14:22, Mark Morgan Lloyd wrote: It was just an idle query... it might turn out to be possible to build it by taking sources of about the right age from e.g. Slackware 8.1, but right now I've got too much else on my plate to get into this. The alternative is to revert fpGUI to using the old non-Xft processed fonts in X11 - thus giving very ugly looking fonts. That was the original font support in fpGUI, but I quickly introduced Xft support to have better looking text in my applications. :) Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 14/09/12 14:22, Mark Morgan Lloyd wrote: It was just an idle query... it might turn out to be possible to build it by taking sources of about the right age from e.g. Slackware 8.1, but right now I've got too much else on my plate to get into this. Thinking about it, there is a 100% Pascal implementation of Xft. I read about it in the Lazarus Forums, and I think it is used in LCL-CustomDrawn widgetset. I don't know how complete that implementation is compared to the Xft library though. So if you really wanted to, you could use that instead of linking to the Xft library. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function for checking correct file name
On 14/09/12 16:50, Jonas Maebe wrote: And the "/". Ah yes, you are correct. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function for checking correct file name
On 15/09/12 10:54, Sven Barth wrote: Right... but 255 characters for a filename is already rather much as well when I compare this with the amount of text I can squash into a SMS ;) Now I can't remember exactly, is that 255 characters, or 255 bytes? Because if it is the latter, then the Unicode character count limit could be significantly less than 255. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + fpGUI + Raspberry Pi = fantastic
On 16/09/12 06:08, Paul Breneman wrote: Three minimal FPC and fpGUI distros were just updated on this page: http://www.turbocontrol.com/easyfpgui.htm Awesome, thanks Paul. I can see I'll have to order another RPi, or more SD cards. :-) The Raspxbmc distro works really well as a media centre, so is hogged in the lounge at the moment. Should be fun to see what embedded projects the RPi can be used in... :) Definitely! One of my next RPi projects is to see if I can build a 3D printer based on the RPi board. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 2012-09-24 14:39, Christo wrote: I'm interested in testing your wrapper. Unfortunately I cannot clone the git link above, I get an error (fatal: https://github.com/hansiglaser/pas-libusb/tree/libusb-1.0/info/refs not That was a web link, not the git url. If you followed that link with your web browser, you would have seen at the top a ZIP button which you can use to download the latest code of that branch in a zip archive. There are also two git clone URL's. One uses the HTTP protocol, and the other uses the faster GIT protocol. git clone https://github.com/hansiglaser/pas-libusb.git or git clone git://github.com/hansiglaser/pas-libusb.git then do... cd pas-libusb git checkout libusb-1.0 Unfortunately the master branch appears to be 2 months old. You simply forgot to switch to the 'libusb-1.0' branch. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 2012-09-25 17:22, Bernd wrote: I highly recommend using the easygit wrapper to make life easier, especially when you come from SVN because git will be very confusing Thanks for the tip, but Git is *not* difficult to use. To cover the average developer workflow, you need like 3-4 commands max. If you can't remember 4 commands, then you have bigger issues than git. If all else fails, then remember one of these: git help git help Git has excellent help with lots and lots of example commands to learn from, and ASCII art to help visualize what it does. If you still have problems, simply use 'git alias' and setup SVN-like commands for git. For example: Used to using 'svn up'? No problems, do the same in git. git up--> can maybe execute: git pull origin or git co --> can maybe execute: git clone There are some very handy aliases created by many. Use Google to find them. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
Hi, Somebody in the fpGUI support newsgroup raised an issue when using BOM, XMLRead units under Linux. Does the use of the DOM, XMLRead and XMLWrite units in FCL (from FPC 2.6.0) require the use of cwstring under Linux? I'm using those units in the FPTest (Free Pascal Unit Testing Framework) project to generate XML output and I don't seem to be getting the error listed below. My projects never have the cwstring unit listed anywhere. So what else could cause this error message? -- My code deals with reading/writing XML files (with XMLRead and DOM) which requires cwstring or else i get an error at runtime: "This binary has no unicodestrings support compiled in. Recompile the application with a unicodestrings-manager in the program uses clause." -- Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting fpcunit test results into a database
On 2012-09-28 09:18, Reinier Olislagers wrote: > > Is there existing code available for getting fpcunit test results into a > database? No, but the Test Listener interface makes such an addition very easy. Simply create a TDatabaseListener that implements the ITestListener interface. It's only 5 required methods to implement. Then simply register that test listener with the testing framework (via TestResult.AddListener() call), and it will be fed test results as they happen. Each of those 5 ITestListerner methods will then insert records into the database as needed. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On 2012-09-28 09:41, michael.vancann...@wisa.be wrote: > > XMLRead uses it, yes. Umm, so how would that affect applications that normally use UTF-8 packed in AnsiString? Like fpGUI and LCL based applications. To give you the exact example. He has XML units he would like to unit test. He can use the FPTest Text Runner no problem, but he would prefer to use the FPTest GUI Test Runner (created with fpGUI). Under 64-bit ArchLinux the GUI Test Runner bombs out at runtime. Under 64-bit Ubuntu or OpenSUSE the GUI Test Runner runs without problems. I'm totally baffled as to what would be the cause of the crash at runtime - just on ArchLinux. I'm also not sure how using cwstring unit would affect fpGUI apps that use UTF-8 inside AnsiString containers. (just like LCL does) > but we're currently stuck on dealing with a > copyright requirement of the Unicode group. I saw a similar post (from a FPC developer) in the Delphi newsgroups. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On 2012-09-28 10:01, michael.vancann...@wisa.be wrote: >> >> I'm also not sure how using cwstring unit would affect fpGUI apps that >> use UTF-8 inside AnsiString containers. (just like LCL does) > > It all depends on the XML. Sorry, I'm not very versed on WideString managers, so excuse if this is a dumb question. Would this (usage of cwstrings) be limited to the XML usage only (reading/writing from file), or to any place in fpGUI or my applications that use String as a data type? TfpgString is defined explicitly as AnsiString so that should be ok, but there are still lots of places (and my own projects) that use String instead. I guess this would cause issues with API calls to external libraries too? > I know. Some of us think that Embarcadero may be violating the copyright :) After following the posts in the Embarcadero newsgroup, I felt the same way. They are using the data from Unicode.org - repackaging it is irrelevant as far as I'm concerned. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting fpcunit test results into a database
On 2012-09-28 10:25, Reinier Olislagers wrote: > > Ah, Listeners thanks. Is this listener concept something that's > common to more xunit frameworks (junit... etc) or is it an fpcunit > invention? I think the idea came from DUnit, though FPCUnit was heavily based on the JUnit design. DUnit2 and FPTest also use the listeners concept. In fact the latter two uses interfaces a lot more than FPCUnit, making some extensions much easier to implement. I believe other xunit frameworks have similar ideas. Each test framework seems to use the best [most suitable] features of the language in question. eg: Object Pascal based test frameworks use published properties, C# and Java uses class attributes etc to define test methods. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On 2012-09-28 10:28, michael.vancann...@wisa.be wrote: > > No, it is just for the XML reader, since it uses widestrings: Ah, so it only takes affect on the WideString type, not the String type. I guess from the name 'widestring manager' I should have seen that relationship. :) Thanks Michael. > Well, the matter is not entirely clear. Are such things ever! > That is why we decided to ask the unicode group what their opinion is > on this matter. That's the best option. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TListBox, scroll horizontally
Wrong mailing list. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-16 22:01, Marco van de Voort wrote: > > [bold][font size=1][color=red][style=blink] > The starting compiler is only guaranteed [snip] > [/style][/color][/font][/bold] hehehe It is rather crazy how often this same problem occurs on the mailing list. Just thinking out loud... Couldn't there be a check in the build system that if the FPC version is not the latest know released version, the build will immediately terminate with same message your wrote. The build system in Trunk and Fixes branch could be hard-coded to what the correct starting compiler version should be (just like the compile has a constant to say what version it is). Optional: And if for some "advanced" reason a starting compiler other than the last stable release version must be used, then a --force or something like that parameter could be introduced too. This will then hopefully reduce (or with some luck totally eliminate) this very popular support question. G. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-16 22:37, Rainer Stratmann wrote: > But that means work... And how much waisted time was spend by users "debugging the issue" and by developers answering the same question over and over. As Marco said, this issue has been around for years! Programmers write code to reduce work, not make more work. :) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 01:40, Frank Church wrote: > > As the solution doesn't seem to be too difficult which file or files can > "we" zoom in on to fix it? Thanks for showing interest in this. I know near zero about Makefiles and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now use fpmake everywhere? If yes, then why are there still so many Makefiles in FPC Trunk? Quite possibly I just don't understand the use of fpmake I guess. The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known "latest stable compiler version" constant, then report an error and terminate. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Seems Delphi is moving to Java-style primitive types
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
eg: This compiles and works in Delphi XE3.
ShowMessage('Hello World!'.ToUpper);
And there are lots more string functions (like .ToUpper) out of the box.
http://www.youtube.com/watch?v=ndeJeBdZQIw&feature=share&list=UUStifH8LUsnsTQNcT_BDTVw
It actually uses record helpers, but the end result looks very much like
Java primitive types where you have .ToString, .Equals,
.Split etc...
Interesting.
Regards,
- Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpmake compiles the same unit multiple times
Hi, I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be honest I don't really use it, but to keep it up to date. Anyway, I noticed that if I do a 'fpmake build', that fpmake compiles many of my units multiple times. Anywhere from 2-4 times. I double checked my fpmake.pas unit, and I haven't added those units multiple times in the code, so why is fpmake building them more than once? The fpmake.pas unit in question can be viewed at the following URL with your web browser: https://github.com/graemeg/fpGUI/blob/master/src/fpmake.pas Belowo you can see the fpmake output. The first part is going well... units are only compiled once. But then later most units are compiled 2-4 times?? [src (wip)]$ ./fpmake build -UG /home/graemeg/devel/fpc-2.6.0/x86_64-linux/lib/fpc/2.6.0/units/x86_64-linux/ Start building package fpgui for target x86_64-linux. Compiling corelib/fpg_base.pas Compiling ./corelib/x11/fpg_impl.pas Compiling corelib/fpg_main.pas Compiling ./corelib/x11/fpg_interface.pas Compiling ./corelib/x11/fpg_x11.pas Compiling ./corelib/x11/fpg_xft_x11.pas Compiling ./corelib/x11/fpg_netlayer_x11.pas Compiling corelib/fpg_main.pas Compiling ./corelib/x11/fpg_interface.pas Compiling corelib/fpg_imgfmt_bmp.pas Compiling corelib/fpg_utils.pas ...snip... Compiling gui/fpg_spinedit.pas Compiling gui/fpg_spinedit.pas Compiling gui/fpg_colorwheel.pas Compiling gui/fpg_colorwheel.pas Compiling gui/fpg_colormapping.pas Compiling gui/fpg_colormapping.pas Compiling gui/fpg_editbtn.pas Compiling reportengine/u_command.pas Compiling reportengine/u_pdf.pas Compiling reportengine/u_report.pas Compiling reportengine/u_command.pas Compiling reportengine/u_visu.pas Compiling reportengine/u_reportimages.pas Compiling reportengine/u_reportimages.pas Compiling reportengine/u_pdf.pas Compiling reportengine/u_report.pas Compiling reportengine/u_report.pas Compiling reportengine/u_visu.pas Compiling reportengine/u_visu.pas [100%] Built target fpgui Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 10:10, Mark Morgan Lloyd wrote: > > Some slack would be desirable: stable is 2.6.0 but there are known > issues which are fixed by 2.6.1. Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could. The fixes branch is "mislabelled". Contrary to the name, not only fixes get applied to that branch. In recent months, more and more "minor new features" got added to the fixes branch too. > Perhaps we need something like > "FORCE=1" to allow a minor version bump to be accepted, or "FORCE=1.1" > to accept anything up to 2.7.1. This is exactly what I mentioned too, but only for very specific cases (though I don't know if such cases exist). Allow a --force or something parameter to allow the developer to use a different starting compiler (thus ignoring the version check), but ONLY if they know what they are doing. > However the thing that's really needed in my opinion is a clear > statement for each SVN tag which FPC version should be used for That will be a ridiculous amount of work. The existing rule of always using the latest released FPC as the starting compiler is good enough. Regards, Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 10:15, Jonas Maebe wrote: > > See http://www.mail-archive.com//msg25868.html and the rest of > the thread. [embarrassed] Clearly my age is starting to show. :-) How do you find this old messages in any case. Your concern about cross-compiling could be an exception - FPC version restriction is not applied in such cases. Cross-compiling in by far the less used option. Most people that complain about this issue is simply trying to compile a new FPC version for their current target. The --force or --ignore-fpc-version option could still help those corner cases, like new platforms where a previous released version did not exist. The developers working on such features should know what they are doing anyway, so fits in with my earlier statement too. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On 2012-10-17 11:17, Jonas Maebe wrote: > > fpmake does not know about unit dependencies, Ah OK. Thanks for the explanation. So if I ordered my units better in the fpmake program, then that might reduce the multiple compiling too. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
