Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » If it's true, you don't believ in the afterlife.

This thread is locked; no one can reply to it. rss feed Print
If it's true, you don't believ in the afterlife.
Trent Gamblin
Member #261
April 2000
avatar

Globs are not expanded by the shell on Windows, they're expanded by the program/runtime, so that explains that.

bamccaig
Member #7,536
July 2006
avatar

Oh, sorry, I didn't realize that Edgar was running this in Windows. Thank you, Trent. Yes, report that bug to Microsoft. It's their bug. The MSYS developers had to hack their utilities to do the globbing themselves because the Windows command shell doesn't. So the shell would create the TODO.txt file and literally send ".*.*" to MSYS grep. MSYS grep then would do the globbing because Windows is too stupid to, and would find TODO.txt in the process since the shell had already created it. Again, grep(1) doesn't know that it is writing to TODO.txt, and Windows even less likely to make it possible for it to find out (not that it's even responsible for such a thing). grep(1) has no bug in this case, except for the globbing which is a workaround for the bug in Windows.

Edgar Reynaldo
Member #8,592
May 2007
avatar

I just looked at the Allegro Hacker's Guide more in depth, and it is totally dated to A4. Perhaps we could create a new one?

Also, I am starting a page on the wiki on Contributing to Allegro. It just has the recently grepped TODO list on it right now, but feel free to add to it. It also has a link to the A5 roadmap for what its worth.

Also, what about having an Allegro Hack Day? There hasn't been one since 2008! :o You know you want to!

Re: grep

I'm running the gnuwin32 versions of the tools btw.

Hate to bother you, but this :

Globbing.cpp#SelectExpand
1 2#include <cstdio> 3 4int main(int argc, char** argv) { 5 for (int i = 0 ; i < argc ; ++i) { 6 printf("Arg %d = '%s'\n" , i , argv[i]); 7 } 8 printf("\n"); 9 return 0; 10}

does this when run :

c:\...\page_table>mingw32-g++ -Wall -o Globbing.exe Globbing.cpp

c:\...\page_table>Globbing.exe .\*.*
Arg 0 = 'Globbing.exe'
Arg 1 = '.\Globbing.cpp'
Arg 2 = '.\Globbing.exe'
Arg 3 = '.\pagedebug.exe'
...
Arg 13 = '.\Utility.hpp'

c:\...\page_table>

So it isn't the program expanding the glob. It is either the shell or the mingw runtime.

Let's try an experiment.

(Globbing.txt does not exist yet)

c:\...\page_table>Globbing.exe .*.* > Globbing.txt

c:\...\page_table>type Globbing.txt
Arg 0 = 'Globbing.exe'
Arg 1 = '.\Globbing.cpp'
Arg 2 = '.\Globbing.exe'
Arg 3 = '.\Globbing.txt'
Arg 4 = '.\pagedebug.exe'
...
Arg 14 = '.\Utility.hpp'

c:\...\page_table>

So the file handle is created before the program is run, and then passed to the program as stdout. And since the file is already there, the globbing run by the shell or runtime sees Globbing.txt and happily passes it to the program.

I guess that's another bug in the cmd shell. But, is it still grep's fault? What if you open a write file handle and then try to open a read handle on the same file? What happens? Let's find out.

If you try to open a FILE handle in "w" mode to a file that is being piped to by the shell, it fails on Vista with MinGW 4.8.1 at least. If you try it in "rw" mode it succeeds but reads and writes to the file silently fail. If you try it in "r" mode it succeeds but reads fail. I tried it. If you try to open a read handle to the file being piped to it never reads input and fgetc returns EOF right away.

What's my point? If grep is opening the TODO.txt file in read-write or read mode at the same time as it is being piped to then all reads should be failing and their file "w" handle should be null too. I can't explain why they're not. How are they able to open the file and successfully read and write to it (recursively no less) if MinGW can't?

Edit
There is another wiki page similar to the one I just made, Allegro development. How about we merge the two? I put in some more details that might be helpful.

bamccaig
Member #7,536
July 2006
avatar

Perhaps we should note that just because somebody writes "TODO" in source code does not mean that what they describe is correct. It just means that they felt their solution was incomplete and that more attention may be needed to make things work their best. If the change is non-trivial you should discuss it on the mailing list first.

Re: grep(1)

The idea of exclusively locking files is more of a DOS/Windows-ism. In the *nix world, unless you go to lengths to lock the file, another process is free to read from it, and possibly to also write to it. I suspect that the UNIX software does its best to work this way despite the limitations and design flaws of Windows. That said, allegedly cmd.exe opens files for redirection exclusively, which might explain the behavior that you see, but doesn't explain how grep(1) is able to access the file then. Of course, I'd still say the bug is in Windows. Not only is it stupid for cmd.exe to ask for exclusive access, but it's the Windows kernel that is presumably letting grep(1) bypass that somehow. I suppose the only way to know would be opening up the MinGW grep source code.

Dennis
Member #1,090
July 2003
avatar

Sooooo... what's up?

LennyLen
Member #5,313
December 2004
avatar

Dennis said:

Sooooo... what's up?

Anything that's not down.

Aaron Bolyard
Member #7,537
July 2006
avatar

I still use Allegro! In C#. Well, kind of. I use it for everything but drawing.

Because I wrote a resolution independent curve renderer and it requires a few more modern features than Allegro exposes...

But it works pretty nicely.

Here is the test image in InkScape:

{"name":"609093","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/2446b0f1addd28d971f667a615ebd98c.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/2446b0f1addd28d971f667a615ebd98c"}609093

And here it is in my C# 'Canvas API':

{"name":"609094","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a3928f307e014663100690114ecbdfae.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a3928f307e014663100690114ecbdfae"}609094

Preeeetty nifty.

Thomas Fjellstrom
Member #476
June 2000
avatar

I wrote a resolution independent curve renderer and it requires a few more modern features than Allegro exposes...

Like what exactly?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Aaron Bolyard
Member #7,537
July 2006
avatar

Like what exactly?

Well, I use forward compatible OpenGL 3 context. I use the stencil buffer and various depth buffer sorting modes, things that aren't exposed by Allegro. I also use OpenGL 3.0 GLSL shaders (well that's kind of obvious) because I fetch noninterpolated texels so I can batch the geometry into as few draw calls as possible.

To clarify, I'm not rendering raster images. In one draw call, I render that entire scene, with the proper depths to ensure order independent translucency (stored in a R32 texture) and colors (stored in a simple RGBA8 texture). With my curve rendering, I can zoom in... as far as I want...

{"name":"609095","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9747b836629e957b2be798050d3aac8f.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9747b836629e957b2be798050d3aac8f"}609095

Chris Katko
Member #1,881
January 2002
avatar

Dude, you're my hero. :o

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

bamccaig
Member #7,536
July 2006
avatar

^ This. That looks damn cool. Remember:

{"name":"f3e0a39eca9ed9f234ed2a48a0736d200daaa01d4a49e4c1dd9a853c61f4f7cf.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/5\/b5864abd6315feb995ec326732d6e2e5.jpg","w":445,"h":280,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/5\/b5864abd6315feb995ec326732d6e2e5"}f3e0a39eca9ed9f234ed2a48a0736d200daaa01d4a49e4c1dd9a853c61f4f7cf.jpg

Onewing
Member #6,152
August 2005
avatar

Well, I use forward compatible OpenGL 3 context. I use the stencil buffer and various depth buffer sorting modes, things that aren't exposed by Allegro. I also use OpenGL 3.0 GLSL shaders (well that's kind of obvious) because I fetch noninterpolated texels so I can batch the geometry into as few draw calls as possible.

I am going to memorize this word for word and then drop it on a non-tech client (add a scoff to "well that's kind of obvious") whenever they make a "small" front end change request. :)

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Thomas Fjellstrom
Member #476
June 2000
avatar

Well, I can say that we do support OpenGL3, not entirely sure if its a forward compatible context or not, but I'm actually using GL3 in my little personal project. Stencil support is something I think we should add. And depth buffer modes sounds like it should just be a display or bitmap option, and shouldn't be too hard to add. If you're interested, one or more of the dev's would be happy to assist you in adding these features.

I already blast all kinds of data at the GPU at once via VBOs and do all my actual "rendering" in a shader (super simple at the moment, but it'll probably need to do some more advanced shenanigans later on).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

furinkan
Member #10,271
October 2008
avatar

That's super cool, dude!

And I think Allegro makes a great compliment to GL. ;D That's one of its strongest attributes: the ability to play nice with GL. You could feasibly use this for a 3D game, if you desired. Just replace the draw code with your own.

Gideon Weems
Member #3,925
October 2003
avatar

And here it is in my C# 'Canvas API':

I tried telling you guys.

BitCruncher
Member #11,279
August 2009

Allegro must not be dead if we're still getting new members; somebody still believes in it.

Chris Katko
Member #1,881
January 2002
avatar

SDL spies!

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

jmasterx
Member #11,410
October 2009

SDLers be so tots jelly of our mind control addon.

Ariesnl
Member #2,902
November 2002
avatar

I still prefer Allegro 5 above SDL.
why ? try making a counter or another "thing with changing text output" and hardware acceleration in SDL2 ..... ::)

Allegro is much easier to use and has more features

SDL is easier to install on linux though.

Perhaps one day we will find that the human factor is more complicated than space and time
(Jean luc Picard)

Thomas Fjellstrom
Member #476
June 2000
avatar

Ariesnl said:

SDL is easier to install on linux though.

Really? On my machines all it takes is an "aptitude install liballegro5-dev". As for installing from source, its like any source build, find the dependencies (that are listed in the readme and the wiki), install them, run the build tool (cmake in allegro's case), and install. How has SDL made it easier than that?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Gideon Weems
Member #3,925
October 2003
avatar

I think he meant Windows?

Ariesnl
Member #2,902
November 2002
avatar

I meant linux, but maybe it's an ubuntu thing.
Anyway Allegro 5 is not dead at all, at least not to me

Perhaps one day we will find that the human factor is more complicated than space and time
(Jean luc Picard)

Gideon Weems
Member #3,925
October 2003
avatar

You and thousands of others. ;)

What was Allegro's installation process like on Ubuntu? Did you install from binaries or build from source?

Chris Katko
Member #1,881
January 2002
avatar

Quote:

DOWNLOADS
37,698

Those were all me, trying to get it to compile! :o

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Ariesnl
Member #2,902
November 2002
avatar

I think I was trying to build from source.
I'm on a slow loan computer right now, but I'll try to build and install allegro 5 right now.

using this ...

https://emman31.wordpress.com/2013/01/21/ubuntu-12-04-installing-allegro-5-on-codeblocks/

Perhaps one day we will find that the human factor is more complicated than space and time
(Jean luc Picard)



Go to: