Re: [fpc-pascal] What's the deal with CloseThread?
In our previous episode, Sven Barth said: And no one bothers to read my answer :( I did. And the part about tthread not being expressed in terms of the procedural api still stands. Apples and oranges. They are IMHO two independent public API with no relation to eachother. Again: The only RTL that currently(!) does something inside CloseThread is the Windows RTL: it closes the thread handle (which was returned by BeginThread and is passed as an argument to CloseThread) using CloseHandle. True. That's what it was introduced for. The Windows TThread.SysDestroy also calls CloseHandle on the handle returned by BeginThread, so the semantic behavior of Begin-/End-/CloseThread and TThread is the same. Nevertheless in my opinion TThread needs to be adjusted so that it calls CloseThread for all RTLs and the direct CloseHandle call needs to be removed. And this is exactly what I will do now... If it makes you happy, but IMHO it is pointless. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's the deal with CloseThread?
Am 23.04.2013 22:40, schrieb Anthony Walter: Thanks for so much Sven. I have another question. Is it okay for a thread to close itself before it's finished? Because I believe that is what happens when FreeOnTerminate is set to True. Here is a brief synopsis of what can execute: In rtl/objpas/classes/classes.inc Line 168: FreeThread := Thread.FFreeOnTerminate; // captures free on termiante Line 173: Thread.Free; // invokes the destructor from within the thread Line 197: CloseThread(FHandle); // thread is closed in destructor TThread.Destroy; Line 174: EndThread(Result); // flow returns here, but the thread was already closed So what it looks like is that we expect code inside a thread continue running after it has been closed. That's ok, because the FHandle is information which is retrieved in the context of the calling thread (e.g. the main thread). And if we don't need any more information about the thread we just close it's handle (equivalent to CloseThread) and be done with it. EndThread on the other hand is called in the context of the called thread. Afterall you also normally close the thread handle which you get returned by a CreateProcess(?) call, but keep the process handle around. With CloseHandle (and the semantically equal CloseThread) you just tell the system that you don't plan to interact with the object that the handle references (in this case a thread) anymore. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Statically link library
On 04/23/2013 10:14 PM, Darius Blaszyk wrote: Thanks Ludo! Works perfectly also here. However for my understanding. Why does MinGW find open, filesize etc? Is there some header file that translates these functions to be compatible with msvcrt? If not I would have to create one myself to limit the amount of work I guess. Is MinGW finding open, filesize ? When building a static library there is no verification at all if functions really exist. Enter size = whatever(file); and build your static library. You don't get any errors. Only when linking the final executable it will start looking for 'whatever'. In C you don't have to prototype functions. The compiler just assumes an extern int if the function is not defined in the source or an header file and leaves it up to the linker to sort it out. Or worse, lets your program crash if the function exists but has a different parameter list or does not return an int. Welcome to the joys of programming in C ;) Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's the deal with CloseThread?
Am 24.04.2013 09:35, schrieb Marco van de Voort: The Windows TThread.SysDestroy also calls CloseHandle on the handle returned by BeginThread, so the semantic behavior of Begin-/End-/CloseThread and TThread is the same. Nevertheless in my opinion TThread needs to be adjusted so that it calls CloseThread for all RTLs and the direct CloseHandle call needs to be removed. And this is exactly what I will do now... If it makes you happy, but IMHO it is pointless. No, it's not pointless. If we should ever have the need to add code to the CloseThread functions of other platforms then we don't need to adjust the platform specific TThread implementations. TThread uses BeginThread (and also EndThread) and thus by definition it should also use CloseThread (the only exception is the old BeOS threading implementation, but this is only kept around for reference). TThread is just an object oriented wrapper around the procedural threading API, so it must adhere to its rules as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RAD Studio XE4 Released?
Seemingly no support for Linux and Android. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object Pascal Grammar in EBNF like style
On 2013-04-23 14:22, Kenneth Cochran wrote: Just curious how your efforts turned out? Not much changed since that post. I've made notes [thanks to the wiki links] of what I still have missing. The latest Language Reference doc can be downloaded in INF format (viewable with DocView - also downloadable) from this URL: http://sourceforge.net/projects/fpgui/files/fpGUI/Documentation/docs_2013-04-20.zip/download Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mipsel compilation: changing elf flags?!
If OP could identify the correct parameter for ld it might be possible to use
fpc's -k option.
What am I supposed to do? ld has myriads of options. I don't set any
intentional (/usr/local/bin/mipsel-linux-ld is just a softlink to
.../mipsel/bin/ld)
RE: [fpc-devel] FPC for MIPS
Pierre Free Pascal Tue, 15 Jan 2013 07:59:00 -0800
I updated ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/ ...
svn up (Revision 24313)
export PP=
make OPT=-O- -g -C compiler mipsel
sudo mv compiler/ppcmipsel /usr/lib/fpc/2.6.2/ppcmipsel
{I don't want to corrupt my standard compiler}
export PP=/usr/lib/fpc/2.6.2/ppcmipsel
mv rtl/units/mipsel-linux/ /usr/lib/fpc/2.6.2/units/
ppcmipsel -vt bogus
|Configfile search: /home/tietze/.fpc.cfg
|Reading options from file /home/tietze/.fpc.cfg
|Path /usr/lib/fpc/2.7.1/units/mipsel-linux/httpd22/ not found
|Path /usr/lib/fpc/2.7.1/units/mipsel-linux/ not found
|Path /usr/lib/fpc/2.7.1/units/mipsel-linux/*/ not found
|Path /usr/lib/fpc/2.7.1/units/mipsel-linux/rtl/ not found
|Path /usr/lib/fpc/2.6.2/units/mipsel-linux/*/ not found
|Path /usr/lib/fpc/2.6.2/units/mipsel-linux/rtl/ not found
|Free Pascal Compiler version 2.7.1 [2013/04/23] for mipsel
|Copyright (c) 1993-2013 by Florian Klaempfl and others
|Path /usr/lib/fpc/2.7.1/units/mipsel-linux/rtl/ not found
|Searching file /lib/ld.so.1... not found
|Searching file /lib/ld-uClibc.so.0... not found
|Compiler: /usr/lib/fpc/2.6.2/ppcmipsel
|Target OS: Linux for MIPSEL
|Using executable path: /usr/lib/fpc/2.6.2/
|Using unit path: /usr/lib/fpc/2.6.2/units/mipsel-linux/
|Using unit path: /usr/lib/fpc/2.6.2/
|Using library path: /usr/local/mipsel/lib/
|Using library path: /usr/lib/fpc/2.6.2/units/mipsel-linux/
|Using library path: /usr/lib/fpc/2.6.2/
|Using object path: /usr/lib/fpc/2.6.2/units/mipsel-linux/
|Using object path: /usr/lib/fpc/2.6.2/
|Compiling bogus
ppcmipsel hello.pp
|Free Pascal Compiler version 2.7.1 [2013/04/23] for mipsel
|Copyright (c) 1993-2013 by Florian Klaempfl and others
|Target OS: Linux for MIPSEL
|Compiling hello.pp
|Assembling hello
|Linking hello
|/usr/local/bin/mipsel-linux-ld: warning: link.res contains output sections;
did you forget -T?
|/usr/local/bin/mipsel-linux-ld: hello.o: warning: linking abicalls files with
non-abicalls files
|/usr/local/bin/mipsel-linux-ld: /usr/lib/fpc/2.6.2/units/mipsel-
linux/system.o: warning: linking abicalls files with non-abicalls files
|3 lines compiled, 0.1 sec
more .fpc.cfg
|#ifdef cpumipsel
|-Xd
|-Fl/usr/local/mipsel/lib
|-Pmipsel
|-Cg
|-CfSOFT
|-Fu/usr/lib/fpc/2.6.2/units/$fpctarget
|-Fu/usr/lib/fpc/2.6.2/units/$fpctarget/*
|-Fu/usr/lib/fpc/2.6.2/units/$fpctarget/rtl
|#endif
readelf -h hello
|ELF Header:
| Magic: 7f 45 4c 46 01 01 01 00 01 00 00 00 00 00 00 00
| Class: ELF32
| Data: 2's complement, little endian
| Version: 1 (current)
| OS/ABI:UNIX - System V
| ABI Version: 1
| Type: EXEC (Executable file)
| Machine: MIPS R3000
| Version: 0x1
| Entry point address: 0x401210
| Start of program headers: 52 (bytes into file)
| Start of section headers: 41624 (bytes into file)
| Flags: 0x50001005, noreorder, cpic, o32, mips32
| Size of this header: 52 (bytes)
| Size of program headers: 32 (bytes)
| Number of program headers: 3
| Size of section headers: 40 (bytes)
| Number of section headers: 9
| Section header string table index: 8
Execution still fails on the Fritz!Box.
PS: Please CC' me any reply; I dislike mailinglists ;-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's the deal with CloseThread?
In our previous episode, Sven Barth said: CloseThread for all RTLs and the direct CloseHandle call needs to be removed. And this is exactly what I will do now... If it makes you happy, but IMHO it is pointless. No, it's not pointless. If we should ever have the need to add code to the CloseThread functions of other platforms then we don't need to adjust the platform specific TThread implementations. TThread uses BeginThread (and also EndThread) and thus by definition it should also use CloseThread (the only exception is the old BeOS threading implementation, but this is only kept around for reference). That is just one side. The other side is that modifications to the underused procedural api potentially also could break the much used tthread implementation. IOW, IMHO the tthread implementation is leading. TThread is just an object oriented wrapper around the procedural threading API, so it must adhere to its rules as well. Around the threadmanager. Not the procedural api, it never was. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's the deal with CloseThread?
Am 24.04.2013 12:43, schrieb Marco van de Voort: TThread is just an object oriented wrapper around the procedural threading API, so it must adhere to its rules as well. Around the threadmanager. Not the procedural api, it never was. Considering that all TThread implementations call BeginThread and EndThread and none calls ThreadManager.BeginThread and ThreadManager.EndThread directly this is not true (the only TThread implementation that in fact calls GetThreadManager is the Unix one and that only to call SemaphoreWait which is not exposed otherwise. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's the deal with CloseThread?
On Wed, Apr 24, 2013 at 3:53 AM, Sven Barth pascaldra...@googlemail.comwrote: That's ok, because the FHandle is information which is retrieved in the context of the calling thread (e.g. the main thread). And if we don't need any more information about the thread we just close it's handle (equivalent to CloseThread) and be done with it. EndThread on the other hand is called in the context of the called thread. Afterall you also normally close the thread handle which you get returned by a CreateProcess(?) call, but keep the process handle around. With CloseHandle (and the semantically equal CloseThread) you just tell the system that you don't plan to interact with the object that the handle references (in this case a thread) anymore. Make sense, got it. Thank you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RAD Studio XE4 Released?
The price is greater than my salary for a year, (When i have a job). On Tue, Apr 23, 2013 at 10:49 PM, vfclists . vfcli...@gmail.com wrote: http://www.h-online.com/developer/news/item/RAD-Studio-XE4-focuses-on-cross-platform-apps-1848176.html http://www.embarcadero.com/press-releases/embarcadero-technologies-unveils-multi-device-true-native-app-development-suite -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- I am using last revision of Lazarus, FPC 2.6 on Windows XP SP3 Best Regards Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RAD Studio XE4 Released?
Hi, Please continue this discussion on the fpc-other list, thanks Jonas FPC mailing lists admin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Simple beep sound Linux
How to program a simple beep in Linux. Now I have a mainboard which has a speaker, but needs to program using the sound device, I guess. Crt sound() does not work in this case. Is there another solution as easy as sound() in the crt unit? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Odyssey: SSockets and Threads.
Hello, There are a multi-thread example using SSockets in FPC? I'm trying to implement it*, but it's very hard and this work it's consuming all my time. The difficulty is to read and write at the same time. I'm almost certain that using SSockets, I would have to create one socket for writing and one for reading, separately by threads. Thank you! * https://bitbucket.org/silvioprog/tcpipcomp (this repo is temporary, and this all code can undergo drastic changes at any time) -- 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] Re: Odyssey: SSockets and Threads.
2013/4/24 silvioprog silviop...@gmail.com Hello, There are a multi-thread example using SSockets in FPC? I'm trying to implement it*, but it's very hard and this work it's consuming all my time. The difficulty is to read and write at the same time. I'm almost certain that using SSockets, I would have to create one socket for writing and one for reading, separately by threads. Thank you! * https://bitbucket.org/silvioprog/tcpipcomp (this repo is temporary, and this all code can undergo drastic changes at any time) ... like ScktComp of Delphi. (no Synapse, LNet or Indy please, I need to use native code) -- 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
Re: [fpc-pascal] Simple beep sound Linux
On Wed, April 24, 2013 19:42, Rainer Stratmann wrote: How to program a simple beep in Linux. Now I have a mainboard which has a speaker, but needs to program using the sound device, I guess. Crt sound() does not work in this case. Is there another solution as easy as sound() in the crt unit? If talking about a simple console application not using unit Crt, you can issue a beep using Write (#7). Google helps you in finding various gotchas/limitations of this solution though (this topic has been discussed before, search for FPC, Linux, SysUtils.Beep and Write (#7)). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] SSockets and write/read simultaneously...
Hello guys, The classes of SSockets allow to use write and read simultaneously? (eg. Gtalk/Skype send messages even receiving a attached file) Please excuse if the question is silly, I even got to do a test, but I wanted to know because I need to implement a multi-platform code, using write/read simultaneous in a socket. Thank you veru much again! -- 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
