Re: [fpc-pascal] DOS compiler wiki page: please review

2013-10-05 Thread greim 

Hi,

writing a 8086 version of fpc is not so strange as some may think!
There are still some 80186 processors around running in embedded 
systems! These architecture is certified for some applications in 
industrial and avionik controll.


A good survey over most  #186 derivates you may find at:

http://www.cpushack.com/2013/01/12/the-intel-80186-gets-turbocharged-vautomation-turbo186/


For example

http://www.lantronix.com/device-networking/embedded-device-servers/dstni-lx_dstni-ex.html

or

http://www.lantronix.com/device-networking/embedded-device-servers/xchip.html

and used for example in this embedded computer:

http://www.beck-ipc.com/en/products/sc2x/index.asp

This processors are using an own OS called RTOS which is quite nice.


BUT
most of these prcessors are using an extended addressing for using more 
then 640 kByte, with more address lines. So "old " 8086 programms can 
only run if they are using only a "small memory" option. With RTOS also 
the header of the EXE files is slightly modified.

So Borland Pacal 7.01 programs can only runn after some ugly patching.
Frank v. Münchow-Pohl has written a small patch program which is 
decribed here:

http://forum.beck-ipc.com/viewtopic.php?f=7&t=824

Until 3 years ago the AMD 186 was still available, which have been real 
80186, but this processor is not produced anymore as far as i know.


So running Pascal programs on these kind of systems is not realy 
possible anymore. The only option afaik is using teh Paradigm C++

compiler:
http://www.devtools.com/pcpp/compiler.htm
which is quite expensive, an as i was told not so reliable.


Here you will see a list of processirs they are supporting, so i think 
there is is still a market for the 80(1)86


http://www.devtools.com/pcpp/processors.htm

So my wish list:
fpc for 80186, supporting the new extended addressing and writing the 
header files for RTOS (see 
http://www.beck-ipc.com/en/products/rtos/index.asp) incl. a FPU emulation !


Anny comment welcome.

Markus


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Custom dataset help request: ftCurrency/ftDateTime returns weird data

2013-10-05 Thread wkitty42 

On Friday, October 4, 2013 11:18 AM, Reinier Olislagers 
 wrote: 
> Thanks, but using that (and similar change for the TDateTime) gives the 
> same results ;( 

perhaps the problem is further back in the code where that data is written to 
the destination?? i've goofed many many many times and forgotten to use the 
caret where necessary so i ended up writing the pointer value to a file or 
stream instead of the data the pointer points to which was what i was really 
after...


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to stop a HttpApp via request?

2013-10-05 Thread silvioprog 
2013/9/25 Michael Van Canneyt 

> On Wed, 25 Sep 2013, silvioprog wrote:
>
>> 2013/9/24 Graeme Geldenhuys 
>>   On 24/09/13 10:46, Michael Van Canneyt wrote:
>>   >
>>   > I am working on it.
>>
>> Thanks Michael.
>>
>> btw: The fcl-web (and all your guidance) has worked wonders with my
>> client side CGI application. The organisation of code and application
>> flow is so much better. Thanks again for all your patience and help.
>>
>
> I had a look at
>
> http://bugs.freepascal.org/**view.php?id=24810
>
> And applied the patches there, with some extra modifications.
>
> I tested, and the server can now reliably be stopped without problems both
> in threaded or non threaded mode, from inside or outside a request.
>
> Michael.


Worked like a charm. Thank you very much Michael! (y)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] gdbm package on Windows

2013-10-05 Thread greim 

Hi,

i want to  _read_ *.pag files created as hash ( dbm or ndbm or gdbm) 
files in Perl (Linux) with freepascal.


I used the gdbm package, and it worked fine with Linux.

On Windows (XP) using the same *.pag file unfortunately not.
I installed different gdbm.dll files in the working directory but the 
testdbm.pp crushed down with some access violation (fpc) or was asking 
for a c.dll (in a Lazarus application) ?


Is the gdbm package designed only for Linux (i fear so) ?
Is there any other package / tool / source snippet for READING dbm files 
on Windows?


Regards

Markus Greim
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] gdbm package on Windows

2013-10-05 Thread Sven Barth 

On 05.10.2013 17:56, greim wrote:

Hi,

i want to  _read_ *.pag files created as hash ( dbm or ndbm or gdbm)
files in Perl (Linux) with freepascal.

I used the gdbm package, and it worked fine with Linux.

On Windows (XP) using the same *.pag file unfortunately not.
I installed different gdbm.dll files in the working directory but the
testdbm.pp crushed down with some access violation (fpc) or was asking
for a c.dll (in a Lazarus application) ?


I don't know gdbm, but it seems that the library itself requires a C dll 
and then it's not important whether the application is written in 
Pascal, C or something else, because the library is a C one and thus 
needs a fitting runtime DLL.


Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Proposal for a XPath Namespace Resolver

