Re: [fpc-pascal] Sets & FPC
On 21 Feb 2010, at 07:26, Justin Smyth wrote: > I've done the bit Micheal suggest now which i highlight TWMDrawItem it says > its comes from TLMDrawItems. > > i still get Error: Incompatible types: got "TOwnerDrawStateType" expected > "" Can you post the full program somewhere? (or the full sources to another, smaller, program that demonstrates the same problem) Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
y := case Other of bla : 'hello'; foo : 'bye'; baz : 'adius'; end; What do you gain with this? Doesn't look much different to case Other of bla : y := 'hello'; foo : y := 'bye'; baz : y := 'adius'; end; Shorter write imho. Is that realy a reason for adding yet another extension to Pascal? This is C thinking. I don't care about a word more or less to write if only the *reading* of source code is easy (and the logic of the language is clear). But each variant in writing makes it harder to understand a source code (especially for newbies to whom the learning curve gets steeper and steeper with each of such 'extensions'). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sets & FPC
The orginal code comes from JVCL , which wont complile under FPC , the actual unit is jvlistbox.pas I have since looked at CustomListBox.inc and made a few change , basically not copying ItemState to a variable but directly doing the checking agaist it procedure TJvCustomListBox.CNDrawItem(var Msg: TLMDrawListItem); begin with Msg.DrawListItemStruct^ do begin Canvas.Handle := hDC; Canvas.Font := Font; Canvas.Brush := Brush; if Integer(itemID) >= 0 then begin if odSelected in ItemState then begin Canvas.Brush.Color := FSelectedColor; Canvas.Font.Color := FSelectedTextColor; end; if (([odDisabled, odGrayed] * ItemState) <> []) or not Enabled then Canvas.Font.Color := FDisabledTextColor; end; if Integer(itemID) >= 0 then DrawItem(ItemID, Area, ItemState) else begin if Background.DoDraw then begin Perform(WM_ERASEBKGND, Canvas.Handle, 0); if odFocused in ItemState then DrawFocusRect(hDC, Area); end else begin Canvas.FillRect(Area); if odFocused in ItemState then DrawFocusRect(hDC, Area); end; end; Canvas.Handle := 0; end; end; On DrawItem i get this error Error: Incompatible type for arg no. 3: Got "TBaseOwnerDrawState", expected "TOwnerDrawState" I'm Using FPC 2.2.4 & Lazarus X64 9.28.2 ( this is the only one i can debug with in X64). Kind Regards - Original Message - From: "Jonas Maebe" To: "Justin Smyth" ; "FPC-Pascal users discussions" Sent: Sunday, February 21, 2010 8:11 PM Subject: Re: [fpc-pascal] Sets & FPC On 21 Feb 2010, at 07:26, Justin Smyth wrote: I've done the bit Micheal suggest now which i highlight TWMDrawItem it says its comes from TLMDrawItems. i still get Error: Incompatible types: got "TOwnerDrawStateType" expected "" Can you post the full program somewhere? (or the full sources to another, smaller, program that demonstrates the same problem) Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Memcached interface for FPC available already?
Hi, Is somebody aware of an fpc interface for the memcached protocol? (See http://memcached.org/) As there seem to be some projects using fpc to provide web content and memcached seems to be one of the more important techniques used on bigger websites there may already be someone who wrote some interface for fpc. I did give it a try myself implementing the plain text protocol using the LNet TLTcp class which seems to work fine. I already implemented the main protocol functions. Also gave the binary protocol a try, but there I'm having trouble with sending the variable length body data. As LNet seems to be a 'web' project itself it may be a nice idea to add a MemcachedClient unit. Before offering this project my amateuristic attempt I'd like to know if and how others did the job. Mark ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sets & FPC
On 21 Feb 2010, at 13:20, Justin Smyth wrote: > The orginal code comes from JVCL , which wont complile under FPC , the actual > unit is jvlistbox.pas Without full source code that compiles rather than uncompilable snippets it takes a lot more time to help you. Please post the full source code that you are trying to compile somewhere and I'm certain that you'll get both an explanation of what was going wrong and a solution in the very next reply. > I'm Using FPC 2.2.4 & Lazarus X64 9.28.2 ( this is the only one i can debug > with in X64). You mean on Win64 (debugging work fine out of the box on Mac OS X/x64 and Linux/x64). See http://forum.lazarus.freepascal.org/index.php/topic,8669.msg41884.html#msg41884 for how to solve the debugging problems on Win64 on 2.4.0. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
ik wrote: > On Sat, Feb 20, 2010 at 20:01, Jürgen Hestermann > mailto:juergen.hesterm...@gmx.de>> wrote: > > > > y := case Other of > bla : 'hello'; > foo : 'bye'; > baz : 'adius'; > end; > > > What do you gain with this? > Doesn't look much different to > > > case Other of > bla : y := 'hello'; > foo : y := 'bye'; > baz : y := 'adius'; > end; > > > Shorter write imho. > Which also means "less chance of mistake". For example, if you decide later to change "y" to "y1", you only have to change the code in one place, not three. Functional "case" and "if" are not only from Ruby, also from all functional languages (sml, ocaml), also Python and even C have functional "if". I'm not saying that this is some revolutional or essential feature. But just because "we can work without it" doesn't mean it's totally useless :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Does this innovation makes "case" a function? procedure SomeProc(const v: string); SomeProc ( case Other of a: 'a'; b: 'b'; end; ); Imho, this reduces the code readability. thanks, dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, dmitry boyarintsev said: > Does this innovation makes "case" a function? I'd rather say an expression. > procedure SomeProc(const v: string); > > SomeProc ( case Other of > a: 'a'; > b: 'b'; >end; ); > > Imho, this reduces the code readability. Even if you are a favorite of said functionality, it should not be added adhoc, but integrated in the language definition. (but that would mean it is no longer Pascal). I don't see the use either. Moreover the benefit/cost (work) is way to high IMHO ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: FPC from subversion without root access
Thank you very much 2010/2/21 Marc Weustink : > Osvaldo Filho wrote: >> >> Thank you. >> >> I have my own compiler - files from another computer - not the ubuntu >> package. >> >> How can I say the Make program where are the files of the compiler? >> They are in: ~/apps/fpc/bin and ~/apps/fpc/lib > > add ~/apps/fpc/bin to your path > > ( if you use bash: add the following to your ~/.bach_profile > PATH=$HOME/apps/fpc/bin;$PATH > ) > > and add the following lines to your ~/.fpc.cfg > > -Fu~/apps/fpc/lib/fpc/$fpcversion/units/$fpctarget > -Fu~/apps/fpc/lib/fpc/$fpcversion/units/$fpctarget/* > -Fu~/apps/fpc/lib/fpc/$fpcversion/units/$fpctarget/rtl > > > if you don't have a ~/.fpc.cfg and do have a /etc/fpc.cfg you can add the > following as first to your new ~/.fpc.cfg > > #INCLUDE /etc/fpc.cfg > > > Marc > > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On 21 February 2010 17:00, Michalis Kamburelis wrote: > > Which also means "less chance of mistake". For example, if you decide > later to change "y" to "y1", you only have to change the code in one > place, not three. Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'? http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit You only need to change one variable, and all other instances will change to. And syncron-edit applies to any selection of text. So already works in more cases. I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, Feb 21, 2010 at 9:03 PM, Graeme Geldenhuys wrote: > I vote against adding this language feature. It's not pascal-like and > actually makes the code harder to read. It also only applies to simple > assignment. Case begin..end blocks can do much more than simple > oneliners. Maybe some-one would like to catch-up with Delphi/Prism? Wouldn't be possible to start a Prism mode to support new Delphi syntax features? (or modeswitch, just like objectivec)? I don't volunteer :) I'm happy with the present FPC syntax. thanks, dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, dmitry boyarintsev said: > > assignment. Case begin..end blocks can do much more than simple > > oneliners. > > Maybe some-one would like to catch-up with Delphi/Prism? > Wouldn't be possible to start a Prism mode to support new Delphi > syntax features? (or modeswitch, just like objectivec)? IMHO Prism is not even Delphi. Just recycling of the brand. I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode). If a feature is not supported by delphi, the usage is usually very low (since most people don't even know about it, and some are limited by compatibility requirements), except in the rare cases that it is really used a lot (like in the past the pointer overindexing and the exit() features. But they are no longer extensions, since D2009 Delphi has them too) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, Feb 21, 2010 at 9:22 PM, Marco van de Voort wrote: > I'd rather see the time spent on features that really matter (like generics, > SEH/COM support, unicode). +1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Graeme Geldenhuys wrote: > On 21 February 2010 17:00, Michalis Kamburelis > wrote: >> Which also means "less chance of mistake". For example, if you decide >> later to change "y" to "y1", you only have to change the code in one >> place, not three. > > > Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'? > > http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit > > You only need to change one variable, and all other instances will > change to. And syncron-edit applies to any selection of text. So > already works in more cases. > Which is cool, but only if you and all your contributors use Lazarus for all your editing. The fact that Lazarus makes something easier should not be a reason to reject the language feature. > > I vote against adding this language feature. It's not pascal-like and > actually makes the code harder to read. It also only applies to simple > assignment. Case begin..end blocks can do much more than simple > oneliners. > This is a matter of taste, I can imagine uses when at least functional "if" would make code *more* readable. Noone forces programmers to convert all their case/if to functional versions if they look unreadable. The functional variants are supposed to be used in particular situations, when they make sense. Mind you, I'm not saying I'm a fan or a big proponent of this feature. I do not own Delphi since a long time, being happy with FPC, so I'm also not interested in compatibility. Mostly, I'm playing devil's advocate here :), and I didn't see yet a good argument against this feature (and I see cases when it would be useful). The fact that it makes some cases less readable doesn't count here imho (because it's optional, and can make other code more readable). Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
In our previous episode, Michalis Kamburelis said: > > You only need to change one variable, and all other instances will > > change to. And syncron-edit applies to any selection of text. So > > already works in more cases. > > > > Which is cool, but only if you and all your contributors use Lazarus for > all your editing. > The fact that Lazarus makes something easier should > not be a reason to reject the language feature. It also proves that such solution external to the language is possible. That weakens the case for a language feature > This is a matter of taste, I can imagine uses when at least functional > "if" would make code *more* readable. Noone forces programmers to > convert all their case/if to functional versions if they look > unreadable. The functional variants are supposed to be used in > particular situations, when they make sense. That is always the reason, but every feature must be implemented tested, supported, and may clash with future extensions. "it wouldn't hurt", and a bit of typing, and some fairly theoretic case about readability are IMHO quite weak arguments. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] some new features to delphi prisem
Hello FPC-Pascal, Sunday, February 21, 2010, 7:29:54 PM, you wrote: MK> This is a matter of taste, I can imagine uses when at least functional MK> "if" would make code *more* readable. Noone forces programmers to MK> convert all their case/if to functional versions if they look MK> unreadable. The functional variants are supposed to be used in MK> particular situations, when they make sense. For me the bigger problem is that both statements change its behavior in function of its context. if a=b then 1 else 2; this is a pascal error, but z := if a=b then 1 else 2; Is it correct ? From my point of view is much more reasonable to use something like: z := iff(a=b,1,2); But to me it looks awful and a bit of c-ism and really horrible code could be written: z: Boolean; begin z := iff(a=b,iif(b=2,a=b,b<>a),not(a=b)); -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sun, 21 Feb 2010 20:37:12 +0100, JoshyFun wrote about Re[2]: [fpc-pascal] some new features to delphi prisem: > Sunday, February 21, 2010, 7:29:54 PM, you wrote: > > MK> This is a matter of taste, I can imagine uses when at least > MK> functional "if" would make code *more* readable. Noone forces > MK> programmers to convert all their case/if to functional versions > MK> if they look unreadable. The functional variants are supposed to > MK> be used in particular situations, when they make sense. > > For me the bigger problem is that both statements change its behavior > in function of its context. > > if a=b then 1 else 2; That is an attempt at a statement, but what is being offered in Prism is an enhanced *expression* syntax. > this is a pascal error, but > > z := if a=b then 1 else 2; This is actually valid ALGOL 60 and/or ALGOL 68. Conditional expressions were available in both languages. I think Niklaus Wirth continued with this in ALGOL W, but dropped it from Pascal. Note that the ALGOLs required the "else" clause, as does C today (see below). > Is it correct ? From my point of view is much more reasonable to use > something like: > > z := iff(a=b,1,2); This is over-punctuated Visual BASIC. Yuck. > But to me it looks awful and a bit of c-ism and really horrible code > could be written: > > z: Boolean; > begin > z := iff(a=b,iif(b=2,a=b,b<>a),not(a=b)); Mega-yuck!! I can only infer that you don't write C. The C equivalent is: z = a == b ? 1 : 2; It's terse, but one gets used to it. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] some new features to delphi prisem
Hello FPC-Pascal,
Sunday, February 21, 2010, 9:32:50 PM, you wrote:
DWN> This is actually valid ALGOL 60 and/or ALGOL 68. Conditional
DWN> expressions were available in both languages. I think Niklaus Wirth
DWN> continued with this in ALGOL W, but dropped it from Pascal.
DWN> Note that the ALGOLs required the "else" clause, as does C today (see
DWN> below).
I'm the opposite of an compilers expert, also never learned Algol,
modula, eiffel or non "main-stream" languages, except Forth. So I
known my opinion is not an expert opinion, just an opinion only.
After this preamble :) I must say that this is Pascal, not Algol ;)
>> Is it correct ? From my point of view is much more reasonable to use
>> something like:
>> z := iff(a=b,1,2);
DWN> This is over-punctuated Visual BASIC. Yuck.
iff is valid in VB ? Just a coincidence, I was trying to note the
"if-function".
>> But to me it looks awful and a bit of c-ism and really horrible code
>> could be written:
>> z: Boolean;
>> begin
>> z := iff(a=b,iif(b=2,a=b,b<>a),not(a=b));
DWN> Mega-yuck!!
I even do not know the result :)
DWN> I can only infer that you don't write C. The C equivalent is:
Oh yes, I write and wrote C/C++ that's the reason I hate such things,
like:
if (a=a++==a) {..}
It's a funny entertainment to try to know which exactly that condition
will execute.
DWN>z = a == b ? 1 : 2;
DWN> It's terse, but one gets used to it.
In near 20 years I was unable to find the reason and need of such
constructions, even when my first computer only have 3 Kb for source
code.
--
Best regards,
JoshyFun
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: > > IMHO Prism is not even Delphi. Just recycling of the brand. +1 > I'd rather see the time spent on features that really matter (like generics, > SEH/COM support, unicode). Definitely. I would like to add 'Interface Delegation' to that list. It's a vital part of Interfaces that is not implemented in FPC yet. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
Marco van de Voort wrote: > > It also proves that such solution external to the language is possible. That > weakens the case for a language feature My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
