Re: [fpc-pascal] how to convert JNByteBuffer variable type to type usable by fw.write
On 2019-08-26 15:13, Mgr. Janusz Chmiel wrote:
Please, does somebody of us know how to write file by using binary
mode and writing data from The variable which have JNByteBuffer
variable type?
Here is a Java example on how to do it. You need to use
java.io.FileOutputStream (JIFileOutputStream in FPC):
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
public class Main {
public static void main(String[] args) throws Exception {
String fromFileName = "from.txt";
String toFileName = "to.txt";
FileChannel in = new FileInputStream(fromFileName).getChannel();
FileChannel out = new FileOutputStream(toFileName).getChannel();
ByteBuffer buff = ByteBuffer.allocateDirect(32 * 1024);
while (in.read(buff) > 0) {
buff.flip();
out.write(buff);
buff.clear();
}
in.close();
out.close();
}
}
(reproduced from
http://www.java2s.com/Code/Java/File-Input-Output/WritewithByteBuffer.htm
)
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
schrieb am Di., 27. Aug. 2019, 01:38: > If anybody would like a near silent POWER9 system at home, > I can really recommend the new Blackbird mainboard with CPU bundles > from Raptor CS. The lower cost 4-core CPU uses so little power you > hardly even need a fan for it. > If only it wouldn't still be so damn expensive... I'm still a bit miffed that I didn't purchase one of the refurbished Tyan servers with a POWER8 for 250€ a few months ago... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hi Pierre,
wow that was fast and it works now! Lazarus (trunk) now compiles and
runs without any changes on a POWER9 machine in little endian mode :=)
Very beautiful! I couldn't be happier. Good work everyone!
I'm running it on Ubuntu but I have also installed a few other Linux
distributions, all with GUI on this machine. One of them runs with both
little and big endian flavors (Void Linux). Will test Lazarus on all of
them soon (not sure if big endian will work though, but that's not
important). If anybody would like a near silent POWER9 system at home,
I can really recommend the new Blackbird mainboard with CPU bundles
from Raptor CS. The lower cost 4-core CPU uses so little power you
hardly even need a fan for it.
Cheers,
Tobias
On Mon, 26 Aug 2019 23:22:01 +0200
Pierre Muller wrote:
>
>
> Le 26/08/2019 à 22:46, tobiasgie...@gmail.com a écrit :
> > Hi Jonas,
> >
> > fantastic, that looks great. I think now I can just wait until Pierre
> > Muller's snapshot is updated :=)
>
>
> As I followed the thread, I made a special issue for you,
> you should find the new snapshot of ftp site:
>
>
> $ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux
> This snapshot was generated 2019-08-26 using:
> make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT="
> -Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5"
> started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64
> ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1
>
> uname -a of the machine is:
> Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14
> 11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux
>
> "svnversion -c ." output is: 1:1415
>
> "svnversion -c fpcsrc" output is: 1:42841M
>
> Enjoy,
>
> Pierre Muller
>
> PS: note that I do have local modifications that I did not have time to
> really check...
> Most are probably not significant, but:
>
> [muller@gcc2-power8 fpcsrc]$ svn diff
> Index: rtl/linux/ostypes.inc
> ===
> --- rtl/linux/ostypes.inc (revision 42841)
> +++ rtl/linux/ostypes.inc (working copy)
> @@ -170,8 +170,8 @@
> FLock = Record
> l_type : cshort; { lock type: read/write, etc. }
> l_whence: cshort; { type of l_start }
> -l_start : kernel_off_t; { starting offset }
> -l_len : kernel_off_t; { len = 0 means until end of file }
> +l_start : off_t;{ starting offset }
> +l_len : off_t;{ len = 0 means until end of file }
> l_pid : pid_t;{ lock owner }
> {$if defined(cpusparc) or defined(cpusparc64)}
> __pad : cshort;
> @@ -386,7 +386,7 @@
>RLIMIT_LOCKS = 10;{ maximum file locks held }
>
> type
> - rlim_t = cULong;
> + rlim_t = cULongLong;
>PRLimit = ^TRLimit;
>TRLimit = record
> rlim_cur : rlim_t;
> Index: rtl/linux/powerpc/stat.inc
> ===
> --- rtl/linux/powerpc/stat.inc (revision 42841)
> +++ rtl/linux/powerpc/stat.inc (working copy)
> @@ -35,9 +35,9 @@
> st_rdev : culonglong;
> __pad2_: cushort;
> st_size : clonglong;
> -st_blksize: clong;
> +st_blksize: blksize_t;
>
> -st_blocks : clonglong;
> +st_blocks : culonglong;
> st_atime : clong;
> st_atime_nsec : culong;
> st_mtime : clong;
> Index: rtl/linux/powerpc64/stat.inc
> ===
> --- rtl/linux/powerpc64/stat.inc(revision 42841)
> +++ rtl/linux/powerpc64/stat.inc(working copy)
> @@ -43,5 +43,7 @@
>st_mtime_nsec : cULong;
>st_ctime : cULong;
>st_ctime_nsec : cULong;
> - __unused : array[0..2] of cULong;
> + __unused4 : culong;
> + __unused5 : culong;
> + __unused6 : culong;
>end;
> Index: rtl/linux/ptypes.inc
> ===
> --- rtl/linux/ptypes.inc(revision 42841)
> +++ rtl/linux/ptypes.inc(working copy)
> @@ -206,7 +206,7 @@
> bfree, { free blocks in system }
> bavail,{ Available free blocks to non-root users }
> files, { File nodes in system }
> -ffree : culong; { Free file nodes in system }
> +ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free
> file nodes in system }
> fsid: array[0..1] of cint; { File system ID }
> namelen, { Maximum name length in system }
> frsize : cint;
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Kind Regards,
Tobias Giesen
Super Flexible Software GmbH & Co. KG
Buddenstr. 29-31
481
Re: [fpc-pascal] ppc64le ABI problem
Le 26/08/2019 à 22:46, tobiasgie...@gmail.com a écrit :
> Hi Jonas,
>
> fantastic, that looks great. I think now I can just wait until Pierre
> Muller's snapshot is updated :=)
As I followed the thread, I made a special issue for you,
you should find the new snapshot of ftp site:
$ cat ftp/snapshot/trunk/powerpc64-linux/README-powerpc64-linux
This snapshot was generated 2019-08-26 using:
make distclean singlezipinstall SNAPSHOT=1 NOGDB=1 DEBUG=1 NOWPOCYCLE=1 OPT="
-Fl/usr/lib64 -Fl/lib64 -Fd -Fl/usr/lib/gcc/ppc64le-redhat-linux/4.8.5"
started using /home/muller/pas/fpc-3.3.1/bin/ppcppc64
ppcppc64 -iVDW output is: 3.3.1 2019/08/26 3.3.1
uname -a of the machine is:
Linux gcc2-power8.osuosl.org 3.10.0-957.10.1.el7.ppc64le #1 SMP Thu Mar 14
11:25:48 GMT 2019 ppc64le ppc64le ppc64le GNU/Linux
"svnversion -c ." output is: 1:1415
"svnversion -c fpcsrc" output is: 1:42841M
Enjoy,
Pierre Muller
PS: note that I do have local modifications that I did not have time to really
check...
Most are probably not significant, but:
[muller@gcc2-power8 fpcsrc]$ svn diff
Index: rtl/linux/ostypes.inc
===
--- rtl/linux/ostypes.inc (revision 42841)
+++ rtl/linux/ostypes.inc (working copy)
@@ -170,8 +170,8 @@
FLock = Record
l_type : cshort; { lock type: read/write, etc. }
l_whence: cshort; { type of l_start }
-l_start : kernel_off_t; { starting offset }
-l_len : kernel_off_t; { len = 0 means until end of file }
+l_start : off_t;{ starting offset }
+l_len : off_t;{ len = 0 means until end of file }
l_pid : pid_t;{ lock owner }
{$if defined(cpusparc) or defined(cpusparc64)}
__pad : cshort;
@@ -386,7 +386,7 @@
RLIMIT_LOCKS = 10;{ maximum file locks held }
type
- rlim_t = cULong;
+ rlim_t = cULongLong;
PRLimit = ^TRLimit;
TRLimit = record
rlim_cur : rlim_t;
Index: rtl/linux/powerpc/stat.inc
===
--- rtl/linux/powerpc/stat.inc (revision 42841)
+++ rtl/linux/powerpc/stat.inc (working copy)
@@ -35,9 +35,9 @@
st_rdev : culonglong;
__pad2_: cushort;
st_size : clonglong;
-st_blksize: clong;
+st_blksize: blksize_t;
-st_blocks : clonglong;
+st_blocks : culonglong;
st_atime : clong;
st_atime_nsec : culong;
st_mtime : clong;
Index: rtl/linux/powerpc64/stat.inc
===
--- rtl/linux/powerpc64/stat.inc(revision 42841)
+++ rtl/linux/powerpc64/stat.inc(working copy)
@@ -43,5 +43,7 @@
st_mtime_nsec : cULong;
st_ctime : cULong;
st_ctime_nsec : cULong;
- __unused : array[0..2] of cULong;
+ __unused4 : culong;
+ __unused5 : culong;
+ __unused6 : culong;
end;
Index: rtl/linux/ptypes.inc
===
--- rtl/linux/ptypes.inc(revision 42841)
+++ rtl/linux/ptypes.inc(working copy)
@@ -206,7 +206,7 @@
bfree, { free blocks in system }
bavail,{ Available free blocks to non-root users }
files, { File nodes in system }
-ffree : culong; { Free file nodes in system }
+ffree :{$ifdef cpupowerpc}culonglong{$else}culong{$endif}; { Free file
nodes in system }
fsid: array[0..1] of cint; { File system ID }
namelen, { Maximum name length in system }
frsize : cint;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hi Jonas, fantastic, that looks great. I think now I can just wait until Pierre Muller's snapshot is updated :=) Cheers, Tobias On Mon, 26 Aug 2019 21:42:37 +0200 Jonas Maebe wrote: > On 26/08/2019 20:56, Jonas Maebe wrote: > > On 26/08/2019 20:54, Florian Klaempfl wrote: > >> Am 26.08.2019 um 20:52 schrieb Jonas Maebe: > >>> On 26/08/2019 14:22, Florian Klämpfl wrote: > Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal > : > > > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > > 14:01: > > > >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 > >> as a > >> temporary test. > > > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > > that fike (plus its preceeding comment) ^^') > > Indeed :-) If it works, it must be made dependent on the target ABI. > >>> > >>> It's indeed like that, see section 2.2.2 of > >>> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf > >> > >> Yes, I checked the docs as well :) I don't know though why it is only 32 > >> for elf_abi_v2 ... > > > > It's because the other ABIs also provide space for a compiler and > > linker-specific slot: > > https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK > > I've submitted the fix. > > > Jonas > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Kind Regards, Tobias Giesen Super Flexible Software GmbH & Co. KG Buddenstr. 29-31 48143 Münster, Germany www.superflexible.com www.tgtools.com --- Registered at register court Münster as HRA 9716 Liability / general partner: TGTools GmbH Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
On 26/08/2019 20:56, Jonas Maebe wrote: > On 26/08/2019 20:54, Florian Klaempfl wrote: >> Am 26.08.2019 um 20:52 schrieb Jonas Maebe: >>> On 26/08/2019 14:22, Florian Klämpfl wrote: Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > 14:01: > >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as >> a >> temporary test. > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > that fike (plus its preceeding comment) ^^') Indeed :-) If it works, it must be made dependent on the target ABI. >>> >>> It's indeed like that, see section 2.2.2 of >>> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf >> >> Yes, I checked the docs as well :) I don't know though why it is only 32 >> for elf_abi_v2 ... > > It's because the other ABIs also provide space for a compiler and > linker-specific slot: > https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK I've submitted the fix. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
On 26/08/2019 20:54, Florian Klaempfl wrote: > Am 26.08.2019 um 20:52 schrieb Jonas Maebe: >> On 26/08/2019 14:22, Florian Klämpfl wrote: >>> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal >>> : >>> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a > temporary test. Line 302 in case anyone is wondering (thankfully that's the only "48" in that fike (plus its preceeding comment) ^^') >>> >>> Indeed :-) If it works, it must be made dependent on the target ABI. >> >> It's indeed like that, see section 2.2.2 of >> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf > > Yes, I checked the docs as well :) I don't know though why it is only 32 > for elf_abi_v2 ... It's because the other ABIs also provide space for a compiler and linker-specific slot: https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#STACK Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 26.08.2019 um 20:52 schrieb Jonas Maebe: > On 26/08/2019 14:22, Florian Klämpfl wrote: >> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal >> : >> >>> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >>> 14:01: >>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a temporary test. >>> >>> Line 302 in case anyone is wondering (thankfully that's the only "48" in >>> that fike (plus its preceeding comment) ^^') >> >> Indeed :-) If it works, it must be made dependent on the target ABI. > > It's indeed like that, see section 2.2.2 of > https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf Yes, I checked the docs as well :) I don't know though why it is only 32 for elf_abi_v2 ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
On 26/08/2019 14:22, Florian Klämpfl wrote: > Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal > : > >> Florian Klämpfl schrieb am Mo., 26. Aug. 2019, >> 14:01: >> >>> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >>> temporary test. >> >> Line 302 in case anyone is wondering (thankfully that's the only "48" in >> that fike (plus its preceeding comment) ^^') > > Indeed :-) If it works, it must be made dependent on the target ABI. It's indeed like that, see section 2.2.2 of https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
schrieb am Mo., 26. Aug. 2019, 19:53: > Hello, > > trying to recompile now ... since ppc64le support is not in 3.0.4, I > suppose I need to use a more recent version to compile it. So there is > no advantage in cross-compiling and I might as well try it with the > latest native fpc compiler? > > So I need to fix compiler errors myself, is that correct, such as this: > sysosh.inc(19,1) Error: Forward type not resolved "Boolean8" > bugs.freepascal.org/view.php?id=35676 > > I wonder how the precompiled FPC for ppc64le is made, if trunk > cannot compile itself? > FPC 3.0.4 is still the latest release and thus currently the only supported compiler. In case of ppc64le you need to indeed cross compile though as long as you have the binutils it's as simple as make clean all CPU_TARGET=ppc64le BINUTILSPREFIX=ppc64le-elf- FPMAKEOPT="-T N" - j N Whereby you need to adjust BINUTILSPREFIX to whatever prefix your binutils have and N to e.g. your number of cores. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hello, trying to recompile now ... since ppc64le support is not in 3.0.4, I suppose I need to use a more recent version to compile it. So there is no advantage in cross-compiling and I might as well try it with the latest native fpc compiler? So I need to fix compiler errors myself, is that correct, such as this: sysosh.inc(19,1) Error: Forward type not resolved "Boolean8" bugs.freepascal.org/view.php?id=35676 I wonder how the precompiled FPC for ppc64le is made, if trunk cannot compile itself? Cheers, Tobias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new design for a JSON Parser
Adding a global redefinable separator character is a good idea which I
might add. With regards to using the forward slash, I am just reusing the
XPath way of doing things and was considering adding a few more XPath like
queries. For example:
N.Find('/inventory/999/sku'); // search from root if the first path
character is '/', find the 999th node, return the sku
N.Find('//item[name="widget"]/price'); // search for the first item in the
entire document ('//') with a name of widget, return its price
N.Find('//item[recalled]/name'); // search for the first item with a
recalled node and return the name
And so on ...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] how to convert JNByteBuffer variable type to type usable by fw.write
Please, does somebody of us know how to write file by using binary mode and writing data from The variable which have JNByteBuffer variable type? What do I had to do so I would be able to write data to The output file in binary mode from The variable which have JNByteBuffer variable type? Thank you very very much for yours answers. I Am using fpcJVM Android target. Unfortunately, fw.write expect Jlstring. Buffer is live \MP3 stream which is automatically loaded by bass.so to The device from The Internet. I want to create record function to record live stream and listen it simultaneously at The same time. So I do not want to use HTTP or other special library to open next standalone media stream to allocate new Internet bandwidth. Do you think, that is it possible or I can not create recording feature to simply? Many of us may be think, why I Am doing my best to develop my own personal little apps by using Pascal and Android. There are so many many players on Google Play. I give you The answer. Professional apps such as Audials, which support recording feature are full of amazing features. I can not tell negative word about it. But many functions have one disadvantage for Me as visually impaired with no sight at all. Many buttons, many GUI controls and orientation inside so complex app is not easy. This is The reason why I do my best to develop my own little radio player and recorder from scratch. And I have next important reason. It is very remarkable opportunity to learn object oriented programming, Android API calls, .so libraryes calls and other. By The way. I have never found other solution than units for FPCJVM Android target, which would allow Me to develop GUI with no need to specify object coordinates and positions by using Pixel or other values. I do not know about Java Android library which would allow Me to create buttons, combo boxes and other elements with no depend on .xml files which contain position values and there is other problem. Even if some Java language commands can display short warning or other think, there is important Czech characters encoding problem. There is no free Lazarus compatible library for Windows, which can be really be used without typing numbers to specify object values. VCL have been created for Delphi and I do not know about legal and opensource alternative to VCL for Lazarus for Windows. So I have decided to program some simple apps for Android. GUI is acceptable by sighted users. Sure, may be, that it will be never so nice like GUI, which uses Gradle themes and special tricks supported by Android studio or Kotlin language. But for Me is very important The fact, that GUI can be used not only with screen readers, but it can be used by sighted users and I can program without assistance of sighted person, who would help Me to tailor GUI by using Mouse and some IDE preview feature while developing GUI. Next factor. FPCJVM compiler enable Pascal programmer to create professional apps. It is possible to call .jar libraryes without embedded .so libraryes or with embedded ones. Very advanced Pascal programmer can even create .so library by using ARM machine code compiler target and call those functions from FPCJVM based source code. If somebody will improve The quality of javapp.jar, so it will not bother because of swing appled when using it from Windows and when generating Android import header files, it will be possible to use not only newer and newer Android APIS. But it also would be possible to use complex projects such as Exoplayer from Google, if somebody would be able to compile standalone Exoplayer library without demo apps to standalone .jar library and if javapp.jar will be able to create usable import headers for it, it will be next multimedia framework for FPCJVM Android developers. Since Exoplayer support audio and video, it do not depend on native code .so libraryes, it is complex app compiled to classes. The question is, if The parts of Exoplayer code have not been developed by using Kotlin. If so, may be, that creating new tool to generate Pascal import headers from Classes, which have been generated by Kotlin compiler would be very very complex task. Thank you very very much for yours answer on my question. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Hello, many thanks, I will try it! I haven't compiled FPC for ppc64le myself so it can take a few days but I will let you know about the result. Cheers, Tobias On Mon, 26 Aug 2019 14:22:01 +0200 Florian Klämpfl wrote: > Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal > : > > > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > > 14:01: > > > >> Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > >> > >>> Hello, > >>> > >>> > >>> > >>> > >>> while examining a crash when running Lazarus on ppc64le, I found the > >>> following issue in function calls. > >>> > >>> > >>> > >>> > >>> Calls to functions with more than eight parameters seem to be > >>> implemented differently from how gcc does it in a C program. > >>> > >>> > >>> > >>> > >>> gcc uses the memory location 96(r1) for the ninth parameter, but FPC > >>> uses 112(r1). > >>> > >>> > >>> > >>> > >>> Therefore, calls to XGetWindowProperty crash. This function has 12 > >>> parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > >> 120(r1), > >>> and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > >>> > >>> > >>> > >>> > >>> What can be done about this? > >> > >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a > >> temporary test. > > > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > > that fike (plus its preceeding comment) ^^') > > Indeed :-) If it works, it must be made dependent on the target ABI. > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Kind Regards, Tobias Giesen Super Flexible Software GmbH & Co. KG Buddenstr. 29-31 48143 Münster, Germany www.superflexible.com www.tgtools.com --- Registered at register court Münster as HRA 9716 Liability / general partner: TGTools GmbH Registered at register court Münster as HRB 17763 Directors: Tobias Giesen and Claudia Giesen ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal : > Florian Klämpfl schrieb am Mo., 26. Aug. 2019, > 14:01: > >> Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: >> >>> Hello, >>> >>> >>> >>> >>> while examining a crash when running Lazarus on ppc64le, I found the >>> following issue in function calls. >>> >>> >>> >>> >>> Calls to functions with more than eight parameters seem to be >>> implemented differently from how gcc does it in a C program. >>> >>> >>> >>> >>> gcc uses the memory location 96(r1) for the ninth parameter, but FPC >>> uses 112(r1). >>> >>> >>> >>> >>> Therefore, calls to XGetWindowProperty crash. This function has 12 >>> parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), >> 120(r1), >>> and FPC into 112(r1), 120(r1), 128(r1), 136(r1). >>> >>> >>> >>> >>> What can be done about this? >> >> Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a >> temporary test. > > Line 302 in case anyone is wondering (thankfully that's the only "48" in > that fike (plus its preceeding comment) ^^') Indeed :-) If it works, it must be made dependent on the target ABI. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > > > Hello, > > > > > > while examining a crash when running Lazarus on ppc64le, I found the > > following issue in function calls. > > > > > > Calls to functions with more than eight parameters seem to be > > implemented differently from how gcc does it in a C program. > > > > > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > > uses 112(r1). > > > > > > Therefore, calls to XGetWindowProperty crash. This function has 12 > > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > 120(r1), > > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > > > > > What can be done about this? > > Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a > temporary test. > Line 302 in case anyone is wondering (thankfully that's the only "48" in that fike (plus its preceeding comment) ^^') Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > Hello, > > > while examining a crash when running Lazarus on ppc64le, I found the > following issue in function calls. > > > Calls to functions with more than eight parameters seem to be > implemented differently from how gcc does it in a C program. > > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > uses 112(r1). > > > Therefore, calls to XGetWindowProperty crash. This function has 12 > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > 120(r1), > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > > What can be done about this? Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a temporary test. > > > I also noticed that the "file" command in Linux mentioned an additional > property of the linked C program I wrote for testing: > "for GNU/Linux 3.10.0" > > > The FPC program did not have this tag. > > > The complete "file" outputs are: > > > a.out: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version > 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, > BuildID[sha1]=6c5d2b5c7408e74eeda95fbf8d120fe8de0f2f30, for GNU/Linux > 3.10.0, with debug_info, not stripped > > > minimalxcrash: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, > version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, with > debug_info, not stripped > > > Hoping my find will be useful, > Best wishes, > Tobias Giesen > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new design for a JSON Parser
Very cool library.
It would be nice if separator character can be change
For example, for me personally
aval := n.find('billTo.name'). value;
more intuitive instead of
aval := n.find('billTo/name'). value;
Also AFAIK, GPL v3 license will require application using this library must use
GPL too.
Zamrony P. Juhara
Fano Framework https://fanoframework.github.io
On Mon, Aug 26, 2019 at 15:12, Anthony Walter wrote: I
know the FCL already has a capable JSON parser, but I am writing some Amazon
web service interfacing projects and wanted a smaller easier to use JSON parser
to assist. I've create a new design for a JSON parser that is pretty small, yet
powerful.
If your interested, I've posted the code under GPLv3 and a write up of my
thought process and the workflow of using an single small class to work with
JSON:
https://www.getlazarus.org/json/
Any and all feedback is welcome.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] A new design for a JSON Parser
I know the FCL already has a capable JSON parser, but I am writing some Amazon web service interfacing projects and wanted a smaller easier to use JSON parser to assist. I've create a new design for a JSON parser that is pretty small, yet powerful. If your interested, I've posted the code under GPLv3 and a write up of my thought process and the workflow of using an single small class to work with JSON: https://www.getlazarus.org/json/ Any and all feedback is welcome. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
