Re: [fpc-pascal] DirectFB for FPC beta tarball
Hello Roland Thanks for the committ andd the tar ball.. I've set aside next weekend to explore and begin testing it. Perhpas others in the group are like me and putting the tarball on their 'To-Do' list. Prince On Sun, May 31, 2009 at 7:23 AM, Roland Schaefer roland.schae...@fu-berlin.de wrote: Hello. There wasn't much feedback to our previous anouncement. Anyway, now there is an FPC-DirectFB tarball which can be downloaded from our SourceForge page: http://sourceforge.net/projects/wiseslap/ Please have DFB 1.0.1 or higher installed. One sample program is included. The known major bugs of previous SVN versions have beeen fixed. We're now starting to actually use DFB in our project. Reports (bugs or anything) are thus highly appreciated. For information on DFB visit: http://www.directfb.org/ Cheers, Roland ___ 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] IE 200307043
Hello Frank,
If my past post was unclear as to whether I think the constant 'nil' is an
address, then let me be clear. I quoted the Borland Object Pascal's
statement nil 'does not reference anything' I was not equating it to a zero
address value. While a pointer with a 'zero' address value should be
invalid, it is different from a pointer with a value of 'nil.'
FP uses the special address constant, 'nil' in much the same way. If you
assign a pointer a valid address and perform valid operations on it, say you
repeatedly decrement or shift it (arithmetic) you could produce an invalid
address. But it would not be 'nil'.
Nil is, by definition, an address; albiet, a special one like the
mathmatical set theory concept of 'empty or null set'. Nil is defined as a
'meta value' and as such whatever the lowest address value in the range of
addresses actually is, nil is defined not a member of that set.
The distinction between a valid address expression that has 'nil' as an
operand and an invalid one (decrementing or shifting a pointer outside a
valid address range) however raises a related by seperate issue. FP must
have operators like assignment or comparision that allow 'nil' to be used in
an expression.
The 'value' such an expression has must be defined in some way just as nil
is a defined lanuage constant; a way that consistently signals
('represents') the expression or operation produces an invalid result. So in
the example given there are two possible decisions
p := p + nil; is INVALID (expression is valid, operands valid but result
is invalid) -- execution error, execution addressing exception
or
p := p + nil; is UNDEFINED (expression is invalid, no operation, no result)
-- compiler error
The second case is what FP does when nil is used in an expression . The
ultimate problem lies in the first case, how to implement nil in a
consistent and reliable way as a internal binary value.
In KR, for example, the NULL address pointer is 'defined' but is
implemented in several different ways based on target CPU. If you look at C
program startup library code you'll see that. The NULL address value in 'C'
was defined for several years a binary '0' on VAX, and PDP machines. This
allowed tests for invalid or empty pointers using the compact syntatic
expression ' if (p) {...}'
Likewise, (p = NULL; and p == NULL) in C are both valid expressions neither
result in compiler warnings or errors (in strict compilers they do) But
there is a difference between how they operate on the expression (p = NULL +
p) and (p = 0 + p) which is similar to the case we are talking abotu here.
So here is our questiuon: should FP allow the expression (p := nil + p)? If
so, what should the result be? I opt that FP should treat it as an invalid
expression (compile error) and not as a valid expression with an UNDEFINED
value. I realize that this differs from what others might think or suggest.
On Wed, May 27, 2009 at 7:49 AM, Frank Peelo f...@eircom.net wrote:
Prince Riley wrote:
Frank,
I think the crux of the matter here is how to make the distinction between
a pointer with 'no value' and one that is initialized or set to the 'lowest
possible value in the range'. The quote I mentioned comes directly from
Borland's Object Pascal Langage Manual
The reserved word nil is a special constant that can be
assigned to any pointer. When nil is assigned to a pointer, the
pointer doesn't reference anything.
I'm only quibbling with the equation of doesn't reference anything with
lowest possible value in the range. On many architectures, a pointer value
of 0 might be a reasonable choice for doesn't reference anything because
the CPU has interrupt vectors there, or uses address 0 for something else.
But my point is that this is not guaranteed. Nil might not even point to
valid data memory.
You can check on this, but when I looked it up the 'nil' constant in a
Object Pascal Language reference and what the reserved word 'nil' , a
special constant, means in terms of pointer value (it's not an address) I
was not able to find and what adding/subtracting/multiplying it by a
literal numeric value (or another valid pointer value) to 'nil' would
create.
But I'm more puzzled by what it would /mean/. In spite of your bracketed
comment here, you seem to be thinking that nil is an address: i.e.
adding/subtracting/multiplying a literal would mean something. I'm just
pointing out that, if you think it's an address, it's undefined. Because
it's not any address. So adding something to it doesn't mean anything.
...
If you then set another breakpoint on the next instruction,
p := p + 1;
you'll notice that the first thing that happens is 'p' get set to a valid
segment address and then the offset, and not the base segment, is
incremented by a value of '1' (again on a Intel CPU machine).
Yup, GIGO.
FP
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Re: [fpc-pascal] IE 200307043
Hello, There seems to be a bigger issue on this... but perhaps someone else confirm that the following programs, similar to the failing one, work. program test1; var p: Pointer; begin p := nil; p := p + 1; end. Does work and the following program program test2; var p: Pointer; begin p := nil; Inc(p); end. works also am I the only one getting this result? Prince On Sun, May 24, 2009 at 4:30 PM, Joost van der Sluis jo...@cnoc.nl wrote: Op zondag 24-05-2009 om 23:14 uur [tijdzone +0200], schreef Aleksa Todorovic: Hi, all! I've just tried to compile some of my old Pascal code, and got IE 200307043. I've tried both 2.2.4 and svn trunk versions. Simple program to generate it: program test; var p: Pointer; begin p := nil + 1; end. I couldn't find issue about this in bug tracker, should I report it? Yes, an IE is always a bug an should be reported. If you can not a report with '200307043' in it, it's not reported yet. Joost. ___ 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] IE 200307043
Hello, I had a chance to go to a reference and check on what the reserved word 'nil' , a special constant, seems to mean. According to the Object Pascal manual (Borland) ... The reserved word nil is a special constant that can be assigned to any pointer. When nil is assigned to a pointer, the pointer doesn't reference anything. Since a pointer is a memory address value, then the interpretation of the statement nil +1 would mean for p to point at the very next valid address above the lowest memory address 'p' can hold. So it would appear that 'p := nil + 1' should not compile or work. My guess, and its just a guess, is that for 'nil + 1' to work then it would have to be done in two steps and not one, e.g. 'p := nil; p := p +1; ' .. both of which are valid statements. Now I have no idea what size address increment the compiler would choose (byte, word, float, etc.) to add to p. Perhaps it assumes PChar .. But if that's not how it works, then my next question about the interpretation of 'p := nil + 1; ' is what is the 'size' of the 'p + 1' increment? How can that increment be set to without casting 'p' to a specific Pascal type (Integer, Char, Byte, Word, etc.). So for Object Pascal the side effect of the statement 'p := nil +1' has to be valid address. As such the compiler does not know the type of object 'p' points at, it can't create a valid address. On the other hand, untyped Pointers are a compromise in Object Pascal , a strongly typed language, to be similar to untyped pointer expressions like void * pointers in C. Untyped C language pointers, according to KR, represent the smallest unit of addressable memory for the CPU architecture (bytes on Intel). However, even in C, the closest equivalent expression to 'p := nil + 1', void *p, is 'p = NULL, p = p + 1' works (compiles) but issues a warning about the 'p = p + 1' expression (GCC v4). On Mon, May 25, 2009 at 12:48 PM, Prince Riley wmarketi...@gmail.comwrote: Hello, There seems to be a bigger issue on this... but perhaps someone else confirm that the following programs, similar to the failing one, work. program test1; var p: Pointer; begin p := nil; p := p + 1; end. Does work and the following program program test2; var p: Pointer; begin p := nil; Inc(p); end. works also am I the only one getting this result? Prince On Sun, May 24, 2009 at 4:30 PM, Joost van der Sluis jo...@cnoc.nlwrote: Op zondag 24-05-2009 om 23:14 uur [tijdzone +0200], schreef Aleksa Todorovic: Hi, all! I've just tried to compile some of my old Pascal code, and got IE 200307043. I've tried both 2.2.4 and svn trunk versions. Simple program to generate it: program test; var p: Pointer; begin p := nil + 1; end. I couldn't find issue about this in bug tracker, should I report it? Yes, an IE is always a bug an should be reported. If you can not a report with '200307043' in it, it's not reported yet. Joost. ___ 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] IE 200307043
Jonas, Thanks for the reply. That's a very interesting answer. So am I understanding you to say that the expression of the form var := constant + numeric literal ; is an invalid expression (syntax) in Object Pascal? Why would the expression adding a numeric literal and a numeric constant create anything other than a numeric value? Both are assignment compatible with the pointer type, both have values known at compile time. True both have known values, but how does that change in the addition operation? Both operands in the 'p := null + 1; expression' are constants that's true. But isn't one a literal constant and in Object Pascal an expression of the form: variable := constant + numeric literal is valid ? Now I grant you an expression like 'a' + 1; would be invalid syntax; but in 'null + 1' there's only one constant and a numeric literal, not two. So unless I misunderstand you, or there's some run-time evaluation, shouldn't this expression be valid? (but I still worry about how the compiler would assign the correct type to the pointer (is it a valid address). On Mon, May 25, 2009 at 6:45 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 25 May 2009, at 19:48, Prince Riley wrote: There seems to be a bigger issue on this... but perhaps someone else confirm that the following programs, similar to the failing one, work. That's because the error was in the constant evaluation (nil and 1 are both constants). Jonas ___ 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] IE 200307043
Jonas Thank you Jonas, for clearing that up. I agree. You have more courage than I my friend to say that, for down that path lies monsters. For while I must agree with your point, in theory it raises a bigger concern. The 'nil' for a pointer constant is problematic in two ways. Fixing this 'bug' could mean addressing two language issues. Type checking for valid pointer arithmetic and the difference between a 'null' or empty pointer and one that has the lowest value of it's type. Both those points may sound abstract and esoteric, but they lie at the heart of the 'fix' for this bug. As you can surmise, for a strongly typed language like Object Pascal, pointer operations should be 'type safe' at best and 'type neutral' for flexibility and utility. Even the apparently simple addition of numeric literal and a pointer requires considerable thought for reasons of portability and ensuring that pointer arithmetic doesn't become a source of opaque bugs. Prince On Mon, May 25, 2009 at 8:43 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 25 May 2009, at 22:39, Prince Riley wrote: That's a very interesting answer. So am I understanding you to say that the expression of the form var := constant + numeric literal ; is an invalid expression (syntax) in Object Pascal? No, I meant that there was a bug (error) in the compiler regarding handling expressions of the form nil + integer constant. It's a valid expression. nil has as type pointer, and you can add integers to untyped pointers (constant or not). The result is again an untyped pointer. Jonas ___ 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] IE 200307043
Frank, I think the crux of the matter here is how to make the distinction between a pointer with 'no value' and one that is initialized or set to the 'lowest possible value in the range'. The quote I mentioned comes directly from Borland's Object Pascal Langage Manual You can check on this, but when I looked it up the 'nil' constant in a Object Pascal Language reference and what the reserved word 'nil' , a special constant, means in terms of pointer value (it's not an address) I was not able to find and what adding/subtracting/multiplying it by a literal numeric value (or another valid pointer value) to 'nil' would create. If you're interested in the details (they are very instructive) compile a sample program with the two programs on an Intel based machine and then check the generated code with the GNU Debugger. Set a break point on the following statement p := nil; and then single step to the next instruction. You'll see immediately that two things happen: 1) the value assigned to 'p' by that statement is not a valid segment/offset address (i32/i64 architecture). If you then set another breakpoint on the next instruction, p := p + 1; you'll notice that the first thing that happens is 'p' get set to a valid segment address and then the offset, and not the base segment, is incremented by a value of '1' (again on a Intel CPU machine). Things get even more interesting when 'p' is first typed, to an Integer for example, and then assigned the 'nil' value. var R: Integer ; P: Pointer; IntArray1, IntArray2: array of Integer; IP: ^Integer; IntArrayPtr: Pointer; begin P := nil; P := @R; P := P + 1; P := nil; IntArray[0] := 1; IntArray[1] := 1; IP := @IntArray[0] IP := IP + 1; IntArrayPtr := @IntArray[1]; if IntArrayPtr^ IP^ then Writeln (Integer Array values not the same); end. Setting breakpoints on the statements where values are assigned to 'P' and 'IP' and watching how their values are set, incremented, and dereferenced will demonstrate how challenging even a simple pointer handling model can be. On Mon, May 25, 2009 at 10:57 PM, Frank Peelo f...@eircom.net wrote: Prince Riley wrote: Hello, The reserved word nil is a special constant that can be assigned to any pointer. When nil is assigned to a pointer, the pointer doesn't reference anything. Since a pointer is a memory address value, then the interpretation of the statement nil +1 would mean for p to point at the very next valid address above the lowest memory address 'p' can hold. That is an interesting interpretation of doesn't reference anything. There is no guarantee that nil is address 0, although it may be so in any available compiler -- at least, any compiler targetting an architecture that does not have usable memory at address 0. Nil doesn't point at anything. It's an undefined address. So it would appear that 'p := nil + 1' should not compile or work. That would be reasonable - although if nil /was/ 0, then nil+1 would be defined for any given pointer type, and a compiler /could/ make a stab at compiling it -- but probably /should not/. Because what would 1 more than undefined mean? FP ___ 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] DBus interface needs an update
Matthias, You might want to take a look at the thread (see below) on this I found On 10/15/06, Marco van de Voort [EMAIL PROTECTED] wrote: Florian, afaik Sebastian already had DBus stuff. He demonstrated it in Muenchen? Arg, duplicated work? Well ... he should have written somewhere that he did it. Anyway dbus is very new, and the API changed a lot in it's short life. It's only getting to 1.0 now, so it's not that bad. My bindings will also have to be updated to 1.0. Currently they are for 0.62 -- Felipe Monteiro de Carvalho On Mon, May 18, 2009 at 11:38 AM, Matthias Klumpp matth...@nlinux.orgwrote: Hello! I've spent hours to get the Pascal DBus interface working for me, but even the example code does not work. The DBus package is very old, as it was created, DBus has not reached version 1.0 yet, I think because of that DBus Pascal is not working today. It would be great if someone could update the DBus files. DBus is an elementary technology for interprocess-communication that is used in every Linux distribution that has a graphical user interface. Maybe the new DBus package could be based on DBus-GLib? I've not much experience in translating the C headers to Pascal, but if someone starts working on this, I would help if I can. Best regards Matthias Klumpp ___ 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
[fpc-pascal] Re: Sourceforge Lazarus DEB Fails on Ubuntu Hardy Heron
Time for Ubuntu and Debian to get these things fixed ... After spending almost five hours attempting to install the lazarus ide on Ubuntu Hardy Heron I've discovered that the souce of all this trouble is a fight between the debian maintainer of the FPC debs and the Ubuntu folks who have not sync'd the libraries and package names.. After reading this console log and looking thru literally hundreds of pages and web notes I come to find out that none of the posted instructions to put the lazarus ide on a Ubuntu system (Hardy) will work correctly .. it doesnt matter how you try or malform the apt-get, its broken fundamentally at the core and unless someone at Ubuntu or Debian get their libs names syncd back up this will remain a problem. The fpc users are caught in the middle here and forgive me for being so blunt, but its neither fair nor professional for the Debian manintainer to fail to notice all the posts that keep popping up on this problem without resolving this and keeping it fixed . The following packages were automatically installed and are no longer required: libglib1.2-dev libgdk-pixbuf-dev libgdk-pixbuf2 libgtk1.2-dev lazarus-src The following packages will be REMOVED: lazarus-src libgdk-pixbuf-dev libgdk-pixbuf2 libglib1.2-dev libgtk1.2-dev 0 upgraded, 0 newly installed, 5 to remove and 2 not upgraded. After this operation, 69.8MB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 173594 files and directories currently installed.) Removing lazarus-src ... Removing libgdk-pixbuf-dev ... Removing libgdk-pixbuf2 ... Removing libgtk1.2-dev ... Removing libglib1.2-dev ... Processing triggers for libc6 ... ldconfig deferred processing now taking place pri...@prince-ubuntu:~$ sudo apt-get install -f Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. pri...@prince-ubuntu:~$ sudo apt-get install lazarus-ide Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: lazarus-ide: Depends: libxi6 (= 2:1.1.3-1ubuntu3) but 2:1.1.3-1 is to be installed E: Broken packages pri...@prince-ubuntu:~$ sudo apt-get install --force-yes lazarus-ide Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: lazarus-ide: Depends: libxi6 (= 2:1.1.3-1ubuntu3) but 2:1.1.3-1 is to be installed E: Broken packages On Wed, May 13, 2009 at 11:59 PM, Prince Riley wmarketi...@gmail.comwrote: The current .DEB lazarus-ide_0.9.26.2-0_i386.deb available from the Sourceforge repository reports a dependency error when I attempt to run it on Ubuntu 8.04. The error reads, Error: Dependency is not satisfiable: libxi6 What makes this vexing is the installer reports a dependency error when in fact I checked the Ubuntu install with Synaptic and it reports that libxi6 is present and up to date. Can anyone explain why the .DEB package is reporting a missing library when that library is present on the Ubuntu system? Is this a version issue? Can I just force the files onto the system and ignore this error. It appears to be a problem with the deb package and not the file it says is missing. --- ___ 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
[fpc-pascal] Sourceforge Lazarus DEB Fails on Ubuntu Hardy Heron
The current .DEB lazarus-ide_0.9.26.2-0_i386.deb available from the Sourceforge repository reports a dependency error when I attempt to run it on Ubuntu 8.04. The error reads, Error: Dependency is not satisfiable: libxi6 What makes this vexing is the installer reports a dependency error when in fact I checked the Ubuntu install with Synaptic and it reports that libxi6 is present and up to date. Can anyone explain why the .DEB package is reporting a missing library when that library is present on the Ubuntu system? Is this a version issue? Can I just force the files onto the system and ignore this error. It appears to be a problem with the deb package and not the file it says is missing. --- ___ 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] Linking issue in Ubuntu 9.04 (32 bit)
Jonas, Sorry to but in, but I read this post and followed the link to the binutils problem you mentioned in your reply. Is it possible the error message, Can't call the linker,... is the result of a bad/missing symlink and not the problem in binutils? I have Ubuntu 9.04 desktop now but haven't installed FPC as yet. Prince On Fri, Apr 24, 2009 at 3:49 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 24 Apr 2009, at 22:39, Alan Krause wrote: I've installed ubuntu 9.04 in a VM to test it out, and have installed fpc 2.2.4. It is always good to look before you leap, right? Anyhow, I am trying to compile an existing project that works fine under Ubuntu 8.04. I can get all of the unit to compile, but when it comes time to link them together into a shared library, I get the following: Linking libproj.so Error: Can't call the linker, switching to external linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled) It's probably caused by this bug in binutils: https://bugzilla.novell.com/show_bug.cgi?id=471901 It has been fixed in the mean time, but only after binutils 2.19.1 was released (and I guess your Ubuntu comes either with 2.19 or 2.19.1 -- although the bug already existed in some 2.18.x versions as well.). Jonas ___ 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] Linking issue in Ubuntu 9.04 (32 bit)
Jonas, Thanks for taking the time to reply Jonas. When I get Ubuntu 9.04 installed this weekend I'll shoot you an e-mail confirming the version of binutils it has ... Prince On Fri, Apr 24, 2009 at 4:42 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 24 Apr 2009, at 23:28, Prince Riley wrote: Sorry to but in, but I read this post and followed the link to the binutils problem you mentioned in your reply. Is it possible the error message, Can't call the linker,... is the result of a bad/missing symlink and not the problem in binutils? It's indeed a generic error message. To see what really happens, you have to compile with the -Cn command line parameter and then execute the generated ./ppas.sh script. The problem is most likely the fact that ld crashes though, as I'm pretty sure that Ubuntu 9.04 ships with binutils 2.19.x Jonas ___ 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] Linking issue in Ubuntu 9.04 (32 bit)
Alan Thanks so much Alan.. another landmine I can try to avoid with 9.04 .. appreciate your help Prince On Fri, Apr 24, 2009 at 5:09 PM, Alan Krause al...@shermanloan.com wrote: Jonas, It does indeed ship with 2.19.1. I've had this same problem in the past, and have had to stick with ubuntu 8.04 for my development box due to this problem. Prince - if you execute fpc with the verbose option (-va), it actually displays the search for a linker to use, which in my instance is found in /usr/bin/ld and listed as found. Alan On Fri, Apr 24, 2009 at 2:42 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 24 Apr 2009, at 23:28, Prince Riley wrote: Sorry to but in, but I read this post and followed the link to the binutils problem you mentioned in your reply. Is it possible the error message, Can't call the linker,... is the result of a bad/missing symlink and not the problem in binutils? It's indeed a generic error message. To see what really happens, you have to compile with the -Cn command line parameter and then execute the generated ./ppas.sh script. The problem is most likely the fact that ld crashes though, as I'm pretty sure that Ubuntu 9.04 ships with binutils 2.19.x ___ 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] ARM / SheevaPlug followup
It would seem that its probably best we take some time and try to spec out, test, and the publish the steps to follow since I've been interested in a port like this as well. Can we use the steps followed to port PFC to the MacOS hardware platform when it was non-Intel? Should be be looking at a cross-compile approach using the i386 host (Linux) and the SheevaPlug developer tools? How can we condense down the FPC libraries and what linking strategy should we use? (static) Just a few questions that I have on my mind looking at this. Prince On Tue, Apr 14, 2009 at 4:21 PM, Henry Vermaak henry.verm...@gmail.comwrote: 2009/4/14 Florian Klaempfl flor...@freepascal.org: Henry Vermaak schrieb: first you need to get fpc to work, which means that you might have to build an eabi compiler, since most distros (even debian) now use eabi (the default arm fpc is oabi). Well, not really. Debian stable is still oabi. hmm, according to this: http://www.debian.org/ports/arm/ the oabi is deprecated... henry ___ 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] Creating FPC enabled websites
On Wed, Mar 4, 2009 at 1:33 AM, Michael Van Canneyt mich...@freepascal.orgwrote: On Tue, 3 Mar 2009, Prince Riley wrote: Joost Reading the responses on this discussion thread, it appears the 'religious war' you mentioned in your prior post was unavoidable. Not to add any fuel to the warring opinions I'd like answer a comment you made in response to my response. The recent push to make web applications (not simply web browsing) perform more like desktop applications has been the primary driver behind the Web 2.0 and the improved Javascript engines by Google and the Mozilla people. They have their own commercial motivations for those improvements, the primary driver has been the software application developers who want web apps to perform like desktop ones. While several traditional desktop application scenarios do still exists that will likely always run directly on the O/S without a web client front end, the direction of most major software application development efforts I've witnessed in the past three years have all targeted migrating the desktop GUI over to a web browser. Others in the discussion thread have referenced several reasons for this shift already, but the trends continue to follow the idea of pushing as much of the presentation and processing layers onto the remote web browser. Finally, respectfully I must disagree with your comments that the applications deployment approach is only true for small applets used by a broad public. ignores the TOC and other economies of scale afforded by portable web applications. Scott Trade and TD Ameritrade are just two of several examples where sophisticated trading desk and customer centric web-based applications are running on 100,000s of web browsers. Just a few years ago these same applications were shipped to clients and had to be installed and run on their desktop PCs. Well, drop by and I'll prove to you - hands down - that what our clients need simply cannot be done by web applications, because they cannot interact with the local desktop. Can your web-app burn a CD-ROM ? Does it have access to a smartcard reader ? Can it start and control MS-Word ? Can you drop files on it to send to the server ? For the sake of clarification let me ask you if its your position that web-apps are limited due to the fact that they are not hosted on a systems H/D and loaded into memory by the O/S in response to a mouse click or a keyboard type in? Is the distinction you are making here between a web-app and a desktop (installed application) based on your understanding that a web-app interface cannot drive and launch local installed hardware and software.? If that's your presumption, and I hope I am mistaken in saying that it is, then let me answer affirmatively .. to each question.. YES , they can. Leaving aside the security implications and the issue of specific hardware capability, Sun Microsystems Java Platform, especially its HotSpot installer/environment can do nearly all the things you have mentioned with very few exceptions. Likewise, with some modifications, the new JavaScript engines and the applications being written and released by Mozilla, Google, Amazon, to run on them can all but replace the entire MS Office Suite. In less than two years, the entire Win32 GUI and service API will be a web-application based entirely on thee .NET framework ( just download Windows 7). Five years ago, Steve Ballmer even announced that the future architecture of the Windows desktop application and O/S system platform would be to migrate toward web-hosted applications consisting of web-deployed components. He was later even more clear on this point stating that future releases of the Windows OS and application suite would not be pre-installed on new desktop PCs, but provided via the web on SOA as leased-licensed products. In essence, the desktop machines workhorse applications with notable few exceptions would all be web-apps. Python, another web-app language, can run MS Office applications using COM/DCOM. without any drag, drop, or click. So unless I am missing the point you are making entirely, and mistaken about the scenarios you mention here, the answer to your questions are yes and yes. However. if you asking whether a web app can start a CD burning program (like Nero) on a remote user machine? The answer is absolutely yes. But can a web-app physically open the CD tray and insert the CD-RW media .. no, but neither can any desktop application or any C/Sapplication. Can a web-app take the data from a smart card reader attached to the system .. again yes it's not a problem whatsoever.. done all day, every day, all over the world. Can a web-app physically put a Smart card into a reader .. no, it can't; but neither can a desktop application or any C/S application. Can a web-app transparently without user intervention start a MS-Word application, open files, and do
Re: [fpc-pascal] Creating FPC enabled websites
On Wed, Mar 4, 2009 at 5:31 AM, Dariusz Mazur dar...@emadar.com wrote: Prince Riley pisze: Since the discussion in this thread has advanced pretty far along toward recommending a FP and Powtils solution to you, then it appears you have a technical answer from the group you can explore. However, without suggesting there is a bias in favor of a specific client-centric vs server-centric web framework, the REST protocol has succeeded in becoming a paradigm for writing web (client sever) apps. Primarily the reason why is -- especially for DB web applications -- is efficiency, maintainability, and scalability. The recent major efforts by Mozilla, Google, and others to improve the performance of browser Javascript engines is due to their experience designing, writing and running CGI based web applications. There is quite a bit of literature and discussion on the web explaining why they are using REST versus CGI (Request/Response) which you might find helpful in making your design choices. REST is bad choice for application , especially for this with much interaction with DB. REST is stateless. Are You see any desktop application, which is stateless? REST is good for simple catalogs, list of parts, etc. For sophisticated application this architecture has many limitation. Most of view depend of before user actions. -- Darek Darek, At the risk of sounding dismissive let me first point out that every one of the application types mentioned in your list are DB applications. Perhaps you meant to choose other examples to make your point. But unless the catalogs and lists of parts are trivial and small, a software architect wouldn't approach building a significant version of these kinds of applications without using a DB. Next, yes REST is stateless. But how does that work to prevent the level or nature of the application data exchanges that flow between the client and the server. Once a transaction is executed on the server by a REST protocol message, the 'state' of the application's data isn't part of the protocol, nor part of the message returned to the client when the request is completed. Let's use a more a representative example. Whenever a client refreshes the data sent to it by the server, its a local copy; and it's that copy, not the protocol, that is what is stateful. The REST protocol would eliminate fetches of rows or tuples from the server it does not need or those the server has no reason to take note of or care about.. Likewise the server would only send updates to the client which affected the 'state' of the transaction that it fetched, for example a change in the row or column made at the server's end of teh transaction. But again, this is a change in the 'state' of the exchange and unless the application's exchange/notification semantics which asked for notification of ANY access to a tuple, even a simple READ, it received from the server. Prince R The REST protocol and the design frameworks built using it are used in applications with significant DB application processing ___ 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] 2.2.4 for FreeBSD AMD64?
Hello I just checked the list on FreeBSD kernel group on the AMD64 port.. and the answer is maybe.. A more definitive answer might be available soon I was told. There is still some delay on the QC for the 2.2.4 RC1 that hasn't been completed and the person doing that QC wasn't answering with a date as yet. On Wed, Mar 4, 2009 at 7:34 PM, Francisco Reyes li...@stringsutils.comwrote: Is there any way to get 2.2.4 RC1 for FreeBSD AMD64? ___ 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] 2.2.4 for FreeBSD AMD64?
If anything breaks before then, I'll send you word on the RC... Prince On Wed, Mar 4, 2009 at 10:04 PM, Francisco Reyes li...@stringsutils.comwrote: Prince Riley writes: Thanks for the reply. I just checked the list on FreeBSD kernel group on the AMD64 port. The work is getting done by someone on the FreeBSD side? the answer is maybe.. A more definitive answer might be available soon I was told. There is still some delay on the QC for the 2.2.4 RC1 that hasn't been completed and the person doing that QC wasn't answering with a date as yet. Thanks again. I guess I will wait a week or two and follow up if there have been no news. ___ 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] Creating FPC enabled websites
Since the discussion in this thread has advanced pretty far along toward recommending a FP and Powtils solution to you, then it appears you have a technical answer from the group you can explore. However, without suggesting there is a bias in favor of a specific client-centric vs server-centric web framework, the REST protocol has succeeded in becoming a paradigm for writing web (client sever) apps. Primarily the reason why is -- especially for DB web applications -- is efficiency, maintainability, and scalability. The recent major efforts by Mozilla, Google, and others to improve the performance of browser Javascript engines is due to their experience designing, writing and running CGI based web applications. There is quite a bit of literature and discussion on the web explaining why they are using REST versus CGI (Request/Response) which you might find helpful in making your design choices. I have not worked with Powtils so I can't discuss whether or not it has the features your application needs, or what the costs of using it might be in terms of server processing load (Web server Request/Response), response time, DB transaction processing load, etc. I also don't know whether it can be tweaked in some way to support the REST protocol for an application like yours. On Mon, Mar 2, 2009 at 3:16 PM, Francisco Reyes li...@stringsutils.comwrote: Prince Riley writes: Finally, give the advance from CGI based web apps to Web 2.0 (Javascript running in the browser) is there a design rational for running code on the server instead of in the web browser. I think that is almost a religious war type of discussion... Short answer (as it applies to me at least) If all I am doing is getting data from a DB and displaying it in the browser, there is little reason to do Javascript. past few years. Zend (which is PHP, not Javascript) is also an alternative. Personally my preference would be 1- Pascal 2- Python 3- PHP PHP can do absolutely everything I need/want; the difference is that I want something which lends itself more easily to well organized and structured coding. Also When I work on php it always feels like work.. even if it something I am doing for fun. It is one of those subjective things... the reason why there are so many languages and tools out there. ___ 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] Creating FPC enabled websites
One further point in this thread ... As a starting point in your thinking thru the design choices, here is a fairly complete but accessible article on the topic you might find helpful http://www.ibm.com/developerworks/java/library/wa-ajaxarch/index.html On Tue, Mar 3, 2009 at 12:30 PM, Prince Riley wmarketi...@gmail.com wrote: Since the discussion in this thread has advanced pretty far along toward recommending a FP and Powtils solution to you, then it appears you have a technical answer from the group you can explore. However, without suggesting there is a bias in favor of a specific client-centric vs server-centric web framework, the REST protocol has succeeded in becoming a paradigm for writing web (client sever) apps. Primarily the reason why is -- especially for DB web applications -- is efficiency, maintainability, and scalability. The recent major efforts by Mozilla, Google, and others to improve the performance of browser Javascript engines is due to their experience designing, writing and running CGI based web applications. There is quite a bit of literature and discussion on the web explaining why they are using REST versus CGI (Request/Response) which you might find helpful in making your design choices. I have not worked with Powtils so I can't discuss whether or not it has the features your application needs, or what the costs of using it might be in terms of server processing load (Web server Request/Response), response time, DB transaction processing load, etc. I also don't know whether it can be tweaked in some way to support the REST protocol for an application like yours. On Mon, Mar 2, 2009 at 3:16 PM, Francisco Reyes li...@stringsutils.comwrote: Prince Riley writes: Finally, give the advance from CGI based web apps to Web 2.0 (Javascript running in the browser) is there a design rational for running code on the server instead of in the web browser. I think that is almost a religious war type of discussion... Short answer (as it applies to me at least) If all I am doing is getting data from a DB and displaying it in the browser, there is little reason to do Javascript. past few years. Zend (which is PHP, not Javascript) is also an alternative. Personally my preference would be 1- Pascal 2- Python 3- PHP PHP can do absolutely everything I need/want; the difference is that I want something which lends itself more easily to well organized and structured coding. Also When I work on php it always feels like work.. even if it something I am doing for fun. It is one of those subjective things... the reason why there are so many languages and tools out there. ___ 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] Creating FPC enabled websites
Joost Reading the responses on this discussion thread, it appears the 'religious war' you mentioned in your prior post was unavoidable. Not to add any fuel to the warring opinions I'd like answer a comment you made in response to my response. The recent push to make web applications (not simply web browsing) perform more like desktop applications has been the primary driver behind the Web 2.0 and the improved Javascript engines by Google and the Mozilla people. They have their own commercial motivations for those improvements, the primary driver has been the software application developers who want web apps to perform like desktop ones. While several traditional desktop application scenarios do still exists that will likely always run directly on the O/S without a web client front end, the direction of most major software application development efforts I've witnessed in the past three years have all targeted migrating the desktop GUI over to a web browser. Others in the discussion thread have referenced several reasons for this shift already, but the trends continue to follow the idea of pushing as much of the presentation and processing layers onto the remote web browser. Finally, respectfully I must disagree with your comments that the applications deployment approach is only true for small applets used by a broad public. ignores the TOC and other economies of scale afforded by portable web applications. Scott Trade and TD Ameritrade are just two of several examples where sophisticated trading desk and customer centric web-based applications are running on 100,000s of web browsers. Just a few years ago these same applications were shipped to clients and had to be installed and run on their desktop PCs. On Tue, Mar 3, 2009 at 2:44 PM, Joost van der Sluis jo...@cnoc.nl wrote: Op dinsdag 03-03-2009 om 12:30 uur [tijdzone -0600], schreef Prince Riley: Primarily the reason why is -- especially for DB web applications -- is efficiency, maintainability, and scalability. The recent major efforts by Mozilla, Google, and others to improve the performance of browser Javascript engines is due to their experience designing, writing and running CGI based web applications. There is quite a bit of literature and discussion on the web explaining why they are using REST versus CGI (Request/Response) which you might find helpful in making your design choices. All those parties have a interest in trying to get as much as people using web-aplications. But the key point in this is that people forget that javascript-programs are not meant to replace a full-blown desktopapplication. What they say, in fact, is that building web-applications on the server side isn't a good idea. (They promoted it for years, and finally they have come to the insight that it doesn't work) So now they suggest to build a client-side web-application. But the question they forget is: why would you want a web-application in that case anyway?!?! Use a db-server and a desktop-application and all your problems are gone... It's all so narrow-minded. If you have as a rule thou shall develop web-based all these things become important. Web-based applications are usefull when you have users who only use your website now and then. In that case it does't matter much if one session takes some time on the server - unless you are google, offcourse. (But also large community-sites now are releasing desktop-clients) If users use the application constantly, don't use a web-application. So the things explained in this document from IBM is usefull for very large systems which a lot of users (Like Amazon, but they also don't like the idea of a full-blown javascript application) or some idiots who do things in a web-application while they shoudn't. Joost. ___ 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] Creating FPC enabled websites
Travis, I am joining this discussion fairly late so if you've found your solution already please ignore this post. First, upon reading you feel Irie Pascal is 'optimized' for CGI execution on OSX (Leopard?) my first question is how are you defining that. I've looked over the Irie code just now (using the trial version) and I compared it to the Indy 9 component. So far I don't see anything that would suggest Irie's CGI could handle HTML requests any faster or handle larger loads better that the Indy components. Could you explain in a bit more detail what are you using as the baseline for your comparisons? Next, could you also be a bit more specific if you are trying to write CGI components for an embedded web server or do you expect to run them under an standalone web server (like Apache)? Again just for the sake of understanding what options to recommend to you, the choices you outlined in your links all appear to be fairly common, ordinary web server add-ons that really rely more on what the CGI tolls calls (external process or a daemon) than something more exotic (like a DB server or transaction-based gateway). Finally, give the advance from CGI based web apps to Web 2.0 (Javascript running in the browser) is there a design rational for running code on the server instead of in the web browser. If you want to see a few examples of this kind of web app check out Google Gears. Its just one of several web app frameworks that have become more stable and production ready in the past few years. Zend (which is PHP, not Javascript) is also an alternative. On Mon, Mar 2, 2009 at 12:06 PM, Travis Siegel tsie...@softcon.com wrote: Not fpc related, but irie pascal (http://www.irietools.com) has a pascal that is cross platform, and does handle web support quite well. My attempts to get him to support osx has fallen flat, but dos, windows, bsd, solaris (I think) and other distributions are supported, so it may do what you want. If something like irie pascal could be built using fpc though, it would be a great help, since I'd really like to build some web apps, but w/o irie for osx, it puts a serious crimp in my ability to make cross-platform apps. Fpc is cross platform I know, but as far as I know, it's not optomized for cgi execution like irie pascal is. I suppose I could build a stripped-down version of fpc specifically for cgi-type work, if anyone is interested in such, but i like the approach irie took in that you could use the same compiled source on any of it's supported platforms. I've thought about cloning irie pascal virtual machines and writing that in fpc, but I don't know if i want to do that much work just to get something that out to be simple to create if Mr.Stewart would pull his head out of his nether regions and allow somebody to make anyhow. ___ 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] Porting linux to pascal, would it be, possible ?
Graeme, I find that very interesting. The Eclipse group has redesigned the web site and it now has a much cleaner and easier to navigate 'front door' that leads most visitors directly to the major Java or Rich Client IDE. Prince On Tue, Dec 9, 2008 at 3:56 AM, Graeme Geldenhuys [EMAIL PROTECTED]wrote: On Mon, Dec 8, 2008 at 8:07 PM, Prince Riley [EMAIL PROTECTED] wrote: Eclipse was first released as a Java development IDE several years ago, but if you take a look at the Eclipse web site www.eclipse.org you'll see that since then Eclipse has evolved and been extended to support Ruby, Python, C/C++. That project is such a mess (my personal opinion). Just the other day I wanted to download the Eclipse IDE, to see what has changed over the last few years since I looked at it. Well, after browsing their website for 30 minutes, I still couldn't find a clear download Eclipse IDE here link! What's up with that!!! I simply gave up and moved on. 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] How Much of the FP/LCL is there in Indy 9/10 of Lazarus?
Hello
Has anyone used or attempted to use Indy with FPC... and if so how did you
incorporate the Indy components.
On Thu, Dec 11, 2008 at 12:24 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Thu, 11 Dec 2008 18:39:18 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Hi,
hopefully someone can help me with my first steps at migrating my
Delphi programs to Lazarus.
I have a TListBox which I modify in the following way:
---
with Form1.ListBoxAusgaben do
begin
Items.Add('aaa');
Items.Strings[Count-1] := 'xxx';
Items.Add('bbb');
Items.Strings[Count-1] := 'yyy';
ItemIndex := Count-1;
Repaint;
end;
---
The result is that I get 3 lines with the first line being
'xxx' plus 2 empty lines. It seems that only the first ADD
and the first aasignment to Strings[Count-1] is done but all
following changes do not appear. Is this a bug in FP/Lazarus?
Maybe. Please create a bug report with a complete example.
Mattias
___
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] Re: Embarcadero/CodeGear officialy interested in Firebird and on native versions of Delphi for other operating systems ...
Jurgen and Bee made a few rich contrasting points about Borland's past mistakes. However, we must acknowledge that Borland's biggest problem was Borland persisten failure to deliver 'price competitive' and 'high value' programming tools. No one denies Borland's well earned reputation for innovation in Windows programming, Turbo C, Turbo C++ and Delphi blew the doors off MC Visual C and MFC programming for they Windows 3.1, Windows 95, Windows NT platforms. They lead with products that were not only feature rich, they turned out solid code and made the job of wrangling the Windows Frameworks like COM, COM+, AFC, ODBC, ASP, and MFC much easier. However, they grabbed defeat from the jaws of victory when they overextebded their development group (Inprise), rushed incomplete and inadequate products (Kylix, Delph 7/8) to market while they buried themselves in 'Enterprise' COBRA/IIOP, and database engines. When they slipped, like the hare, this gave MS the catch up and pass them which allowed them to solidify their base with the OS systems. On Wed, Dec 10, 2008 at 1:01 AM, Jürgen Hestermann [EMAIL PROTECTED] wrote: So, supporting open source should be the safest choice for them. If M$ grows bigger, they can grow bigger with M$. If M$ goes down, they can still grow bigger with other platforms (linux, mac, etc). Many years ago (when Borland was still a real competitor of M$) Borland had problems to create good compilers because they didn't have all the information about the M$ OS (while compilers from M$ had of course). I remember that some articles stated that Borland made a deal with M$ so that they will get information but on the other hand may not support other OSes (and open source). I am not sure whether that's true but it would explain the behaviour of all Delphi owners. Jürgen Hestermann. ___ 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] Porting linux to pascal, would it be, possible ?
Thank you for your reply. Eclipse was first released as a Java development IDE several years ago, but if you take a look at the Eclipse web site www.eclipse.org you'll see that since then Eclipse has evolved and been extended to support Ruby, Python, C/C++. The suggestion I was making is there is a very large base of programmers, developer, and others who now use Eclipse as their primary IDE in much the same way UNIX folks use emacs and if there were a Eclipse FPC plugin they could discover and learn the language. Prince On Mon, Dec 8, 2008 at 3:58 AM, Marco van de Voort [EMAIL PROTECTED] wrote: In our previous episode, Prince Riley said: Like ti weigh in on this thread in the discussion regarding increasing the GUI-ness of FP. Has anyone looked into writing an Eclipse plug-in for FP (as an was done for Python and Ruby)? Afaik there was a more editor like plugin at one time. But at that time designer support only existed for C++ and Java. Haven't heard much since. Given the huge base of Eclipse users this might be a way to reach the goal with both a better developer tool and plugging into a big audience of potential users. Afaik most Eclipse users use Java? ___ 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] Porting linux to pascal, would it be, possible ?
Hello Like ti weigh in on this thread in the discussion regarding increasing the GUI-ness of FP. Has anyone looked into writing an Eclipse plug-in for FP (as an was done for Python and Ruby)? Given the huge base of Eclipse users this might be a way to reach the goal with both a better developer tool and plugging into a big audience of potential users. Prince On Sat, Dec 6, 2008 at 10:34 PM, Andrew Haines [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: On Fri, Dec 5, 2008 at 5:55 PM, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: If you want to do some large work to increase the use of FPC I would recommend creating a Window Manager instead, probably with fpgui. How far did you guys get with the 'fpwm' project? Did it actually run at some point. I see the last code changes was 2 years ago. I just checked out fpwm and updated it and fpgui locally so it can compile. It does almost nothing atm but can reparent and close windows :) not alot. I was thinking I might write a widget for resizing and moving windows. Currently the window title bar is a Label and a Button that has an X for it's text and stdimg.quit as the image. I might work on it some in the coming week if I can find the time. Regards, Andrew ___ 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] Free Pascal Support for ARM Architecture
Sorry to everyone for replying so far down the thread to the points mentioned earlier. The FPC ARM support is stated as ' does not specify an ARM architecture' ... fine ..but there is a major issue there that needs clarification and better documentation. Is it really safe to have no way to target the entire compiler (FP code and assemble op codes that are passed thru) output to a specific ARM processor? Since the back end GNU as supports several variants of ARM, why is FP limited to an unspecified ARM processor? If FP compiler is outputting ARM assembler code for the entire program, and the assembler ignores invalid ARM opcodes, without specifying what ARM sub-architecture (ARM7, ARM5, ARM9), then what defines which ARM op codes are 'invalid' ? I realize that at the time someone may have thought it really didn't made any difference, but as was mentioned in this post, several ARM processors do not have multipliers. So what happens when one writes a FP function that multiplies two numbers? How does the complier choose to output ARM ADD opcodes instead of MULTIPLY opcodes? Does the FP compiler just use ADD opcodes all the time? What I keep asking here and not getting a precise answer about is what specific ARM opcodes does the FP support What is its default ARM architecture is the opcode spec based on? To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.' Perhaps the person who coded that support into FP can write back and say which ARM op codes look-up table it uses generating the FP compiled code. Is it ARM7? Is it ARM9?, Is it ARM4/5? Thanks Prince On Mon, Dec 8, 2008 at 12:27 PM, Marc Santhoff [EMAIL PROTECTED]wrote: Am Montag, den 08.12.2008, 19:22 +0100 schrieb Jonas Maebe: On 08 Dec 2008, at 18:26, Marc Santhoff wrote: There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for hardware multiplier unit. Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. That's a compiler and not an assembler decision. Yes, you're right, sorry. Code generator issue, that is. Marc ___ 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] Free Pascal Support for ARM Architecture
Sorry, I think you are mistaken.. I did ask which ARM Architecture and if you follow the thread back you'll see I even gave examples of what the assembler options were for ARM Here is the text of that post === Thanks for that reply ... and yes I meant IA32 A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' *the GNU assembler back end of which ARM architecture is intended ..*. The following is just a snippet from the GNU Assembler manual showing the ARM processor option codes ... -mcpu=processor[+extension...] This option speci es the target processor. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target processor. The following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500, arm7500fe, arm7t, arm7tdmi, arm8, arm810, strongarm, strongarm1, strongarm110, strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, arm9e, arm946e-r0, arm946e, arm966e-r0, arm966e, arm10t, arm10e, arm1020, arm1020t, arm1020e, ep9312 (ARM920 with Cirrus Maverick coprocessor), i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm) technology coprocessor) and xscale. The special name all may be used to allow the assembler to accept instructions valid for any ARM processor. In addition to the basic instruction set, the assembler can be told to accept various extension mnemonics that extend the processor using the co-processor instruction space. For example, -mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312. The following extensions are currently supported: +maverick +iwmmxt and +xscale. *I need to be clear on how FP specifies one of these option and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end'* == if you look at this list you'll see that ARM3,6, and 7 are among the options. So back then, as I have up to now, I asked which assembler code option ( meaning -- which ARM architecture --) did FP support. On Mon, Dec 8, 2008 at 2:17 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 08 Dec 2008, at 20:43, Prince Riley wrote: What I keep asking here and not getting a precise answer about is what specific ARM opcodes does the FP support What is its default ARM architecture is the opcode spec based on? The problem was that you never asked for which ARM architecture FPC generates assembler code, but only which ARM sub-architecture parameter FPC passes to the GNU assembler. Those are two completely separate questions (and unrelated in this case). By default, FPC generates ARMv4 architecture code. You can also ask for ARMv5 and ARMv6 code (using the -Cp command line option, see ppcrossarm -i for the possible options). In practice, the only difference at this time is that the prefetch() statement is not translated into assembler code unless you target ARMv6 (because earlier ARM cpus do not have a prefect assembler instruction). To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.' They are variants of the same processor family (just like the i386 and the Core2Duo are variants of the same processor family). The fact that they are variants does not mean that they support exactly the same instruction set. Jonas ___ 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] Free Pascal Support for ARM Architecture
Marc, Just wanted to say thank you for that info.. much obliged. Prince On Mon, Dec 8, 2008 at 2:14 PM, Marc Santhoff [EMAIL PROTECTED]wrote: Am Montag, den 08.12.2008, 13:43 -0600 schrieb Prince Riley: Perhaps the person who coded that support into FP can write back and say which ARM op codes look-up table it uses generating the FP compiled code. Is it ARM7? Is it ARM9?, Is it ARM4/5? As already mentioned by Jonas: it is the Achitecture v4. Look there for reference: http://www.arm.com/products/CPUs/architecture.html Marc ___ 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] Re: Embarcadero/CodeGear officialy interested in Firebird and on native versions of Delphi for other operating systems ...
Bee -- You make a very excellent point in your post and one that I think doesn't get repeated loudly enough into the ears of the Embarcadero folks. Maybe its time for an open letter posted to these kinds of lists and sending their president a e-mail with the link to read the comments for himself. Market presence, that elusive and ill-defined Holy Grail that Borland chased, is now luring these folks into trying to be too many things to too many people. But what we as developers with the FPC and Lazarus must do more of and be keen about is promoting the benefits you describe and coding projects that will make the case less a matter of loyalty and more a matter of results. The mobile/embedded market is the place every software tool company wants to be right now. It's very difficult to get Embaradero to take their eyes off the .NET market since they have decided to sell $900 development tool sets. We have to be smarter than they are and keep pushing the language toward these new applications. Prince On Mon, Dec 8, 2008 at 9:33 PM, [EMAIL PROTECTED] wrote: something i just read at http://www.firebirdnews.org and in Marco Cantu's blog ( http://blog.marcocantu.com/blog/coderage_2008_closing .html) Sometimes I just understand those guys. Delphi (as language) by support of FreePascal and Lazarus had been already on Mac and Linux since years! Especially since Lazarus supported GTK2 on Linux and Carbon on Mac. Why are they still busy with other alternatives (Mono/.Net, Java, RealBasic, Ruby, XCode, etc) while what they had been dreaming about is right before their eyes. Yes, FPC and Lazarus is not perfect, but what is?! FPC's FCL and Lazarus' LCL is very much similar and compatible with Delphi's (as product) VCL. Having single codebase for different platforms and OSes is not that hard, though in some special cases it can't be 100% single codebase but it can be solved easily using IFDEFs. Some people (mostly people in this list) have been using Delphi (as language) on more than 16 platforms (including mobile devices), yet they are (Codegear/Embarcadero fan boys) still dreaming about it. My very deep condolence goes to them. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ 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] Free Pascal Support for ARM Architecture
Jonas Thank you for that reply. OK.. well if that opinion is just a guess, then as this is really a question that has to be answered by actually looking at the FP code and finding out what it sets as the ARM specific GNU AS command line options. Prince On Sun, Dec 7, 2008 at 3:11 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 07 Dec 2008, at 00:30, Prince Riley wrote: A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' the GNU assembler back end of which ARM architecture is intended ... FPC does not specify any particular sub-architecture to the assembler. I guess this means it's just a generic ARMv4 (i.e., ARM7 and above). Jonas ___ 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] Free Pascal Support for ARM Architecture
My point is saying 'guess' was not to discredit your statement about what the FP compiler does, rather to say that no one seems to know exactly what ARM option FP sends to the GNU Assembler and what that option value actually is. Reading the GNU as manual, the arch parameter value needs to be set to one of several values. It can also specify generic ARM architecture, but that choice in addition to being imprecise, could result in code that either is not optimized for the target ARM processor, or fail to execute as expected. Thank you for your reply. Prince On Sun, Dec 7, 2008 at 4:53 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 07 Dec 2008, at 23:01, Prince Riley wrote: On Sun, Dec 7, 2008 at 3:11 PM, Jonas Maebe [EMAIL PROTECTED] wrote: On 07 Dec 2008, at 00:30, Prince Riley wrote: A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' the GNU assembler back end of which ARM architecture is intended ... FPC does not specify any particular sub-architecture to the assembler. I guess this means it's just a generic ARMv4 (i.e., ARM7 and above). OK.. well if that opinion is just a guess, then as this is really a question that has to be answered by actually looking at the FP code and finding out what it sets as the ARM specific GNU AS command line options. FPC does not specify any particular sub-architecture to the assembler. was not an opinion or a guess, but a fact. What sub-architecture the GNU assembler picks in that case (i.e., by default) was the guess. Jonas ___ 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
[fpc-pascal] Free Pascal Support for ARM Architecture
Hello I have read on the wiki that FP supports ARM.. which I find very interesting.. After reading the manuals I see that FP uses the GNU tools as back-ends and they support ARM ... but it that the extent of the support here. For example, the ASM directive in FP targets the IA33 processor semantics/syntax ...not ARM .. I am not opposed to working up the missing pieces if that's necessary, but before beginning that work, I wanted to check with the group and see if anyone had already started down this road and if so how far along have you gotten ? Thanks Pricne ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Hello Thanks for that reply ... and yes I meant IA32 A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' the GNU assembler back end of which ARM architecture is intended ... The following is just a snippet from the GNU Assembler manual showing the ARM processore option codes ... -mcpu=processor[+extension...] This option species the target processor. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target processor. The following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500, arm7500fe, arm7t, arm7tdmi, arm8, arm810, strongarm, strongarm1, strongarm110, strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, arm9e, arm946e-r0, arm946e, arm966e-r0, arm966e, arm10t, arm10e, arm1020, arm1020t, arm1020e, ep9312 (ARM920 with Cirrus Maverick coprocessor), i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm) technology coprocessor) and xscale. The special name all may be used to allow the assembler to accept instructions valid for any ARM processor. In addition to the basic instruction set, the assembler can be told to accept various extension mnemonics that extend the processor using the co-processor instruction space. For example, -mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312. The following extensions are currently supported: +maverick +iwmmxt and +xscale. I need to be clear on how FP specifies one of these option and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end' Thanks Prince On Sat, Dec 6, 2008 at 4:55 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 06 Dec 2008, at 23:32, Prince Riley wrote: After reading the manuals I see that FP uses the GNU tools as back-ends and they support ARM ... but it that the extent of the support here. For example, the ASM directive in FP targets the IA33 processor semantics/syntax ...not ARM .. I guess you mean IA32 rather than IA33. Anyway, FPC is always compiled with support for creating code for one single cpu architecture. The currently supported ones are i386 (=IA32), x86_64, powerpc (32 bit), powerpc64, sparc and ARM. Apart from generating code for one such architecture, every such compiler can also only parse assembler code written for that same architecture (since there is no way the compiler can translate assembler code written for one architecture into assembler code for another architecture). I am not opposed to working up the missing pieces if that's necessary, but before beginning that work, I wanted to check with the group and see if anyone had already started down this road and if so how far along have you gotten ? ARM support works fairly well (except for EABI support, which still has some bugs). Jonas ___ 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] Porting linux to pascal, would it be, possible ?
Hello Everyone, While I can't honestly say I share any enthusiasm for writing a OS in FreePascal, I do think there is merit in looking for projects of similar scope and interest that can demonstrate the power of the language and the tremendous tools that have been developed by this group over the past four years. I do think that if someone were to interested in testing their mettle for writing something like an OS, he or she might first take a crack at writing a few of the GNU tools in FP. Say for example the BusyBox suite. Once they had done that, there are a few more code foothills they could climb to build up enough additional undestanding and programming techniques others could then learn and then join them later on more ambitious OS projects. My current projects are to port the FP compiler to the OpenSolaris platform and to eventually write an Eclipse plug-in oe a Mozilla based XUL application (like Komodo) for FP. Ultimately, I am interested in exploring more of the ARM platform support in FP. Prince On Fri, Dec 5, 2008 at 9:58 AM, Gerard N/A [EMAIL PROTECTED]wrote: On Fri, Dec 5, 2008 at 1:18 PM, Ingemar Ragnemalm [EMAIL PROTECTED] wrote: This is an argument only after considering the time versus the goal. Is the goal worth the time? No, and that was exactly my point. Life is too short to spend it rewriting Linux in Pascal. g Another goal is to make a better OS. FPC programs use less memory and starts faster. That can be a good thing. Would it be significant? I'm not sure. Then maybe it would better to focus on something different from Linux. You are perfectly right in that we must choose our battles and spend our time on things that are worth the time. I don't rule out that this could be one. Porting Linux doesn't have to imply that every little program is ported. Not every little program, but only for the kernel + drivers + filesystems the task is daunting. Gerard. ___ 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] Re: Porting linux to pascal, would it be possible ?
Hello I don't mean to start a culture war here, but I think there is a bit of overstatement in this post that 'C' is somehow a better language for writing an OS in than say Pascal or OP or anything else. In point of fact, the only 'best' language for any processor is its own machine code which is always binary. And the first operating system software written was done so in the assembly language which is written to use mnemoics that when 'assembled' convert directly into the binary machine language on a one to one basis. Now EVERY compiled language, including C, must be processed from its syntactical representation into assembly language or machine code. In fact, if you download the GCC complier source code and read it, you'll see almost immediately that it actually a 'language' front-end connected to a 'assembler machine code' back end. When the 'C' language was designed at ATT it used 'assembler' like constructs and syntax because it's author wanted to stop writing programs in a language called BCPL.. So aside from a 'historical accident' that the first ATT OS ..UNIX.. was being written at the same time C was being developed, there is no other reason for any program, including an OS, to be written in C. To suggest that C is better is rather like suggesting that Spanish is a better language than English for writing a novel. That said, if someone wished to write a modern OS in FP, which has nearly every programming construct that 'C' has (ints, doubles, floats, bytes, and bits) and you were willing to put in the time to fine tune and modify the FP compiler, you could produce a OS in FP that would be every bit as effective and perform as well or better as one written in C. And as far as the processor running the OS couldn't tell what language the OS was written in. If anyone wants to convince themselves on this its simple, you'll find Ritchie (the creator of the C language) explained these points in the preface to his first book on C. There is also a brief mention of this in the Wikipedia article on the UNIX operating system. (see the article footnotes) Prince On Fri, Dec 5, 2008 at 6:59 PM, Guillermo Martínez Jiménez [EMAIL PROTECTED] wrote: Are you sure? Yes, I am. doesn't older MacOS's versions where written in Object Pascal? Yes, it does, but as I said I think it wasn't the better options. I think the problem here (again) is not the language, it's the critical mass of users of the language. Using C for Linux was a good bet, not because the language is good (Pascal is way better for me), but because C has a wider user base who can fix/add features. I disagree. C is better for write operating systems *by definition*: C was created to write UNIX, Pascal was created to learn good programming techniques. C is low/mid-level language, Pascal is high-level (and Object Pascal is even higher): OS are the lowest software level. I'm not saying it's impossible: here you have MacOS and Toro. I'm just saying that _I think_ it isn't the best option. Of course a better option is to write the kernel in C and Assembler and the utilities in Pascal and Object Pascal. Guillermo Ñuño Martínez ___ 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] Re: Porting linux to pascal, would it be possible ?
Here is a direct reference from the Wikipedia article I referenced in my prior post ... In 1973, Unix was rewritten in the C programming languagehttp://en.wikipedia.org/wiki/C_%28programming_language%29, contrary to the general notion at the time that something as complex as an operating system, which must deal with time-critical events, had to be written exclusively in assembly language.[4]http://en.wikipedia.org/wiki/UNIX#cite_note-Stallings-3The migration from assembly language http://en.wikipedia.org/wiki/Assembly_Language to the higher-level language http://en.wikipedia.org/wiki/High-level_programming_language C resulted in much more portablehttp://en.wikipedia.org/wiki/Software_quality#Portabilitysoftware, requiring only a relatively small amount of machine-dependent code to be replaced when porting Unix to other computing platformshttp://en.wikipedia.org/wiki/Platform_%28computing%29 . Prince On Fri, Dec 5, 2008 at 7:57 PM, Prince Riley [EMAIL PROTECTED] wrote: Hello I don't mean to start a culture war here, but I think there is a bit of overstatement in this post that 'C' is somehow a better language for writing an OS in than say Pascal or OP or anything else. In point of fact, the only 'best' language for any processor is its own machine code which is always binary. And the first operating system software written was done so in the assembly language which is written to use mnemoics that when 'assembled' convert directly into the binary machine language on a one to one basis. Now EVERY compiled language, including C, must be processed from its syntactical representation into assembly language or machine code. In fact, if you download the GCC complier source code and read it, you'll see almost immediately that it actually a 'language' front-end connected to a 'assembler machine code' back end. When the 'C' language was designed at ATT it used 'assembler' like constructs and syntax because it's author wanted to stop writing programs in a language called BCPL.. So aside from a 'historical accident' that the first ATT OS ..UNIX.. was being written at the same time C was being developed, there is no other reason for any program, including an OS, to be written in C. To suggest that C is better is rather like suggesting that Spanish is a better language than English for writing a novel. That said, if someone wished to write a modern OS in FP, which has nearly every programming construct that 'C' has (ints, doubles, floats, bytes, and bits) and you were willing to put in the time to fine tune and modify the FP compiler, you could produce a OS in FP that would be every bit as effective and perform as well or better as one written in C. And as far as the processor running the OS couldn't tell what language the OS was written in. If anyone wants to convince themselves on this its simple, you'll find Ritchie (the creator of the C language) explained these points in the preface to his first book on C. There is also a brief mention of this in the Wikipedia article on the UNIX operating system. (see the article footnotes) Prince On Fri, Dec 5, 2008 at 6:59 PM, Guillermo Martínez Jiménez [EMAIL PROTECTED] wrote: Are you sure? Yes, I am. doesn't older MacOS's versions where written in Object Pascal? Yes, it does, but as I said I think it wasn't the better options. I think the problem here (again) is not the language, it's the critical mass of users of the language. Using C for Linux was a good bet, not because the language is good (Pascal is way better for me), but because C has a wider user base who can fix/add features. I disagree. C is better for write operating systems *by definition*: C was created to write UNIX, Pascal was created to learn good programming techniques. C is low/mid-level language, Pascal is high-level (and Object Pascal is even higher): OS are the lowest software level. I'm not saying it's impossible: here you have MacOS and Toro. I'm just saying that _I think_ it isn't the best option. Of course a better option is to write the kernel in C and Assembler and the utilities in Pascal and Object Pascal. Guillermo Ñuño Martínez ___ 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] Re: Porting linux to pascal, would it be possible ?
Link to the article about the ATT UNIX OS and C http://en.wikipedia.org/wiki/UNIX On Fri, Dec 5, 2008 at 8:01 PM, Prince Riley [EMAIL PROTECTED] wrote: Here is a direct reference from the Wikipedia article I referenced in my prior post ... In 1973, Unix was rewritten in the C programming languagehttp://en.wikipedia.org/wiki/C_%28programming_language%29, contrary to the general notion at the time that something as complex as an operating system, which must deal with time-critical events, had to be written exclusively in assembly language.[4]http://en.wikipedia.org/wiki/UNIX#cite_note-Stallings-3The migration from assembly language http://en.wikipedia.org/wiki/Assembly_Language to the higher-level language http://en.wikipedia.org/wiki/High-level_programming_language C resulted in much more portablehttp://en.wikipedia.org/wiki/Software_quality#Portabilitysoftware, requiring only a relatively small amount of machine-dependent code to be replaced when porting Unix to other computing platformshttp://en.wikipedia.org/wiki/Platform_%28computing%29 . Prince On Fri, Dec 5, 2008 at 7:57 PM, Prince Riley [EMAIL PROTECTED]wrote: Hello I don't mean to start a culture war here, but I think there is a bit of overstatement in this post that 'C' is somehow a better language for writing an OS in than say Pascal or OP or anything else. In point of fact, the only 'best' language for any processor is its own machine code which is always binary. And the first operating system software written was done so in the assembly language which is written to use mnemoics that when 'assembled' convert directly into the binary machine language on a one to one basis. Now EVERY compiled language, including C, must be processed from its syntactical representation into assembly language or machine code. In fact, if you download the GCC complier source code and read it, you'll see almost immediately that it actually a 'language' front-end connected to a 'assembler machine code' back end. When the 'C' language was designed at ATT it used 'assembler' like constructs and syntax because it's author wanted to stop writing programs in a language called BCPL.. So aside from a 'historical accident' that the first ATT OS ..UNIX.. was being written at the same time C was being developed, there is no other reason for any program, including an OS, to be written in C. To suggest that C is better is rather like suggesting that Spanish is a better language than English for writing a novel. That said, if someone wished to write a modern OS in FP, which has nearly every programming construct that 'C' has (ints, doubles, floats, bytes, and bits) and you were willing to put in the time to fine tune and modify the FP compiler, you could produce a OS in FP that would be every bit as effective and perform as well or better as one written in C. And as far as the processor running the OS couldn't tell what language the OS was written in. If anyone wants to convince themselves on this its simple, you'll find Ritchie (the creator of the C language) explained these points in the preface to his first book on C. There is also a brief mention of this in the Wikipedia article on the UNIX operating system. (see the article footnotes) Prince On Fri, Dec 5, 2008 at 6:59 PM, Guillermo Martínez Jiménez [EMAIL PROTECTED] wrote: Are you sure? Yes, I am. doesn't older MacOS's versions where written in Object Pascal? Yes, it does, but as I said I think it wasn't the better options. I think the problem here (again) is not the language, it's the critical mass of users of the language. Using C for Linux was a good bet, not because the language is good (Pascal is way better for me), but because C has a wider user base who can fix/add features. I disagree. C is better for write operating systems *by definition*: C was created to write UNIX, Pascal was created to learn good programming techniques. C is low/mid-level language, Pascal is high-level (and Object Pascal is even higher): OS are the lowest software level. I'm not saying it's impossible: here you have MacOS and Toro. I'm just saying that _I think_ it isn't the best option. Of course a better option is to write the kernel in C and Assembler and the utilities in Pascal and Object Pascal. Guillermo Ñuño Martínez ___ 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
