Re: [fpc-devel] bounty: FPC based debugger

I see no problems with the idea of creating another debugger, especially if written in FPC. Since there're plenty of the GDB-wrappers already! And it's also a good option to support either ways: "over-gdb" and "native". In fact, I've been planning to add "GDB" target into Duby, together with native

Re: [fpc-devel] bounty: FPC based debugger

On Tue, Sep 13, 2011 at 10:03 PM, Paul Ishenin wrote: > 14.09.2011 9:21, dmitry boyarintsev wrote: > How would you estimate the costs of this task? Would you take it if we > collect some good sum of money or do work for a full day now? It's not just 1 task. These are multiple task

Re: [fpc-devel] bounty: FPC based debugger

On Wed, Sep 14, 2011 at 6:48 AM, Michael Schnell wrote: > IMHO, if we really can work with the gdb team on feeding the necessary > Object-Pascal specific add-ons into gdb, creating a new debugger from > scratch does not make any sense at all. That's true. The only thing concerns me about that, is

Re: [fpc-devel] bounty: FPC based debugger

On Thu, Sep 15, 2011 at 3:34 AM, Michael Schnell wrote: > Yak ! > Is a reunification in progress ? I'd ask on Apple-dev-maillist, gdb-maillist, gnu-maillist or Jonas :) 2 Graeme: thanks for your hard work! I could definitely use code clean-ups. thanks, Dmitry

Re: [fpc-devel] Little feature teaser

Does a debugger understands that? On Friday, August 2, 2013, Sven Barth wrote: > Hello together! > > Just a little feature teaser what I'm currently working on when I find the > time. :) > > === source begin === > > program tgenfuncs; > > {$modeswitch result} > > generic function IsIn(aElement: T

Re: [fpc-devel] Internal assembler: tai_directive usage

On Mon, Nov 9, 2009 at 1:59 PM, Jonas Maebe wrote: > If some of these directives simply create a new section, then the directives > can be removed and everywhere they are currently used in the compiler you > can create the appropriate section instead (you can submit this in a > separate patch). r

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Mon, Nov 9, 2009 at 6:30 PM, Martin Schreiber wrote: > WideString could be reference counted on all platforms and the current not > reference counted Windows WideString could be renamed to OLEString in order > applications which don't need different encodings in strings don't suffer > from the

[fpc-devel] darwin indirect symbols

Hello Jonas, There're 2 ways to define indirect symbol by the compiler: tai_const with type aitconst_indirect_symbol or tai_directive with asd_indirect_symbol either way produces identical assembler output: .indirect_symbol %symbol_name So i'm wondering, what was the reason to separate them the

Re: [fpc-devel] darwin indirect symbols

On Tue, Nov 10, 2009 at 3:50 PM, Jonas Maebe wrote: > I think simply that I forgot that one way was already available when I added > the other way :) It's fine to remove either one. hmm... I'll try to make the patch. thanks, dmitry ___ fpc-devel mailli

Re: [fpc-devel] darwin indirect symbols

On Tue, Nov 10, 2009 at 3:53 PM, dmitry boyarintsev wrote: > hmm... I'll try to make the patch. here's the one: http://bugs.freepascal.org/view.php?id=15050 Removing tai_const with indirect_symbol doesn't seem to harm the generated asm code at all, at least for i386 targe

Re: [fpc-devel] Save the current FPC UnicodeString!

On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl wrote: > Ansistring: system encoding > RawByteString: variable encoding, cannot be checked at compile time, > when working with RawByteStrings, you've to take care of the newly > introduced encoding field Let's say there's a library that works wit

Re: [fpc-devel] Save the current FPC UnicodeString!

On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl wrote: > Well, an ansistring has an implicit encoding: system. This won't change > and if one uses only unicodestrings and ansistrings, no change will be > noticed. Thanks. It's always nice to hear "No changes required" :) > No, because it would

Re: [fpc-devel] Save the current FPC UnicodeString!

On Fri, Nov 13, 2009 at 12:55 AM, Florian Klaempfl wrote: > Well, I guess you're talking about lazarus ;) I don't see yet however, > if and how the ansistring abuse in the lcl will bite one ... not really. But it's good to know that LCL is safe as well :) thanks, dmitry __

[fpc-devel] FPC tests

hello FPC-developers, I've added the internal i386-darwin assembler to FPC. It seems to work fine on my small tests, but I'm having problems using FPC tests. $ make TEST_FPC=~/modcompiler/i386/pp make -C utils utils make -C units FPC_VERSION= FPC=/Users/dmitry/modcompiler/i386/pp CPU_TARGET=is OS

Re: [fpc-devel] FPC tests

On Sun, Nov 15, 2009 at 5:11 PM, Jonas Maebe wrote: > because you are somehow registering two assemblers with the same id (maybe > you used the same id as the external Darwin assembler?) yes i did... fixed now! thanks a lot! ___ fpc-devel maillist -

Re: [fpc-devel] Record with dynamic array of same type

On Wed, Dec 9, 2009 at 5:22 PM, Jonas Maebe wrote: > I guess it should be possible to give an error similar to what Kylix does: >  tt.pp(9) Error: Type 'TMyRecord' is not yet completely defined if dynamic arrays are actually pointers, why the record should not be completely defined? Isn't using d

Re: [fpc-devel] Record with dynamic array of same type

On Wed, Dec 9, 2009 at 5:48 PM, Jonas Maebe wrote: > I don't know why Kylix refuses it. It's true that in theory it could be > compilable (and apparently some very old FPC version did and very new Delphi > version does compile it). It seems that it's "fixed" in 2010 only, because the structure can

[fpc-devel] access vialoation while rebuilding compiler

Hello All I've been trying to modify the patch: http://bugs.freepascal.org/view.php?id=15163 so it can be accepted. But I've ran into a strange bug. I'm using r14593 compiler + int_asm_darwin.patch applied (from the link above). Go to ogbase.pas and comment or erase "indirect : string;"(line 152

Re: [fpc-devel] access vialoation while rebuilding compiler

On Sun, Jan 10, 2010 at 4:23 PM, Florian Klaempfl wrote: > Could you use a compiler with line info? make OPT="-g -gl"? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] access vialoation while rebuilding compiler

On Sun, Jan 10, 2010 at 4:23 PM, Florian Klaempfl wrote: > > Could you use a compiler with line info? here you go: Compiling symdef.pas Fatal: Compilation aborted An unhandled exception occurred at $00011AD5 : EAccessViolation : Access violation $00011AD5 fpc_shortstr_to_shortstr, line 684 o

Re: [fpc-devel] access vialoation while rebuilding compiler

After cleaning all units manually, the compiler can built. But if i change anything in TObjSymbol interface again, the compiler is unable to re-use files and fails with the same error thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.

Re: [fpc-devel] user problems with fcl-res. need assistance

Maybe StringToPPChar should be fixed instead? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Semicolon before else

On Fri, Jan 29, 2010 at 2:08 PM, Marco van de Voort wrote: > I don't really see a need for this. Some languages are terminator, some are > separator. We are also not Basic in that we try to disambiguate every > possible syntax. > > It is just a risk without real benefit attached to it, so I'm agai

[fpc-devel] RTL and Unicode filenames operations.

Hello, FPC developers Any hints on these bugs? http://bugs.freepascal.org/view.php?id=12923 http://bugs.freepascal.org/view.php?id=15642 // patch proposed to workaround RTL limitation in LCL This is mostly concern of Windows OS. Moders Unix doesn't have the problem, usually having UTF8 as their's

Re: [fpc-devel] RTL and Unicode filenames operations.

On Mon, Feb 1, 2010 at 11:01 AM, Marco van de Voort wrote: > What would you do on Unix? Any solution must be platform-wide. I'm not talking about removing Ansi functions. I'm talking about the possibility of adding Unicode function equivalents. For Unix unicode functions would simply call Ansi fu

Re: [fpc-devel] RTL and Unicode filenames operations.

On Mon, Feb 1, 2010 at 11:31 AM, Marco van de Voort wrote: > Which requires libc, and *nix supports UTF-8 directly. Now, i see, the technical solution is not easy. > The point is more or less to come up with some logical system, not just > random additions when something is missing. FPC will be

Re: [fpc-devel] RTL and Unicode filenames operations.

On Mon, Feb 1, 2010 at 11:09 AM, Graeme Geldenhuys wrote: > Alternatively you can introduce helper RTL functions. We have done similar > in fpGUI project (fpg_utils.pas unit), having functions like > fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the > standard RTL functio

Re: [fpc-devel] RTL and Unicode filenames operations.

On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort wrote: > More importantly, the stuff in the FCL depends on the RTL, so stuffing in > the FCL is useless since it would need primitives in the RTL to operate on. Does it mean, if i provide a FCL package with: unit UnicodeFileUtils; function Fi

Re: [fpc-devel] RTL and Unicode filenames operations.

Reported: http://bugs.freepascal.org/view.php?id=15795 It's up to FPC team to accept or reject the package. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTL and Unicode filenames operations.

On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: > Reject as far as I'm concerned. I'd like to see the RTL being in the system > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > RTLString. Vincent, is there a place in CCR for the run-time package? thanks, dmitry _

Re: [fpc-devel] RTL and Unicode filenames operations.

On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: > Reject as far as I'm concerned. I'd like to see the RTL being in the system > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > RTLString. > > This sets a precedent. Could you please resolve the issue with "won't be

Re: [fpc-devel] RTL and Unicode filenames operations.

Thanks Mattias, i'll do proper changes to file name comparison functions. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] FourCharCode expression for objective-p mode

Hello Developers, Jonas, would it be possible (and logical) to allow FourCharCode for objectivec1 mode s witch? Since Objective-C mode is used only on MacOSX it would be easier to declare headers that using FourChar constants. And no need to use macpas mode. thanks, dmitry ___

Re: [fpc-devel] Help with Lazarus

On Mon, Mar 1, 2010 at 1:30 PM, Jonas Maebe wrote: > I also don't think it is a good idea that Lazarus does its own packaging of > official release versions of the compiler, because that can only lead to > confusion and additional errors (as above -- now before finding out what the > problem is

Re: [fpc-devel] Help with Lazarus

On Mon, Mar 1, 2010 at 6:53 PM, Vincent Snijders wrote: > Please, create a bug report and assign it to me, so I won't forget it. Done: http://bugs.freepascal.org/view.php?id=15874 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.fr

Re: [fpc-devel] RTL and Unicode filenames operations.

Hello, The patch has been updated: http://bugs.freepascal.org/view.php?id=15795 (is it possible to allow the reporter to delete its files in FPC bug tracker?) The library is now RTL "encoding" independent. Actually it's configurable, so, if RTL string encoding changes, only a 2-3 lines in the lib

Re: [fpc-devel] RTL and Unicode filenames operations.

On Tue, Mar 9, 2010 at 1:49 PM, Marco van de Voort wrote: >> The library is now RTL "encoding" independent. Actually it's >> configurable, so, if RTL string encoding changes, only a 2-3 lines in >> the library should be changed. > > I don't know, but I can delete anything but the most recent if yo

Re: [fpc-devel] -Xg option

On Fri, Mar 12, 2010 at 6:01 AM, Paul Ishenin wrote: > One possibility is to use -Xg by default. But hence the question - whether > -Xg works reliable for all platforms? afaik, -Xg is not support on Darwin at all. Technically it can be supported for Dwarf debug only. thanks, dmitry _

Re: [fpc-devel] properties with getter evaluation in gdb

On Fri, Mar 12, 2010 at 9:43 PM, Jonas Maebe wrote: >> Are they that cheap to >> hold back such kind of information? > > I'm not aware of them being cheap in this or in other ways. Quite official, i guess: http://docwiki.embarcadero.com/RADStudio/en/Fastcall,_fastcall thanks, dmitry ___

Re: [fpc-devel] properties with getter evaluation in gdb

On Fri, Mar 12, 2010 at 10:04 PM, Jonas Maebe wrote: > Yes, but it is not the full documentation. yep. I guess is the source for the the information give at wikipedia :) Anyway, following Flávio's suggestion: https://forums.embarcadero.com/thread.jspa?threadID=34211&stqc=true thanks, dmitry ___

Re: [fpc-devel] -Amacho

On Sat, Mar 13, 2010 at 7:48 AM, Adriaan van Os wrote: > Is it useful to file bugs for -Amacho or is the feature still in > experimental state ? It is useful. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepas

Re: [fpc-devel] -Amacho

On Sat, Mar 13, 2010 at 3:27 PM, Adriaan van Os wrote: > Dmitry, you may wnt to run the testssuite with -Amacho -Cg-. Indeed. I've not tested non PIC compilation. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.fre

Re: [fpc-devel] RTL and Unicode filenames operations.

Any hints about the package? http://bugs.freepascal.org/view.php?id=15795 thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RTL and Unicode filenames operations.

