It is currently Mon Dec 17, 2018 10:57 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 95 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
Author Message
 Post subject: Support for Ascii compilation ends after the next LTS cycle
PostPosted: Sat Aug 09, 2014 11:44 am 
Offline
PureBasic Team
PureBasic Team
User avatar

Joined: Fri Apr 25, 2003 5:21 pm
Posts: 5770
Location: Germany
Hello everybody,

As Fred has explained here, supporting both the creation of ascii and unicode executables in the compiler is becoming a burden and we would like to end support for ascii compilation in order to streamline the library code and make it easier to maintain the PureBasic package in the future. However, the above thread has shown that people wish for a longer transition period, and we would like to honor this wish.

So we decided to remove the ability to compile in ascii mode in the PB version that follows after the next LTS version (that is, the LTS version coming after the 5.2x LTS cycle ends).

There are no exact dates for the releases, but the timeline looks like this:

  • The current 5.2x LTS version will be supported until at least 09/17/2015
  • After that date, a new LTS version will be released with support for 2 years. This version will still have full ascii compilation support.
  • The first non-LTS version released after the next LTS cycle starts will have no ascii compilation support

This means that the first non-LTS version without ascii support will be released in about a year. By staying with LTS releases, you have the ability to use an ascii mode compiler with a fully supported PB version for at least another 3 years starting from today. This should give enough time for a smooth transition.

No changes will be made to the language or data types (The .c, .a and .u as well as the pseudo-types and library commands will remain as they are). The only difference is that the "compile in unicode mode" switch in the compiler will be permanently set to "on".

Please understand that we do listen to the concerns voiced in the discussion thread and that we do not make this decision lightly. I think we have a quite good track record of supporting older technology as is evidenced by the very long support for Windows 9x which just recently ended and by the fact that we still support Windows XP even after MS dropped all support for it. However, in order for us to be able to introduce new technologies (like x64 compilation in the past, or now support for the web with Spiderbasic), we simply cannot support old stuff indefinitely. In order to move forward into the future, we have to leave some stuff behind from time to time. We hope you can understand that.

The PureBasic Team

_________________
quidquid Latine dictum sit altum videtur


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 11:53 am 
Offline
Addict
Addict
User avatar

Joined: Fri Jan 21, 2011 8:25 am
Posts: 1019
Location: 'stralia!
Wise decision! :)

I mentioned that it might make sense to add a special ASCII compatibility library,
basically a simplified version of the string library that allows us to apply basic operations
on "ASCII memory".

Any thoughts regarding that or is this completely out of the question?

_________________
Image
Blog: Why Does It Suck? (http://whydoesitsuck.com/)
"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly."
- Linus Torvalds


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 1:17 pm 
Offline
Addict
Addict
User avatar

Joined: Fri Apr 12, 2013 1:55 pm
Posts: 1058
Location: just outside of Ferguson
Support?
It truly makes sense to define what "support" and "supporting" means.
Obviously we have vastly different concepts.
A professional statement followed by action would help.
What I see is a cascade of more and more new bugs being created and getting worked on, with the Linux ones unacknowledged and unfixed.
That trend seems to be accelerating.

"The inability of a developer to commit to a time frame is a fallacy. Yes there are costs and issues associated with correcting bugs. But I am assuming you are committed, like we are here, to deliver value to our customers. This means you must have the process in place to rank and/or characterize the severity of a bug. Also, that you are prepared to correct problems in a reasonable time frame. This may mean next version, next release, next month or next week. The developer knows the release schedule and can estimate the time required to fix a bug. So, the developer has an idea of the time frame, your support person can establish the severity, so you can give the client a reasonable time frame to resolve the problem." Excerpt from Tech Support Benchmarks & Best Practices.

Since Fantaisie does sell this software, the professional thing to do would be to fix the existing bugs BEFORE charging off to develop new ones.
Broken promises are serious.

Does Fantaisie have a prioritized current PB bug list for us to see?
If by some chance one exists, is it a secret?
I have a list of the bugs that I've found and remain unfixed, and it's too long.
I am becoming somewhat aggravated about this and getting reluctant to use PB to develop significant Linux software because of the certainty of encountering more broken functionality that won't be fixed in a reasonable time frame.

In this case SUPPORT is the wrong word.
The thread's title should be
Ability to compile in Ascii ends after the next LTS cycle

_________________
Keep it BASIC.


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 1:31 pm 
Offline
Addict
Addict

Joined: Tue May 06, 2003 5:07 pm
Posts: 2422
Location: UK
Sounds like a very good decision to me! I almost always use the Unicode mode now.


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 1:55 pm 
Offline
Enthusiast
Enthusiast

Joined: Mon Jul 09, 2007 4:47 pm
Posts: 214
Location: Courthouse
Another LTS cycle will afford me the time I need to do it properly.

Thanks Fred/Freak :)


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 2:36 pm 
Offline
Always Here
Always Here

Joined: Fri Oct 23, 2009 2:33 am
Posts: 5779
Location: Wales, UK
Support is a correct word in this context. That is perfectly good English. The title also reminds everyone that they can continue to use ASCII compilation using the earlier versions.

There will always be room for improvement. PB is perfect for my needs and is always my choice (when the choice is mine to make). PB is a really excellent language and deserves a bigger market share. Fantaisie deserve greater recognition and far less criticism! If the moaners and groaners really think things are so bad, perhaps they could write their own programming language and sell it. It would need to be better than PB........

_________________
IdeasVacuum
If it sounds simple, you have not grasped the complexity.


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 2:41 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sat Feb 24, 2007 3:15 pm
Posts: 728
Location: Germany
heartbone wrote:
Support?
It truly makes sense to define what "support" and "supporting" means.
Obviously we have vastly different concepts.
A professional statement followed by action would help.
What I see is a cascade of more and more new bugs being created and getting worked on, with the Linux ones unacknowledged and unfixed.
That trend seems to be accelerating.

wrong, new versions are much more stable know as it was in past.
Even the betas seem to be more stable then some old final versions. :wink:

Quote:
"The inability of a developer to commit to a time frame is a fallacy. Yes there are costs and issues associated with correcting bugs. But I am assuming you are committed, like we are here, to deliver value to our customers. This means you must have the process in place to rank and/or characterize the severity of a bug. Also, that you are prepared to correct problems in a reasonable time frame.

PB team is doing right that.

Quote:
This may mean next version, next release, next month or next week. The developer knows the release schedule and can estimate the time required to fix a bug. So, the developer has an idea of the time frame, your support person can establish the severity, so you can give the client a reasonable time frame to resolve the problem."

No developer has to know any date. As long as no contract with
a deadline exists. For pb it is officially "when it's done".

Quote:
Since Fantaisie does sell this software, the professional thing to do would be to fix the existing bugs BEFORE charging off to develop new ones.

You know that there is no more charge? :shock:

If you mean with "charging" e.g. "release a new version"
If the small pb team is starting to just fix bugs, there will be
never a new version? We would be still at the feature set of ... 2.0? :lol:
How much fun would it make to program with PB? :wink:
And still bugs would remain, too. :?

Quote:
Does Fantaisie have a prioritized current PB bug list for us to see?
If by some chance one exists, is it a secret?
I have a list of the bugs that I've found and remain unfixed, and it's too long.
I am becoming somewhat aggravated about this and getting reluctant to use PB to develop significant Linux software because of the certainty of encountering more broken functionality that won't be fixed in a reasonable time frame.

Not yet, mabe this will change in future ... but i don't think so.
PB is sold "as it is" ... you should have that in mind at any
time by deciding of using PB or another language for one of
your projects.

The pb team is just doing a great job. Especially in support as considering
the small size. Support in this forum cost you nothing, but they
react frequently ... really impressive. :wink:

MFG PMV


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 3:51 pm 
Offline
Addict
Addict
User avatar

Joined: Tue Nov 09, 2010 10:15 pm
Posts: 1497
Fred & Freak,

I really appreciate the generous amount of notice you have given. Thank you.

Can you post an update with those ASCII to Unicode and Unicode to ASCII conversion procedures so we can begin our transition?

Thanks again!


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 4:18 pm 
Offline
Addict
Addict
User avatar

Joined: Fri Apr 12, 2013 1:55 pm
Posts: 1058
Location: just outside of Ferguson
PMV wrote:
wrong, new versions are much more stable know as it was in past.
Even the betas seem to be more stable then some old final versions. :wink:
Stable is much different concept versus buggy.
Why confuse things?
I acknowledge that you think it is wrong to have different concepts, and the betas are better nowadays. :wink:

Quote:
PB team is doing right that.
OK?

Quote:
No developer has to know any date. As long as no contract with a deadline exists. For pb it is officially "when it's done".
Yes. And they are good in keeping the Windows® version fixed.

Quote:
You know that there is no more charge? :shock:

If you mean with "charging" e.g. "release a new version"
If the small pb team is starting to just fix bugs, there will be never a new version? We would be still at the feature set of ... 2.0? :lol:
How much fun would it make to program with PB? :wink:
And still bugs would remain, too. :?
I think that you very much underestimate the technical capabilities of the PB dev team.

Quote:
Not yet, mabe this will change in future ... but i don't think so.
PB is sold "as it is" ... you should have that in mind at any time by deciding of using PB or another language for one of your projects.

The pb team is just doing a great job. Especially in support as considering the small size.
Support in this forum cost you nothing, but they react frequently ... really impressive. :wink:

MFG PMV
What you have posted here is certainly true, especially if you exclusively program in Windows®. :wink:

_________________
Keep it BASIC.


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 4:52 pm 
Offline
User
User

Joined: Wed Aug 06, 2008 8:21 am
Posts: 72
OK and thanks, this will give me the time i need to move to another programing language. 8)

_________________
PureBASIC v5.41 LTS , Windows v8.1 x64
Forget UNICODE - Keep it BASIC !


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 5:01 pm 
Offline
Addict
Addict
User avatar

Joined: Tue Nov 09, 2010 10:15 pm
Posts: 1497
marroh wrote:
OK and thanks, this will give me the time i need to move to another programing language. 8)

You are unhappy with a relatively small change, so you are going to make a huge change?

Odd logic.

Or, looking at it another way...
You feel it is too large of a task for YOU to convert ascii to unicode, but it is ok to ask Fred and Freak to do it for hundreds of library files?

More odd logic.

If you are happy with the way PB is now, then use keep using PB, as it is. Why rush to change things just to avoid a chance?


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 5:12 pm 
Offline
User
User

Joined: Wed Aug 06, 2008 8:21 am
Posts: 72
Tenaja wrote:
marroh wrote:
OK and thanks, this will give me the time i need to move to another programing language. 8)

You are unhappy with a relatively small change, so you are going to make a huge change?

Odd logic.

Or, looking at it another way...
You feel it is too large of a task for YOU to convert ascii to unicode, but it is ok to ask Fred and Freak to do it for hundreds of library files?

More odd logic.

If you are happy with the way PB is now, then use keep using PB, as it is. Why rush to change things just to avoid a chance?

Odd logic, i need the feature to build ASCII exe, this is fact for me. Pointless to to discuss it, that you and other should accept.

_________________
PureBASIC v5.41 LTS , Windows v8.1 x64
Forget UNICODE - Keep it BASIC !


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 5:25 pm 
Offline
Addict
Addict
User avatar

Joined: Sat Feb 19, 2005 2:46 pm
Posts: 1749
Location: Pas-de-Calais, France
Good decision, and thank you for this communication effort. I'm also supporting the idea of continuous simple operations on ascii strings, as pb is one of the best tool for hackers, electronicians, phreaks and other computers monsters.


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 5:49 pm 
Offline
Addict
Addict
User avatar

Joined: Wed Aug 31, 2005 11:09 pm
Posts: 3669
Location: Italy
I wondering... would be wise to continue to use SizeOf(Character), StringByteLength() and similar constructs to be able to support in future maybe unicode encodings not exactly 2 bytes in len or is ok to simply consider a char len = 2 like you did for ascii with char len = 1 ? This when you know your program will have to access only unicode data and not other formats.
I would still tend towards using this type of code not making supposition. In short to continue to code as an ascii build were still possible.

_________________
Philosophy is questions that may never be answered. Religion is answers that must never be questioned.

[ My little PureBasic review ]


Top
 Profile  
Reply with quote  
 Post subject: Re: Support for Ascii compilation ends after the next LTS cy
PostPosted: Sat Aug 09, 2014 6:05 pm 
Offline
Addict
Addict
User avatar

Joined: Sat Feb 19, 2005 5:05 pm
Posts: 1769
Location: Norway
Does certain people here have an axe to grind? It certainly seems that way.

Instead of PB 5.40 having the change the next LTS will instead (hilarious if that turns out to be 5.30 though).
A new LTS will continue when the old stopped so if current LTS (5.2x) ends in 2015, and the next LTS will last 2 years then that means all the incompetent programmers have until sometime in 2017 to update their own code. (TWENTY BLOODY YEARS AFTER MicroSoft moved to unicode), people say MicroSoft is slow, but when you are 20 years slower than MicroSoft? That's really slow...



If you software is so ascii encrusted with codepage dependancies then how the hell do you ensure your software handles filrnames correctly.
How do you ensure a bank statement has the correct name when it doesn't get the charater ø correctly?

People wonder how come so much software is so shitty... This is why.

Some people here have had excuses like "oh but the Delphi 7 program I'm making dlls for don't support unicode dlls", that's not your or PUreBasics problem that's te crappy developers of the Delphi 7 program.
Also, you dll can be unicode and still be used by a ascii program (or vice versa) if you just code things correctly.
If you already make tailored dlls or you make s program tat uses legacy dlls then you already are neckdeep in kludge code so a line or two extra won't make matter worse.

Also, some are complaining as if the PureBasic they use will be removed from their hands, preventing them from developing software. Must be Insanity or something. You will still be able to download the last "ascii" PureBasic from the website (Fred will make sure it is available there I'm sure).

And as to not having a ascii LTS version any more, what's the issue? an LTS is like a year or two of extended polishing. Any bugs or issues that are left re non-critical or can be coded around (if not they would have been fixed much earlier).
And if your software managed to do fine using the same LTS for a year or two or more, then you can not possibly have had issues with those bugs or do people simply like to save up a list of secret bugs (and annoy their clients?), otherwise any bugs or issues in deployed software would have been reported to and fixed by Fred already during the LTS period.
If there truly was a critical bug ten you as a developer would have to have made a workaround already to ensure the software works for he clients right? So if the LTS has ended, why not keep using that workaround, it's stable right? *sigh*

As a developer it is your responsibility to be up to date, that means not just updating to the latest LTS but the latest PureBasic as well and let your clients benefit from the improvements, whom in turn will benefit their clients.

Do you know what happens when you lag behind and refuse to improve or evolve?
This October/November the bank system in Norway will be dropping Java for the bank authentication and instead use a HTML5 based solution.
This means during a few months the userbase for Java in Norway will plummet through the floor as maybe more than 90% of all Java users will no longer need it, I'm pretty sure Oracle is shitting their pants at this as it means that users will have no need for Java in their browsers any more.
And that's just Norway, other nations has already changed or will change away from a Java solution.

If people are so geared at maintaining legacy code and systems, then what is the problem of using a legacy compiler? Wouldn't that match perfectly with the system then?

Also if people are concerned with bugs/issues now and the LTS, how the heck did you software even work with older releases of PureBasic?

Or is it just that you are greedy conniving developers who let the PUreBasic team "fix" issues indirectly for your clients that you should have fixed yourself as developers for your clients.

As a developer it is your responsibility to give the client what you promised and use whatever tools and methods to make it work for them. If that means being stuck with an old release of PureBasic then so be it.

Or you could do the smart thing and upsell it to the client. "Don't you want to be able to accept Japanese costumers? Don't you want to accept Chinese companies?"
Messing up names and characters is one thing, but once legal agreements get names wrong or worse addresses wrong for deliveries it can get expensive real fast.
Filenames is another mess as that can cause system to crash if you are unlucky. Or worse give a hacker root/admin access just because The system has a different codepage than your program expected it to have.

Also I'd like to repeat something I've said before.
The PureBasic team are NOT removing the "ability to handle ascii"!

What will happen is that you may need to add a few lines of code to convert from/to ascii when dealing with non-unicode dlls or programs etc.

Also again, the current LTS has been around how long now? a year?
I'm pretty sure most that has ascii legacy software is using the current LTS (or even a older PureBasic), so what are thoe people doing now? Are they halted in development saying to their cliets that they can program for them?
Of course not, for some reason they are able to provide what the clients want despite how "buggy" the old PureBasic release are. Strange that huh?

Why will that be any different/more difficult when the current LTS ends? IT wont', it doesn't change a thing. If the current LTS had a show stopping bug then that wold be fixed.
I highly doubt a bug will lie in wait and sneak around the corner in 2015 and go "PEEKABOO" all of a sudden and crash your program.
If you are able to develop today with the LTS and ship that product to your clients then you are able to do so in a year or two or 5 anyway on the few Windows 2000 systems still existing by then.

I know the real reason why so many are resisting. It's going to take a little extra work, oh buhuu cry me a river. I dropped ascii support when I decided to support only Windows 2000 and later, and that was years ago.
And if someone uses a old shitty program that do not handle characters than are not the 26 in the English alphabet ten I tell them that t software is shit and I tell them where to find one tat works and won't mangle the names/titles on their song collection, that won't corrupt their filesystem or image collection, or will be able to do invoices with correct names and addresses.
Heck the Euro currency sign does not even exist in ascii, good luck denoting that currency in your crappy old software.

Do you realize that the copyright sign may be stored differently in various codepages?
This means that on some system your work will have the copyright symbol while on other not. Oops? Do your clients like that "bug"?

Have you ever tried to play a Japanese Visual Novel? A ton of them are ascii only and often pop up error boxes in Japanese complaining about something looking like a filename, because the codepage is wrong.
I have had software (Russian even) fail to install because it assumes it was on a system with a Russian codepage, oblivious to the US-English codeage on my Norwegian system (my locale is set to Norway but the Language is English), it wrecks havoc with crappy old ascii software that often fail to run properly or have messed up text because of it. And trust me that as soon a I find a alternative way or a better program I remove the old crap and never use it again, a user/customer lost because they didn't support unicode/have a unicode exe.

And those complaining about Unicode performance or wanting more UTF8 features...
I wouldn't be surprised if performance and features related to uinicode and UTF8 would improve a lot over time, after all with unicode being the only build choice there is double the incentive it performs well and is useful.

Also, it is not a n issue to deal with a ascii dll from a unicode program. Take BASS for example, it accepts filenames as unicode if you set a flag (and you use the p-unicode pseudotype), if you do not use the flag it accepts filenames as ascii only. (which will fail with non-ascii filenames obviously, and unicode has no issues with ascii filenames in the first place).
Then in other parts of BASS it only accepts ascii, no flags here, so you must use a few macro and prototypes (using the .p-ascii pseudotype) to push that text along.

There are also a few odd MicroSoft Wndows APIs that expect ascii strings despite actually being unicode dlls. Again prototypes and pseudotypes does the trick here (and ther is always PeekS and PokeS for other situations).


You can complain about PureBasic not progressing, then complain that it is progressing (just because you are slow/lazy/too cheap to keep up with progress).
If you refuse to keep up because clients will move to other companies because they wont be moving to unicode then the clients suck, ad it's just a made up excuse.
What will happen is that another company with smarter clients will outcompete your client because they keep up with progress, and then your client will see their competitor get all the action and they will move providers as well. But now it's too late, you lost all your big clients, oops?

If you are "surprised" by unicode today, where the hell where you a decade ago or two decades ago? In a daze? Or where you even born yet? Or is the other direction that is the issue?
Are you a 125 year old geriatric programmer that dream of the good old COBOL and pre-Y2K days when using two digit years was not an issue?



Note! I keep saying "you" a lot s a generic term to refer to the many in this case, but I'm pretty damn sure somebody here will think of themselves as "you" and be very offended.
This post is neutral, there is no smiley or frowny faces, no personal attacks, but wait and see, somebody will get personally hurt anyway for some reason.
""Lazy programmer" how dare you call me that?" they will shout. And I'll simply tell them, "It takes one to know one!"...


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 95 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

 


Powered by phpBB © 2008 phpBB Group
subSilver+ theme by Canver Software, sponsor Sanal Modifiye