2013-10-05 Thread Daniel Gaspary 
(Let me know if bugtracker is better to discuss the idea)

Today the XPath Ns Resolver is marked as "Experimental" and is just an
alias for TDomNode:

  TXPathNSResolver = TDOMNode {!!! experimental}; [1]

The problem happens when the Namespace definition is not at the root
of the XML being processed:


  
  


Using

EvaluateXPathExpression('//@u1:AnAttribute', x.DocumentElement,
   x.DocumentElement);

(x is a TXmlDocument)

 Will raise an Exception due to the "Resolver" not being capable of
finding the URI when starting from root.

I think of something simple as:

TXPathNSResolver = class

   property CurrentNode: TDomNode; //Necessary??
   property xml: TXmlDocument;
   property OnNeedUri: TXPathNeedUriEvent;
end;

TXPathNeedUriEvent would be something like:

procedure (Sender: TXPathNSResolver; out AUri: String) of object;

Searching first at CurrentNode.lookupNamespaceURI and, if not found,
using OnNeedUri.

Ideas?

Should I post it at mantis, change, quit.. ?


[1] Line #352: 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-xml/src/xpath.pp?view=markup
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)

2013-10-05 Thread Philippe 
  

I am back !!! (a bit sick ... teeth ...) 

I am now trying to move
to win32. At first leaving crt unit, moving to video unit. 

Problem!(?)
... I was using window, gotoxy and so on ... and I don´t find anything
similar with video unit! 

On Fri, 20 Sep 2013 11:02:00 +0200, Sven
Barth wrote: 

> Am 19.09.2013 22:46, schrieb Tomas Hajny:
> 
>> On Thu,
September 19, 2013 21:55, Sven Barth wrote: 
>> 
>>> On 19.09.2013
17:28, Tomas Hajny wrote:
>> . . 
>> 
 2) You still need at least a
linker for the GO32v2 target (FPC internal linker does not support this
target) and that is the somewhat tricky part.
>>> Hmm? Looking at
compiler/systems/t_go32v2.pas I would say GO32v2 does have an internal
linker?!
>> Have you checked it in fixes or trunk? In any case, I've
tried it directly with the 2.6.2 binary before posting - even if I pass
-Xi explicitly, the compiler still complains about go32v2-ld.exe not
found if it is not accessible (and linking fails). I believe that Sergei
may have fixed / enabled it for GO32v2 in trunk (but my memory may serve
me wrong, of course).
> 
> Ehm, yes, trunk only. Sergei implemented it
in revision 21435 at 30th 
> May 2012.
> 
> Regards,
> Sven
>
___
> fpc-pascal maillist -
fpc-pascal@lists.freepascal.org [1]
>
http://lists.freepascal.org/mailman/listinfo/fpc-pascal [2]



Links:
--
[1] mailto:fpc-pascal@lists.freepascal.org
[2]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)

2013-10-05 Thread Tomas Hajny 
On Sat, October 5, 2013 21:34, Philippe wrote:
>
>
> I am back !!! (a bit sick ... teeth ...)
>
> I am now trying to move
> to win32. At first leaving crt unit, moving to video unit.
>
> Problem!(?)
> ... I was using window, gotoxy and so on ... and I don´t find anything
> similar with video unit!

First of all, what do you try to solve by moving from unit Crt to unit
Video? I suggested using unit video as a substitution of your original
direct access to video adapter memory. Partial alternative of GotoXY
exists in unit Video - there is SetCursorPos. However, there is no direct
support for Window and thus the addressing is in absolute coordinates, not
relative to the defined window. Using direct video memory access (i.e.
very low-level approach) together with high-level routines like Window,
etc., is a bit strange. Units Video and Crt are not very compatible to
each other at the moment, unfortunately (although the incompatibility may
not be as bad on Win32 as on some other platforms). Nevertheless, you may
try it. Otherwise, you'd need either to create your own alternatives of
Window, etc., based on unit Video, or to avoid using the solution based on
directly addressing video memory/buffer.

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proposal for a XPath Namespace Resolver

2013-10-05 Thread Benito van der Zander 
Alternatively, just use the XPath implementation of my Internet Tools 
(http://www.benibela.de/sources_en.html#internettools).


Works perfectly there.

E.g. process('  
 ', '//@u1:AnAttribute' ).toString

returns 'AttValue'


On 10/05/2013 07:08 PM, Daniel Gaspary wrote:

(Let me know if bugtracker is better to discuss the idea)

Today the XPath Ns Resolver is marked as "Experimental" and is just an
alias for TDomNode:

   TXPathNSResolver = TDOMNode {!!! experimental}; [1]

The problem happens when the Namespace definition is not at the root
of the XML being processed:


   
   


Using

 EvaluateXPathExpression('//@u1:AnAttribute', x.DocumentElement,
x.DocumentElement);

(x is a TXmlDocument)

  Will raise an Exception due to the "Resolver" not being capable of
finding the URI when starting from root.

I think of something simple as:

TXPathNSResolver = class

property CurrentNode: TDomNode; //Necessary??
property xml: TXmlDocument;
property OnNeedUri: TXPathNeedUriEvent;
end;

TXPathNeedUriEvent would be something like:

procedure (Sender: TXPathNSResolver; out AUri: String) of object;

Searching first at CurrentNode.lookupNamespaceURI and, if not found,
using OnNeedUri.

Ideas?

Should I post it at mantis, change, quit.. ?


[1] Line #352: 
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-xml/src/xpath.pp?view=markup
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Helpers: Implementation Location influencing the result

2013-10-05 Thread Daniel Gaspary 
I have created an example to show the different results I got due to
where the implementation of a object is .

The code is at http://pastebin.com/wY2qmZFm

If you cut and paste the code block at "Location A" to the "Location
B" the result of the program changes.

At Location A the method of the helper is used. At Location B it is not.

My questions are

Is this right?

Why?


Thank you.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proposal for a XPath Namespace Resolver

2013-10-05 Thread Daniel Gaspary 
On Sat, Oct 5, 2013 at 5:59 PM, Benito van der Zander
 wrote:
> Alternatively, just use the XPath implementation of my Internet Tools
> (http://www.benibela.de/sources_en.html#internettools).
>
> Works perfectly there.
>
> E.g. process(' 
>  ', '//@u1:AnAttribute' ).toString
> returns 'AttValue'

It's not an option at moment. But could be useful to test and compare results.

Thank you.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Helpers: Implementation Location influencing the result

2013-10-05 Thread Sven Barth 
Am 05.10.2013 22:57 schrieb "Daniel Gaspary" :
>
> I have created an example to show the different results I got due to
> where the implementation of a object is .
>
> The code is at http://pastebin.com/wY2qmZFm
>
> If you cut and paste the code block at "Location A" to the "Location
> B" the result of the program changes.
>
> At Location A the method of the helper is used. At Location B it is not.
>
> My questions are
>
> Is this right?

Yes.

> Why?

At location A the helper is not yet declared, thus GetAnotherString uses
the GetString function of its own class. On location B the helper is
already declared and thus the implementation of GetAnotherString will pick
up the helper's GetString function instead.

As normally helpers aren't declared in the same unit as their extended type
this isn't necessarily that obvious. ;)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)

2013-10-05 Thread Philippe 
  

I really assumed that I had to choice between video unit and crt
unit ... 

my old unit which interfaced the video must be updated to be
compiled for win32. 

I already though about to create my window
procedure and my gotoxy procedure ... this way I may not have to make a
lot of changes in my program. 

I missed SetCursorPos ... thanks a lot


My first step, anyway, is to verify it is compiling for win32! ...
later I´ll make more changes and all the adjustments. 

Philippe 

On
Sat, 5 Oct 2013 22:48:09 +0200, Tomas Hajny wrote: 

> On Sat, October
5, 2013 21:34, Philippe wrote:
> 
>> I am back !!! (a bit sick ... teeth
...) I am now trying to move to win32. At first leaving crt unit, moving
to video unit. Problem!(?) ... I was using window, gotoxy and so on ...
and I don´t find anything similar with video unit!
> 
> First of all,
what do you try to solve by moving from unit Crt to unit
> Video? I
suggested using unit video as a substitution of your original
> direct
access to video adapter memory. Partial alternative of GotoXY
> exists
in unit Video - there is SetCursorPos. However, there is no direct
>
support for Window and thus the addressing is in absolute coordinates,
not
> relative to the defined window. Using direct video memory access
(i.e.
> very low-level approach) together with high-level routines like
Window,
> etc., is a bit strange. Units Video and Crt are not very
compatible to
> each other at the moment, unfortunately (although the
incompatibility may
> not be as bad on Win32 as on some other
platforms). Nevertheless, you may
> try it. Otherwise, you'd need either
to create your own alternatives of
> Window, etc., based on unit Video,
or to avoid using the solution based on
> directly addressing video
memory/buffer.
> 
> Tomas
> 
>
___
> fpc-pascal maillist -
fpc-pascal@lists.freepascal.org [1]
>
http://lists.freepascal.org/mailman/listinfo/fpc-pascal [2]



Links:
--
[1] mailto:fpc-pascal@lists.freepascal.org
[2]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Helpers: Implementation Location influencing the result

2013-10-05 Thread Daniel Gaspary 
On Sat, Oct 5, 2013 at 8:27 PM, Sven Barth  wrote:
> At location A the helper is not yet declared, thus GetAnotherString uses the
> GetString function of its own class. On location B the helper is already
> declared and thus the implementation of GetAnotherString will pick up the
> helper's GetString function instead.

I believed that the location that matters, in this case,  was only the
object instantiation (program/implementation body), because it was, in
both cases, after the helper declaration. A little weird.


Thanks, Sven.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal