Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search in forums












SourceForge.net Logo



Home » Community » U++ community news and announcements » U++ 2017 beta
Re: U++ 2017 beta [message #47321 is a reply to message #47320] Wed, 04 January 2017 11:19 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1190
Registered: September 2007
Senior Veteran
mirek wrote on Wed, 04 January 2017 11:28
cbpporter wrote on Wed, 04 January 2017 10:06

I'm sure that a lot of the user base, if U++ worked out of the box with Visual Studio, would never boot up TheIDE again.


Perhaps it is time to do that... I mean, with .icpp problem gone, somebody could try again... Regroup sources to classic .libs should be easy now.

(The only trouble is layout/icon designers, but you can use theide for it, it works with commandline parameters - perhaps even rename the executable to 'upp_designer' or something).

Maybe.

A bit too late for that.

I think at this stage it is better to improve the debugger. I'm very strapped on time, but I did boot up some 2009 debugger code and it still compiles in TheIDE, so I will do some tests with improving String debugging.

Currently, 75% of my debugging time is spent with looking at strings. And in 90% of those times, I need to DUMP that string because the debugger shows me a really long line of useless information, yet it cuts off often the actual string part of the String.

The tooltip clips of screen, it has no multiline support and is generally not good.

But I'll focus on strings first. Won't have probably time for anything more.

Here is a mockup of what I'm thinking:
index.php?t=getfile&id=5159&private=0

The top one is the current solution: ugly, bad, information overload. I have full trust in U++. I don't need to debug your string implementation. I need to debug my strings. Their content! The bottom one is my mockup. first line, full string, with far greater clipping size. Followed by length. Second line is the rest of the bullshit I don't care about.

When debugging bigger classes with multiple fields, the second line should be either put at the end of the first or dropped all together. Oh, and in the case of these classes, if the have few fields, like let's say less then 10, each field should be on its own line.

This is just a simple mock-up. I bet if I boot up an old C# project in Visual studio or an old Java project in Eclipse and copy random ideas from those debuggers, the mock up can be improved exponentially!!!

PS: since I'm here, how do you change the filename of the default application log?
  • Attachment: mockup.png
    (Size: 9.90KB, Downloaded 196 times)
Re: U++ 2017 beta [message #47322 is a reply to message #47321] Wed, 04 January 2017 12:32 Go to previous messageGo to next message
Tom1
Messages: 341
Registered: March 2007
Senior Member
Hi,

Not sure how recent behavior this is, but for some reason:
Format("%.2f",1.23);

results in 1,23 (with comma) instead of expected 1.23 (with decimal point) when using "GUI MT" in Linux. If I select "GUI MT X11", the result is correctly 1.23 (with decimal point).

Can this be fixed before release? If the separators (or date/time formats for that matter) automatically change depending on regional settings used on each computer, reading and writing of various ASCII file formats gets completely out of control.

Best regards,

Tom
Re: U++ 2017 beta [message #47323 is a reply to message #47322] Wed, 04 January 2017 12:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
Tom1 wrote on Wed, 04 January 2017 12:32
Hi,

Not sure how recent behavior this is, but for some reason:
Format("%.2f",1.23);

results in 1,23 (with comma) instead of expected 1.23 (with decimal point) when using "GUI MT" in Linux. If I select "GUI MT X11", the result is correctly 1.23 (with decimal point).

Can this be fixed before release? If the separators (or date/time formats for that matter) automatically change depending on regional settings used on each computer, reading and writing of various ASCII file formats gets completely out of control.

Best regards,

Tom


".2f" is actually using C lib (see FloatFormatter). Can you check the same with 'printf' or 'sprintf' ? (That said, I can certainly recplace ',' with '.' in FloatFormatter, just to be sure...).

Mirek
Re: U++ 2017 beta [message #47324 is a reply to message #47323] Wed, 04 January 2017 13:20 Go to previous messageGo to next message
Tom1
Messages: 341
Registered: March 2007
Senior Member
Hi,

Both Format("%.2f",1.23); and sprintf(text,"%.2f",1.23); use comma as decimal separator when under "GUI MT" in Linux. With "GUI MT X11" both are clean decimal points.

In Windows both used decimal points.

I never imagined GTK could affect text formatting!

Thanks and best regards,

Tom
Re: U++ 2017 beta [message #47325 is a reply to message #47324] Wed, 04 January 2017 14:02 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1190
Registered: September 2007
Senior Veteran
Then GTK must be changing your locale with (non-)portable means of setting this in the std c lib.
Re: U++ 2017 beta [message #47326 is a reply to message #47324] Wed, 04 January 2017 14:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
Tom1 wrote on Wed, 04 January 2017 13:20
Hi,

Both Format("%.2f",1.23); and sprintf(text,"%.2f",1.23); use comma as decimal separator when under "GUI MT" in Linux. With "GUI MT X11" both are clean decimal points.

In Windows both used decimal points.

I never imagined GTK could affect text formatting!

Thanks and best regards,

Tom


OK, so what is the correct resolution here?

Mirek
Re: U++ 2017 beta [message #47327 is a reply to message #47321] Wed, 04 January 2017 14:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 04 January 2017 11:19

But I'll focus on strings first. Won't have probably time for anything more.

Here is a mockup of what I'm thinking:
index.php?t=getfile&id=5159&private=0



Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String.

Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately...
Re: U++ 2017 beta [message #47329 is a reply to message #47326] Wed, 04 January 2017 15:29 Go to previous messageGo to next message
Tom1
Messages: 341
Registered: March 2007
Senior Member
Hi,

@cbpporter: My locale on both Windows and Linux (Mint 18.1) computers is "Language: English, Region: Finland". Numeric formats are under Region, which is Finnish, and surely use comma as decimal separator, but that has never affected my programs on WIN or X11. I do not know how GTK changes the sprintf and Format behavior, but that certainly is annoying and can have severe consequences since the calls to these functions are scattered all around my code in 'million' places.

@Mirek: I bet this will divide opinions: My opinion is that I should be able to trust on Format to use decimal point regardless the region. I.e. the way it has always been with WIN and X11. If region compatible Formatting output is desired, that should be addressed through e.g. some "FormatRegional()" API or some optional formatter flags which are disabled by default.

For some users it might be nice to have numeric values in dialogs shown with regional separators and display formats, but for writing e.g. CSV files (comma separated values), the regional separators will just introduce a catastrophy. (1,23,2,34,3,45 ...) Even, if list separators were different, the international file transfer would be a disastrous mess with tens of file layouts.

--

Is it possible to make U++ on GTK to behave consistently like WIN and X11 do?

Best regards,

Tom

Re: U++ 2017 beta [message #47330 is a reply to message #47327] Wed, 04 January 2017 15:38 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1190
Registered: September 2007
Senior Veteran
mirek wrote on Wed, 04 January 2017 15:49
cbpporter wrote on Wed, 04 January 2017 11:19

But I'll focus on strings first. Won't have probably time for anything more.

Here is a mockup of what I'm thinking:
index.php?t=getfile&id=5159&private=0



Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String.

Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately...

Yeah, that's exactly what I'm doing. Added special logic based on type name. Small price to pay I think for the added benefits. And not just String. A few Core classes should be handled like this too, like Vector, which has abysmal debugging. This isn't 1995 anymore, we can't have it like it is. Plus, the debugger should be aware of a few more other things, like Moveable. Remove all unnecessary information.

Think of the most fancy and elegant scripting language possible. Something people love to use and once they start to use it, become extremely loyal to it, like Python or Ruby. Now imagine how streamlined and useful debugging can look in those (there is support for full time run-time reflection and eval). That's what I want in U++. A String shouldn't have len, ptr, s, wptr, w, q and what not. What are even those? I know what they are, but I don't want to. Nobody does! The debug output should be readable for a String by a baby.

We can't do stuff like in the scripting languages, but we can hard code the debugger to pretty print a couple of hand picked types if in debug mode and if they have the proper layout.

I tested a very early and hack version of this for U++ in 2009, but there was no interest for it. Now I must do it because I can't stand to debug another string where 1/3 of it is cut off so I can have a clear look at the blasted wptr value. Or to debug a vector where I can only look at the first element. Things like this worked in Delphi like 10 years ago. They work perfectly in C#.

I don't have C# installed right now on this computer, but here is a screenshot of a decent, not great debugger:
index.php?t=getfile&id=5160&private=0


The length of those fields in the window are enough to show most strings and there is no extra unneeded info.
  • Attachment: image001.gif
    (Size: 30.76KB, Downloaded 142 times)
Re: U++ 2017 beta [message #47331 is a reply to message #47330] Wed, 04 January 2017 15:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 04 January 2017 15:38
mirek wrote on Wed, 04 January 2017 15:49
cbpporter wrote on Wed, 04 January 2017 11:19

But I'll focus on strings first. Won't have probably time for anything more.

Here is a mockup of what I'm thinking:
index.php?t=getfile&id=5159&private=0



Trouble with that is that it requires "special treatment" for String - debugger needs to be aware that you are at String.

Frankly, the ideal solution would be calling 'AsString' for values somehow, but that aint so easy unfortunately...

Yeah, that's exactly what I'm doing. Added special logic based on type name. Small price to pay I think for the added benefits. And not just String. A few Core classes should be handled like this too, like Vector, which has abysmal debugging. This isn't 1995 anymore, we can't have it like it is. Plus, the debugger should be aware of a few more other things, like Moveable. Remove all unnecessary information.

Think of the most fancy and elegant scripting language possible. Something people love to use and once they start to use it, become extremely loyal to it, like Python or Ruby. Now imagine how streamlined and useful debugging can look in those (there is support for full time run-time reflection and eval). That's what I want in U++. A String shouldn't have len, ptr, s, wptr, w, q and what not. What are even those? I know what they are, but I don't want to. Nobody does! The debug output should be readable for a String by a baby.

We can't do stuff like in the scripting languages, but we can hard code the debugger to pretty print a couple of hand picked types if in debug mode and if they have the proper layout.


Been there - that is what micio with MI2 debugger was trying. For me, it was never really usable. But maybe you will have a better luck Smile

Re: U++ 2017 beta [message #47332 is a reply to message #47319] Wed, 04 January 2017 22:32 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 388
Registered: September 2012
Location: Poland, Kraków
Senior Member
cbpporter wrote on Wed, 04 January 2017 10:06

I remember in my old job, we got some senior on one of the U++ projects. Very talented guy and great coder. Didn't want to use use TheIDE, but said he'll use it for a day or two to see what's the deal with the packages and learn the code and the move over to Visual Studio. Soon, he became very angry, cursing TheIDE. I asked what's wrong. He way very explicitly cursing it, saying what kind of an IDE does not have an "Open file" option. He just wanted to open a file to edit it and couldn't do it. I showed him that the option was "Edit file", not "Open file". He never touched TheIDE again, nor U++ or the project.


Hello cbpporter,

Good catch Laughing - "Edit file" is now called "Open file".

Sincerely,
Klugier


Ultimate++ - one framework to rule them all.

[Updated on: Wed, 04 January 2017 22:33]

Report message to a moderator

Re: U++ 2017 beta [message #47333 is a reply to message #47151] Thu, 05 January 2017 05:01 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 775
Registered: November 2005
Location: Czech Republic - Praha
Veteran

About decimal comma.

Well, in Java world you should always provide also the Locale to be used by the formatter. So then you do thing like str = Format(Locale.US, "%.2f", value) when you are exporting data for machine, or you call with other (none=default) to get formatting for human output, which can include also things like thousands separator/etc (and is not suitable for machine export/import).

Tom1:

BTW, if your OS (GTK) is set to ",", then it sort of does what it should, and I would rather like to see introduction of this Java-like "provide target Locale" logic, than some hardcoded hacks to get "." every time. As when you want to format numbers for your human users, you should follow their OS settings.

I do believe that you can set locale to the "C" even in your source even now (maybe at the start of application, if you don't want to format outputs with default OS settings), to get the printf behaviour with dot. Too lazy to google for some example, sorry. Smile

[Updated on: Thu, 05 January 2017 05:05]

Report message to a moderator

Re: U++ 2017 beta [message #47334 is a reply to message #47333] Thu, 05 January 2017 08:20 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
mr_ped wrote on Thu, 05 January 2017 05:01
About decimal comma.

Well, in Java world you should always provide also the Locale to be used by the formatter. So then you do thing like str = Format(Locale.US, "%.2f", value) when you are exporting data for machine, or you call with other (none=default) to get formatting for human output, which can include also things like thousands separator/etc (and is not suitable for machine export/import).



Actually, that is in U++ for ages:

String Format(int language, const char *fmt, __List##I(E__NFValue));

Only you have to use U++ formatters instead of C ones...

Mirek
Re: U++ 2017 beta [message #47335 is a reply to message #47332] Thu, 05 January 2017 08:23 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
Klugier wrote on Wed, 04 January 2017 22:32
cbpporter wrote on Wed, 04 January 2017 10:06

I remember in my old job, we got some senior on one of the U++ projects. Very talented guy and great coder. Didn't want to use use TheIDE, but said he'll use it for a day or two to see what's the deal with the packages and learn the code and the move over to Visual Studio. Soon, he became very angry, cursing TheIDE. I asked what's wrong. He way very explicitly cursing it, saying what kind of an IDE does not have an "Open file" option. He just wanted to open a file to edit it and couldn't do it. I showed him that the option was "Edit file", not "Open file". He never touched TheIDE again, nor U++ or the project.


Hello cbpporter,

Good catch Laughing - "Edit file" is now called "Open file".

Sincerely,
Klugier


Sorry, but reverted. Creates the wrong impression that we are somehow 'opening/editing/saving/closing' files, which is not true.

Mirek
Re: U++ 2017 beta [message #47336 is a reply to message #47329] Thu, 05 January 2017 08:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 10924
Registered: November 2005
Ultimate Member
Tom1 wrote on Wed, 04 January 2017 15:29

@Mirek: I bet this will divide opinions: My opinion is that I should be able to trust on Format to use decimal point regardless the region. I.e. the way it has always been with WIN and X11. If region compatible Formatting output is desired, that should be addressed through e.g. some "FormatRegional()" API or some optional formatter flags which are disabled by default.


Commited, please check!

Mirek
Re: U++ 2017 beta [message #47337 is a reply to message #47336] Thu, 05 January 2017 09:17 Go to previous message
Tom1
Messages: 341
Registered: March 2007
Senior Member
Hi Mirek,

Now Format() works on GTK like on Windows and X11. (Note to other readers: sprintf and Sprintf still follow the GTK locale for decimal separator, which is not consistent with Windows/X11 behavior.)

Thanks and best regards,

Tom
Previous Topic: upp-10502-winxp32-compiled
Next Topic: On-line meeting before 2017 release
Goto Forum:
  


Current Time: Sat Feb 25 10:42:43 CET 2017

Total time taken to generate the page: 0.00512 seconds