Release of Gambas 2.6

Hi,

Here is a new release of Gambas 2.

The new feature is the support of SVN conflict in the IDE. When a SVN conflict
is detected, you will not be able to edit the file in conflict. Instead, you
will get a conflict dialog that will help you to solve the conflict.

Otherwise, this release fixes some important bugs:

* Evaluating expressions in the IDE output console works again.

* Symbol polymorphism is now correctly handled when the inheritance depth is
greater than two!

* The evaluation of Eval() expressions is handled the same way as any other
code now, to prevent stack leaks.

* Reading floating point values from a SQLite database does not depend on the
locale anymore.

* Clipboard.Copy() from gb.qt component now correctly sends UTF-8 strings to
the clipboard.

Here is the full changelog:

-------------------------------------------------------------------------------

[CONFIGURATION]
* BUG: Search include files inside lib64 directories too. Hurra for the
  distributions that put non 64 bits specific files into a 64 bits specific
  directory!
* NEW: Makes better configuration warning messages when detecting libintl
  and libiconv libraries.

[DEVELOPMENT ENVIRONMENT]
* BUG: The auto-completion of a child class now is correctly updated if its
  parent class is modified.
* BUG: The auto-completion of children classes does not overflow the stack
  anymore.
* BUG: Evaluating expressions in the output console works again.
* BUG: Text editor does not flash anymore when being resized.
* BUG: Correctly raise an error when making an executable fails for any
  reason.
* BUG: Extract the property help better.
* BUG: Fix the layout of the property sheet text edit dialog.
* BUG: Splitting view in editor correctly updates the procedure combo-box
  now.
* BUG: The menu editor does not crash anymore when all menus are deleted
  at once.
* NEW: Add a search box in the output console toolbar.
* NEW: Displays an error message if a project is not a Gambas 2 project.
* NEW: Subversion conflicts support.
* OPT: Do not set Project ColumnView AutoResize property to TRUE. Use a
  very wide column instead to optimize redrawing.

[INTERPRETER]
* BUG: Symbol polymorphism is now correctly handled when the inheritance
  depth is greater than two!
* BUG: INC and DEC now toggle boolean values.
* BUG: Getting information on a not yet loaded class does not crash the
  debugger anymore.
* BUG: Handle the evaluation of Eval() expressions the same way as any
  other code. Otherwise, stack can be leaked when there is an exception
  inside.
* NEW: The foreign function interface is now optional.

[COMPILER]
* BUG: Adds many error messages when a compiler limit is reached: too many
  static symbols in a same class, too many dynamic symbols, too many
  functions, and so on.
* BUG: Do not print error messages on unexpected strings with newline
  inside. Just claim that an unexpected string has been encountered.

[GB.DB.SQLITE2]
* BUG: Reading floating point values and other values do not depend on the
  locale anymore.
* NEW: Remove useless code.

[GB.DB.SQLITE3]
* BUG: Reading floating point values and other values do not depend on the
  locale anymore.
* NEW: Remove useless code.

[GB.EVAL]
* BUG: Remove an apparently useless line of code that made the highlighter
  sometimes crash!
* BUG: Evaluating "Error" does not crash anymore. It just raises an error.
* BUG: Do not print error messages on unexpected strings with newline
  inside. Just claim that an unexpected string has been encountered.

[GB.FORM]
* BUG: Correctly cancel a impossible rename operation in the DirView
  control.
* NEW: Add a slider for setting the alpha color component.

[GB.FORM.DIALOG]
* BUG: Standard dialogs now correctly react to double clicks.

[GB.GTK]
* BUG: Void items are correctly handled by ComboBox without crashing now.
* BUG: Windows cannot get focus anymore.
* BUG: PictureBox.Alignment property now correctly deals with Align.Normal,
  Align.TopNormal, and Align.BottomNormal alignments.
* BUG: Fix uninitialized variables in ggridview.cpp and gmainwindow.cpp.

[GB.PDF]
* BUG: Compiles correctly against poppler 0.8 now.

[GB.QT]
* BUG: Resizing a GridView column inside the ColumnResize event handler
  does not lead to a crash anymore.
* BUG: Correctly update the PictureBox and DrawingArea background when the
  background color changes.
* BUG: Clipboard.Copy() sends UTF-8 strings to the clipboard correctly now.
* BUG: SpinBox.Text works correctly now.
* BUG: PictureBox is correctly refreshed now when its contents change.
* BUG: TabStrip[].Count now always returns the correct number of child
  controls in a tab.
* NEW: Non resizable windows can be resized by the Move() or Resize()
  methods now.
* OPT: The PictureBox control does not flicker anymore when its Picture
  property is changed.

[GB.QT.EXT]
* BUG: Editor now correctly highlight its frame according to the focus
  change on styles that have use of that.
