Allegro 4.2.0 beta 2 is ready and has been released. This is a beta release for Allegro 4.2.0 that adds features and corrects problems with regard to the 4.0 codebase. It is
API (source) compatible with 4.0.0 on every platform, except for a few minor changes (see docs/html/api.html).
Get it from the download page on sourceforge.

This release fixes problems in the previous beta, which was announced in this thread. Please download and test the new release, especially if you had problems with that last beta, and let us know if there are problems. Do not hesitate to report problems even if they have been reported before! Please provide an example programme that demonstrates the problem and if possible help to locate and fix the problem. You can reposrt bugs on the forums, but browsing through a long thread for this is combersome so it would be better to post the problem on the mailing list or the tracker.

I would also like to remind you all again of the Allegro demo competition which is still open and encourage everyone to contribute a better demo game! I'll open up a second thread to make sure I reach everyone.

I'm busy doing a test Mac OS X build as we speak, having been unable to build 4.2.0 beta 1.

I have no idea if this is a 'new' thing, but does fix.sh really have to convert the line endings of the Windows, BeOS, etc code? I appreciate it is probably on a simple automated 'find and convert' mission but could this not be fixed by someone somewhere? I don't know any shell scripting but I'm going to have a peek inside fix.sh and see if I can't come up with a solution myself...

I also apologise for raising such a trivial issue. No doubt everything else will compile fine.

EDIT: someone really should clear up the ambiguity in docs/build/macosx.txt about whether "sudo make install-framework EMBED=1" and "sudo make install-framework" are alternatives or may complement each other. I've read it as alternatives but it really isn't very clear.

Hmm... I see datafiles._tx still has over 9 characters. I am guessing it won't build for Watcom DOS. Let's see how it behaves in the other ports.

Quick question: Would anyone happen to have an explaination why running the setup program and clicking "test" would case the setup program to minimize (MS Windows)?

For some strange reason, I seem unable to get allegro to properly output MIDI data. The setup program, no matter what MIDI driver I set it to, refuses to output any form of MIDI. After I get home from school I'm going to try running some tests to see if I can pinpoint what exactly is going on. Just thought I should ask here before I get too far into troubleshooting something that may or may not be a well documented issue in some piece of documentation that I have no access to.

The potential hardware culprit is an integrated soundcard on a HP Laptop, the appropriate linux driver for the sound card is the intel_8x0 driver set (IIRC). Lets see, what else... Ah, the windows hardware resources panel identifies it as a "Soundmax Integrated Audio Device." It also happens to be integrated on a nForce 3 motherboard.

I'm going to see if I can reproduce the problem later. Any comments?

EDIT: This is a confirmed problem on my end with Beta 1 at least. It will several hours before I will have time to troubleshoot this further... No earlier than 3:00 PM Mountain Daylight Time.

EDIT2: I will setup and run the same procedure to see if it is reproducable in Beta 2. Maybe one of the bugfixes above caught the problem. I'll also see if the problem exists in any of the previous versions, like the stable 4.03 branch. Sorry that I can't be of assistance any earlier, I'm busy finishing up some final papers for my classes...

Hmm... ok, this is... wierd. I am leaving for work, but with MinGW (GCC 3.2.3), I did make all, and make compiled the optimized, then the debug, then the profile, then the optimized again (!). Then I did make installall, and compiled the optimized again(!!).

Something is broken somewhere I am guessing. Will see if it happens at work as well with 3.2.

(Edited: Installed the optimized, and now compiling the debugging version again (!!!)).

(Edited 2: Installed the debugging, and compiling the profiling version again (!!!!)).

(Edited 3: Hmm... make 3.79 told me the makefile.dep had changed time in the future. 3.80 didn't say a thing. I will compile again later to see if that happens again. I am guessing 3.80 didn't use the dep because of that. That is what happens when you download the packet as soon as it was released in a eastern country

Just one major OS X problem to report!

Having successfully completed make, sudo make install and sudo make install-framework EMBED=1, I get an error at sudo make install-template. Specifically:

Toms-Computer:/Programming Libraries/allegro-4.2.0 thomasharte$ sudo make install-template
install: d: No such file or directory
make: *** [/Library/Application Support/Apple/Developer Tools/Project Templates/Application/Allegro Application] Error 71

So close!

On the first beta, I was getting odd problems (due to timezones) where a "make install" was recompiling everything after a "make".

Perhaps when Allegro 4.2 is released, it should be announced publically the day after it is posted? This will prevent some initial panic of "it doesn't work!"...

And how would the developers know that something doesn't work?

Isn't there some utility you can make to go through and modify the timestamp on the files so make doesn't get confused Usually IIRC gcc would throw a clock skew detected. I'm thinking a small utility could be whipped up rather quickly.

Actually, I think it's supposed to be so that the timestamp and timezone are stored in the archive and updated when it is unpacked.
Maybe that requires additional setup on the user's system though...

EDIT:

Makes sense. I think it would be pre-released internally for developers first anyway.

Hmm... no idea. Can you try running `make depend' before make? The problems with the first beta were solved by doing that. Just a random guess though.

Ouch... missed that one. Should be easy to fix though.

EDIT2: As a general warning, and probably something I should have pointed out before although it is somewhat obvious: do not yet distribute Windows programmes the depend on alleg42.dll. There can be some mild breakage due to changes and fixes between beta 1 and beta 2 and eventual release.

I'm only referring to problems that timezones cause. I know that when unzipping a recent Allegro build (I'm six hours off UTC) under Windows that strange things happen. Once the time of my system > the time of the release, everything is fine. It just gives a bad first impression to someone who doesn't understand what's going on.

Double-dutch?

As I understand it, the normal framework and the embedded framework are alternatives.

Pete

Why are there timezone troubles in the first place???

The expackf.c reads " Allegr" instead of "Allegro" during one of the tests. Nothing major, I know but still

Oh that's a bug then. Guess nobody tested expackf.c with DOS line endings so far

Argh. I guess we could just place something in the first line for the seek test.. or do something like in your original..

Someone creates the package and uploads it from Japan (example), where it is currently 6:00 PM (example) o'clock, and makes an announcement. I get the notification, and download it half an hour later at 6:30 PM. However, my local time is 6:30 AM. When I uncompress the packet, the date and time for each file will be touched at 6:00 PM, that is, a future date.

Some versions of make will warn that the files have a future modification date and stop the process for you to check. Others seem just to work with them, but will rebuild the files everytime because the original files will always look as if they were modified (make checks if the source is newer than the object files, since the sources were made at 18:00 and I am at 6:30, the program will think I modified the files again at 18:00 and thus the object files need to be rebuilt).

Hope that helps understanding.

Actually, the timestamp on the files in the source archive seems to be their last modification time... so I'm not sure what's going on. At any rate, unzip could (potentially) check the timezone and adjust for that. I could be wrong, but I think tar does.

It is possible, this was one of the first times I downloaded the zip instead of the tar file. Maybe when generating the zip package the developer should move his clock backwards a day and touch all the files?

I don't think you have to move the clock back a day, doesn't touch accept a timestamp argument?

EDIT Yup, sure does:

-d, --date=STRING parse STRING and use it instead of current time

On building the optimized dll with mingw32 (gcc 3.4.2) I get three warnings:

Warning: .drectve `%.*s' unrecognized
Warning: .drectve `%.*s' unrecognized
Warning: .drectve `%.*s' unrecognized

These appear just after running the dllwarp for liballeg.a . The build is nonetheless completed correctly and the resulting library is working. I dont know if these appear on the other configurations.

Also, some preliminary testing shows that the new beta ate ~70 fps from my game (300->230 fps), on both the optimised and debuging libs for both msvc7.1 and mingw32. I'll have to test some more though to see what causes this.

Compiled fine with the free Microsoft Visual Studio 2003 Toolkit, full DirectX 9 SDK from April 2005, and the Platform SDK for Windows XP SP2.

Two problems, though. One is that MSVCRT.lib isn't available (though I just copied it from the .NET Framework SDK v1.1, but there are ways of getting it without having to download the full framework). The other is that the setup I had lacks lib.exe. I tried the solution given here (creating a lib batch file that calls <i>link lib), but didn't work. However, changing in the MSVC makefile from lib to <i>link lib worked.

I tried the makefile.vc modification with MSVC6, and it worked for both dynamically and statically linked. I suggest patching the makefile to prevent problems if someone else uses the free tools:

--- makefile.vc	Sun Apr 10 14:17:14 2005 UTC
+++ makefile.vc	Thu Apr 21 20:14:40 2005 UTC
@@ -134,7 +134,7 @@
    MSVC_CL = $(MSVCDIR_U)/bin/cl
 endif
 MSVC_LINK = $(MSVCDIR_U)/bin/link
-MSVC_LIB = $(MSVCDIR_U)/bin/lib
+MSVC_LIB = $(MSVCDIR_U)/bin/link /lib
 MSVC_RC = rc
 

I don't get these using TARGET_ARCH_EXCL=i586. Probably because I'm using the binutils candidate package released in January.

I was trying to build only the optimized library

fix mingw32
mingw32-make uninstall
mingw32-make clean
mingw32-make

It waits too much (I think) on this line:

gcc -O -Wall -Wno-unused  -I. -I./include -o obj/mingw32/asmdef.exe src/i386/asm
def.c
obj/mingw32/asmdef.exe obj/mingw32/asmdef.inc

(and there's no CPU utilization)

gcc (GCC) 3.4.2 (mingw-special)
GNU Make 3.80
Windows XP SP1
Amd Athlon-64 3200+

[edit]

It should be under Platform_SDK_Dir\Bin\Win64. Anyway I'd like if it could be replaced by your suggested makefile modification

[edit2]

While waiting for the make process on the latest version, I completely recompiled the 4.1.18 version

[edit3] A useless comment, but why does it die so horribly if I do mingw32-make uninstall twice? If I do mingw32-make clean twice it simply says "Nothing to be done for 'clean'"

[edit4] I can't explain it, but today it worked perfectly. I redone the whole compilation process and it finished correctly both times

beta_testers++;

Installation was a breeze on WinXP using MinGW, DEBUGMODE=1.

This probably happened ages ago and has been discussed, but:
When did the numeric values assigned to the KEY_* constants change?
It looks to me like the modifier keys have changed, is this correct?

This would break any program with user-defined keys that are stored as ints in a config file. Can anyone recommend the best way to

• Handle the transition from 4.0 to 4.2

• Make sure this doesn't happen again if the constants are changed again

NB this isn't a rant, I just wonder what's the best way to deal with this?

Pete

For the transition: Either convert the keys, or invalidate old configurations when compiled with 4.2.0.

If you are interested, the problem was, that the key values were ordered like:

normal keys .. modifier keys

So every time a new key was added, all modifier key values increased by one. Right now, the limit of 128 keys is hit - so probably in the compatibility layer, the values won't change anymore (but we'll have to find a way to support more keys, 128 is not enough for many keyboards).

Generally, directly using internal values like the KEY_* values isn't a good idea. But in this case, I guess it is quite safe.. the compatibility layer can't get more than 128 keys, and in 4.3.x I hope we'll simply have an int for every key, so there also will be no need to ever change the values.

Create a key macro to string map and store strings in the config file.
Below is mine. Not useful to you as-is, but editing it might take less time than typing it all in yourself. IIRC, there might also be one in one of Allegro's examples.

Well there's a function scancode_to_name for that... pity it wasn't in 4.0

Pete

Yeah, hmm, I guess it's a recent addition.

Well, I think I might have another bug for y'all to chew on...

<edit>
Os: Windows XP SP2
AMD Athlon 64 3400+
SoundMax Integrated Audio ( comes on NForce 3 mobo's )
GeForce 440 Go 64MB
768MB Ram
</edit>

I've been doing some research into the weird minimizing bug that I have been having with the setup program, and I have been able to reproduce a bug similar to it with the following test program (not the exact same error, but it brings about some interesting results)...

test.c:

The code above is built with this command, FYI: gcc -o test.exe test.c -lalleg

Now, on my system, it outputs the following...

 MIDI Testing Program
 MIDI: Driver Detected, but no way to determine voices
 DIGI: Digital Device Detected, Voices = 65535
 Everything installed fine, I'm lost...
 The Midi Loaded fine, do you hear anything? I'm guessing not

..and then waits for the escape key ( expected ).

However, this is where the "interesting" results come in. Here is what I have noticed. The allegro application creates what is basically a "null" window on the task bar and assigns focus to it (this, I assume, has something to do with grabbing keypresses or something). However, whenever the null window is in focus, the MIDI will not play. If any other window is in focus, the midi does play, which presents us with an interesting problem.

I'm not sure how to further proceed debugging this problem. I can debug my own programs just fine, but a library I'm not exactly sure how to proceed with debugging.

Any ideas?

Also, some other people might want to test this just to make sure I'm not going crazy or that it is just some increadibly wacko hardware problem or something.

Does the same happen if you call set_gfx_mode somewhere at the beginning?

I dunno, let me try that real quick... I will edit with the results.

EDIT:

It actually works even less with set_gfx_mode ( GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0) added right below the voices = detect_digi_driver line.

The Midi stutters now... if you switch focus from the window to the dos window back and forth, you get what sounds like a "frame" of the midi at a time, instead of having the midi playing continuously (well, in fact it may be playing continuously, we can only hear something when we switch back and forth).

Ok. What if you add: set_display_switch_mode(SWITCH_BACKGROUND) after set_gfx_mode?

Adding set_display_switch_mode makes it revert back to the previous symptoms (if main window is in focus, no midi. Midi everywhere else).

Hm, I'm in linux right now.. so can't do much testing myself.. but I have one more thing to let you try : Does the same also happen in exmidi (replace GFX_AUTODETECT with GFX_AUTODETECT_WINDOWED)?

Changing it to GFX_AUTODETECT_WINDOWED causes the stuttering effect.
Adding set_display_switch_mode ( SWITCH_BACKGROUND ) causes the suttering to disappear. Interesing, though, is that the counter on the inside of the window continues to count in both situations (meaning that when the window has focus, it is probably trying to play notes but can't).

Either method ( switch background and default switching mode (no switch line)) with GFX_AUTODETECT (fullscreen mode) fails to produce any midi output.

Uhm... shouldn't that be either DIGI_AUTODETECT or detect_midi_driver?

Thanks. I can just try it with exmidi then when I'm in windows the next time. Oh, which driver was being used?

To me it sounds that somehow Allegro blocks the windows midi player from playing.. now how it does that, I have no idea. Maybe when DX Sound is initialized, there is a flag to let the midi play? Or maybe DX can itself play midi..

gnolam, you are right. However, it still does the same thing... (I'm guessing the #define is the same value for both midi and digi autodetect)

I edited the code post to reflect this.

Huh? You are still calling detect_digi_driver(DIGI_AUTODETECT) twice.

I believe the docs said that the set_gfx_mode() should go before the install_keyboard() etc. otherwise these might fail in some platforms. Have you tried that?

AHHH!!! Attack of TEH TYPOS!!!!

I'll try fixing it right now...

EDIT: See code two posts below for current test case code

GHA! Somedays even I wonder what I was smoking when I wrote stuff...

It still outputs the same thing, though. And the behaviour is still the same, no sound when main window is in focus, sound everywhere else.

As for determining the driver the program is using, anyone know of an easy way to determine it?

digi_driver->name
digi_driver->desc
midi_driver->name
midi_driver->desc

EDIT: What if you put rest(0) in the while loop?

Okay, the driver information the program reports is the following:

 digi_driver->name = Allegmix SoundMAX Digital Audio
 digi_driver->desc = Allegmix SoundMAX Digital Audio
 midi_driver->name = Microsoft MIDI Mapper
 midi_driver->desc = Microsoft MIDI Mapper

EDIT: Placing rest(0) in the while-loop causes the same results in the test program above; no sound while main window is in focus, sound everywhere else.

EDIT:

Test program now reads:

found a keyb scan code bug with the ALT key
http://www.allegro.cc/forums/view_thread.php?_id=484193

I know. Mailing list only is fine for reporting bugs.

as discussed on #allegro, some folks dont think so

Who on #allegro? What did they tell you? Mailing list definitely is fine, unless you need some feedback to confirm it first by others (in which case, send first only here, then later to [AD] if no developer responds).

there was a heated (+1.5 degrees) debate on #allegro about using mailing lists as the primary method for submitting patches/changes/bugs.

I don't know what #allegro means, but I remember the debate. The point was, people not in the mailing list tend think that there's nothing going on wrt bugs, because they are in no way informed about bugs and any progress wrt corrections.

I'm not sure about this, but keeping people informed about bugs and their corrections in this forum seems to be a good idea, but discussing bugs here is not a good idea: discussions should be only in the mailing list.

Hmm... yeah, I meant to log into #allegro again sometime...

A mailing list is definitely fine for doing development work. You don't want to have your primary development on an open forum such as this, because too many people will start to meddle in the discussion. It would be like trying to get work done while sitting in a busy cafe on thursday night. Ultimately, we need less talk and more code.
I've tried to keep track of patches and discussions on the forums here, and it is simply not convenient. I need to do extra steps to download patches, sift to a number of posts that sidetrack the main issue and I can't easily mark a message for closer inspection. With the mailinglist I can and everything is centralised.
For the forums, I already have a hard time keeping track of the things listed in this thread alone.

I've heard the argument that people don't know what's going on. Big deal. The general public doesn't need to know about every petty bug that gets fixed and every comma that gets changed in the docs. Changes are listed in the change logs and some problems and discussion is held here at the forums from time to time. Anyone who has a genuine interest in following the development process can read the mailinglist archives (which are public) or join the list itself. That said, it wouldn't hurt if someone posted regular summaries of what has been discussed on the mailinglist here, but that takes a fair amount of time.

Anyway, what I meant to say was that posting a bugreport on the mailinglist and then report the problem in two threads here is redundant. I understand why you would want to post the problem here and that's fine, but doing it twice is, as I said, redundant. It's fine if you just post on the mailinglist, I'm sure most of us see it at least as fast as a message on the forums.
Bugs don't get fixed faster if you whine harder. We do our best in the time we have.

Maybe we could do something like a monthly IRC meeting, where the most important bugs and so on are discussed, and everyone can ask questions to the developers. But then.. there's hardly any need for it. Let's just keep #allegro as the place for things which are too off-topic even in Off-Topic

You could have a special forum where people need to sign up to post. I agree that having an open forum would just end up cluttering things, but having a small, out of the way mailing list is keeping away potential developers.. I would think even Windows developers since I doubt they'd be keen on such developmental methods (mailing lists). IMO, email isn't really the optimal solution anymore with the amount of spam and server issues that crop up. Not everyone wants their email box flooded (yeah, I know AD is rather low traffic, but AD isn't the only email people would get).

That would depend on the forum in question, wouldn't it? Downloading patches isn't any harder, IMO.. here on Allegro.cc it only takes two clicks, while on things like phpBB it only takes one.

That said, however, I can understand that some of the current developers may not have time for checking forums over mailing lists. A solution is pretty simple though.. you can set up a forum to generate an email to AD when something's posted, and you could make emails posted to AD get posted into threads on a forum. From what I hear, such a thing is fairly easy to set up. The only problem is finding a suitable forum, and there may even be a potential place for that if "the powers that be" think it's a worthwhile idea.

I think the main reasons I prefer email is that I have everything organized and in one place, and that it's much easier to access. Opening a web-browser and getting to the allegro.cc mainpage, then the forums page, then the development forum, takes like half a minute, while clicking on an incoming email on the desktop notification area takes less than a second.

But that's just personal preference I guess. I like the idea of a mailinglist-forum gateway. I'm not even sure posting would need to be restricted.

Somethng like this would be somewhat problematic on the technical side though.. what should be done with the delayed and dropped mails of SF? Like, someone posts into the AD forum - should the post appear, or should it only appear once it actually was sent to AD (which may be anything from seconds to days later).

That's SF's fault and happens currently with entire email domains.. and another reason why it might be better to move away from mailing lists completely.

Yeah, the instability of SF is a big annoyance of [AD]. In an ideal world, both could be combined.. the ease of use of of email, with the immediacy of forums. Hm.. something that would work would be POP3 access to the allegro development forum, so I could simply add it as another mail source in my MTA. And for posting, the mentioned email gateway. I think such a setup would be perfect

I've filtered my AD email since I subscribed, so it doesn't all end up in my inbox. Seems to solve the mailbox flooding issue for me.

That's one extra click in a seperate browser window I need to close again afterwards though. That, and I have to download the patch and then open an editor to look at the patch before I try it because I can't view it inline.
I know, all that could be fixed in principle, but as it is right now I find patches posted on the forum very inconvenient to work with.

The SourceForge tracker already sortof does that... not that it works well, but at least there is something for this. I actually think we should encourage more people to use it.

As for making a forum that doubles as a mailing list browser/archive where you can also post, it sounds like a great idea, but there should be a requirement to register; otherwise you will see the mailinglist become flooded. Someone would have to make this though.

Speaking for me personally, I don't want to move away from a mailinglist completely. The easy way in which I can store or order messages or place marks by them is very important for me, as is the routine of checking the mailinglist along with my mail. I would not read it as thoroughly if it were forum based. In fact, I'd probably find that keeping up to date is too much trouble for me.

Although SourceForge's mailinglist service is (too) often a royal pain in the behind now and then with its insane delays, it mostly works well, at least in my opinion.

Not everyone knows and can be bothered to set up a proper filter. It actually took me a while to set up a filter that properly catches only [AD] email. Some people are stuck with webmail access.

For me in Thunderbird, not all of them come through inline. And the fact that some of them do come through inline has sorta made me lazy to not downloading the ones that don't come through as inline.

If it's what I'm thinking it is, it's quite ugly, hard to follow, and completely unappealing. Why would someone want to use that if you can barely read and follow it? Forum software (even phpBB's default theme shudders) is much better suited.

Elias, why don't you suscribe yourself to the forum feedback? Right now it updates everytime anybody writes anything ain any of the threads... maybe Matthew can create a special feedback for the Allegro Development forum. It is not POP3, but almost as good

I just added it to my rss2email list, but I think it will be too much mails.. but yes, maybe if there's a way to select the forums it contains..

It has the same information the Recent Thread list shows. Will suggest Matthew now, just in case he misses this thread.

Hm, my inbox has almost 50 mails now, and still downloading I got an email for every posting since I added it yesterday (only, the RSS doesn't have the actual message + attachements - so isn't really much more useful than opening the forum manually and scanning the yellow bulbs). Removed it again

[Edit:] Hm, just noticed a symbol "RSS feed" besides some threads (not sure what it does, maybe just never noticed it before).. and Matthew told me there's already some sort of forum-mailing in the works.

I think I filter either on the [AD] string in the subject, or the mailinglist sender ID, both in KMail and GMail.
Anyway, what this will boil down to is that some people prefer a forum because they don't sort or tag their email anyway, while other people prefer email because they do (and, as I said, I find email easier to search through: it's rather harder to keep track of a discussion and posted patches on these messageboards than it is on the mailinglist).
In such a case, I'd vote to keep the status quo rather than invest a lot of time and effort into switching to something else. But as I said, a forum frontend to the mailinglist could work.

Most don't come for me either, but in that case it's simply a matter of clicking the attachment, which opens an editor with the patch. This as opposed to (the current way of) clicking the download link, clicking a button in a new browser window, safe the attachment, close browser window, open editor, open file.

Sounds about right.
This is what it's intended to do though... it's a shame we can't customise the sourceforge page for that, otherwise it would be ideal...

Just set it to always open the file type with the selected application, without asking. On something like phpBB or somewhere else that offers one-click-to-download links, it's exactly the same as in Thunderbird. With something like a.cc, it's a little different because it's a button instead of a link (which I find myself not liking from time to time), but I wouldn't imagine we'd use a.cc as-is.

Displaying it inline (as e.g. Evolution does) still beats that, since there's no application to open at all.

Hm, yes, I guess you're right. So, Matthew.. don't work on all that gateway or whatever stuff unless you want to

On the topic, I can only say that personally, the main reason why I am not contributing anything to Allegro's development is because I loathe mailing lists with a vengeance. I'm sure I'm not alone in this.

Well, that's why there are is this forum and the IRC channel, so someone who can only contribute if there are forums, as well as someone who can only contribute if there's an IRC channel, as well as someone who can only contribute when there's a mailing list.. we have something for everyone

Please contribute if you have the time X-G. You have the skills to help with the development of Allegro.

I have three letters for you. WoW.

And I'm sure I'm not alone in prefering a mailing list.
Anyway, the mailinglist archive is public, though it could be improved, but you can still follow the discussion easily enough. Posting comments or suggestions here is ok, although such discussions do tend to get rather side-tracked easily. Posting patches here is fine too, although I find it generally harder to keep track of them than for the mailinglist.
If you have anything to contribute, especially on the Windows front, by all means share it!

Damn, now that I get the forum contents forwarded to my mailbox I'm actually annoyed that I need to open a webbrowser to post replies.

Heh, same here

And as noted above, displaying inline doesn't always work.

The people who are interested in the forum<->mailing list gateway want to do this, but don't want to go against "the powers that be". I'm not really sure where you got that it was Matthew from..

This forum, which Evert has admitted to having trouble following for patches and things. This forum is not set up for such things, so something better would be needed. And you do realize the state of the IRC channel don't you? Evert doesn't really go there, and even when you (Elias) and Peter do, it's not usually for too long. Not to mention, they're both under different nicks, so no one that isn't familiar with it would know it's you.

That seems to be the growing opinion lately. A shame that something better can't be found, since we could use more developers..

Could you not put together a forum X-G? You already wrote the one for MonkeyBlah didn't you?

Well, I'm not really sure what would be needed. Personally, the only problem I see with the mailing list is SF.. but anyway, I guess your criticism about this forum are just some details which could be improved, so tell your suggestions to Matthew

Yes.. I was just being sarcastic about X-G's claim that the mailing list would be the main reason to not submit code

Well, he implemented an allegro-development -> email forwarder for us (unfortunately with no way to reply, so still have to open the browser to write this)

[Edit: hm, but with an email reply I couldn't have edit my grammar mistake.. OTOH, i would have saved time..]

I "Could" run a little forum email gateway on my host, but would probably need someone to handle writing the forum code. I've got too many projects on the go as it is

Seconded.

Personally, I would have to agree that I find the argument a bit silly. I never felt the urge to any mailing list (I still don't), but I did subscribe to this one because I had something to contribute. I just forgot to unsubscribe again afterwards
If you have something of value and care enough to add it, I don't really see why joining the mailinglist would be an issue. Actually, you don't even have to join: if you're not subscribed the message goes to a moderator (Grzegorz? Peter?) who decides on wether or not to forward the message.

Yeah, you lose some forum features through the mail, such as the ability to edit posts or see edited posts (though there must be a clever way to keep aware of that; maybe a notification if the last post was edited). Going the other way, you would lose some of the things you can do with mail if you switch to a forum.
What I'd love to see most though, apart from the ability to reply, is a direct link in the message to the post in question, and possibly the attachment as well.

Anyway, I think the discussion on `switching' is irrelevant in the sense that both forum and mailinglist can coexist quite easily. If at some point the forum gets used more than the mailinglist, then fine.

Something different on the issue, and something I think most people would be unaware of: at least the primary developers are all subscribed to the cvs-commits mailinglist. This is almost nescessary to be able to track changes in the repository as other people make changes to the code. For overall consistency alone it is convenient to have a mailinglist for discussion as well. It's also practical because you can very quickly pick out an email from the commit list and send a message to the development list in case you have a comment about the patch.

Not to mention mailing lists. I offered a while ago, but it fell on deaf ears. again, I can host a mailing list or 200 as well.

Blah, need to check a mailing list (two if you are also in AL), the A.cc forums and a new forum? Too much. Too much.

The new forum would crosspost with the mailing list, so AD and the new forum would be the same.

Everyone in AD will have to switch to this new forum, because it is possible that some mails never reach the mailing list. But as some hate mailing lists, others find it useful, and would reject switching to a forum.

If you ever do that, add RSS feed with the full text of what has been written and a quick link to reply. I still think it is not needed, but well...

AFAIK, every post to the forum would generate an email to AD, and every email sent to AD would generate a post on the forum.

I saw the post, sorry if I didn't respond.
Personally, much as I hate the slowness of the SF mailinglist, I like some continuity so I wouldn't really want to move away from it too rashly. Since Allegro itself is also hosted on SourceForge, having the mailinglist there is also convenient. For a case like this, I personally also prefer a third party which is at least partly dedicated to providing the service, meaning no disrespect to you.
But if everyone else wants to switch...

On the subject of forums versus mailing lists, I think I'm going to remove the development forum from my recent threads view when Matthew changes the script so I can post through email. I find it so much more convenient to be able to read it through my mail!

Just a sidenote, has anyone noticed that the title of this thread sais Alllegro 4.2.0 beta 2 has been released!?

I guess, that shows how long Evert had to stay up that night to get the beta out

I just had an idea, a way to keep a forum from having messages that the list doesn't. You turn on message echoing (recieving the message you sent) for the forum's recive address, and once your message comes back, then post it to the forum. Also maybe have it setup to queue messages so you can see thier status, and possibly have them be resent if they haven't shown up after a day or more.

I might put something up just as proof of concept.

Even if you could post on these forums as easily as in email, I would hesitate to do any serious development here. Having all the important discussions searchable from one place is a huge boon. That's another reason not to shift the mailing list away from SF too lightly.

What about http://gmane.org/? I've never used it, but it looks like it might satisfy some mailing list refuseniks.

Well, that would be another problem to consider when replacing the ML with a forum.. but just switching to another ML wouldn't mean it would have no search facility for the old archives (just need to import them, even SF managed to do that.. so it must be really simple).

Just looked at gmane.org.. it mentions newsgroups.. and I understand that newsgroups are more like forums (you can edit posts and so on).. but how would it specifically help? I doubt someone who has no proper email client has a news reader..

Peter, Evert, you don't have or need to use the forums that are being talked about. Noone is really talking about completely replacing the mailing lists (if they are, they need some tough love). What I heard was a forum<-> mailing list gateway, somewhat like how gmane works for mailing lists and news groups.

And just so you know, my host provides a standard mailman list with a pipermail archive. Hell, theres even an option to setup a mail<->news gateway. Full controll of the list, vs. Sourceforge... Who knows, maybe we can import the list straight from SF. if of course they'll let you grab an archive of the list...

edit, just for fun, heres what the interface looks like. I havent actually totally setup that list, so who knows what'll happen if you join.

Er, it's SF. That should be enough to know if they let you do it or not

I don't have much experience with SF... I registered one project years ago decided it wasnt worth the pain and never looked back.

I think, instead of bothering about forums or ML or such, take the time to do some serious development for allegro. That time would be much better spent, and really add value. If you have anything to contribute, it just doesn't matter if it is distributed via ML or open/closed forums or anything else.

Yeah, but it's easier to opine than write code.

EDIT: Elias, gmane's web interface looks pretty nice. e.g. http://news.gmane.org/gmane.games.devel.linux. I haven't really looked into posting, but apparently you can do that on the web too, and they use a challenge-response thing to prevent spam.

As for getting ML archives from SF.net, I'm pretty sure it can be done. It's still a pain though.

It seems that if development isn't mailing-list-only, we will have more people to help write code..

Hmm... conditioning help because of medium... then we would get replies about "I would help if XXX wasn't in the project", "I would help if we switch to Berlios", "I would help if you follow my ideas instead of the others"...

More like "We would help if we weren't restricted to just the mailing list." No one's asking to get rid of the mailing list, just that there be another way to get involved with the development.

Who has said that improvements to allegro can't be discussed here?

Simple improvements and active development are two completely different things.

People have been able to post patches here for quite a while, and there have been some discussions as well. I don't see why this needs to be pointed out. I still prefer the mailinglist for technical discussions over the forum and probably always will.

Turning the argument about mailinglist vs forum around (I realise that that is not what we're discussing at the moment), if the people doing the most actual work on Allegro prefer a mailinglist over a forum, doesn't their voice carry more weight than that of people saying that they would do more if...?

It's still not the same thing. People who don't use the forums would miss out on anything going on here/there, and anyone who doesn't use the mailing list would miss out on things there. Since no one seems to want to give up the mailing list, but we can setup a forum gateway.. I don't really see the problem. Best of both worlds, everyone gets what they want.

Yes, as long as they realize what exactly the consequences would be. But as you said, that's not what we're discussing here..

Well, most of the current developers read the forums anyway and can cross-post as needed. Conversely, the mailinglist archives are public (and typically don't lag much behind the delivery anyway, if at all) so those who want to can follow what goes on there fine now too.

On a side note, I anticipate to post less on the forums now that I can follow discussions here (the dev forum) in my mailbox (because I don't need to open the forum page and be tempted to post in other threads than those I came to check out).

I find it a PITA to follow the mailing list archive. It typically runs days behind, from my experience. It's also hard to follow threads since they're so broken up and don't seem to be organized by the date of the latest post.

I have to agree with KC here...

Not only are they a pain to follow, they are A) Relatively crappily formatted. (Try reading it in thunderbird. Heh, that is a mess). B) Don't flow particularly well. C) Have some rather annoying character formatting problems (For instance, %20 poping up everywhere is a good example).

Perhaps if someone could design a less "crappy" looking, "crappy" formatted, and "crappy" lagtimed mailing list I would be more impressed. However, the way it works currently is rather flawed.

For example, why not send an easy to read digest that is in HTML format as well as Text Format? HTML is nice because you can separate the enteries better, provides better formatting opportunities, etc. Not to mention that if the email is RFC822 compliant, the text version would still have to exist.

If someone could write a custom mailing-list/forum combo, it would be rather nice as well. Basically, the mailing-list is nothing more than a notification system for the forum, but also provides a method to mail the mailing list to add additional "posts" to the forum counterpart as well. (So you could use basically either medium seemlessly). Plus, if the forum adopted some sort of common formatting routine (similar to Allegro.cc), the HTML version could include images, functioning links, etc. (Not really important for the most part, but kinda nice sometimes).

Too bad I don't know more PHP

I have some new hardware to replace the stuff I broke, and a newish 21" Samsung CRT monitor \o/ I can't wait to run it at full res, IMAGINE the space

So yeah, I think as a test of my new hardware and monitor, I'll put together a little forum <-> email gateway thing. Shouldn't be hard.

As I said, it doesn't lag too much behind
I think it should be at most a day behind.

I never really used it much, but doesn't changing some of the view settings
help?

No. The mailinglist should not be reduced to a forum notification
system.

Anyway, it seems that Matthew's mail interface to the forum is working, so
that's something at least.

EDIT: will, mostly anyway. Looks like the mailer inserts linebreaks where I don't want them, so I'll need to work aroud that somehow.

So no interest at all anyone? You should all know me well enough by now, I won't do it if noone cares.

I guess it's a bit hard to say. I think we need to see the system in action
before deciding wether or not it will be useful.
What would be great anyway is if you could make a better browser/viewer for
the mailinglist archive. The ability to post responses would be a
relatively straightforward addition to that, I would imagine.

For replacing the SF archive - well, there is interest since SF is so crappy, but probably we won't switch away just now. So no need to work on a mailing list server.

But apparently, there is a lot of interest for some sort of gateway, or development forum. Hm, actually, after all this discussion.. does someone have an example of such a development forum of another project? Something where all the people who can't use a mailing list would then start doing development, if they had such a forum?

EDIT: discard; my mailclient screwed up and I had to retype the message, which was apparently send anyway.

On Thu, 2005-04-28 at 11:14 +0000, Evert wrote:

True, just replacing the SF mail archive with something better sounds
like a great idea.

--
Elias Pschernig

[Edit: Hm, I guess, to be perfect, the email gateway still needs to: remove the first line, remove the signature, and fix up word-wrap.. but it already is nice ]

on a different note, apart from the various bug fixes mentioned in the release note what is hugely different from 4.0.3 and 4.2?

Neil.

Faster X11 drawing, better mixer code.. of course, I'm biased there.

EDIT Silly me.

My favourite change has to be getting rid of the keyboard.dat dependency (well, for all ports except DOS). Someone else will have to give you the complete picture.

Well, among other things there's a MacOS X port, a sane Windows keyboard driver, new font handling code, support for hardware cursors on most systems, platform specific native mouse cursors, the ability (in principle) to use the packfile routines to access other things beside files on disk, vtable entries that can be used (by AllegroGL, for instance) for more hardware acceleration, better text output routines, sane close button handling, native AMD64 support in Linux, run-time cheching if the library versions used to compile and used to run the code are compatible (as opposed to just crashing), vastly improved documenation...
... and of course the bugfixes you already mentioned, which in themselves would be enough reason to upgrade.

Note that many of the things I mentioned here were already possible in older WIP releases, but you did say changes between 4.0 and 4.2
Oh, there have also been some enhancements to the build system, making it more robust and reliable (we hope).

4.0 is not binary compatible with 4.2.

Hmm, yeah, I'm way too tired. Sorry. :/ BTW, Kitty, did you see my edit in "Carrus' midi bug" thread?