Re: [Lazarus] GDB is not good, any tricks to improve it?
Am 26.05.2016 10:41 schrieb "Tony Whyman" : > I take Graeme's point about GDN not being that great for Pascal, but it does work most of the time and adding a few well placed "writeln" statements often makes up for any deficiencies (again much easier under Linux due to the difficulty of getting a working console under Windows). At least with Pascal you don't seem to get the regular C++ GDB problem of "variable optimised out" just when need to get its value. Huh? Debugging with a console on Windows is less of a headache than on Unix systems. On Windows one just needs to make sure that the apptype is console and Windows will provide the console for your application to mess around in (even for GUI applications). On Linux we now have the Terminal Output window, but that only works if you don't want anything fancy (think the textmode IDE) otherwise you need to resort to a start application, on older Mac OS X systems even the terminal output window isn't available... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] HEAPTRACE IFDEF
Am 03.05.2016 15:49 schrieb "Aradeonas" : >> >> AFAIK, it's because it's not technically possible. > > As an amateur can I ask why? Because -gh does not trigger the recompilation of used units as internally it basically only adds another unit to the main program's uses clause. Thus any define for the presence of the heaptrace unit would only work in the main program file and there you use the variant with declared() anyway... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Example of full screen console program anywhere?
Am 25.04.2016 16:59 schrieb "Bo Berglund" : > > I need to create a console program, but one that works similar to the > nano editor, the gpsd position/satellite view or raspi-config on a > Raspberry Pi. > I.e. the program manages the full terminal screen and displays its > data in certain areas on screen and reads keystrokes as commands for > controlling the program. > I once did such programs on Windows using BASIC, but that was before > Windows appeared and I have all but forgotten how it was actually > accomplished > So I am looking for some examples to start off where the cursor for > writing is positioned on the screen in order to put output data in > certain places and commands can be entered without moving the > displayed screen. > > Is there such an example for FPC/Lazarus available somewhere? > Target is Raspbian on a Raspberry Pi3 and I cannot use any GUI system > for this because it must be accessed remotely via SSH (PuTTY) over a > slow link that does not work decently with the graphical interface. One example would be the Free Pascal's text mode IDE that you can find in the compiler's sources in ide/. It uses the Free Vision component system that's an open source clone of Turbo Pascal's Turbo Vision (FV is also part of FPC). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
Am 13.04.2016 10:19 schrieb "Michael Schnell" : > > BTW. according to the said wiki page (at the end of the page) I am wrong assuming that DefaultSystemCodePage is a constant introduced by the compiler. > > Now I still don't know whether/how the default encoding for the type "String (which is different from DefaultSystemCodePage according to the wiki) is depending on the arch/OS the compiler is built for. (I only tested on Linux and here it rather obviously is UTF8. I assume on Windows it's UTF16 for Delphi compatibility). > The code pages that are relevant here are only single byte code pages (e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store UTF-16 data. And the DefaultSystemCodePage is determined upon startup from the system. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Pretty neat stuff Lazarus
Am 11.04.2016 03:10 schrieb "Alan Corey" : > Installing and running as root seems to present a strange problem in > that when I rebuild the IDE it doesn't write the new version to > /root/.lazarus/lazarus, it stays in /usr/local/bin. I'll figure it > out. You should not run Lazarus as root. Of course it will then place new binaries in /usr/local/bin, because it *can*. As a normal user it can't and thus it's falling back to ~/.lazarus. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
Am 08.04.2016 13:12 schrieb "Michael Schnell" : > > On 04/07/2016 04:33 PM, Mattias Gaertner wrote: >> >> On Thu, 07 Apr 2016 16:25:26 +0200 >> Michael Schnell wrote: >> >>> On 04/07/2016 04:19 PM, Mattias Gaertner wrote: What -Fu paths do you have in your fpc.cfg? >>> >>> I did suppose something like this. >>> >>> Am I supposed to manually edit this file even for the unmodified svn d/l ? >> >> FPC does not care where the sources are coming from. >> You need a valid fpc.cfg, usually /etc/fpc.cfg . >> > I do have this. > > Here multiple times $fpcversion and $fpctarget are used which supposedly are provided by the compiler. > > Can it be that the compiler uses wrong values for those ? > > How can I check that ? (I did > > make FPC=`pwd`/compiler/ppc386 install INSTALL_PREFIX=/usr > > and hoped that would provide for this, and I suppose it did some time ago, as ) > Would you please test whether your installed trunk compiler works correctly (e.g. by compiling a simple helloworld program)? Maybe also add -vi if necessary so that the compiler will print its version information while compiling. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
Am 08.04.2016 13:29 schrieb "Michael Schnell" : > > On 04/07/2016 04:30 PM, Michael Van Canneyt wrote: >> >> >> I have this in my fpc.cfg, it is 2 lines long: > > > In my lazarus/trunk dir (created by svn), there is no fpc.cfg file. > > Do you suggest it should ? It should either be in /etc/fpc.cfg or ~/.fpc.cfg Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Search dialog scope
Am 07.04.2016 17:18 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-07 10:43, Ondrej Pokorny wrote: > >> > But the dialog's behaviour has always been 'as in delphi' (or at least > >> > as long as I remember) > > No, it wasn't. > > > > > Since when is Lazarus design goal now "Delphi IDE compatible"? The LCL > yes, the IDE no! The linked report also mentions other editors, so it's more like "common sense compatible" than "Delphi compatible" ;) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PDF generator, try 2
Am 07.04.2016 14:58 schrieb "Martin Schreiber" : > > On Thursday 07 April 2016 13:49:06 Graeme Geldenhuys wrote: > > I was about to mention that. This was discussed before, and there was a > > reason (which eludes me now) why FillChar() will not be changed. > > Because out parameters are finalised on caller side: Ah, yes, that was the subtle point I mentioned :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PDF generator, try 2
Am 07.04.2016 13:49 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-07 12:25, Martok wrote: > > If Move+FillChar would use out instead of var (as they should - they don't read > > the dest value, that's the whole point), that would be fixed once and for all. > > But I remember having this discussion before and apparently it was like this for > > some compatibility reason... > > I was about to mention that. This was discussed before, and there was a > reason (which eludes me now) why FillChar() will not be changed. And > that is also when I came up with the FillMem() solution. > "out" and "var" behave different in rather subtle points and thus code that would currently work with FillChar would no longer work then or have subtle errors. > If FPC starts nagging about uninitialised pointer parameters (as in the > usage by FillMem(...) ), then I am afraid there is *no solution* to get > rid of that compiler hint for FPC 2.6.4. There is no warning/hint/whatever because a parameter is always assumed to be initialized (except it's am "out" one). > I haven't looked at what FPC 3.0's Default() function does yet, but > maybe FPC could implement a FillMem() exactly like FillChar() but with > an out parameter instead. So then FillChar() is there for whatever > backward compatibility, and FillMem() could be used going forward to get > rid of that compiler hint. Then again, I probably made this suggestion > in our previous discussions on this topic. ;-) Default() essentially creates a variable of the given type and sets it to zero (there are optimizations for simple types). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PDF generator, try 2
Am 07.04.2016 07:43 schrieb "Jesus Reyes A." : > > En Wed, 06 Apr 2016 13:14:49 -0500, Michael Van Canneyt < mich...@freepascal.org> escribió: > >> >> >> On Wed, 6 Apr 2016, silvioprog wrote: >> >>> On Wed, Apr 6, 2016 at 2:14 PM, Michael Van Canneyt < mich...@freepascal.org> >>> wrote: >>> [...] >>> Why is this patch needed ? It should not be needed at all ? >>> >>> Sorry, I sent a wrong patch, please consider this new one in attachment. >>> >>> My patch just fix wrong chars in the generated PDF, eg, before the apply >>> it, I got: >> >> >> I see. I don't understand why this patch fixes it for you. >> >> Because it means that somewhere a conversion happens that should not happen. >> > > Here it fixes the problem too. So I did a small investigation and this is what I found: > > The problem starts with this code: > > procedure TPDFPage.AddTextToLookupLists(AText: UTF8String); > var > str: UnicodeString; > begin > if AText = '' then > Exit; > str := UTF8ToUTF16(AText); > Document.Fonts[FFontIndex].AddTextToMappingList(str); > end; > > AText (a CP_UTF8 tagged string) is passed away to UTF8ToUTF16(AText) which expects a mere and mundane ansistring (to be used later as a pchar), the assembler window shows at what point the conversion is attempted: > > C:\ThePathTo\fpctrunk\packages\fcl-pdf\src\fppdf.pp:1583 str := UTF8ToUTF16(AText); > 00435974 8b45fc mov-0x4(%ebp),%eax > 00435977 8d4dc8 lea-0x38(%ebp),%ecx > 0043597A 66ba mov$0x0,%dx > 0043597E e80d3dfdff call 0x409690 > 00435983 8b45c8 mov-0x38(%ebp),%eax > 00435986 8d55f4 lea-0xc(%ebp),%edx > 00435989 e8a286 call 0x43e030 > > fpc_ansistr_to_ansistr converts AText from the given UTF8String to ansistring via RawbyteString. And it converts it to whatever DefaultSystemCodePage says it should. Now this is a problem because in Windows and according to the wiki this value is "The result of the GetACP OS call, which returns the Windows ANSI code page". In my case, and I guess Silvio's too, DefaultSystemCodePage=1252 not CP_UTF8, so in our case if AText is 'Greek: Γειά σου κόσμος' there will be problems converting that to CodePage=1252 which is solved by showing the "?" in the problematic characters > > the SetMultiByteConversionCodePage(CP_UTF8) call makes DefaultSystemCodePage=CP_UTF8 which matches UTF8String and so in fpc_ansistr_to_ansistr no conversion is performed. > > And so that is why SetMultiByteConversionCodePage(CP_UTF8) is needed when compiling in windows > :) UTF8ToUTF16 should best take a UTF8String then. It would fit the purpose of the function better anyway... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Instalation on win 10
On 04.04.2016 20:21, Pedro Albuquerque wrote: > Hi, > > There has been a while since I used Windows and, more specifically win10 > I never tried. I recently got a new machine, but it runs win10. Are > there any special precautions to take with Lazarus/fpc instalation? > > I mean known issues, choosing specific directories for clean and build, > etc.? Is there any ongoing discussion about this? > > I would really appreciate some help because I really don't feel like > studying win10. :-S > > Thank's in advance. So far only the usual Windows points apply. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] German umlauts in component names
On 04.04.2016 18:07, Ondrej Pokorny wrote: > On 04.04.2016 16:57, Bart wrote: >> To me it just looks funny to have 2 languages in one file e.g. > > Just a curiosity from FPC code :) > > compiler/tokens.pas: > _LECKKLAMMER (I assume "linke eckige Klammer") > _RECKKLAMMER > _LKLAMMER > _RKLAMMER > > > rtl/inc/text.inc: > Procedure fpc_Write_Text_Currency(fixkomma,Len : Longint;var t : Text;c > : Currency); iocheck; compilerproc; Well, that definitely shows that even projects that are now international can have such identifiers from their past... Kinda proves my point ;) (the best one is _KLAMMERAFFE though ;) ) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] German umlauts in component names
Am 04.04.2016 12:12 schrieb "Mattias Gaertner" : > > As funny as the idea of using emojis for identifiers sound as scary it is. > > So I don't really support this. > > I share your concerns about non English keywords. For identifiers I > see some gain. > > Do the linker, assembler, debugger support UTF encoded identifiers? At > least on Win, Linux, Mac? The assembler symbols would need to be escaped anyway to avoid any potential problems. Even more fun with exported/imported symbols... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] German umlauts in component names
Am 04.04.2016 11:40 schrieb "Special" : > What problems, Denis? We use component names like "SchließenButton" since many years with Delphi in training programs for german pupils. And in code for the international community, we don't use it. *You* might do this, but others might not, they might publish projects on GitHub containing Chinese identifiers. As funny as the idea of using emojis for identifiers sound as scary it is. So I don't really support this. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
Am 01.04.2016 13:21 schrieb "Michael Schnell" : > > On 04/01/2016 01:13 PM, Sven Barth wrote: >> >> >> However classical WinAPI can't access it. You can access it only with Windows Store Apps and then only one at a time. Though you can runs these platforms headless as well without problems. >> > That is not true (and a very common misconception). > > A colleague of min already did run Windows services done with Delphi on Win IoT. > > The complete Windows API seems to work if you don't use GUI functions (which would be called widgets in Linux). Timers and TCP/IP do work . "it" meant the GUI, WinAPI applications can not access the GUI on IoT systems. From our past discussions you should know that I know that by now. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Can some fix this "make" issue? Pi related.
Am 01.04.2016 11:20 schrieb "Henry Vermaak" : > > On Fri, Apr 01, 2016 at 09:12:10AM +, Mark Morgan Lloyd wrote: > > Henry Vermaak wrote: > > >On Fri, Apr 01, 2016 at 12:39:15AM -0400, Anthony Walter wrote: > > >>My question is can someone look into this issue so that building Lazarus in > > >>environments where free memory is than 700MB does not result in Lazarus > > >>build failures? > > > > > >I've come across ld running out of memory when linking the lazarus > > >executable on my (very) old ARM laptop. You can try to pass > > >--no-keep-memory and --reduce-memory-overheads to ld, at the cost of > > >performance. I can't see how the build system has anything to do with > > >it. > > > > It's always worked fine for me on things like NSLU-2 provided that the > > overall memory (i.e. RAM + swap) is at least 512Mb. It will be unfortunate > > if recent builds of FPC and/or Lazarus have pushed this requirement upwards, > > but so far I've not seen any problems on a Raspberry Pi (both 1 and 2) > > running Raspbian or Debian. > > Yes, I remember that the slug needed swap. Swap is painfully slow, > though, so I'd recommend reducing ld's memory usage instead. I wonder > if anyone has tried the gold linker. It was supposed to be faster, I > don't know about memory usage. FPC does not support the gold linker (though I don't remember right now what the problems were). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
Am 01.04.2016 09:52 schrieb "Michael Van Canneyt" : > > > > On Fri, 1 Apr 2016, Michael Schnell wrote: > >> On 04/01/2016 08:58 AM, Michael Van Canneyt wrote: >>> >>> >>> Some years ago they announced that the sever could run "without GUI". >> >> >> In fact "Windows IOT" is windows 10 without the GUI API (i.e. you can run Aervicesm but you can't run applications). >> >> So this is viable/sensible/possible in the end. > > > "Windows IOT" is a misnomer. Windows = GUI. The name kind of gives it away. However classical WinAPI can't access it. You can access it only with Windows Store Apps and then only one at a time. Though you can runs these platforms headless as well without problems. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
On 31.03.2016 23:14, vfclists . wrote: > > They have recently announced Bash for Windows and they are aiming to get > a lot of Unix tools running easily on Windows. > In fact those tools have been there for a while but they were not > seriously promoted. > They announced the ability to run ELF binaries on Windows. Basically an advanced/improved version of their POSIX/Unix subsystem that they had from NT times till Windows 8 (exclusive if I remember correctly). Unlike then the binaries now run as is (back then one needed to compile them from source with an adjusted gcc, but it worked rather nicely :) ) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Feature Request: Insert {codepage UTF8} per default
Am 31.03.2016 00:48 schrieb "Bart" : > > On 3/31/16, Graeme Geldenhuys wrote: > > > [~]$ echo $LANG > > en_GB.UTF-8 > > This is what I hink is happening to your test (Sven can probably > explain it better): Jonas would probably be a better choice. Or the wiki page where the changes are documented (don't know it right now, but Jonas refers to it rather often :) ) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Feature Request: Insert {codepage UTF8} per default
Am 30.03.2016 11:23 schrieb "Juha Manninen" : > > Ok, FPC had UnicodeString earlier than I remembered. > Currently WideString is often used with WinAPI when UnicodeString > should be used, as Marco reminded in another discussion. The WinAPI does not know UnicodeString. It only knows PWideChar or B_STR for COM which is in Pascal handled by WideString. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Having multiple Lazarus like GetLazarus version
Am 24.03.2016 01:45 schrieb "Aradeonas" : >> >> Put a "lazarus.cfg" into the folder with lazarus.exe and write exactly this line into this file. > > Thanks but it seems not a good way. Lazarus will lose all the setting ans installed package and also GetLazarus version doesn't use a cfg file as I searched so it can has a better answer. Of course it looses all the settings, because you just told it to look in a different directory. Copy your original settings from their default location over to the new one and you should be good to go. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal / Lazarus calling conventions
Am 29.02.2016 16:04 schrieb "Chavoux Luyt" : > > > Hi guys, > > Just a stupid question, but is the Lazarus calling conventions documented anywhere? Is it different from Delphi calling conventions? When calling external c functions from libraries, does one need any special declarations like in Delphi to tell it to use c-style calling conventions? The register calling convention on i386 should be the same as Delphi's. The others (cdecl, stdcall, pascal) are implemented in a compatible way as well. On other platforms there is only one calling convention (exceptions on e.g. Amiga aside) which is the platforms default calling convention. > > Related (it was actually Bo's question that got me thinking about this... how easy/difficult would it be to write Linux drivers in Object Pascal, but in a way that C/C++ programs can also use it? Or for that matter (since Lazarus has been ported to Haiku) it might be easier to write drivers for Haiku in Pascal rather than C? Maybe speed things up a bit? For driver development in kernel mode you'll more often than not need a completely custom RTL. Exceptions would only be micro kernel system of which drivers are user mode processes as well and user mode driver frameworks. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus on my ancient computer?
On 14.02.2016 15:14, Bart wrote: > Hi, > > This is a bit off-topic. > > I have an ancient computer: Intel Celeron 700Mhz, 512MB RAM, 20GB IDE HD. > (http://flyingsheep.nl/computer_nostalgie.htm#celeron700) > (Hardware upgrades are not in the picture.) [snip] > So, do you have tips on which Linux flavour to install on this machine? I'd suggest ArchLinux. It's a very lightweight distro that's based on a rolling release (like Gentoo), but uses binary packages instead. I use it on my two main computers. On one I'm only using Awesome as window manager and on the other OpenBox. Nothing else. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
Am 12.02.2016 17:37 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth
wrote:
>>
>> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" <
skalogryz.li...@gmail.com>:
>> >
>> > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>> >>
>> >> {$define String:=RawByteString}
>> >>
>> >> and you are done.
>> >
>> >
>> > How to achieve the same effect from command line?
>>
>> Just don't. There are things that are not worth the trouble and this is
one of them.
>
> In this particular case (of porting Delphi 7 code straight to FPC 3.0.0)
is a matter of backward compatibility.
>
> I could agree that there are very little options left:
> * Delphi (whatever version supports 64bit) - changes in code are needed
> * FPC 3.0.0 - {$define String:=RawByteString} must be added to every unit
(or a single .inc file if used)
> * FPC 2.6.4 - no changes needed (?)
> So it might be indeed a thing not worth the trouble.
As long as you don't change the default code page strings in 3.0.0 should
behave very close to 2.6.4. The only exceptions would be API that talk to
the system (e.g. file APIs, though AFAIK we haven't really touched those
yet and the FindFirst API).
But in the end one should simply try it and after all one should have
testcases that help one discover problems anyway...
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>>
>> {$define String:=RawByteString}
>>
>> and you are done.
>
>
> How to achieve the same effect from command line?
Just don't. There are things that are not worth the trouble and this is one
of them.
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Can I assign items in an array all at once in FreePascal?
Am 07.02.2016 12:51 schrieb "Michael Van Canneyt" : > > > > On Sat, 6 Feb 2016, Sven Barth wrote: > >>> >>> Because of 2 reasons: >>> >>> 1. Delphi introduced the create constructor. >>> >>> 2. A literal such as [10,20,30,40] is a set in pascal, not an array. >> >> >> The answer is no longer correct with current Delphi versions. It now is >> "because we haven't implemented it yet". > > > Indeed. Well, I'm still on XE, the jump to XE 10 is for next month. > Seems I'll have some reading up to do... > > Disregarding the fact that they introduced now 2 syntaxes to initialize an > array, I'm curious what Jonas is going to say, because I remember he always advocates that the type of an expression is determined by the terms/factors in the expression, not by what you assign it to. > > For > ['abc','def'] + ['ghi','jkl'] > it is more or less clear. > > But what is the type of this expression: > [1,2,3] + [4,5,6] > is it an array or a set ? > > It probably means that they regard [] always as an array, and added some > kind of automatic set-to-array type assignment compatiblity for types that somehow fit in a set. Well... FPC is handling them special as well, after all we support open array parameters as well which clearly are no sets either. ;) They are parsed into an array constructor nodes and then converted into either an open array or a set by the node they're contained in. Support for normal arrays will simply(TM) mean the addition of additional special cases... (yes, it's easier said than done ;) ) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Can I assign items in an array all at once in FreePascal?
Am 06.02.2016 18:06 schrieb "Michael Van Canneyt" : > > > > On Sat, 6 Feb 2016, Aradeonas wrote: > >> Michael can I ask why we cant do something like this : >>> >>> MyArr :=[10, 20, 30, 40]; > > > Because of 2 reasons: > > 1. Delphi introduced the create constructor. > > 2. A literal such as [10,20,30,40] is a set in pascal, not an array. The answer is no longer correct with current Delphi versions. It now is "because we haven't implemented it yet". Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
Am 01.02.2016 16:18 schrieb "Anthony Walter" : > > Sven, > > What's the current road map look like for closures? Is it even on the radar? If so, and if no major work has been done on it yet, an improved syntax would go a long way in usability. Someone is working on them and a prototype exists (look in fpc-devel's archive for December). Now the code only needs to be cleaned up. In my head I already play around with a shorter/nicer syntax at least for expressions (thus lambda expressions ;) ), but most ideas rely on type inference which I'm very reluctant to add, because that's something that's not part of the sprit of Pascal. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
Am 01.02.2016 13:54 schrieb "Michael Van Canneyt" : > > > > On Mon, 1 Feb 2016, Anthony Walter wrote: > >> Just a bit of information, my Cross.Codebot library has threading built in >> to the socket protocol implementations, so with regards to explaining it I >> could just show the source code or I could write it a again just to >> demonstrate. >> >> With regards to complexity, I never define a new thread class, which is the >> typical way most people think about working with threads in Free Pascal. >> Instead I have one thread class defined in my System unit, and you pass it >> your execute method along with an optional status handler. Your execute is >> called, the thread object is freed for you automatically, and you don't >> need to declare a new type. >> > > [snip] > > >> procedure TDownloadForm.DownloadClick(Sender: TObject); >> begin >> if FThread <> nil then >>Exit; >> FThread := TSimpleThread.Create(Download, DownloadStatus, >> DownloadComplete); >> end; > > > This mechanism could easily be added as class static methods to TThread > itself. It would make life easier for many simple cases. > > Class Procedure TThread.Spawn(MyProcedure,OnStatus,OnTerminate : TThreadProcedure); static; > > Or "ExecuteInThread" instead of "Spawn". > > Would you care to enter this as a feature request ? Current Delphis have something similar for anonymous functions already, so we should use the same name, but with "of object" procvars instead (note: the resulting thread class will be TAnonymousThread). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to change Class Completion for Setter methods
Am 25.01.2016 12:16 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Hi, > > When I do class completion in Lazarus for a property with a setter > method I get code as follows: > > > procedure TFPCustomMemo.SetAlignment(AValue: TAlignment); > begin > if FAlignment = AValue then Exit; > FAlignment := AValue; > end; > > > How, if at all, do I change that code formatting to his: > > > procedure TFPCustomMemo.SetAlignment(AValue: TAlignment); > begin > if FAlignment = AValue then > Exit; > FAlignment := AValue; > end; > > > > Note that the latter example has a line break after the if..then statement. You are not the first who wants this ;) http://bugs.freepascal.org/view.php?id=15922 Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Bls: how to modify or add component after Application.Run method?
Am 24.01.2016 10:01 schrieb "Mr Bee" : > > No, I can't put them in the Form1's OnCreate event. Because the additional code wouldn't be just from me, but the could be from others as well. I'd like to make the main application into a unit. So, the form should be established on the unit call. The other would simply use the unit and add or modify any components of the existing Form1. That's not how things are supposed to be done AND bad style. But if you really need to do this you must do it before the call of Run. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] how to modify or add component after Application.Run method?
Am 24.01.2016 09:46 schrieb "Mr Bee" : > > Hi, > > Common Lazarus project source code contains this snippet: > > begin > Application.Initialize; > Application.CreateForm(TForm, Form1); > Application.Run; > end. > > Adding code to modify or add components of/into Form1 after the Application.Run method will be ignored because it's out of the application's main thread. So, is there a correct and safe way to do it? > > begin > Application.Initialize; > Application.CreateForm(TForm, Form1); > Application.Run; > // how to make below code be executed? > Form1.Caption := 'My caption'; > Form1.Edit1.Text := 'My text input'; > MyLabel := TMyLabel.Create(Form1); > MyLabel.Parent := Form1; > MyLabel.Caption := 'My runtime label'; > // or one could add any arbitraty code here > end. Put it into the form's OnCreate event handler. This kind of code does not belong into the main project file anyway. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpc trunk fails "make all"
Am 18.01.2016 18:52 schrieb "Anthony Walter" : > > While trying to "make all" of fpc on Window I am receiving and error on: > > make -C packages clean > > The error message is: > > make[2]: *** No rule to make target `clean'. Stop. Such questions are better asked on fpc-pascal. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Opening non existing files and (not) adding them to the project
Am 18.01.2016 12:11 schrieb "Juha Manninen" : > Can you find what revision caused the original problem you described? Seems like it was more PEBKAC than anything else. The thing is I normally use this when I work with the compiler and there I add my tests to a directory parallel to the project directory. However when I found this "problem" I had a different project in this test directory open (cause I needed to debug it), but I added a test in the same directory. Now while looking for the changed revision I found out that Lazarus applies a heuristic when to add a file to the project. Part of the decisions is the above mentioned difference and it seems to have been like that at least since 1.3 times (that's what I had accessible right now). So there was nothing changed at all and I merely stumbled upon my own stupidity -.- Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Opening non existing files and (not) adding them to the project
Am 18.01.2016 12:11 schrieb "Juha Manninen" : > Can you find what revision caused the original problem you described? I'll try to. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
Am 18.01.2016 11:05 schrieb "Michael Schnell" : > > On 01/18/2016 01:41 AM, Graeme Geldenhuys wrote: >> >> 1. Most websites are unusable without Javascript > > > The HTTP protocol cripples TCT/IP disallowing the server to spontaneously send anything . > > So without scrip the browser is dead by design. > > -Michael (IMHO, http was the worst idea ever...) The requirements back then were different. You didn't have highly interactive code running in the browser like you have today and for that HTTP was perfect. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Opening non existing files and (not) adding them to the project
Am 17.01.2016 20:36 schrieb "ListMember" : > > On 2016-01-17 16:30, Sven Barth wrote: >> >> when I opened a non-existing file and I confirmed that I want to have it created the file was not added to project or the project's mainfile. > > > But, isn't this how Delphi has been doing it all these years. > > 1) When you create a new unit, it automatically gets added to the project. > > 2) When you decide to save the project, you're asked whether you want to save the newly added (not saved yet) units. If not, it is removed from the project and you lose its contents. > > 3) If you want to exclude the newly created unit, you remove it from the project. In that case, IDE asks you whether you wish to save that file (or lose it). > > Do you still/really want a 'non-standard' behavior? I don't care what Delphi does. I care about what Lazarus has done for years and what I have relied upon. For me this *is* standard behavior. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Opening non existing files and (not) adding them to the project
Am 17.01.2016 22:35 schrieb "Juha Manninen" : > > On Sun, Jan 17, 2016 at 4:30 PM, Sven Barth wrote: > > Back in 1.4.x when I opened a non-existing file and I confirmed that I want > > to have it created the file was not added to project or the project's mainfile. > > [...] > > Now with 1.6RC2 I noticed that such files are added to the uses clause of > > the main program file and the project inspector. > > You cannot open a non-existing file, meaning that you cannot use the > File -> Open dialog for it. There is now a "FileMustExist" or similar > flag. I remember it fixed some bug but don't remember which one. > IMO it is logical because you can by definition only open existing > files. If a file does not exist, you must create it instead. Don't shock me like that, Juha. The IDE actively asks me whether I want to create a new file if I open a non existing one and it should definitely stay that way. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking search results
Am 17.01.2016 20:17 schrieb "Ondrej Pokorny" : > > On 17.01.2016 19:29, Juha Manninen wrote: >> >> It is opened if it was left open when Lazarus was closed previously. > > > No, it is not. It is opened if you saved your desktop with search result dialog opened. If you saved your desktop with search result dialog closed, it won't be opened. > If you have enabled "auto save desktop" option and you close the IDE with search result dialog opened, of course it is opened the next time. > > This is correct behaviour. Do not change it!!! E.g. some people want the search result dialog have docked or opened by default. I agree. I don't mind it to be open from the beginning either, normally I'm docking it into a tab with the message window anyway. Which reminds me: would the Search tab be automatically brought to front if I search something and the Message tab is in the front? I know I could simply test that myself, but till I'm in front of a Lazarus today I'll probably have forgotten that... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking search results
Am 17.01.2016 19:29 schrieb "Juha Manninen" : > @Sven: > > Ah, thanks. Will the reversal also be part of the final 1.6? > > Yes. It didn't make it to RC2 unfortunately. Ok, thanks :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Opening non existing files and (not) adding them to the project
Am 17.01.2016 18:22 schrieb "Bart" : > > On 1/17/16, Sven Barth wrote: > > > Is there some option I have missed to change this behavior? Because not > > only meeses this up the compiler project, but CodeTools don't like it as > > well as the files I add this way are usually program files, thus they > > shouldn't be in the uses section anyway. > > Odd. > > ProjectOptions->Miscallaneous-> "Main unit has uses section containing > all units of a project". > Uncheck and save as default compiler options? > > Would have expected that to be a global setting. That solves at least one part of the issue. The new file is however still added to the project which is not good. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking search results
Am 17.01.2016 17:43 schrieb "Ondrej Pokorny" : > > On 17.01.2016 16:46, Sven Barth wrote: >> >> Another thing I noticed in 1.6RC2: I can't dock the search results window anymore. Does anyone know whether this is on purpose and if yes why? > > > http://mantis.freepascal.org/view.php?id=29320 Ah, thanks. Will the reversal also be part of the final 1.6? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Docking search results
Helle together! Another thing I noticed in 1.6RC2: I can't dock the search results window anymore. Does anyone know whether this is on purpose and if yes why? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Opening non existing files and (not) adding them to the project
Hello together! Working with 1.6RC2 I noticed a - for me - very serious problem and wonder whether I've missed some option. Back in 1.4.x when I opened a non-existing file and I confirmed that I want to have it created the file was not added to project or the project's mainfile. This is wonderful and I use it to quickly create testcases for the compiler (which don't need their own project and are compiled from the command line or from the compiler running debugged in the IDE anyway). Now with 1.6RC2 I noticed that such files are added to the uses clause of the main program file and the project inspector. Is there some option I have missed to change this behavior? Because not only meeses this up the compiler project, but CodeTools don't like it as well as the files I add this way are usually program files, thus they shouldn't be in the uses section anyway. If there isn't the this should be changed preferably before the release of 1.6 as otherwise that version will be useless for me (or I'll have to patch out that code myself). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FileExistsUTF8 and long paths
Am 17.01.2016 12:42 schrieb "Bart" : > In the end I used a bootable linux dvd (puppy linux), mounted the > partition in question and used the filemanger from that distro to > remove the folder and file. You know that you could just have written a program that uses the *W API to delete files with a \\?\ prefixed path? ;) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FileExistsUTF8 and long paths
Am 17.01.2016 14:23 schrieb "Jürgen Hestermann" : > >> I did not find any comments that mentions long paths > > You need new glasses then ;-) > > === code == > > //if Filename uses ExtendedLengthPath scheme then it cannot be expanded > > //AND it should not be altered by ForcePathDelims or ResolveDots > > //See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx > > if (Length(Fn) > 3) and (Fn[1] = PathDelim) and (Fn[2] = PathDelim) and > > (Fn[3] = '?') and (Fn[4] = PathDelim) //Do NOT use > > AllowDirectorySeparators here! > > then Exit; > > === end code === > > I have read this but how is this related to \\?\ and long paths? > What is ExtendedLengthPath scheme? > I don't see any information about W functions and \\?\ prefix. Did you look at the if-clause following the comment? What do you think PathDelim + PathDelim + '?' + PathDelim evaluates to? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] IDE Coolbar and its default after updating
Hello together!
Today I updated my Lazarus from 1.4.4 to 1.6RC2 and while reporting some
bugs (not specific to the RC2, but general ones), I noticed that the
toolbar buttons ("open", "save", etc.) were missing. Thinking first that my
docking settings were messed up again I checked those, but they were okay.
Then I noticed the IDE Coolbar settings and that it's switched off.
Switching it on brought the buttons back, but I wonder whether it's a good
idea to have this as "default off" after an upgrade...
(OS: Windows 10)
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot find unit lNet when building project
Am 15.01.2016 16:08 schrieb "Mark Morgan Lloyd" < markmll.laza...@telemetry.co.uk>: > > Mattias Gaertner wrote: >> >> On Fri, 15 Jan 2016 14:50:35 +0100 >> Bo Berglund wrote: >> >>> [...](AFAIK "fppkg install lnet"). >> >> >> Yes. >> It is a bit confusing, that lnet is in FPC sources, but needs to be >> installed by fppkg. > > > I agree. Does anybody know the historical reason for this? fppkg needs socket support, but that was needed before our own implementation was ready enough, so lnet was imported directly into fppkg as to avoid the appearance that lnet is distributed in the fpc sources. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot find unit lNet when building project
Am 15.01.2016 12:30 schrieb "Mattias Gaertner" : > > I usually > > create the objects in code anyway and my test program is a console > > (non-gui) program. > > > > >Maybe you updated your compiler and forgot to update lnet? > > Same compiler as before (3.0.0) > > And the IDE picks up the source unit from: > > /usr/fpc/3.0.0/utils/fppkg/lnet/lnet.pp > > Good. That's the usual place on Linux. That's the place where fppkg needs it during compilation, yes, but not where the compiler would and should find it. The user should use fppkg (just a coincidence that both times fppkg is involved here) to install the package (AFAIK "fppkg install lnet"). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Conditional Defines for Raspberry PI?
Am 13.01.2016 17:03 schrieb "Donald Ziesig" : > > Hi Everyone! > > Are there any conditional defines that let me exclude PI-specific code when compiling for 64-bit amd linux (or vice-versa)? > > I can define my own if necessary, but that is one more thing to worry about when switching machines. Raspberry Pi is an ARM so you could check for CPUARM. 64-bit x86 Linux would be CPUX86_64 (for completeness: CPUI386 is for 32-bit x86). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Do we really need a PaintSwastika procedure?
Am 06.01.2016 21:25 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-01-06 19:21, Anthony Walter wrote: > > but our lcl > > version precisely matches the Nazi version. > > No it doesn't - if you want to get technical. The star isn't drawn > inside a circle (as your screenshot clearly shows). It also isn't drawn > on a red background by default. The "Hakenkreuz" wasn't black on white surrounded by red everywhere. Especially on sculptures (think eagle of the Reich) it was more often than not simply the base material with the "white" being air. Anyway, I agree that PaintSwastika doesn't necessarily have to do with the Nazis... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Do we really need a PaintSwastika procedure?
Am 06.01.2016 20:44 schrieb "Marc Santhoff" : > Got some silver knifes and black candles at hand? Ehm... You do know that the one with the tip at the top is *not* a satanic symbol? It's a protective symbol instead. The satanic one is the one standing on its tip. I should know, because I like to wear the protective variant ;) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cross Platform SQL Client/Editor
Am 02.01.2016 15:55 schrieb "Anthony Walter" : > > Sven, > > >> I don't see MSSQL support. I don't want to setup ODBC DSNs, > > > It *does* support MSSQL. It supports all databases that FPC supports. > > On my system LazDataDesktop does not show MSSQL as an option: > > http://cache.getlazarus.org/images/where-is-mssql.png Hmm... Then the unit was not added. Simply file a bug report then as FPC supports it definitely and thus there's no reason why the LazDataDesktop shouldn't... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cross Platform SQL Client/Editor
Am 02.01.2016 01:13 schrieb "Anthony Walter" : > > Michael, > > I don't want a "visual" table builder and I'm unsure how many others do. All I want is something to connect me to a database engine where I can then execute bits of SQL (it executes what you highlight), which is what my program does. LazDataDesktop allows for that as well. I don't have it right in front of me, but if I remember correctly there is a tab - after you're connected - in which you can simply execute statements. > Lazarus database desktop seems geared towards everything I don't want. I don't see MSSQL support. I don't want to setup ODBC DSNs, I just want a straight MSSQL connection. I don't see an simple create/test connection screen. Right clicking in a blank list view to get a menu and then selecting an option is just bad design. Straight off I don't see a SQL editor either. It *does* support MSSQL. It supports all databases that FPC supports. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lazarus 1.6 rc1 fpc 3.0 opendialog
On 16.12.2015 19:11, Martin Frb wrote: On 16/12/2015 17:26, Ondrej Pokorny wrote: On 16.12.2015 18:20, Bart wrote: On 12/16/15, Ondrej Pokorny wrote: >I had the same issue on Windows 10 and was advised to check >DisableLoadSymbolsForLibraries (I don't remember who advised me, sorry). Yoe beat me to it. (And I was the one.) :) Is it possible/reasonable to check the settings by default? Maybe more people will be affected by the Win10 issue and not by disabling load symbols by default? If we could get a more uptodate gdb for 64 bit that should solve it (providing it passes the gdbmi test case without crash) If the option is active and you develop a library project, then you can not debug it. - In the past 64 bit did not work because of SEH, so the error was encountered with 32 bit. For 32 bit gdb was updated to 7.7.1 and that should (afaik) fix the issue. (On 32 bit gdb > 7.7.1, tested up do gdb 10 are less stable, they crash in the testcase) What about fpdebug? Does it work for Win64? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 16.12.2015 18:12, Bart wrote: On 12/10/15, Jürgen Hestermann wrote: But now I have a problem with UTF8Strings: With this declaration var S : UTF8String; I want to delete a character UTF8Delete(S,1,1); but I get an error that the (var) parameter mismatches. Fixed in r50850. Proposed for merging to 1.6RC2. Better read Jonas' comments on that commit first: The code that was committed for UTF8Delete(utf8string) in http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/lazutils/lazutf8.pas?root=lazarus&r1=50850&r2=50849&pathrev=50850 makes no sense: * it's the "string" version that needs this wrapper, not the utf8string one (it's probably done because the "string" version is more commonly called, but that doesn't help if the current approach is wrong) * changing the codepage of tmp at the start is a no-op, since it's an empty string at that point and you can't change the code page of an empty string (it's a nil pointer) * if you can reasonably expect any custom string type to already have an utf8 code page, it's utf8string. It's not guaranteed of course, but it's much more likely than for a random "string"-typed variable (even if defaultsystemcodepage = CP_UTF8, because system unit routines may return rawbytestrings that have different code page) -- so if you want to change the code page of strings to make sure it's utf8, that should be done in the plain string version rather than in the utf8string version. I also made an error in my original code (apart from the missing rawbytestring typecasts when calling SetStringCodePage). The "s:=tmp;" at the end needs to be "s:=RawByteString(tmp);" to avoid a codepage conversion in that assignment. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Install FPC and Lazarus from source
On 13.12.2015 20:01, Bo Berglund wrote: On Sat, 12 Dec 2015 18:23:19 +0100, Sven Barth wrote: strip removes the debug information stored in the binary. So in that case you won't get detailed exception information (stack trace) inside Lazarus if an exception occurs there. So it means that I could not debug inside the Lazarus code itself. But that is a no-issue for me since I would not know what to do anyway. I just want my own code to be debuggable. Yes, that would be the consequence. As long as you're aware of that, go strip your binary. Or you could build Lazarus with OPT="-Xs" which will already tell the compiler to strip the debug information (you can also supply this option in the IDE dialogs responsible for rebuilding (I don't know the name right now, sorry) and then it will also be applied each time you rebuild Lazarus from within the IDE). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 13.12.2015 10:55, Jürgen Hestermann wrote: > For most cases things did not change very much. Earlier you had to use > the explicit UTF8...() functions, now you don't need them. What does this mean? If I use DELETE on a String type (that is an UTF-8 string) does it now use UTF8Delete internally? Utf8Delete is a LCL function, not a RTL function while Delete is an RTL function. The latter does not know about the former. Does it delete bytes or code points? Does LENGTH now give back the number of bytes or the number of characters (when used on an UTF-8 String)? In both cases its Byte. I *think* we have some functionality to deal with code points as well, but I'd need to look that up as I'm not working with these that much... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 12.12.2015 18:40, Jürgen Hestermann wrote: Am 2015-12-12 um 18:20 schrieb Sven Barth: Yes, internally Windows uses UTF-16, but if you set your Windows Ansi code page or at least the current thread's locale to UTF-8 (indirectly by choosing a locale that has UTF-8 as code page, I don't know one right now though) then the *A functions *do* work with UTF-8, simply because they use the current locale's code page to convert from Ansi to Unicode and in this case Ansi includes UTF-8. If that would be true then we could simply switch the Windows (API) interface to UTF-8 and nobody needs to worry about code pages anymore. I doubt that this can be done. How do you set the Win API interface to now expect UTF-8 strings in all *A functions? Any link? I'll come back to you regarding this. It *is* possible, but it is not feasible - which is why it isn't used more - and I'm currently a bit too busy to write an example... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 13.12.2015 11:37, Jürgen Hestermann wrote: > And hence, at that point in time, there would (for programmers using > Lazarus) bee no need to use the type Utf8String at all. Then I would suggest to remove this type. Utf8String is part of the FPC RTL and is just a shorthand for AnsiString(CP_UTF8). That the LCL provides String routines that don't take an Utf8String, but an AnsiString, aka AnsiString(CP_ACP) is not the fault of the Utf8String type, so it will stay. Period. But I still don't understand the rationale behind the decision to not allow ansistring(A) to be fed into a var parameter of ansistring(B). I would expect that *all* ansistrings are assignement compatible. They *are* assignment compatible, just like ShortString and UnicodeString are assignment compatible. But they are different types and just like you can't pass a UnicodeString to a function expecting a ShortString var parameter you can't pass an AnsiString(CP_UTF8) to a function expecting a AnsiString(CP_ACP). Simply consider them as different types with automatic type conversions between them... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Install FPC and Lazarus from source
On 12.12.2015 17:27, Bo Berglund wrote: On Sat, 12 Dec 2015 15:32:15 +0100, Bo Berglund wrote: Also, what is the purpose of strip -s lazarus? Answering this myself after looking at strip -help: It strips all embedded symbols from the lazarus program file! I tried it in a Linux Mint 17.2 Cinnamon virtual machine on my Win7 laptop and amazingly the file size shrunk: from 102,683,731 bytes to 26,751,376 bytes Quite amazingly much! strip removes the debug information stored in the binary. So in that case you won't get detailed exception information (stack trace) inside Lazarus if an exception occurs there. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 12.12.2015 12:46, Jürgen Hestermann wrote: Am 2015-12-11 um 19:14 schrieb Sven Barth: > Windows uses multi byte strings (one byte per character or more) > and UTF-16 (which is mostly 2 Byte and 4 for surrogate pairs). > The functions WideCharToMultiByte and MultiByteToWideChar which > are also used inside FPC for string conversions both take a > CodePage parameter that can also be CP_UTF8. As far as I know, (current) Windows versions only use UTF16 internally. But it provides the old legacy ANSI functions too (which convert to UTF16). MultiByteToWideChar and WideCharToMultiByte are just helper functions to convert from arbitrary encodings to UTF16 (and back). But UTF-8 is nowhere used internaly in Windows (not even ANSI anymore, except the legacy functions which convert to and from UTF16) and you cannot use UTF8 as string encoding for WIN API functions. Otherwise we would not have this problem and could use UTF-8 as a standard for everything. Yes, internally Windows uses UTF-16, but if you set your Windows Ansi code page or at least the current thread's locale to UTF-8 (indirectly by choosing a locale that has UTF-8 as code page, I don't know one right now though) then the *A functions *do* work with UTF-8, simply because they use the current locale's code page to convert from Ansi to Unicode and in this case Ansi includes UTF-8. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 12.12.2015 17:37, Jürgen Hestermann wrote: Is it correct that now every ansistring has a static code page and a dynamic code page (as mentioned in http://wiki.freepascal.org/FPC_Unicode_support)? Yes. Is it correct that each ansistring type can store strings with any encoding (dynamic code page) but there is a "genuine" (static) code page which is preferred (in cases a target encoding needs to be chosen)? Yes. What is the difference between UTF8String = type ansistring(cp_UTF8); and String = type ansistring(cp_ACP); when cp_ACP=cp_UTF8? CP_ACP is *never* CP_UTF8. It is *always* CP_ACP. So these two will *always* be different types. However the specific codepage that CP_ACP refers to is determined at runtime and that can indeed be CP_UTF8. Both would have the same static code page (UTF-8) but may contain a different encoding at run time. So why can't I use an UTF8String in the same way as a String type as parameter? Why are they not assignment compatible? They are assignment compatible (all AnsiStrings are) and the compiler will insert a code page conversion if necessary (if CP_ACP refers to CP_UTF8 and if one of the two strings is CP_ACP the other CP_UTF8 then the conversion routine won't do a code page conversion of course). However since they are different types you can't simply pass a AnsiString(CP_UTF8) to a var parameter of type AnsiString(CP_ACP). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 12.12.2015 16:47, Bart wrote:
On 12/11/15, Sven Barth wrote:
Not necessarily. You can use SetCodePage() to change the code page of
the string without triggering a codepage conversion by using the third
parameter which is a Boolean that tells the function to either do a
conversion (True; default) or not (False). You'd then need to declare
the UTF8* routines as RawByteString and explicitly handle the type
conversion.
That's not really an option since it will break every single program
using those functions.
AFAIK the Utf8* functions assume their input is UTF8 encoded (they do
not check), so something like this should work?
{$ifndef NO_CP_RTL}
procedure Utf8Delete(var S: Utf8String; StartCharIndex, CharCount:
PtrInt); overload;
var
Temp: String;
begin
SetLength(Temp, Length(S));
Move(S[1], Temp[1], Length(S));
//nex step might not be needed?
SetCodePage(RawBytestring(Temp), CP_UTF8, False);
UTF8Delete(Temp, StartCharIndex, CharCount);
SetLength(S, Length(Temp));
Move(Temp[1], S[1], Length(Temp));
end;
{$endif}
Anyhow, as stated before, there should be noneed to use the type
Utf8String in Lazarus programs.
Jonas has given me the following as a possible solution:
=== code begin ===
procedure UTF8Delete(var s: UTF8String; StartCharIndex, CharCount: PtrInt);
begin
...
end;
procedure UTF8Delete(var s: String; StartCharIndex, CharCount: PtrInt);
var
orgcp: tsystemcodepage;
tmp: utf8string;
begin
orgcp:=StringCodePage(s);
{ change code page without converting the data }
SetStringCodePage(s,CP_UTF8,false);
tmp:=s;
{ keep refcount to 1 if it was 1, to avoid unnecessary copies }
s:='';
UTF8Delete(tmp,StartCharIndex,CharCount);
{ same as above }
s:=tmp;
tmp:='';
SetStringCodePage(s,orgcp,false);
end;
=== code end ===
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 11.12.2015 13:12, Mattias Gaertner wrote: On Fri, 11 Dec 2015 08:05:12 +0100 Sven Barth wrote: [...] UTF8Delete(AnsiString(Pointer(s)),1,1); While the typecast itself would probably work I strongly advice against it since you're relying on implementation details. True. Also I doubt that you can do this for var parameters... FPC 3.0 eats it without a hint. I just checked the generated code and it's the same for both with and without Pointer. The question is whether this is intended to work. If I were you I definitely wouldn't rely on that until this question is answered (and then you can probably use it without the Pointer typecast...) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 11.12.2015 15:20, "Jürgen Hestermann" wrote: >My link explains some differences important for Lazarus. But it does not explain the difference between an "UTF8String" and an "UTF8 String" >The encoding hassle is built into Windows. The compiler cannot overcome >it. It can only give you tools to make it easier. That is not true. Windows uses 2 kinds of strings: ANSI (one byte) and/or UTF16 (2 byte). None of them can be used with UTF8 functions so a conversion is needed anyway. This is not entirely correct. Windows uses multi byte strings (one byte per character or more) and UTF-16 (which is mostly 2 Byte and 4 for surrogate pairs). The functions WideCharToMultiByte and MultiByteToWideChar which are also used inside FPC for string conversions both take a CodePage parameter that can also be CP_UTF8. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 11.12.2015 15:14, Juha Manninen wrote: On Fri, Dec 11, 2015 at 4:10 PM, Mattias Gaertner wrote: The job of the wrapper is to convert to type String without triggering the conversion of the content. Ok, lots of ugly Pointer typecasts. Doable, yes. Not necessarily. You can use SetCodePage() to change the code page of the string without triggering a codepage conversion by using the third parameter which is a Boolean that tells the function to either do a conversion (True; default) or not (False). You'd then need to declare the UTF8* routines as RawByteString and explicitly handle the type conversion. That's at least more officially supported than ugly pointer typecasts... (Note: it might be that some details don't work as I described them; if in doubt ask on fpc-pascal please) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
Am 11.12.2015 08:20 schrieb "Martin Schreiber" : > > On Friday 11 December 2015 08:05:12 Sven Barth wrote: > > Am 10.12.2015 23:04 schrieb "Mattias Gaertner" < nc-gaert...@netcologne.de>: > > > > > > What about: > > > > > > UTF8Delete(AnsiString(Pointer(s)),1,1); > > > > While the typecast itself would probably work I strongly advice against it > > since you're relying on implementation details. Also I doubt that you can > > do this for var parameters... > > > It is difficult to make efficient Free Pascal applications without > such "tricks". ;-) But then don't come and complain if such tricks don't work anymore for some reason or another... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
Am 10.12.2015 23:04 schrieb "Mattias Gaertner" : > > On Thu, 10 Dec 2015 19:59:26 +0100 > Sven Barth wrote: > > > Am 10.12.2015 19:53 schrieb "Juha Manninen" : > >[...] > > > A typecast can be used as a workaround now. > > > UTF8String and AnsiString have the same memory layout so it should work. > > > > This has nothing to do with the memory layout. Both Utf8String and > > AnsiString are AnsiString types and an assignment to each other or a > > typecast will result in a codepage conversion if necessary. > > What about: > > UTF8Delete(AnsiString(Pointer(s)),1,1); While the typecast itself would probably work I strongly advice against it since you're relying on implementation details. Also I doubt that you can do this for var parameters... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
Am 11.12.2015 06:52 schrieb "Jürgen Hestermann" : > > > > Am 2015-12-10 um 18:22 schrieb Juha Manninen: >> >> On Thu, Dec 10, 2015 at 6:49 PM, Jürgen Hestermann >> wrote: >>> >>> How can I use UTF8Delete on an UTF8string? >> >> You can't. Please read this : >> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus >> "String" type is UTF-8 and it works now (almost) transparently without >> explicit conversions. >> > Then why does the compiler complain when I > feed UTF8Delete with an UTF8String? UTF8Delete probably takes an AnsiString (or String) as var parameter and for var parameters the static codepages have to match exactly (String has CP_ACP while Utf8String has CP_UTF8). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
Am 10.12.2015 19:53 schrieb "Juha Manninen" : > > On Thu, Dec 10, 2015 at 8:18 PM, Ondrej Pokorny wrote: > > IMO, there should be overloaded versions for UTF8* functions that > > explicitely accept UTF8String. > > Or am I wrong? > > You are right. I did not even think so far yet. > A typecast can be used as a workaround now. > UTF8String and AnsiString have the same memory layout so it should work. This has nothing to do with the memory layout. Both Utf8String and AnsiString are AnsiString types and an assignment to each other or a typecast will result in a codepage conversion if necessary. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
Am 04.12.2015 11:34 schrieb "Michael Schnell" : > > On 12/04/2015 10:44 AM, Sven Barth wrote: >> >> >> Why do you assume that every software written in Lazarus/Free Pascal is automatically an open source one? >> > I don't assume "is" but I assume "should be", as I consider closed source projects as a fraud against the highly valuated fpc and lazarus team members. pen source software of course can be payed for customer projects, but any obfuscation of the true working of a program in neither "nice" towards the customer nor sensible, as a decent hacker will crack it, anyway. Maybe you never had the problem of your software to be illegally distributed or even hacked to be distributed as such. There is a certain point when you *must* do something, otherwise your losses get too large. And this also applies to otherwise legal customers not adhering to the license restrictions because they aren't technically enforced anyway. Also it doesn't need to be protected forever, just long enough that you can release the next version where the crackers would need to begin anew (of course one needs to adjust one's copy protection/tamper proofing then). Also the more complex a software is to crack the further down in the ToDo list of the cracker it is. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
Am 04.12.2015 13:02 schrieb "Richard Mace" : > > > On 4 Dec 2015 09:48, "Sven Barth" wrote: > > > Do you want to protect your whole application or only a specific part? (e.g. a specific algorithm you don't want to disclose or the license validation code) > > > > Regards, > > Sven > > > > Hi Sven, > I guess just the license checking part really. > I am already using OnGuard but I was just thinking about maximising the protection before its released. I can't comment on how good OnGuard is regarding that, but the hints from Marc Santhoff are definitely something and other than that I'd search for C/C++ stuff as that can most likely be adapted for FPC. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
Am 04.12.2015 09:29 schrieb "Richard Mace" : > > Hi All, > I was wondering if there was a way where an application, written in Lazarus, could detect when a compiler is running, perhaps by it's mutex? > My idea was, in my application, I could periodically check to see if a decompiler was running and then my app could perform an operation, such as maybe closing. You can't do anything actively against a decompiler (please don't confuse this with "compiler"...) or dissasembler as these are running while your application is not. You'd need to use code obfuscation for that - especially on the assembly level - so that neither a human nor an algorithm can easily reconstruct the code's meaning. What you cam do at runtime though is to protect against debuggers. Since this isn't specific to Lazarus/Free Pascal I'd suggest you to look also in context of C/C++ programs. Do you want to protect your whole application or only a specific part? (e.g. a specific algorithm you don't want to disclose or the license validation code) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
Am 04.12.2015 10:29 schrieb "Michael Schnell" : > > On 12/04/2015 09:29 AM, Richard Mace wrote: >> >> >> My idea was, in my application, I could periodically check to see if a decompiler was running and then my app could perform an operation, such as maybe closing. > > > Why should open source software need a decompiler ? Why do you assume that every software written in Lazarus/Free Pascal is automatically an open source one? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC Pestering Peacock (3.0.0) release
Am 26.11.2015 20:02 schrieb "Kostas Michalopoulos" : > > Wow, that is a great release. Two major things for me: > > 1. I had a bug in my 3D world editor for some time now that i couldn't spot. Turns out, i was accessing the fields of a direct getter property (property Foo: TSomeStruct read FFoo...) that in 2.6.4 most of the time it worked but now and then it accessed garbage. The code looked right (this might be a negative for property syntax looking exactly like variable field syntax...) so i never focused on that bit. But 3.0.0 refused to compile it and once i changed it, the bug went away. At least the change paid off then ;) > 2. The editor's lightmapper seems to be between 3 to 3.5 times faster! Of course having said that, it is really unoptimized and a lot of the slowness in 2.6.4 seemed to be from FPC inserting tons of calls to "hidden" methods so probably the speed up came from optimizing the usage of those (i haven't investigated why it is faster, i just report it - besides i plan to rewrite the lightmapper anyway since it is a prototype that outlived its purpose for almost four years :-P but in the meanwhile the performance boost is very welcome). Good to know that the compiler indeed generates better code now :D Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Q: Compiler features as a service to Lazarus
Am 24.11.2015 12:11 schrieb "Michael Van Canneyt" : > > > > On Tue, 24 Nov 2015, Sven Barth wrote: > >> Am 24.11.2015 10:05 schrieb "Michael Van Canneyt" : >>> >>> >>> And I think you highly exaggerate the amount of time it takes for Mattias >> >> to enable new features in the IDE codetools. If he is aware of a new >> feature, it generally is added to the IDE very quickly. >>> >>> >>> On the whole, I tend to see the current situation as a plus, rather than >> >> a minus. >> >> Plus there are no services of the compiler you could ask. The compiler is >> highly integrated and not even the textmode IDE - which has the compiler >> statically compiled - in can do this. > > > Exactly. That was the gist of my statement that > > > "The compiler structure is currently entirely unsuitable for this purpose." It seems I have problems with communicating after a weekend of coding :P Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Q: Compiler features as a service to Lazarus
Am 24.11.2015 10:05 schrieb "Michael Van Canneyt" : > > > > On Tue, 24 Nov 2015, Anthony Walter wrote: > >> I have a tangential question related to Sven's new generic features and >> thought it deserved its own thread. > > > [snip] > > >> **This tutorial demonstrates how to use the editor services provided by the >> compiler. This API is used to provide auto-complete, tool-tips, parameter >> info help, matching of brackets and other functions in editors including >> Visual Studio, Xamarin Studio and Emacs.** >> >> http://fsharp.github.io/FSharp.Compiler.Service/editor.html >> >> If they can do it, why can't we? > > > Because 1. We don't want to. >The amount of work needed to accomplish that is prohibitive. >The compiler structure is currently entirely unsuitable for this purpose. > > 2. The codetools continue to work even if the sources do not compile. >Not always, but often. >This is simply not possible if you use the compiler itself. > > And I think you highly exaggerate the amount of time it takes for Mattias to enable new features in the IDE codetools. If he is aware of a new feature, it generally is added to the IDE very quickly. > > On the whole, I tend to see the current situation as a plus, rather than a minus. Plus there are no services of the compiler you could ask. The compiler is highly integrated and not even the textmode IDE - which has the compiler statically compiled - in can do this. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Video: Docked Designer Test
Am 23.11.2015 23:29 schrieb "Michael Van Canneyt" : > > > > On Mon, 23 Nov 2015, Sven Barth wrote: > >> Am 23.11.2015 19:41 schrieb "Den" : >>> >>> >>> Micheal, I'm thinking they mean just a visual representation of the >> >> non-visual components, by having them displayed in a different area. For >> you, they would show up wherever you want to put them (by default the >> designer could put them in a grid), but the XY won't change of the >> components themselves, just putting them out of the way for the ones that >> want the option on (if I got it correctly). >> >> What about newly added non-visual components though? Would they all just >> clutter in one spot? > > > That is exactly what I meant with my remark... I know, but others don't seem to get the problem... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Video: Docked Designer Test
Am 23.11.2015 19:41 schrieb "Den" : > > Micheal, I'm thinking they mean just a visual representation of the non-visual components, by having them displayed in a different area. For you, they would show up wherever you want to put them (by default the designer could put them in a grid), but the XY won't change of the components themselves, just putting them out of the way for the ones that want the option on (if I got it correctly). What about newly added non-visual components though? Would they all just clutter in one spot? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Video: Docked Designer Test
Am 23.11.2015 12:35 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2015-11-23 10:40, Anthony Walter wrote: > > I did some testing with the new sparta docked form designer on OSX. here is > > a video clip of it in action: > > May I make a suggestion. Why not automatically place non-visual > components (eg: TOpenDialog, TSaveDialog etc) in a dedicated non-visual > area outside the designed form: eg: in a panel above the "Code, > Designer" tabs shown in the video. It could even be order alphabetically. > > I never understood why non-visual components lived inside the designer > form at a specific x,y position - cluttering up your designer form. Even > the streaming had to be "hacked" to support a fake x,y position for > these non-visual components. I agree with Graeme. At least as an option :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 3.0.0-rc2 release
Am 20.11.2015 11:32 schrieb "Maciej Izak" : > > Can we merge r31911 into final 3.0 version? I can't use Generics.Collections library with Lazarus packages :\ > > http://bugs.freepascal.org/view.php?id=28766 As Jonas already wrote, no, it's too late. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Encryption compatible with .net
Am 15.11.2015 06:31 schrieb "Gabriele Cappelletto" <
cappellettogabri...@yahoo.it>:
>
>
>
> Il 14/11/2015 18:11, Graeme Geldenhuys ha scritto:
> > On 2015-11-14 09:44, Gabriele Cappelletto wrote:
> >> the .net DESCryptoServiceProvider.
> > Please show how the data was encrypted... The exact code snippet would
> > be useful. I could then show you how to use DCPCrypt with the same
> > settings to decrypt it.
> >
> > Without knowing how it was encrypted, there is no way anybody can show
> > you code on how to decrypt it.
> >
> > Regards,
> > - Graeme -
> > Ok thanks. We start from the opposite. cryptographer a string with
vb.net with the following code, what's the code to decrypt it with DCPCrypt?
>
> Ok thanks. We start from the opposite. cryptographer a string with
> vb.net with the following code, what's the code to decrypt it with
DCPCrypt?
>
> Dim Key() As Byte = {}
> Dim IV() As Byte = {1, 2, 3, 4, 5, 6, 7, 8}
>
> Dim KeyStr As String = "cicciob1"
> Dim vector As String = "12345678"
> Dim inputByteArray(TextBox3.Text.Length) As Byte
> Dim des As New DESCryptoServiceProvider
> 'des.Mode = CipherMode.CBC
> 'des.Padding = PaddingMode.Zeros
> Key = System.Text.Encoding.UTF8.GetBytes(KeyStr)
> inputByteArray = Encoding.UTF8.GetBytes(TextBox3.Text)
>
> Dim ms As New MemoryStream
> Dim cs As New CryptoStream(ms, des.CreateEncryptor(Key, IV),
> CryptoStreamMode.Write)
> cs.Write(inputByteArray, 0, inputByteArray.Length)
> cs.FlushFinalBlock()
>
> TextBox4.Text = Convert.ToBase64String(ms.ToArray)
What did you try in the Pascal side (code please)? Did you decode the
Base64 stream before passing the data to the decryption?
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] "lcl: less with-blocks for FPC 3.1.1"
Am 11.11.2015 18:58 schrieb "Marcos Douglas" : > > Hi, > > Many changes using this comment (in the subject) was made in LCL SVN, > changing the 'with' sintaxe to use a variable instead... why? > > Please, I would like to know if something will change in the new > compiler version using the 'with' sintaxe. > > http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/carbon/carbonthemes.pas?root=lazarus&r1=50303&r2=50302&pathrev=50303 For more details see the "Extending TRect breaks Lazarus" thread :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 10.11.2015 14:37 schrieb "Sven Barth" : > > Am 10.11.2015 12:27 schrieb "Jürgen Hestermann" : > > > > Am 2015-11-10 um 11:32 schrieb Sven Barth: > >> > >> The user doesn't need to know the detail that the value is kept in a temporary register, because that statement by itself is utterly useless for the user, as on load/store architectures like ARM you /always/ have values in registers if they are worked with and the compiler will happily spill around the contents if necessary. > > > > > > Does that mean, that local variables and with statements are treated completely identically? > > Are both held in registers with the same mechanism and will there never be an (speed) adavantage of one of them? > > If there is only the chance that it may speed up the code (even when only on certain platforms) then I would like to know it. > > It always depends on the specific code (its complexity) and the specific compiler settings (optimizations) and maybe also the target architecture (because of register pressure and such). There is nothing general I can say /except/ that the with expression will be evaluated only once. Thus depending on the circumstances a local variable and the usage of with might behave the same. In simple cases the with /might/ be faster because it won't result in the expression result being stored on the stack, but that's by no means a given. So... I quickly rechecked the code and can now make a more fundated statement. In case of a more complex expression (e.g. not a field that's a class or something like that) the expression will be stored in a temporary /variable/ not a register. Thus the generated code should be the same as for a local variable. For non complex expressions the value is used directly (e.g. as if the with didn't happen), though further optimizations (e.g. the regvars optimization) might improve that. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 10.11.2015 12:27 schrieb "Jürgen Hestermann" : > > Am 2015-11-10 um 11:32 schrieb Sven Barth: >> >> The user doesn't need to know the detail that the value is kept in a temporary register, because that statement by itself is utterly useless for the user, as on load/store architectures like ARM you /always/ have values in registers if they are worked with and the compiler will happily spill around the contents if necessary. > > > Does that mean, that local variables and with statements are treated completely identically? > Are both held in registers with the same mechanism and will there never be an (speed) adavantage of one of them? > If there is only the chance that it may speed up the code (even when only on certain platforms) then I would like to know it. It always depends on the specific code (its complexity) and the specific compiler settings (optimizations) and maybe also the target architecture (because of register pressure and such). There is nothing general I can say /except/ that the with expression will be evaluated only once. Thus depending on the circumstances a local variable and the usage of with might behave the same. In simple cases the with /might/ be faster because it won't result in the expression result being stored on the stack, but that's by no means a given. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 10.11.2015 09:40 schrieb "Jürgen Hestermann" : > > Am 2015-11-09 um 14:26 schrieb Sven Barth: >> >> >> > The docs already note that the compiler uses a temporary register >> > for 'With'. >> > http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 >> > Of course if there is no register left the compiler uses the stack. >> >> Please note that this is an implementation detail. The point a user should care about is that the expression of the with is evaluated only once (before the block of the with is entered). Everything else is up to the compiler. >> (I would prefer if it wouldn't be mentioned as is in the documentation) >> >> > This information is very important IMO. > The programmer should know which coding has which performance. Which is solved by saying that the expression is only evaluated once. The user doesn't need to know the detail that the value is kept in a temporary register, because that statement by itself is utterly useless for the user, as on load/store architectures like ARM you /always/ have values in registers if they are worked with and the compiler will happily spill around the contents if necessary. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 09.11.2015 13:11 schrieb "Mattias Gaertner" : > > On Mon, 9 Nov 2015 10:48:02 + > Lukasz Sokol wrote: > > >[...] > > Thanks, I believe, this should be added into the docs somewhere ;) if it's not already there. > > The docs already note that the compiler uses a temporary register > for 'With'. > > http://www.freepascal.org/docs-html/ref/refsu58.html#x155-16500013.2.8 > > Of course if there is no register left the compiler uses the stack. Please note that this is an implementation detail. The point a user should care about is that the expression of the with is evaluated only once (before the block of the with is entered). Everything else is up to the compiler. (I would prefer if it wouldn't be mentioned as is in the documentation) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Extending TRect breaks Lazarus
Am 06.11.2015 17:59 schrieb "Marco van de Voort" : > > On Fri, Nov 06, 2015 at 05:42:39PM +0100, Michael Van Canneyt wrote: > > > by Delphi compatibility... > > > > Ehm. How can "with" ever be safe ? > > Btw the case that I fixed was like this > > procedure TSomeForm.Getwind... > > procedure setwidthheight(const r : TRect); inline; > begin > with R do >begin > width:=right-left; > height:=bottom-top; > end; > end; > > begin > ... > setwidtheight(r); > end > > In such case fixing with SELF doesn't work, because self isn't allowed in > the nested function. I had to strip the WITH. Self really isn't allowed in nested functions? O.o Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] A big thank you!
Am 05.11.2015 06:50 schrieb "Ondrej Pokorny" : > > On 05.11.2015 01:02, Anthony Walter wrote: >> >> Regarding the state of generics, Sven has crushed it. Using trunk I haven't had a compiler problem with them in while. I consider them solid at this point. Go Sven! > > > I know Sven is working hard on them! I didn't want to offend anybody! I didn't take any offence, but if you have problems with generics I need to know whether I've already fixed them or don't even know about them. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] A big thank you!
Am 04.11.2015 21:03 schrieb "Ondrej Pokorny" : > In particular I don't use Generics because of the issues with compiler and CodeTools. I can live without them. (I am not telling that I don't like them - I do.) Issues that are addressed in 3.0.0? Issues fixed in 3.1.1? Reported issues? Unknown issues? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
Am 31.10.2015 00:14 schrieb "Bo Berglund" : > The biggest hurdle I have now is getting a TCP socket component > working so I can plug it into the problem unit. I have tried several > different approaches but am unfortunately not done yet. And I hesitate > to ask more questions here because I feel I am getting flamed for not > getting how it should be done. :( Simply ignore those flaming answers. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying (attn: Michael Schnell)
Am 26.10.2015 10:59 schrieb "Michael Schnell" : > > On 10/26/2015 10:09 AM, Mattias Gaertner wrote: >> >> The point is that it is annoying. If you don't know how to fix it, then please remove it before you send the mail. > > I am rather sure that it's not added to the thread by my postings. *Everybody* should remove that nonsense before sending. If you look at this month's archive you'll see that it's only your mails that add this (see here: http://lists.lazarus.freepascal.org/pipermail/lazarus/2015-October/thread.html ). Your mail today regarding the widgetset initialization added yet another "*SPAM*" for example. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: *SPAM* Re: Lazarus implementation of TListView etc?
Am 26.10.2015 09:29 schrieb "Michael Schnell" : > > On 10/23/2015 05:01 PM, Sven Barth wrote: >> >> >> It will depend on the specific initialization whether it can do any harm (especially with the widgetset not initialized) if left in... >> > So you suggest that they would not do any API calls to any external Widget Set that in the target environment might not exist ? Yes and Matthias did indeed confirm that. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
Am 23.10.2015 14:29 schrieb "Bo Berglund" : > So I am a bit surprised that just using this unit would make the FPC > command program not work... It's not exactly FPC's fault, but more that one must not take one's environment for granted. E.g. on Windows you basically always have a GUI which is provided by the core OS (yes, there are things like headless servers or the new Windows 10 for IoT). On Linux systems on the other hand the GUI is entirely optional and provided by the distribution (I simplified here). In addition there can be multiple GUI toolkits (GTK and Qt to name two). If you now have for some reason a dependency on a Qt library but try to run it on a system without Qt your applications won't work. This part is solved by not using the Interfaces unit which is required for LCL GUI applications and which pulls in the widgetset (WinAPI, GTK, Qt, etc.) dependency (you are already doing this). However there /might/ be unit initialization sections in the LCL units that rely on the fact that the widgetset had been initialized (because the Interfaces unit is usually one of the first used in the program file) and thus will result in a crash during the initialization of the unit. Again this does not happen with Delphi's VCL as there is no such widgetset abstraction like the LCL has, because it directly accesses the WinAPI (which is always there). So I at least suggest you to split the GUI and non-GUI parts of the unit to be on the really safe side. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
Am 23.10.2015 14:20 schrieb "Michael Schnell" : > > On 10/23/2015 02:12 PM, Sven Barth wrote: >> >> He simple needs to get the unit to compile (which he did by adding the LCL dependency) and stay clear from using any of the code that might use GUI. In that case there will be no dependency on a specific GUI, because the Interfaces unit is missing and the compiler might even smartlink away the GUI-related code that isn't used anyway. > > What about code in the "initialization" section of the multiple units that will get pulled even if using a single GUI related unit from the LCL ? > Those and the code they link to would remain. It will depend on the specific initialization whether it can do any harm (especially with the widgetset not initialized) if left in... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
Am 23.10.2015 09:45 schrieb "Michael Schnell" : >> In this case I do not want to re-invent all of the communications and data parsing code... > > You obviously are out of luck (As already discussed, additionally to the "visual-component" issues, the Event-queue issue will hit you as well. To solve this, non-RAD will not be enough.). > > There is no shortcut on this way. That is why I recommended to do a standard GUI application with Lazarus. I somehow have the feeling that you and Graeme as well don't understand what Bo's precise problem is. He has a unit which is a collection of various different methods, classes, whatever. Some of these are related to GUI components (e.g. TTreeView) while others are not. He wants to use the non-GUI related code in his project without restructering the unit (for now). So this has /nothing/ to do with RAD or hom writing a console application or whatever. He simple needs to get the unit to compile (which he did by adding the LCL dependency) and stay clear from using any of the code that might use GUI. In that case there will be no dependency on a specific GUI, because the Interfaces unit is missing and the compiler might even smartlink away the GUI-related code that isn't used anyway. TL;DR: Yes, Bo should restructure his code, but he does not /need/ to do so right now. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
Am 23.10.2015 07:39 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > Then refactor / clean-up the code to remove such "gui" dependencies if > you want a true console application. Windows always has a GUI - so there > you can get away with including GUI units, widgets or clipboard in your > "console" application. But for Unix-based systems that have true > headless environments, you *must* create a true console application, > otherwise the application will not run. While I agree that Bo should refactor his code three is also the point that including just the units does no harm as Matthias has said. Only the "Interfaces" unit does that, cause that is the one that binds the components to the widgetset and is only used in the main program. This is especially true if the code related to the GUI components isn't even used (yes, I knew such stuffed units as well -.- ). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hour of Code 2015
Am 22.10.2015 22:39 schrieb "Johannes W. Dietrich" < j.w.dietr...@medizinische-kybernetik.de>: > > The Hour of Code is coming again! > > The Hour of Code, a one-hour introduction to computer science, is a global movement reaching tens of millions of students in more than 180 countries. In celebration of the Computer Science Education Week during December 7-13, 2015, its goal is to give every student the opportunity to learn the foundations of programming and information technology. > > Anyone can organize an Hour of Code event, anywhere in the world. If you are a teacher, parent or potential tutorial partner you might want to register at http://hourofcode.com to support the movement. > > The broad support of Lazarus and Free Pascal for a plethora of operating systems and platforms opens a great opportunity to communicate solid programming skills to students. > That "Hour of Code" project is a really nice idea (I especially loved last year's Frozen related tutorials ^^). I hope someone finds the time and inspiration to do something Pascal related :D Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
