Re: [fpc-pascal] delphi compatibility
Replace with just Windows. Delphi hasn't had these since version 1.0 and they are aliased to that one Unit. No idea why they exist in the unit. In question also Very strange. Sent from my iPhone 4 On 21 Apr 2011, at 17:22, John Lee johnelee1...@googlemail.com wrote: Just downloaded tried to registry.pas - for accessing win registry. It uses SysUtils, WinTypes, WinProcs, Messages, Classes,ShellAPI My standard v242 fpc win compiler/rtl doesn't have these wintypes, winprocs or messages. Where are these why aren't they there by default? Are they delphi? John . ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting .m4a to .wav
On 09/03/2011 12:52, Leonardo M. Ramé wrote: Hi, does anyone knows if there's a library/class/function to handle .m4a (IPhone sound files)? also, if it allows conversion to other formats, such as .wav? m4a is basically aac, so I'd look down that route. However, m4a files can be protected by DRM, and those files will be much harder, maybe even impossible, to convert. Though, I believe the extension becomes m4p when protected, and also m4b when an audio book. The format is much richer than MP3 or WAV as it can contain meta data such as notes, images and chapter markers. You'll lose these when converting. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name of the programming language used in/with FPC
On 16/02/2011 09:48, Frank Church wrote: How about Apollo? This was the code name for Adobe Air - I expect it would be hard to get traction if Adobe still hold some kind of rights over it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + Haiku
On 28/01/2011 11:08, Ben wrote: Hi, Anybody here using FPC on Haiku? If so, how well does it work compared to under Windows or Linux? It used to work well enough under BeOS R5, but there was always an issue with the C++ nature of the Be API. Haiku seems to have a Qt port, so you might get further with it. I seem to recall Lazarus can target Qt, right? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
On 10/01/2011 09:26, alexv...@mail.ru wrote: If so, there must be an executable format supported by all FPC target platforms natively. I don't know any such format. We have to duplicate some OS functions to make things crossplatform. I don't think that is what Sven meant. I think the executable format would be that of the native platform. However, the interface to the library (the exported symbols and such) would be a common interface that abstracts away the specifics of the underlying OS Library loading routines. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
On 10/01/2011 11:09, michael.vancann...@wisa.be wrote: Like I said, your proposal requires that we emulate all OSes on all other OSes. Or create a VM layer that levels the OS level differences - but again, why do this? Creating such a VM is probably a magnitude of complexity over just using the tools already available and requiring a recompilation to target each platform. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for SDL_opengl header
On 08/12/2010 09:42, Darius Blaszyk wrote: Couldn't find it there, although there are some examples with SDL and OpenGL available with Jedi-SDL. So perhaps I don't need a specific SDL_opengl header (I'm porting a C app). Darius Did you try here? http://www.freepascal-meets-sdl.net/ Or here? http://www.pascalgamedevelopment.com/content.php Also, I used to work with a guy called Dominique Louis (he now owns Savage Software, who seem to still be around) and he was an extremely big Delphi/Pascal game development advocate. I believe he had a hand in the Jedi SDL conversion, at least for FreePascal. It might be worth trying to get in contact with him. He might even be on this list. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
On 07/12/2010 10:46, Felipe Monteiro de Carvalho wrote: Still not ideal, however. Well, no. As Android targets any processor - not just ARM. Indeed, there are Intel based versions. Native is bad, and only come in to existence to compete with other platforms with purely native compilation - and then purely to counteract criticisms on the performance of games and multimedia apps. Davlik was created for a reason - compile once, run on multiple targets. Would it not be a better solution to create a Dalvik back-end? As I understand it, Dalvik is very, far from a traditional stack based Java VM and closer to a traditional register based processor in design. I know little about it, but the benefits of Android, as a platform, are completely lost when one focuses on native compilation. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More Win CE
Sent from my iPhone 4 On 18 Nov 2010, at 08:31, Max Vlasov max.vla...@gmail.com wrote: But I thought about it recently and I think at least that there's a platform that could be such - Symbian. Never developed for Symbian using their native SDK, but as an OS - Symbian is extremely backwards. What doesn't help OS that Nokia's are now desperately trying to graft a touch based interface on top. If Nokia was to bite the bullet and drop Symbian in favour of Meego, things might get interesting. Chances are though that will never happen. Mind you, at least they seem to keep the ABI and API fairly similar in Symbian. Maemo an Meego, not so much. It was pot luck as to whether apps from a prior NIT OS would still run on later devices. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More Win CE
On 17/11/2010 09:16, Felipe Monteiro de Carvalho wrote: You could try MeeGo: http://en.wikipedia.org/wiki/MeeGo Which is. at least in this instance, based on Maemo. At the moment with this phone: http://en.wikipedia.org/wiki/Nokia_N900 My best advice - and this is real world experience speaking - keep clear of Nokia and Nokia devices. Nokia have a very real history of completely screwing over developers for their tablet based OS. I was an N800 owner, and I developed for that platform. I went through NIT-OS 2007 and 2008. Nokia released the N810, and we were told that this was just a revision and all would continue. The N800 was dropped 6 months later and we were then told the N800 will have no further updates, buy an N810 if you want future releases.. Guess what? They released the N900, they pretty much shelved the N810 and there was never more than a hack level version of any future OS for the N810. Next beef - Maemo used Hildon as the UI kit. It was based on GTK+. It was okay - we all may well know the pain of using OO based C API's, but it certainly was not impossible to develop for at all. So, Nokia acquires Qt and Trolltech. Announces that Qt will sit along side Hildon - no one needs to worry about anything, they will both be first class citizens in Maemo land. Um.. well, sure, that lasted for one OS release. Now Hildon is pretty much dead and all the skillset learned for the device is gone. Maybe Hildon might still work in part - I don't really care to find out. All indications to me are that it is gone though. Next beef - and this is unrelated to Tablets OS; my company was developing a system using RFID based technology. Nokia had a product that was almost off the shelf. We were woo-ed by their technical sales guys and so agreed to sign a contract to use their services and buy their hardware. We had a substantial amount of custom we were willing to put their way. Myself and two other guys went on an expensive 2 day training course and learnt the technology. We scheduled in the development. Two weeks before we commenced the project, Nokia announced they were dropping the product, no longer selling the RFID capable phones and we could only have the service for a maximum of 2 years, where after it would be shelved. So, we were left high and dry and out of pocket. Nokia really does not treat customers of parters well. I would never willingly develop for their platform(s) again, including Qt. I hope that in 2011 Nokia will launch cheaper phones with MeeGo and that the platform will get cheaper, more stable and with a larger market share There is little chance that will happen as it assumes Nokia will focus on Meego... Nokia can't focus on a blade of grass on a sunny day - they will carry on as is IMO and be shamed in to releasing cheap and shoddy hardware in a few years when it will be too little too late to save their business. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] More Win CE
Sent from my iPhone 4 On 17 Nov 2010, at 15:26, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: Which smartphone platform do you recommend then? None of them are ideal at the moment. From a Free Pascal perspective, iPhone has the best support. If I was choosing, I'd probably go for Windows Phone 7 because I code in .Net and WPF, so it's trivial to move to. If I wanted potential Market saturation - Android. Meego is on one device, is it not? I seem to recall the rest of Nokia's phones are Symbian. Even the C7 etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 Nov 2010, at 13:16, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On 14 November 2010 14:18, Sven Barth wrote: IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC (although they are aliased the other way round, but that doesn't matter). So then comes the big question — why have IInterface then, if it is exactly the same as IUnknown, yet not a known COM interface name? Delphi 5 supported both COM and CORBA. No IInterface, only IUnknown. Delphi 3 supported COM without interfaces at all. When I was still doing Delphi, it was 5. We used to use Interfaces all the time, but we simply reimplemented the TInterfacedObject and ignored the COM methods. We used them much as one would with in .Net these days. More about light public interfaces, encapsulation and delegation rather than ref counting and such. M___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Re: WinCE / Win32 compilation
On 16 Oct 2010, at 14:23, Uffe Kousgaard u...@routeware.dk wrote: Sven Barth pascaldra...@googlemail.com wrote in message TCriticalSection is a WinAPI struct if you include the unit Windows. Appart from unit ordering (which is a shaky way of reliably resolving things), you could always qualify the name with the unit prefix too: var cs: SyncObjs.TCriticalSection; This would universally work across Delphi and FPC and unit order would not matter. Sent from my iPhone___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTempFileName in Linux
Sent from my iPhone On 7 Oct 2010, at 22:44, Michael Van Canneyt mich...@freepascal.org wrote: Aren't there automation systems for this? Just like debian's 'apt-get update upgrade' with a custom repository with your software? But then for windows I presume? I haven't seen any yet. The main problem is that the update isn't 'optional' or 'to be scheduled at X every night'. It must be done when the server application says it is time to do so. I've had to do this. It's extremely painful in Windows because there's no easy way to replace the executing application. Everything runs pretty smoothly till you need to update the section of the app that does the update! To assume that will never occur is to invite FAIL! it might be easier now that NT is the target, but 9x made it extremely hackish to get working. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Any recommendations for a good in-memory storage type
Graeme Geldenhuys wrote:
So which one would be more fitting for any mime types, or is there
another option I didn't think of? Here is a simple usage example of
the TfpgMimeData class - to help put this in perspective:
This seems a lot like the BMessage class used with in the BeAPI. There
is an API called MUSCLE, which originates from a project created by
Jeremey Freisner for BeOS, but is now very cross platform. It uses a
Message class to implement the format you mention below. It is designed
to be used for comms, so it has the concept of flattening data to a
binary format and then unflattening the data at the destination.
What does all this have to do with your class? I wrote an implementation
for Delphi a good 5 years ago. It might be worth looking at? It was in
the original MUSCLE distro, but if not, I can find you a copy.
https://public.msli.com/lcs/muscle/
Messages are not the fastest way of storing data, but the idea of an
extensible generic data storage mechanism is extremely powerful,
especially for distributed comms. MUSCLE implements a whole lot more and
really is worth looking at if you want to create C/S over a WAN. The
MUSCLE server becomes a middle man dispatcher on to which the clients
publish resources and subscribe to events. The server becomes another
node. Really love it, would love it more if it wasn't written in C++.
M
var
m: TfpgMimeData;
d: TfpgDrag;
a: TfpgDropAction;
begin
m := TfpgMimeData.Create;
m.SetData('text/plain', 'My name is Earl');
m.SetData('text/html', 'My name is bEarl/b'); // text/plain
can actually be created from this automatically
m.SetData('image/png', MyPNGImage);
d := TfpgDrag.Create(self);
d.MimeData := m;
d.StartDrag([daCopy]);
// d manages the lifespan of m
// d will be freed automatically when drag action is complete or cancelled
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] deprecated syntax is inconsistent.
Graeme Geldenhuys wrote: On 29 April 2010 14:51, Florian Klaempfl flor...@freepascal.org wrote: Having a bigger lookahead makes a lot more things far more complex epecially in combination with include files, macros, generics. Why? You only apply the extra lookaheads where needed (code that could be ambiguous). All other parts of the code will be parsed as normal - as it is done now. So far I know of only two examples where extra lookaheads need to be used. * wiki example where 'default' is used * my example to fix the inconsistent syntax for hint directives (deprecated). Let's be honest here - maybe you should submit a patch? It might get accepted if it passes testing. If you're not willing or able to do so, it doesn't sound like the key FPC developers are going to do the changes for you ;-) It's a really, really small and insignificant syntax annonoly. There are far worse ones in Pascal - I point you towards repeat... until in The TP/Delphi/Borland style Pascal dialects. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit on WinCE
Adrian Veith wrote: //pcol^ := Plongword(p)^; -- changed pcol^ := (LongWord(p[3]) shl 24) + (LongWord(p[2]) shl 16) + (LongWord(p[1]) shl 8) + LongWord(p[0]); This looks like an endian issue. Aren't Bitmaps in Little Endian format (as per the usual endianess of the Intel x86 processor) and ARM can be either in big or little endian? This could explain the scrambling of this image too. Are there any routines in the RTL that could be used to get round this? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit on WinCE
Adrian Veith wrote: ..the bitmaps look scrambled and have different colors. I haven't found the solution for this yet. Ignore that last message. It seems WinCE is only ever little endian. So it is probably more to do with DIB vs general device dependent Bitmaps. Have you tried converting the bitmap in question to a DIB? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Sent from my iPhone On 24 Feb 2010, at 06:10, Jürgen Hestermann juergen.hesterm...@gmx.de wrote: Well, *this* can be done much easier ;-): snip I think an interjection at this point is required - all of this is down to personal experience, preference and style. It is what you are used to. Having done 10+ years of Pascal, yes this is very alien. Having done 5+ years of C# and C based languages, no this is useful. Should it be part of Free Pascal? That is for the compiler maintainers to decide. However, don't write it off because you find it undesirable. One languages feature is another's bad syntax decision. I can't count the number of times I've tried to explain the point of Sets to non Pascal programmers (read: C based language users.) I also don't want to remember the countless bad implementations of Sets I saw whilst trying not to have to reinvent the wheel. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] some new features to delphi prisem
Sent from my iPhone On 21 Feb 2010, at 19:37, JoshyFun joshy...@gmail.com wrote: z := iff(a=b,1,2); But to me it looks awful and a bit of c-ism No, that is a VB-ism. A C-ism would be: z = (a==b ? 1 : 2); Which I fo tend to use myself in c# as it is a lot more convenient in some cases. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Graeme Geldenhuys wrote: Marco van de Voort wrote: It also proves that such solution external to the language is possible. That weakens the case for a language feature My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case. This is unrelated though. Refactoring has its place, but is absolutely specific to a single IDE. If one never intends to use that IDE, the functionality is gone. I don't care for the feature either, but I can also see why it would be desirable over mechanical string replacement, no matter how advanced. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: IMHO Prism is not even Delphi. Just recycling of the brand. Laying cards on the proverbial table, I don't think it was ever intended to be Delphi. RemObjects developed the compiler completely outside of Delphi for a number of years before the technology was licensed to become Prism. Fact. IIRC, they billed Chrome (then Oxygen) as a Pascal-like syntax refined for the .Net framework. It was the Codegear/Embarcadero licensing that first created Delphi Prism. The syntax that Prism uses is a lot cleaner in many respects - especially removing the procedure/function conundrum and using instead method. However, in other ways it is horrible and so I can also see why it is not something worth discussing further. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Jonas Maebe wrote: Maybe this discussion could be moved to the fpc-other list? It's not really directly applicable to FPC anymore. Indeed, which is why I said [..] I can also see why it is not something worth discussing further. I guess if someone was committing to developing the compiler mode switch for the dialect, it might be a different case. I sent a follow up before reading your email, so apologies and lips are now firmly zipped!! ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Farewell
After almost 10 years of being on this list (FPC was at about 0.9x when I joined), it occurs to me that I just don't code in Pascal any more and don't foresee doing so again. I do read messages, but more from a nostalgic point of view. So, I'm going to leave the list. This will be a two stage operation. Step 1, this list address will become SPAM in Thunderbird. Stage 2, when I get a chance to I will unsubscribe. At any rate, I'll no longer post or respond to messages from today onwards. It's been a fun Journey. FPC is a fine compiler. I wish you all good luck, and bid you farewell! M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Michael Van Canneyt wrote: And it is exactly why I can't use MySQL, MSSQL: they don't have sequences or generators. I need the ID BEFORE I insert the record, not after. YES!! This is also missing from SQL Server... or at least, using a GUID is complete overkill. The mechanisms SQL Server has for retrieving the last interted identity value are completely unsane too. Yes, they do work, but things get tricky in real world situations. I have no idea how anyone wrote reliable code to insert a record and retern the IDENTITY value prior to SQL Server 2005. OT: does anyone know of a reliable generator style atomic robust multi user friendly auto IDENTITY generation mechanism for SQL Server? I'd love to be able to define one, but I don't think I have seen one yet that *really* works well. So: Each his taste :- Generators and For select .. into .. suspend are the features I really miss from Interbase/Firebird. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Inoussa OUEDRAOGO wrote: Have you try SCOPE_IDENTITY() ? Available at least since SQL SERVER 2000. I have used it with success. Well, yeah. But it's not perfect. I want generators, as in: create generator an_atomic_counter; set an_atomic_counter = 1 /*or something like that*/ declare variable next_atomic_value int begin next_atomic_value = gen_id(an_atomic_counter, 1); end next_atomic_is is alway a unique incremental id, and is *not* tied to a specific table. It's not so much the ability to generate a unique id, it's the use auto inc IDENTITY fields or be damned attitude that Sql Server has. The only other option is a GUID. Microsoft's insane SET IDENTITY_INSERT ON|OFF is also dangerous. Have you ever tried to migrate data between to databases using Sql Server? Nightmare! from MSDN : quote Returns the last identity value inserted into an identity column in the same scope. A scope is a module: a stored procedure, trigger, function, or batch. Therefore, two statements are in the same scope if they are in the same stored procedure, function, or batch. /quote Interesting article ( 10 Things You Shouldn't Do with SQL Server ) : http://www.sqljunkies.ddj.com/Article/92CC4817-604D-4344-8BE0-4490F8ED24B6.scuk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Marco van de Voort wrote:
Michael Van Canneyt wrote:
My point of view is that a database is for storage, not for logic...
Ah, this is basic use of resources. The benefit of Stored Procs is speed
of execution.
For dialy routines, only if they are not complex, and significantly reduce the
amount of data
transfered tuples (the result set), and it can not be expressed in a query.
I don't doubt what you are saying, but in my experience, this is not the
case. It really depends on the client and underlying protocol used to
access the RDBMS. In a local database system, yeah, probably. In a
RDMBS, no.
With complex I mean is that if the stored proc needs to use temp tables or
other state that consists out of a set of tuples, then it is usually slower.
Again, not true in my experience. Writing the same code on the client
that manipulates data from multiple tables and uses the resulting
dataset is a lot slower. Using Interbase/Firebird, you can create stored
procs that return datasets in a ad hoc fashion (multithreaded) or bulk.
Something like:
create proc test ()
returns (a int, b int, c int, d int, e int)
for select a, b, c, d
from TZ
into :a, :b, :c, :d do
begin
e = 0;
if (b in [1, 2, 5, 200]) then
begin
e = 22;
suspend;
end
else if (c = 250) and (b 5) then
begin
e = 25;
suspend;
end
else if (a 250) and (b = 5) then
begin
e = 8;
suspend;
end
else if (d = -1) then exit;
end
(forgive my syntax mistakes above, not done any Interbase for over a year.)
is far better than (pseudo code)
var
table : table_class;
begin
...(some construction or whatever)
table.execsql(select * from TZ)
while (not table.Eof) do
begin
a := table.fieldbyname('a').AsInteger;
b := table.fieldbyname('b').AsInteger;
c := table.fieldbyname('c').AsInteger;
d := table.fieldbyname('d').AsInteger;
e = 0;
if (b in [1, 2, 5, 200]) then
begin
e = 22;
suspend;
end
else if (c = 250) and (b 5) then
begin
e = 25;
suspend;
end
else if (a 250) and (b = 5) then
begin
e = 8;
suspend;
end
else if (d = -1) then exit;
end
end;
end;
Oh, and CPU is cheap compared to DB licenses nowadays.
Aha, the Microsoft defense! ;-) Chewbaka was a Wookie, don't you know? ;-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
On 10 Apr 2008, at 11:44, Marco van de Voort wrote: Oh, and CPU is cheap compared to DB licenses nowadays. Aha, the Microsoft defense! ;-) Chewbaka was a Wookie, don't you know? ;-) I saw him whine yesterday in the Empire Strikes Back yes. And he was as realistic as buying P-I client machines nowadays. Geode, or the VIA processor line. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Graeme Geldenhuys wrote: Any documentation for Interbase 5.5 or 6.0 should be fairly helpful. TBH, the way Firebird did security last time I looked, was pretty similar to the way SQL Server does it if you don't use integrated security. Adding users was hell, but adding grants etc was pretty simple. The bigger issue with Firebird was that it was so unstable (but then, so is Interbase) and required a lot of fiddling to stop it misbehaving (some of which might have been the archaic components and poor code I inherited.) I won't vent my spleen about Interbase/Firebird, except to say: it works really well till you start writing UDF libraries in Pascal. The Free UDF lib is buggy and also there are a number of subtly different versions floating around and no real version control. It has some nice features (Stored Procedures and the for select ... suspend mechanism) but I would never use Interbase in production again and would need to see pretty conclusive proof that Firebird had improved greatly. I did read they now have a PL/SQL emulation layer... that sounds really nice. M Hi, Anybody know of a Firebird book I can purchase? Language needs to be in English. I'm looking for something that covers the SQL syntax, DB tuning and importantly, security. The latter is one major issue I have with Firebird. It's security model is very different to MS SQL Server, and I'm struggling to find information on how I should implement my applications with Firebird security. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Marco van de Voort wrote: On Wed, 9 Apr 2008, Matt Emson wrote: The only negative thing I can say about Firebird is that it can produce a corrupt backup file. IIRC Mass insertion could bring down the db (slow to an effective DOS to other users) unless you commit the transaction every 1 items or so. Yep, we definitely saw that. We ended up going a little insane with committing transaction (bad original design relied on keeping transactions open slightly too often.) Even so, the Delphi controls we used (Delphi 5, whatever the latest IBExpress Borland shipped) were appalingly buggy wrt transactional stuff. I always liked the other ones, IBObjects, personally - even if they were quite odd. IBExpress could not handle the server disconnecting - totally unrecoverable. IBO did handle it quite well. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Graeme Geldenhuys wrote: ... At the moment we simply hard-code a firebird username and password in the application to create the connection, then access our own 'users' table to manage access to our application. Is that how everybody else does it with Firebird? Yes. I've seen that in a number of IB/FB apps. It is fairly common. But, also common to create a non SYSDBA user too for that purpose. Be careful about grants.. if you have two users, IB and FB management tools tend to grant for that specific user by default. If someone logs on as SYSDBA, I've seen mad things where people have made random grants for various users because of this. The EMS tools are pretty cool. We used to use their manager, forget what it is called now. I did use Marathon for a while, but it was quite buggy and unstable. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Looking for a Firebird book?
Michael Van Canneyt wrote: On Wed, 9 Apr 2008, Marco van de Voort wrote: IIRC Mass insertion could bring down the db (slow to an effective DOS to other users) unless you commit the transaction every 1 items or so. Not in my experience: over 600.000 records inserted in 1 transaction. Maybe with interbase this was so ? If you bring a UDF in to the equation, it will happen. Easily. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why I?m choosing (Object) Pascal
On 7 Apr 2008, at 20:07, Michael Van Canneyt wrote: On Mon, 7 Apr 2008, Ingemar Ragnemalm wrote: Linux works (I did the port myself) but is still a bit rough on the deployment side, so they don't include it officially yet. And if linux works, the other platforms should work also (I took care of that during porting). It looks very expensive still. $995 is a lot of money when compared to other frameworks (RAILS come to mind, and ASP.NET via Mono.) You also have to look at things like OpenLaszlo and Adobe Flex. If I was writing a RIA, Flex is the route I would take (passable IDE, nice enough language, very Powerful), runs on 90%+ of Intel based operating systems, including Mac OS X, LINUX and Windows. Also runs on many mobile phones and PDA's - N800/N810 (via full plugin), N series Symbian based phones and many others (via Flash Lite 3.0.) If you forgo the IDE, Flex is completely free. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MacOS and Opaque types
Bent Normann Olsen wrote: I'm new to Mac development environment, and I was looking thru the CoreMIDI/MIDIServices.h, to see how much work it's going to take (at least maybe partially) to implement some of the functions to own projects. I hit the wall with some typedef, for example struct OpaqueMIDIClient * MIDIClientRef, and I now understand that Apple do not always want developers to know what is behind some type definitions. Is this true? As an aside - a lot of why Apple does this in Carbon stems back to the old MacOS 9.x heritage. In the old pre 10,x system, the memory manager forced the programmer to refer to data by handles that were references to pointers. This was historical and was originally because of the funky things it did with shuffling pointers around in memory to handle the fact that the early hardware (Mac 128 for example) was only barely able to run the OS within the memory constraints of the hardware. PowerPC might have altered this, dunno, but the basic OS worked on that premise for 68000 at least. Carbon should have minimised the madness, but I guess some still persists? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?
Peter Vreman wrote: None the less very interesting example. Problem is ofcourse FPC does not support the new Delphi 2007 features. And the big question is how would you port this code to FPC ? Please don't make _your_ problem our problem!!! You knew beforehand that FPC doesn't support these features. If you want to be compiler independent you have to keep to the smallest feature set. Writing multiple mails with complains will not help to get features in the compiler. I don't think this guy actually listens to anything anyone says to him. He always seems, to me, to be speaking to an audience, rather than a discussion list. Adios Sybuck Flying, added you to my ignore list ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Multiple inheritance is more powerful than Pascal's interfaces ?
Andrey Gusev wrote:
This question was posted to fpc-other, yesterday, but seems wrongful,
in subject appropriation sense to that maillist.
===
I wish to introduce some additional (and general) functional to an
existing (and foreign) freepascal's unit. I wouldn't to introduce any
my own code to that foreign module, consider to development process,
svn updation...
With C++'s multiple inheritance quality it is easy to implement:
---
#include stdio.h
#include list
using namespace std;
class TObj {
protected:
int fff;
};
type
TObj = class
protected
fff: integer;
end;
class TObj2: TObj {
protected:
int fff2;
};
type
TObj2 = class(TObj)
protected
fff2: integer;
end;
class TIntf {
public:
virtual void ppp() = 0;
};
type
TIntf = interface
procedure ppp;
end;
class TObji: public TIntf,TObj {
public:
virtual void ppp();
};
type
TObji = class(TObje, TIntf)
public
procedure ppp; virtual;
end;
class TObj2i: public TObji,TObj2 {
public:
virtual void ppp();
};
type
TObj2i = class(TObj2, Tintf) //you do not need to use multiple
inheritance here!! TObj2 already inherits from TObj
public
procedure ppp; virtual;
end;
But i can't invent nothing like that,
in object pascal, with him interfaces!
That is a translation of what you use as an example.
Alternate route is to use composition and/or aggregation.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] property or public
Joao Morais wrote: Damien Gerard wrote: On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public snip List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) Encapsulation, on behalf of the integrity of the instance. Implementation detail is also a good example. Then: TMyClass = class private FList1: array of string; //convoluted, but uses a different storage mechanism FList2: array of string; protected function GetList1: TStringList; virtual; function GetList1: TStringList; virtual; public property List1: TStringList read GetList1; property List2: TStringList read GetList2; end; You can implement the storage for GetList1 and GetList 2 any way that you wish internally, but give a uniform external interface. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Vinzent Hoefler wrote: On Friday 18 January 2008 11:39, Bee wrote: I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :( No offense, but maybe this is a good time to start becoming a serious developer now? I think you are missing the point. Bee may indeed be misguided, but the feature is in Delphi[.Net] in general. It is used to implement Namespaces - something sadly lacking in the FPC dialect of Pascal. Maybe it is time *you* embraced modern programming techniques? I, for one, would rate Namespaces over templates and generics. I use them daily. Give me partial classes too (i.e. OO modular design.) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Daniël Mantione wrote: Op Fri, 18 Jan 2008, schreef Bee: Both compilers [CAN] use the UCSD Pascal unit system, I have added a missing word from that statement I think. which, as of today is still one of the best modular programming systems. That is the base to start from. No, no it is not one of the best modular programming systems. Not for OO related code. Love them or hate them, namespaces and partial classes are extremely useful.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Vinzent Hoefler wrote: On Friday 18 January 2008 12:35, Bee wrote: Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. And units are better because...? I would take Namespaces over the crippled '80's unit notation any day. Units come from an age when filenames were limited to 8.3 format. Yes, we now have longer unit names, but Namespaces give context if nothing else. Scoping is what you make of it. Java has Packages, C++ has Namespaces, C# has DotNet style Namespaces (not entirely the same thing.) I'd far rather have: uses Windows.Win32.Standard, Windows.Win32.Messages; than uses Windows, Messages; File names should have nothing to do with Namespaces too. I'd also love: unit Blah; Namespace MyAPI.Blah; interface type TTest = partial class //non GUI code end; implementation end. and then be allowed unit Blah.GUI; Namespace MyAPI.Blah; interface type TTest = partial class public //GUI code end; implementation end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Matt Emson wrote: What is the difference ? The second one saves on typing, which is a plus in my book ? Right.. confusion over verbosity. Given two units called Constants.pas, which one is the correct unit? Given a unit called Utils.pas and one called ExtraDefs.pas, both of which contain different implementations of the type TSocket, which is the correct unit to use? File names should have nothing to do with Namespaces too. I'd also love: unit Blah; Namespace MyAPI.Blah; And how will you know which namespace is in what unit (or file) ? Turning it on its head - file names should have nothing to do with unit names. The unit lives in a namespace, The namespace directive gives the path to the unit. so it would be: unit Blah; namespace MyAPI and uses MyAPI.Blah; You then need a second structure mapping namespaces on filenames, making it slower, bulkier and error prone. The cure is worse than the disease, IMHO Nope.. see above. Do you have a problem with partial classes? Also called Categories in Objective C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Marco van de Voort wrote: Michael Fuchs wrote: But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace. The filename would be MyAPI.Blah.pas as you indicate. And if I import blah what would be imported? As far as I can see this is no real advantage, except allowing dots in unitnames No, you would import MyAPI.Blah... I would say, remove unit replace with Namespace and all would be fine. Thinking about it, the Chrome dialect is a better model. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Marco van de Voort wrote: However again, as far as I understand partial classes (Class Helpers in Delphi.NET), for this you need a registration system again because you need to compile all units that might use class X so that they auto import all units with classhelpers for unit X. (or you have to scan all directories on each compiler start, and must make 100% sure that you don't use units that don't have these class helpers added. Not really. In practice, you can compile a partial class without all of its parts and use it just fine. In the real world, this is extremely useful in sharing an engine between GUI systems (or a web application and a Console application) without pulling in specifics for the role implemented (GUI kits etc). It allows for a modular design (extensions at compile time.) It allows the programmer to create a flatter less complex hierarchy - e.g MVC in a single class, but with clear separation of responsibility. In C#, Vs2005 always buts all of the GUI generation code in to a partial class called XXX.Designer.cs. This is an extreme improvement over the Pascal way. An extention to this would be partial units (just invented this) which would allow the removal of the include files that dog FPC's RTL and support libs. All specific files could be organised in such a way that the include path found only the correct unit parts. Yes, this is all a pipe dream, but dreaming is fun sometimes ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
Michael Fuchs wrote: But how can fpc find the unit which contains this namespace? I think better is: Namespace = unit name = file name It is easier to allow a dot in the unit name than writing code, which search all units for the right naemspace. The filename would be MyAPI.Blah.pas as you indicate. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Classes with abstract methods
Graeme Geldenhuys wrote: On 14/01/2008, Michael Van Canneyt [EMAIL PROTECTED] wrote: Is there a way to abort the compilation in this cases instead of a warning ? Currently not. If you want to be that strict, then use Interfaces instead of Abstract classes I always found (and still do in C#) that interfaces are good for forcing structure but bad for forcing good inheritance trees. The good thing about classes with abstract methods is that they form a point for inheritance. Interfaces - well, I regularly use interfaces to create a common structure, e.g. an API that will have both a webservice interface and a local interface. The common API is an interface in a separate assembly, used on both client and server to implement an identical API (client code can then link to either the local API or the webservice via a client that implements the same interface.) DotNet also makes reflection (RTTI) quite useful with interfaces too, but I digress. The point is that the webservice class, the client and the local API that the webservice wraps all implement the interface (the webservice usually just delegates responsibility to an internal instance), but none of them inherit from each other. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extension .pp or .pas
Graeme Geldenhuys wrote: As far as I know .pp is the old 'classical' file extension. .pas is the new more widely know (I think) extension for Object Pascal. I prefer .pas personally. I had never seen .pp before FPC. In all the Delphi/Turbo Pascal I'd used, it was always .pas. On the Mac it seems to have been .p quite regularly. Was .pp the UNIX standard? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Arrays of objects
Adrian Maier wrote: Hello, I'm seeking for advice about which is the best way to hold an array of class instances I need to access the elements using its position (like a regular array) , and also i'd like the structure to grow when I add more elements TObjectList If you want specific non type casted code, write a wrapper that exposes the obvious methods and properties: type TMyObject = class public a: integer; end; TMyObjectListWrapper = class private flist: TObjectList; procedure SetItem(index: counter; item: TMyObject); function GetItem(index: integer): TMyObject; public function Count: integer; function Add(item: TObject): integer; procedure Delete(index: integer); procedure Clear; property Items[index: integer]:TMyObject read GetItem write SetItem; end; untested because I have no Pascal to compile with, but you get the jist. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Arrays of objects
Marco van de Voort wrote: Adrian Maier wrote: VArray: array of TSomeClass; begin SetLength(VArray, 10); // now you have VArray[0] .. VArray[9]; SetLength(VArray, 20); // now you have [0] .. [19]; // Length(VArray) = 20 // for I := 0 to Pred(Length(VArray)) is a valid statement They are reference counted, just like ansi strings, ie don't worry about memory leakages. ... Of the array itself. The objects it contains is another matter. Which is why TObjectList is a good choice: TObjectList.Create(True) makes all instances added to the list owned by the list and free'd when the list is free'd. TObjectList also manages the allocation/deallocation and size for you. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and JAVA
Krishna wrote: Another thing, the code produced for the winemulator target is x86 code or arm code? Depends. The Visual Studio 2003 emulator is x86. Based on the VirtualPC core product. The Visual Studio 2005.. um.. I don't remember. I know Microsoft provide an ARM emulator that runs dog slow. I had the emulator and WM6 images about 5 months ago in my last job. Testing against the x86 emulator is only good for quick tests. Nothing beats debugging on a real device. If you pony up the cash, you can do that with VS2003 or VS2005. Let me just point out.. and this isn't a troll, it's my own experience: The end user does not care what your application is written in. Just so long as it works. As such, I would recommend Compact Framework and managed code for any Windows Mobile device. The memory footprint is minimal - all WM5 devices I have used (and we used quite a few brands) have the Compact Framework in ROM. Speed wise, it's fast. It doesn't crawl at all. Given the significant bugs Microsoft had in their native code SQL Server CE 2.0 - as an example of native code on mobile devices, C# and CF.NET make life far, far, far simpler. I found it cut development time down by between 50% and 70%. I can't even look at old code written using C anymore. Shudder. As for the FPC compiler targeting CLR.. It could be done. But why would you need to? Use Chrome instead. Why reinvent the wheel. I see no advantage in porting Legacy Pascal code to a new disparate platform. Especially when said platform does things a lot more pleasurably. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and JAVA
Krishna wrote: On 10/26/07, Matt Emson [EMAIL PROTECTED] wrote: We are talking about Symbian OS here. For linux and windows mobile devices, I understand you can use FPC directly, right? Sorry, you said Winemulator. I read windows emulator not emulator for windows. My bad. As for the FPC compiler targeting CLR.. It could be done. But why would you need to? Use Chrome instead. Why reinvent the wheel. I see no advantage in porting Legacy Pascal code to a new disparate platform. Especially when said platform does things a lot more pleasurably. Legacy Pascal? Din't generics get added in the last release? Anyways, I'm not asking for a CLR/JVM port. FPC already generates code for the target (here, ARM) it is only the OS interface that we are talking about. All native Object Pascal is legacy code for me. I haven't used Pascal in a new project for .. um.. 3 + years. Last job I maintained a Delphi app, but all new dev was in DotNet. I don't see going back to Delphi as an option, ever. I keep on this list because I have ~15 years of Object Pascal legacy code under my belt and I still really like Pascal. I want to use it, but it's just not possible at the moment. Things might change soon, I'm entering the world of MacOS X soon. Though MONO is on the MacOS X platform, so I might not even then. Does FPC support the flavour of Linux on the N800? That might also be something I'd like to look at. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] D language and Object Pascal
Marco Ciampa wrote: Yes, it's so sad to see people that waste time reinventing the wheel... To be fair to Walter, you have to look at his history. He wrote a lot of different compiler implementations over the years - this is pretty much what he's been doing *since* the time of Turbo Pascal. He was responsible for the Symantec C++ compiler, which has a lineage back to some old DOS compiler that was either the first or at least one of the first to implement C++ outside of the original implementation (the parser that parsed to plain C.) He also wrote the native Java compiler from the Visual Cafe for Windows product line (very nice compiler for its time.) Digital Mars C++ has a direct line back to Symantec C++ IIRC. So D is Walter's, done a lot of C style syntaxed compilers, but now I want one I actually like myself trip. You need to forgive him for that. He was writing compilers when Florian was at Grade school ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] D language and Object Pascal
Jilani Khaldi wrote: Hi All, just curious about the D language (http://www.digitalmars.com/d/index.html), I read some articles on the site, downloaded the compiler... and wrote some little examples. Well, many of the things that the author presented as new and hot features are already present in Turbo Pascal or in Delphi for a decade (objects by reference, strings...). I only with that Walter would take on-board Sets ala Object Pascal. They get all these crazy, crazy set implementations popping up in the D forums, but if you demonstrate how OP does it, we get a that's nice and it's totally ignored... well last time I looked, so maybe he did implement sets now. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Halt() bypassed try..finally block
Michael Van Canneyt wrote: On Thu, 13 Sep 2007, Graeme Geldenhuys wrote: Hi, Is that correct behavior? When calling Halt() somewhere inside a try..finally block, it _doesn't_ execute the finally code. This is by design. Halt finalizes the units and then exits. Yeah, I always used to use something like: var haltApp: boolean; begin haltApp := false; try //some code that does something if (some_condition) then begin haltApp := true; exit; end; //some other code finally //cleanup code if (haltApp) then Halt(halt_condition_code); // one could argue this should be outside of the finally, // but if it were it would not always be executed as // desired - especially if an exception was raised. end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] writing programs for non Intel Processors
The Motorola MPx220 runs a 200-MHz Texas Instruments OMAP 1611 processor, which is a a 32bit ARM v5 with a ARM926EJ-S core. It runs Windows 2003 Smartphone though, so I'm guessing the answer is a little more tricky - probably no. M - Original Message - From: Pianoman To: fpc-pascal@lists.freepascal.org Sent: Wednesday, May 16, 2007 3:22 PM Subject: [fpc-pascal] writing programs for non Intel Processors Hello, I would like to ask whether is it possible to use freepascal to write application for example for Motorola MPX220 (mobile phone) ( it runs windows 2003 mobile edition) Pianoman -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] writing programs for non Intel Processors
Why no? Because Windows CE Win32. Smartphone more so. However, the word probably conveyed my doubt that I had all the facts. There you go. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to know if a class implements a method
Any idea how I know if a class, in a class pointer, overrides a virtual
method? Eg:
snip
vfooclass := tboo1;
// vfooclass doesn't implement sample.
vfooclass := tboo2;
// vfooclass implements sample.
You need to implement a virtual method, even if it does nothing. Are you
sure you're not meaning abstract method?
e.g.
TBlah = class
public
procedure blah; virtual;
procedure blahblah; virtual; abstract;
end;
Will only compile if TBlah.blah has a body where as TBlah.blahblah
does not require itself to be implemnted.
At this moment I know that:
1. I could cast a method pointer with tmethod if sample was a class
method;
2. I could cast this same method pointer if I had an instance of
vfooclass.
But is there another way beyond creating an instance?
You can always hack the RTTI/VMT, but that might not be a safe way.
Might it be that you need to have a more complex inheritence tree? So add a
few levels?
tfooBaseclass = class of tfooBase;
tfooclass = class of tfoo;
tfooBase = class
private
procedure sample; virtual;
end;
tfoo = class(tfooBase)
public
procedure sample; override; //a base implementation
end;
tboo1 = class(tfooBase)
//sample is still private and not publicly accessable
end;
tboo2 = class(tfoo)
public
procedure sample; override; //whatever
end;
if (x is tfoo ) then {supports the sample};
if (x is tfooBase ) then {does not make public the sample};
You then know that tfooBaseclass never implement sample, but that all
tfooClass have that method. It all seems a little confusing though. I'm not
really clear what you are trying to achieve. Inheritence wants you to either
make methods static, or virtual. If it is static, you can't override it,
only hide (Replace) it.
You coule also use interfaces. Then you don't need a base class:
ifoo = interface
private
procedure sample; virtual;
end;
tboo1 = class( ifoo)
procedure sample;
end;
tboo2 = class
end;
if (tboo is ifoo) then {supports the ifoo interface};
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to know if a class implements a method
So, at this moment I know that I can: 1. Use a safe, magic and efficient way, but I need to know if it exists; 2. Create a light instance using vfooclass.NewInstance method; 3. hack the vmt. Which approach do you use? I have worked with a bespoke OPF a few years ago. The way we got around this was to use a multitier approach and literally have the client ask the server questions in this kind of situation. The server was multithreaded and it cached information, so it usually didn't have much of an impact. So long as the network traffic was minimal and only happened once per session (the reply being cached) it worked well. We also used a complex inheritance tree with interfaces being passed back from the server rather than class references. There were also tight rules about implementing methods. Methods with no implementation were not allowed in persistently stored objects. I don't think there's much more really you can do. Other than caching the RTTI info for each class you use in this way. HTH ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] A randon posting on the Borland web server
Has anyone seen this: a randon posting on the Borland web server... anyone care to relieve the poor fellow ;-) ? This is how FPC window looks on my monitor at it's maximum size. Any idea/way to make it bigger? http://www.exsotron.com/exs_pics/bucket/freepascal.jpg; He seems to be refering to the IDE. This was in a thread called FPC on borland.public.delphi.non-technical. I've sen a few of you guys there before, so, um..? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A randon posting on the Borland web server
The picture link is dead, but in general it is simply a matter of increasing terminal/dosbox fontsize. Odd, works okay for me... Okay, I'll post this ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Fpc running in Zeta?
But is there such a thing as a free download of beos? BeOS R5 PE - runs from a 500MB virtual partition - http://bebits.com/app/2680 BeOS MAX - installs to a hard disk, a new version is in BETA - http://bebits.com/app/3892 MAX is your best bet. BeOS is quite picky with hardware though. Mainly because it hasn't been commercially developed since 1999/2000. If something doesn't work, it's either because it's not supported, there's some kind of IRQ conflict, you're motherboard is pretending to be Plug and play (turn it off if you have the option) or your missing a driver. In the latter case, a quick look on BeBits usually finds whether or not you're in luck. I'd be willing to help someone get the build environment set-up. I can offer advice etc. I don't have an intel BeOS machine at the moment, so I can't help with compilation. All my Be boxes (Mac and BeBox) are PowerPC. As porting FPC to BeOS for PowerPC is impossible, I'll not dwell on that ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Fpc running in Zeta?
The wikipedia article about zeta doesn´t look very promissing: http://en.wikipedia.org/wiki/Magnussoft_ZETA That's a bit political thing. Bernd Kortz is the guy that licensed the code from Palmsource/Access. He's the guy we need to worry about ;-) As porting FPC to BeOS for PowerPC is impossible, I'll not dwell on that ;-) why? It uses Apple's PEF as its binary format, it uses Metrowerks as its C++ compiler (mwcc, mwld et al) and no assembler was ever produced (bar inline assembler.) Without an assembler, or bintools that target PEF, there's simply no way to make FPC work natively. Interestingly, the C++ ABI is the same as the one Apple Mac's use (seemingly) as least with Metrowerks tools. If Metrowerks ever released a Codewarrior MWOB binary objectfile compatible assembler in source form, porting it would be fairly simple and I guess it would make an FPC port more likely. I ran some tests a few years ago, and Metrowerks CW 9 (latest version I have - runs under MacOS X) and Metrowerks CW 6 both produce valid BeOS executables if you use the Be headers and libs (copied to MacOS obviously.) I guess, it's possible to hack a command like assembler from MacOS to work, but I wouldn't like to try to do it... Some kind of compatibility lib might work with *a lot* of work. BeOS for PPC is a dead end though. Not worth the effort. Maybe in my retirement in 30 odd years ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Fpc running in Zeta?
What´s wrong with codewarrior? They don´t like to release assemblers??? That's Metrowerks for you. They *never* seem to produce assemblers. But, with the Apple platform, you had MPW, so that wasn't an issue. Else where ... ah.. problem! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Fpc running in Zeta?
Free Pascal 1.0.10 was released with a Beos-port, developed by Carl Eric Codère. However, Carl stopped with FPC development, and nobody took over, so the Beo-port had to be discontinued. Not to contradict you, but version 2.11 is available from here: http://bebits.com/app/4321 (which basically links to the BeFPC souceforge file repo.) Olivier Coursiere maintained a port after Carl stopped producung them. I have no idea which version Pixel uses, as it uses its own widget set anyway, so theoretically should run with most versions that are at a suitable feature set. Pixel's development team were extremely underhanded in the past and took people's money (on the BeOS platform) and thengave little to show for it. Definately not the right thing to do. Only recently (with in the last 2 years) is Pixel even usable on BeOS/Zeta. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C++ Name Mangling
Does Symbian use PE? Yes, Symbian uses PE. Symbian : EPOC 32 by another name ;-) Ummm ... I would like to avoid that, but it seams that it´s easier to use a c wrapper in fact. The effort is larger, but you really do get a more stable and portable solution. It doesn't tie you to a specific language too, so should someone want to use another language (?what I don't know?) they could still use your wrapper. You might even find some one would *pay* you to use it. You never know ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
Most of your arguments point to something like VB3 To clarify, I mean in language complexity. In VB 3, one could (with little extra knowledge) code in BASIC quite quickly. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
[explaining classes is not really harder than program/unit] I disagree with this part. Sure, you will get questions of about programs/units, but the purpose of the keywords belonging to them is way easier to explain than public, static and class. To a complete novice, there's not really much in it. Honestly. In fact, students get to grips with basic OOPD fairly quickly. It often removes them from the problem and lets them visualise a solution more clearly. I want to throw another argument in the arena: libraries. The Java OOP libraries are a powerfull framework, but this adds complexity. Java standard I/O is such a maze of complexity, I'm quite sure readln is easier to explain than streams and tokenizers. Sure, but Java's API is akin to Win32 API. There's always the scope to write a simplified version if one needs to. Whether theat defeats the object (no pun intended) is another matter. [Java doesn't have pointers but references] I call references an eufemism for pointers. References are typically not pointers. References are more like a by value but operating on a central datastore. How languages choose to implement this is not relevant. The fact that usually it's as a typed pointer is just down to the architect of the compiler. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
Well, let's do the standard:
Pascal:
program
Hello_World;
begin
WriteLn ('Hello world.');
end.
Class: What does program mean? Does the name matter? Does it have to be the
same as the executable? Why is there a colon at the end of the line - isn't
the begin end at the bottom part of it - like with for or while loops or
procedure and functions? Why is there a dot/fullstop/period at the end? What
does begin and end mean? Where does writeln come from? Why is the System
unit hidden?
Ada:
with Ada.Text_IO;
procedure Hello_World is
begin
Ada.Text_IO.Put_Line (Hello World.);
end Hello_World;
Wow.. I forgot how horrible ADA was ;-)
Class: is what? Why do I need to repeat the name of the procedure? If I
use with why do I need to put the whole line in again? Why can't I leave
out with but can leave out uses? Where does the put put it? - plus
some similar ones from the Pascal above.
Java:
public class HelloWorld {
public static void main(string[] args) {
System.out.println (Hello World.);
}
}
Thins that are simpler to explain:
1) void - the procedure and function paradimn often confuses students.
With Java/C./C++/C# the syntax is completely consistent.
2) public - try explaining unit syntax to a beginner. The difference
between interface and implementation and the argument for public and
private are already on a par.
3) static, easily glossed over as a feature you will find useful later
on. No more complex than explaining the entry point in a pascal program
or how on earth ADA works out what the entry point is in the firtst place.
4) System.out how is this any more complex than the Ada example. In fact,
if you imported System.out it would actually be *simpler* than the ADA
example.
5) The string[] array of arguments.. again, it's a fairly simple you'll
find this useful in the future, but it's simply and array of the parameters
passen on the command line. The way Pascal handles this is far, far more
complicated to explain that the, quite frankly up front, way Java does.
ParamStr(), ParamCount and all that business... is not intuitive at all.
Java in that respect is definitely harder to grasp. You learn a lot of
keywords in one lesson, though.
Not really. The syntax is different, it's not that you learn anything more
or less.
So, it isn't? A full bunch of keywords wrapped inside a class to make it
OOP and it's not even close to *any* OOP is *easy*?
No, you can write seriously non OOP code in Java if you treat a class as a
unit. You could even write inline classes if you so wished.
Well, at that point programming ends and software engineering starts to
emerge. The latter Java already lacks by mixing interface and
implementation into one holy mess.
Java does nothing of the sort. It mixes nothing.. it actually forces the
programmer to think about the scope of a routine rather than leaving it up
to the luck of the draw, And when it comes to units and classes in Object
Pascal - well that's one holy big mess in itself.
Pointers - no, no, no. Java passes by reference. This is not anything
to do with pointers
That's why it's called NullPointerException instead of
NoneReferenceException, I'd suppose?
Historical.
Well, it's a minor technicality, if you call it pointer or reference.
A reference contains much more information.
different to Java? If you wish to pass integral types by reference,
box them. It's not exactly rocket science ;-)
It's damn hard rocket science, because even if you do that it's still
not clear, what sort of parameter mode it is supposed to have. :P
Not really... Objects are passed by reference. That's the only rule you need
to remember ;-)
double is a simple type, Double is a class.
double dd = 3.142;
Double dD = new Double(d); //boxed..
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows--Linux library
The fonctions use to manage sockets under Linux and Windows are different. Rather than nasty ifdefs, you might want to look at the Free Pascal port of the Synapse Sockets library. It will abstract away your OS differences and pushes support of the network code away from your hands. http://synapse.ararat.cz/ I used Synapse with Windows a few years ago and found it very good. YMMV. HTH M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2.1 version
Another source of info might be http://www.freepascal.org/mantis/changelog_page.php Though it gives quite a lot of info, that page also fails with the following error (just now, maybe not always?) : Fatal error: Allowed memory size of 10485760 bytes exhausted (tried to allocate 35 bytes) in /FPC/html/mantis-1.0.3/core/bug_api.php on line 880 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease thevisibility of a method?
I use singletons in the following cases. The problem with using singletons in this way is that they're not [very] thread safe. You end up needing a locking mechanism that gets tiring very quickly. I can't offer you a better solution, but I have worked on a project where it was a real problem, and so speak from experience. If you go down this route, you kind of force single threadedness on to your application - which obviously might be what you desire. Retro fitting threading semantics on to such an app is a complete nightmare though. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: [lazarus] Article on Pixel.
I don't know all that much about graphics, but (Jedi-)SDL is a great 2D and 3D library that uses OpenGL. It can also use other platform dependant graphic engines like DirectX on Windows. JEDI SDL is a Delphi (ObjectPascal) binding to SDL created by the JEDI project (actually, I used to work for the same company as its lead maintainer.) JEDI has nothing directly to do with SDL. No more than SDL.Net does (a binding for C# and other CLR/.Net languages.) It is written in C++, Actually its in plain old C AFAIA; but I may be wrong.. Certainly, it presents a flat C style API interface. but there are versions for Delphi and FPC. No, JEDI SDL is what you are thinking of. SDL is a seperate project. Unfortunatly it was never made compatible with TForm or to use with LCL or VCL components. SDL has nothing to do with the TForm hierarchy of components. It is more like the GDI under Windows. It's a low level graphics API. It's not a widget set. HTH ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease thevisibility of a method?
On 8 dec 2006, at 10:55, Graeme Geldenhuys wrote: I still don't know why we can't decrease visibility in Free Pascal. Is there some internal language design that prevents it? At least Borland explicitly says you cannot do that: http://info.borland.com/techpubs/delphi/delphi5/oplg/classes.html Delphi 5 onwards generates a hint for each method that is of a lower visibility thatn its ancestors implementation. I've used the following to implement a singleton before: unit x; interface type ISingleton = interface [-GUID GOES HERE-] procedure SingletonAction; end; var MySingleton: ISingleton; implementation type TSingleton = class(TInterfacedObject, ISingleton) private procedure SingletonAction; end; procedure TSingleton .SingletonAction; begin [] end; initialization MySingleton := TSingleton.Create; finalization MySingleton := nil; end. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpdoc and three packages
Hi Graeme - sorry to be slightly off topic, but is tiOPF working with FPC now? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpdoc and three packages
Yes, for a year now... Been using it in a commercial application since January. Cool.. and it works with Lazarus? I looked at tiOPF, but went with instant objects becauuse it had better Delphi 5 support. tiOPF is cross platform too? M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpdoc and three packages
Delphi 5 support has been removed in tiOPF version 2, but version 1 is still available on request. Anybody still using tiOPF v1 is highly recommended to upgrade to tiOPF v2. No, I used v1. I looked at how much work a backport to D5 would be. Mostly it was routines missing from the Delphi RTL until you got into the whole RTTI debarcle. Needless to say I gave up. I use the Model-GUI-Mediator (MGM) pattern, to make any standard GUI control Object Aware. MGM is a combination of the Observer and Mediator design patterns. Never used that patter but have used those patterns to achieve the same result. However, it's pnly viable for new projects, and those are not generally in Delphi here anymore. Useful for my own work though I guess. If you've never looked at Instant Objects it is worthwhile. Far, far simpler to get in to than tiOPF. Only Win32 though AFAIAA. Yes, tiOPF is standard Object Pascal code. I use tiOPF under Linux and Windows for all my projects. Very useful to know. Thank you! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with multiple inheritance
How can I work around this? I mean, how can I redesign my idea to make it work with FP? Note that Qt requires that all methods to receive events, and signals be from objects (I cannot use a procedure to receive events). In Delphi, I'd do it through interfaces. Delphi has this neat little trick that lets you have a property that implements an interface. Assuming FPC supports that, if you need to refer to the class that owns the property, you simply add a property of the correct interface type that the owner implements and then set it on creation. Having said all that, if you go OTT with this, there are a number of bugs I found (at least in Delphi 5) that make A/V's happen quite frequently. Okay, if that option is not available, use a design pattern, like the Adaptor or Mediator , or cheat. I wrote a basic wrapper for the Be API in Free Pascal (not the one that you may have heard of - that was occo, mine was more like the Kylix Qt wrappers.) But what I found was that I needed to do things that the BeAPI didn't support. So I wrote a glue library in C++ that took each control and added the features I wanted at the level I needed them in C++. I then created an abstract class tree to represent each Pascal class, with lots of protected members. I then promoted the methods and properties I needed as and when I needed them. This strikes me as what you need. Alternatively, look at the way occo did it for BeOS. http://www.sf.net/projects/befpc . An older version of my (now lost) code is there too. Oh, whilst were speaking, please stop mentioning Lazarus every time people mention Kylix on the B.P.D.Non-tech news group. It's tiresome. All you'll end up doing is making people realize that Kylix did more than Lazarus does at the moment in Kylix 1. You're turning more people off than on IMHO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with multiple inheritance
In the future, make this kind of comments in private, Would you listen any more gracefully? not in the middle of a technical discussion. It was related to the discussion. It was also a small proportion of the rest of the email. 24 lines, only 4 related to this outburst. You are overreacting. This has no place on this thread. Debatebale. Please refrain from ordering me to do *anything* and then maybe we can all speak like adults. I at least had the courtesy to say please and certainly didn't assume any form of authority over you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc arm big endian help
- Original Message - From: Terry Kemp [EMAIL PROTECTED] To: fpc-pascal@lists.freepascal.org Sent: Monday, October 23, 2006 11:14 PM Subject: [fpc-pascal] fpc arm big endian help Hi all I'm working on some code for the NSLU2 'slug'. How do I get ppcarm to compile in big endian mode? I have done it once before but I've lost the magic wand somewhere. Do I need to build from source as in a post I saw on devel list... change system_arm_linux_info.endian to endian_big in /pp/compiler/systems/i_linux.pas then run make clean CPU_TARGET=arm CROSSINSTALL=1 then make crossall CPU_TARGET=arm OS_TARGET=linux heres one I prepared earlier... $ file /opt/slugtest /opt/slugtest: ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, statically linked, for GNU/Linux 2.0.0, stripped so I know it worked before - but now... $ ppcarm -XParm-linux- slugtest.pp Free Pascal Compiler version 2.0.4 [2006/08/23] for arm Copyright (c) 1993-2006 by Florian Klaempfl Target OS: Linux for ARM Compiling slugtest.pp slugtest.pp(26,10) Note: Local variable lK is assigned but never used slugtest.pp(10,6) Note: Local variable lI not used Assembling slugtest Linking slugtest 69 Lines compiled, 0.0 sec $ file slugtest slugtest: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, statically linked, for GNU/Linux 2.0.0, stripped $ ppcarm -XParmv5b-linux- slugtest.pp Free Pascal Compiler version 2.0.4 [2006/08/23] for arm Copyright (c) 1993-2006 by Florian Klaempfl Target OS: Linux for ARM Compiling slugtest.pp slugtest.pp(26,10) Note: Local variable lK is assigned but never used slugtest.pp(10,6) Note: Local variable lI not used Assembling slugtest Linking slugtest /home/tkemp/bin/armv5b-linux-ld: /usr/local/lib/fpc/2.0.4/units/arm-linux/rtl/prt0.o: compiled for a little endian system and target is big endian /home/tkemp/bin/armv5b-linux-ld: failed to merge target specific data of file /usr/local/lib/fpc/2.0.4/units/arm-linux/rtl/prt0.o /home/tkemp/bin/armv5b-linux-ld: /usr/local/lib/fpc/2.0.4/units/arm-linux/rtl/system.o: compiled for a little endian system and target is big endian /home/tkemp/bin/armv5b-linux-ld: failed to merge target specific data of file /usr/local/lib/fpc/2.0.4/units/arm-linux/rtl/system.o... ... I'm cross compiling from x86_64 if that makes any difference... fpc-2.0.4-2.fc5 Free Pascal Compiler version 2.0.4 [2006/09/20] for x86_64 Copyright (c) 1993-2006 by Florian Klaempfl Thanks for any help Terry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.8/489 - Release Date: 20/10/2006 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc arm big endian help
Ooops.. this time with a reply.. prt0.o is a bit of assembler IIRC... is it compiled for bigendian? That looks to be your issue. Part of the RTL is in little endian format and needs to be recompiled. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Data exchange between programs
I have 2 FPC programs running on a Linux machine, is there an easy way to exchange a few data between these programs (I do not want to use disk operations). I was thinking of using environment variables, but I cannot find a way to change environment variables from a program. MMap? Unix domain sockets? Or do these count as file operations? Isn't there a GetEnv and SetEnv procedure/function somewhere in the LINUX RTL? Libc or somewhere like that? HTH, M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboExplorer
http://www.borland.com/downloads/download_turbo.html - Original Message - From: Leonardo M. Ramé [EMAIL PROTECTED] To: fpc-pascal@lists.freepascal.org Sent: Tuesday, September 05, 2006 8:37 PM Subject: [fpc-pascal] TurboExplorer It looks like TurboExplorer wait time is finished but...Can't download anithing :( Leonardo M. Ramé http://leonardorame.blogspot.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/438 - Release Date: 05/09/2006 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi ShareMem -DLL-pchar
Can anyone comment on the Delphi unit ShareMem and if FPC ever did any work to incorporate what this Delphi unit is doing for DLL shared memory managment? I'm looking so far, at the docs on creating a memory manager, and at the strings unit, which has some pchar utilities in it. I don't use it any more. I use FastMM or BucketMM. you only really need SHareMem if you are passing String types (string/AnsiString etc) to a DLL. It doesn't sound like you're doing that. Beware, Sharemem is slow and buggy in my experience. Also, you would need sharemem in FPC as Delphi assumes you are sending your Delphi types (strings, classes etc), that dictate you need Sharemem, to another Delphi process. This article, http://delphi.about.com/od/objectpascalide/l/aa103003a.htm explains much about the Delphi related, Win32 DLL pointer and shared memory problems. I'm working on creating a DLL between two Win32 applications, but having a lot of exception and pointer related problems to do with pchar and asciiz data transfer. the only way to avoid issues is to make sure the process that allocates the buffer deallocates it. That fixes most issues. C gets round it because you generally use the same compiler and Malloc etc. With Delphi and FPC, you are going to have issues because they are two completely different compilers. I'd do something like: function getFpcStrBuffer(buffer: pchar; const size: integer): boolean; and procedure freeFpcStrBuffer(buffer: pchar); //maybe size too? then var b: pchar; begin if getFpcStrBuffer(b, 21) then try callAFpcDllRoutine(b, 21); finally freeFpcStrBuffer(b); end; Do that in the DLL yhou want to pass data TO. So FPC would implement it, for example. Get the Delphi code to then allocate and free buffers using that routine. Something ike that. Avoid using STRING/ANSISTRING/WIDESTRING when passing to a DLL like the plague. Sorry lack of sleep.. must go to bed. Hopefully that makes sense. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AsciiZ confusion
As noted, the Delphi Program integrates a DLL stub which forces me to make calls using it's pre-defined Variants Only format. I'm not clear why you need to have a FPC DLL between a PB DLL and Delphi... this part makes no sense. If you need to, dynamically load the DLL. If you are exporting params compatible with FPC, they should also be compatible with Delphi. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typecasting by accident
No. Typecasts, as any other aspect of a language, has to have rules. AFAIR this cast in Delphi would require another cast from AnsiString to Pointer. And if typed pointers is enabled would require another cast from Pointer to TObject. Nope. The C style cast is not type safe. Using the as operator is. var p: pointer; i: integer; begin i := 10; p := TObject(i); //will work, but is invalid p := (i as TObject); //should fail (not tried) because i is not compatible end; M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typecasting by accident
Weird, I wouldn't expect OBJFPC mode to allow automatic conversion from AnsiString to Pointer... Um... raise Not_Now (Exception_Message); It's a CAST dude! Exception_Message is being case as Not_Now. That should work fairly well in most dialects.t M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
Smaller than FPC ? That shouldn't differ too much, I think. Delphi's optimizer is superior to FPC currently. Delphi has another 10 - 15 years and paid developers on top of FPC, so this can be expected, I guess. And the compiler is just sooo fast. Delphi 2005 gives 1.48MB for the mside.exe uncompressed. That is probably without DB support. I just complied the main unit with no changes other than to a couple of properties. I don't really see why ability to compile with Delphi is so big an advantage (distinct) ? For all the reasons others have stated. Also, Delphi's debugger alone makes it worthwile. If you don't like the debugger, fine. However do not blame your dislike of the Delphi debugger on your personal debugging preferences. I've been using Delphi commercially since 1998, or there abouts, and the debugger is perfectly acceptable. The debugger is the thing I always miss in other IDE's, especially VS.NET 2003. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
debugger, fine. However do not blame your dislike of the Delphi debugger on your personal debugging preferences. I've been using Delphi commercially since 1998, or there abouts, and the debugger is perfectly acceptable. The So can you confirm that looking at variables that are up the stack does not work for you as well? Was is supposed to work? I can't say that is does because I don't generally debug that way. As I said, you blame the debugger when, in fact, it is the style of debugging you employ that is causing you problems. Delphi promotes a break often style of debugging. Utilise the call stack to trace the code path, but set break points to inspect variables. This is how I have always worked and this is how I feel comfortable working. F7/F8/F9, the Evaluate/Modify and the call stack is all that is needed. debugger is the thing I always miss in other IDE's, especially VS.NET 2003. Hmm, from what I've heard, the debugger in Visual Studio (6?) is *way* more advanced than the one in BCB, and that one's better than Delphi's. I don't assume they've removed the debugger from 2003 ? It is slw as hell to step through code. Slooower on a PDA for example. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
If it ain't broke, don't fix it. Well, compared with other commercial compilers it is broken ;) Heh, well when I can do what I am currently able to do in Delphi in an FPC based IDE, we'll talk again, yes? ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
Because of the superior functionality valgrind offers, I've installed vmware at my pc at work and compile sometimes my programs with gcc (usually developed with MSVC) to find memory leaks, dangling pointers etc. Hmmm... so GCC produces the exact same output as MSVC now? I don't think so. All you'll find are syntactical errors mainly. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] another fpc RAD: MSEide
MSEgui has a distinct advantage over Lazarus. It compiles under Delphi. Just tried it. Fiddled with one or two lines in the code, but I got the IDE to compile and run and then built a small hello world app that also ran. Pretty impressive really. M Hi, Movie: = For those who did not try MSEide yet, here is a movie teaser. http://users.pandora.be/Jan.Van.hijfte/qtforfpc/mse01.html Wiki: === http://www.freepascal.org/wiki/index.php/MSEide__MSEgui Can someone provide a more appropriate entry in the wiki for this page. I cannot modify all pages, but did not find an appropriate page either. Perhaps there should be some page: fpc related projects. kind regards, Den Jean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a Modern Language
Not wishing to make this OT, but... Talk to them about targets that c# does not reach, like *BSD, Mac OS X, Sparc, etc =) Um.. *cough* Portable.NET, *cough* Mono. Both will get you on to most of those platforms. Don't assume Microsoft needs all the answers. You can certainly compile under Windows and run under some of theose OS with little changes. Others might mean slight GUI tool kit issues. No more so that a Delhi to Kylix or Lazarus transition though. However, I have never heard a story describing the opposite, ie. a person going from Pascal to a C-Language and having the same epiphany. I've tried to make the transition myself on several occasions, but I always end up coming back to Pascal. This will bring a tear to your eye then... I have been a Delphi/Pascal programmer for 10 years. I recently began a transit process to C#, and .Net and I absolutely love it. It is a complete breath of fresh air. I can't think of a single reason to stay using Object Pascal, not one. And there are only small bits of the VCL I miss (DB access components.) I have used Delphi 2005, and Object Pascal is just funky and nasty when used with .Net. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal a Modern Language
Not so fresh, since it's the people that designed Delphi which designed C# and .NET, so actually you are doing more of the same. Nothing is fresh in IT. OP originated (so I understand, at least partially) with additions to Pascal for MacOS. God only knows what will happen now that Borland is going through its changes. Without the Delphi jump point, making OP an important language will be a lot harder. Let's hope the new company doesn't go down the toilet ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiStrings and Memory Management
(astonishing that ShortStrings are slower than AnsiStrings in this example in delphi). Not really. Delphi is silently upcasting your shortstrings to AnsiStrings in the background. You would probably have to recompile the VCL to get around this ;-) Hope that helps, M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Boolean expression short-circuit
Thanks, I guess I lost the argument :]. Anyway, I guess it wouldn't hurt to clarify that just a little bit in the manual :-/ However, IIRC complete boolean eval (which is what delphi calls it) would blow the code up, as even if Foo was nil, the second half would be evaluated regardless. Maybe that will go some way to winning part of the argument? ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cgi-bin/PSP
i was pretty sure there might be some PSP lurkers on this list. You have to be careful here, because there are two competing projects called PSP. One is by a Spanish guy (who wrote the Nemesis Pascal interpreter too) and uses an Object Pascal interpreter to pretty much do the same kind of thing as PHP, and the other is by an Eastern European guy and it seemed to me (when looking) was just a way to write CGI in Pascal. I personally use PSP, but I use the former - which has been greatly extended by me to support more webservers and also to load plug-ins rather than staticly linking everything. I'm not clear if this is what *you* are using, but this is what I immediately thought of. IMO the former is far superiour as I can change a page in a plain text editor - I only need to recompile if I want to change the core functionality. The downside - it is Delphi/Kylix only, as it uses Jedi VCL. Your mileage, obviously, may vary ;-) M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] single application instance
How can I also do it in linux? Use semaphores. There is a semaphore implementation for LINUX, Windows, BeOS and probably most other Unices. Certainly, any platform that conforms to POSIX and/or PThreads will have a semaphore implementation. The mechanics will be different - the idea will be universal. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal 2.0 for cygwin
Is there some posibility to make (compiling) fpc without fpc? Is there some makefile or script in fpc (cvs) to avoid to use a fpc 1.0.0 or 2.0.0 to create a fpc new version? Cygwin runs exclusively on Windows machines... FPC has a Windows port. Whilst I can see the point of a port to Cygwin, I seriously can't understand why you can't use the Windows compiler to bootstrap the compiler. Cygwin is just a bunch of DLLs and support binaries at the end of the day, and creating a minimal bootstrap implementation using the Windows compiler, whilst not trivial, is the simplest way of doing it. Am I missing some reason for not using the Win32 compiler? By the way, how would one compile Pascal code without a Pascal compiler? No magic script file will avoid the need for fpc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extended float to single and pchar types
Hi,
I have a stdcall reference to a c based dll. called target.dll
In c the setup is ...
Are you sure it is stdcall? Quite often it's the calling convention that
messes up the calling of a C DLL. Could it be safecall or cdecl? Which
compiler made the DLL?
float Get_l1_BidPriceSingle(void* p);
The Pascal reference is...
function Get_l1_BidPrice(p : pointer) : single;
stdcall; external 'target.dll' name 'Get_l1_BidPrice';
Which all looks okay.
The end result is to allow a usage in win32 as ...
SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar(s)));
Hmmm.. this is not a good idea if 's' is of type string. If 's' is a string
(AnsiString or whatever) you should probably call SetLength on it, and I'd
also advise passing a pointer to the first char too, rather relying on the
cast.
E.g.
s := 'Test data';
SetLength(s, Length(s));
SendMessage(listbox, LB_ADDSTRING, 0, longint(@(s[1])));
That probably has more chance of working, but still assumes you are not
crossing process boundaries. If threads are involved, it's not going to
work.
The c reference is a 'Single' float, but each time I make refernece to
data
conversion, errors tell me that the reference to the call is returning a
10
bit Extended float which fails, appearing to be a default autotype
conversions to an extended 10 byte float, in fpc.
If it is a reference, it should probably be a pointer. Is the C function
really returning the resultant by value, or by reference?
Converted data as an Ansistring seems to fail any type of conversion, as
a
runtime 207 crash.
Convert how? FloatToStr should handle any floating point type.
e.g.
var
f: single;
d: double;
e: extended;
begin
f := 10.01;
d := 10.01;
e := 10.01;
messagebox(0, PChar(FloatToStr( .. ), 0); // replace '..' with f, d or e
end;
If I store Str conversions to a shortstring, I can format the fp and
convert it to a fixed decimal rounded output, xxx.yyy, but using length()
direct or pointer access, still pulls the 0 byte and extra characters of
the
string into any other converted output, requiring array managment and
parsing.
var
s: string;
f: single;
begin
f := 123.45678; //this will round
s := format('%3.3f', [f]); //think sprintf
end;
Is there a way to take an extended FP and covert it ultimately to a
Pchar
that would allow messaging to win32 list boxes or similar to a litteral
equivelent behaviour, without having to run through all the symantics of
array management?
OR
Can one circumvent the auto-typing to extended, so that single or double
would behave to conversion methods like FloatToStr() that I could then
type
over to pchar and serve the same purpose?
Surely you could just use an extended and then cast it? So long as it is
possible to store the value in the variable you wish to, it'll work.
Clearly I'm not yet comfortable with string manipulation in Pascal, so an
example would go a long way toward getting me to where I can do the work
myself.
Well, it's an awful lot simpler that C until you have to interact with C API
calls!!
M
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Sharp Zaurus ARM port stability?
Just laid my hands on a used Zaurus SL5500. I was wondering how stable the Zaurus cross compiler and QT wrapper were? I realise this is slightly off topic, but I remember the developer working on the bindings posted to this list a while back. Any info? TTFN, Matt ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sharp Zaurus ARM port stability?
The fpc qte binding demo program shows that it is usable. If however you have problems and think it is binding or fpc related, I am always willing to investigate this. I just did so for someone who had a problem with QLCDNumber, it probably is a small fpc bug concerning passing a double parameter. If you use something else than Mandrake, it would be nice if you could adapt my installation instructions to match your experience on your distro. I will add then update my webpage and the fpc wiki (they need an update anyhow) http://users.pandora.be/Jan.Van.hijfte/qtforfpc/qtedemo.html http://www.freepascal.org/wiki/index.php/Setup_Cross_Compile_For_ARM Excellent. I do have a Mandrake 8.1 and Mandrake 9.0 install CD hanging about. Are either of those preferable? I would also like to get it going under Windows.. just because I know I'll be in Windows for more frequently. Was there a specific reason for using LINUX, bar the obvious QTE runs on Zaurus, Zaurus uses LINUX thing? Matt ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
