BlitzMax V1.33 release candidates now up!
BlitzMax Forums/BlitzMax Programming/BlitzMax V1.33 release candidates now up!
| ||
| Hi, ***** Release candidate 5 now up! ***** BlitzMax 133 release candidates are now available from the product updates page. I strongly recommend installing this to a new 'BlitzMax133rc4' directory for a true clean install. This version mainly addresses a bunch of internal unicode issues. BlitzMax should now be pretty much completely unicode friendly on Win2K onwards and all Mac/Linux platforms. This has involved enough internal changes that I thought a version bump was in order too. The changes *should* be transparent, but are still low level enough to be treated with caution! This is release candidate 4 - it's been put through the wringer a fair bit by the DevTeam but there may still be outstanding issues (as opposed to...?!?). Anyway, here's the relevant versions.txt stuff: **** 1.33 Release ***** Major unicode fix release! * MacOS/Linux/Win2K/XP/Vista: Full unicode support has been added to the BRL, Pub and MaxGUI modules! * Win95/98/ME: MaxGUI now provides unicode support but requires unicows.dll to run: http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ED06-4F0D-80A4-2A7EEAEE17E2&displaylang=en You will need to copy the included unicows.dll into your BlitzMax directory to run the MaxIDE under 95/98/ME, as MaxIDE uses MaxGUI. Max apps that use MaxGUI will also need unicows.dll to run under Win95/98/ME. Unfortunately, unicows cannot legally be redistributed with apps so you will need to notify users in a readme.txt file or similar. The BRL and Pub modules DO NOT support unicode under Win95/98/ME and do not require unicows. * MaxIDE now does a quick test to see if it can write to necessary directories when it starts up. This should detect any potential problems with admin/user modes on Vista. Note: If you install Blitzmax to the default "program files" directory on Vista, you will need to use 'run as administrator' to run MaxIDE. Installing BlitzMax elsewhere (for example, good old "c:\") will allow you to run MaxIDE as a non-admin user. * Several changes to BRL.System and Pub.Stdc - many interfaces that previously used $z and $w params now just use plain Blitz strings. This will hopefully not affect client code in any way! * AppDir and AppFile detection code moved from BRL.AppStub to BRL.Blitz. * TChannel Playing() methods in BRL.OpenALAudio and BRL.DirectSoundAudio modified to return False if channel is paused. * Linux glgraphics window close button now generates EVENT_APPTERMINATE (AppTerminate() in polled mode...) ala Win/Mac instead of just closing/dying. * Linux glgraphics window size now locked ala Windows, Mac versions. * Removed exception handling for SIGILL, SIGSEGV, SIGABRT, SIGTERM. These used to get converted to Max style 'Throw's - but only on some platforms and in a quite probably unrecoverable way. Best just to leave these to the OS/debugger to deal with. |
| ||
| Thank you, Mark! |
| ||
| * Removed exception handling for SIGILL, SIGSEGV, SIGABRT, SIGTERM. These used to get converted to Max style 'Throw's - but only on some platforms and in a quite probably unrecoverable way. Best just to leave these to the OS/debugger to deal with. This in particular is making me really happy...Also seems my key-value observing code isn't crashing anymore. Probably means there's still a bug in my code, but this is just confusing. |
| ||
| TChannel Playing() methods in BRL.OpenALAudio and BRL.DirectSoundAudio modified to return False if channel is paused Nice! |
| ||
| Thanks mark ! removed 132. and install 133. Now i've just an error about maxgui into my program. Previous i used 'Import MaxGUI.Drivers' to use maxgui. What's the right method to use/include maxgui now ? Thanks ! |
| ||
| Have you reinstalled maxgui and recompiled? as it looks like the maxgui package has not changed. (i.e still 132) Cheers. |
| ||
| oups sorry. i've reinstalled my pc and maxgui is inside another package ! !Thanks for the help. |
| ||
| I`m not sure if this is a bug or not but if I load a sound and then play it through a channel without allocating it first then later try to stop the channel from playing I get a BSOD. I know that I should check myself that these types of things are created properly but I can imagine lots of beginners trying this and getting a nasty surprise when their machine crashes. Maybe a simple `channel not allocated` could be added? When installing BMax in the default directory I know that you have to run as administrator but is there a way to stop having to click on allow program to run each time the program starts without resorting to turning of UAC? I have set BMax to run as administrator but I still have to keep clicking allow despite this for some reason. Otherwise it`s nice to see these constant updates. Thanks for your time in providing them :) I look forward to how you expand the language in the future. Jason. |
| ||
| excellent stuff, will use this from now on :) |
| ||
| strange bugs here with floats ! i read a value from my old level file and want display it, ... (note all works fine with 132, i've just tested). drawtext display : -1.#IND0000 to display the float value ! perhaps a bug when convert the string value to float ? n.Vitesse = ReadLine (hFile).ToString() print float(n.Vitesse) ??? t.Alpha# = ReadLine (File).toFloat() ??? i don't know if this is a read file issue or convertion error with the new unicode system. (windows XP french). |
| ||
| I still can't see MaxIDE source, what happened to it? Thanks Mark for nice release. |
| ||
a:String="2.0" Print a.tofloat() result=3868616.00 |
| ||
| Good to see another release! But if Zeke's post is true I'll wait for the next update ;). |
| ||
| result=3868616.00 Ouch, same here (I get 9633564.00). Same goes for ToDouble. Both use atof () in blitz_string.c, and the weird result seems to fit in with this: "If the string is not a valid textual representation of a double, atof will silently fail, returning a random value. It's better and safer to use strtod." This page seems to suggest the 'random' value might be the original pointer/value/whatever: "If the first sequence of non-whitespace characters in str does not form a valid floating-point number as just defined, or if no such sequence exists because either str is empty or contains only whitespace characters, no conversion is performed". a:String="2.0" Print a.tofloat() Print Int (Varptr (a)) The second value is suspiciously close to the ToFloat result (60 bytes), as if ToFloat is getting the address, or an offset, or... something. I guess "2.0" is being converted weirdly before atof is called? (Maybe bbStringToCString?) |
| ||
| who and when will it be fixed??? |
| ||
| I still can't see MaxIDE source, what happened to it? Have you clicked on the spot to download MaxIDE source on your accounts page? |
| ||
| Just when I was getting used to 1.32 you have to up and throw this at me. :-D In all seriousness thanks Mark! We appreciate your hard work. |
| ||
| |
| ||
| I tracked down the problem to bbStringToFloat in brl.blitz blitz_string.c Changed it to: When i now do "0.35".toFloat() it gives me: debug float: |0.35|19597256.000000| Which means the String given to it is ok, but the result of atof is wrong. I can't understand how this can be... Edit: Found it. blitz_string.c does not include stdlib.h, so atof is not defined. And as the bmk does not compile C-Code with -Wall, no warning is given. Just add #include <stdlib.h> to the top of mod/brl.mod/blitz.mod/blitz.h, after #define UNICODE and Floats work again. |
| ||
| Like what James says... atof() is deprecated. Should be using strtod() instead. |
| ||
| It works fine, if it's defined ;) strtod() would also fail if it's header is not included. |
| ||
| Maybe :-) But apparently atof() is not thread safe (according to the docs)... which might be bad for anyone running in threaded mode. |
| ||
| Any function that accesses data and does not lock itself with a mutex is not thread-safe. The user must lock the String using a mutex if he accesses it from more than one thread at the same time. |
| ||
| I got this with regards to atof thread-safety: http://www.mkssoftware.com/docs/man3/atof.3.asp "This function is MT-Safe as long as no thread calls setlocale() while this function is executing." (Nice huntin', BtbN!) |
| ||
| Any function that accesses data and does not lock itself with a mutex is not thread-safe. I should think that would only be the case if the string were mutable, but all BMax strings are immutable, so it's just reading data. I could be wrong though, I'm not entirely familiar with all the issues surrounding thread-safety.The user must lock the String using a mutex if he accesses it from more than one thread at the same time. Edit: Unless you're talking about calling setlocale like BlitzSupport mentioned. |
| ||
| > Edit: Found it. blitz_string.c does not include stdlib.h Nice find! > #define UNICODE Ummm...you shouldn't have a #define UNICODE in blitz.h - this has been removed for 1.33 >Any function that accesses data and does not lock itself with a mutex >is not thread-safe. That should really be "accesses *global* data" - local data/params should be OK. So most string funcs are probably safe, as they just mess with the string. Of course, locale is probably implemented as a global so anything that needs this may not be 100% safe. |
| ||
| Hi, Release candidate 5 now up! |
| ||
| Mark is on the jazz tonight! Thanks :) |
| ||
| Well...String.ToFloat() not working was a bit of a show stopper! |
| ||
| ok. all works fine for me now. many thanks Mark to fix this ! |
| ||
| yes, it is not working. I had to remove the 133rc4 folder and depack again (linux) as overwriting did not cure it. Thanks Mark :D |
| ||
| Mark: http://www.blitzbasic.com/Community/posts.php?topic=84488 Just wanted to point that thread out since currently mutexes behave differently between Windows and Linux (Windows having recursive locks and pthreads, by default, not creating recursive locks). |
| ||
| Awesome support. thanks Mark. |
| ||
| In regard to TChannel Playing() : Ahhh that's why I was getting trouble using this method ^^ Good to hear this one :) Thanks a lot Mark |
| ||
| Just curious... what mingw version should we install now? |
| ||
| still no 64bit support for linux, still useless for me. i still cannot compile any code. |
| ||
| still no 64bit support for linux, still useless for me. i still cannot compile any code. Get a proper OS? :) |
| ||
| Get a proper OS? :) "Configure your OS properly" is probably more appropriate, since it otherwise tends to work fine under Linux. |
| ||
| It would be nice if all DebugLog, DebugStop, etc. calls got completely removed in release mode instead of the debug functions being emptified (I noticed calls to _brl_blitz_DebugLog still exist in the assembler source for release mode). It would also be nice to be able to attach some sort of property to functions and methods that tell the compiler to remove all calls to them in the given '?<opt>'. EDIT: For example (probably something other than metadata would be preferred, for the compiler that is): ' The 'opt_debugonly' metadata tells the compiler to remove this function and all calls to it in any other mode than debug.
' The 'opt_threadedonly' metadata tells the compiler to remove this function and all calls to it if the threaded GC is not used.
' The 'opt_win32only' metadata tells the compile to remove the function and all calls to it if the release target is not windows.
Function SomeFunction(printme:String) { opt_debugonly opt_threadedonly opt_win32only }
Print(printme)
End Function |
| ||
| By the way, I don't quite remember which RC I installed. Is there a way to know that ? (Except from running the about IDE that return BM v1.32) Also, when RC5 is about to change ? thanks |
| ||
| * Several changes to BRL.System and Pub.Stdc - many interfaces that previously used $z and $w params now just use plain Blitz strings. This will hopefully not affect client code in any way! So how would you now define a 8bit char string now as opposed to a 16bit char string? |
   |