On Tue, Mar 21, 2010 at 2:01 PM, Marco van de Voort wrote: > I'll reiterate my opinion that first a decision about what the working > stringtype of the RTL will be. > IMHO there is no decent solution till there is a real utf-8 type (read > cpnewstr)

Re: [fpc-devel] RTL and Unicode filenames operations.

On Sun, Mar 21, 2010 at 7:53 PM, Jonas Maebe wrote: > On Mac it's utf-8, not utf-16. At least, not as "sequence of bytes", see test1.pas of the ufiles package. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepa

Re: [fpc-devel] VAL behavior

On Tue, Mar 23, 2010 at 6:50 PM, Dariusz Mazur wrote: > Delphi set ii to 9, FPC set 0 (io is equal 2) > is this bug? Don't assume the value of ii (since it's invalid), if io <> 0 thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] var param as property index?

On Sun, May 30, 2010 at 5:29 PM, Martin wrote: > I don't think the following is intended? (it compiles with trunc). > > Note the property index is a var param > > >  TForm1 = class(TForm) >  private >    function GetFoo(var Index: Integer): Boolean; >  public >    property Foo[var Index: Integer]:

Re: [fpc-devel] "Permission denied" - /examples/hash/.svn/all-wcprops

The bug is forever. I usually delete the "examples" directory at the installation path before making. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Conditional Breakpoints using FPC and GDB

On Fri, Aug 13, 2010 at 1:31 PM, Graeme Geldenhuys wrote: > Hopefully Dmitry could solve these problems with Duby. I haven't evaluated > Duby is some months, but last time I did check, it made good progress. I > guess it's time I get another code update. No updates. Sorry. The last changes were:

Re: [fpc-devel] refcounting in fcl-passrc

If ref-counting mechanism is already implemented, i'd prefer to keep and debug it. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] refcounting in fcl-passrc

On Sun, Aug 22, 2010 at 11:32 AM, Michael Van Canneyt wrote: > And why do you want this ? refcounting is always a pain, and should be > avoided when possible. Rewriting code might produce even more bugs. I prefer to make as less changes as possible. thanks, dmitry ___

Re: [fpc-devel] refcounting in fcl-passrc

On Sun, Aug 22, 2010 at 4:27 PM, Michael Van Canneyt wrote: > We would not be rewriting the parser; merely the TPasElement nodes. > > I'll do it myself, this is not a problem. Ok then. No more refcounting. So TPasExpr classes doesn't require changes. Currently they free sub expressions instead

Re: [fpc-devel] When native debuggers?

Duby is not yet usable as a debugger. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proposed change in Objective-Pascal syntax

The idea seems fine to me. But isn't "external" a reserved word? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

On Sat, Aug 20, 2011 at 6:28 PM, Jonas Maebe wrote: > And Florian/Peter for the code generator design, that made it possible to > gradually add a high level code generator on top of it rather than having to > completely rewrite it. So there're actually 2 code generators right now. One is used f

Re: [fpc-devel] New FPC target: JVM

On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe wrote: > > On 21 Aug 2011, at 02:37, dmitry boyarintsev wrote: > >> So there're actually 2 code generators right now. One is used for JVM >> and another is used for native machine code? > > The JVM target only uses th

Re: [fpc-devel] New FPC target: JVM

On Sun, Aug 21, 2011 at 5:33 PM, Jonas Maebe wrote: > > The problems are > a) he is adding the '.class' extension when trying to run the program. You > have to specify the name of the class to run, not the name of the class file > (so leave out the '.class') > b) he should specify the base path

Re: [fpc-devel] CPPClass

