Re: [fpc-devel] Bugtracker - registration
On 09 Feb 2010, at 23:27, Nikolai Zhubr wrote: > 09.02.2010 16:17, Michael Van Canneyt: >> For some reason, mail.ru blocks our mail server, this is why you don't >> receive the confirmation email. >> >> I have filed a request to stop blocking. Luckily I speak Russian :-) >> >> I hope you'll receive this mail at least :-) > > Hmmm, I suspected this, therefore I've already whitelisted *.freepascal.org > for my account, and I do receive mailing list posts with no problem. Whitelisting domains/addresses cannot help in this case because the mails are already rejected at the SMTP handshake. The bug reporting mails are indeed sent from another server than the one used for the mailing list, namely by bugs.freepascal.org (62.166.198.202). That one is blacklisted by mail.ru for some reason. It's not on any public rbl as far as I can see. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bugtracker - registration
09.02.2010 16:17, Michael Van Canneyt: For some reason, mail.ru blocks our mail server, this is why you don't receive the confirmation email. I have filed a request to stop blocking. Luckily I speak Russian :-) I hope you'll receive this mail at least :-) Hmmm, I suspected this, therefore I've already whitelisted *.freepascal.org for my account, and I do receive mailing list posts with no problem. Maybe bugtracker uses some other mailserver for confirmation requests, or maybe they block it in such way that even their whitelist has no effect... Anyway, if it gets too hard I'll use gmail instead. Sorry for the extra burden with this, and thank you! Nikolai Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: changing conditional compilation
2010/2/9 Jonas Maebe :
>
> On 09 Feb 2010, at 01:24, Flávio Etrusco wrote:
>
>>> As far as I know, that's how macros behave.
>>>
>>> E.g.:
>>>
>>> {$macro on}
>>>
>>> {$define xxx:=1}
>>>
>>> {$if xxx}
>>> begin
>>> end.
>>> {$endif}
>>>
>>> If you undefine "xxx", you'll get a compile time error.
>>>
>>> Downside: they don't work with booleans for some reason, only with
>>> integers...
>>
>> Hi Jonas,
>> As you can imagine I'd prefer to "solve" the $ifdef "problem" ;-)
>
> To be honest: no, I can't imagine why you would prefer that.
Because everybody automatically uses $ifdef and most of the code would
work with minor intervention. E.g. we usually use something like
{.$define EnableDocking} to undefine the symbol. You'd just have to
force it explicitly $undef or some kind of {$define EnableDocking
disable} or 'false', or something.
> The entire
> difference between $ifdef and $if is that $if checks the value of something
> (and hence will give an error if the symbol is undefined) and $ifdef checks
> whether it is defined or not. As far as I can tell, you would simply like to
> be able to use boolean constants in $if expressions.
This would solve the problem for my code, not conditionals I'm trying
to use on 3rd party code...
>> Yes, I noticed the problem with bools - and that it would fail with
>> "string found but boolean expected" if the name was undefined -,
>
> The latter is the behaviour you want, no?
Yes - apart from puzzling error message to the casual users - but it'd
require to set a convention on the Macro value for on/off and back to
possibly causing errors due to typos.
> Jonas
>
> PS: please reply to the list___
Sorry, I just skip the list sometimes when I think the post will be
just noise to other people. I'd certainly get back to it when I have
something relevant to say ;-)
Best regards,
Flávio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bugtracker - registration
On Tue, 9 Feb 2010, Nikolai Zhubr wrote: Hello people, Apparently there is some problem with bugtracker. Yesterday I tried to create an account, but never got a confirmation email. I then tried a "lost password" feature, just in case, but got no reasult either. Mantis keeps boycotting me absolutely. A minute ago I also registered at community.freepascal.org (seemingly successfull), but bugtracker refuses to accept the respective address and password too (despite this is clearly mentioned there as a possible option). Or am I doing something really really stupid? :) For some reason, mail.ru blocks our mail server, this is why you don't receive the confirmation email. I have filed a request to stop blocking. Luckily I speak Russian :-) I hope you'll receive this mail at least :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bugtracker - registration
Hello people, Apparently there is some problem with bugtracker. Yesterday I tried to create an account, but never got a confirmation email. I then tried a "lost password" feature, just in case, but got no reasult either. Mantis keeps boycotting me absolutely. A minute ago I also registered at community.freepascal.org (seemingly successfull), but bugtracker refuses to accept the respective address and password too (despite this is clearly mentioned there as a possible option). Or am I doing something really really stupid? :) Thank you! Nikolai ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: changing conditional compilation
On 09 Feb 2010, at 01:24, Flávio Etrusco wrote:
As far as I know, that's how macros behave.
E.g.:
{$macro on}
{$define xxx:=1}
{$if xxx}
begin
end.
{$endif}
If you undefine "xxx", you'll get a compile time error.
Downside: they don't work with booleans for some reason, only with
integers...
Hi Jonas,
As you can imagine I'd prefer to "solve" the $ifdef "problem" ;-)
To be honest: no, I can't imagine why you would prefer that. The
entire difference between $ifdef and $if is that $if checks the value
of something (and hence will give an error if the symbol is undefined)
and $ifdef checks whether it is defined or not. As far as I can tell,
you would simply like to be able to use boolean constants in $if
expressions.
Yes, I noticed the problem with bools - and that it would fail with
"string found but boolean expected" if the name was undefined -,
The latter is the behaviour you want, no?
Jonas
PS: please reply to the list___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ref.tex documentation mistake
On Tue, 9 Feb 2010, Graeme Geldenhuys wrote: Michael Van Canneyt wrote: It was already on my TODO list for 2.4 (together with resources), but I didn't get around to it. Thanks, I remember a while back you mentioned you had a documentation todo list for FPC 2.4 release - I assumed you completed the todo list as 2.4 is already released. With that, I thought I would mention the UnicodeString oversight. ;-) If my todolist was a mountain, mount Everest would look like a mere mole heap in comparison. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ref.tex documentation mistake
Michael Van Canneyt wrote: > > It was already on my TODO list for 2.4 (together with resources), > but I didn't get around to it. Thanks, I remember a while back you mentioned you had a documentation todo list for FPC 2.4 release - I assumed you completed the todo list as 2.4 is already released. With that, I thought I would mention the UnicodeString oversight. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ref.tex documentation mistake
On Tue, 9 Feb 2010, Graeme Geldenhuys wrote:
Hi Michael,
I updated my fpcdocs repository from r625 (pre 2.4.0 release) to r634 (post
2.4.0 release), but still found a bug in documentation and missing
information related to FPC 2.4.0
1) Wrong Information:
---[ ref.tex line 1340 ]-
\subsection{WideStrings}
\index{Widestring}\index{Types!Widestring}\index{Types!Reference counted}
\keywordlink{Widestring}
Widestrings (used to represent unicode character strings) are implemented
in much
the same way as ansistrings: reference counted, null-terminated arrays,
only they
are implemented as arrays of \var{WideChars} instead of regular \var{Chars}.
--
WideString is not reference counted on all platforms. On Windows it is
_not_ reference counted as far as I know. This is done to be compatible
with COM string type behaviour.
2) Missing information:
Under "Character Types", there is no documentation on the new type
"UnicodeString". To add to this, UnicodeString is exactly the same as
WideString _except_ that it IS reference counted on all platforms.
It was already on my TODO list for 2.4 (together with resources),
but I didn't get around to it.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ref.tex documentation mistake
Hi Michael,
I updated my fpcdocs repository from r625 (pre 2.4.0 release) to r634 (post
2.4.0 release), but still found a bug in documentation and missing
information related to FPC 2.4.0
1) Wrong Information:
---[ ref.tex line 1340 ]-
\subsection{WideStrings}
\index{Widestring}\index{Types!Widestring}\index{Types!Reference counted}
\keywordlink{Widestring}
Widestrings (used to represent unicode character strings) are implemented
in much
the same way as ansistrings: reference counted, null-terminated arrays,
only they
are implemented as arrays of \var{WideChars} instead of regular \var{Chars}.
--
WideString is not reference counted on all platforms. On Windows it is
_not_ reference counted as far as I know. This is done to be compatible
with COM string type behaviour.
2) Missing information:
Under "Character Types", there is no documentation on the new type
"UnicodeString". To add to this, UnicodeString is exactly the same as
WideString _except_ that it IS reference counted on all platforms.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fpsigprocmask
On 02/08/2010 06:45 PM, Martin Schreiber wrote: > The potential problems of FPC libc unit (packages/libc/src/libc.pp) is that > it > is not included in .deb packages by default, that it is i386-linux only, that > it is not maintained maybe and that it is possible that FPC team will remove > the file from the distribution in future. > mselibc.pas is maintained by me, it is included in MSEgui distribution, it is > Linux i386 and x84_64 and it will be ported to other systems by me if > necessary. > Great for mseide, but not good for my Lazarus add-on package which obviously will not be maintained by you. Same should use what the FPC-RTL offers. At the moment I simply use the functions in the libc unit instead of those with the same name from msesys, but on the long run this should be replaced by the "new Linux RTL" as described by Marco. I feel this would not harm when introduced in the mseide code tree freeing you from part of the maintenance obligation. Moreover a main the target of this package that enables applications for "headless" hardware, obviously is non-X86 archs. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fpsigprocmask
In our previous episode, Martin Schreiber said: > > Of course it does not, as in the msesys unit the same code (just > > "external ") as in libc is available and thus introduced the same > > potential problems. > > The potential problems of FPC libc unit (packages/libc/src/libc.pp) is that > it > is not included in .deb packages by default, that it is i386-linux only, that > it is not maintained maybe and that it is possible that FPC team will remove > the file from the distribution in future. > mselibc.pas is maintained by me, it is included in MSEgui distribution, it is > Linux i386 and x84_64 and it will be ported to other systems by me if > necessary. Well, baseunix is maintained by the FPC core, works on all *nix platforms already is packaged in all distro's, and still you won't use it :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
