Re: [fpc-pascal] re-engineering tool

On Mon, 2018-01-08 at 15:21 +0200, Juha Manninen wrote: > On Sat, Jan 6, 2018 at 11:46 AM, Marc Santhoff > wrote: > > Since I'm confronted with the task of analyzing a pile of object > > pascal > > sources I'd like to know: > > > > Is there any tool that can help me? > > > > Automatically genera

Re: [fpc-pascal] re-engineering tool

On Mon, 2018-01-08 at 08:35 +0100, Marc Santhoff wrote: > On Sat, 2018-01-06 at 18:01 +0100, Marco van de Voort wrote: > > In our previous episode, Marc Santhoff said: > > > Since I'm confronted with the task of analyzing a pile of object > > > pascal > > > sources I'd like to know: > > > > > > Is

Re: [fpc-pascal] re-engineering tool

On 08/01/18 13:30, Juha Manninen wrote: On Sat, Jan 6, 2018 at 11:46 AM, Marc Santhoff wrote:> Since I'm confronted with the task of analyzing a pile of object pascal> sources I'd like to know:>> Is there any tool that can help me?>> Automatically generating a visual class diagram having uses

Re: [fpc-pascal] re-engineering tool

On Sat, Jan 6, 2018 at 11:46 AM, Marc Santhoff wrote: > Since I'm confronted with the task of analyzing a pile of object pascal > sources I'd like to know: > > Is there any tool that can help me? > > Automatically generating a visual class diagram having uses and > aggregation of other classes wou

Re: [fpc-pascal] re-engineering tool

On Sat, 2018-01-06 at 18:01 +0100, Marco van de Voort wrote: > In our previous episode, Marc Santhoff said: > > Since I'm confronted with the task of analyzing a pile of object > > pascal > > sources I'd like to know: > > > > Is there any tool that can help me? > > I've used Peganza's pascal anal

Re: [fpc-pascal] re-engineering tool

In our previous episode, Marc Santhoff said: > Since I'm confronted with the task of analyzing a pile of object pascal > sources I'd like to know: > > Is there any tool that can help me? I've used Peganza's pascal analyser in the past, for D7 code. I haven't used it in a while though. _

[fpc-pascal] re-engineering tool

Hi! Since I'm confronted with the task of analyzing a pile of object pascal sources I'd like to know: Is there any tool that can help me? Automatically generating a visual class diagram having uses and aggregation of other classes would be very helpful. Any hints? TIA, Marc -- Marc Santhoff

[fpc-pascal] Re Raise Exception

Hi all, I'm having problems with an application on a client with random A/V's. In order to understand what is going on, I wrote a simple web service client for my mantis tracker using wst, which works well and with the use of the information's from the wiki ( http://wiki.freepascal.org/Logg

[fpc-pascal] Re: Very odd case parsing problem

> No, that shows a semicolon separating successive cases, not terminating each one Right, sorry I misinterpret "separate" with "terminate". -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Very-odd-case-parsing-problem-tp5717723p5717731.html Sent from the Free

Re: [fpc-pascal] Re: Very odd case parsing problem

Am 29.12.2013 09:10 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > leledumbo wrote: >>> >>> I can fix that either by putting a semicolon before the else- which I >> >> believe is strictly incorrect >> >> Nope, that's correct. Take a look at the syntax diagram for case statem

Re: [fpc-pascal] Re: Very odd case parsing problem

leledumbo wrote: I can fix that either by putting a semicolon before the else- which I believe is strictly incorrect Nope, that's correct. Take a look at the syntax diagram for case statement here: http://www.freepascal.org/docs-html/ref/refsu50.html As you can see, each "case" is terminated b

[fpc-pascal] Re: Very odd case parsing problem

> I can fix that either by putting a semicolon before the else- which I believe is strictly incorrect Nope, that's correct. Take a look at the syntax diagram for case statement here: http://www.freepascal.org/docs-html/ref/refsu50.html As you can see, each "case" is terminated by ";". From the pa

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

Am 27.12.2013 11:22 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Reinier Olislagers wrote: >> >> On 27/12/2013 10:17, Lukasz Sokol wrote: >>> >>> On 26/12/13 12:13, Reinier Olislagers wrote: On 26/12/2013 13:09, Dennis Poon wrote: Search the archives for pro

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