* BUG: Editor correctly goes to the end of file when pressing CTRL+END.
  Consequently, SelectAll() works correctly too now.

[GB.SETTINGS]
* BUG: Do not use Array datatype incorrectly anymore.

-------------------------------------------------------------------------------

Enjoy it!

Regards,

--
Benoit Minisini

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Guillermo Ballester Valor]

Thanks Benoit,

It compiled OK on openSUSE 10.2 and 10.3.  32 and 64 bit rpms are already
built. You can get them from openSUSE buildservice repository:

http://download.opensuse.org/repositories/home:/gbvalor/

Guillermo

El Saturday 10 May 2008 11:11:00 Benoit Minisini escribió:
> Hi,
>
> Here is a new release of Gambas 2.
>



--
Guillermo Ballester Valor
gbv@...
http://www.oxixares.com/~gbv
Ogijares, Granada - SPAIN

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

On dimanche 11 mai 2008, you wrote:

>    IMHO this is broken thinking. It might be a little more typing to use
> VarName = NOT VarName but it is decidedly more transparent as to what
> datatype 'VarName' is and what is being done to it.
>
> Success = Not Success
>
> vs
>
> INC(Success)
>
> DEC(Success)
>
>    In the first example it is very clear what is being done, even when
> Hungarian notation is not being used, whereas in the second example all
> that is clear is that a value is being incremented or decremented. INC
> and DEC implies a change in direction (up or down) to a numeric value,
> while NOT implies a change in state, which is more analogous to a toggle.
>
>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
> error is the proper response to those trying to INC or DEC a boolean.
>   Sorry, I just had to reply, when I see things like this it makes me
> cringe, like someone dragging their fingernails on a blackboard makes me
> cringe.
>
>
> Kindest regards
> Stephen Bungay
>

Boolean and Integer values can be converted into each other in Gambas:

True -> -1
False -> 0

0 -> False
Any other value -> True

Incrementing or decrementing a boolean variable actually incremented or
decremented its integer converted value.

INC False -> Inc 0 -> 1 -> True
INC True -> Inc -1 -> 0 -> False

DEC False -> Dec 0 -> -1 -> True
DEC True -> Dec -1 -> -2 -> True ?

Weird, so this was fixed in Gambas 2.6, so that DEC True -> False. Otherwise,
you will have to remember that INC toggle, but not DEC. I found that too
complex for my own brain.

This is coherent with the common behaviour of Gambas. I mean you can INC or
DEC dates too, as Date and Float can be converted to each other.

You can ignore this feature if you don't like it. Anyway, it cannot be removed
in 2.x for backward compatibility reasons.

I could remove it in 3.0, and replace it by a NOT instruction that would do
the same thing only for booleans:

NOT MyMenu.Checked ' for example

Regards,

--
Benoit Minisini

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Pablo Valentini]

Hi,

Since this release is most bug-fixing why 2.6 and not 2.5.x?

Thanks,


Pablo

On Sat, May 10, 2008 at 8:11 AM, Benoit Minisini
<gambas@...> wrote:
> Hi,
>
> Here is a new release of Gambas 2.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

On dimanche 11 mai 2008, Pablo Valentini wrote:
> Hi,
>
> Since this release is most bug-fixing why 2.6 and not 2.5.x?
>
> Thanks,
>
>
> Pablo
>

Because this is not *just* bug fixing, there are new features.

Or because these are bug fixes for the 2.0 version, not the 2.5.

Or because I noticed that newbies tend to be lost as soon as there are more
than two digits in the version number.

As you can see, one can find many reasons! :-)

Regards,

--
Benoit Minisini

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Stephen Bungay-2]

Benoit Minisini wrote:

> On dimanche 11 mai 2008, you wrote:
>>    IMHO this is broken thinking. It might be a little more typing to use
>> VarName = NOT VarName but it is decidedly more transparent as to what
>> datatype 'VarName' is and what is being done to it.
>>
>> Success = Not Success
>>
>> vs
>>
>> INC(Success)
>>
>> DEC(Success)
>>
>>    In the first example it is very clear what is being done, even when
>> Hungarian notation is not being used, whereas in the second example all
>> that is clear is that a value is being incremented or decremented. INC
>> and DEC implies a change in direction (up or down) to a numeric value,
>> while NOT implies a change in state, which is more analogous to a toggle.
>>
>>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
>> error is the proper response to those trying to INC or DEC a boolean.
>>   Sorry, I just had to reply, when I see things like this it makes me
>> cringe, like someone dragging their fingernails on a blackboard makes me
>> cringe.
>>
>>
>> Kindest regards
>> Stephen Bungay
>>
>
> Boolean and Integer values can be converted into each other in Gambas:
>
> True -> -1
> False -> 0
>
> 0 -> False
> Any other value -> True
>
> Incrementing or decrementing a boolean variable actually incremented or
> decremented its integer converted value.
>
> INC False -> Inc 0 -> 1 -> True
> INC True -> Inc -1 -> 0 -> False
>
> DEC False -> Dec 0 -> -1 -> True
> DEC True -> Dec -1 -> -2 -> True ?
>
> Weird, so this was fixed in Gambas 2.6, so that DEC True -> False. Otherwise,
> you will have to remember that INC toggle, but not DEC. I found that too
> complex for my own brain.
>
> This is coherent with the common behaviour of Gambas. I mean you can INC or
> DEC dates too, as Date and Float can be converted to each other.
>
> You can ignore this feature if you don't like it. Anyway, it cannot be removed
> in 2.x for backward compatibility reasons.
>
> I could remove it in 3.0, and replace it by a NOT instruction that would do
> the same thing only for booleans:
>
> NOT MyMenu.Checked ' for example
>
> Regards,
>

   Yes, just because the feature is there doesn't mean the programmer
