Re: [fpc-devel] Does FreePascal support named parameters?
On 2 April 2013 04:37, Anthony Walter sys...@gmail.com wrote: Name parameters are supported through variants. procedure Test(V: Variant); begin V.SomeMethod(12, ParamOne := '', ParamTwo := 12.5); end; Internally what happens is V is checked to for IDispatch, next GetIDsOfNames is called to find the dispid of SomeMethod, then a variant array of arguments is constructed (with the names), and finally Invoke is called. This comes from the Microsoft COM concept of automation, though automation encompasses a bit more than IDispatch, including marshalling, remoting, and error handling; passing errors back from a remote machine for example. People don't really use this stuff much anyone, nor is their much demand for people with knowledge of the inner workings of COM. But if you want, you can write your own objects which implement IDispatch. See the source code in the download link on this page: http://www.codebot.org/delphi/?doc=9573 ScripTools.pas class TScriptlet which exposes arbitrary pascal methods and properties to a Javascript engine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Does this work on Linux as well, or is it only for Windows? -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
I have observed a lot of Delphi developers who have written code that needs or depends on the features like anonymous methods, generics, RTTI give up porting to FPC because it proved too difficult, but then it turns out those libraries could greatly enhance FPC usage. So I think this bullet must be bitten once to enable those libraries to be ported over, by FPC achieving parity or syntax compatibility in that area. Once that is done the FPC development team should make it clear where they don't agree with Embarcadero's approach, so developers who want to port to FPC don't depend on any funny stuff Embarcadero might concoct in the future. It may even turn out that in the future Delphi will be the one that has to follow FPCs lead or accommodate it, if this issue is successfully resolved, just as Microsoft has had to accommodate Linux. The more developers can accomplish with FPC and Linux the less relevant the restrictive and proprietary Windows and Mac environments become and that is what FPC devs should keep in sight. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On 29 November 2012 10:08, Alexander Klenin kle...@gmail.com wrote: On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this. I have rather curious story behind this request. In Russia, schoolchildren must pass Unified State Exam (ЕГЭ in russian) upon graduation. The exam on informatics includes requirement to write a simple program. Currently, the program is allowed to be written in any programming language, but it is written on paper, the pupil must precisely specify the language, and the program is graded manually by teachers. Some pupils wrote in Free Pascal, which is moderately popular in schools (something around 20% IIRC). Several of them omitted initialization of global arrays based on the assumption that they will be zeroed automatically. Those pupils were failed for that, and the graders stated that even if current implementation happens to zero global variables, this is not documented and so is merely an implementation artifact which must not be relied upon. Hence, this omission resulted in lower grades for some schoolchildren. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel The teachers were correct. A program's correctness stands purely on the states defined by the meaning of its texts, not on some compiler behaviour or some execution or implementation model. The teachers are at fault here. I don't suppose they understand that themselves, as the students wouldn't err if the teachers impressed that principle before the test. The graders were right but for the wrong reasons. In the pure sense defined by the meaning of the texts the initial states are undefined if the variables are not expressly initialized. We must learn to work with program texts while (temporarily) ignoring that they admit the interpretation of executable code. http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html. As some of you might suspect I am a fan of the late Edsger Dijkstra, That paper is a bit of a (quite justified) rant but some of the issues are covered in his other papers, but it has taken me some time to begin to grok the foundations of his perspective. I am also not that good a programmer. :-( -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On 5 January 2013 13:39, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Sat, 5 Jan 2013 13:06:42 + Frank Church vfcli...@gmail.com wrote: [...] It is obvious that Unicode is not a simple topic and among FPC/Lazarus developers/contributors,I suspect that few if any at all, have a detailed grasp of how it all hangs together in the current state of implementation. It brings to mind the parable of the 12 blind men and the elephant. The FPC and Lazarus UTF details are not that difficult. The complexity comes from adding Delphi *, third party libraries and old FPC, Lazarus versions. I think a diagram or graph of Unicode rules and their current state of implementation in FPC/Lazarus would go a long way to helping both developers and end users in this area. It is a topic which comes up regularly and it doesn't show signs of ever going to be properly resolved. For Lazarus: - works with fpc 2.6.x and 2.7.1 - LCL and most code expect ansistrings to hold UTF-8. - pascal sources, lfm, po files are stored in UTF-8 without BOM. Special care has to be taken, when using widestrings/unicodestring. - there are UTF-8 functions and classes (most in package lazutils). - the IDE supports many encodings - all this is documented via wiki and fpdoc - no support for UTF-16 has been started [...] Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Glad to hear this. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreePascal Git Repo and 2_6 branch
On 28 April 2012 18:57, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Graeme Geldenhuys said: To do it the correct way, is a lot of work, hence the reason I stopped mirroring the fixes branches. What I mean by correct way, is cherry-picking the commits from Trunk (master) and applying them in the fixes branch - thus it is one standard git repository (with alternate branches), is more efficient for git to work with, and uses less disk space. But the problem is, it can't be automated (I need to manually track what commits are merged by FPC developers, manually fix conflicts etc) and my free time is very limited. I can try to create some form of automated feed of fixes tree commits + items that are merged. So assume fixes branch rev X merges revision T1,T2,T3 from trunk. You then roughly would do for X in all fixes revs to process since last processing do begin svn diff fixes branch X-1,X temp.patch cherry pick from git trunk to git fixes revs (e.g. T1 T2 T3) git revert all changes to files but not mergeinfo (resolves all conflicts) patch -p0 temp.patch( applies the manually merged fixes) git push/commit whatever end; An innerloop for T1,T2,T3 separately is unfortunately not possible (since manual fixes up might apply to all revs at once) I'm not saying that I will have such info next week, but if you could test if you could get such scenario done with GIT, I can see if I drag such info out of the mergelog package in time. (which I'm still expanding) I doubt it is the same as truly working through GIT (I'm not sure if tracking of line changesets works even if you could all Tx individually), it might be already better since it is automated and has GIT level info per fixes rev what revs were merged from trunk. It assumes GIT can deal with mergeinfo a bit creatively and flexible though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel How about SubGit - http://subgit.com ? I am always on the lookout for the next miracle cure :) Disclaimer: sender of this email knows next to nothing about git and svn interoperability issues. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposed change in Objective-Pascal syntax
On 2 January 2011 16:00, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 30 Dec 2010, at 18:09, Jonas Maebe wrote: So I would propose to change the syntax by moving the external modifier to the same location as where sealed and abstract can be placed for Delphi-style classes. It should be quite easy to modify the Objective-C headers parser script to produce that new syntax. I also think that after this change, the Objective-Pascal syntax can be finalised and considered as stable. Based on the feedback, I've implemented this syntax change. I've also adjusted the Objective-C parser (in svn) and reparsed the Objective-Pascal header translations. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Is there an Objective-Pascal that is not the same of Object Pascal? Is it also compiled by FPC? -- Frank Church === http://devblog.brahmancreations.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
