Re: [fpc-devel] (no subject)
On 27/04/2019 23:17, Григорий Параскевов via fpc-devel wrote: command line tools are already installed, use "Software Update" to install updates", но при очередной попытке установить fpc-3.0.4.intel.macosx выходит сообщение "you have to install Xcode and its command line tools before installing this package. Помогите, не знаю что делать. Try executing "xcode-select --install" in a terminal window. If that does not help, which version of macOS and Xcode are you using? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
Здравствуйте! Я не могу установить Лазарю на свой Мак. После того, как скачиваю fpc-3.0.4.intel.macosx и в терминал ввожу xcode-select ---install, пишет " command line tools are already installed, use "Software Update" to install updates", но при очередной попытке установить fpc-3.0.4.intel.macosx выходит сообщение "you have to install Xcode and its command line tools before installing this package. Помогите, не знаю что делать. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
DIFF attached for comment and review. Provides the following features / difference: 1) Switched operation of cpuinfo.pas - there is still a SET containing the ct_ constants, but that now indexes an array of structures rather than a collection of arrays. The array contains the info from the old arrays, PLUS FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each. NOTE: Switched for both ARM and AVR. AVR changes will compile the cross compiler, but choke while building the RTL (complaining about a function being too complex). However, the SVN and daily build exhibit the same behaviour - so I do not believe I have broken the AVR any further than it was broken. 2) Added LM3FURY controller unit file - this will be built up into a base unit file for all the Fury class Stellaris controllers. 3) I intend to leave the "Stellaris" controller class with the intention that those that don't want a full set of system defines can use this class and will receive nothing more than the bare minimum to boot a chip into PASCALMAIN. The Flash and SRAM sizes will be set very large - so caveat emptor to the user if, as they will need to ensure the programs do not require more resources than their chip require. 4) t_embed.pas was changed. The case() statement is still in there, but all the cases fall down to the same code - which uses the cpuinfo.pas memory definitions to create the linker file. 5) put a test in t_embed.pas - if we are only compiling to assembly, then we skip the Internal Error on not having a link definition. 6) option.pas, globals.pas, ncgutil.pas and pmodules.pas were modified to accommodate the addition of the structure. 7) IF controllerunitstr is empty - then no added file is included in the build (again, to support a "base" controller type - with no defines what so ever - power user option) NOTE: The Makefile changes were picked up by svn diff - not sure why they changed so much, my incantation of fpcmake must be different than the original sources code NOTE: The AVR link script generation has not been changed to accommodate the additional information - the original link script did not set memory sizes to match the processor. JohnIndex: rtl/embedded/Makefile.fpc === --- rtl/embedded/Makefile.fpc (revision 18278) +++ rtl/embedded/Makefile.fpc (working copy) @@ -48,7 +48,7 @@ SYSINIT_UNITS= ifeq ($(ARCH),arm) -CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103 +CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103 lm3fury endif ifeq ($(ARCH),avr) Index: rtl/embedded/Makefile === --- rtl/embedded/Makefile (revision 18278) +++ rtl/embedded/Makefile (working copy) @@ -1,8 +1,8 @@ # -# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/08/11] +# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/04/23] # default: all -MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc i386-wince i386-embedded i386-symbian i386-nativent i386-iphonesim m68k-linux m68k-freebsd m68k-netbsd m68k-amiga m68k-atari m68k-openbsd m68k-palmos m68k-embedded powerpc-linux powerpc-netbsd powerpc-amiga powerpc-macos powerpc-darwin powerpc-morphos powerpc-embedded powerpc-wii sparc-linux sparc-netbsd sparc-solaris sparc-embedded x86_64-linux x86_64-freebsd x86_64-solaris x86_64-darwin x86_64-win64 x86_64-embedded arm-linux arm-palmos arm-darwin arm-wince arm-gba arm-nds arm-embedded arm-symbian powerpc64-linux powerpc64-darwin powerpc64-embedded avr-embedded armeb-linux armeb-embedded mipsel-linux +MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc i386-wince i386-embedded i386-symbian m68k-linux m68k-freebsd m68k-netbsd m68k-amiga m68k-atari m68k-openbsd m68k-palmos m68k-embedded powerpc-linux powerpc-netbsd powerpc-amiga powerpc-macos powerpc-darwin powerpc-morphos powerpc-embedded sparc-linux sparc-netbsd sparc-solaris sparc-embedded x86_64-linux x86_64-freebsd x86_64-solaris x86_64-darwin x86_64-win64 x86_64-embedded arm-linux arm-palmos arm-darwin arm-wince arm-gba arm-nds arm-embedded arm-symbian powerpc64-linux powerpc64-darwin powerpc64-embedded avr-embedded armeb-linux armeb-embedded mipsel-linux BSDs = freebsd netbsd openbsd darwin UNIXs = linux $(BSDs) solaris qnx haiku LIMIT83fs = go32v2 os2 emx watcom @@ -189,11 +189,7 @@ TARGETSUFFIX=$(OS_TARGET) SOURCESUFFIX=$(OS_SOURCE) else -ifneq ($(findstring $(OS_TARGET),$(LIMIT83fs)),) -TARGETSUFFIX=$(OS_TARGET) -else TARGETSUFFIX=$(FULL_TARGET) -endif SOURCESUFFIX=$(FULL_SOURCE) endif ifn
[fpc-devel] (no subject)
-- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
> Why do you need a plug in mechanism? You've the sources? When you > have the sources, 90 per cent of the use of a plugin are gone. >> Well, we'd call that non-intrusive change. ;) >> >> You'd just need to compile the plug-in, and not a changed compiler >> (which then may even apply recursively). This rules out a whole class >> of possible error sources. >> >> So it's probably the last 10% that counts. ;) Which, BTW, fits nicely >> into another 90/10 rule: 90% of all errors are coming from only 10% of >> the code. ;) Absolutely agree here, plug-ins are most useful even in open source.. compilers plug-in system right now is the FPC.CFG file. Some people don't see this as a plug-in but it is. Imagine if you had to recompile the fpc compiler each time you wanted to change the search paths. That being said, a monolithic single exe compiler is okay - I think plugins are more useful in larger programs with lots of component stuff, like web sites and gui programs, and certain console programs that grow large enough. I have many rants about this on PasWiki, as some of you may have come across - why I personally find that plug in systems are still important even if you have the source. Biggest advantage of plug-in: If someone writes shitty code, uninstall the plug-in. People write shitty code, even the best of programmers. Easier to debug shitty code when it is inside a plugin and not in the main executable. There are issues with plug in systems and they aren't the holy grail, such as DLL hell or reliances or speed issues (loading plugins for compiler could be slow, but in GUI apps or certain console apps there is no need to worry). I find also that plug in systems encourage good engineering. If a program has a good plug-in API then the API was engineered well - algorithms weren't just slapped in units (or on a form) and recompiled. Someone had to think hard about the engineering and actually design the program it to be extensible. It's not a solution for quicky RAD apps, it's a long term thing for larger projects. An operating system is a plug-in system. Elf's and Exe's are plugins. No one thinks of them like plug-ins, but they are. HTML files are plugins too. Imagine if we had to recompile the operating system each time we wanted to install a new program? Hey, the kernel is open source - just add more code to the bottom of the kernel.c file and add your program... no way, thanks. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Michael Van Canneyt wrote: On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is FPC able to compile Kylix forms (*.xfm) now? Yes, using an external resource compiler. It will embed .xfm, .dfm and .res files. But you'll still need an .rc -> .res compiler for icons, bitmaps etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is it automated in CrossFCP? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote: > Marco van de Voort wrote: > > > > Interesting switch in FPC 2.1.1: > > > > > > -Skload fpcylix unit > > > > > > what is it for? > > > > > > > > > > Afaik it implicitely USES the fpcylix unit that contains some identifiers > > for Kylix compat that we _really_ didn't want in the normal > > system/sysutils > > unit. > > > > ___ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-devel > > > > > > > > > Is FPC able to compile Kylix forms (*.xfm) now? Yes, using an external resource compiler. It will embed .xfm, .dfm and .res files. But you'll still need an .rc -> .res compiler for icons, bitmaps etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
> Marco van de Voort wrote: > > > >Afaik it implicitely USES the fpcylix unit that contains some identifiers > >for Kylix compat that we _really_ didn't want in the normal system/sysutils > >unit. > > > Is FPC able to compile Kylix forms (*.xfm) now? Forms are something of a higher level than FPC. They are compiled by an (external) resourcecompiler and then stored as a resource in a file. However for CrossFPC's sake, resourcehandling has been made more compatible, but I assume one still needs a resourcecompiler for this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is FPC able to compile Kylix forms (*.xfm) now? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Tomas Hajny wrote: > Marco van de Voort wrote: > >>>Interesting switch in FPC 2.1.1: >>> >>> -Skload fpcylix unit >>> >>>what is it for? >> >>Afaik it implicitely USES the fpcylix unit that contains some identifiers >>for Kylix compat that we _really_ didn't want in the normal >>system/sysutils >>unit. > > > BTW, looking at the current implementation - shouldn't GetModuleName be > changed to return name part of ParamStr (0) (without path and extension), > and GetModuleFileName the complete ParamStr (0)? No, the situation is more complex, that's not implemented yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: >> Interesting switch in FPC 2.1.1: >> >>-Skload fpcylix unit >> >> what is it for? > > Afaik it implicitely USES the fpcylix unit that contains some identifiers > for Kylix compat that we _really_ didn't want in the normal > system/sysutils > unit. BTW, looking at the current implementation - shouldn't GetModuleName be changed to return name part of ParamStr (0) (without path and extension), and GetModuleFileName the complete ParamStr (0)? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
[EMAIL PROTECTED] wrote: Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. where can i find it ? http://svn.freepascal.org/svn/fpc/trunk/rtl/linux/fpcylix.pp Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
>>>Interesting switch in FPC 2.1.1: >>> >>> -Skload fpcylix unit >>> >>>what is it for? >>Afaik it implicitely USES the fpcylix unit that contains some identifiers >>for Kylix compat that we _really_ didn't want in the normal >> system/sysutils >>unit. > where can i find it ? ~/fpc>>> find . -name 'fpcylix.pp' ./rtl/linux/fpcylix.pp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Marco van de Voort wrote: Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel where can i find it ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
> Interesting switch in FPC 2.1.1: > >-Skload fpcylix unit > > what is it for? Afaik it implicitely USES the fpcylix unit that contains some identifiers for Kylix compat that we _really_ didn't want in the normal system/sysutils unit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
Interesting switch in FPC 2.1.1: -Skload fpcylix unit what is it for? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Ростислав Окулов wrote:
>>Ростислав Окулов wrote:
>>
>>>How I can aligh data in FPC like in C?
>>>
>>>struct __declspec(align(16)) VECTOR4F
>>>{
>>>float x;
>>>float y;
>>>float z;
>>>float w;
>>>};
>>
>>FPC can align local data only up to 4 byte boundaries. Aligning to 16 byte
>>boundaries done by the compiler requires too much extra code because at every
>>procedure entry the stack must be realigned so causing often a slow down.
>>
>
> Ok. By when you use SSE2 or SSE3 data *MUST* be alligned to 16 bytes..
Only vector data. The compiler doesn't generate vector instruction so you need
it for assembler only and in assembler procedures you can align the stack
yourself.
> and if it is? we can use movups or movaps instead movss(FPC use this
> instruction, but It's more sloly than use mov*ps)
Clock cycle count of mov*ps might be lower but: movups/movaps move 16 bytes
while movss moves only 4 bytes: higher memory traffic. Further, if you load a
single, using mov*ps is dangerous because you could access data outside valid
memory which can cause segmentation faults, if the segment limits aren't aligned
to 16 byte boundaries.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Ростислав Окулов wrote: > Will be an SSE3 for assembler support? > 2.0.0 supports it? c:\fpc\compiler>type test.pas begin asm hsubps %xmm0,%xmm0 end; end. c:\fpc\compiler>fpc test.pas Free Pascal Compiler version 2.0.0 [2005/05/08] for i386 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: Win32 for i386 Compiling test.pas Linking test.exe 5 Lines compiled, 0.1 sec c:\fpc\compiler> ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
Ростислав Окулов wrote:
> How I can aligh data in FPC like in C?
>
> struct __declspec(align(16)) VECTOR4F
> {
> float x;
> float y;
> float z;
> float w;
> };
FPC can align local data only up to 4 byte boundaries. Aligning to 16 byte
boundaries done by the compiler requires too much extra code because at every
procedure entry the stack must be realigned so causing often a slow down.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
Will be an SSE3 for assembler support? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
How I can aligh data in FPC like in C?
struct __declspec(align(16)) VECTOR4F
{
float x;
float y;
float z;
float w;
};
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] (no subject)
Pls try win32_197.zip, which is latest win32 snapshot? Regards John > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 10 February 2005 19:45 > To: fpc-devel@lists.freepascal.org > Subject: [fpc-devel] (no subject) > > > Hint: fpc-1.9.7.i386-win32.exe 8/2/2005 is corrupt! > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
Hint: fpc-1.9.7.i386-win32.exe 8/2/2005 is corrupt! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
On Thu, 13 Jan 2005 14:04:10 +0100 (CET), Ladislav Lacina wrote > Message: 2 > Date: Wed, 12 Jan 2005 17:31:41 +0100 > From: "Tomas Hajny" <[EMAIL PROTECTED]> > Subject: Re: [fpc-devel] The new 1.9.6 release > To: FPC developers' list > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-2 > > > Ladislav Lacina wrote: > > > > > There are many problems in this version - at least under the GO32V2 > > > target. Mainly the things asociated with the FreeVision. Even the > > > installer doesn't work properly. The mouse is not visible and the 'OK' > > > button is in strange way hidden. Nor in the IDE is the mouse not shown. > > > Interresting is, that if you go to the Dosshell and return, the mouse > > > works properly. And there are many other problems. > > > Anyway thanks for the FreeVision. Finally. I modified it to use with the > > > previous 1.0.10 version. > > > And the last thing - will be in IDE in the official 2.0 version support > > > for VESA modes? > > > I very miss it. > > >1) The mouse cursor issue is already known, it will be researched and > >hopefully fixed. > > >2) For the other problems, please, report them using the bug repository > >accesible from our WWW pages. > > >3) Regarding VESA modes, what exactly do you miss there - extended text modes > >(132x50, 132x60 etc.), or something else? > > >Regards > >Tomas > > Yes, I mean the extended text modes (132x50, 132x60,...) I guess that implementing this functionality shouldn't be that hard, in fact. It needs the following changes in video.pp for GO32v2 as far as I can see: - New function checking for VESA availability and adding the found text modes to SysVMD table (which must be extended to be able to accomodate the new modes) - let's call it GetVESAModes. This function can be derived from vesa.inc located in the GO32v2 directory in RTL sources (GetVESAInfo, GetVESAModeInfo). The found information should be kept in (copied to) global structure to allow finding mode number when switching to this mode. - Add call to this new function to unit initialization (after SetVideoDriver call). - Provide new DoSetVESAMode function which can find the requested mode in the list of all available VESA modes (kept from GetVESAModes call), derive the appropriate mode number from it and change to this video mode using function 4F02h on interrupt 10h (see SetVESAMode in vesa.inc). - Change SysSetVideoMode to call DoSetVESAMode for video modes placed in SysVMD with index 5 and above. I don't have time to do that myself, but I'm willing to assist anybody in resolving encountered problems etc. (you can contact me directly). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
Message: 2 Date: Wed, 12 Jan 2005 17:31:41 +0100 From: "Tomas Hajny" <[EMAIL PROTECTED]> Subject: Re: [fpc-devel] The new 1.9.6 release To: FPC developers' list Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=iso-8859-2 > Ladislav Lacina wrote: > > > There are many problems in this version - at least under the GO32V2 > > target. Mainly the things asociated with the FreeVision. Even the > > installer doesn't work properly. The mouse is not visible and the 'OK' > > button is in strange way hidden. Nor in the IDE is the mouse not shown. > > Interresting is, that if you go to the Dosshell and return, the mouse > > works properly. And there are many other problems. > > Anyway thanks for the FreeVision. Finally. I modified it to use with the > > previous 1.0.10 version. > > And the last thing - will be in IDE in the official 2.0 version support > > for VESA modes? > > I very miss it. >1) The mouse cursor issue is already known, it will be researched and >hopefully fixed. >2) For the other problems, please, report them using the bug repository >accesible from our WWW pages. >3) Regarding VESA modes, what exactly do you miss there - extended text modes >(132x50, 132x60 etc.), or something else? >Regards >Tomas Yes, I mean the extended text modes (132x50, 132x60,...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
[EMAIL PROTECTED] wrote: I got the latest lazarus and fpc snap. The message comes since the new directories are being introduces e.g. win32 --> i386-win32 just noticed this dir change myself, i'm assuming that it "should" be ok to copy the "non-updated" files from the old bin dir to the new one? -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.279 / Virus Database: 264.12.7 - Release Date: 01/11/2004 ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
I got the latest lazarus and fpc snap. The message comes since the new directories are being introduces e.g. win32 --> i386-win32 Marco van de Voort wrote: the new directory structure has broken something!? D:\Lazarus>make process_begin: CreateProcess((null), ppc386.exe -iVSPTPSOTO, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iSP, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iTP, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iSO, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iTO, ...) failed. makefile:154: *** The Makefile doesn't support target , please run fpcmake first. Stop. D:\Lazarus> The lazarus Makefiles aren't updated. So there is something wrong in your setup Some possibilities: - can't find fpc, ppc386 or so. - some files (e.g. make) are not taken from the fpc dir, but from a cygwin or borland dir. - you use older make versions then the ones distributed with fpc 1.0.10 ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
> > the new directory structure has broken something!? > > > > D:\Lazarus>make > > process_begin: CreateProcess((null), ppc386.exe -iVSPTPSOTO, ...) failed. > > process_begin: CreateProcess((null), ppc386.exe -iSP, ...) failed. > > process_begin: CreateProcess((null), ppc386.exe -iTP, ...) failed. > > process_begin: CreateProcess((null), ppc386.exe -iSO, ...) failed. > > process_begin: CreateProcess((null), ppc386.exe -iTO, ...) failed. > > makefile:154: *** The Makefile doesn't support target , please run > > fpcmake first. Stop. > > D:\Lazarus> > > The lazarus Makefiles aren't updated. So there is something wrong in your > setup Some possibilities: - can't find fpc, ppc386 or so. - some files (e.g. make) are not taken from the fpc dir, but from a cygwin or borland dir. - you use older make versions then the ones distributed with fpc 1.0.10 ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] (no subject)
> the new directory structure has broken something!? > > D:\Lazarus>make > process_begin: CreateProcess((null), ppc386.exe -iVSPTPSOTO, ...) failed. > process_begin: CreateProcess((null), ppc386.exe -iSP, ...) failed. > process_begin: CreateProcess((null), ppc386.exe -iTP, ...) failed. > process_begin: CreateProcess((null), ppc386.exe -iSO, ...) failed. > process_begin: CreateProcess((null), ppc386.exe -iTO, ...) failed. > makefile:154: *** The Makefile doesn't support target , please run > fpcmake first. Stop. > D:\Lazarus> The lazarus Makefiles aren't updated. So there is something wrong in your setup ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] (no subject)
the new directory structure has broken something!? D:\Lazarus>make process_begin: CreateProcess((null), ppc386.exe -iVSPTPSOTO, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iSP, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iTP, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iSO, ...) failed. process_begin: CreateProcess((null), ppc386.exe -iTO, ...) failed. makefile:154: *** The Makefile doesn't support target , please run fpcmake first. Stop. D:\Lazarus> ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
All recent bugs fixed! Thanks FPC team (esp. Peter)! ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
On 6 jan 2004, at 15:06, litwr wrote:
I've found a bug during compiling of the followed program. Borland
Pascal 7 had complied it without problems.
Compile your program in TP mode (add {$mode tp} at the top of the
source, or use the -So command line option).
Jonas
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
Hi! I've found a bug during compiling of the followed program. Borland Pascal 7 had complied it without problems. Regards. Vladimir Lidovski. type linear = array[1..1]of real; ftype = function(var a; qrf, qcf: integer): real; function maxa(var a; qr, qc:integer): real; begin maxa := 1 end; function mina(var a; qr, qc:integer): real; begin mina := 0 end; procedure transform (var a; qr, qc: integer; f:ftype); begin end; const a:array[1..5, 1..4] of real = ( (1.,2.,3.,5. ), (2.,4.,5.,7. ), (11.,10.,19.,51. ), (1.,0.1,9.,5. ), (4.,6.,7.,11. )); var f: ftype; begin transform(a, 5, 4, maxa); end. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
On Tue, 6 Jan 2004 [EMAIL PROTECTED] wrote: > > > Why is there no daily binary snapshot at > > ftp://ftp.freepascal.org/pub/fpc/snapshot/v11/win32-i386/ ??? > > Latest files are marked with 14/12/03. It probably means that the build fails for some reason. Michael. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
Why is there no daily binary snapshot at ftp://ftp.freepascal.org/pub/fpc/snapshot/v11/win32-i386/ ??? Latest files are marked with 14/12/03. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
I have a problem with the different key codes identifiers. I would
suggest a carnonical key code
like shown below. According to used platform/component-library the
dedicated key codes are always
being mapped to the same identifier Key_.
//Kylix Qt : Key_Return = 4100;
//Microsoft : VK_RETURN = 13;
//Lazarus : key_Return = 13;
//GTK : GDK_KEY_Return = $FF0D;
{$IFDEF MsWindows}
const
Key_Return = Windows.vk_Return;
Key_Escape = Windows.vk_Escape;
Key_Space = Windows.vk_Space;
Key_C = Windows.vk_Cancel;
Key_Up = Windows.vk_Up;
Key_Down= Windows.vk_Down;
Key_Prior = Windows.vk_Prior;
Key_Next= Windows.vk_Next;
Key_Left= Windows.vk_Left;
Key_Right = Windows.vk_Right;
Key_Home= Windows.vk_Home;
Key_End = Windows.vk_End;
{$ENDIF}
{$IFDEF FPC_Linux}
const
Key_Return = VCLGlobals.key_Return;
Key_Escape = VCLGlobals.key_Escape;
Key_Space = -0;//???
Key_C = -1;//???
Key_Up = VCLGlobals.key_Up;
Key_Down= VCLGlobals.key_Down;
Key_Prior = -2;//???
Key_Next= -3;//???
Key_Left= VCLGlobals.key_Left;
Key_Right = VCLGlobals.key_Right;
Key_Home= VCLGlobals.key_Home;
Key_End = VCLGlobals.key_End;
{$ENDIF}
...
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
> >Hi folks, > >daily binary snapshots of fpc and lazarus > >without source, doc, etc would be useful. > > Is there a binary lazarus snapshot too? > You can better ask the question on the lazarus mailing list ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
>Hi folks, >daily binary snapshots of fpc and lazarus >without source, doc, etc would be useful. Is there a binary lazarus snapshot too? ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
Am Fre, 2003-04-04 um 09.40 schrieb Jeff Pohlmeyer: > Patch for /fpc/fcl/passrc/pscanner.pp > so it will recognize '<', '>', and '<>' > > - Not sure why these were omitted, maybe it has > something to do with fpdoc's tag generation? No, as Michael said, it's just because until now it only scans interfaces; and at the moment I only implement what I need. But I think these units will evolve and improve a lot over time. Thanks for the patch for now... (In the future, the scanner will recognise more symbols, and will be much faster as well.) - Sebastian ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
On vrijdag, apr 4, 2003, at 09:40 Europe/Brussels, Jeff Pohlmeyer wrote: Patch for /fpc/fcl/passrc/pscanner.pp so it will recognize '<', '>', and '<>' Seems it's still missing >= and <= though :) Jonas ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel](no subject)
On Thu, 3 Apr 2003, Jeff Pohlmeyer wrote: > Patch for /fpc/fcl/passrc/pscanner.pp > so it will recognize '<', '>', and '<>' > > - Not sure why these were omitted, maybe it has > something to do with fpdoc's tag generation? Normally not. I think that the explanation is that pscanner is used for the interface section only. Normally you don't find < > or <> in the interface section, except maybe in exotic things like Const N1 = 12; N2 = 13; Bigger = (N1>N2) ; // Boolean type However, don't let that stop you. Any improvements are welcome. Michael. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel](no subject)
Patch for /fpc/fcl/passrc/pscanner.pp so it will recognize '<', '>', and '<>' - Not sure why these were omitted, maybe it has something to do with fpdoc's tag generation? [PATCH] --- pscanner.oldThu Mar 27 10:32:48 2003 +++ pscanner.newThu Apr 3 23:48:57 2003 @@ -51,7 +51,9 @@ tkDivision,// '/' tkColon, // ':' tkSemicolon, // ';' +tkLessThan, // '<' tkEqual, // '=' +tkGreaterThan, // '>' tkAt, // '@' tkSquaredBraceOpen,// '[' tkSquaredBraceClose,// ']' @@ -59,6 +61,7 @@ // Two-character tokens tkDotDot, // '..' tkAssign, // ':=' +tkNotEqual, // '<>' // Reserved words tkabsolute, tkand, @@ -230,13 +233,16 @@ '/', ':', ';', +'<', '=', +'>', '@', '[', ']', '^', '..', ':=', +'<>', // Reserved words 'absolute', 'and', @@ -726,10 +732,25 @@ Inc(TokenStr); Result := tkSemicolon; end; +'<': + begin +Inc(TokenStr); + if TokenStr[0] = '>' then + begin + Inc(TokenStr); + Result := tkNotEqual; + end else + Result := tkLessThan; + end; '=': begin Inc(TokenStr); Result := tkEqual; + end; +'>': + begin +Inc(TokenStr); +Result := tkGreaterThan; end; '@': begin [/PATCH] Hoping to use this unit in a little project I am working on... Thanks, - Jeff __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