(me in this case) has to use it. Or, as I've become fond of saying,
'Just because something CAN be done a certain way doesn't mean it SHOULD
be done that way'.
   INC and DEC makes sense on Dates since it implies a direction, into
the future or back in the past, as opposed to the state change of On or
Off, True or False a boolean value implies.

   Personally I think I'll just stay with the already implemented BASIC
syntax and use;

MyMenu.Checked = NOT MyMenu.Checked

   as it is clear as to it's intent. With typeahead already working to
reduce typing there is little in the way of extra burden to the
programmer as far as keystrokes go.

IMHO, creating a 'NOT' instruction confuses things further since;

MyMenu.Checked = Not MyMenu.Checked

and

NOT MyMenu.Checked

   would produce the same result, however the latter looks more like an
incomplete conditional than an assignment statement.

   IMHO it is a good idea to Deprecate the INC and DEC on BOOL datatypes
in Gambas 3.0.

   GAMBAS is your baby Benoit, and you have done the Linux community a
great service with it. I really have no place making any suggestions and
thank you for taking the time to read my thoughts on the subject,
however naive they might be.

Stephen Bungay

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

On dimanche 11 mai 2008, Stephen Bungay wrote:

> Benoit Minisini wrote:
> > On dimanche 11 mai 2008, you wrote:
> >>    IMHO this is broken thinking. It might be a little more typing to use
> >> VarName = NOT VarName but it is decidedly more transparent as to what
> >> datatype 'VarName' is and what is being done to it.
> >>
> >> Success = Not Success
> >>
> >> vs
> >>
> >> INC(Success)
> >>
> >> DEC(Success)
> >>
> >>    In the first example it is very clear what is being done, even when
> >> Hungarian notation is not being used, whereas in the second example all
> >> that is clear is that a value is being incremented or decremented. INC
> >> and DEC implies a change in direction (up or down) to a numeric value,
> >> while NOT implies a change in state, which is more analogous to a
> >> toggle.
> >>
> >>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
> >> error is the proper response to those trying to INC or DEC a boolean.
> >>   Sorry, I just had to reply, when I see things like this it makes me
> >> cringe, like someone dragging their fingernails on a blackboard makes me
> >> cringe.
> >>
> >>
> >> Kindest regards
> >> Stephen Bungay
> >
> > Boolean and Integer values can be converted into each other in Gambas:
> >
> > True -> -1
> > False -> 0
> >
> > 0 -> False
> > Any other value -> True
> >
> > Incrementing or decrementing a boolean variable actually incremented or
> > decremented its integer converted value.
> >
> > INC False -> Inc 0 -> 1 -> True
> > INC True -> Inc -1 -> 0 -> False
> >
> > DEC False -> Dec 0 -> -1 -> True
> > DEC True -> Dec -1 -> -2 -> True ?
> >
> > Weird, so this was fixed in Gambas 2.6, so that DEC True -> False.
> > Otherwise, you will have to remember that INC toggle, but not DEC. I
> > found that too complex for my own brain.
> >
> > This is coherent with the common behaviour of Gambas. I mean you can INC
> > or DEC dates too, as Date and Float can be converted to each other.
> >
> > You can ignore this feature if you don't like it. Anyway, it cannot be
> > removed in 2.x for backward compatibility reasons.
> >
> > I could remove it in 3.0, and replace it by a NOT instruction that would
> > do the same thing only for booleans:
> >
> > NOT MyMenu.Checked ' for example
> >
> > Regards,
>
>    Yes, just because the feature is there doesn't mean the programmer
> (me in this case) has to use it. Or, as I've become fond of saying,
> 'Just because something CAN be done a certain way doesn't mean it SHOULD
> be done that way'.
>    INC and DEC makes sense on Dates since it implies a direction, into
> the future or back in the past, as opposed to the state change of On or
> Off, True or False a boolean value implies.
>
>    Personally I think I'll just stay with the already implemented BASIC
> syntax and use;
>
> MyMenu.Checked = NOT MyMenu.Checked
>
>    as it is clear as to it's intent. With typeahead already working to
> reduce typing there is little in the way of extra burden to the
> programmer as far as keystrokes go.
>
> IMHO, creating a 'NOT' instruction confuses things further since;
>
> MyMenu.Checked = Not MyMenu.Checked
>
> and
>
> NOT MyMenu.Checked
>
>    would produce the same result, however the latter looks more like an
> incomplete conditional than an assignment statement.
>
>    IMHO it is a good idea to Deprecate the INC and DEC on BOOL datatypes
> in Gambas 3.0.
>
>    GAMBAS is your baby Benoit, and you have done the Linux community a
> great service with it. I really have no place making any suggestions and
> thank you for taking the time to read my thoughts on the subject,
> however naive they might be.
>
> Stephen Bungay
>

