Show Posts

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.


Messages - Josh @ Dreamland

1891
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.

1892
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;
}

1893
Announcements / Re: Tentative Todo
« on: June 07, 2010, 11:55:35 PM »
<____<"

1894
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.

1895
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.

1896
Off-Topic / Re: c++0x
« on: June 05, 2010, 09:21:04 AM »
"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.

1897
Off-Topic / Re: c++0x
« on: June 04, 2010, 09:51:22 PM »
"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. :troll:
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.

1898
Off-Topic / Re: c++0x
« on: June 04, 2010, 03:04:59 PM »
"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.

1899
Off-Topic / Re: c++0x
« on: June 04, 2010, 12:58:43 PM »
"Is this a fallacy? Not any more than your arguments, so you can't complain."
That final clause itself was a fallacy. You're both spouting little but fallacies.

"know what is a pointer and what is not, and that is impossible in C++."
I'm going to assume you meant something other than how that reads; otherwise, that's the biggest lout of bullshit I've ever heard.

Anyway, C++ is not meant to be a garbage collected language. It implements something wonderful over C in the direction of memory management, being constructors and destructors. Google V8 is one to really whore that system. In an ExecuteString wrapper, I can say so little as
Code: (C) [Select]
{
  v8::HandleScope handle_scope; // Constructor allocates and integrates a new scope
  ExecuteString(String::New(line), "(shell)", true, true); //Operates in the newly constructed scope
  return 0;
} // Destructor automatically disposes the new scope

People get used to strings; I myself have become spoiled by them, and feel so every time I use them. C gave no way of returning new strings, save allocating them yourself. With C++, std::string is a great example of how the annoying bits are handled for you. String keeps its own reference count at the beginning of the char* in memory. When you return a string in C++, the constructor of the new string increments that count, the destructor of the old string then decrements it, and a string is returned with no manual allocation.

I had a leak once, and I used ctors and dtors to keep my own count, and to help me isolate where they were allocated that they weren't being freed. It was greatly convenient; had I wanted, I could have turned it into a garbage collector on my own. Thing is, I prefer the program to be geared correctly to take care of such itself.

Is it possible to get C++ to wipe all the memory management ickiness off your ass for you? No. What I think Rusky was trying to convey is that C++ introduces no system of reference tracking. Personally, all considered, I prefer it that way.

1900
Announcements / Re: Tentative Todo
« on: June 03, 2010, 09:07:28 PM »
He never claimed that he was working on it the entire time nor that he was making good progress; just that at some point some progress was made. If he does it, it will be good, and I will use it. If he does not, I will try to run with his ideas that he forwarded to me; they were pretty good ones.

Aside from retep, who doesn't have experience in pixel perfect collisions, no one has volunteered to work on the system. I'm in no position to just start working on it; if he is going to finish it he'll have to do so before I finish that list above and do it myself.

1901
Off-Topic / Re: c++0x
« on: June 03, 2010, 09:04:16 PM »
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.

1902
Announcements / Re: Tentative Todo
« on: June 03, 2010, 07:05:04 PM »
luis: We're going for terrific efficiency.
freezway: That's part of the new instance system, yes.
polygone: Luda doesn't seem to want to continue. I'll ask him about it again sooner or later.

1903
Announcements / Re: Tentative Todo
« on: June 03, 2010, 02:40:51 PM »
Painfully aware. :P
Serp recommends I rename it draw_serplipse().

1904
Announcements / Re: Tentative Todo
« on: June 03, 2010, 01:58:53 PM »
it draws -something- of an ellipse. It's actually two parabolas stuck together, because serp doesn't believe in sqrt or trig.

1905
Announcements / Tentative Todo
« on: June 03, 2010, 12:14:07 PM »
This is what's going on and what will be going on before release.

Current Todo:
  • Implement instance system (Currently working on)
  • Implement new var (has already been coded)
  • Resolve, once and for all, string() vs string, using a special property of macros. (#define string(x) toString(x))
  • Make some changes to the parsers to accommodate some of these and more:
    • Implement macros in the syntax check
    • Implement C++ operators scope resolve :: and template parameter pass <...>
    • Implement GML operators not equal <> , access . , and dynamic array subscript [...] .
    • Run a check on subscript passes to global variables
    • Finish implementing special treatment for variables declared as const.

What's just been done recently includes a fix on global declarations as well as testing of all drawing functions. Only draw_ellipse doesn't work, and I will fix that "soon."