| 00:30:29 | * | DAddYE joined #nimrod |
| 01:17:20 | * | DAddYE quit (Remote host closed the connection) |
| 01:33:56 | * | XAMPP-8 joined #nimrod |
| 01:34:54 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
| 01:38:23 | * | DAddYE joined #nimrod |
| 01:58:05 | * | DAddYE quit (Read error: Connection reset by peer) |
| 02:02:35 | * | DAddYE_ joined #nimrod |
| 02:41:14 | * | DAddYE_ quit (Remote host closed the connection) |
| 02:52:44 | * | DAddYE joined #nimrod |
| 03:15:13 | * | DAddYE quit (Remote host closed the connection) |
| 04:20:32 | * | OrionPK quit (Quit: Leaving) |
| 04:27:11 | * | Ricky_Ricardo joined #nimrod |
| 05:33:44 | * | Ricky_Ricardo quit (Quit: laptop[lid].close) |
| 07:45:48 | * | Araq_ joined #nimrod |
| 07:46:04 | * | Araq_ quit (Client Quit) |
| 08:16:21 | * | q66 joined #nimrod |
| 08:46:36 | * | EXetoC joined #nimrod |
| 09:39:13 | * | SparkyFlary joined #nimrod |
| 09:45:08 | SparkyFlary | is nimrod a better python or something? |
| 10:12:07 | EXetoC | why? because of the syntax? |
| 10:14:00 | SparkyFlary | perhaps..? |
| 10:18:13 | EXetoC | I think languages such as python are fine for simple applications, but dynamic typing is nothing but an inconvenience in my opinion |
| 10:20:21 | SparkyFlary | what about for web development? |
| 10:21:17 | SparkyFlary | what's nimrod good at? |
| 10:26:39 | * | Araq_ joined #nimrod |
| 10:26:47 | EXetoC | Nimrod has a language-level templating engine, and there's a web framework called Jester. both seem to be fairly useful |
| 10:28:09 | EXetoC | what it's good at? All I can say is that I think it's better than pretty much all statically-typed languages I've used before |
| 10:28:40 | EXetoC | Araq_ might be able to provide a more concrete answer to that question |
| 10:28:45 | Araq_ | EXetoC: wow, thank you :-) |
| 10:29:13 | EXetoC | :> |
| 10:29:15 | Araq_ | hi SparkyFlary welcome; well we use it for compilers, web apps, games and scripting |
| 10:31:31 | SparkyFlary | what so special that the others can't do or have hard time? |
| 10:31:46 | SparkyFlary | other languages |
| 10:35:00 | Araq_ | let's see, we have global dead code elimination leading to small binaries, a realtime GC, easy interfacing with C, meta programming which pushes the state of the art |
| 10:36:30 | Araq_ | I'm not aware of any other language that supports all of this |
| 10:40:40 | SparkyFlary | looks interesting |
| 10:41:19 | SparkyFlary | thanks for the help |
| 10:41:26 | * | SparkyFlary quit (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
| 10:55:46 | * | Araq_ quit (Read error: Connection timed out) |
| 10:56:59 | * | Araq_ joined #nimrod |
| 10:57:10 | * | Araq_ quit (Client Quit) |
| 11:40:48 | dom96 | This looks like something Nimrod would be perfect for: http://pandacodium.ca/ |
| 11:44:50 | * | Araq_ joined #nimrod |
| 11:57:15 | EXetoC | I don't like pandas |
| 11:59:00 | dom96 | why :O ? |
| 12:00:21 | EXetoC | They are scary. I wouldn't let one in my house |
| 12:00:41 | dom96 | I would love a pet panda. |
| 12:00:54 | dom96 | I would prefer a pet sloth though |
| 12:01:18 | EXetoC | :> |
| 12:17:09 | * | zahary_ joined #nimrod |
| 12:56:19 | dom96 | Why does the compiler use a nimrod.cfg file for compilation if it exists in a parent directory? |
| 12:56:46 | dom96 | That just caused me some bother |
| 12:57:15 | dom96 | on the other hand it did help me find a different bug |
| 13:03:58 | * | bmp quit (Remote host closed the connection) |
| 13:06:14 | Araq_ | dom96: blame zahary_ for that feature; it implements some nice config "inheritance" |
| 13:06:52 | dom96 | Araq_: btw the getLastError weirdness is caused by activating threads. |
| 13:07:34 | Araq_ | getLastError should be threadsafe |
| 13:08:15 | dom96 | I'm not creating any threads though, simply compiling with --threads:on causes these problems. |
| 13:08:56 | * | Ricky_Ricardo joined #nimrod |
| 13:09:49 | * | Ricky_Ricardo quit (Client Quit) |
| 13:10:27 | Araq_ | well ... that means the code calls the OS more to get thread local storage |
| 13:10:38 | Araq_ | so yeah that could cause it |
| 13:11:55 | dom96 | ok, i'll wrap ThreadVarSetValue with a getLastError and a setLastError then. |
| 13:12:05 | dom96 | (and ThreadVarGetValue) |
| 13:12:27 | Araq_ | it's worth a try, yeah |
| 13:13:47 | dom96 | I think it's a good idea to keep it in alloc also. |
| 13:14:07 | dom96 | According to the docs "some winapi calls reset LastErrors on success and some don't" |
| 13:14:13 | dom96 | How nice... |
| 13:14:50 | Araq_ | you can check Wine's source to figure out which ones do |
| 13:15:00 | Araq_ | I think ... |
| 13:15:32 | dom96 | Yeah, but what if it changes between Windows versions? |
| 13:17:53 | Araq_ | unlikely |
| 13:18:06 | Araq_ | and if so wine's source should tell you *cough* |
| 13:18:44 | dom96 | meh, I don't feel like going through Wine's source :P |
| 13:20:47 | dom96 | Araq_: er, why do you not check TlsSetValue's return value? |
| 13:21:09 | dom96 | it has been wrapped incorrectly in fact |
| 13:21:54 | Araq_ | why? |
| 13:22:11 | Araq_ | and what should we do if it fails? |
| 13:22:22 | dom96 | dunno |
| 13:22:25 | dom96 | Just checking. |
| 13:22:26 | Araq_ | we can call quit() I suppose |
| 13:22:49 | dom96 | It just makes me worried that it might not work because it's wrapped incorrectly. |
| 13:22:57 | dom96 | But I guess it doesn't matter |
| 13:23:25 | Araq_ | if you refer to the missing return type, it doesn't matter |
| 13:23:30 | Araq_ | "TlsSetValue was implemented with speed as the primary goal. The function performs minimal parameter validation and error checking. In particular, it succeeds if dwTlsIndex is in the range 0 through (TLS_MINIMUM_AVAILABLE – 1). It is up to the programmer to ensure that the index is valid before calling TlsGetValue." |
| 13:23:47 | Araq_ | so we may as well not check the return value |
| 13:24:10 | dom96 | ok, well I added the return type to the proc signature and I'll just discard it |
| 13:24:27 | Araq_ | if it makes you happy ... |
| 13:24:40 | dom96 | yay that fixes it |
| 13:26:28 | dom96 | now where is the place to put the wrapped GetLastError and SetLastError so that alloc.nim and threads.nim can both use it? |
| 13:26:38 | EXetoC | what will the next version bring us? better threading semantics? that's one of the few areas that are still in flux, right? |
| 13:27:32 | EXetoC | you know what would be a killer feature? automatic high level wrapper generation :> |
| 13:27:53 | Araq_ | EXetoC: better threading model, changed lookup rules for hygienic templates, making '=' overloadable, bugfixes |
| 13:31:02 | EXetoC | neat |
| 13:31:05 | Araq_ | EXetoC: I plan to make c2nim support C++; dunno if that's what you mean |
| 13:34:46 | dom96 | EXetoC: Hopefully a first early version of an await feature (ala C#'s await) from me, and with that an optimized asyncio (and other modules which use it) and hopefully an async TFile implementation. |
| 13:38:10 | EXetoC | Araq_: sounds mildly complicated |
| 13:40:28 | dom96 | Araq_: Any ideas? |
| 13:41:19 | Araq_ | dom96: about what? |
| 13:41:46 | dom96 | Araq_: Where should I put GetLastError and SetLastError so that alloc.nim and threads.nim can use it? |
| 13:44:37 | Araq_ | dunno |
| 13:45:13 | Araq_ | ansi_c.nim? :P |
| 13:46:06 | dom96 | ok |
| 13:52:43 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 15:07:05 | * | Sergio965 joined #nimrod |
| 15:23:01 | gradha | Do we have an image processing lib? Loading/saving images and modifications, either through pure pixel buffer or higher level constructs |
| 15:24:57 | gradha | actually, forget about formats, that introduces more dependencies |
| 15:26:34 | dom96 | gradha: nimforum uses cairo to create the captcha during registration: https://github.com/nimrod-code/nimforum/blob/master/captchas.nim |
| 15:27:05 | gradha | I know, that part had trouble under macosx |
| 15:27:45 | dom96 | you could also use sdl |
| 15:28:09 | gradha | yes, I was thinking now about using that instead of wrapping something else, as I may well end up using pixel access anyway |
| 15:37:12 | gradha | oh, nice, so sdl 2 is not lgpl to allow embedded/static linking |
| 15:49:10 | * | Endy joined #nimrod |
| 16:37:55 | dom96 | that's pretty nice, do we have sdl2 bindings? |
| 16:38:15 | gradha | no idea, the sdl bindings don't work at all on macosx anyway |
| 16:38:34 | dom96 | I see :\ |
| 16:44:52 | NimBot | nimrod-code/Aporia master b477853 Dominik Picheta [+0 ±2 -0]: Fixed more GTK signal bool problems and 'permission denied' config save errors. |
| 16:44:52 | NimBot | nimrod-code/Aporia master f9219a3 Dominik Picheta [+0 ±2 -0]: More fixes relating to incorrect usage of 'bool' for signals. |
| 16:44:52 | NimBot | nimrod-code/Aporia master 1078822 Dominik Picheta [+0 ±1 -0]: Fixes connection being closed prematurally on Windows when launching Aporia in single instance mode twice. |
| 16:45:47 | dom96 | damn it, it's spelled prematurely. |
| 16:48:54 | * | DAddYE joined #nimrod |
| 17:40:22 | EXetoC | uh oh |
| 18:07:14 | NimBot | nimrod-code/Aporia master b115144 Dominik Picheta [+0 ±1 -0]: Fixes crash on startup when no config is present. |
| 18:24:29 | * | Endy quit (Ping timeout: 256 seconds) |
| 18:26:53 | fowl | dom96, gradha i've had sdl2 binding for months now |
| 18:46:57 | * | Sergio965 quit (Ping timeout: 248 seconds) |
| 18:47:25 | dom96 | fowl: cool |
| 18:59:20 | * | Sergio965 joined #nimrod |
| 19:08:55 | EXetoC | meep meep |
| 19:09:28 | * | dom96 hisses |
| 19:09:48 | dom96 | EXetoC: Cured cancer with Nimrod yet? |
| 19:10:20 | EXetoC | I'm on it |
| 19:33:52 | EXetoC | there's no 'with' block, right? my enumerations are pure, so that would be convenient |
| 19:36:02 | EXetoC | maybe I'll implement a library version of it |
| 19:36:04 | fowl | dom96, can the irc logs be integrated with the forums, and have people on the forums ask questions in IRC, relayed through NimBot ? |
| 19:36:23 | fowl | EXetoC, what is "with" |
| 19:36:45 | dom96 | fowl: You mean announcements when a new thread/post is created? |
| 19:36:54 | dom96 | I am going to add that eventually |
| 19:37:17 | fowl | no i mean a textinput at the end of the log that you can type a question into and have it sent here through NimBot |
| 19:37:29 | EXetoC | fowl: with enumtype: # no need to specify enumtype now |
| 19:37:34 | EXetoC | or some arbitrary namespace |
| 19:37:36 | fowl | you know, with javascripts and such |
| 19:37:57 | fowl | huh, weird |
| 19:38:31 | EXetoC | when the enum type is pure, of course |
| 19:39:10 | fowl | why? you want to circumvent the purity of the enum to save keystrokes? |
| 19:40:45 | EXetoC | pretty much |
| 19:41:05 | dom96 | Meh, I think the forum is good enough for that purpose. |
| 19:41:31 | dom96 | But if you want, you can implement it. |
| 19:41:44 | gradha | maybe fowl is suggesting this because forums implicitly require registration to avoid spam, but then, the anonymous log would spam you anyway once somebody figures automating it |
| 19:43:36 | fowl | idk i just thought about it last night |
| 19:43:57 | fowl | if the irc logs were more prominent and you could get into irc without opening a client |
| 19:47:50 | gradha | but then we could not talk freely about nimrod dongles |
| 19:48:23 | gradha | fowl: have they removed SDL_main macro trickery in 2.0? |
| 19:54:14 | fowl | gradha, its still there, you dont have to use it though |
| 19:56:03 | Araq | EXetoC: now you know why I almost never use pure enums ... ;-) the namespacing is annoying, I go with 2 letter prefixes most of the time |
| 19:57:32 | fowl | gradha, i guess someone should test it out on windows |
| 19:57:39 | Araq | implementing 'with' as a macro is fun ... we don't have an API yet to access the enum fields of a type ... |
| 19:59:28 | EXetoC | ok |
| 20:02:17 | EXetoC | I prefer explicit namespaces, but it's nice to be able to specify implicit namespace lookups |
| 20:03:31 | Araq | well as I said the API is missing for that for now |
| 20:04:37 | Araq | but then why bother ... "I want namespacing, except I don't in this, this and that context" is meh ... |
| 20:05:41 | gradha | namespacing is very important, imagine writing C code without the namespace keyword... madness! |
| 20:06:46 | * | fowl imagines a language in which everyone's preferences are fulfilled... nope, cant do it |
| 20:07:53 | gradha | it's easy to find people who agree with you that a language/feature sucks, but pretty hard to find those who agree on what you like |
| 20:08:15 | fowl | dynamic static weak strong typing, imperaprocedurafunctionality, etc |
| 20:08:38 | fowl | mutable immutability would be nice to have |
| 20:09:23 | Araq | EXetoC: you can put the enum into its own module and then use module.enumval everywhere except when you don't feel like it |
| 20:10:08 | fowl | yea then export it from the module that requires it so you dont have to import it everywhere |
| 20:10:39 | Araq | fowl: ha, haven't thought of that ... :-) |
| 20:11:01 | Araq | java-style, put everything in its own file |
| 20:11:02 | gradha | careful there, next thing you know you are writing modular code |
| 20:11:20 | Araq | gradha: java-style is anti-modular, don't worry |
| 20:12:01 | gradha | I remember how we used to concatenate C++ source code to reduce compile times but then had to be careful with per file static-ness |
| 20:21:42 | dom96 | Every time I write docs I keep writing 'function' and then thinking "I should be writing procedure". Is 'function' fine? or should I strictly be saying 'procedure' or 'proc'? |
| 20:24:50 | gradha | are functions different from procs? |
| 20:25:05 | Araq | function is fine now |
| 20:29:07 | dom96 | ok |
| 20:29:35 | dom96 | gradha: I think they're pretty much synonyms. |
| 20:33:58 | Araq | dom96: by now they are indeed |
| 20:34:04 | dom96 | Just as I thought, deprecating OSError creates A LOT of warnings. |
| 20:40:37 | Araq | dom96: only if you don't fix the stdlib |
| 20:40:53 | dom96 | yay. How fun :P |
| 20:41:40 | EXetoC | gradha: there is a namespace, and if implicit lookup is an issue then you don't use that particular feature for said piece of code |
| 20:41:47 | EXetoC | but whatever, this is a minor thing |
| 20:46:04 | dom96 | Araq: Yeah, I don't think this is working. |
| 20:47:29 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:51:27 | dom96 | I have OSLastError right after the 'if' in an else clause, all OSLastError does is call GetLastError and cast it to TOSErrorCode. |
| 20:51:39 | dom96 | Works without --threads:on. |
| 20:55:50 | EXetoC | Araq: such an enum API wouldn't be strictly necessary I think. the only problem right now is that symbols passed to macros and templates must be valid in the actual instantiation scope if I'm not mistaken |
| 20:56:27 | Araq | EXetoC: dunno, use an immediate macro then |
| 20:56:34 | EXetoC | oh |
| 20:56:57 | Araq | dom96: good point |
| 20:57:15 | Araq | you need to do {.push stackTrace:off.} proc osLastError ... {.pop.} |
| 20:57:22 | Araq | and then it should work |
| 21:00:15 | EXetoC | yes that seems to work |
| 21:00:44 | dom96 | Araq: Yep, that works. |
| 21:08:25 | EXetoC | or just this: "type TA = enum \n type B = a \n let a = B.x" had it worked. seems reasonable |
| 21:08:34 | EXetoC | except you wouldn't bother with such short names |
| 21:08:47 | * | q66 quit (Remote host closed the connection) |
| 21:23:05 | * | Associat0r joined #nimrod |
| 21:23:14 | dom96 | hello Associat0r |
| 21:23:14 | EXetoC | Associat0r: rly |
| 21:24:43 | EXetoC | I *think* he's going to show us some articles, but I might be wrong :> |
| 21:25:11 | gradha | so brace for impact? |
| 21:28:24 | dom96 | The suspense is killing me. |
| 21:30:02 | EXetoC | or maybe he mostly does that in #d and possibly other channels c(:) |
| 21:38:17 | reactormonk | how do I get directory contents? |
| 21:38:19 | dom96 | Araq: arghh, Windows uses errno too? |
| 21:38:23 | reactormonk | aka os.listdir |
| 21:38:31 | dom96 | reactormonk: os.walkdir |
| 21:39:31 | dom96 | Araq: This means I will need to make TOSErrorCode an object since errno requires a different proc to be used to convert it into a string |
| 21:42:16 | Araq | dom96: windows uses errno for very little I think it's safe to say it doesn't use it |
| 21:42:59 | dom96 | Araq: I see a function in os.nim which checks errno... |
| 21:43:18 | Araq | dom96: which one? OSError doesn't count |
| 21:43:26 | dom96 | removeFile |
| 21:44:08 | Araq | yeah well |
| 21:44:17 | Araq | removeFile shouldn't call OSError then |
| 21:44:52 | Araq | but raise newException(EOS, $strerror(errno)) |
| 21:44:58 | dom96 | ok |
| 21:45:06 | Araq | but hmm |
| 21:45:11 | dom96 | ... |
| 21:45:51 | Araq | yeah I think it's fine this way, you use the abstraction or errno directly |
| 21:46:11 | Araq | should always work, right? |
| 21:47:02 | dom96 | I hope so. |
| 21:47:33 | dom96 | I'm worried about the other 'c' procs |
| 21:47:39 | dom96 | like moveFile |
| 21:48:00 | dom96 | The thing is, we will break the behaviour of OSErrorMsg |
| 21:50:03 | dom96 | This is a very big change. |
| 21:50:09 | dom96 | I still don't like it |
| 21:50:31 | dom96 | I will break more things than I will fix while fixing these deprecation warnings. |
| 22:05:27 | * | OrionPK joined #nimrod |
| 22:06:21 | Araq | dom96: OSErrorMsg should be deprecated too |
| 22:07:42 | dom96 | I know. |
| 22:09:49 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 22:11:38 | dom96 | Araq: Thoughts about my other points? |
| 22:12:21 | Araq | the 'c' procs use errno, the windows proc getLastError |
| 22:12:38 | Araq | I think it's fine to not conflate these two |
| 22:25:31 | * | EXetoC joined #nimrod |
| 22:38:47 | dom96 | Araq: ok, so I will change all 'c' procs to not use OSError... |
| 22:39:15 | Araq | dom96: thanks |
| 22:48:39 | dom96 | Araq: argh, this feels inconsistent. Since I can use OSError for errorno but only on unix... |
| 22:48:41 | dom96 | oh well |
| 22:50:49 | * | XAMPP quit (Ping timeout: 256 seconds) |
| 23:07:14 | reactormonk | now I know why I can't code in nimrod as fast... googability is low. |
| 23:07:58 | dom96 | I don't think Google will help you much with Nimrod. |
| 23:08:20 | gradha | start spamming stackoverflow |
| 23:08:29 | Araq | or use the index |
| 23:09:00 | gradha | or listen to cool music |
| 23:10:05 | * | dom96_ joined #nimrod |
| 23:12:33 | * | dom96_ quit (Client Quit) |
| 23:31:29 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
| 23:31:44 | EXetoC | enumerators can't be tuples? |
| 23:33:46 | dom96 | what do you mean? |
| 23:37:59 | EXetoC | dom96: the tuple syntax for enumerators is for overriding the string representation |
| 23:38:07 | EXetoC | the workarounds are trivial though |
| 23:40:00 | dom96 | sorry, i'm still not sure what you mean. Code example? |
| 23:43:14 | EXetoC | dom96: enumerators as in enum members. type T = enum x = (1, "ohai") gives x the value of 1 and sets its string representation to ohai |
| 23:43:49 | dom96 | i see. Yeah, you can't do that. |
| 23:45:55 | EXetoC | ya |
| 23:58:28 | * | BitPuffin joined #nimrod |
| 23:58:35 | BitPuffin | Hey guys! |
| 23:58:51 | BitPuffin | You should add pattern matching to Nimrod, it's very expressive :D |
| 23:59:03 | EXetoC | c(:) |
| 23:59:37 | dom96 | hey BitPuffin |
| 23:59:42 | BitPuffin | hey dom96! |
| 23:59:51 | dom96 | BitPuffin: You could add it yourself with macros ;) |