[fpc-pascal] Re: Debugger support for FP (issues with libgdb.a)
Jonas Maebe wrote: > > On 04 Jan 2009, at 16:51, Andrea wrote: > >> My gdb is version 6.8, on your link I can only find 6.2.1 >> Will that be a problem when it runs? > > No: libgdb.a basically contains a complete gdb implementation in that > library, and the IDE will use that. It's not an interface to your > system-installed gdb > > Maybe: that older gdb (6.2.1) may not fully support your system. > Ok, I have finally built fpc with gdb support as suggested by you. Now, whenever I try to use the debugger (e.g. F8) fp crashes "Program generated a signal 11. Save your sources and restart the IDE" and "The IDE generated an internal error and will now be closed" Do you have any more ideas? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Suggestions for fpspreadsheet
Hello, I got some time and I decided to improve fpspreadsheet: http://wiki.lazarus.freepascal.org/FPSpreadsheet I wrote a OLE document generator, so now it is possible to generate Excel 5 spreasheets in any platforms (actually some lines of code are missing for big endian systems). And it supports numbers, text and formulas, as well as multiple worksheets in the same file. Excel 2 support is also complete. I have some more time, but I am not entirely sure what would really add value to the library, so I thougth I would ask possible users what they really need (I already have all the functionality I need). Some ideas I had are: * Add support to also read Excel 5 files * Add write support to other formats * More advanced formulas * Make charts (maybe too hard?) I went for Excel 5 because it's supported by nearly all spreadsheet software out there and has lot's of features. I am not saying I will implement any of this in a short time, just asking for suggestions =) thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 32 to 64 bits
In our previous episode, J?rgen Hestermann said: > Because of these weak definition of types (which is very confusing IMO) > I often use a check in the implementation part of units if I have to > reliy on sizes: > > if sizeof(Word)<>2then Halt(9000); > if sizeof(DWord)<>4 then Halt(9001); > if sizeof(LongInt)<>4 then Halt(9002); > Then I am at least warned in case my presumption are no longer valid. The only one variable to my knowledge are pointer, integer, ptrint and ptruint. Integer with compiler mode, and the others with 32/64bit ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 32 to 64 bits
"The cardinal type is currently always mapped to the longword type. The definition of the cardinal and integer types may change from one architecture to another and from one compiler mode to another." "Always" or "may change" ? :-? Current always, but may change ? Perfect English. Now so, but not guaranteed to last forever. This pegging is mostly for Delphi compatibility (and then specially the Windows headers). If you don't have that, it doesn't matter so much. Because of these weak definition of types (which is very confusing IMO) I often use a check in the implementation part of units if I have to reliy on sizes: if sizeof(Word)<>2then Halt(9000); if sizeof(DWord)<>4 then Halt(9001); if sizeof(LongInt)<>4 then Halt(9002); etc. Then I am at least warned in case my presumption are no longer valid. Jürgen Hestermann. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] 32 to 64 bits
In our previous episode, JoshyFun said: > MvdV> Afaik most is in the docs, but some short pointers: > > Sure :) but as I said not found :( and the information I had found > does not describe the 32/64 bits differences. First, if you don't know the 64-bit memory model discussions have a look here: http://www.stack.nl/~marcov/buildfaq/buildfaq.html#x1-660005.1 which is a summary (in case you want more background) of http://queue.acm.org/detail.cfm?id=1165766 > MvdV> 32 64 > MvdV>unsigned 16 bits WORD?WORD? > MvdV>signed 16 bitssee table docs (smallint/shortint) > MvdV>unsigned 32 bits DWORD? DWORD? > MvdV>signed 32 bitscompiler mode dependant 16/32 > > Hmmm... I was asking only for 32/64 differences (my targetted systems) > but 16 bits is interesting also. For 32/64 this should be the LongInt > do not ? No. There are multiple choice, and the normal integer type usually stays 32-bit. Only the type equivalent to pointer scales. (in our case, in the C case, there were even more possibilities) > MvdV>Native "integer" "native" is ambiguous. > MvdV>Signed integer as big > MvdV> as pointer PtrInt Ptrint > > PtrInt does not have too much sense :-? There are not negative memory > addresses. Pascal calculates by default in signed arithmatic. > MvdV> "native" is confusing since it can taken in many ways. Native as in most > MvdV> performance? Register size? Addressing size? Addressing size + segment ? > MvdV> (size_t, ssize_t). > > Well, I understand "native" as the less efforce variable to be > loaded/written to memory, in 32/64 bits usually it is the register > size. Not necessarily. There are processors that need two memory cycles to fetch a full word. Moreover, using 64-bit everywhere blows up your data size unnecessarily (you are constantly shoveling those 32 generally empty zeros in every word around) > And "integer" ? Is it always 32 bits ? Oh! I found the table in the > documentation finally :) Integer is 16/32/64 bits (the thing I call it > "native"). The integer _type_ is 16/32 only, depending on mode. 16-bits in TP modes, 32-bit in Delphi (-like) modes. Note that in general all whole numbers types (except for comp in some cases) are also classified as the "integer" types family. > "The cardinal type is currently always mapped to the longword type. > The definition of the cardinal and integer types may change from one > architecture to another and from one compiler mode to another." > > "Always" or "may change" ? :-? Current always, but may change ? Perfect English. Now so, but not guaranteed to last forever. This pegging is mostly for Delphi compatibility (and then specially the Windows headers). If you don't have that, it doesn't matter so much. The most important part to remember is to always use ptrint/ptruint for pointers, but preferably also for differences of pointers. (e..g when walking memory). There might be breaking changes for future freak platforms, but the fact that pointer size changes is the main issue of 64-bit systems now. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] 32 to 64 bits
Hello Marco, Saturday, January 10, 2009, 12:36:37 AM, you wrote: MvdV> Afaik most is in the docs, but some short pointers: Sure :) but as I said not found :( and the information I had found does not describe the 32/64 bits differences. MvdV> 32 64 MvdV>unsigned 16 bits WORD?WORD? MvdV>signed 16 bitssee table docs (smallint/shortint) MvdV>unsigned 32 bits DWORD? DWORD? MvdV>signed 32 bitscompiler mode dependant 16/32 Hmmm... I was asking only for 32/64 differences (my targetted systems) but 16 bits is interesting also. For 32/64 this should be the LongInt do not ? MvdV>unsigned 64 bits QWORD? QWORD? MvdV>signed 64 bitsInt64? Int64? MvdV>Native "integer" "native" is ambiguous. MvdV>Signed integer as big MvdV> as pointer PtrInt Ptrint PtrInt does not have too much sense :-? There are not negative memory addresses. MvdV>Unsigned integer as big MvdV> as pointer PtruInt Ptruint MvdV> "native" is confusing since it can taken in many ways. Native as in most MvdV> performance? Register size? Addressing size? Addressing size + segment ? MvdV> (size_t, ssize_t). Well, I understand "native" as the less efforce variable to be loaded/written to memory, in 32/64 bits usually it is the register size. >> Where LongInt fits ? Bits dependent or not ? MvdV> always 32-bit signed. And "integer" ? Is it always 32 bits ? Oh! I found the table in the documentation finally :) Integer is 16/32/64 bits (the thing I call it "native"). But there is something that I do not understand in this table. The doc says: "The cardinal type is currently always mapped to the longword type. The definition of the cardinal and integer types may change from one architecture to another and from one compiler mode to another." "Always" or "may change" ? :-? MvdV> The docs are the primary source, the language ref should have a table MvdV> somewhere near the start. I sometimes use it, because I always forget which MvdV> is 8-bit signed and which is 16-bit signed. (which is why I never use them MvdV> and always use ctypes) Yes, ctypes could be my solution too. Thank you for your help. -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for .. in loop implementation [off topic - goto ?]
Vinzent Höfler wrote: Jürgen Hestermann wrote: Mantra: First make it work, then make it fast. In general that's true from the programmer's viewpoint. But this does not apply to adding language details because there is no 'first make it work'. Why obscure important implementation details if the only benefit is saving some writing? I won't judge on the "only save some writing" here, but generally it *does* apply to language features: If a particular language feature helps you writing correct code faster (by supporting you to make it work instead of relying on your abilities to use the debugger), then it does apply. The real question is if the (or any other) proposal is "good enough" to do just that, or if it's really some syntactic sweetener (not even sugar, sugar at least contains energy). That's something to discuss. Let me take a rather extreme point of view: After all, all those for-, while-, and repeat-until-loops are only there to save you from some typing work[0], because Pascal already has a perfectly good loop-construct with which you can do all that: goto. Would you agree here? Probably not. 1) "goto" alone (labels assumed) can not replace any of the loop constructs. It must be paired with "if" (or anything to check conditions) 2) Otherwise you are of course right. Following this logic however most programming languages (including pascal and assembler) become redundant. They have far to many instructions to archive the same thing. Look at languages like "whitespace" or "brainfuck" and you will see that a language which is kept simple (by the meaning of "no unneeded instructions" does not need more than 6 to 8 instructions. SCNR. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