Dennis Poon wrote: For what it's worth, I'm ambivalent. Not because I feel that try stacks couldn't or shouldn't be simplified, but because I feel that whoever overloaded try for two different structures should be shot. I don't know enough about compiler. Could you kindly elaborate on the a

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

For what it's worth, I'm ambivalent. Not because I feel that try stacks couldn't or shouldn't be simplified, but because I feel that whoever overloaded try for two different structures should be shot. I don't know enough about compiler. Could you kindly elaborate on the above please? D

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

Am 2013-12-27 11:22, schrieb Mark Morgan Lloyd: but because I feel that whoever overloaded try for two different structures should be shot. Yes, that's what I thought too as I discovered this long ago. I think this is yet another cuckoo's egg from Borland/Embacadero...

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

Reinier Olislagers wrote: On 27/12/2013 10:17, Lukasz Sokol wrote: On 26/12/13 12:13, Reinier Olislagers wrote: On 26/12/2013 13:09, Dennis Poon wrote: Search the archives for proposals for syntax like this that didn't lead to anything. It did lead exactly to Sven Ah yes, you're right that

Re: [fpc-pascal] Re: how to simplify try try except end finally end?

On 27/12/2013 10:17, Lukasz Sokol wrote: > On 26/12/13 12:13, Reinier Olislagers wrote: >> On 26/12/2013 13:09, Dennis Poon wrote: >> Search the archives for proposals for syntax like this that didn't lead >> to anything. >> >> > It did lead exactly to Sven Ah yes, you're right that *is* progress

[fpc-pascal] Re: how to simplify try try except end finally end?

On 26/12/13 12:13, Reinier Olislagers wrote: > On 26/12/2013 13:09, Dennis Poon wrote: >> It seems possible in Java and C# but not in FPC. >> Is there a way to combine them like > > No. > Search the archives for proposals for syntax like this that didn't lead > to anything. > > It did lead exactl

[fpc-pascal] Re: how to simplify try try except end finally end?

On 26/12/2013 13:09, Dennis Poon wrote: > It seems possible in Java and C# but not in FPC. > Is there a way to combine them like No. Search the archives for proposals for syntax like this that didn't lead to anything. ___ fpc-pascal maillist - fpc-pas

Re: [fpc-pascal] Re: Re: Announcing PUMA Repository (Ralf Quint) (waldo kitty)

On 16 Dec 2013, at 21:32, Johannes W. Dietrich wrote: > Your MIME decoding URL is in fact valuable. However, it is still nasty that > it is required to manually decode messages - be it a bug in the mail reader, > the list processor or the sending application... As mentioned before, please move

[fpc-pascal] Re: Re: Announcing PUMA Repository (Ralf Quint) (waldo kitty)

Your MIME decoding URL is in fact valuable. However, it is still nasty that it is required to manually decode messages - be it a bug in the mail reader, the list processor or the sending application... Best, Johannes -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Re: [fpc-pascal] Re: Announcing PUMA Repository (Ralf Quint)

On 12/15/2013 3:06 PM, Johannes W. Dietrich wrote: A proper email client (instead of Apple Mail) would be a good start... ;-) Ralf Apple Mail doesn't seem to be the only software that doesn't know what to do with this type of encoded data. The problem seem to affect the list processor, too. Se

[fpc-pascal] Re: Announcing PUMA Repository (Ralf Quint)

A proper email client (instead of Apple Mail) would be a good start... ;-) Ralf Apple Mail doesn't seem to be the only software that doesn't know what to do with this type of encoded data. The problem seem to affect the list processor, too. See http://lists.freepascal.org/lists/fpc-pasca

[fpc-pascal] Re: Announcing PUMA Repository (Ralf Quint)

A proper email client (instead of Apple Mail) would be a good start... ;-) Ralf Apple Mail doesn't seem to be the only software that doesn't know what to do with this type of encoded data. The problem seem to affect the list processor, too, See http://lists.freepascal.org/lists/fpc-pasca

Re: [fpc-pascal] Re: Announcing PUMA Repository (waldo kitty)

