Re: [fpc-devel] Added new target to fpmake

[Darius Blaszyk]

> - Selection of output format ?
> - Add to zip ?

I created a new patch that implements these options. Can someone please
review the patch and comment on it. Are there any other frequently used
settings or conditions regarding fpdoc that should be taken in the
patch? I'm happy to apply them.

http://bugs.freepascal.org/view.php?id=18050

Regards, Darius

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Max Vlasov]

On Fri, Nov 26, 2010 at 9:45 PM, Nikolay Nikolov <
nick...@users.sourceforge.net> wrote:

> On 11/26/2010 10:42 AM, Max Vlasov wrote:
>
>>
>> Is anyone aware of similar concept in any other OOP language?
>>
> Yes, C++ has it:
> http://duramecho.com/ComputerInformation/WhyHowCppConst.html
>
> It's true that it's a little bit messy, but that's pretty much the norm
> with everything in C++ ;-)
>
>

Thanks, Nikolay, it's interesting information, when I tried to search before
I posted, I didn't use "const", only "read only" so did not find anything. I
already see that it never would be implemented the similar way since in
contrary to  C++ const objects in pascal already can do whatever they want.


Also searching now, found a post

http://community.freepascal.org:1/bboards/message?message_id=256912&forum_id=24082

Where was question about const, but it seems that primary discussion was
about optimization, not preventing from occasional modification.

Max Vlasov
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Nikolay Nikolov]

On 11/26/2010 10:42 AM, Max Vlasov wrote:


Is anyone aware of similar concept in any other OOP language?

Yes, C++ has it:
http://duramecho.com/ComputerInformation/WhyHowCppConst.html

It's true that it's a little bit messy, but that's pretty much the norm 
with everything in C++ ;-)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Jonas Maebe]

On 26 Nov 2010, at 18:59, Tomas Hajny wrote:

> I'm not sure if closing the handle using the platform specific API is
> actually a good idea here, because the RTL is probably not opening the
> file in this case

You're right, so you don't even need that special code. Just change the handle 
and you're fine.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Tomas Hajny]

On Thu, November 25, 2010 18:57, Jonas Maebe wrote:
> On 25 Nov 2010, at 13:21, Jonas Maebe wrote:
>> On 25 Nov 2010, at 12:24, Anton Kavalenka wrote:
>>
>>> What I have to do to properly initialize these defaults for new threads
>>> AFTER capturing StdOut?
>>
>> Store a copy of your stdout in a global variable, and after creating a
>> new thread
>>
>>  close(stdout);
>>  stdout:=myglobalstdout;
>>
>> (and maybe the same for "output").
>
> Actually, that won't work because the different threads will then work on
> a common buffer but with distinct pointers into it. A better solution is
> probably to do this in the intialisation code of each thread instead:
>
> {$ifdef unix}
>   fpclose(ttextrec(stdout).handle);
> {$elsif defined(MSWINDOWS)}
>   { this is a copy of do_close() from the rtl, I don't know whether
> a new handle from a thread can actually have any of these values }
>   if (handle <> StdInputHandle) and
>  (handle <> StdOutputHandle) and
>  (handle <> StdErrorHandle) then
> CloseHandle(ttextrec(stdout).handle);
> {$else}
>   {$error Add support for this platform}
> {$endif}
>
> ttextrec(stdout).handle:=myglobalstdouthandle;

I'm not sure if closing the handle using the platform specific API is
actually a good idea here, because the RTL is probably not opening the
file in this case and trying to close it multiple times (in different
threads) may have unwanted effects (it would result in a failure return
code probably).

BTW, other alternative solutions for the original problem (not necessarily
fitting your needs, just for completeness sake):

- Perform the writes always in one and the same thread dedicated for that
purpose (i.e. have the other threads communicate to that thread using some
sort of inter-thread communication).

- Don't write to stdout but write to your own global (text) variable
instead while ensuring that only one thread is accessing the variable at a
time by your own means.

- Alternative of the above - override Write / WriteLn by your own routine
doing one of the former two.

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: New language feature suggestion (probably not existing in Delphi)

[Sergei Gorelkin]

Max Vlasov пишет:



On Fri, Nov 26, 2010 at 11:42 AM, Max Vlasov > wrote:



An idea here is to introduce a directive (maybe something else, but
directive looks more straightforward), let's call it readonly that
forces the method to be able only to read the fields and properties
of the object it belongs to and forbid any writing. Sure in this
case it only can call only the methods also containing such directive.


Also, one note to consider
It is know that some of OOP concepts can be implemented with procedural 
language. For example, pseudo-encapsulation with the records. 
Ironically, this idea can be implemented using the emulation.


Compare

procedure MyObjFind(var Rec: TMyObjData) with
procedure MyObjFind(const Rec: TMyObjData)

the latter is actual readonly emulation, you won't be able to change 
anything and you won't be able to pass this record by reference to any 
other procedure


I tend to think that the primary goal of introducing 'const' parameters was optimization, not access 
restriction. Although I don't know exactly.


Sergei

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: New language feature suggestion (probably not existing in Delphi)

[Max Vlasov]

On Fri, Nov 26, 2010 at 11:42 AM, Max Vlasov  wrote:

>
> An idea here is to introduce a directive (maybe something else, but
> directive looks more straightforward), let's call it readonly that forces
> the method to be able only to read the fields and properties of the object
> it belongs to and forbid any writing. Sure in this case it only can call
> only the methods also containing such directive.
>
>
Also, one note to consider
It is know that some of OOP concepts can be implemented with procedural
language. For example, pseudo-encapsulation with the records. Ironically,
this idea can be implemented using the emulation.

Compare

procedure MyObjFind(var Rec: TMyObjData) with
procedure MyObjFind(const Rec: TMyObjData)

the latter is actual readonly emulation, you won't be able to change
anything and you won't be able to pass this record by reference to any other
procedure

Max Vlasov
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Max Vlasov]

On Fri, Nov 26, 2010 at 6:57 PM, Sergei Gorelkin wrote:

> Max Vlasov пишет:
>
>
>>   > Speaking of new features, I remember the bunch of them were introduced
>
>> with Delphi 1.0 and many of them were inspired by other languages and
>> dialects. I admit that frequent implementing of features like the one I
>> suggested will make fpc more experimental and less solid. So consider it an
>> idea just thrown in the wild to see whether it will survive or not :)
>>
>>  This particular idea probably won't survive. In 'unsafe' language with
> pointers, there's no way to enforce the restriction you suggest. It will
> only cause annoyance and make people implement 'workarounds'.
>
>
Sergei, around what code? if implemented, by default all methods read/write.
If a developer restricts readonly directive to its own method, it is his own
decision. For example, you're writing method Find, you understand that it
hasn't change anything in the object state, you apply this directive to help
yourself in the future :) if you talk about virtual readonly method someone
introduced, it's similar to private section of object, you can love it or
hate it, but this features exists (sure sometimes bringing real pain :)
restricting usage of this method in other units.

Another example, you successfully wrote first version of a method with
reaonly directive, you try to change something several months later and one
of your changes is try to change a field inside method implementaion, the
compiler points out to the restriction and stops. You have two options: beat
yourself for this silly change or understand that the state changing is
really needed. If the latter, ok, press ctrl-shift-up, and delete reaonly
directive, no problem :)

Max
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Sergei Gorelkin]

Max Vlasov пишет:



 > Speaking of new features, I remember the bunch of them were introduced
with Delphi 1.0 and many of them were inspired by other languages and 
dialects. I admit that frequent implementing of features like the one I 
suggested will make fpc more experimental and less solid. So consider it 
an idea just thrown in the wild to see whether it will survive or not :)


This particular idea probably won't survive. In 'unsafe' language with pointers, there's no way to 
enforce the restriction you suggest. It will only cause annoyance and make people implement 
'workarounds'.


Sergei

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Paul Ishenin]

26.11.2010 22:19, Max Vlasov wrote:
Paul, you mean encouraging them to implement this and return to this 
discussion when D2011(12,13..) implements this? :) Just kidding
I think we need a collaboration between the communities and developers. 
Copperative feature discussion can be a first step in collaboration 
between projects.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Max Vlasov]

On Fri, Nov 26, 2010 at 2:39 PM, Paul Ishenin  wrote:

> 26.11.2010 16:38, Michael Van Canneyt wrote:
>
>> Everything we introduced first Embarcadero has consistently done
>> different, so I would not hope for that.
>>
> Exit(Value) not.
>
> Btw, maybe to discuss new features on Embarcadero forum too before the
> final decision?
>
>
Paul, you mean encouraging them to implement this and return to this
discussion when D2011(12,13..) implements this? :) Just kidding

Speaking of new features, I remember the bunch of them were introduced with
Delphi 1.0 and many of them were inspired by other languages and dialects. I
admit that frequent implementing of features like the one I suggested will
make fpc more experimental and less solid. So consider it an idea just
thrown in the wild to see whether it will survive or not :)

Max
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Michael Van Canneyt]

On Fri, 26 Nov 2010, Paul Ishenin wrote:


26.11.2010 16:38, Michael Van Canneyt wrote:
Everything we introduced first Embarcadero has consistently done different, 
so I would not hope for that.

Exit(Value) not.


I don't see how they could have done that different :)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Paul Ishenin]

26.11.2010 16:38, Michael Van Canneyt wrote:
Everything we introduced first Embarcadero has consistently done 
different, so I would not hope for that.

Exit(Value) not.

Btw, maybe to discuss new features on Embarcadero forum too before the 
final decision?


Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Michael Van Canneyt]

On Fri, 26 Nov 2010, Jonas Maebe wrote:



On 26 Nov 2010, at 11:11, Michael Van Canneyt wrote:


I think this is not bad; the question is whether we can do it on unix.
On Unix, we can currently only check when a threadvar is accessed.


The semantics of those callbacks would be that they are called as soon as the 
RTL is initialised for a thread. On Unix, this is indeed only done on the 
first threadvar access.


If we decide to add this, maybe we should give the users a chance to test for 
this themselves ?

Procedure CheckThreadInitialize;

This way they can call this at the entry point of some externally called 
routines.
For windows, we'd need this 'check' procedure anyway, since there are 2 
notification mechanisms.
(TLS callback and DLL_THREAD_ATTACH)
If the RTL is already initialized for this thread, it would do nothing.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Jonas Maebe]

On 26 Nov 2010, at 11:11, Michael Van Canneyt wrote:


I think this is not bad; the question is whether we can do it on unix.
On Unix, we can currently only check when a threadvar is accessed.


The semantics of those callbacks would be that they are called as soon  
as the RTL is initialised for a thread. On Unix, this is indeed only  
done on the first threadvar access.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Michael Van Canneyt]

On Fri, 26 Nov 2010, Jonas Maebe wrote:



On 25 Nov 2010, at 20:15, Anton Kavalenka wrote:


At 25.11.2010 19:57, Jonas Maebe wrote:
Actually, that won't work because the different threads will then work on 
a common buffer but with distinct pointers into it. A better solution is 
probably to do this in the intialisation code of each thread instead:


{$ifdef unix}
 fpclose(ttextrec(stdout).handle);
{$elsif defined(MSWINDOWS)}
 { this is a copy of do_close() from the rtl, I don't know whether
   a new handle from a thread can actually have any of these values }
 if (handle<>  StdInputHandle) and
(handle<>  StdOutputHandle) and
(handle<>  StdErrorHandle) then
   CloseHandle(ttextrec(stdout).handle);
{$else}
 {$error Add support for this platform}
{$endif}

ttextrec(stdout).handle:=myglobalstdouthandle;

That's unsuitable. I have lots of modules and lost of threads. Many modules 
built with C++ runtime, others with C.


The C++ and C threads won't have their input/output handles replaced by 
default, since they are not started via the FPC RTL. The only exception is in 
case they call back into Pascal code and they are subsequently hooked by the 
RTL because the Pascal code (indirectly) accesses a threadvar.


Coincidentally, just the other day we were discussing introducing the ability 
to install hooks that will be called automatically whenever an external 
thread is hooked by the RTL (since the RTL has to initialise a bunch of 
things at such a point, so may user code). You could do whatever 
initialisation you need to do at that point.


I think we could extend such a callback mechanism to all threads, possibly 
with a boolean parameter indicating whether the thread was started via the 
FPC RTL or not in case the difference is important in some use cases.


I think this is not bad; the question is whether we can do it on unix.
On Unix, we can currently only check when a threadvar is accessed.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] StdOut capture for FPC RTL

[Jonas Maebe]

On 25 Nov 2010, at 20:15, Anton Kavalenka wrote:


At 25.11.2010 19:57, Jonas Maebe wrote:
Actually, that won't work because the different threads will then  
work on a common buffer but with distinct pointers into it. A  
better solution is probably to do this in the intialisation code of  
each thread instead:


{$ifdef unix}
  fpclose(ttextrec(stdout).handle);
{$elsif defined(MSWINDOWS)}
  { this is a copy of do_close() from the rtl, I don't know whether
a new handle from a thread can actually have any of these  
values }

  if (handle<>  StdInputHandle) and
 (handle<>  StdOutputHandle) and
 (handle<>  StdErrorHandle) then
CloseHandle(ttextrec(stdout).handle);
{$else}
  {$error Add support for this platform}
{$endif}

ttextrec(stdout).handle:=myglobalstdouthandle;

That's unsuitable. I have lots of modules and lost of threads. Many  
modules built with C++ runtime, others with C.


The C++ and C threads won't have their input/output handles replaced  
by default, since they are not started via the FPC RTL. The only  
exception is in case they call back into Pascal code and they are  
subsequently hooked by the RTL because the Pascal code (indirectly)  
accesses a threadvar.


Coincidentally, just the other day we were discussing introducing the  
ability to install hooks that will be called automatically whenever an  
external thread is hooked by the RTL (since the RTL has to initialise  
a bunch of things at such a point, so may user code). You could do  
whatever initialisation you need to do at that point.


I think we could extend such a callback mechanism to all threads,  
possibly with a boolean parameter indicating whether the thread was  
started via the FPC RTL or not in case the difference is important in  
some use cases.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Michael Van Canneyt]

On Fri, 26 Nov 2010, Max Vlasov wrote:


Hi,

I thought about OOP recently, as many sometimes wonder that it's not as good as 
it can be in some areas. For example, the OOP encapsulation is good, but
sometimes the developer doesn't track the context completely or makes other 
"bad" things related to the hidden nature of encapsulation context. The
notion of name the variables with "f" at the start also speaks itself about 
these problems.

An idea here is to introduce a directive (maybe something else, but directive 
looks more straightforward), let's call it readonly that forces the method
to be able only to read the fields and properties of the object it belongs to 
and forbid any writing. Sure in this case it only can call only the methods
also containing such directive.

One of example of possible usage: TBitmap contains PixelFormat, when user 
changes it, there should be a conversion, but to be more sure that it will be
accurate and there are no side effects I'd mark the method for conversion with 
this directive so it will only read existing properties and create some
new one to return in variable passed by reference. With this directive on, any 
attempt of this method to change the fields related to bits or handle will
be stopped by the compiler, also if it tries to call a read/write method, the 
compiler will also stops. There are others examples that come to mind, all
allowing oop programming to be more controlled.

I thing there might be some logical contradictions I'm not aware at the moment, 
but I think they can be resolved with general oop inheritance logic.

What do you think? Is anyone aware of similar concept in any other OOP 
language? Apart from the idea (worth it or not), there's also a question about
introducing brand-new features in fpc. Are developers (read "Florian" :) is 
open to introducing new features that later possible other parties (read
Embarcadero :) will be willing to adapt?


Everything we introduced first Embarcadero has consistently done different, so 
I would not hope for that.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Max Vlasov]

Hi,

I thought about OOP recently, as many sometimes wonder that it's not as good
as it can be in some areas. For example, the OOP encapsulation is good, but
sometimes the developer doesn't track the context completely or makes other
"bad" things related to the hidden nature of encapsulation context. The
notion of name the variables with "f" at the start also speaks itself about
these problems.

An idea here is to introduce a directive (maybe something else, but
directive looks more straightforward), let's call it readonly that forces
the method to be able only to read the fields and properties of the object
it belongs to and forbid any writing. Sure in this case it only can call
only the methods also containing such directive.

One of example of possible usage: TBitmap contains PixelFormat, when user
changes it, there should be a conversion, but to be more sure that it will
be accurate and there are no side effects I'd mark the method for conversion
with this directive so it will only read existing properties and create some
new one to return in variable passed by reference. With this directive on,
any attempt of this method to change the fields related to bits or handle
will be stopped by the compiler, also if it tries to call a read/write
method, the compiler will also stops. There are others examples that come to
mind, all allowing oop programming to be more controlled.

I thing there might be some logical contradictions I'm not aware at the
moment, but I think they can be resolved with general oop inheritance logic.

What do you think? Is anyone aware of similar concept in any other OOP
language? Apart from the idea (worth it or not), there's also a question
about introducing brand-new features in fpc. Are developers (read "Florian"
:) is open to introducing new features that later possible other parties
(read Embarcadero :) will be willing to adapt?


Thanks,

Max Vlasov
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel