[fpc-pascal] Re: fpc-pascal Digest, Vol 95, Issue 21

Thu May 24 23:06:56 CEST 2012

Bien Miguel, estos son los costos:
Ya esta colocado en la WEB

24/05/12 	Cambio: texto Banner Promociones 	S/. 	5.00
24/05/12 	Actualización: Promoiocnes 	S/. 	15.00

*Total
* 	
	*S/.* 	*20.00*

Att.
Luis Del Aguila
Telf.: 2422297
Cel.: 999264073
www.aguila3000.net
www.conoce3000.com

El 10/05/2012 10:04 a.m., fpc-pascal-request at lists.freepascal.org escribió:
> Send fpc-pascal mailing list submissions to
> 	fpc-pascal at lists.freepascal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> or, via email, send a message with subject or body 'help' to
> 	fpc-pascal-request at lists.freepascal.org
>
> You can reach the person managing the list at
> 	fpc-pascal-owner at lists.freepascal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fpc-pascal digest..."
>
>
> Today's Topics:
>
>     1.  Re: 2.6.0 for Solaris? (microcode at zoho.com)
>     2.  Re: 2.6.0 for Solaris? (microcode at zoho.com)
>     3.  fpc&  arm-embedded interrupts (Koenraad Lelong)
>     4. Re:  Re: 2.6.0 for Solaris? (Tomas Hajny)
>     5. Re:  fpc&  arm-embedded interrupts (Jeppe Gr?sdal Johansen)
>     6.  Re: Runs correctly when debugging. (Guillermo Mart?nez Jim?nez)
>     7.  Re: 2.6.0 for Solaris? (microcode at zoho.com)
>     8. Re:  Re: 2.6.0 for Solaris? (Tomas Hajny)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 May 2012 11:22:38 +0000
> From: microcode at zoho.com
> Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
> To: fpc-pascal at lists.freepascal.org
> Message-ID:<20120510112300.82330A3501A at lists.freepascal.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 10 May 2012 07:27:22 +0000 Mark Morgan Lloyd wrote:
>
>> microcode wrote:
>>> What SPARC box(es) do you have? I may be able to host Solaris
>>> development systems if needed although the SPARC stuff would have to be
>>> scheduled since I cannot leave them on all the time because of the huge
>>> noise and heat factor. The Intel box is on most of the time.
>> I've got a range here: mostly U60 running "in anger", a U80, E4500, U10s,
>> a U1, plus some museum pieces I can't find an OS for. I'm also one of
>> very few people who've got an SS1000E running Linux SMP, but that's not a
>> recent distro and because of library versions (**) I'm not sure what if
>> any version of FPC I could get running on it.
> The E4500s are monsters, aren't they? I'd like to have one but I'm out of
> space. I'd like an Ultra 80 as well. I could find a spot for one of those.
>
> I've got a stack of Sun Fire 210s and 440s. They're very nice but they're
> in various states of needing odds and ends and I don't have much disk
> capacity but plenty for development machines. The 210s are two bangers and
> are fast enough for building large apps in a reasonable timeframe. The 440s
> are slow but they're unstoppable, they run like a freight train, nothing
> bothers them. I'm hoping to get a pile of RAM but so far all the promises
> haven't panned out. I have a bad UPS and when I get that fixed I'll have
> more machines available to come online whenever needed.
>
>> ** When a program is built, the (Linux) linker puts the actual filenames
>> of the .so files it expects to find in the binary- not the names of any
>> symlinks. That means that once you've built a binary using standard
>> parameters, that binary /requires/ the same collection of .so versions
>> that was on the development system
> Right you are. Before reading your post I built glibc-2.14 and tried fp
> again but no joy..
>
>> . ... I managed to get around that to backport FPC from Solaris 10 to 8
>> but in general I think it's better to start off with a version that runs
>> and work forwards.
> Agreed.
>
>> I wholeheartedly agree that power, and in the Summer heat, is a massive
>> problem. There's only so much we can afford, and even with substantial
>> air conditioning things can get pretty unpleasant in my workroom and the
>> adjacent machineroom. That's why I'm only able to offer U10s as always-up
>> systems, Vincent used one of those for Lazarus two or three years ago and
>> I've tried to test both FPC and Lazarus on Linux and Solaris fairly
>> regularly since.
> Sun makes awfully nice boxes and Solaris is a very nice development
> platform. I hope the guys will keep FPC going on Solaris. There are many
> Solaris 10 on Sun fans.
>
>>> I appreciate your offer for packages but since you or somebody else has
>>> already pointed me to the buildfaq, I'll try this on my own and when I
>>> get stuck I'll email the list again. Thanks again for all the help.
>> You might find it useful to go to the Mantis bug tracker and look at the
>> SPARC-related bugs I've reported- use "View Issues", expand "Search",
>> select "Mark Morgan Lloyd" from "Reporter" then "Use Filter". You might
>> in particular need http://mantis.freepascal.org/view.php?id=18271 when
>> getting your initial FPC binary installed on Solaris 10.
> Thanks for the info.
>
>
>> When you get to compiling, you might find it necessary to use a command
>> line like this:
>>
>> make NOGDB=1 OPT='-O- -gl'
>>
>> What that does is tell it to not try to use the optional libgdb in the fp
>> text-mode IDE, and it disables optimisation in the compiler binary (/not/
>> the compiler's ability to apply optimisation) so that if something goes
>> wrong you can get a useful backtrace.
> Thanks.
>
>
>> On Debian, you'll need [checks] build-essential, gdb, libgpmg1-dev, and
>> some combination of libncurses5-dev and libncursesw5-dev. If you get as
>> far as building Lazarus use trunk (on SPARC) and treat libgtk2.0-dev and
>> possibly libqt4pas-dev as prerequisites, if those aren't available (e.g.
>> on Slackware) I suggest we continue on the Lazarus mailing list.
> I don't think I'll spend any further time looking at Linux, as the
> Slackware copy of 2.6.0 seems to work for a few small samples. If I can't
> get fp built on Solaris SPARC or if it doesn't work on Solaris Intel (will
> check that next week) then I'll think about what to do next, probably just
> live with Emacs. If I get bored and my list of things to do ever gets small
> enough I'll look at rebuilding 2.6.0 Linux under 2.6.0 with my glibc.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 May 2012 11:25:12 +0000
> From: microcode at zoho.com
> Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
> To: fpc-pascal at lists.freepascal.org
> Message-ID:<20120510112532.BE51FA350F9 at lists.freepascal.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 10 May 2012 07:32:47 +0000 Mark Morgan Lloyd wrote:
>
>>> How many sockets do you have on your E4500?
>> 12, i.e. space for an I/O card and internal discs for booting.
> Woohoo! That's a lot of CPUs. I'll bet you can heat your home with that in
> the winter.
>
>> I prefer the SS1000 architecture, where each of the eight cards is
>> identical so you can have 16x CPUs plus full I/O... in addition being a
>> Xerox PARC design it has a certain pedigree ;-)
> I'm not familiar with that one.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 May 2012 13:56:51 +0200
> From: Koenraad Lelong<fpascal at brouwerij.homelinux.net>
> Subject: [fpc-pascal] fpc&  arm-embedded interrupts
> To: fpc-pascal at lists.freepascal.org
> Message-ID:<4FABAD03.9010207 at brouwerij.homelinux.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I'm working on an embedded-arm application. I do want to use interrupts
> but I don't find how to easily setup the interrupt-handlers.
> In the startup code in C, I see default handlers defined with the
> keyword WEAK. Looking around, I found that this means that if one
> defines a function with the same name, that will be used instead of the
> default-handler. The start-address of that new function will be entered
> in the interrupt-vector table in flash.
> Is something similar possible with fpc ? Looking in the
> fpc-startup-code, the rtl, I don't see that, but that could be me.
> Or do I have to modify the rtl for every project I will be making ? What
> I did see I think, in some rtl-units for arm-embedded, is that there
> seems to be a contruction to put the start-address of the main
> error-handlers in RAM. Would that be the only way to have interrupts ?
>
> Thanks for any help,
>
> Regards,
>
> Koenraad Lelong.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 10 May 2012 14:07:47 +0200 (CEST)
> From: "Tomas Hajny"<XHajT03 at hajny.biz>
> Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris?
> To: "FPC-Pascal users discussions"<fpc-pascal at lists.freepascal.org>
> Message-ID:
> 	<32247.62.141.0.146.1336651667.squirrel at mail.freepascal.org>
> Content-Type: text/plain;charset=iso-8859-2
>
> On Thu, May 10, 2012 13:22, microcode at zoho.com wrote:
>   .
>   .
>> Sun makes awfully nice boxes and Solaris is a very nice development
>> platform. I hope the guys will keep FPC going on Solaris. There are many
>> Solaris 10 on Sun fans.
>   .
>   .
>
> FPC support of individual platforms depends on availability of volunteers
> interested and capable of supporting these platforms. FPC can target
> really many platforms nowadays, but this increasing number cannot be
> supported with constant number of developers. Someone from the Sun fans
> has to step in, otherwise the support cannot be guaranteed in the long
> term.
>
> Tomas
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 10 May 2012 14:28:25 +0200
> From: Jeppe Gr?sdal Johansen<jjohan07 at student.aau.dk>
> Subject: Re: [fpc-pascal] fpc&  arm-embedded interrupts
> To: FPC-Pascal users discussions<fpc-pascal at lists.freepascal.org>
> Message-ID:<4FABB469.9040706 at student.aau.dk>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> The easiest way to do interrupt processing in Cortex-M3 processors(which
> I assume you are using), is to create an interrupt vector table in SRAM
> and then change the NVIC to use that. That way you can point to the
> interrupt handlers at runtime.
>
> It's true that the normal way of doing it is with weak linking as you
> write, but there's no support for that directly in FPC currently, so
> it'll have to be done with external assembly. It is doable, but noone
> has made it entirely yet.
>
> Den 10-05-2012 13:56, Koenraad Lelong skrev:
>> Hi,
>>
>> I'm working on an embedded-arm application. I do want to use
>> interrupts but I don't find how to easily setup the interrupt-handlers.
>> In the startup code in C, I see default handlers defined with the
>> keyword WEAK. Looking around, I found that this means that if one
>> defines a function with the same name, that will be used instead of
>> the default-handler. The start-address of that new function will be
>> entered in the interrupt-vector table in flash.
>> Is something similar possible with fpc ? Looking in the
>> fpc-startup-code, the rtl, I don't see that, but that could be me.
>> Or do I have to modify the rtl for every project I will be making ?
>> What I did see I think, in some rtl-units for arm-embedded, is that
>> there seems to be a contruction to put the start-address of the main
>> error-handlers in RAM. Would that be the only way to have interrupts ?
>>
>> Thanks for any help,
>>
>> Regards,
>>
>> Koenraad Lelong.
>> _______________________________________________
>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 10 May 2012 14:44:41 +0200
> From: Guillermo Mart?nez Jim?nez<gmartinez at burdjia.com>
> Subject: [fpc-pascal] Re: Runs correctly when debugging.
> To: fpc-pascal at lists.freepascal.org
> Message-ID:
> 	<CAAmE6CM-AuMeeXCX=5DsfOnNbMYAwyy4-UAxFborHB1fAVo48g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> No, you have to use pchar.  I would also define ALLEGRO_BITMAP as an
>> empty record, to be clear that it's an opaque type:
>>
>> {$packrecords c}
>>   TAllegroBitmap = record
>>   end;
>>   PAllegroBitmap = ^TAllegroBitmap;
>>
>> Thus:
>>
>> function al_load_bitmap(const filename: pchar): PAllegroBitmap; cdecl;
>> external ALLEGRO_LIB_NAME;
>>
>> Make sure you use {$packrecords c}.  Use the types in unit "ctypes",
>> e.g. cint, cfloat, cdouble.  This will ensure the variables are the same
>> size and work on all architectures.
>>
>> Henry
> Ok, then I should revise all the "STRING" parameters, as well as all
> pointer types and "ctypes".
>
> Thanks for the advices.
> Guillermo.
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 10 May 2012 13:20:09 +0000
> From: microcode at zoho.com
> Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
> To: fpc-pascal at lists.freepascal.org
> Message-ID:<20120510132033.E15B6A34808 at lists.freepascal.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote:
>
>> On Thu, May 10, 2012 13:22, microcode wrote:
>>> Sun makes awfully nice boxes and Solaris is a very nice development
>>> platform. I hope the guys will keep FPC going on Solaris. There are
>>> many Solaris 10 on Sun fans.
>> FPC support of individual platforms depends on availability of volunteers
>> interested and capable of supporting these platforms. FPC can target
>> really many platforms nowadays, but this increasing number cannot be
>> supported with constant number of developers. Someone from the Sun fans
>> has to step in, otherwise the support cannot be guaranteed in the long
>> term.
> Yeah, that's obvious. I'm sure anybody who was capable would help. All I
> can offer at this point is development systems but that doesn't seem to be
> the problem. How much platform dependent code is there? I would think if
> the main product works on i386 or AMD64 for example then there isn't much
> to do except build on the other targets?
>
> Is it a matter of not having developers for the specific platform or not
> having anybody to build it for a specific platform?
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 10 May 2012 17:03:36 +0200 (CEST)
> From: "Tomas Hajny"<XHajT03 at hajny.biz>
> Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris?
> To: "FPC-Pascal users discussions"<fpc-pascal at lists.freepascal.org>
> Message-ID:
> 	<8310.62.141.0.146.1336662216.squirrel at mail.freepascal.org>
> Content-Type: text/plain;charset=iso-8859-2
>
> On Thu, May 10, 2012 15:20, microcode at zoho.com wrote:
>> On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote:
>>> On Thu, May 10, 2012 13:22, microcode wrote:
>>>> Sun makes awfully nice boxes and Solaris is a very nice development
>>>> platform. I hope the guys will keep FPC going on Solaris. There are
>>>> many Solaris 10 on Sun fans.
>>> FPC support of individual platforms depends on availability of
>>> volunteers
>>> interested and capable of supporting these platforms. FPC can target
>>> really many platforms nowadays, but this increasing number cannot be
>>> supported with constant number of developers. Someone from the Sun fans
>>> has to step in, otherwise the support cannot be guaranteed in the long
>>> term.
>> Yeah, that's obvious. I'm sure anybody who was capable would help. All I
>> can offer at this point is development systems but that doesn't seem to be
>> the problem. How much platform dependent code is there? I would think if
>> the main product works on i386 or AMD64 for example then there isn't much
>> to do except build on the other targets?
>>
>> Is it a matter of not having developers for the specific platform or not
>> having anybody to build it for a specific platform?
> There are operating system specific parts in both the compiler
> (i_sunos.pas and t_sunos.pas being the most visible ones but not
> necessarily the only ones) and the RTL. Moreover, talking about Solaris on
> Sun, there are also parts of the compiler and RTL specific for the SPARC
> platform. There are also packages which may occasionally need some
> platform specific adaptations too (not even mentioning the examples,
> etc.).
>
> All of this requires some testing at least before releases and obviously
> also resolution of bugs specific to the particular platform (which may
> involve also debugging problems reported for the particular platform to
> the point where it is clear that the problem lies in some shared code).
>
> Preferably, the maintainer should also run the testsuite regularly and
> watch for possible deviations in order to keep quality under control and
> avoid last minute surprises either before or even after new releases.
>
> Tomas
>
>
>
>
> ------------------------------
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
> End of fpc-pascal Digest, Vol 95, Issue 21
> ******************************************
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20120524/e38760cc/attachment.html>