On 12/14/2013 9:28 AM, Johannes W. Dietrich wrote: Thanks again! assuming you are thanking me for pointing you to the mime decoding site, you are welcome... if that's not what you are thanking me for, i don't have any idea but you are welcome (still) ;) J. W. D. Am 14.12.2013 um 12:00 sch

[fpc-pascal] Re: Announcing PUMA Repository (waldo kitty)

Thanks again! J. W. D. Am 14.12.2013 um 12:00 schrieb fpc-pascal-requ...@lists.freepascal.org: Re: Announcing PUMA Repository (waldo kitty) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Dr. Johannes W. Dietrich, M.D. -- Laboratory XU44, Endocrine Research

Re: [fpc-pascal] Re: MD5 decryption?

Reinier Olislagers wrote: Please don't take this as an insult, but make sure you don't design/implement any password/encryption schemes if you don't know what you're doing... Most people who /do/ know what they're doing shouldn't try to design encryption or hashing schemes, although it must b

[fpc-pascal] Re: MD5 decryption?

On 11/12/2013 18:08, silvioprog wrote: > Ah ha... I haven't seen this detail. xD > > Phew, I was thinking it would be possible to know the hidden text in a hash. > TBH: it seems you don't know very much about encryption. Please don't take this as an insult, but make sure you don't design/impleme

[fpc-pascal] Re: MD5 decryption?

On 11/12/2013 17:41, silvioprog wrote: > How to decrypt a MD5 in FPC?: > You're not supposed to. MD5 is a one way hash function. Otherwise use rainbow tables, brute force attack etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://li

[fpc-pascal] Re: Is this behavior related to calling convention?

Nope, calling convention only specifies parameter passing order, not parameter evaluation order. If you want to specify exactly how the parameters are evaluated, put each in a local variable first, according to your order needs. -- View this message in context: http://free-pascal-general.104571

Re: [fpc-pascal] RE: Minimal telnet server

And I know that Mystic BBS also has telnet server code in it as well. On 12/05/2013 06:49 AM, Hartmut Eilers wrote: Hallo Mark, I have a minimal telnet server in my Projekt OpenMSR. Information about OpenMSR on the webpage at www.openmsr.org . The source is hosted at sf.

[fpc-pascal] Re: cannot read /sys/class/net/eth1/address even as root user on linux

On 05/12/13 14:42, Dennis Poon wrote: > >> While your method should work if that file actually exists, you >> probably want to use libudev for enumerating and getting device >> information from sysfs. libudev will also enable you to get >> hotplug notification. >> >> > For your your reply. The

[fpc-pascal] RE: Minimal telnet server

Hallo Mark, I have a minimal telnet server in my Projekt OpenMSR. Information about OpenMSR on the webpage at www.openmsr.org. The source is hosted at sf. If you check it out you find the telnet server in the directory DeviceServer. Check the code in DeviceServer.pas for usage. Kind regards Hartm

Re: [fpc-pascal] Re: Objects in dynamic arrays

On Thu, November 28, 2013 09:03, Sven Barth wrote: > Am 28.11.2013 08:33, schrieb Andreas Schneider: >> Maybe a bit late, but that might not be true. If Timothy really talks >> about _object_ (and not _class(TObject)_) it should work as he does >> it. Also Destroy would probably be appropriate. Jus

Re: [fpc-pascal] Re: Objects in dynamic arrays

Am 28.11.2013 08:33, schrieb Andreas Schneider: Maybe a bit late, but that might not be true. If Timothy really talks about _object_ (and not _class(TObject)_) it should work as he does it. Also Destroy would probably be appropriate. Just saying :-) The actual type defs used are missing. Unli

Re: [fpc-pascal] Re: Objects in dynamic arrays

On Saturday, November 16, 2013, at 02:36 Martin wrote: > On 16/11/2013 01:03, Timothy Groves wrote: >> >> Here's the code I *actually* have in the method: >> >> var >> index, >> last : integer; >> begin >> last := length (t_volumes) - 1; >> index := 0; >> while ((t_volumes [index] <> t_cu

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