No problem. But if you are the only one people that is disturbed by this
semantic, maybe I won't remove it. On the other hand, if many many people
cry, I will!

--
Benoit Minisini

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Paul Horechuk]

On May 11, 2008 11:45:44 am Benoit Minisini wrote:

> On dimanche 11 mai 2008, Stephen Bungay wrote:
> > Benoit Minisini wrote:
> > > On dimanche 11 mai 2008, you wrote:
> > >>    IMHO this is broken thinking. It might be a little more typing to
> > >> use VarName = NOT VarName but it is decidedly more transparent as to
> > >> what datatype 'VarName' is and what is being done to it.
> > >>
> > >> Success = Not Success
> > >>
> > >> vs
> > >>
> > >> INC(Success)
> > >>
> > >> DEC(Success)
> > >>
> > >>    In the first example it is very clear what is being done, even when
> > >> Hungarian notation is not being used, whereas in the second example
> > >> all that is clear is that a value is being incremented or decremented.
> > >> INC and DEC implies a change in direction (up or down) to a numeric
> > >> value, while NOT implies a change in state, which is more analogous to
> > >> a toggle.
> > >>
> > >>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
> > >> error is the proper response to those trying to INC or DEC a boolean.
> > >>   Sorry, I just had to reply, when I see things like this it makes me
> > >> cringe, like someone dragging their fingernails on a blackboard makes
> > >> me cringe.
> > >>
> > >>
> > >> Kindest regards
> > >> Stephen Bungay
> > >
> > > Boolean and Integer values can be converted into each other in Gambas:
> > >
> > > True -> -1
> > > False -> 0
> > >
> > > 0 -> False
> > > Any other value -> True
> > >
> > > Incrementing or decrementing a boolean variable actually incremented or
> > > decremented its integer converted value.
> > >
> > > INC False -> Inc 0 -> 1 -> True
> > > INC True -> Inc -1 -> 0 -> False
> > >
> > > DEC False -> Dec 0 -> -1 -> True
> > > DEC True -> Dec -1 -> -2 -> True ?
> > >
> > > Weird, so this was fixed in Gambas

2.6http://www.directdial.com/LX.AJA0X.226.html, so that DEC True -> False.

> > > Otherwise, you will have to remember that INC toggle, but not DEC. I
> > > found that too complex for my own brain.
> > >
> > > This is coherent with the common behaviour of Gambas. I mean you can
> > > INC or DEC dates too, as Date and Float can be converted to each other.
> > >
> > > You can ignore this feature if you don't like it. Anyway, it cannot be
> > > removed in 2.x for backward compatibility reasons.
> > >
> > > I could remove it in 3.0, and replace it by a NOT instruction that
> > > would do the same thing only for booleans:
> > >
> > > NOT MyMenu.Checked ' for example
> > >
> > > Regards,
> >
> >    Yes, just because the feature is there doesn't mean the programmer
> > (me in this case) has to use it. Or, as I've become fond of saying,
> > 'Just because something CAN be done a certain way doesn't mean it SHOULD
> > be done that way'.
> >    INC and DEC makes sense on Dates since it implies a direction, into
> > the future or back in the past, as opposed to the state change of On or
> > Off, True or False a boolean value implies.
> >
> >    Personally I think I'll just stay with the already implemented BASIC
> > syntax and use;
> >
> > MyMenu.Checked = NOT MyMenu.Checked
> >
> >    as it is clear as to it's intent. With typeahead already working to
> > reduce typing there is little in the way of extra burden to the
> > programmer as far as keystrokes go.
> >
> > IMHO, creating a 'NOT' instruction confuses things further since;
> >
> > MyMenu.Checked = Not MyMenu.Checked
> >
> > and
> >
> > NOT MyMenu.Checked
> >
> >    would produce the same result, however the latter looks more like an
> > incomplete conditional than an assignment statement.
> >
> >    IMHO it is a good idea to Deprecate the INC and DEC on BOOL datatypes
> > in Gambas 3.0.
> >
> >    GAMBAS is your baby Benoit, and you have done the Linux community a
> > great service with it. I really have no place making any suggestions and
> > thank you for taking the time to read my thoughts on the subject,
> > however naive they might be.
> >
> > Stephen Bungay
>
> No problem. But if you are the only one people that is disturbed by this
> semantic, maybe I won't remove it. On the other hand, if many many people
> cry, I will!