On Sat, Jan 18, 2014 at 12:19 AM, Den wrote: > I'd really like to use it as I would rather write a Pascal CPPClass and > interface with a Library rather than making my own bridge library and > interfacing with that. > Shouldn't there be 2 kind of CPPClass variants? One for GNU another for MSVC.

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Sun, Feb 2, 2014 at 8:42 PM, Martin Frb wrote: > > This does not include: > ^ deref > . accessing a member of a class/record (not unary) > Are these two even considered as operators in pascal? Shouldn't [] (array-element access) be added in this case? thanks, Dmitry ___

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 10:25 AM, Martin Frb wrote: > It does not state if or if not it is an operator. And also give no > indication on its precedence, or if it is applied before or after operators. > > This is not so much about he -a^ (which is a (very) constructed case), but > about @a^ which

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 11:02 AM, Martin Frb wrote: > Parsed yes, but if it comes to evaluation, then you get {$T-} (@a)^ > "cant dereference an untyped pointer" or similar > > @a^ always works. All I was asking is if the documentation should state it > more clearly that ^ is (As part of the iden

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

http://en.wikipedia.org/wiki/FLAGS_register It's a trap (single-step) flag. to stop after each instruction. (IIRC with some exceptions). I'd think it should be AMD64 compatible. thanks, Dmitry On Mon, Mar 31, 2014 at 6:17 PM, Martin Frb wrote: > C:\FPC\SVN\fpc_2.6.4\rtl\win\wininc\defines.inc

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

at 9:58 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > http://en.wikipedia.org/wiki/FLAGS_register > > It's a trap (single-step) flag. to stop after each instruction. (IIRC with > some exceptions). > I'd think it should be AMD64 compatible. > > t

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

On Tue, Apr 1, 2014 at 1:47 PM, Martin Frb wrote: > > Anyway, If it exists for 64 bits, should/can it be added to > rtl\win\wininc\defines.inc same as it is for 32 bit? > > Imho, no. At least not in "rtl" defines. 1) it's not part of originating Windows headers (if these are used as part of RTL

[fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

Hello, The message file contains the comment (introduced in r13815) # Russian (utf-8) Language File for Free Pascal The file is in fact CP 866. This (non) issue is small enough to skip the bug tracker. thanks, Dmitry ___ fpc-devel maillist - fpc-de

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

I thought it would be good for consistency with other translation files: errorpl.msg / errorpli.msg errorhe.msg / errorheu.msg ...and sanity. Could transcoder update the comment as well? thanks, Dmitry On Tue, May 27, 2014 at 2:24 PM, Sergei Gorelkin wrote: > 27.05.2014 22:07, Dmi

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

On Tue, May 27, 2014 at 6:47 PM, Sergei Gorelkin wrote: > > Stock one (the "iconv" program) does not change contents of the file. > > Anyway, errorr.msg updated in r27819. Should sed -i 's/# Russian (utf-8)/# Russian (cp 866)/g' errorr.msg help, after iconv call? ___

Re: [fpc-devel] New targets for FPC - Windows Phone 8 and Flash

On Fri, Jul 4, 2014 at 5:07 PM, Sergio Flores wrote: > > Also, would anyone have interest in support Flash as a FPC target? > It is possible to compile C++ to .swf, so having the same capacity for FPC > would be great! > There is a open source project called FlashPascal that does exactly this, > I

Re: [fpc-devel] New targets for FPC - Windows Phone 8 and Flash

Sergio, Not sure if it helps you.There's a project of converting pascal to JavaScript. The thread about it came up just recently: http://lists.freepascal.org/pipermail/fpc-devel/2014-April/033689.html I'm sure you'd find it helpful for Pascal to ActionScript conversion. Besides, you might want to

[fpc-devel] Syntax choice (was: Blocks support)

Hello, I was curious about the proposed syntax option, why "in block" rather than just "block"? There's no "block" reserved word in FPC yet (unlike mentioned earlier Oxygen). In general "reference to" seems like a poor choice made by Embarcadero (and FPC has to follow). * using "in block" seems m

Re: [fpc-devel] Method for write string into TStreamt

How about introducing a default parameter? The parameter keeps the method backward compatible, allowing write a string without the prefix. public procedure TStream.WriteAnsiString( const S: string; withLength: Boolean = true; ); thanks, Dmitry On Mon, Jul 21, 2014 at 5:34 AM, Marco van de V

Re: [fpc-devel] Syntax choice (was: Blocks support)

On Sun, Jul 20, 2014 at 6:28 PM, Jonas Maebe wrote: > > I proposed to use "is block" because of the analogy with the already > existing "is nested". Neither "block" nor "nested" was/is/would be a > reserved word afterwards, just like many other words that have a special > meaning in one context o

Re: [fpc-devel] Method for write string into TStreamt

On Tue, Jul 22, 2014 at 6:46 AM, tha...@thaddy.com wrote: > A case for ternary computing is not really a bad idea ;) > > On 21-7-2014 21:42, Hans-Peter Diettrich wrote: > >> Dmitry Boyarintsev schrieb: >> >> How about introducing a default parameter? >>>

Re: [fpc-devel] Method for write string into TStreamt

