|
If it's true, you don't believ in the afterlife. |
Trent Gamblin
Member #261
April 2000
|
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
|
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. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Edgar Reynaldo
Major Reynaldo
May 2007
|
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! You know you want to! Re: grep I'm running the gnuwin32 versions of the tools btw. Hate to bother you, but this : 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 My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
bamccaig
Member #7,536
July 2006
|
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.
-- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Dennis
Member #1,090
July 2003
|
Sooooo... what's up? --- 0xDB | @dennisbusch_de --- |
LennyLen
Member #5,313
December 2004
|
Dennis said: Sooooo... what's up? Anything that's not down.
|
Erin Maus
Member #7,537
July 2006
|
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"} 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"} Preeeetty nifty. --- |
Thomas Fjellstrom
Member #476
June 2000
|
Aaron Bolyard said: I wrote a resolution independent curve renderer and it requires a few more modern features than Allegro exposes... Like what exactly? -- |
Erin Maus
Member #7,537
July 2006
|
Thomas Fjellstrom said: 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"} --- |
Chris Katko
Member #1,881
January 2002
|
Dude, you're my hero. -----sig: |
bamccaig
Member #7,536
July 2006
|
^ 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"} -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Onewing
Member #6,152
August 2005
|
Aaron Bolyard said: 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. ------------ |
Thomas Fjellstrom
Member #476
June 2000
|
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). -- |
furinkan
Member #10,271
October 2008
|
That's super cool, dude! And I think Allegro makes a great compliment to GL. 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
|
Aaron Bolyard said: And here it is in my C# 'Canvas API': |
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
|
SDL spies! -----sig: |
jmasterx
Member #11,410
October 2009
|
SDLers be so tots jelly of our mind control addon. Agui GUI API -> https://github.com/jmasterx/Agui |
Ariesnl
Member #2,902
November 2002
|
I still prefer Allegro 5 above SDL. 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
|
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? -- |
Gideon Weems
Member #3,925
October 2003
|
Ariesnl
Member #2,902
November 2002
|
I meant linux, but maybe it's an ubuntu thing. 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
|
Chris Katko
Member #1,881
January 2002
|
Quote:
DOWNLOADS Those were all me, trying to get it to compile! -----sig: |
Ariesnl
Member #2,902
November 2002
|
I think I was trying to build from source. 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) |
|
|