| 00:55:32 | fowl | I was getting an error for missing gluErrorUnicodeStringEXT, so I googled it and it seems its windows only, putting when defined(windows): before the proc fixed it (for me, not on windows) |
| 00:57:11 | * | Trixar_za is now known as Trix[a]r_za |
| 04:40:27 | * | XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.) |
| 13:20:14 | Araq | zahary: why does nimDestroyRange need to be exported? |
| 13:23:06 | Tasser | dom96, shouldn't parseFoo take a tainted string as well |
| 13:23:37 | dom96 | I don't think so. |
| 13:23:55 | Tasser | dom96, why? isn't parsing the step that converts unstructured to structured data? |
| 13:24:12 | dom96 | TaintedString is a string which comes from the outside world, i.e. it's unsafe to parse. |
| 13:24:41 | dom96 | Like lets say you get some information from the outside world, and you want to make a sql query out of that. |
| 13:24:43 | Araq | in fact I thought the same as Tasser :-) |
| 13:24:53 | Araq | parsing is input validation |
| 13:25:02 | Araq | well the way parseutils does it |
| 13:26:01 | dom96 | I don't think it's suited for parseutils though. If you want a proc which validates input it should take in a TaintedString and convert it into a string then check whether it is valid, or make it valid using parseutils. |
| 13:26:01 | Araq | however the parsing functions should also be usable for untainted strings and then you have a problem |
| 13:26:23 | Tasser | Araq, converter for string -> TainedString ? |
| 13:26:34 | Araq | proc parseInt(s: TaintedString|string, ... |
| 13:26:35 | Tasser | or simple type subserset? |
| 13:26:43 | Tasser | ehh superset |
| 13:26:49 | Tasser | also known as inheritance |
| 13:26:51 | Araq | would be the proper signature but nimrod doesn't support that |
| 13:27:13 | Tasser | why can't any string be used as TainedString? |
| 13:27:42 | Araq | because it's implemented as a 'distinct' string and distinct does not imply any subtype relation |
| 13:28:04 | Araq | the converter may work |
| 13:28:22 | Araq | but it causes problems quickly |
| 13:28:26 | Tasser | why so? |
| 13:28:37 | Araq | "my string" & "tainted string" |
| 13:28:48 | Tasser | gives a tained string |
| 13:28:53 | Araq | nope :P |
| 13:29:05 | Tasser | why not? |
| 13:29:06 | Araq | according to you, it's a nontainted string |
| 13:29:24 | Araq | because the tainted string is converted to ... oh wait |
| 13:29:41 | Araq | lol |
| 13:29:53 | Araq | seems you're correct :-) |
| 13:30:23 | Tasser | I still wonder why the taint part is done with the type system |
| 13:30:37 | Araq | how would you do it? |
| 13:30:40 | Tasser | but I suppose a string is the only data that can be tained? |
| 13:30:48 | Tasser | orthogonally |
| 13:30:53 | Tasser | but that kind of sucks as well |
| 13:31:08 | Araq | it's only necessary for strings in practice IMO |
| 13:31:25 | Tasser | until you parse them |
| 13:31:49 | Tasser | yeah, it's fine |
| 13:31:57 | Tasser | just add a converter from string to tainted one |
| 13:32:19 | Tasser | converter is basically an inheritance hack ;-) |
| 13:32:39 | Araq | yes but more flexible :P |
| 13:33:00 | Araq | but it's a nonissue really |
| 13:33:07 | Araq | the current way is not hard to deal with |
| 13:33:19 | Araq | and btw taint mode is off per default anyway |
| 13:33:34 | Araq | it's only the compiler's error message is somewhat misleading |
| 13:33:42 | Tasser | but do you agree with "parsing tainted -> clean"? |
| 13:33:51 | Araq | not really |
| 13:34:07 | Araq | I agree it's the way to do it for parseutils |
| 13:34:25 | Tasser | yeah, that's what I kind of meant... the other part you're right |
| 13:34:50 | Tasser | what's those n_n prefixes in the bootstrap btw? |
| 13:35:09 | Araq | os_cpu number |
| 13:35:21 | Tasser | oh |
| 13:35:25 | Araq | but since lots of files are shared/platform independent |
| 13:35:34 | Araq | I chose to use meaningless numbers |
| 13:36:00 | Araq | otherwise I'd get bug reports like "it uses x86_mac/times.c on linux!" |
| 13:36:12 | Tasser | hehe |
| 13:37:10 | Tasser | so an issue filed then? |
| 13:37:42 | Araq | dunno |
| 13:37:52 | Araq | lots of more important things left to do |
| 13:37:54 | Araq | but ok |
| 13:38:02 | Araq | I'll make it a feature request |
| 13:39:18 | Araq | converter sucks currently as the compiler does no trivial inling for them for now |
| 13:39:38 | Araq | and without inlining you'd get a string copy operation implicitely |
| 13:39:50 | Araq | which sucks |
| 13:40:14 | Tasser | indeed |
| 13:42:02 | Araq | so ... every tainted string is a string? |
| 13:42:16 | Araq | no |
| 13:42:22 | Araq | every string is a tainted string, right? |
| 13:42:43 | Tasser | indeed |
| 13:43:13 | Araq | but we also have: |
| 13:43:28 | Araq | proc add(x: var TaintedString, y: string) |
| 13:44:03 | Tasser | the compiled should choose add(x,y: string) in that case |
| 13:44:20 | Tasser | so you choose to handle TainedString and strings differently - so what? |
| 13:45:18 | Araq | just checking some ops |
| 13:45:41 | Araq | is s[i] valid for tainted strings? I suppose it is ... |
| 13:46:28 | Araq | in fact, 'distinct' is still missing essential features like "subscript op is allowed" |
| 13:46:42 | * | Trix[a]r_za is now known as Trixar_za |
| 13:47:00 | Tasser | what's "distinct"? |
| 13:47:20 | Araq | the type feature that enables tainted strings |
| 13:47:36 | Araq | type TaintedString = distinct string |
| 13:47:43 | Araq | is the declaration if taint mode is on |
| 13:47:49 | Araq | otherwise it's: |
| 13:47:57 | Araq | type TaintedString = string # simply an alias |
| 13:48:21 | Araq | it's planned to support: |
| 13:48:39 | Araq | type x = distinct y with `==`, `[]`, ... |
| 13:49:41 | Trixar_za | Hmmmm |
| 13:49:45 | Tasser | why not copy? |
| 13:49:56 | Araq | copy what? |
| 13:50:08 | Tasser | seems like a type copy to me |
| 13:50:08 | Trixar_za | How hard is it to write a rst parser? |
| 13:50:23 | Araq | Trixar_za: use nimrod's docutils package |
| 13:50:37 | Araq | an rst parser takes months to create |
| 13:50:40 | Trixar_za | No, I was thinking of using Wiki software like LionWiki |
| 13:50:50 | Trixar_za | Then just writing in a simple rst parser |
| 13:51:04 | Trixar_za | then I can just dump the text files in the data directory and have instant wiki pages |
| 13:51:43 | Araq | use nimrod's docutils and jester and implement a nimrod based wiki software instead |
| 13:51:58 | Araq | there is no such thing as a "simple rst parser" |
| 13:52:15 | Araq | it's one of the hardest to parse languages IMO |
| 13:52:28 | Trixar_za | Then why did you use it? :P |
| 13:52:34 | Araq | because I love it |
| 13:52:51 | Trixar_za | I see you like difficult women then |
| 13:53:39 | Araq | unfortunately yes ;-) |
| 13:53:41 | Trixar_za | The kind that has red hair, good in bed and insane that they come after you with a scissor to cut off your balls for cheating (true story) |
| 13:55:22 | Araq | sounds good :P |
| 13:57:14 | Trixar_za | True, red heads are always the most fun |
| 13:57:22 | Trixar_za | Especially if you have good reflexes |
| 13:59:35 | Trixar_za | Also, I'm quite lazy if you haven't noticed. To me it's less effort to use an existing php txt file based wiki and adapt it's parser to display the files I want |
| 13:59:35 | Trixar_za | :P |
| 14:00:28 | Araq | *shrug* |
| 14:00:46 | Araq | I'm so lazy I had to invent a new programming language that supports my laziness ... :P |
| 14:01:19 | Trixar_za | I once made LionWiki's parser compatible with true Wikipedia-like syntax, because people were complaining :/ |
| 14:02:59 | Trixar_za | Well, Laziness is an art. It's to reduce the total amount of effort required to do something. So even if the initial effort seems excessive, it does reduce the total amount for continued effort to do the same thing. |
| 14:10:18 | * | Nyx joined #nimrod |
| 14:10:30 | Araq | hi Nyx |
| 14:10:32 | Trixar_za | Interesting |
| 14:10:43 | Trixar_za | This is dom96's Python IRC client |
| 14:10:54 | Araq | oh ... |
| 14:10:57 | dom96 | hehe |
| 14:11:03 | Araq | :-( |
| 14:11:15 | dom96 | Haven't worked on it in years. |
| 14:11:35 | Araq | it's a zombie irc client then |
| 14:11:39 | Araq | back from the dead |
| 14:11:41 | dom96 | And it's filled with random bugs :D |
| 14:11:49 | Araq | it came to hunt me down |
| 14:11:56 | Nyx | lol |
| 14:12:06 | Trixar_za | [16:11:13] Araq: 7e00::f03c:91ff:fe93:822b PRIVMSG #nimrod :it came to hunt me down |
| 14:12:13 | Trixar_za | That's how all of Araq's messages look |
| 14:12:37 | dom96 | Araq: The python, it will choke you. The Nyx, it will love you. |
| 14:12:43 | dom96 | Trixar_za: Screenshot? |
| 14:12:51 | dom96 | I never tested it with IPv6 hostnamed :D |
| 14:12:54 | dom96 | *hostnames |
| 14:13:53 | Araq | dom96: make NimBot fight Nyx :-) |
| 14:14:14 | dom96 | Araq: hehe |
| 14:14:19 | Araq | shodan vs. xerxes :Dd |
| 14:15:05 | Trixar_za | http://trixarian.net/nyx.jpg |
| 14:15:30 | Trixar_za | oh, the upload stalled |
| 14:15:31 | Trixar_za | fun |
| 14:15:32 | Trixar_za | lol |
| 14:15:32 | Tasser | Araq, https://github.com/Araq/Nimrod/issues/148 wasn't low/high partly magic? |
| 14:16:17 | dom96 | Trixar_za: Can has the rest of screenshot? :P |
| 14:16:24 | dom96 | Ahh there. |
| 14:16:26 | Trixar_za | Right, fixed |
| 14:16:51 | dom96 | lol. My parser obviously fails with IPv6 :P |
| 14:17:45 | Trixar_za | It's an interesting client though :P |
| 14:17:54 | Araq | Tasser: ugh yes low/high are magic |
| 14:18:26 | Araq | but the bug seems to be new, I remember fixing 'count' for 'char' |
| 14:19:09 | * | Nyx quit (Quit: Nyx IRC Client, visit http://sourceforge.net/projects/nyxirc/) |
| 14:20:38 | Trixar_za | And yes, my SliTaz desktop looks similar to Windows |
| 14:20:39 | Trixar_za | :P |
| 14:21:31 | Tasser | Araq, wtf, tab.low and tab.high correctly return 0 and 255 |
| 14:22:03 | Araq | well yes |
| 14:22:14 | Araq | but try to add +1 to 255 for an unsigned byte |
| 14:23:58 | Araq | oh lol I only fixed it for 'items', not for 'countup' apparently |
| 14:31:33 | * | Trixar_za is now known as Trix[a]r_za |
| 14:43:50 | * | Trix[a]r_za is now known as Trixar_za |
| 14:54:10 | Trixar_za | Hmmm, Aporia is actually pretty light |
| 14:57:40 | Trixar_za | Except some of the keys don't work |
| 14:57:42 | Trixar_za | :/ |
| 14:58:21 | Araq | bug reports to dom96 :-) |
| 14:59:04 | dom96 | Wchich keys? |
| 14:59:11 | dom96 | *which |
| 14:59:42 | Trixar_za | Well, I can't type def |
| 15:00:08 | Trixar_za | and when I went SHIFT+ N E V E R M I N D |
| 15:00:11 | Trixar_za | only R showed up |
| 15:00:12 | Trixar_za | :P |
| 15:07:47 | Trixar_za | Ok |
| 15:08:06 | Trixar_za | It's because I compiled it with nimrod c -d:release --opt:size |
| 15:08:41 | dom96 | I bet I have some asserts which cause this somewhere |
| 15:08:44 | Trixar_za | compiling it without -d:release breaks it - you can't use any keys in it and it refuses to close |
| 15:09:02 | dom96 | 0_o |
| 15:09:14 | Trixar_za | compiling it with just -d:release allows me to type :/ |
| 15:10:48 | Araq | don't use --opt:size then |
| 15:10:53 | Trixar_za | lol |
| 15:11:03 | Trixar_za | Yeah, using -d:release makes it work perfectly |
| 15:12:37 | Araq | it's pretty strange though |
| 15:14:00 | dom96 | indeed |
| 15:14:43 | Trixar_za | Well, without -d:release and when you run it as ./aporia |
| 15:14:48 | Trixar_za | It shows Key Used: Right |
| 15:14:57 | Trixar_za | depending on which key you're using |
| 15:14:58 | Trixar_za | :P |
| 15:23:51 | dom96 | Well it should |
| 15:24:29 | Araq | argh |
| 15:24:42 | Araq | how to get a unique id for an object in javascript? |
| 15:25:04 | Araq | I don't want to map every hash value to 0 ... |
| 15:52:15 | * | JStoker quit (Excess Flood) |
| 16:03:16 | * | JStoker joined #nimrod |
| 16:07:48 | * | shevy quit (Ping timeout: 248 seconds) |
| 16:20:50 | * | shevy joined #nimrod |
| 16:36:14 | * | Trixar_za is now known as Trix[a]r_za |
| 17:10:27 | Tasser | Araq, ehm |
| 17:11:01 | Tasser | Araq, you need an id or just something to test disimilarity? |
| 17:11:17 | Araq | a hash value |
| 17:11:22 | Araq | but I hacked around it |
| 17:11:34 | Araq | I use obj["_NimID"] |
| 17:11:48 | Araq | and if it doesn't exist, I increment a global to get a new id |
| 17:13:57 | Tasser | have fun with mutex |
| 17:14:15 | Araq | why? |
| 17:14:23 | Araq | there is no concurrency in JS, is there? |
| 17:14:32 | Tasser | there is async in JS |
| 17:14:59 | * | Araq doesn't care |
| 17:27:19 | Araq | ugh my JS codegen sucks |
| 17:31:21 | Araq | see you later |
| 17:46:04 | Tasser | how much? |
| 18:01:47 | * | JStoker quit (Excess Flood) |
| 18:08:16 | * | JStoker joined #nimrod |
| 18:37:35 | * | filwit joined #nimrod |
| 18:37:45 | filwit | hi peeps |
| 18:39:36 | filwit | I'm not sure if anyone's around, but the other day I was trying to figure out how to make an "interface" in Nim similar to C#/D/Java's 'interface' construct |
| 18:40:15 | filwit | I never got it working, though I didn't have a whole lot of time to try. Anyone around that might know a bit about how to tackle this? |
| 18:40:38 | filwit | (or the Nimrod equivalent?) |
| 18:42:04 | dom96 | hello filwit |
| 18:42:14 | filwit | hi dom96 |
| 18:42:45 | dom96 | As far as I know the only way to achieve an interface-type thing is to have a list of procedures. |
| 18:43:03 | dom96 | Similar to how the streams module works. |
| 18:43:07 | dom96 | or how asyncio does. |
| 18:43:08 | filwit | I thought that's what 'method's where for :S |
| 18:43:17 | dom96 | Perhaps. |
| 18:43:34 | dom96 | Maybe my idea of interfaces is wrong D: |
| 18:43:42 | filwit | basically I have it almost working... |
| 18:43:53 | filwit | but I can't create a completely blank type |
| 18:44:00 | dom96 | Can I see your code? |
| 18:44:06 | filwit | with blank methods I mean |
| 18:44:11 | filwit | sure, one sec |
| 18:45:19 | filwit | https://gist.github.com/3029213 |
| 18:45:26 | filwit | that was my simple test |
| 18:46:27 | filwit | so basically I want to create a type (IShip) that provides a couple blank methods for it's derivatives |
| 18:47:11 | filwit | you know, now that I think about it... I guess I could just static assert (if that's possible) from the IShip methods to enforce that those aren't called directly |
| 18:48:06 | dom96 | give me a sec. |
| 18:48:13 | filwit | np |
| 18:51:01 | dom96 | You could have this: https://gist.github.com/effee3d78d270ea2fadf |
| 18:51:05 | dom96 | But I don't really like it. |
| 18:51:15 | dom96 | And I'm not sure if it fits your purpose |
| 18:52:16 | filwit | ah right, function pointers are the same as methods i suppose |
| 18:52:56 | filwit | but it's not the greatest syntax to create a FighterShip if I have to manually link up the procs in the constructor |
| 18:53:13 | filwit | though I suppose Nimrod encourages closure style objects |
| 18:53:18 | dom96 | You can also do this: https://gist.github.com/971f505d655ef5688852 |
| 18:53:36 | dom96 | You don't need to use methods |
| 18:54:09 | dom96 | I am still not entirely clear on what the purpose of methods is. |
| 18:54:14 | filwit | yes, but that doesn't work |
| 18:54:23 | dom96 | Why not? |
| 18:55:11 | filwit | if I have an array of ref IShip, and I use it to update a bunch of different kinds of IShip types: FighterShip, BomberShip, etc |
| 18:55:20 | filwit | I need dynamic dispatch |
| 18:55:38 | dom96 | I see. |
| 18:56:00 | dom96 | You do need methods then |
| 18:56:22 | filwit | yes, I think I can get it to work realy |
| 18:56:31 | filwit | how can I static assert? |
| 18:56:52 | dom96 | What do you mean by static assert? |
| 18:57:03 | filwit | is there a {.msg: "compile time message".} i can use? |
| 18:57:12 | filwit | asserting at compile time |
| 18:57:26 | dom96 | {.error: "...".} |
| 18:57:27 | dom96 | I think |
| 18:57:37 | filwit | ah, thanks, I'll try that |
| 18:57:38 | dom96 | But, huh? |
| 18:57:54 | dom96 | What do you want to happen? |
| 18:57:59 | dom96 | What's the problem with your code? |
| 18:58:35 | filwit | well, in languages that have an interface primitive, you use it to enforce (at compile time) functions that need to be implemented by derived types |
| 18:58:51 | filwit | I want to get similar functionality |
| 18:58:55 | dom96 | I see. |
| 18:59:01 | dom96 | I don't think that pragma will work |
| 18:59:11 | dom96 | It will be raised all the time |
| 18:59:29 | dom96 | It's only not raised when it's in a `when false:` I think |
| 18:59:53 | filwit | well I don't care so much about enforcing the type implements all the methods, only that you get an error if you try and call one on an IShip directly |
| 19:00:19 | filwit | so: |
| 19:00:26 | dom96 | Well since it's only known at runtime what the type is. |
| 19:00:34 | dom96 | You can only raise an exception at runtime. |
| 19:00:50 | dom96 | So just do: doAssert(false) or raise newException(.., ...) |
| 19:00:56 | filwit | method fire(ship:IShip) = {.error: "Not Implemented".} |
| 19:01:06 | dom96 | Right, well I need to go. Spain vs. Italy :P |
| 19:01:08 | dom96 | see ya later |
| 19:01:13 | filwit | ha, bye |
| 19:21:33 | * | filwit quit (Quit: Leaving) |
| 21:17:32 | * | zahary quit (Read error: No route to host) |
| 21:18:10 | * | zahary joined #nimrod |
| 22:36:52 | fowl | where is c2nim? |
| 22:37:17 | Araq | $nimrod/compiler/c2nim |
| 22:38:50 | fowl | hrm im missing it |
| 22:42:57 | Araq | which version? |
| 22:44:58 | Araq | which os? |
| 22:47:14 | fowl | 0.8.14 linux |
| 22:48:14 | * | filwit joined #nimrod |
| 22:48:23 | Araq | hi filwit |
| 22:48:29 | filwit | hi Araq |
| 22:48:34 | Araq | interfaces are to be done with a tuple of closures ;-) |
| 22:48:38 | filwit | I figured out my previous problem |
| 22:48:56 | Araq | or you use an 'assert' in the abstract method as dom96 suggested |
| 22:49:02 | * | filwit should have just read the docs again |
| 22:50:04 | filwit | so who's winning the football game? |
| 22:50:10 | dom96 | Spain won |
| 22:50:17 | dom96 | It was embarrasing |
| 22:50:21 | dom96 | 4-0 |
| 22:50:23 | dom96 | For a final. |
| 22:50:24 | filwit | nice |
| 22:50:28 | dom96 | A new record actually. |
| 22:50:37 | filwit | you voting for them? |
| 22:50:38 | dom96 | Highest score lead or whatever |
| 22:50:42 | Araq | and germany would have never beat this spain team |
| 22:50:50 | Araq | :-/ |
| 22:51:01 | Araq | so it doesn't really matter we lost against italy |
| 22:51:06 | dom96 | lol |
| 22:52:01 | filwit | one thing I never really liked about soccer is that the scores are always low.... |
| 22:52:27 | dom96 | I'll never understand you americans :P |
| 22:52:34 | filwit | :-P |
| 22:52:41 | dom96 | Not that i'm a big fan of football |
| 22:52:49 | dom96 | or soccer as you call it |
| 22:53:20 | filwit | well... in our football, we actually have tactics |
| 22:53:26 | * | filwit *says that and runs* |
| 22:53:40 | filwit | X-P |
| 22:54:27 | Araq | whatever |
| 22:55:17 | filwit | lol, I'm not a huge sports fan myself. I'm just poking fun |
| 22:56:21 | filwit | so, anyways... |
| 22:56:27 | filwit | we finished our game |
| 22:56:34 | Araq | cool |
| 22:56:42 | filwit | so I'll have some time to help with stuff now |
| 22:56:48 | Araq | excellent |
| 22:56:48 | dom96 | filwit: You shouldn't say that, ballotelli will kill you :P |
| 22:57:16 | dom96 | (But I shouldn't be bringing back this off-topic topic :P) |
| 22:57:21 | dom96 | Anyway, that's great! |
| 22:57:35 | filwit | guys want to see? |
| 22:57:40 | filwit | we made a short promo |
| 22:57:49 | dom96 | sure |
| 22:57:57 | filwit | http://www.youtube.com/watch?v=7pvCcgQiXNk&feature=g-u-u |
| 22:58:40 | filwit | we had to change the graphics a couple of times because of limitations with WP7, which is why it took us longer than expected to finish the thing |
| 22:58:50 | filwit | but in the end I'm pretty happy with it |
| 22:59:33 | * | dom96 likey |
| 22:59:47 | filwit | :) |
| 23:00:04 | fowl | cool |
| 23:00:04 | Araq | is it windows only? |
| 23:00:33 | filwit | Araq: no, it's Window, Mac, Linux + Tablets/Phones + Xbox360 (indie) |
| 23:01:09 | filwit | but we've only published to Xbox and WP7 today, and don't have the Android/iOS/PC builds done yet |
| 23:01:58 | filwit | we hope to have the builds done in a day or so, but each platform has a review process that can take a few days. (7+ for iOS) |
| 23:02:24 | filwit | so it'll be a week or so before you see it on those platforms |
| 23:02:40 | dom96 | filwit: Submit it to steam :D |
| 23:02:58 | filwit | we plan too, especially since it's coming to Linux soon |
| 23:03:38 | filwit | also, we're hoping we might get it into a Humble Bundle as a minor/side game |
| 23:04:47 | filwit | We hope to get it on the upcoming Windows 8 marketplace, Mac Appstore, and Ubuntu Software Center |
| 23:05:00 | filwit | anyways, I'm pretty excited :) |
| 23:06:28 | dom96 | cool |
| 23:06:35 | dom96 | Would be nice to see it in a humble bundle |
| 23:06:53 | dom96 | Then I would know someone who made a game that is in a humble bundle! :D |
| 23:07:52 | filwit | I hope |
| 23:09:46 | dom96 | Anyways, good night. |
| 23:10:00 | filwit | night |
| 23:13:22 | filwit | hmmm... I don't have to 'instantiate' a seq[] before I add to it do I? |
| 23:13:35 | Araq | you do: |
| 23:13:41 | Araq | var s: seq[string] = @[] |
| 23:14:06 | filwit | is there a function alternative to the '@[]' syntax? |
| 23:14:24 | Araq | newSeq(s, 0) |
| 23:14:27 | filwit | but thanks, that works |
| 23:14:32 | filwit | okay, thanks |
| 23:14:38 | * | XAMPP joined #nimrod |
| 23:15:52 | filwit | mind if I default that parameter and make a pull request so 'newSeq()' works? |
| 23:16:00 | filwit | or do you have something against that? |
| 23:16:15 | Araq | hm dunno |
| 23:16:37 | Araq | we should encourage to set it to a useful size |
| 23:17:37 | filwit | well considering you need to do that before adding anything, I would think encouraging clean syntax would be best. but It's your language :) |
| 23:18:08 | Araq | @[] is clean syntax :P |
| 23:18:27 | filwit | true |
| 23:18:58 | Araq | but seriously |
| 23:19:13 | Araq | what is it with you and constructor syntax? |
| 23:19:27 | Araq | why is it so important? |
| 23:19:49 | Araq | what percentage of your code is initialization? |
| 23:20:24 | filwit | well, my points about wanting constructors has more to do with understanding the types I'm working with |
| 23:20:36 | filwit | not just the few lines that actually initialize the object |
| 23:21:04 | filwit | if I can't just glance at a line and see the type, I think there's something wrong with the design (slightly) |
| 23:21:28 | filwit | it's true that a lot of the work is done with proper IDE support |
| 23:21:29 | Araq | you don't like type inference then, right? |
| 23:22:39 | filwit | not really |
| 23:23:10 | Araq | alright I see |
| 23:24:04 | filwit | it's mostly practicality. If I have to look up a function definition to see what Type i'm working with, something is wrong (IMO) |
| 23:24:14 | filwit | IDE support helps a lot, true |
| 23:25:09 | filwit | but it's still... annoying... to need to hover your mouse over something, where in other OOP languages you can simply glance and know that information through the syntax |
| 23:25:25 | filwit | don't get me wrong, I think Nimrod does a whole lot of things right |
| 23:25:47 | Araq | MyObject obj = new MyObject(); :P |
| 23:26:11 | filwit | var obj = new MyObject() yes |
| 23:26:26 | Araq | well my point was |
| 23:26:35 | filwit | oh |
| 23:26:41 | Araq | "new MyObject" actually prevents factories |
| 23:26:56 | filwit | well see, I'm open to new or different ideas |
| 23:27:03 | Araq | and thus is not abstract enough |
| 23:27:10 | filwit | or even arguments for factories alone |
| 23:27:19 | * | Trix[a]r_za is now known as Trixar_za |
| 23:27:26 | filwit | but I still think my argument is valid |
| 23:27:49 | filwit | for practical reasons, normally you don't need that sort of abstraction, you just want regular construction |
| 23:27:57 | Araq | not really; the convention is 'newT' and then you can see the type easy enough too |
| 23:28:11 | Araq | except that 'newT' can be turned into a factory |
| 23:28:13 | filwit | yes, but even with Aporia code, often this isn't the case |
| 23:28:16 | Araq | as it's only a convention |
| 23:28:29 | Trixar_za | Wait. Steam is coming to Linux? |
| 23:28:49 | filwit | especially when Nimrods types are TType/PType all over the place, and then the factories use 'newType()' |
| 23:29:03 | Araq | well the convention is: |
| 23:29:07 | Araq | initT # returns T |
| 23:29:12 | filwit | Trixar_za: yes |
| 23:29:13 | Araq | newT # returns 'ref T' |
| 23:29:26 | Araq | and perhaps: |
| 23:29:35 | Araq | allocT # returns 'ptr T' |
| 23:30:03 | Araq | but 'ptr' is rare enough that we have no convention for it |
| 23:30:03 | filwit | yes, I understand how, given a strictly followed set of naming rules, it can be easy to understand the type |
| 23:30:26 | filwit | the problem is that often we use others libraries, who may use different rules |
| 23:30:51 | filwit | or we change our rules and pass on code, and others don't know the original naming convention |
| 23:31:41 | filwit | It's usable, but honestly I just think that theres a better way that doesn't force developers to understand naming conventions to be able to understand the code |
| 23:32:10 | filwit | I hope you're not seeing me as saying "Nimrods unusable unless there's constructors" |
| 23:32:12 | filwit | cause I'm not |
| 23:32:36 | Araq | well constructors are planned but they don't do what you think they'll do |
| 23:32:39 | Trixar_za | Question: Who is 'we'? |
| 23:33:03 | Araq | and I think it's a very mood point |
| 23:34:02 | Araq | because the naming convention is not hard to learn |
| 23:34:14 | Araq | and if you don't want to adhere to it, fine |
| 23:34:45 | Araq | consistency between different libraries is hard to achieve |
| 23:34:58 | Araq | what if lib A uses factories and lib B does not? |
| 23:35:08 | Araq | here you go with your 'new T' syntax ... |
| 23:35:39 | Araq | and factories are IMO essential for OO |
| 23:36:01 | Araq | as often you don't want inheritance but "object patching" instead |
| 23:36:36 | Araq | "add to all Objects of type T this field 'x' please" |
| 23:36:47 | Araq | you can't do that with inheritance alone |
| 23:37:01 | Araq | you *need* to abstract the object construction for this to work |
| 23:37:31 | Araq | there are other ways to achieve object patching and nimrod may support true partial object type descriptions some day |
| 23:37:37 | Trixar_za | Oh God. I actually know what you're saying. |
| 23:38:06 | Trixar_za | I have been around you guys too long :/ |
| 23:38:47 | filwit | That is a valid reason for factories, but I think my point is equally as important considering you *most* often use simple construction. I just think there's a way to achieve both |
| 23:38:49 | Trixar_za | That and the 59 page essay on Event Driven Design (of which OO is a subset) |
| 23:38:58 | filwit | (citations needed) |
| 23:39:51 | Trixar_za | Hmmm, my headache is gone too |
| 23:40:05 | Trixar_za | So please continue, I'm actually interested |
| 23:41:38 | filwit | I know you say naming conventions are easy to follow, but I kind of disagree. We're not really talking about any function here, but the 'main' functions |
| 23:42:13 | filwit | when you read code, you see a variable that's doing things, and you need to know what it's type is to really understand what's going on with those functions |
| 23:42:28 | Araq | http://nimrod-code.org/apis.html |
| 23:42:38 | filwit | I admit, factories do work here, as often they're clear enough to understand |
| 23:42:43 | Araq | in C# it's either Count or Length or Size ... |
| 23:42:48 | Trixar_za | Ok, let me try to understand. Factories are objects with pre-set attributes and functions? |
| 23:43:19 | Araq | Trixar_za: a factory is a function that abstracts object construction and hides the object hierachy from you |
| 23:43:25 | filwit | Arqa: C# uses Count when counting is implied, and Length when the operation is O(1) |
| 23:43:49 | Araq | so a factory pretends to return T but may return a subtype instead |
| 23:44:05 | Araq | filwit: no, it's just messed up :-) |
| 23:44:22 | Trixar_za | So it's just a obfuscation of object design for the sake of...er... simplicity? |
| 23:44:44 | filwit | I don't see how. It informs the programmer about operation cost |
| 23:45:01 | Araq | you have a class hierarchy and then decide you actually don't like the type proliferation and hide it in a factory :-) |
| 23:45:06 | Araq | filwit: oh please |
| 23:45:07 | filwit | and both Count and Length are easy enough to find and understand on the Suggest List |
| 23:45:21 | Araq | it's Length for arrays and Count for Lists |
| 23:45:29 | Araq | and both are O(1) |
| 23:45:36 | Araq | as both are not braindead |
| 23:45:43 | Trixar_za | lol |
| 23:46:25 | filwit | that's true, but I think this has more to do with a common Itorator type for foreach loops |
| 23:46:32 | Trixar_za | ... ok, something is up with my playlist tonight. It's just throwing up songs about "Making a move" or "Change your Life" or "Make the Leap" type of songs. |
| 23:46:34 | Araq | and the inconsistent naming is a PITA in C# |
| 23:46:35 | filwit | though I'm not sure |
| 23:46:40 | Trixar_za | And people think God doesn't exist |
| 23:47:12 | Araq | and I program daily in C# btw, so don't try to convince me it's not :P |
| 23:47:44 | filwit | though I find it odd that now you're suggesting that C#'s naming discrepancies are a big issue, when you where previously saying that relying on naming conventions (which often change) isn't a big deal |
| 23:48:27 | Araq | my point is: |
| 23:48:31 | filwit | this is actually my point about factories, they're hard to _remember_ which one to call |
| 23:48:38 | Araq | it's much better in nimrod already |
| 23:48:45 | Araq | because nimrod uses 'len' consistently |
| 23:48:54 | filwit | where as common constructor keywords are easy: 'name' + type |
| 23:49:00 | Araq | and I never hear you complain about C# :P |
| 23:49:02 | filwit | typo: 'new' + type |
| 23:49:44 | filwit | I'm not a huge fan of C# for other reasons, but I do think they get most of their naming right |
| 23:50:01 | Araq | and nimrod's convention can actually be adhered to when you have a factory |
| 23:50:08 | filwit | most of the library functions in C# system are very easy to understand and descriptive |
| 23:50:49 | Araq | I never know if it's X() or just X ... |
| 23:51:16 | Araq | but yeah C# ain't too bad |
| 23:51:30 | Araq | it could be better though; but then it would be Nimrod :D |
| 23:51:43 | filwit | true ;) |
| 23:52:38 | filwit | mostly the problems with C# are it's pre-processor syntax and it's limited system power (though we do have the Marshal lib) |
| 23:52:56 | Trixar_za | In my personal opinion (which probably isn't worth much), I find the syntax of Nimrod both weird and extremely flexible. |
| 23:53:44 | filwit | Trixar_za: I like Nim's syntax overall. I think it's clean and simple, yet powerful |
| 23:53:54 | Trixar_za | Oh and by osmosis I'm actually picking things up from you guys |
| 23:54:01 | filwit | but there's still just a few things that 'erk' me |
| 23:54:18 | Araq | nimrod's syntax is good but could be better :-) |
| 23:54:26 | Araq | I'm working on it |
| 23:54:45 | Araq | though in my not so humble opinion I think my design aged extremely well |
| 23:54:58 | Trixar_za | You still have to write up a specification for it - according to the manual anyway |
| 23:55:03 | Araq | keep in mind it's from 2004 |
| 23:55:34 | filwit | one thing I really like about Nimrod syntax is that it combines procs and templates into the same calling conventions |
| 23:55:42 | Araq | and most of the new sexy stuff didn't exist back then |
| 23:56:04 | Araq | like coffeescript ... :D |
| 23:56:25 | filwit | where in D you need to use a '!' to differentiate between 'compile time' parameters and run-time ones, in Nim you just call functions that can do very powerful things. |
| 23:56:34 | Araq | filwit: that's a major design idea |
| 23:56:46 | Araq | I decoupled the syntax from the semantics |
| 23:57:02 | Trixar_za | Yep, somehow I knew it would be js generator |
| 23:57:43 | Araq | I got carried away |
| 23:57:49 | filwit | lol |
| 23:57:51 | Araq | I only wanted to make a single test green |
| 23:58:09 | Araq | and ended up improving the JS backend |
| 23:58:15 | Araq | which isn't even documented |
| 23:58:26 | Araq | and has no priority |
| 23:58:38 | Trixar_za | Atleast you enjoy working on your language |
| 23:59:46 | Trixar_za | Btw Araq, I talked one of the devs of SliTaz into using Nimrod to rewrite certain bash or javascript functions in SliTaz |
| 23:59:55 | Trixar_za | And he's already better at Nimrod than me |
| 23:59:56 | Trixar_za | lol |