Our end-of-semester rushes usually take 2 weeks. Anyway I’m hoping it’s
going to be tested (I did for i386-win32 and x86_64-win64) and applied
asap. :(
--
Best regards,
JC Chu
On Jul 12, 101 R.O.C., at 23:32, Sven Barth
wrote:
Am 12.07.2012 12:20 schrieb "JC Chu" :
>
> I uploaded a patch in
> Oversight, a bug.
> I am currently working on the parser, I'll look into this.
> Michael.
Thanks, I appreciate it.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-p
Ludo Brands wrote:
We only support 32 bit SPARC, and there we split a 64 bit load into
two
32 bit loads. dbl, assuming it points to a double, should
point to a 64
bit-aligned memory location though (depending on the cpu, 32 bit
alignment may be sufficient, but better be safe than sorry).
I'll
On Thu, 12 Jul 2012, Seth Grover wrote:
Greetings! I've been using fcl-passrc (PParser and PasTree) to create
a tool to help me with coverage analysis. Using the example provided
in the package directory as a starting point, I've created a tool
which finds the "begin" line number for each func
Greetings! I've been using fcl-passrc (PParser and PasTree) to create
a tool to help me with coverage analysis. Using the example provided
in the package directory as a starting point, I've created a tool
which finds the "begin" line number for each function/procedure
definition and inserts a line
On 12 July 2012 15:20, luciano de souza wrote:
> localhost, I would like indications about small, not instalable web
> servers, ideal for my simple and sharable Pascal CGIs! Does someone
> know something about this?
Have a look an nYume. It is a small and easy, but fully functional
HTTP-server.
Am 12.07.2012 12:20 schrieb "JC Chu" :
>
> I uploaded a patch in #22359 about a week ago but I see that it’s not
> been applied yet. (There was something wrong in previous versions but
> I believe the latest one should be correct.) Since it’s been about a
> week, I’m wondering if there’s still so
Theres lightwebserver in Powutils
2012/7/12 Michael Van Canneyt :
>
>
> On Thu, 12 Jul 2012, luciano de souza wrote:
>
>> Hello all,
>> I am running some CGIs in localhost. When talking about web servers,
>> the name of Apache comes as natural. However, I would like to share
>> some zip fi
> > We only support 32 bit SPARC, and there we split a 64 bit load into
> > two
> > 32 bit loads. dbl, assuming it points to a double, should
> point to a 64
> > bit-aligned memory location though (depending on the cpu, 32 bit
> > alignment may be sufficient, but better be safe than sorry).
>
On Thu, 12 Jul 2012, luciano de souza wrote:
Hello all,
I am running some CGIs in localhost. When talking about web servers,
the name of Apache comes as natural. However, I would like to share
some zip files to show the results. For this purpose, Apache is not
the best because I need
In our previous episode, Jonas Maebe said:
>
> > I'll try to test against 2.7.1 later in the day, although as I've
> > said Linux is OK.
>
> The memory layout is not necessarily the same on both OSes.
Or does the linux kernel contain a facility to work around certain kinds of
exceptions?
E.g.
Hello all,
I am running some CGIs in localhost. When talking about web servers,
the name of Apache comes as natural. However, I would like to share
some zip files to show the results. For this purpose, Apache is not
the best because I need something not instalable.
I tried a small server
Mark Morgan Lloyd wrote on Thu, 12 Jul 2012:
I'll try to test against 2.7.1 later in the day, although as I've
said Linux is OK.
The memory layout is not necessarily the same on both OSes.
Is the if FIntegerDatetimes then something Solaris-specific Ludo?)?
That would be extremely unlik
Jonas Maebe wrote:
Thomas Schatzl wrote on Thu, 12 Jul 2012:
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0,
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc,
Thomas Schatzl wrote on Thu, 12 Jul 2012:
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0,
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa
803
Thomas Schatzl wrote:
Hi,
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Ludo Brands wrote:
Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a
consistent error
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LO
Hi,
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
> Ludo Brands wrote:
>
> Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a
> consistent error
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 4]
> 0x004b08b8 in TPQCONNECTION__LOADFIELD (CU
good work,thinks!
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/BUG-flush-the-serial-in-FPC2-6-0-tp5710299p5710308.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist
I uploaded a patch in #22359 about a week ago but I see that it’s not
been applied yet. (There was something wrong in previous versions but
I believe the latest one should be correct.) Since it’s been about a
week, I’m wondering if there’s still something that I missed.
Thanks.
--
Best regards
Ludo Brands wrote:
I've found a problem when a (well-tested) program that connects to a
PostgreSQL database is compiled and run on Solaris 10 for
SPARC, Linux
SPARC is OK.
I appreciate that this is a minority platform, but would I be less
unpopular reporting it against 2.6.0 or testing it ag
> I've found a problem when a (well-tested) program that connects to a
> PostgreSQL database is compiled and run on Solaris 10 for
> SPARC, Linux
> SPARC is OK.
>
> I appreciate that this is a minority platform, but would I be less
> unpopular reporting it against 2.6.0 or testing it against
On 11-7-2012 22:22, waldo kitty wrote:
> On 7/11/2012 01:36, Reinier Olislagers wrote:
>> On 11-7-2012 4:19, waldo kitty wrote:
>>> On 7/10/2012 07:00, Luiz Americo Pereira Camara wrote:
With the old behavior, in an system with a system code page<> UTF8,
if i try to
show the parsed
Am 12.07.2012 10:11 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> I've found a problem when a (well-tested) program that connects to a
PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux
SPARC is OK.
>
> I appreciate that this is a minority platform, but
I've found a problem when a (well-tested) program that connects to a
PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux
SPARC is OK.
I appreciate that this is a minority platform, but would I be less
unpopular reporting it against 2.6.0 or testing it against 2.7.1 first?
P
kc87654321 wrote:
I am trying to flush the serial incom on Linux with no success.
So far I have: serial.pp in fpc 2.6.0
is SerFlush, which calls fpfsync, intended to discard input data, no work.
it is patch as 0018946 but for fpc 2.4.2 no 2.6.0
http://free-pascal-general.1045716.n5.nabble.com/
I am trying to flush the serial incom on Linux with no success.
So far I have: serial.pp in fpc 2.6.0
is SerFlush, which calls fpfsync, intended to discard input data, no work.
it is patch as 0018946 but for fpc 2.4.2 no 2.6.0
http://free-pascal-general.1045716.n5.nabble.com/Unix-serial-port-han
26 matches
Mail list logo
