| 01:45:52 | * | mal``` joined #nimrod |
| 01:51:11 | * | XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.) |
| 01:54:03 | * | XAMPP joined #nimrod |
| 01:54:03 | * | XAMPP quit (Changing host) |
| 01:54:03 | * | XAMPP joined #nimrod |
| 01:58:18 | * | XAMPP quit (Remote host closed the connection) |
| 02:01:40 | * | XAMPP joined #nimrod |
| 02:58:33 | * | XAMPP quit (Read error: No route to host) |
| 03:02:25 | * | XAMPP joined #nimrod |
| 04:31:22 | * | Bosc0p joined #nimrod |
| 04:31:47 | * | Boscop quit (Disconnected by services) |
| 04:31:49 | * | Bosc0p is now known as Boscop |
| 04:31:51 | * | Boscop quit (Changing host) |
| 04:31:51 | * | Boscop joined #nimrod |
| 04:57:14 | * | XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.) |
| 08:08:44 | Araq | hi mal``` welcome |
| 08:11:21 | Trixar_za | :D |
| 08:11:49 | Araq | Trixar_za: do you know mal``` ? |
| 08:12:25 | Trixar_za | Nope, but I just created a multiple socket bot using asynchronous sockets in less lines than the first one I wrote for only one |
| 08:14:09 | Araq | did you write it in nimrod? |
| 08:15:35 | Trixar_za | Not yet, but I will attempt it now |
| 08:15:45 | Trixar_za | Now that I understand the underlying principle, its actually easy |
| 08:16:01 | Trixar_za | And I just created 7 bots on the fly. This is awesome |
| 08:17:30 | Araq | alright, I have to go, see you later |
| 08:17:45 | Trixar_za | Later Araq |
| 08:17:48 | Araq | hopefully closures will be done by the end of the weekend ... |
| 08:18:02 | Araq | but I doubt it ... *sigh* |
| 08:18:20 | Araq | bye |
| 09:49:21 | dom96 | hello everyone |
| 09:49:43 | Trixar_za | Hey dom96 |
| 09:50:02 | dom96 | Trixar_za: how goes the bot making? Started writing one in Nimrod yet? :P |
| 09:50:24 | Trixar_za | Well, mastering AsyncIO took some time :P |
| 09:51:01 | Trixar_za | And not yet. But I did make the python version create new bots on demand. Which to me is kind of awesome. |
| 09:52:04 | Trixar_za | It is a funny thing though. It was hard until the moment I actually wrote the code. Then it started to make sense. |
| 10:03:50 | * | zahary joined #nimrod |
| 10:03:53 | dom96 | Yeah, I felt that way about AsyncIO too. |
| 10:34:29 | Araq | ping zahary |
| 10:40:45 | zahary | pong |
| 10:42:14 | Araq | we should make the .borrow feature work with the new generic + ops |
| 10:44:22 | zahary | yep |
| 10:44:29 | zahary | I was about to say the same :) |
| 10:44:41 | Araq | otherwise .borrow becomes pointless :-) |
| 10:44:53 | Araq | should be easy to do though |
| 10:45:05 | Araq | iirc there is special code for the searching |
| 10:45:24 | zahary | yes, there is (see semBorrow) |
| 10:45:39 | zahary | it should do something similar to overload resolution |
| 10:45:54 | Araq | perhaps |
| 10:46:21 | Araq | I'd simply take tyTypeClass into account though |
| 10:47:22 | zahary | well, it should work with regular generics too - I think, it should just skipTypes over the distinct and try regular overload resolution with the resulting (original) type |
| 10:50:29 | zahary | btw, I have some other use cases for distinct types that doesn't work well right now. |
| 10:50:29 | zahary | for example, when you want a custom hast table, the nimrod design suggest that you should create a unique type with overloaded hash and equals. usually, you'll just want to create a distinct that's in every way the same as the original except these two procs |
| 10:50:41 | zahary | we can introduce a borrowAll pragma to do that |
| 10:52:42 | zahary | and if we have borrowAll, I imagine the implementation will be very similar to "predicated borrow" - where you can specify some wildcard mask (regex) to specify which functions you want |
| 11:18:48 | Araq | hm |
| 11:18:59 | Araq | sounds good |
| 11:19:28 | Araq | perhaps we can somehow marry it with another idea I always wanted to try |
| 11:19:38 | Araq | which is language support for delegation |
| 11:20:18 | Araq | where you have a field in a object/tuple x and want to delegate all the operations to x.field |
| 11:20:41 | Araq | you can do it right now with a converter to 'var T' though |
| 11:32:33 | zahary | converter to var gets the job done here indeed and there are the proxy type rewrites for more customized forms of delegation |
| 11:36:18 | Araq | but a converter to var allows all operations |
| 11:36:42 | Araq | and it's nicer to whitelist the valid operations |
| 11:41:42 | zahary | aha, I see |
| 14:21:26 | * | fowl joined #nimrod |
| 15:04:03 | * | apriori_ joined #nimrod |
| 15:11:53 | apriori_ | did something change with imports? |
| 15:12:17 | apriori_ | I import another import, which imports several other nims which export types.. and these types are no longer visible in my main.nim |
| 15:19:59 | dom96 | If module C exports function foo, module B imports C and you import B, `foo` won't be accessible to your application. |
| 15:20:43 | apriori_ | so.. what would be the solution? |
| 15:21:16 | apriori_ | I mean.. sure I can directly import.. but that's not really convenient |
| 15:21:46 | apriori_ | I guess.. I would need to use "include" in such a case |
| 15:22:25 | dom96 | In most cases a better solution is to have a 'types.nim' or 'utils.nim' which all modules can import. |
| 15:22:55 | apriori_ | ok, ty |
| 15:23:12 | Araq | apriori_: nothing changed wrt import (I hope) |
| 15:23:38 | Araq | and the planned 'export' feature will allow for symbol forwarding |
| 15:23:47 | Araq | but dom96's advice is good |
| 15:24:41 | apriori_ | yeah, ok |
| 15:24:59 | apriori_ | for now I just made a "opencl.nim" which has several import lines.. and "include" that |
| 15:25:55 | apriori_ | btw., one nice syntax for module forwarding would be like import A* |
| 15:27:11 | Araq | nah ;-) |
| 15:27:20 | Araq | planned is: |
| 15:27:24 | Araq | import A |
| 15:27:29 | Araq | export A.x, A.y, A.z |
| 15:27:47 | apriori_ | no whole module export? |
| 15:28:11 | Araq | would that be useful? |
| 15:28:29 | apriori_ | well... |
| 15:28:43 | apriori_ | otherwise you would enforce the structure as described by dom96 |
| 15:29:08 | apriori_ | because no one would like dozens of export foo.bar |
| 15:29:32 | Araq | well I dunno, perhaps you're right |
| 15:29:49 | Araq | alright, we need a syntax for whole module export |
| 15:30:14 | Araq | people hate the * export marker so I'm not too sure "import A*" is good enough |
| 15:30:17 | apriori_ | import A* would be consistent with the current usage of export |
| 15:30:31 | Araq | that's true |
| 15:31:02 | apriori_ | why do they hate the import marker? |
| 15:31:23 | Araq | because they can't figure out the meaning without reading a tutorial about nimrod ... |
| 15:31:32 | apriori_ | ... |
| 15:31:37 | apriori_ | hardly a reason to hate it |
| 15:31:45 | Araq | *shrug* |
| 15:31:57 | apriori_ | oh.. surprise.. you need to read something about a language in order to understand it... |
| 15:32:07 | Araq | I often wonder if people who nitpick about these things ever actually write a single line of working code ... |
| 15:32:28 | apriori_ | unlikely ^^ |
| 15:33:39 | apriori_ | is there a way to make a forwarded function which is imported from a c-library only fail at runtime if it is actually called? |
| 15:34:10 | Araq | sure use {.deadCodeElim:on.} in the wrapper |
| 15:34:14 | apriori_ | I know its a strange case.. but with opencl I encountered a case in which a function which is described in the headers is not even implemented in the shipped OpenCL library (of nvidia) |
| 15:34:19 | apriori_ | ah, ok |
| 15:34:21 | apriori_ | ty |
| 15:34:23 | Araq | well |
| 15:34:36 | Araq | that's not fail at runtime if it's actually called |
| 15:34:48 | Araq | but "fail if client module actually uses it" |
| 15:34:58 | apriori_ | thats enough |
| 15:35:25 | Araq | most wrappers use this pragma :-) |
| 15:35:58 | apriori_ | {.deadCodeElim:on, importc: "clGetGLContextInfoKHR", dynlib: "libOpenCL.so".} |
| 15:35:59 | apriori_ | hm |
| 15:36:05 | apriori_ | nimCL/cl/cl_gl.nim(128, 81) Error: invalid pragma: deadCodeElim: on |
| 15:36:15 | apriori_ | some syntax error? |
| 15:39:26 | Araq | it's a module wide pragma |
| 15:39:37 | Araq | so make it a top level statement: |
| 15:39:44 | Araq | {.deadCodeElim:on.} |
| 15:39:55 | apriori_ | ah, ok |
| 15:39:55 | Araq | put it before any procs are defined |
| 15:40:01 | apriori_ | thanks |
| 17:17:14 | * | apriori_ quit (Quit: Konversation terminated!) |
| 17:51:44 | Araq | ping Boscop |
| 17:59:22 | * | Zerathul joined #nimrod |
| 18:04:38 | * | Zerathul quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]) |
| 19:58:24 | Boscop | pong Araq |
| 19:58:46 | Araq | oh hi |
| 19:58:54 | Araq | only a minor point |
| 19:58:54 | Boscop | hi |
| 19:59:19 | Araq | but ever tried to change some fonts to make _ look more like - ? |
| 20:00:56 | Boscop | no, but because _ is often visually nearly in the next line, my lang uses - for multi-word identifiers, like lisp, it's also one keypress less |
| 20:01:59 | Araq | well yes I know |
| 20:02:12 | Araq | but I still prefer - for minus and _ for separating words |
| 20:02:21 | Boscop | - is minus too |
| 20:02:50 | Araq | so you require whitespace around it? |
| 20:03:12 | Boscop | yes |
| 20:03:29 | Boscop | I usually leave whitespace around it in C/C++/D anyway |
| 20:03:40 | Araq | do you require whitespace for other operators too? |
| 20:03:49 | Boscop | no, but I recommend it |
| 20:04:51 | Boscop | it's a compromise, I could have used one of the unicode hyphens/minuses but those aren't easily typeable |
| 20:05:17 | Araq | there is also the idea to make whitespace precedence relevant |
| 20:05:28 | Boscop | yes, I do that, too |
| 20:05:36 | Araq | so 1+3 * 3 is (1+3) * 3 |
| 20:05:42 | Boscop | yes |
| 20:05:51 | Araq | interesting |
| 20:05:52 | Boscop | but I only do it one level deep |
| 20:06:01 | Araq | hm yeah that's good |
| 20:06:13 | Boscop | so multiple spaces are treated as one |
| 20:07:04 | Araq | I'd perhaps choose 2 levels deep but I dunno |
| 20:07:54 | Boscop | yeah, it's a bit experimental, but it's just syntax, it can be changed later if it doesn't work out |
| 20:08:10 | Araq | I came to the conclusion that _ is misdesigned and all fonts should be fixed :-) |
| 20:08:27 | Araq | and then nimrod supports your favourite way too :D |
| 20:08:41 | Boscop | yes, but it's harder to fix all fonts for everyone ;) |
| 20:09:30 | Araq | true but a language needs IDE support anyway |
| 20:09:41 | Araq | and you only need to fix it in the IDE mostly |
| 20:10:18 | Boscop | yeah, the IDE could allow easy access to unicode minus/hyphen |
| 20:10:29 | Boscop | instead of messing with fonts |
| 20:10:31 | Araq | well that too yes |
| 20:10:48 | Araq | hm |
| 20:11:54 | Boscop | at least _ is better than camelCase in that it allows separation of acronym names, e.g. SQLWriter vs SQL_writer or SQL-writer |
| 20:14:38 | Boscop | the problem I'm currently thinking about is how to manage different configs of modules, usually there is debug/release but there can also be custom configs, e.g. which interface type to use, CLI,GUI,web etc. and how to propagate configs to the imported modules (e.g. if A imports B and A is debug, B should be automatically debug too, but also for custom program-wide configs) |
| 20:15:15 | Araq | what's the problem? just do it like nimrod ;-) |
| 20:15:27 | Boscop | how does it do it? |
| 20:15:42 | Araq | there is a project wide configuration file |
| 20:16:06 | Araq | which supports basically all command line options to the compiler |
| 20:16:20 | Araq | and support C-like "defined symbols" |
| 20:16:37 | Araq | which can be accessed in nimrod code via the built-in "defined(...)" |
| 20:17:07 | Araq | and there are pragmas like {.push boundChecks:on.} and {.pop.} |
| 20:17:21 | Araq | to change the settings for code sections |
| 20:19:16 | Boscop | yeah, I also want to allow e.g. optimization flags per code sections |
| 20:19:33 | Araq | see http://nimrod-code.org/nimrodc.html#configuration-files for the configuration file stuff |
| 20:19:40 | Boscop | but the whole system should be as simple as possible, not like make or even requiring make |
| 20:19:47 | Boscop | ah |
| 20:20:12 | Araq | nimrod doesn't use 'make' either |
| 20:20:53 | Araq | and invokes multiple GCC processes in parallel |
| 20:21:17 | Araq | the compiler itself is almost impossible to parallelize due to nimrod's static semantics |
| 20:21:40 | Araq | but at least the backend is fully parallelized |
| 20:22:42 | Araq | I think this is inherently the case for every compiler for a real world programming language |
| 20:23:29 | Araq | http://nimrod-code.org/nimrodc.html#compilation-cache may also be interesting for you |
| 20:24:07 | Araq | and this: http://nimrod-code.org/intern.html#compilation-cache |
| 20:25:53 | Boscop | but then users need to learn the format of another config system which fulfills a special case of make.. |
| 20:27:01 | Araq | in nimrod's case unfortunately yes, but you can easily re-use the parser |
| 20:27:13 | Araq | and use the same syntax for configuration files |
| 20:27:37 | Araq | I'd do it this way if I would do the config system again |
| 20:27:48 | Araq | but there are always better things to do ;-) |
| 20:28:26 | Araq | when I wrote it, the nimrod parser was not finished I think |
| 20:37:35 | Araq | so Boscop, what's your opinion about rust? |
| 20:51:03 | Araq | well write down the answer if you like, I need to go |
| 20:51:09 | Araq | good night |
| 20:52:54 | Boscop | I haven't had time to start a project in Rust yet, but I've read the tut/docs and blog posts about it |
| 20:54:05 | Boscop | people complained about usability issues, but the rust people are working on improving that |
| 20:54:52 | Boscop | e.g. not nestable types, having to propagate template args etc. |
| 21:00:14 | Boscop | it seems to have limited metaprogramming capabilities |