.PureBasic v4.00 - Beta 1
Some experiences with PB Release 4 Beta…
1. Installed new release into a new directory and tested a few trivial procedures just to make sure the installation was OK.
2. What next? It would be unwise to convert all my current work over to a new environment that will inevitably have some errors. I must run with 3.94 until the new version is out of Beta. I decided to take a medium size application and go through the process of converting it… this will give me an indication of the complexity and the pitfalls of the conversion process.
3. I chose an instrumentation package that involves DLLs, high speed graphics, some primitive sound functions and multiple screens, about 6400 lines of source. Working with a COPY of the original source I repeatedly compiled it and responded to each error message. I made some arrays global, included the File# into lots of places where the new compiler needs it and generally learned a lot about the new system.
4. I found three major problems and wrote three helpful bug reports. In the process of creating the essential mini-app that showed each problem and how to reproduce it the cause of each error was found, and was always an instance of not reading the documents supplied… More haste, less speed.
5. After about six hours of work the final version now runs with just one problem left… I get a rude message and an invitation to send a report to Microsoft when the program closes. I have seen this mentioned elsewhere so will be patient.
Summary:
No real difficulties upgrading. Be patient and careful. RTFM.
Common sense -- stay with 3.94 for a while for mission critical software.
Click the DONATE button, do NOT let it be lonely and un-loved.
RichardL
1. Installed new release into a new directory and tested a few trivial procedures just to make sure the installation was OK.
2. What next? It would be unwise to convert all my current work over to a new environment that will inevitably have some errors. I must run with 3.94 until the new version is out of Beta. I decided to take a medium size application and go through the process of converting it… this will give me an indication of the complexity and the pitfalls of the conversion process.
3. I chose an instrumentation package that involves DLLs, high speed graphics, some primitive sound functions and multiple screens, about 6400 lines of source. Working with a COPY of the original source I repeatedly compiled it and responded to each error message. I made some arrays global, included the File# into lots of places where the new compiler needs it and generally learned a lot about the new system.
4. I found three major problems and wrote three helpful bug reports. In the process of creating the essential mini-app that showed each problem and how to reproduce it the cause of each error was found, and was always an instance of not reading the documents supplied… More haste, less speed.
5. After about six hours of work the final version now runs with just one problem left… I get a rude message and an invitation to send a report to Microsoft when the program closes. I have seen this mentioned elsewhere so will be patient.
Summary:
No real difficulties upgrading. Be patient and careful. RTFM.
Common sense -- stay with 3.94 for a while for mission critical software.
Click the DONATE button, do NOT let it be lonely and un-loved.
RichardL
geoff wrote: Fred, I hope this is the last time we need such major changes.
I have spent 5 hours converting a PB3.94 program to PB4.0, and I still have 28 other programs to do.
Fred wrote: Why converting all ?
Source code needs to be maintained.the fool wrote:I too don't understand that..
Why?
1) Because applications sometimes needs to be changed.
2) Because it takes a long time to find every last bug, sometimes years.
If you don't convert code you have to keep a different version of the compiler for each of your programs. This is impractical and leads to compatibility problems between the programs which may share common procedures, for example. Old compiler versions are not supported so if you have compile problems you will get no help.
Am I missing something here?
I thought that porting source code to the latest compiler version was standard practice?
Yes, it's definitly not standard to port all your code.geoff wrote: Am I missing something here?
I thought that porting source code to the latest compiler version was standard practice?
The Software company we work with maintains 3 versions of there administrative software, just because it works with Sybase on the server and Omnis7 or Omnis studio on the client side.
They can not affort to go updating all customers to always be on the newest database software an Omnis version....license is expensive also.
So there are 3 update packages when they have an update.
http://www.jurisoft.be/
They now have 5283 users
I wish it was that easy Icesoft.Icesoft wrote:Use search/replace ... you will see... it is faster next time
It's not just name changes.
For example, if you have a procedure that writes to the current open file you now have to pass the file # to this procedure so that the file# can be put in the new Read / Write commands.
Also the File System commands. I had to do a partial re-write of a re-entrant file listing procedure, because of this change.
But I am not complaining about this, the changes make sense.
All I am saying is, lets not change things too often.
---------------------------
To make things easier I have written a small program to create a highlighted text version of each of my source codes, where any commands that require attention are highlighted.
But it takes a time.
The (small) program I am currently working on has 353 highlighted commands, some of which are simple name changes but most aren't.
> For example, if you have a procedure that writes to the current open
> file you now have to pass the file # to this procedure so that the file#
> can be put in the new Read / Write commands
Search: WriteStringN(
Replace: WriteStringN(0,
Very easy. Make it even faster by using an app like this...
http://www.rjlsoftware.com/software/utility/search/
...to do it to ALL your PureBasic sources in one big hit, and you're done.
Then just do a search for all "WriteStringN(0," in each app as required,
and check to make sure they're using the correct file number.
> file you now have to pass the file # to this procedure so that the file#
> can be put in the new Read / Write commands
Search: WriteStringN(
Replace: WriteStringN(0,
Very easy. Make it even faster by using an app like this...
http://www.rjlsoftware.com/software/utility/search/
...to do it to ALL your PureBasic sources in one big hit, and you're done.
Then just do a search for all "WriteStringN(0," in each app as required,
and check to make sure they're using the correct file number.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.