Page 5 of 7
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 2:17 pm
by User_Russian
c4s wrote:That's not true. I might be wrong in some degree but as far as I know Fred and Freak are not really involved in that. There are at least two forum members who take care of the 3D part.
Then what did do Fred and freak, between versions 4.61 and 5.00? Fact in version 5.00 almost all the updates are related to 3D.
In PB not many basic things, such as unsigned variables, OOP, etc. Why did his do even more waning, removing ASCII. This degradation pathway!
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 3:17 pm
by heartbone
Fred wrote:There is absolutely no plan to drop the 3D engine which is an intregral part of PB, so this whole discussion is moot.
Thank you for the statement of clarification.
I plan to use the 3D components in most future projects.
I find the discussion illuminating (from the perspective of the peanut gallery).
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 6:13 pm
by Olby
User_Russian wrote:c4s wrote:That's not true. I might be wrong in some degree but as far as I know Fred and Freak are not really involved in that. There are at least two forum members who take care of the 3D part.
Then what did do Fred and freak, between versions 4.61 and 5.00? Fact in version 5.00 almost all the updates are related to 3D.
In PB not many basic things, such as unsigned variables, OOP, etc. Why did his do even more waning, removing ASCII. This degradation pathway!
This is a very conservative way of thinking. Nowadays society is all about representation and inclusion. So "the majority gets to decide for everyone" is a concept of 20th century and should generally be avoided. Instead, where possible, we need to cater for all groups within the greater society. This example translates directly to PB, if Fantaisie has made the decision to keep Ogre we should respect that. There are people who actively use or plan to use the 3d command set. I have used Ogre to create non gaming software (to render Google Street View panoramas). Besides, as far as I understand, Comtois is the man behind majority of Ogre wrapping. And don't get me started on this whole OOP thing... tons of other objective oriented languages out there.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 6:58 pm
by marroh
Fred wrote:There is absolutely no plan to drop the 3D engine which is an intregral part of PB, so this whole discussion is moot.
The fact is that ASCII also was all the time a inherent part of PureBasic, so absolutely nothing is certain in PureBasic future.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 7:21 pm
by Danilo
That's life. Everything is uncertain, nobody knows the future. You can plan for the next 10 years, and pass away tomorrow.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 8:39 pm
by skywalk
freak wrote: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".
Code: Select all
;FROM C
;typedef struct myStruc{
; int mac_enabled;
; char mac_address[4][12];
;}myStruc;
;TO PB v5.3 ascii
Structure myStruc
mac_enabled.l
mac_address.s{12}[4];<-- With Unicode only compiles, do I lose this easy C translation?
;<-- Or are fixed len strings still 1 byte per char?
endStructure
;TO PB v5.4 unicode
Structure myStruc
mac_enabled.l
mac_address.a[12*4];<-- Now I have to build my own parser for each string :(
endStructure
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 9:10 pm
by Danilo
@skywalk:
Wouldn't it be better to introduce a new structure, because PB does not support multi-dimensional static arrays ( [4][12] or [4,12] )?
Code: Select all
Structure mac_address_field
_data.a[12]
EndStructure
Structure myStruc
mac_enabled.l
mac_address.mac_address_field[4]
EndStructure
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Aug 13, 2014 9:32 pm
by skywalk
Yes, a nested structure can help, but you can see we are losing a datatype and creating more work.
I wrote a c to pb header converter and doing this type of nesting is rather complex.
That is why I collapsed [4][12] to [4*12].
But now I also have to change the datatype and add code to manipulate these type of 1 byte char fields.
Arggg, double arggg.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Thu Aug 14, 2014 10:40 am
by dige
Hi folks, I guess the most people here, who use PB are not employees at Disney, Electronic Arts or whats ever.
Most projects are one man shows and lacks skills of designers, graphic artists, etc..
It is the great PureBasic programming language, that we can create impressive programs very easy.
Therefore I do not expect that someone creates a famous game here in competition to big teams with many contributors.
PB is developed fantastic and I am very happy, that I've decided to use this programming language years ago.
I must admit, that I have never done anything with Unicode and I use many Libs (including by Gnozal), they only run with Ascii
and also no longer be developed, however.
For me it's a big hassle to upgrade to Unicode, but most importantly to me is, that PB will continue developed and the language runs as stable as possible. So if it has many advantages for the team, then do it.
Just my two pence.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Thu Aug 14, 2014 11:50 am
by useful
just a note
https://wiki.debian.org/ReleaseGoals
|_
https://wiki.debian.org/ReleaseGoals/utf-8
Full UTF-8 support in all packages (support input and display in UTF-8 by
default(*), the delivery of
ALL(*) text files in UTF-8, delivery packages
ONLY(*) files with names in UTF-8).
(*)my selection
p.s. Thus, let's completely
eradicate https://en.wikipedia.org/wiki/Mojibake 
however, the trend
p.p.s(2014.08.22) looked announcement wxwidget 3.0 and surprisingly it on jump 2.x -> 3.x for full disclaimer ascii in favor of unicode
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Thu Aug 14, 2014 3:20 pm
by Thorium
Well, time to switch to unicode. Didnt used it much befor, but i dont see any hard problems.
The only reason to use ASCII today is if you have to interact with legacy applications or systems, in which case you can use a legacy PB compiler without problems.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Sep 03, 2014 6:07 pm
by the.weavster
Hi Fred/Freak
According to the help file the AES cipher commands need the compiler to be in ascii mode, will those commands be updated to work in a unicode executable?
Those commands (or at least some form of encrypt/decrypt commands that are also supported by PHP) are quite important for something I've just started to work on.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Sep 03, 2014 6:23 pm
by freak
the.weavster wrote:Hi Fred/Freak
According to the help file the AES cipher commands need the compiler to be in ascii mode, will those commands be updated to work in a unicode executable?
Those commands (or at least some form of encrypt/decrypt commands that are also supported by PHP) are quite important for something I've just started to work on.
It just says that on the example because it it uses Len(x) to allocate the memory for the ciphered string (which will be too short to fit the unicode string). We just need to fix the examples to work in unicode, that's all.
The AES commands themselves are not affected by the unicode switch.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Wed Sep 03, 2014 7:16 pm
by the.weavster
freak wrote:It just says that on the example because it it uses Len(x) to allocate the memory for the ciphered string
Thanks.
Re: Support for Ascii compilation ends after the next LTS cy
Posted: Fri Sep 05, 2014 7:57 am
by the.weavster
Rescator wrote:Don't people realize that an ascii string can be stored in a unicode string? *shakes head*
RealBasic has two simple functions that make this very easy, PB equivalents might look like this:
Code: Select all
InternalString$ = DefineEncoding(IncomingData$,#PB_UTF8) ; for data being read into the program
DataToExport$ = ConvertEncoding(InternalString$,#PB_UTF8) ; to output data in the correct format
I'm assuming from what you've said this should also be achievable in PB.
It's been a very long time since I've used PB (it's really SpiderBasic that's got me interested again), last night I was trying to figure out how you'd achieve the above and to be honest I'm still not sure. I've also read both threads about Fantaisie dropping support for ascii compilation and there's been talk of Buffers, Peeking, Poking, Pointing and pseudo-types... it all sounds horribly complicated compared to the two commands I'm used to.
Are strings in SpiderBasic UTF8? If there's going to be an inconsistency between the strings in PB and SB it would be even more helpful if the commands for handling encodings were as simple as possible.