I have to side with Stephen on this. Allowing INC and DEC on Boolean is just
plain bad form. What's next, INC(Char) or INC(File)?



--
-- Paul Horechuk
Think Free
Use Open Source Software

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[David Yoder-2]

To me it seems that this is much to do about nothing!

Success = Not Success

does not imply boolean function unless Success is known to be
declared boolean. The programmer could be invoking the binary
complement of Success.

The best implication of boolean that I know is the assignment of
True or False.

I know that many programmers use increment / decrement with boolean
objects and that many use int objects as though they were boolean, while
that may have me doing a mental frown, it's a so what! Not something I
would do as a professional.

Dave

Paul Horechuk wrote:

> On May 11, 2008 11:45:44 am Benoit Minisini wrote:
>  
>> On dimanche 11 mai 2008, Stephen Bungay wrote:
>>    
>>> Benoit Minisini wrote:
>>>      
>>>> On dimanche 11 mai 2008, you wrote:
>>>>        
>>>>>    IMHO this is broken thinking. It might be a little more typing to
>>>>> use VarName = NOT VarName but it is decidedly more transparent as to
>>>>> what datatype 'VarName' is and what is being done to it.
>>>>>
>>>>> Success = Not Success
>>>>>
>>>>> vs
>>>>>
>>>>> INC(Success)
>>>>>
>>>>> DEC(Success)
>>>>>
>>>>>    In the first example it is very clear what is being done, even when
>>>>> Hungarian notation is not being used, whereas in the second example
>>>>> all that is clear is that a value is being incremented or decremented.
>>>>> INC and DEC implies a change in direction (up or down) to a numeric
>>>>> value, while NOT implies a change in state, which is more analogous to
>>>>> a toggle.
>>>>>
>>>>>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
>>>>> error is the proper response to those trying to INC or DEC a boolean.
>>>>>   Sorry, I just had to reply, when I see things like this it makes me
>>>>> cringe, like someone dragging their fingernails on a blackboard makes
>>>>> me cringe.
>>>>>
>>>>>
>>>>> Kindest regards
>>>>> Stephen Bungay
>>>>>          
>>>> Boolean and Integer values can be converted into each other in Gambas:
>>>>
>>>> True -> -1
>>>> False -> 0
>>>>
>>>> 0 -> False
>>>> Any other value -> True
>>>>
>>>> Incrementing or decrementing a boolean variable actually incremented or
>>>> decremented its integer converted value.
>>>>
>>>> INC False -> Inc 0 -> 1 -> True
>>>> INC True -> Inc -1 -> 0 -> False
>>>>
>>>> DEC False -> Dec 0 -> -1 -> True
>>>> DEC True -> Dec -1 -> -2 -> True ?
>>>>
>>>> Weird, so this was fixed in Gambas
>>>>        
> 2.6http://www.directdial.com/LX.AJA0X.226.html, so that DEC True -> False.
>  
>>>> Otherwise, you will have to remember that INC toggle, but not DEC. I
>>>> found that too complex for my own brain.
>>>>
>>>> This is coherent with the common behaviour of Gambas. I mean you can
>>>> INC or DEC dates too, as Date and Float can be converted to each other.
>>>>
>>>> You can ignore this feature if you don't like it. Anyway, it cannot be
>>>> removed in 2.x for backward compatibility reasons.
>>>>
>>>> I could remove it in 3.0, and replace it by a NOT instruction that
>>>> would do the same thing only for booleans:
>>>>
>>>> NOT MyMenu.Checked ' for example
>>>>
>>>> Regards,
>>>>        
>>>    Yes, just because the feature is there doesn't mean the programmer
>>> (me in this case) has to use it. Or, as I've become fond of saying,
>>> 'Just because something CAN be done a certain way doesn't mean it SHOULD
>>> be done that way'.
>>>    INC and DEC makes sense on Dates since it implies a direction, into
>>> the future or back in the past, as opposed to the state change of On or
>>> Off, True or False a boolean value implies.
>>>
>>>    Personally I think I'll just stay with the already implemented BASIC
>>> syntax and use;
>>>
>>> MyMenu.Checked = NOT MyMenu.Checked
>>>
>>>    as it is clear as to it's intent. With typeahead already working to
>>> reduce typing there is little in the way of extra burden to the
>>> programmer as far as keystrokes go.
>>>
>>> IMHO, creating a 'NOT' instruction confuses things further since;
>>>
>>> MyMenu.Checked = Not MyMenu.Checked
>>>
>>> and
>>>
>>> NOT MyMenu.Checked
>>>
>>>    would produce the same result, however the latter looks more like an
>>> incomplete conditional than an assignment statement.
>>>
>>>    IMHO it is a good idea to Deprecate the INC and DEC on BOOL datatypes
>>> in Gambas 3.0.
>>>
>>>    GAMBAS is your baby Benoit, and you have done the Linux community a
>>> great service with it. I really have no place making any suggestions and
>>> thank you for taking the time to read my thoughts on the subject,
>>> however naive they might be.
>>>
>>> Stephen Bungay
>>>      
>> No problem. But if you are the only one people that is disturbed by this
>> semantic, maybe I won't remove it. On the other hand, if many many people
>> cry, I will!
>>    
> I have to side with Stephen on this. Allowing INC and DEC on Boolean is just
> plain bad form. What's next, INC(Char) or INC(File)?
>
>
>
>  

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Richard-147]