1. perhaps their system is finding the wrong sources? No. 2. i wonder what their command line is? make clean all CPU_TARGET=i386 3. i wonder what the version output of their /home/deskx/Aplicativos/fpclaz /bin/ppc386 is? FPC 2.6.3 - Rev 26119 4. is the compiler in #3 their 64bit->32bit crosscom

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

On 24 Nov 2013, at 15:27, leledumbo wrote: > Seems like your compiler is buggy, my trunk compiler has no problem there > though so you might want to try updating your compiler. He's using 2.6.3, not trunk. Jonas ___ fpc-pascal maillist - fpc-pascal

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

On 11/24/2013 9:27 AM, leledumbo wrote: Seems like your compiler is buggy, my trunk compiler has no problem there though so you might want to try updating your compiler. is that the trunk *crosscompiler* for linux 64bit -> linux 32bit? just trying to point out the OP's specifics... 1. perhaps

[fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

Seems like your compiler is buggy, my trunk compiler has no problem there though so you might want to try updating your compiler. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Cross-Compile-treefilteredit-pas-60-60-Error-Illegal-expression-tp5717560p5717568.h

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

Well, sorry, but my enviroment, and my problem, is with this: Environment: Ubuntu 13.10 64bits FPC 2.6.3 - Rev 26119 Lazarus 1.2RC - Rev 43472 Compiling from Linux 64 bits for Linux 32 bits. I really thank you for participating, but I seek information in the scenario that I posted. 2013/11/24

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

On Sun, Nov 24, 2013 at 1:00 PM, Osvaldo Filho wrote: > TBranchList = specialize TFPGObjectList; // line 60 The syntax is perfectly valid and compiles fine here with FPC 2.6.2. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://l

Re: [fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

procedure Clear; end; * TBranchList = specialize TFPGObjectList;* // line 60 { TTreeFilterEdit } TTreeFilterEdit = class(TCustomControlFilterEdit) private 2013/11/24 leledumbo > Please include the respective line. In my trunk source, it's a valid > generic > specialization. That

[fpc-pascal] Re: Cross Compile : treefilteredit.pas(60, 60) Error: Illegal expression

Please include the respective line. In my trunk source, it's a valid generic specialization. That point has > as closing bracket of generic type name. Either your compiler is buggy or you accidentally change the source. -- View this message in context: http://free-pascal-general.1045716.n5.nabb

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark ... many thanks. Your last comment prompted me to avoid using Write/Writeln to monitor what was happening. By removing Write/Writeln from the threads , ... everything works correctly with two threads , one running on core1 and the other thread running on core2. I think this boils down to the

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: "... The critical sections you are using only protect each thread against itself, meaning they basically do nothing. Being inside a critical section is not a guarantee that you won't get preempted, but just that no other threads can enter the same section. ..." The two threads do no

[fpc-pascal] Re: GetAffinity\SetAffinity

"... The critical sections you are using only protect each thread against itself, meaning they basically do nothing. Being inside a critical section is not a guarantee that you won't get preempted, but just that no other threads can enter the same section. ..." The two threads do not share and var

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Am 22.11.2013 19:17 schrieb "Jeppe Græsdal Johansen" : > Your code is broken. > > You are using the console output from two threads simultaneously without proper locking. That's most likely what's causing the crash. (Disclaimer: I haven't looked at the code, so I'm just assuming that he's using Wr

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Den 22-11-2013 16:21, Brian skrev: Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

[fpc-pascal] Re: Is the GIT repository updated?

That repo is maintained by Graeme and seems like it doesn't have autosync feature, so it's up to Graeme when to synchronize with main repository (svn). -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Is-the-GIT-repository-updated-tp5717545p5717551.html Sent fro

[fpc-pascal] Re: GetAffinity\SetAffinity

Attached binary executables which run on Ubuntu 12.04lts , but should be portable. coret_ok sets the process and two threads to core1 coret_fail sets to process to cores1 and 2 , one thread to core 1 and one thread to core 2. It soemtimes runs ok , but usually fails with a GP fault. coret_ok

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Attached is a simple test program with two threads. When the threads run , one displays '+' and the other displays '2'. If both threads run on the same core , the threads work , but if the threads are set to different cores , it generates a GP fault. If anyone is interested , downl

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark , Thanks for the tips and info. There are two reasons for running threads on specific cores : 1) The possible need for a tight loop for receiving serial data. 2) The program is serial in nature receiving data, does not use X11 , controls the mouse and keyboard using libusb , and writes dir

[fpc-pascal] Re: GetAffinity\SetAffinity

Attached is a simple test program with two threads. When the threads run , one displays '+' and the other displays '2'. If both threads run on the same core , the threads work , but if the threads are set to different cores , it generates a GP fault. If anyone is interested , download the code .

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Mark, All the documentation seems to indicate that processes and threads are treated alike in Linux , Remember that historically, there were two different threading models: LinuxThreads, where a thread was implemented as a process, and the newer NPTL. Somewhere I've got code tha

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark, All the documentation seems to indicate that processes and threads are treated alike in Linux , however , even having established that I can apparently select a core to run a thread , I haven't yet been able to make it work. I explain the findings from a dual core Intel CPU. Using the sche

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: After a bit of research , the issue of setting the cpu affinity has been solved , which may be of use to other folks. A bit of info here concerning the data type cpu_set_t , which as far as I can determine (no help from the mess that is the c library source) is essentially an array

[fpc-pascal] Re: GetAffinity\SetAffinity

After a bit of research , the issue of setting the cpu affinity has been solved , which may be of use to other folks. A bit of info here concerning the data type cpu_set_t , which as far as I can determine (no help from the mess that is the c library source) is essentially an array of DWORD. For m

[fpc-pascal] Re: virtual method and generics

2013/11/19 Xiangrong Fang > > Now I have a problem. CALL#1 is virtual as expected (sub-class's OnRestore > is called), but CALL#2 is not virtual, it just call the (empty) OnRestore > method defined in TTree. > > How to solve this problem? > BTW, this also does NOT solve the problem: TSelfType(n

[fpc-pascal] Re: ibase package

On 18/11/2013 12:05, Antonio Fortuny wrote: > So far so good. When I install the program in another Linux box, running > Firebird 2.1, the program complains that > "Can not load default Firebird clients ("libfbclient.so.2.5" or > "libgds.so" or "libfbembed.so.2.5")". Looks normal as this Linux box

[fpc-pascal] Re: GetAffinity\SetAffinity

Request for additional info : do_Syscall(syscall_nr_sched_setaffinity,fpgetpid,setsize,@cpu_set); The function do_SysCall() Arg 4 expects longint not a pointer but even when typecast do_SysyCall() doesn't appear to work. ... a good description here. http://www.ibm.com/developerworks/linux/

Re: [fpc-pascal] Re: Objects in dynamic arrays

On 16 Nov 2013, at 02:36, Martin wrote: > On 16/11/2013 01:03, Timothy Groves wrote: >> [last].Destroy; > > destroys the object pointed to by both: t_volumes [last] and t_volumes [index] > > You should have destroyed t_volumes [index] *before* copying the value And you should call Free inste

Re: [fpc-pascal] Re: Objects in dynamic arrays

On 16.11.2013 02:03, Timothy Groves wrote: This produces bad results, as it currently sits. What am I doing wrong? Here's the code I *actually* have in the method: var index, last : integer; begin last := length (t_volumes) - 1; index := 0; while ((t_volumes [index] <> t_current

Re: [fpc-pascal] Re: Objects in dynamic arrays

On 16/11/2013 01:03, Timothy Groves wrote: Here's the code I *actually* have in the method: var index, last : integer; begin last := length (t_volumes) - 1; index := 0; while ((t_volumes [index] <> t_current_volume) and (index < last)) do inc (index); if (index < last) then be

[fpc-pascal] Re: Objects in dynamic arrays

On 13-11-15 07:57 PM, Timothy Groves wrote: How exactly are instantiated classes treated in an array? Can I copy one into another? And if I unallocate an array member, does it automatically Destroy the object? I have objects stored in a dynamic array, and I want to delete an arbitrary recor

[fpc-pascal] Re: GetAffinity\SetAffinity

Alexey Voytsehovich wrote > Just a huge thank you:) > > 2011/1/21 < > michael.vancanneyt@ > >: >> >> >> See >>  man sched_setaffinity >> for the call to do this. >> >> Free Pascal does not have this call predefined, but you can make this >> call. >> >> >> Using the do_syscall you should be able

[fpc-pascal] Re: paszlib problem: integer overflow

On 14/11/2013 13:00, Dennis Poon wrote: > Dennis Poon wrote: >> I downloaded the Paszlib-sg from >> http://sagsehome.net/oss/paszlib-sg.php (as suggested by Paszlib >> freepascal.org wiki). Which URL exactly? paszlib-sg doesn't seem to be mentioned in http://wiki.freepascal.org/paszlib ... > Is a

[fpc-pascal] Re: Move with pointers to memory

> Is there a description of the behaviour of const and var in this case? Not so clear: http://www.freepascal.org/docs-html/ref/refsu59.html A ltle bit clearer: http://docwiki.embarcadero.com/RADStudio/XE5/en/Parameters_(Delphi)#Untyped_Parameters > Why is it not both const or both var? If t

[fpc-pascal] Re: "identifier not found" case probelm

On 12/11/13 16:27, leledumbo wrote: >> I have a feeling this 'returns' may be a keyword... > > No, it is not, I believe. Reserved words are listed in the docs. > Yeah, I checked too, 'returns' isn't a keyword. -ENOCRYSTALBALL but /maybe/ the 'returns' is declared 'under' the code in question s

[fpc-pascal] Re: "identifier not found" case probelm

> I have a feeling this 'returns' may be a keyword... No, it is not, I believe. Reserved words are listed in the docs. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/identifier-not-found-case-probelm-tp5717460p5717471.html Sent from the Free Pascal - General

