00:41:30 lament is .NET?! 00:41:35 Stay AWAYYYYY! 00:42:24 I'd rather .NET than perl ;) 00:42:31 wait 00:42:42 i am obliged to warn you that this whole channel is in fact .NET too. 00:42:43 I'd rather CLR than Perl 00:42:45 Are you sure about that? 00:43:05 Think carefully my friend. CLR is horribly bloated. Perl is not. 00:43:18 and Perl is horribly fugly. 00:43:27 :) 00:43:27 So is C. Point? 00:43:35 C != CLR 00:43:39 I know. 00:43:54 C isn't horribly bloated. It's horribly fugly. 00:43:57 There's plenty of languages other than C on the CLR, you know :) 00:44:08 Scheme beats 'em all, and then some. 00:44:24 actually, I'd have to say I prefer ruby, but I don't think there's a .rb ccTLD :( 00:44:25 Oh, C on the CLR? Ewww. 00:44:42 C-like languages, sorry ;) 00:44:44 It's so pointless, IMO. 00:45:37 Where's Scheme?! Bah! Where's Forth?! 00:45:50 (define CLR #f) 00:45:51 You know you like COBOL.NET 00:46:07 * Asztal wonders if you can use it with managed Direct X 00:46:14 I don't have Mono on this box. 00:46:22 Direct X. EWWW 00:46:28 Talk about commercial and nonportable. 00:47:12 I suppose that's true. But somehow I still prefer it to OpenGL ;) 00:47:13 there is F#, which is an Ocaml clone 00:47:30 activex is somewhat of a non-issue 00:47:37 it doesn't even run in my OS 00:47:44 i don't have to care about museum software 00:48:10 Yeah, I'd a heard of F#. 00:48:19 Asztal: Then your code stays on your platform. 00:48:25 :) 00:48:46 While Mac OS X and *Nix can share. 00:48:48 My games do :) 00:49:14 OCaML's syntax looks god-awful. 00:49:31 But I tend to (try to) write them so they're more or less API-independant 00:49:32 You would think S-expressions look bad, but OCaML is just *shudder* 00:49:49 Razor-X;; 00:50:21 I'm no game programmer. Although I've been feeling like playing around with OpenGL in Scheme some time for the heck of it. 01:26:29 -!- puzzlet_ has joined. 04:12:57 -!- GreaseMonkey has joined. 04:29:21 -!- GregorR has joined. 04:37:53 -!- GregorR has quit (Read error: 104 (Connection reset by peer)). 05:24:36 -!- ivan` has joined. 05:25:24 -!- Sgeo has quit (Remote closed the connection). 05:38:35 -!- calamari has quit ("Leaving"). 05:50:59 afk food 06:12:25 -!- GregorR-L has joined. 06:38:41 -!- GregorR-L has changed nick to FailureLobster. 06:39:00 -!- FailureLobster has changed nick to LobsterOfFailure. 06:47:08 -!- wooby has joined. 07:20:06 -!- LobsterOfFailure has changed nick to GregorR-L. 07:36:00 back 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:04:20 -!- GregorR-L has quit ("Leaving"). 08:15:27 -!- wooby has quit. 08:38:25 -!- oerjan has quit ("Good night"). 08:43:47 An ever shorter Forth quine: 08:43:53 source type 08:44:19 an even SHORTER Forth quine: 08:44:49 Yes? 08:44:55 (blank) 08:45:03 Good job my friend. 08:45:10 i can't send blank mesgs... gays 08:45:32 erm 08:45:47 damn, can't send blanks with a /raw command either :( 08:53:47 -!- GregorR has joined. 08:54:30 -!- EgoBot has joined. 08:57:05 anyways gonna get off so bye 08:57:50 -!- GreaseMonkey has quit. 09:50:15 -!- Razor-X has quit (Remote closed the connection). 09:51:46 -!- Razor-X has joined. 12:04:25 -!- ka_1900 has joined. 12:07:44 can any one plz tell me what is going on with this code !? 12:07:46 http://pfo.pastebin.com/831922 12:08:13 it is supposed to print a number ,.bt it prints another totally different number 12:11:13 hey pppl!! 12:11:16 anybody here 12:11:17 ? 12:29:02 that's undefined behaviour 12:29:39 the compiler is free to do whatever it likes 12:30:28 no there is a logic behind this ,. 12:31:09 there is 12:31:45 http://en.wikipedia.org/wiki/Sequence_point 12:32:37 you have to remember that function arguments can be evaluated in any order 15:22:07 -!- Sgeo has joined. 15:35:26 -!- jix has joined. 15:46:49 -!- CakeProphet has quit ("haaaaaaaaaa"). 16:04:47 Asztal 16:04:52 r us still there ? 16:05:09 this logic i sent u b4 is making me crazy 16:14:05 I think I understand the problem you're dealing with. 16:14:22 so ? do u got an answer ? 16:15:03 there's an easy way to fix it- don't do multiple pre- and post- increments on the same variable in a function call 16:15:37 just replace ++x with (x+1) and so on- then your code will function how you expect it to. 16:16:46 the problem is nt in the wrong answer ,. the problem i have to solve ,. is why it is doing so ,. btw this is the right code 16:16:50 http://pastebin.com/831918 16:20:14 it's like Asztal said- function arguments can be evaluated in any order, and several of your arguments change the value of X. 16:21:01 can we make it step by step together ??? 16:21:20 there 16:21:44 here 16:22:06 is nothing to go through step-by-step- you can effectively assume that the arguments you pass to your function are evaluated randomly, because it's undefined behavior 16:22:30 no it is not randomly 16:22:30 int x = 5 ; printf("%d%d%d%d%d", x++, ++x, x, ++x, x++) ; 16:22:48 the first printf should print 5 16:22:49 right ? 16:23:41 and the second and third printf should print 7 ? right ? 16:23:46 function arguments aren't necessarily evaluated from left to right, that's what I'm trying to get through to you. 16:23:58 and the last ++x and x++ should print 8 , 16:24:29 but the calculation is done left to right and printed right to left ,. why ?! 16:24:48 i mean the calculation gives 57788 16:24:56 but it prints 88775 16:24:57 why !? 16:25:50 but the calculation is done left to right and printed right to left ,. why ?! << it isn't done from left to right 16:26:21 it's obviously being done right to left in this case, and it'd probably do something else on a different compiler. 16:26:34 undefined. behavior. 16:27:11 no there is nothing called undefiend behaviour ,. our proffessor told us it has a logic and we have to find out why 16:27:31 ka_1900: huh? 16:27:32 than read the c standard 16:28:26 and professors can be wrong 16:29:14 whenever a function call is made with arguments that are expressions (x+5, x--, etc) they have to be evaluated before the actual function operates on these values (at an abstract level). The order in which arguments are evaluated is compiler-defined. 16:29:23 that's how it works, period. 16:30:09 the actual time at which the statements are evaluated in machinecode is determined by the compiler, which is *why* it's compiler-defined 16:31:00 -!- tgwizard has joined. 16:31:21 so the answer that this is undefined behavioud 16:31:24 r* 16:56:04 -!- ka_1900 has quit (Read error: 104 (Connection reset by peer)). 17:29:14 -!- tgwizard has quit (Read error: 110 (Connection timed out)). 18:22:27 -!- tgwizard has joined. 19:40:49 -!- xor has left (?). 19:41:07 -!- xor has joined. 20:06:19 i have a very cool idea for a new esolang! 20:06:50 nah doesn't work 20:07:01 i was lying i just wanted to test a script and needed people to talk 20:07:27 heh 20:07:42 sorry 20:07:46 hmm... 20:08:45 hmm 20:21:05 -!- CakeProphet has joined. 20:23:26 -!- CakeProphet has quit (Client Quit). 20:51:15 You can't assume that arguments are evaluated randomly, because it's undefined behaviour; you must assume that _anything_ can happen, including the computer exploding. 20:51:25 It doesn't necessary evaluate any arguments at all. 20:52:06 (To answer the conversation that was here over four hours ago.) 20:52:59 (It's undefined behaviour since it modifies x multiple times between sequence points.) 20:56:36 Actual evaluation order is implementation-defined, but that's another issue. printf("%d%d\n", printf("foo\n"), printf("bar\n")); does not have any undefined behaviour, but what it prints is implementation-defined. It must be "foo\nbar\n44\n" or "bar\nfoo\n44\n", though. (Barring any IO errors or such.) 21:02:28 -!- CakeProphet has joined. 21:25:49 fizzie: yeah, true. I was just trying to explain things simply 21:27:27 No mercy! 21:27:54 whatever 21:38:45 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht"). 21:43:13 -!- Sgeo has quit (Remote closed the connection). 23:04:42 -!- CakeProphet has quit ("haaaaaaaaaa"). 23:54:35 -!- CakeProphet has joined.