On Tue, Jul 22, 2014 at 12:17 PM, tha...@thaddy.com wrote: > What I was a little bit more than hinting at in my previous answers is > that it is impossible for an abstract read stream to know that there's a > string to read. There is at least one higher level of implementation > necessary: one t

Re: [fpc-devel] Suggestion: reference counted objects

On Sat, Sep 20, 2014 at 3:43 PM, Boian Mitov wrote: > PS. Forgot the mention the anonymous methods – a real revolution when > you do multithreading or parallel processing. Anything else looks like joke > next to them... You can see some of my examples from interview in the > Blaise Pascal Magaz

Re: [fpc-devel] Suggestion: reference counted objects

On Tue, Sep 23, 2014 at 1:51 PM, silvioprog wrote: > On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov wrote: > >> It used to be compatible, however since we rewrote it to use anonymous >> methods, and attributes (And reduced the code to 1/4 of the original size >> in the process) ~2 years ago, the

Re: [fpc-devel] Suggestion: reference counted objects

That's exactly what I wanted to confirm - no name - for an anonymous function. I'm sure eventually the development society, will discourage the use of anonymous functions (just like unnamed constants are considered to be a bad pattern). Thus the only thing that would remain welcomed are closures -

Re: [fpc-devel] Suggestion: reference counted objects

On Tue, Sep 23, 2014 at 10:47 PM, Boian Mitov wrote: > Hmm... I have serious doubt the anonymous methods (actually referenced > objects as previously discussed) will be discouraged. > If anything they are more and more used across the majority of the > languages, as they have huge advantages. >

Re: [fpc-devel] Proof of Concept ARC implementation

On Wed, Oct 29, 2014 at 10:33 AM, wrote: > I believe that whoever came up with new strings overcomplicated it > Consider Java and C# : they do not store encoding in string variables > And NSFoundation (the foundation for Cocoa and iOS) strings do. But adding encoding was not about "what other l

Re: [fpc-devel] Proof of Concept ARC implementation

On Wed, Oct 29, 2014 at 10:38 AM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > ... about Delphi compatibility. > > That's the number two (and some times number one) reason, why FPC has to deal with the new features as ref-counting, anonymous funct

Re: [fpc-devel] Masm

On Fri, Nov 7, 2014 at 12:55 PM, Adriaan van Os wrote: > (to my astonishment Xcode even installs nasm). > > Just in case, you find this interesting: http://forum.nasm.us/index.php?PHPSESSID=sl1i7lf3upjgenov75agnkui56&topic=1972.msg8738#new ___ fpc-deve

Re: [fpc-devel] "fpc -h" and "fpc -i"

On Sat, Nov 8, 2014 at 2:15 PM, Juha Manninen wrote: > On Fri, Nov 7, 2014 at 1:13 AM, Tomas Hajny wrote: > > If you mean that FPC itself should use a JSON file for generating the > > help, that doesn't sound like a good idea to me (see below). > > I think it is a good idea if only somebody impl

Re: [fpc-devel] Masm

On Fri, Nov 7, 2014 at 11:05 PM, Adriaan van Os wrote: > I saw that and wondered if nasm can be used with FPC on Mac OS X. What is > the status of -Amacho, by the way ? > > Stalled. The same place is was 4-5 years ago. i386 only (the only hardware I had then) and no PIC support Not sure, if I'll

Re: [fpc-devel] "fpc -h" and "fpc -i"

On Sun, Nov 9, 2014 at 4:27 AM, Juha Manninen wrote: > Sorry, my bad. We had a long discussion about this subject, Mattias > thought the info about FPC options should be maintained in FPC project. I > agreed because it is quite logical and makes sense. Why should help info > about FPC options be

Re: [fpc-devel] "fpc -h" and "fpc -i"

On Wed, Nov 12, 2014 at 7:03 AM, Juha Manninen wrote: > The fact still is that "fpc -h" + a parser in Lazarus requires the > least amount of maintenance in the long run. > The help output already listed the vast majority of all options. > Is there an exclusion for "-P" option in the parser? Afte

Re: [fpc-devel] AArch64 port committed to svn trunk

On Mon, Feb 23, 2015 at 6:02 PM, Jonas Maebe wrote: > I've just committed the AArch64 (aka "ARM64") port to trunk. It > currently only supports iOS, but adding Linux support should not be > difficult. > Great news! Thank you, Jonas! ___ fpc-devel mailli

Re: [fpc-devel] AArch64 port committed to svn trunk

I've been able to get a project compile for x86-64-iphonesim. I just gave a few hints on the wiki: http://wiki.freepascal.org/iPhone/iPod_development#iOS_8.0 I've been looking through existing tutorials (i.e. Simon Choi's compiling iOS 7 or earlier Ingemar's iOS 5). Each tutorial is mentioning abo

Re: [fpc-devel] Xe3 Parallel for

On Tue, May 12, 2015 at 12:43 PM, Marco van de Voort wrote: > IMHO no discussion is necessary besides the bugreport where you added the > patch :-) > Except for Prism (which is a descendant of pascal syntax) are there any other thread oriented syntax that could be accommodated by FPC? thanks, D

Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch

On Fri, Jul 17, 2015 at 11:44 AM, Paul van Helden wrote: > The Oxygene dialect is absolutely beautiful in my opinion. Lots of things > in there that I've been wanting for decades and many stupid things dropped > completely. Silly example: var declarations when you need them like C. > > So wi

Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch

On Fri, Jul 17, 2015 at 1:53 PM, Maciej Izak wrote: > Proposed mode is not proposed as default pascal mode. You are safe :P. You > will be able to using classic pascal forever. So what is the problem? > Is it better to spend compiler-development time to such staff as improving compiler speed, ge

Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch

On Fri, Jul 17, 2015 at 2:03 PM, Maciej Izak wrote: > 2015-07-17 17:44 GMT+02:00 Paul van Helden > > The world is looking for a new language. That is why we recently got > Google's Go and Apple's Swift. I believe a modern and clean dialect of > Object Pascal has a "leg-up" on both of these. > I'

Re: [fpc-devel] re : FPC app crash with "has text relocations" / android 6.0

On Wed, Sep 9, 2015 at 3:40 PM, Maciej Izak wrote: > still unreadable ... :( > >   needs to be replaced with the space, obviously 2015-09-09 18:35 GMT+02:00 크레딕스 최원식 : Oh Sorry More Testing - Test Env. FPC 3.1.1 (svn 31577) Case 1. Java Loading Shared Lib (JNI)

Re: [fpc-devel] new features and facilities

On Thu, Oct 8, 2015 at 12:54 PM, Sven Barth wrote: > I had the idea to implement inline-if as well. I think the syntax I > selected is derived from Oxygene, but it looks very Pascal and shouldn't > break anything: > > left := if expr1 then expr2 else expr3; > > Thereby expr1 returns Boolean and e

Re: [fpc-devel] new features and facilities

The only Pascal way is left := IfThen(expr1, expr2, expr3) Similar to addr(), sizeof(), length(), write() and recently added Default() in intrinsic. I guess functions declared in Math unit are not covering all the needs (since type of expr2, expr3) may vary. That's why a bit of compiler support

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 2:30 PM, Michael Van Canneyt wrote: I'm not sure this kind of semantics is possible with a compiler intrinsic... > But if it is: In that case the IfThen or IIF() or somesuch has my absolute > top preference, followed by ternary. (and the If .. then expression should > be bl

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 2:45 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Looking at the assembler code, a=0 is evaluated first. > If it's true, the code is passed to the next line after assert, w/o > evaluating 'error '+intToStr(b). > And t

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 5:04 PM, Sven Barth wrote: > Yes a compiler intrinsic could handle that. In the end all three syntaxes > are the same code representation anyway: namely an if-node. > The IfThen() intrinsic would be fine with me as well. Let's call this our > common ground ;) > I wonder if

Re: [fpc-devel] Fwd: While - Otherwise Statement

a bit off-topic, But has case-otherwise been in FPC from the start? I believe it came from GNU pascal ( http://www.gnu-pascal.de/gpc/otherwise.html) and never existed in Delphi world ( http://docwiki.embarcadero.com/RADStudio/XE3/en/Declarations_and_Statements#Case_Statements) ?! I can see that F

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 2:07 AM, Sven Barth wrote: > It's from Extended ISO Pascal and I don't know for how long it exists in > FPC already, but it does so definitely for some time. > Thanks! I've never thought to go and read the FP documentation on "case statement", assuming it works in turbo pa

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 1:35 PM, Ralf Quint wrote: > > Either the while loop is executed or it isn't, depending in the > expression. I don't see an actual use case for any else/otherwise extension > to it... > You probably want to reread python while-else implementation. ( https://docs.python.or

  1   2   3   >