[fpc-pascal] Re: "identifier not found" case probelm

On 10/11/13 10:54, rambo waz here wrote: > at the moment i have a case where each choice leads off to a procedure. .. > looks like this > repeat > writeln('Main Menu'); > writeln('1. New Customer Info'); > writeln('2. Withdrawal'); > writeln('3. Returns'); > writeln('4. Money ow

[fpc-pascal] Re: "identifier not found" case probelm

The compiler does say which identifier is not found, doesn't it? -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/identifier-not-found-case-probelm-tp5717460p5717461.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___

[fpc-pascal] Re: FpHttpServer and DaemonApp does not works on Linux

2013/11/7 silvioprog > 2013/11/7 silvioprog > >> Hello, >> >> I'm trying to use a HTTP server with daemon on Linux, but, it does not >> works. I did a project that is working perfectly well on Windows, but on >> Linux, although the service is successfully installed, it does not starts >> the HTT

[fpc-pascal] Re: FpHttpServer and DaemonApp does not works on Linux

2013/11/7 silvioprog > Hello, > > I'm trying to use a HTTP server with daemon on Linux, but, it does not > works. I did a project that is working perfectly well on Windows, but on > Linux, although the service is successfully installed, it does not starts > the HTTP server. > > I followed this tu

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Tue, Nov 5, 2013 at 12:10 PM, leledumbo wrote: >> The packages are defined using directories. Is Java a mess too? > > Yes, exactly, that's what makes Java package system messy. It makes > refactoring (or restructurization) extremely difficult for deep package > hierarchy. So I proposed somethi

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Tue, 5 Nov 2013 07:10:21 -0800 (PST) leledumbo wrote: > > The packages are defined using directories. Is Java a mess too?  > > Yes, exactly, that's what makes Java package system messy. It makes > refactoring (or restructurization) extremely difficult for deep package > hierarchy. Java has

[fpc-pascal] Re: [Bulk] Re: Namespaces Support

> The packages are defined using directories. Is Java a mess too?  Yes, exactly, that's what makes Java package system messy. It makes refactoring (or restructurization) extremely difficult for deep package hierarchy. On Tuesday, November 5, 2013 6:37 PM, Marcos Douglas [via Free Pascal - Ge

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 10:44 PM, Dmitry Boyarintsev wrote: > On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas wrote: >> >> Sorry, but this is boring. >> Do you not agree that is much better propose a solution to be possible >> to use two -- or more -- units that have the same name but works >> toge

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas wrote: > Sorry, but this is boring. > Do you not agree that is much better propose a solution to be possible > to use two -- or more -- units that have the same name but works > together at the same project? Thought process is a boring thing in natu

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 1:31 PM, Dmitry Boyarintsev wrote: > On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas wrote: >> >> On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev >> wrote: >> > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote: >> >> >> >> 2- If ExtraUtils depends on StrUtils.pas

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas wrote: > On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev > wrote: > > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote: > >> > >> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is > >> not a subdirectory of lib then th

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev wrote: > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote: >> >> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is >> not a subdirectory of lib then the "otherlib needs to be compiled >> using a ALIAS: >> -ALIAS=TheLib@l

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote: > 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is > not a subdirectory of lib then the "otherlib needs to be compiled > using a ALIAS: > -ALIAS=TheLib@lib\* > Ah, yes, you've mentioned the necessity for two steps compila

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 10:45 AM, Dmitry Boyarintsev wrote: > On Mon, Nov 4, 2013 at 8:07 AM, Marcos Douglas wrote: >> >> >> First, if you have a lib that have dependencies to another lib, you >> >> have to provide all sources together -- in the same directory or >> >> subdirectories. For this ca

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Mon, Nov 4, 2013 at 8:07 AM, Marcos Douglas wrote: > >> First, if you have a lib that have dependencies to another lib, you > >> have to provide all sources together -- in the same directory or > >> subdirectories. For this case just use the rule #1. > >> But, if you did not provide the sourc

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sun, Nov 3, 2013 at 10:22 PM, Dmitry Boyarintsev wrote: > On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas wrote: >> >> Wrong. Do not breaks the compiler backward compatibility. >> I said " in the same directory and/or own tree", ie, in the same >> directory and subdirectories. For these cases,

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas wrote: > Wrong. Do not breaks the compiler backward compatibility. > I said " in the same directory and/or own tree", ie, in the same > directory and subdirectories. For these cases, the compiler do not > need changes. > The compiler doesn't use a u

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sun, Nov 3, 2013 at 1:25 PM, Marco van de Voort wrote: > In our previous episode, Benito van der Zander said: >> > Then the John Douglas and Douglas McKey are running into the same issue. >> > Both guys (while living on different parts of the world) created the >> > same "douglas" namespace! >>

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sun, Nov 3, 2013 at 12:06 AM, Dmitry Boyarintsev wrote: > On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote: >> >> On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev >> wrote: >> > >> > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote: >> >> This works only if you don't want use Str

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

In our previous episode, Benito van der Zander said: > > Then the John Douglas and Douglas McKey are running into the same issue. > > Both guys (while living on different parts of the world) created the > > same "douglas" namespace! > > That's why most languages use domains as namespace > Then yo

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

Then the John Douglas and Douglas McKey are running into the same issue. Both guys (while living on different parts of the world) created the same "douglas" namespace! That's why most languages use domains as namespace Then you would have net.delfire.douglas.* org.msegui.* and no collision

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote: > On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev > wrote: > > > > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote: > This works only if you don't want use StrUtils of your project and, > IMHO, this is more complex solution. You wi

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sat, Nov 2, 2013 at 7:44 PM, Dmitry Boyarintsev wrote: > On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote: >> >> > compiling with >> > fpc -ALIAS /lib/* TheLib >> > >> > won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils >> >> Well, is more common to use just ppu files

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote: > > compiling with > > fpc -ALIAS /lib/* TheLib > > > > won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils > > Well, is more common to use just ppu files to not compile these files > every compilation. So, the Lib was alrea

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev wrote: > > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote: >> >> On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev >> wrote: >> > Technical problem: >> > * a unit name collision of two independent library code. Either library >> > are >

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

Hmm, let me extend your example: /project/unit1.pas /project/StrUtils.pas /lib/StrUtils.pas /lib/ExtraUtils.pas ---code--- unit ExtraUtils; uses StrUtils; // assumed library StrUtils, not project ===code=== However, since StrUtils is present in project directory, it will be used instead, causin

Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support

On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev wrote: > Technical problem: > * a unit name collision of two independent library code. Either library are > using unit with the same name. The code in the conflicting units is > different. Thus one library should use its own unit, the other shoul

  1   2   3   4   5   6   7   8   9   10   >