Just adding my fourpence worth; I agree that Success = NOT Success doesn't
necessarily imply a boolean operation is being executed, but it is a MUCH
stronger hint that this is the case than an appearent attempt to increment or
decrement a value.

There is a world of difference between type punning and type coersion. One
requires/presumes an understanding of lower level architecture and the other
is an attempt to make knowledge of the underlying structure unneccessary.

The first time I came across type coersion was in Sinclair SuperBASIC in
1983/4. It was a huge leap forward in making programming a more human
friendly process and part of an overall strategy in that language to hide the
messy irrelevant details and make BASIC more readable. It wasn't until the
Turbo compiler was introduced years later that the concept of designating
types for numeric variables was introduced. But I digress.

The ability to apply INC and DEC to boolean variables does nothing for data
abstraction or human readability (surely these are two important goals for
every high level language?). Perhaps people who see nothing "wrong" with this
apparent abuse of logic and language are more at home with lower level
languages (such as C) or do not have English as their mother tongue.

I also think it is a huge mistake to say that some typographical convention
should be used in naming the variable to make it clear that the "INC" or
"DEC" operation is in fact the boolean operation "NOT". Many people, myself
included, believe that reintroducing an expectation that the reader of a
program needs to know the underlying structure of the storage used for a
variable merely discourages good programming practices; use meaningful names
for variables and functions and declare them close to where they are used.

If your code requires an understanding of the data type being stored in a
variable for a reader to understand the code then perhaps there is something
else wrong. If the declaration of a variable is only a few lines away at the
start of the function/procedure then it should be easy to refer to if needed.

If we are voting, then I vote for the official deprecation of INC and DEC on
boolean values.

On Sunday 11 May 2008 18:32, David Yoder wrote:

> To me it seems that this is much to do about nothing!
>
> Success = Not Success
>
> does not imply boolean function unless Success is known to be
> declared boolean. The programmer could be invoking the binary
> complement of Success.
>
> The best implication of boolean that I know is the assignment of
> True or False.
>
> I know that many programmers use increment / decrement with boolean
> objects and that many use int objects as though they were boolean, while
> that may have me doing a mental frown, it's a so what! Not something I
> would do as a professional.
>
> Dave
>
> Paul Horechuk wrote:
> > On May 11, 2008 11:45:44 am Benoit Minisini wrote:
> >> On dimanche 11 mai 2008, Stephen Bungay wrote:
> >>> Benoit Minisini wrote:
> >>>> On dimanche 11 mai 2008, you wrote:
> >>>>>    IMHO this is broken thinking. It might be a little more typing to
> >>>>> use VarName = NOT VarName but it is decidedly more transparent as to
> >>>>> what datatype 'VarName' is and what is being done to it.
> >>>>>
> >>>>> Success = Not Success
> >>>>>
> >>>>> vs
> >>>>>
> >>>>> INC(Success)
> >>>>>
> >>>>> DEC(Success)
> >>>>>
> >>>>>    In the first example it is very clear what is being done, even
> >>>>> when Hungarian notation is not being used, whereas in the second
> >>>>> example all that is clear is that a value is being incremented or
> >>>>> decremented. INC and DEC implies a change in direction (up or down)
> >>>>> to a numeric value, while NOT implies a change in state, which is
> >>>>> more analogous to a toggle.
> >>>>>
> >>>>>    I think, and perhaps I'm wrong on this, that a 'data type
> >>>>> mismatch' error is the proper response to those trying to INC or DEC
> >>>>> a boolean. Sorry, I just had to reply, when I see things like this it
> >>>>> makes me cringe, like someone dragging their fingernails on a
> >>>>> blackboard makes me cringe.
> >>>>>
> >>>>>
> >>>>> Kindest regards
> >>>>> Stephen Bungay
> >>>>
> >>>> Boolean and Integer values can be converted into each other in Gambas:
> >>>>
> >>>> True -> -1
> >>>> False -> 0
> >>>>
> >>>> 0 -> False
> >>>> Any other value -> True
> >>>>
> >>>> Incrementing or decrementing a boolean variable actually incremented
> >>>> or decremented its integer converted value.
> >>>>
> >>>> INC False -> Inc 0 -> 1 -> True
> >>>> INC True -> Inc -1 -> 0 -> False
> >>>>
> >>>> DEC False -> Dec 0 -> -1 -> True
> >>>> DEC True -> Dec -1 -> -2 -> True ?
> >>>>
> >>>> Weird, so this was fixed in Gambas
> >
> > 2.6http://www.directdial.com/LX.AJA0X.226.html, so that DEC True ->
> > False.
> >
> >>>> Otherwise, you will have to remember that INC toggle, but not DEC. I
> >>>> found that too complex for my own brain.
> >>>>
> >>>> This is coherent with the common behaviour of Gambas. I mean you can
> >>>> INC or DEC dates too, as Date and Float can be converted to each
> >>>> other.
> >>>>
> >>>> You can ignore this feature if you don't like it. Anyway, it cannot be
> >>>> removed in 2.x for backward compatibility reasons.
> >>>>
> >>>> I could remove it in 3.0, and replace it by a NOT instruction that
> >>>> would do the same thing only for booleans:
> >>>>
> >>>> NOT MyMenu.Checked ' for example
> >>>>
> >>>> Regards,
> >>>
> >>>    Yes, just because the feature is there doesn't mean the programmer
> >>> (me in this case) has to use it. Or, as I've become fond of saying,
> >>> 'Just because something CAN be done a certain way doesn't mean it
> >>> SHOULD be done that way'.
> >>>    INC and DEC makes sense on Dates since it implies a direction, into
> >>> the future or back in the past, as opposed to the state change of On or
> >>> Off, True or False a boolean value implies.
> >>>
> >>>    Personally I think I'll just stay with the already implemented BASIC
> >>> syntax and use;
> >>>
> >>> MyMenu.Checked = NOT MyMenu.Checked
> >>>
> >>>    as it is clear as to it's intent. With typeahead already working to
> >>> reduce typing there is little in the way of extra burden to the
> >>> programmer as far as keystrokes go.
> >>>
> >>> IMHO, creating a 'NOT' instruction confuses things further since;
> >>>
> >>> MyMenu.Checked = Not MyMenu.Checked
> >>>
> >>> and
> >>>
> >>> NOT MyMenu.Checked
> >>>
> >>>    would produce the same result, however the latter looks more like an
> >>> incomplete conditional than an assignment statement.
> >>>
> >>>    IMHO it is a good idea to Deprecate the INC and DEC on BOOL
> >>> datatypes in Gambas 3.0.
> >>>
> >>>    GAMBAS is your baby Benoit, and you have done the Linux community a
> >>> great service with it. I really have no place making any suggestions
> >>> and thank you for taking the time to read my thoughts on the subject,
> >>> however naive they might be.
> >>>
> >>> Stephen Bungay
> >>
> >> No problem. But if you are the only one people that is disturbed by this
> >> semantic, maybe I won't remove it. On the other hand, if many many
> >> people cry, I will!
> >
> > I have to side with Stephen on this. Allowing INC and DEC on Boolean is
> > just plain bad form. What's next, INC(Char) or INC(File)?
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
>one _______________________________________________
> Gambas-user mailing list
> Gambas-user@...
> https://lists.sourceforge.net/lists/listinfo/gambas-user

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user

[Stefano Palmeri]

Il Saturday 10 May 2008 13:11:00 Benoit Minisini ha scritto:

> Hi,
>
> Here is a new release of Gambas 2.
>
> The new feature is the support of SVN conflict in the IDE. When a SVN
> conflict is detected, you will not be able to edit the file in conflict.
> Instead, you will get a conflict dialog that will help you to solve the
> conflict.
>
> Otherwise, this release fixes some important bugs:
>
> * Evaluating expressions in the IDE output console works again.
>
> * Symbol polymorphism is now correctly handled when the inheritance depth
> is greater than two!
>
> * The evaluation of Eval() expressions is handled the same way as any other
> code now, to prevent stack leaks.
>
> * Reading floating point values from a SQLite database does not depend on
> the locale anymore.
>
> * Clipboard.Copy() from gb.qt component now correctly sends UTF-8 strings
> to the clipboard.
>
> Here is the full changelog:
>
> ---------------------------------------------------------------------------
>----
>
> [CONFIGURATION]
> * BUG: Search include files inside lib64 directories too. Hurra for the
>   distributions that put non 64 bits specific files into a 64 bits specific
>   directory!
> * NEW: Makes better configuration warning messages when detecting libintl
>   and libiconv libraries.
>
> [DEVELOPMENT ENVIRONMENT]
> * BUG: The auto-completion of a child class now is correctly updated if its
>   parent class is modified.
> * BUG: The auto-completion of children classes does not overflow the stack
>   anymore.
> * BUG: Evaluating expressions in the output console works again.
> * BUG: Text editor does not flash anymore when being resized.
> * BUG: Correctly raise an error when making an executable fails for any
>   reason.
> * BUG: Extract the property help better.
> * BUG: Fix the layout of the property sheet text edit dialog.
> * BUG: Splitting view in editor correctly updates the procedure combo-box
>   now.
> * BUG: The menu editor does not crash anymore when all menus are deleted
>   at once.
> * NEW: Add a search box in the output console toolbar.
> * NEW: Displays an error message if a project is not a Gambas 2 project.
> * NEW: Subversion conflicts support.
> * OPT: Do not set Project ColumnView AutoResize property to TRUE. Use a
>   very wide column instead to optimize redrawing.
>
> [INTERPRETER]
> * BUG: Symbol polymorphism is now correctly handled when the inheritance
>   depth is greater than two!
> * BUG: INC and DEC now toggle boolean values.
> * BUG: Getting information on a not yet loaded class does not crash the
>   debugger anymore.
> * BUG: Handle the evaluation of Eval() expressions the same way as any
>   other code. Otherwise, stack can be leaked when there is an exception
>   inside.
> * NEW: The foreign function interface is now optional.
>
> [COMPILER]
> * BUG: Adds many error messages when a compiler limit is reached: too many
>   static symbols in a same class, too many dynamic symbols, too many
>   functions, and so on.
> * BUG: Do not print error messages on unexpected strings with newline
>   inside. Just claim that an unexpected string has been encountered.
>
> [GB.DB.SQLITE2]
> * BUG: Reading floating point values and other values do not depend on the
>   locale anymore.
> * NEW: Remove useless code.
>
> [GB.DB.SQLITE3]
> * BUG: Reading floating point values and other values do not depend on the
>   locale anymore.
> * NEW: Remove useless code.
>
> [GB.EVAL]
> * BUG: Remove an apparently useless line of code that made the highlighter
>   sometimes crash!
> * BUG: Evaluating "Error" does not crash anymore. It just raises an error.
> * BUG: Do not print error messages on unexpected strings with newline
>   inside. Just claim that an unexpected string has been encountered.
>
> [GB.FORM]
> * BUG: Correctly cancel a impossible rename operation in the DirView
>   control.
> * NEW: Add a slider for setting the alpha color component.
>
> [GB.FORM.DIALOG]
> * BUG: Standard dialogs now correctly react to double clicks.
>
> [GB.GTK]
> * BUG: Void items are correctly handled by ComboBox without crashing now.
> * BUG: Windows cannot get focus anymore.
> * BUG: PictureBox.Alignment property now correctly deals with Align.Normal,
>   Align.TopNormal, and Align.BottomNormal alignments.
> * BUG: Fix uninitialized variables in ggridview.cpp and gmainwindow.cpp.
>
> [GB.PDF]
> * BUG: Compiles correctly against poppler 0.8 now.
>
> [GB.QT]
> * BUG: Resizing a GridView column inside the ColumnResize event handler
>   does not lead to a crash anymore.
> * BUG: Correctly update the PictureBox and DrawingArea background when the
>   background color changes.
> * BUG: Clipboard.Copy() sends UTF-8 strings to the clipboard correctly now.
> * BUG: SpinBox.Text works correctly now.
> * BUG: PictureBox is correctly refreshed now when its contents change.
> * BUG: TabStrip[].Count now always returns the correct number of child
>   controls in a tab.
> * NEW: Non resizable windows can be resized by the Move() or Resize()
>   methods now.
> * OPT: The PictureBox control does not flicker anymore when its Picture
>   property is changed.
>
> [GB.QT.EXT]
> * BUG: Editor now correctly highlight its frame according to the focus
>   change on styles that have use of that.
> * BUG: Editor correctly goes to the end of file when pressing CTRL+END.
>   Consequently, SelectAll() works correctly too now.
>
> [GB.SETTINGS]
> * BUG: Do not use Array datatype incorrectly anymore.
>
> ---------------------------------------------------------------------------
>----
>
> Enjoy it!
>
> Regards,

Just to say that it compiles perfectly on last Slackware 12.1.

Bye,

Stefano


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gambas-user mailing list
Gambas-user@...
https://lists.sourceforge.net/lists/listinfo/gambas-user