This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1891
Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 10:59:27 am »
Eh, char* and char*& are two different things. Array != &Array... &Array will, should the array for some reason be given a register despite its use, dump the pointer into the memory and give you a reference to it. Assuming you meant Array == Array&, that isn't true, either. If you never state Array = something; in the code taking Array&, it will modify the array without requiring return. Taking Array as a parameter would simply copy the pointer, and only the local copy in the new scope would be changed.
Now, in the context of his code, GCC will probably be nice and make it such that (int Array) is the same as (int &Array). So fine.
...But they're still different.
Now, in the context of his code, GCC will probably be nice and make it such that (int Array) is the same as (int &Array). So fine.
...But they're still different.
1892
Announcements / Re: Around the Clock
« on: June 15, 2010, 01:01:52 am »
There are parsers for YAML taking thousands of lines and requiring several awkward symbols to be added to my file, which I think is beautiful as it is. The parser for it barely takes 200 lines. It's just not that complicated. YAML introduces what seems to be hundreds of features we don't use, requires symbols to make explicit what should be implied, and lacks (for sake of versatility on a scale not required here) a feature the current format uses. It would be easier for me (perhaps even at this point) to include some huge YAML nonsense, but I don't think I'll be doing so. If Ism, however, indicates in any way an intention to share this file with me, I will, via a simple regexp, make the file into YAML, and either revise my parser to use YAML's | and >, or perhaps even break habit and include some fucking huge thing and piss with its API to get the info I need. The question is whether I want the format to be YAML or to be YAML compliant, assuming I want it to be related to YAML at all (which I slightly do, since Ism reports that the format being YAML-ready would slightly improve her odds of working with it).
Ism:
That's a bug, yes. Should work like GM. And yes, Shift wouldn't change anything; I get the keycode raw and convert it myself via large array. This array is -not- cross API, meaning it may work find on Winblows even though I screwed up on X. I'd prefer not to add checking for both at first glance due to the unfolding of code that would have to transpire (either unfolding an array by segment, keeping a second array, or just adding a special check), but I will look into doing so all the same. If I did, I would probably mandate that a correction be implemented just above the API level (as soon as I have a key code), so no additional checking is done each keyboard_check. Hoping this isn't the work of XLookupKeyCode, or whatever that function was.
Ism:
That's a bug, yes. Should work like GM. And yes, Shift wouldn't change anything; I get the keycode raw and convert it myself via large array. This array is -not- cross API, meaning it may work find on Winblows even though I screwed up on X. I'd prefer not to add checking for both at first glance due to the unfolding of code that would have to transpire (either unfolding an array by segment, keeping a second array, or just adding a special check), but I will look into doing so all the same. If I did, I would probably mandate that a correction be implemented just above the API level (as soon as I have a key code), so no additional checking is done each keyboard_check. Hoping this isn't the work of XLookupKeyCode, or whatever that function was.
1893
Announcements / Re: Updates, Updates, Updates on the way.
« on: June 15, 2010, 12:44:09 am »Code: (C++) [Select]
#include <stdio.h> //puts
int main(int,char**) {
return puts("Hello, world!") , 0; /* this is just lazy */
} // tits
Code: (C++) [Select]
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#pragma arse
#include <stdio.h>
#include <stdio.h> //puts
int main(int,char**) {
return puts("Hello, world!") , 0; /* this is just lazy */
} // tits
Code: (cpp) [Select]
int a[b] please don't be bold [/b]; b = 'weee';
1894
Announcements / Re: Around the Clock
« on: June 10, 2010, 01:08:13 pm »
-Sigh-
I like the format how it is. It's humanly readable now without the %YAML, ---, -, \nGroup ID:, and ....
In fact, it's close enough to YAML that I'm comfortable calling it that anyway. Or at least YAML-like. I'll outline all six differences in the docs regarding the events file, if you like.
YAML highlighters are grotesque at best; I'd get better highlighting if I named the file *.sh. I don't see much benefit to trying to comply...
I like the format how it is. It's humanly readable now without the %YAML, ---, -, \nGroup ID:, and ....
In fact, it's close enough to YAML that I'm comfortable calling it that anyway. Or at least YAML-like. I'll outline all six differences in the docs regarding the events file, if you like.
YAML highlighters are grotesque at best; I'd get better highlighting if I named the file *.sh. I don't see much benefit to trying to comply...
1895
Announcements / Re: Around the Clock
« on: June 10, 2010, 01:55:53 am »
Indeed. Kinda laughed.
Anyway. This new instance system is beautiful. What was 55 lines is now 17. This unified iterator thing didn't look half as powerful on paper. Damn, what an idea.
Anyway. This new instance system is beautiful. What was 55 lines is now 17. This unified iterator thing didn't look half as powerful on paper. Damn, what an idea.
1897
Announcements / Around the Clock
« on: June 09, 2010, 09:00:53 pm »
Hardly. I've worked on Thank You cards to six million people. My cousin's graduation party is Sunday, which I will apparently be attending. Today I took a trip north with my dad, solely to visit my grandparents. Made the mistake of committing my code so I could work on ENIGMA there from my laptop. Didn't have much time to do so, ultimately. What's more, I came back to a certain someone informing me that the code I committed mid-sentence doesn't compile. <___<"
No, the instance system is not done. But I do have a surprise for you all.
I've seen questions going around of how GM handles events. Specifically, questions regarding the order in which they are executed. I myself used to wonder what exactly went on to implement hspeed and vspeed that ruined my first slope-using platformer. Well, that won't be a problem in ENIGMA.
I have implemented a file for R4 that contains a list of all events, the code executed in them, and some other details and trivia. I know a few are thinking right now, "great, another document for Josh to not maintain." Well, HAH. This one will always be current. Why? Because it's the file ENIGMA actually uses to determine what events were passed.
This is a beautiful thing for a number of reasons, one of the most important being that anyone can correct an event or add an event that a new version of GM implements. This is a snippet of the file, for demonstration purposes:
That code will serve to bring an end to the hard-coded, undocumented GM method of event management.
Anyway, I'm back to work.
No, the instance system is not done. But I do have a surprise for you all.
I've seen questions going around of how GM handles events. Specifically, questions regarding the order in which they are executed. I myself used to wonder what exactly went on to implement hspeed and vspeed that ruined my first slope-using platformer. Well, that won't be a problem in ENIGMA.
I have implemented a file for R4 that contains a list of all events, the code executed in them, and some other details and trivia. I know a few are thinking right now, "great, another document for Josh to not maintain." Well, HAH. This one will always be current. Why? Because it's the file ENIGMA actually uses to determine what events were passed.
This is a beautiful thing for a number of reasons, one of the most important being that anyone can correct an event or add an event that a new version of GM implements. This is a snippet of the file, for demonstration purposes:
Code: (Events) [Select]
beginstep: 3
Group: Step
Name: Begin Step
Mode: Special
Case: 1
alarm: 2
Group: Alarm
Name: Alarm %1
Mode: Stacked
Sub Check: { if ((alarm[%1] == -1) or (alarm[%1]--)) return 0; }
# Keyboard events. These are simple enough.
keyboard: 5
Group: Keyboard
Name: Keyboard <%1>
Type: Key
Mode: Stacked
Super Check: keyboard_check(%1)
#...
step: 3
Name: Step
Mode: Special
Case: 0
Constant: {
x += hspeed, y += vspeed;
speed -= friction;
vspeed += sin(gravity_direction * pi/180),
hspeed += cos(gravity_direction * pi/180);
}
#...
collision: 4
Group: Collision
Name: %1
Type: Object
Mode: Stacked
Super Check: instance_number(%1)
Sub Check: place_meeting(x,y,%1)
That code will serve to bring an end to the hard-coded, undocumented GM method of event management.
Anyway, I'm back to work.
1898
Off-Topic / Re: logy(x) ≢ log(x)÷log(y)
« on: June 09, 2010, 12:28:17 pm »
Eh, Wolfram reports log -1 of -1 is 1.
What told you it wasn't?
Oh, I see. This is the same problem you face with arcsin(), though. The method holds; there are just more answers than you are given by the function. It's not like this only happens with those, either; you see the same problem when you have x**2 = y. Because the sqrt() function only returns positive. As do all the other pow(x,1/n) functions, even though there are always n answers.
What told you it wasn't?
Oh, I see. This is the same problem you face with arcsin(), though. The method holds; there are just more answers than you are given by the function. It's not like this only happens with those, either; you see the same problem when you have x**2 = y. Because the sqrt() function only returns positive. As do all the other pow(x,1/n) functions, even though there are always n answers.
1899
Announcements / Re: Updates, Updates, Updates on the way.
« on: June 08, 2010, 09:19:23 am »Code: (C++) [Select]
#pragma syntax_highlighting
#include <stdio.h> // puts
//dongs
int main(int,char**) {
return puts("Hello, world!"), 0;
}
Code: (C++) [Select]
#include <stdio.h> // puts
//dongs
int main(int,char**) {
return puts("Hello, world!"), 0;
}
Code: (C++) [Select]
#pragma arse // arse
#include <stdio.h> // puts
//dongs
int main(int,char**) {
return puts("Hello, world!"), 0;
}
Code: (C++) [Select]
#include <conio.h> // no reason at all
#include <stdio.h> // puts
//dongs
int main(int,char**) {
return puts("Hello, world!"), 0;
}
1901
Announcements / Re: Tentative Todo
« on: June 07, 2010, 02:40:33 pm »
I love speculation. No, I meant truly amazing on the scale of a flexible instance system. Something to fix Game Maker's poorly documented event behavior.
1902
Announcements / Re: Tentative Todo
« on: June 07, 2010, 11:57:30 am »
Sometimes, "real life" causes me grief in the most unexpected of times. I will be making a post about something truly amazing here in a bit. Wait for it.
1903
"Also, that same bloat can get in the way of adding new features to C++."
Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.
"My claim is that C++ is used for big applications because when those big applications were started there was nothing better or because they were started as C."
That almost definitely applies to Excel, because otherwise, Microsoft would have taken the opportunity to advertise that srs biznez can really be accomplished in C#. And that IS part of their intention. Singularity's one screen shot was so transparently propaganda-laden it made me sick.
Loading ************C#*********** kernel of Mar 25 2008
Please direct your attention to the C# in the last message
Did you notice the kernel is C#? Look, it even loads amicoolyet
Singularity>
Of course, C# is my least favorite example of such languages, and there are far better ways of accomplishing type safety that don't end up removing mad pointer tricks as a method of accomplishing something.
As for this little Brainfuck argument, Luis is going to argue it in the wrong direction. Brainfuck could be a really nice language with the right tools. For example, you could give it a DLL containing wrappers to the standard C library. " would be LoadLibrary, ' would be GetProcAddress, » would push an argument, « would call the function with the pushed arguments and store the return value.
Because the code would be so horribly redundant (having to load a new proc address every time you want to call a function), an optimizer could boil the code down to nothing. It might even be faster than C++. :O
...Until you need to pass arguments that aren't strings.
Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.
"My claim is that C++ is used for big applications because when those big applications were started there was nothing better or because they were started as C."
That almost definitely applies to Excel, because otherwise, Microsoft would have taken the opportunity to advertise that srs biznez can really be accomplished in C#. And that IS part of their intention. Singularity's one screen shot was so transparently propaganda-laden it made me sick.
Loading ************C#*********** kernel of Mar 25 2008
Please direct your attention to the C# in the last message
Did you notice the kernel is C#? Look, it even loads amicoolyet
Singularity>
Of course, C# is my least favorite example of such languages, and there are far better ways of accomplishing type safety that don't end up removing mad pointer tricks as a method of accomplishing something.
As for this little Brainfuck argument, Luis is going to argue it in the wrong direction. Brainfuck could be a really nice language with the right tools. For example, you could give it a DLL containing wrappers to the standard C library. " would be LoadLibrary, ' would be GetProcAddress, » would push an argument, « would call the function with the pushed arguments and store the return value.
Because the code would be so horribly redundant (having to load a new proc address every time you want to call a function), an optimizer could boil the code down to nothing. It might even be faster than C++. :O
...Until you need to pass arguments that aren't strings.
1904
"Will you at least admit C++ has lots of legacy junk nobody needs anymore? Because that's what this discussion was about - the claim that C++ was bloated."
Do you read what I write?
"As a language, C++ is fairly bloated. That bloat doesn't really get in your way unless you are trying to parse it. The output is typically far from bloated, though there are slight amounts of overhead if you utilize more than C would give you alone."
"From the point of view of a GC, you don't know if some word in memory is an integer or a pointer cast to an integer. If casting between pointers and integers were impossible, you could place GC roots at compile time; as it is you can't."
From the point of view of Escherichia coli, your garbage collector is indistinguishable from a string of bits in memory.
Now, when you're done raging over the bluntness of that statement, consider its implications. ISO C++ forbids void* arithmetic, it forbids implicit casts between pointers of non-inherited types, and it forbids implicit cast from pointer to integer. The question isn't of whether a separate garbage collector can be slapped on to the output of any old C++ program; that kind of thinking leads to output bloat instead of C85 language bloat that can be ignored.
Also, you can't pretend that a garbage collector alleviates all allocation problems. Specialized ones, knowing the size of everything up front, can be used to alleviate allocation headaches and just increment a pointer. There's nothing a garbage collector can accomplish that manual can't if given equal thought. Garbage collection has come a long way, and it's typically not an O(N) clusterfuck anymore. That doesn't mean that they are programmed with magic that fixes all our resource problems.
"Haskell has Darcs and Yi. It has GHC and Cabal. It has Xmonad and seL4 and House. It has compilers for Perl 6, Lisp, bla bla bla look at Hackage. Do some research before making things up."
I don't see any of those as being exceptionally large... Looking at Xmonad, it's built off of X, which only serves to help my point. The rest are little things like RapidSVN that I kind of take for granted because really, they're just nice wrappers to what I'd otherwise be doing in a terminal.
Also, I can be missing a huge, huge project made in Haskell without "making things up." I'm reporting my findings. I indicated what would "probably [be] notice[d]," based off of my findings. Quit accusing me of making things up simply because you disagree with my point.
"Eventually, something will be written in C(the kernel, perhaps?). Heck, there are things that should really be written in C(or at least have a public C ABI), such as system libraries. However, this does not apply to applications."
I hinted earlier at Microsoft Singularity. I'm glad you agree that there are some things that just had ought to be C. Much of Singularity is C, but the rest is C#. There are benefits to having garbage collection in some of the system resources that applications will be accessing. I think, however, you'll agree that Singularity oversteps the boundaries. If not, maybe you'll agree that integrated circuitry designed to implement a garbage collector is. (Or, hell, maybe you'll think it's a great idea, who the hell knows). I was reading about ATMs that have their own integrated garbage collector. I wanted to puke, personally.
"The "go fast or go high level" is another false dichotomy fallacy."
I wasn't citing that as a mathematical truth. There are a lot of brilliantly efficient high level things.
Do you read what I write?
"As a language, C++ is fairly bloated. That bloat doesn't really get in your way unless you are trying to parse it. The output is typically far from bloated, though there are slight amounts of overhead if you utilize more than C would give you alone."
"From the point of view of a GC, you don't know if some word in memory is an integer or a pointer cast to an integer. If casting between pointers and integers were impossible, you could place GC roots at compile time; as it is you can't."
From the point of view of Escherichia coli, your garbage collector is indistinguishable from a string of bits in memory.
Now, when you're done raging over the bluntness of that statement, consider its implications. ISO C++ forbids void* arithmetic, it forbids implicit casts between pointers of non-inherited types, and it forbids implicit cast from pointer to integer. The question isn't of whether a separate garbage collector can be slapped on to the output of any old C++ program; that kind of thinking leads to output bloat instead of C85 language bloat that can be ignored.
Also, you can't pretend that a garbage collector alleviates all allocation problems. Specialized ones, knowing the size of everything up front, can be used to alleviate allocation headaches and just increment a pointer. There's nothing a garbage collector can accomplish that manual can't if given equal thought. Garbage collection has come a long way, and it's typically not an O(N) clusterfuck anymore. That doesn't mean that they are programmed with magic that fixes all our resource problems.
"Haskell has Darcs and Yi. It has GHC and Cabal. It has Xmonad and seL4 and House. It has compilers for Perl 6, Lisp, bla bla bla look at Hackage. Do some research before making things up."
I don't see any of those as being exceptionally large... Looking at Xmonad, it's built off of X, which only serves to help my point. The rest are little things like RapidSVN that I kind of take for granted because really, they're just nice wrappers to what I'd otherwise be doing in a terminal.
Also, I can be missing a huge, huge project made in Haskell without "making things up." I'm reporting my findings. I indicated what would "probably [be] notice[d]," based off of my findings. Quit accusing me of making things up simply because you disagree with my point.
"Eventually, something will be written in C(the kernel, perhaps?). Heck, there are things that should really be written in C(or at least have a public C ABI), such as system libraries. However, this does not apply to applications."
I hinted earlier at Microsoft Singularity. I'm glad you agree that there are some things that just had ought to be C. Much of Singularity is C, but the rest is C#. There are benefits to having garbage collection in some of the system resources that applications will be accessing. I think, however, you'll agree that Singularity oversteps the boundaries. If not, maybe you'll agree that integrated circuitry designed to implement a garbage collector is. (Or, hell, maybe you'll think it's a great idea, who the hell knows). I was reading about ATMs that have their own integrated garbage collector. I wanted to puke, personally.
"The "go fast or go high level" is another false dichotomy fallacy."
I wasn't citing that as a mathematical truth. There are a lot of brilliantly efficient high level things.
1905
"Tell me, how many variables are pointing to 0x043030FE in your program"
"What I think Rusky was trying to convey is that C++ introduces no system of reference tracking."
"They dared to automatically dispose of strings in C++? BUT THAT'S SO INEFFICIENT!!!"
How so? The idea is a garbage collector that can linearly assume you are done with it because the entire scope's life is ending. My argument was never that all convenient things are inefficient; it's if you start periodically iterating through everything to make sure nothing's just kind of waiting there that shit becomes inefficient.
"Therefore, when it comes to wiping out the memory management ickiness, other languages are better."
...Okay. For the most part, this has worked for a few large projects. You'll probably notice that the more the language does for you, the less large projects are successfully written in it. Openoffice is a shining example, in my opinion. Only a few of its aspects have been reported as being slow (the one I am thinking of is Calc, being 12x slower than Excel at something or another). I look at Haskell, and I see things like Geordi. Marvelous little toy; not ultimately very big.
Ultimately, it's a nice thing to have a low-written runtime at your disposal in a high level language; it gets you the speed of the low with the simplicity of the high. The more things the low level system does for you, the better off you'll be. Like GM. Sprites and collisions are acceptable because something coded in a real (not GML) language handles them. Java has a few aspects of it that are "faster than C"... usually large libraries such as compression that are written in a lower level language.
If you want anything sizable that runs fast, you'll need something lower level at some point, even on our constantly improving hardware. Haven't heard anything on Singularity. But I know that the more Microsoft develops, the slower their output becomes. It is nice to swim in the high level end and have simpler-to-read code with the ugly parts handled. Microsoft's been trying that for a long time. It isn't always an option. C++ is always an option.
Maybe some day, Microsoft will fix that. C++ being an option, I mean. In the meantime, it's a true dilemma between whether you want your time to be consumed in development by your team or in execution by all users. And since programmers get paid by the hour, not by the output...
Either way, the majority of these posts is fluff. Every language has its purposes; I wouldn't want Geordi written in anything other than Haskell, because Haskell got the job done far faster and probably far more cleanly than C++ would have. It simply doesn't need that speed. I would kind of like OpenOffice to not be Java, because Java acts up on this machine sometimes, but whatever; it's free. I wouldn't have ENIGMA coded in any other way.
"What I think Rusky was trying to convey is that C++ introduces no system of reference tracking."
"They dared to automatically dispose of strings in C++? BUT THAT'S SO INEFFICIENT!!!"
How so? The idea is a garbage collector that can linearly assume you are done with it because the entire scope's life is ending. My argument was never that all convenient things are inefficient; it's if you start periodically iterating through everything to make sure nothing's just kind of waiting there that shit becomes inefficient.
"Therefore, when it comes to wiping out the memory management ickiness, other languages are better."
...Okay. For the most part, this has worked for a few large projects. You'll probably notice that the more the language does for you, the less large projects are successfully written in it. Openoffice is a shining example, in my opinion. Only a few of its aspects have been reported as being slow (the one I am thinking of is Calc, being 12x slower than Excel at something or another). I look at Haskell, and I see things like Geordi. Marvelous little toy; not ultimately very big.
Ultimately, it's a nice thing to have a low-written runtime at your disposal in a high level language; it gets you the speed of the low with the simplicity of the high. The more things the low level system does for you, the better off you'll be. Like GM. Sprites and collisions are acceptable because something coded in a real (not GML) language handles them. Java has a few aspects of it that are "faster than C"... usually large libraries such as compression that are written in a lower level language.
If you want anything sizable that runs fast, you'll need something lower level at some point, even on our constantly improving hardware. Haven't heard anything on Singularity. But I know that the more Microsoft develops, the slower their output becomes. It is nice to swim in the high level end and have simpler-to-read code with the ugly parts handled. Microsoft's been trying that for a long time. It isn't always an option. C++ is always an option.
Maybe some day, Microsoft will fix that. C++ being an option, I mean. In the meantime, it's a true dilemma between whether you want your time to be consumed in development by your team or in execution by all users. And since programmers get paid by the hour, not by the output...
Either way, the majority of these posts is fluff. Every language has its purposes; I wouldn't want Geordi written in anything other than Haskell, because Haskell got the job done far faster and probably far more cleanly than C++ would have. It simply doesn't need that speed. I would kind of like OpenOffice to not be Java, because Java acts up on this machine sometimes, but whatever; it's free. I wouldn't have ENIGMA coded in any other way.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »