FMC - Comments and Discussion
BlitzMax Forums/BlitzMax Programming/FMC - Comments and Discussion
| ||
| Hi, a while ago I started to develop modules for a new module scope, the FMC. This scope contains some helper modules making the development of BlitzMax applications easier. Since I think these modules could be useful for you, I'm now publishing them. However, these modules are still in development (all versions are below 1.00) and need some improvements and surely also bugfixes. Therefore I'd like you, if you want to, to test my modules and post comments about them telling what you'd like to improve. Improvements and bugfixes can be discussed here. Some features: Every module contains documentation describing the features in that module. Here's a small list of the most important ones: * Abstract classes helping you to structure an application * Simple multi-threading support * Stream classes for asynchronous access * A BASIC-like ImageBuffer/ImageGraphics function to draw to images * Allows launching external executables and easy communication with them * Fixes some bugs in the official BlitzMax modules * Additional gadgets: Splitter, SliderPanel, DragAndDrop * Non-blocking requesters (allows to create multiple requesters at the same time) * Sending an icon to the Windows System Tray * Cutting parts out of a MaxGUI gadget * Working on multiple desktops How to get these modules: The modules can be downloaded using the BlitzMax syncmods tool, which is present in every BlitzMax installation. To make the syncmods tool synchronizing with the server where the modules are located you need to add the following line to the "cfg/modservers.cfg" file in your BlitzMax installation directory: webspace100.we.funpic.de/root/modEach server in the modservers.cfg-file needs to be on a separate line. If you've got an IDE accepting additional module scopes, you can now just add the "fmc" scope to the IDE's list and synchonize modules. The modules should download automatically and are on Windows directly usable. On other platforms you need to "Build modules" before using them. The documentation is included in the modules and should be visible in the navigation tree view on the right under Help/Modules. If you don't have such an IDE (for example the IDE coming with 1.24 doesn't accept additional modules) you can download a Windows version here, see below for the download. If you don't have such an IDE and don't want to download one, you can call the syncmods tool from the command line typing: syncmods fmcYou might have to prepend the path to the "bin" directory in your BlitzMax installation directory depending on whether you've added this path to the "PATH" variable or not. IDE Download: You also can download an alternative IDE for synchronizing the modules: MaxIDE.exe (if you're interested in seeing the source code: it can be found here) - Just replace the new MaxIDE.exe with the old one in your BlitzMax installation directory; then you need to download xsyncmods.exe (source is here) and place it into the "bin" directory of your BlitzMax installation. In order to recompile the modules you currently have to install Bacoreap over your BlitzMax installation. If you just want to use them, you don't need to install anything. Most of the modules are mainly developed for Windows; however, some can also be used platform independent. Sadly I couldn't test these modules which should be platform independent on other platforms than Windows, since I don't have access to a Linux or MacOS system. I'm hoping this will work and you'll have fun in general using these modules. If you've got any question, just ask. |
| ||
| Wait a second.. how are you hosting your own modserver? Also, can people trust you not to be logging passwords and the like? |
| ||
| The modserver is using PHP scripts to imitate the behaviour of the official BlitzMax server. I can post you the PHP source code if you want, it's really simple. You can be sure that this server doesn't log passwords, and doesn't log user names. However, if you don't trust, you can do the command line thing instead of synchronizing with the IDE; on command line, you don't need to specify a password or user name, since my server is for open access (you don't need to register or such) |
| ||
| I'd appreciate being able to host my own, so if you don't mind sending me the code that'd be great. Anyhow, will go ahead and try synchronizing anyway. I figure if people notice me suddenly acting odd that'll be a good sign to change their passwords. ;) |
| ||
| Okay, instead of sending you the information via email, I decided to post it here, just to avoid someone else asking the same thing again ;-) |
| ||
| Hi, to make it easier to update modules while considering to specify the correct password for different servers, I wrote a new SyncMods requester for the MaxIDE. This allows you to specify different usernames and passwords for different servers:  Every module server takes one line in the SyncMods requester. In the example above you would specify your password and username only for the official BMX server - the german modserver (btbn.de/ModServer) and the FMC-modserver won't receive a password. Using this extended syncmods requester you can also specify different proxy servers and module scopes, if you need, for each modserver individually. I updated my first post in this thread, see the "IDE Download" section to download this IDE. |
| ||
| Very Nice! |
| ||
| Thanks! Just to give you an overview about what I'm currently doing: I'm now playing around with network stuff, and created fmc.SocketEx - however currently it doesn't work at all, it actually should be a mix of a normal TSocket and a TWin32Stream, this should have the advance that you can use them in bridges and pass them to called processes. I need this because I'm currently working on an application which remotely executes other processes and connects their outputs directly in a socket... |
| ||
| So this is a Windows-only framework ? |
| ||
| Yes, that means as far as I know about 2/3 is Windows-only, 1/3 is cross-platform or at least is available for the other platforms, too. |
| ||
| Is the multithreading part working on multicore machines or killing BM as any other module so far did? (ie do your modules replace the GC or not. If not, BM can't be run in true MT, just single processor *HT does not mather, it adds no real second thread, just a virtual one*) |
| ||
| I tested and compiled the modules on a dualcore pc. So I guess it works with multicore in general. However, you should notice that it isn't possible to use the debugger or GC (although they are present) from any thread except the main thread. I could write a redirection for the debugger which makes it simply ignoring debugging commands from any thread different to the main thread. However, I couldn't do this for the GC; that means that you can call the GC directly or indirectly from all threads, however, this might cause the application to crash. So when writing the code which will be executed in the secondary threads, you need to be really careful, since the GC is used very often (eg concating two string objects is a GC operation since the resulting string is stored in a newly created object, and creating objects means registering their memory to the GC -> would cause a crash). All in all you can see that it wouldn't make sense to write the main part of code of a project in a secondary thread - instead it's better to write most in the main thread and use the other threads as helper threads. For example the Bridge class implements a secondary thread which just does a simple task, nothing more than moving stream contents around. As for why I couldn't rewrite debugger and/or GC for multi-threading: The debugger does some string output to the ide, and since working with strings often includes concating them, it would need a working GC. So about the GC: The problem about the current GC is that not all references are counted in the object's reference counter - Local variables aren't counted. This is a problem for multithreading since you can't now about the stack and registers of another thread. That means no thread could have a complete overview about the object references, so no thread could be securely handling garbage collecting. Though a big part of the GC is in the modules, there's still something hard-coded into the compiler. Therefore I can't change the GC, though I could write a module replacing the current GC - it wouldn't be compatible with this bcc internal structures which I can't touch. |
| ||
| is this a bug? Import fmc.ProcessStream
Local ps:TStream
ps = CreateProcessStream("t","ffmpeg.exe")
While True
Local lin:String = ReadLine(ps)
If lin<>""
Print lin
EndIf
Delay 5
Wend
The result is as if i never passed a commandline. (I've double checked by running it in the actual windows commandline) Any idea of a work around i can use to pass a parameter to the process? |
| ||
| Sorry, I don't know about ffmpeg very well, but I think I can guess where the problem comes from: Many windows applications especially those written using the c-libs are cutting off the first white space separated token from the command line - this is because they *think* the first white space separated token would always be the program's executable path. However if you call the CreateProcessStream function this is no longer the case: the actual command line is "t" and not "<program_path><space>t" like the application might expect it. So it cuts away the first token and gets an empty string, since there is only one token. To solve this I suggest you to write this: ps = CreateProcessStream("ffmpeg.exe t","ffmpeg.exe")or, more easier:ps = CreateProcessStream("ffmpeg.exe t")The second way is possible because if the second parameter is omitted, windows automatically takes the first white space separated token as the executable file name. |
   |