[fpc-pascal] No Hello World after updating Xcode to 2.1
I've just installed Xcode 2.1 and can no longer compile FPC using 2.0.0. For good measure, I re-installed FPC 2.0.0 and the Xcode Integration Kit, including the Universal Interfaces. The latter acted oddly with a crashing program which tried to open up a dialog box, until I mounted the Universal Interfaces disk image first. (This sounds familiar to me from an earlier upgrade but I can't remember what to do to fix it, and the lists archives don't seem to want me to see them.) In any event, I can't even compile a tool. Here's the result of trying. What's up? Lance Native Build of Target "pascaltooldumpmeUnits" using Build Configuration "Development" PhaseScriptExecution /Users/jerrybauck/pascaltooldumpme/build/ pascaltooldumpme.build/Development/pascaltooldumpmeUnits.build/Script- b8bd1d4d.sh mkdir build cd /Users/jerrybauck/pascaltooldumpme setenv ACTION build setenv APPLE_INTERNAL_DEVELOPER_DIR /AppleInternal/Developer setenv APPLE_INTERNAL_DIR /AppleInternal setenv APPLE_INTERNAL_DOCUMENTATION_DIR /AppleInternal/ Documentation setenv APPLE_INTERNAL_LIBRARY_DIR /AppleInternal/Library setenv APPLE_INTERNAL_TOOLS /AppleInternal/Developer/Tools setenv ARCHS ppc setenv BUILD_COMPONENTS "headers build" setenv BUILD_DIR /Users/jerrybauck/pascaltooldumpme/build setenv BUILD_ROOT /Users/jerrybauck/pascaltooldumpme/build setenv BUILD_STYLE Development setenv BUILD_VARIANTS normal setenv BUILT_PRODUCTS_DIR /Users/jerrybauck/pascaltooldumpme/ build/Development setenv CACHE_ROOT /Library/Caches/com.apple.Xcode.501 setenv CCHROOT /Library/Caches/com.apple.Xcode.501 setenv CHMOD /bin/chmod setenv CHOWN /usr/sbin/chown setenv CLASS_FILE_DIR /Users/jerrybauck/pascaltooldumpme/build/ pascaltooldumpme.build/Development/pascaltooldumpmeUnits.build/ JavaClasses setenv CLEAN_PRECOMPS YES setenv CLONE_HEADERS NO setenv CONFIGURATION Development setenv CONFIGURATION_BUILD_DIR /Users/jerrybauck/ pascaltooldumpme/build/Development setenv CONFIGURATION_TEMP_DIR /Users/jerrybauck/pascaltooldumpme/ build/pascaltooldumpme.build/Development setenv CONTENTS_FOLDER_PATH setenv COPY_PHASE_STRIP NO setenv COPY_RESOURCES_FROM_STATIC_FRAMEWORKS YES setenv CP /bin/cp setenv CURRENT_PROJECT_VERSION setenv CodeWarrior "/Applications/Metrowerks CodeWarrior 8.0/ Metrowerks CodeWarrior" setenv DEBUGGING_SYMBOLS YES setenv DEPLOYMENT_LOCATION NO setenv DERIVED_FILES_DIR /Users/jerrybauck/pascaltooldumpme/ build/pascaltooldumpme.build/Development/pascaltooldumpmeUnits.build/ DerivedSources setenv DERIVED_FILE_DIR /Users/jerrybauck/pascaltooldumpme/build/ pascaltooldumpme.build/Development/pascaltooldumpmeUnits.build/ DerivedSources setenv DERIVED_PATHS setenv DERIVED_SOURCES_DIR /Users/jerrybauck/pascaltooldumpme/ build/pascaltooldumpme.build/Development/pascaltooldumpmeUnits.build/ DerivedSources setenv DEVELOPMENT_LANGUAGE English setenv DOCUMENTATION_FOLDER_PATH setenv DSTROOT /tmp/pascaltooldumpme.dst setenv DYLIB_COMPATIBILITY_VERSION setenv DYLIB_CURRENT_VERSION setenv DYLIB_INSTALL_NAME_BASE setenv ENABLE_HEADER_DEPENDENCIES YES setenv EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES "*.nib *.lproj *.framework *.gch *.xcode (*) CVS .svn" setenv EXECUTABLES_FOLDER_PATH setenv EXECUTABLE_EXTENSION setenv EXECUTABLE_NAME pascaltooldumpme setenv EXECUTABLE_PATH pascaltooldumpme setenv EXECUTABLE_PREFIX setenv EXECUTABLE_SUFFIX setenv EXECUTABLE_VARIANT_SUFFIX setenv FRAMEWORKS_FOLDER_PATH setenv FRAMEWORK_FLAG_PREFIX -framework setenv FRAMEWORK_SEARCH_PATHS /Users/jerrybauck/pascaltooldumpme/ build/Development setenv FRAMEWORK_VERSION A setenv FULL_PRODUCT_NAME pascaltooldumpme setenv GCC_AUTO_PCH_HEADER_c setenv GCC_AUTO_PCH_HEADER_c++ setenv GCC_AUTO_PCH_HEADER_objective-c setenv GCC_AUTO_PCH_HEADER_objective-c++ setenv GCC_DYNAMIC_NO_PIC NO setenv GCC_ENABLE_AUTO_PCH NO setenv GCC_ENABLE_FIX_AND_CONTINUE YES setenv GCC_GENERATE_DEBUGGING_SYMBOLS YES setenv GCC_OPTIMIZATION_LEVEL 0 setenv GCC_PFE_FILE_C_DIALECTS "c objective-c c++ objective-c++" setenv GCC_PRECOMPILE_PREFIX_HEADER setenv GCC_PREFIX_HEADER setenv GCC_SYMBOLS_PRIVATE_EXTERN YES setenv GCC_TREAT_WARNINGS_AS_ERRORS NO setenv GCC_USE_GCC3_PFE_SUPPORT setenv GCC_VERSION setenv GENERATE_PKGINFO_FILE NO setenv GENERATE_PROFILING_CODE NO setenv GLOBAL_CFLAGS setenv GROUP staff setenv HEADERMAP_INCLUDES_PROJECT_HEADERS YES setenv HEADER_SEARCH_PATHS /Users/jerrybauck/pascaltooldumpme/ build/Development/include setenv INCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES setenv INFOPLIST_FILE setenv INFOPLIST_PATH setenv INFOSTRINGS_PATH setenv INIT_ROUTINE setenv INPUT_FILE_BASE EmptyPlaceHolderUnit seten
Re: [fpc-pascal] No Hello World after updating Xcode to 2.1
Lance Boyle wrote: I've just installed Xcode 2.1 and can no longer compile FPC using 2.0.0. For good measure, I re-installed FPC 2.0.0 and the Xcode Integration Kit, including the Universal Interfaces. The latter acted oddly with a crashing program which tried to open up a dialog box, until I mounted the Universal Interfaces disk image first. (This sounds familiar to me from an earlier upgrade but I can't remember what to do to fix it, and the lists archives don't seem to want me to see them.) In any event, I can't even compile a tool. Here's the result of trying. What's up? Lance Native Build of Target "pascaltooldumpmeUnits" using Build Configuration "Development" setenv ZERO_LINK YES /bin/sh -c "rm -f build/$(PRODUCT_NAME)" /bin/sh: line 1: PRODUCT_NAME: command not found rm: build/: is a directory I've also run into this problem. Here's how I fixed it although it may not be the correct answer. open xcode and then open /Library/Application Support/Apple/Developer Tools/Project Templates/Pascal/Pascal Carbon Application/PascalCarbonApp.xcodeproj In the treeview Groups & Files, select Targets and then <> then in the "Action" combobox choose "Get Info" Under the "Rules" tab change all vars that you can see from $(SOME_VAR_NAME) to $SOME_VAR_NAME also I had to change the output directories some: Here's the lines I had to change for the output path mkdir -p build/$BUILD_STYLE/$PRODUCT_NAME.app/Contents/MacOS mv -f build/$PROJECT_NAME.build/$PRODUCT_NAME build/$BUILD_STYLE/$PRODUCT_NAME And for my "with output files" section: build/$PROJECT_NAME.build/$INPUT_FILE_BASE.o build/$PROJECT_NAME.app/Contents/MacOS/$PRODUCT_NAME and that's it. You'll have to make the same changes to the "Pascal Tool" and "Pascal CGI" directories ProjectTemplate Files (*.xcodeproj) Andrew PS again there may be a better way to fix this but this is how I did it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Porter Stemming for FPC 2.0
It's great that 2.0 is out! Unfortunately it seems to break some code I used for Porter Stemming because the code sometimes reads data from a pchar at negative indexes. Reportedly this works fine in Delphi 5 and I don't seem to have trouble with Delphi 7 but it generates RTEs using fpc 2.0. (If this is a FAQ, forgive me, I've been away from Free Pascal for a while...) So, here is a file containing my patched code and a test program that seems to run fine: http://www.alanmead.org/downloads/fpc2_PorterStem.zip The homepage for this algorithm, which may offer my fix someday, is here: http://www.tartarus.org/~martin/PorterStemmer/ -Alan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Extending FPDoc
Hi there, For Lazarus I have made a tool called LazDoc that attempts to integrate a documentation editing tool with the IDE. Depending on the position of the cursor on the source editor, the appropriate documentation tag is searched and then selected in the editor. Anyway, while I was working on the tool, I realized that some additional tags would be very usefull. todo: Here you can enter todo items in your code. Later after documentation generation, an additional summary page is generated with an overview of the todo items. notes: Here you can enter notes in your source. They coud be remarks for instance for other developers, or just plain reminders for yourself. I don't know how others feel about this, but it's sure I cannot do it myself. Perhaps someone can help me here?? Just an explanation on how to handle and where to look would also be nice. Darius Blaszijk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Extending FPDoc
Hi there, For Lazarus I have made a tool called LazDoc that attempts to integrate a documentation editing tool with the IDE. Depending on the position of the cursor on the source editor, the appropriate documentation tag is searched and then selected in the editor. Anyway, while I was working on the tool, I realized that some additional tags would be very usefull. todo: Here you can enter todo items in your code. Later after documentation generation, an additional summary page is generated with an overview of the todo items. notes: Here you can enter notes in your source. They coud be remarks for instance for other developers, or just plain reminders for yourself. I don't know how others feel about this, but it's sure I cannot do it myself. Perhaps someone can help me here?? Just an explanation on how to handle and where to look would also be nice. Darius Blaszijk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
[EMAIL PROTECTED] schrieb: > Hi there, > > For Lazarus I have made a tool called LazDoc that attempts to integrate a > documentation editing tool with the IDE. Depending on the position of the > cursor on the source editor, the appropriate documentation tag is searched > and then selected in the editor. > Anyway, while I was working on the tool, I realized that some additional > tags would be very usefull. > > todo: > Here you can enter todo items in your code. Later after documentation > generation, an additional summary page is generated with an overview of > the todo items. > > notes: > Here you can enter notes in your source. They coud be remarks for instance > for other developers, or just plain reminders for yourself. > > I don't know how others feel about this, but it's sure I cannot do it > myself. Perhaps someone can help me here?? Just an explanation on how to > handle and where to look would also be nice. I think I can easily add this. I think it would be sufficient to 'just' support it, without usage within the doc writers? - Sebastian ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
On Fri, 16 Sep 2005 [EMAIL PROTECTED] wrote: > Hi there, > > For Lazarus I have made a tool called LazDoc that attempts to integrate a > documentation editing tool with the IDE. Depending on the position of the > cursor on the source editor, the appropriate documentation tag is searched > and then selected in the editor. > Anyway, while I was working on the tool, I realized that some additional > tags would be very usefull. > > todo: > Here you can enter todo items in your code. Later after documentation > generation, an additional summary page is generated with an overview of > the todo items. > > notes: > Here you can enter notes in your source. They coud be remarks for instance > for other developers, or just plain reminders for yourself. > > I don't know how others feel about this, but it's sure I cannot do it > myself. Perhaps someone can help me here?? Just an explanation on how to > handle and where to look would also be nice. I'd rather you keep these todo separate. It'll slow down parsing (which is already horribly slow) and I see no added value. If you must really use it inside the file, just use special formatting of comments: In lazarus, you could even store the TODO in a separate file. If I'm correct, Lazarus has already a TODO system. What concerns notes, there is already a node. It is meant for 'Extra' text. You can use that inside the package or module node. At the level of the package, you can nest topics: Notes For this Package Remember to do this more note text At the level of a module, you can't nest topics, but there you could use a description list: Remember to do this Note 1more note text it's easy to parse with the XML engine. You should be able to get a long way with this without needing to change anything in FPDoc. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
Michael Van Canneyt schrieb: > > I'd rather you keep these todo separate. It'll slow down parsing > (which is already horribly slow) Huh? Really? A small reminder: FPDoc can support different backends, the XML storage is just the only one currently implemented. We can talk about this anytime... - Sebastian ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
Sebastian Günther wrote: Michael Van Canneyt schrieb: I'd rather you keep these todo separate. It'll slow down parsing (which is already horribly slow) Huh? Really? A small reminder: FPDoc can support different backends, the XML storage is just the only one currently implemented. We can talk about this anytime... I would prefer to profile the xml reader and see if we can improve it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
On Fri, 16 Sep 2005, Sebastian Günther wrote: > Michael Van Canneyt schrieb: > > > > I'd rather you keep these todo separate. It'll slow down parsing > > (which is already horribly slow) > > Huh? Really? I didn't mean the FPC implementation specifically, but XML in general is slow to parse. > A small reminder: FPDoc can support different backends, the XML storage > is just the only one currently implemented. We can talk about this > anytime... I know, but this would require a major rewrite of FPDoc. The TDOMElement is deeply rooted in the structure. And you need the XML anyway for transforming the pseudo-html, so I see no gain in having another backend. And anyway, I don't see the need for the proposed changes, see my other mail. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
Florian Klämpfl schrieb: > > I would prefer to profile the xml reader and see if we can improve it. Yes, but I don't see this mutually exclusive :) - Sebastian ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
Michael Van Canneyt schrieb: > > I didn't mean the FPC implementation specifically, but XML in general > is slow to parse. Yes > I know, but this would require a major rewrite of FPDoc. > The TDOMElement is deeply rooted in the structure. > And you need the XML anyway for transforming the pseudo-html, so I see > no gain in having another backend. This is not quite true. FPDoc can work with XML fragments, which you can store in a database. Looking up elements would be much faster then. > And anyway, I don't see the need for the proposed changes, see my other > mail. yes... - Sebastian ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending FPDoc
On Fri, 16 Sep 2005, Sebastian Günther wrote: > Michael Van Canneyt schrieb: > > > > I didn't mean the FPC implementation specifically, but XML in general > > is slow to parse. > > Yes > > > > I know, but this would require a major rewrite of FPDoc. > > The TDOMElement is deeply rooted in the structure. > > And you need the XML anyway for transforming the pseudo-html, so I see > > no gain in having another backend. > > This is not quite true. FPDoc can work with XML fragments, which you can > store in a database. Looking up elements would be much faster then. Yes, I know. I even have a database model ready for it... My plan was to have the descriptions in the database, and produce a correct XML file which is then fed to fpdoc. I'm not yet convinced that having a DB backend to FPDoc will be so trivial, but if you think it's easy to do: I'm all for it :-) Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porter Stemming for FPC 2.0
> It's great that 2.0 is out! Unfortunately it seems to break some > code I used for Porter Stemming because the code sometimes reads data > from a pchar at negative indexes. Reportedly this works fine in > Delphi 5 and I don't seem to have trouble with Delphi 7 but it > generates RTEs using fpc 2.0. (If this is a FAQ, forgive me, I've > been away from Free Pascal for a while...) Reading PChars at negative indexes? Buffer underrun in other words... This is absolutely not a good thing. If FPC is preventing buffer under and overrruns, then it is actually right, for once, and Delphi is wrong, wrong, wrong! A question... how do you know the memory at the negative index is valid? Various factors (memory management, record alignement and poor consistency in longterm projects) can alter what you are reading drastically. Even if you *believe* you know what it is. This is the kind of horror story I see sometimes in Legacy code that makes me wonder how the darn thing _ever_ worked all these years. You ask the guy maintaining it and he goes all mistical - "It just works, but no one remembers why.. we dare not change it because last time somebody did anything to it the entive project A/V'd every 30 seconds and died in a puff of green smoke." M M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porter Stemming for FPC 2.0
This is very interesting. I've always wondered if anyone did this on purpose, and I've always wondered what the big deal is with just adding array range checking to C. A company with tons of internal software development, and whose existence is made miserable by buffer under/over flows, could surely pull this off. For example, Microsoft could change the compilers that they use internally, and any programmers found to be depending on the persistence of memory "next to" an array would be taken out and shot. I'm sure someone will respond, telling me why this would be a bad idea or impossible, but that's my two cents worth. Lance On Sep 16, 2005, at 4:55 PM, memsom wrote: It's great that 2.0 is out! Unfortunately it seems to break some code I used for Porter Stemming because the code sometimes reads data from a pchar at negative indexes. Reportedly this works fine in Delphi 5 and I don't seem to have trouble with Delphi 7 but it generates RTEs using fpc 2.0. (If this is a FAQ, forgive me, I've been away from Free Pascal for a while...) Reading PChars at negative indexes? Buffer underrun in other words... This is absolutely not a good thing. If FPC is preventing buffer under and overrruns, then it is actually right, for once, and Delphi is wrong, wrong, wrong! A question... how do you know the memory at the negative index is valid? Various factors (memory management, record alignement and poor consistency in longterm projects) can alter what you are reading drastically. Even if you *believe* you know what it is. This is the kind of horror story I see sometimes in Legacy code that makes me wonder how the darn thing _ever_ worked all these years. You ask the guy maintaining it and he goes all mistical - "It just works, but no one remembers why.. we dare not change it because last time somebody did anything to it the entive project A/V'd every 30 seconds and died in a puff of green smoke." M M This is very interesting. I've always wondered if anyone did this on purpose, and I've always wondered what the big deal is with just adding array range checking to C. A company with tons of internal software development, and whose existence is made miserable by buffer under/over flows, could surely pull this off. And surely it wouldn't break _that_ much code. For example, Microsoft could change the compilers that they use internally, and any programmers found to be depending on the persistence of memory "next to" an array would be taken out and shot. I'm sure someone will respond, telling me why this would be a bad idea or impossible, but that's my two cents worth. Lance ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
