00:01:39 | * | yglukhov quit (Ping timeout: 248 seconds) |
00:01:54 | * | reactormonk quit (Quit: WeeChat 1.4) |
00:02:09 | * | vendethiel joined #nim |
00:09:49 | * | Matthias247 quit (Read error: Connection reset by peer) |
00:09:59 | * | jaco60 quit (Ping timeout: 240 seconds) |
00:11:02 | * | zepolen quit (Remote host closed the connection) |
00:12:36 | * | toaoMgeorge quit (Ping timeout: 276 seconds) |
00:22:09 | * | darkf joined #nim |
00:23:01 | * | vendethiel quit (Ping timeout: 244 seconds) |
00:24:46 | * | awsteele quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
00:33:56 | * | miko__ quit (Ping timeout: 250 seconds) |
00:36:55 | ldlework | proc calculateRegionPosition(index, atlas_width: int): tuple[x, y: int] = |
00:36:56 | ldlework | (index %% atlas_width, index /% atlas_width) |
00:37:19 | ldlework | It seems when atlas_width is 0 I can't "expect" with the unit-test any exception type |
00:40:59 | * | darkf quit (Ping timeout: 240 seconds) |
00:41:33 | * | darkf joined #nim |
00:46:26 | * | darkf_ joined #nim |
00:46:30 | * | darkf quit (Ping timeout: 250 seconds) |
00:46:38 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
00:47:21 | * | Kingsquee joined #nim |
00:51:29 | * | darkf_ quit (Ping timeout: 240 seconds) |
00:53:23 | * | darkf joined #nim |
00:58:49 | * | yglukhov joined #nim |
01:01:40 | * | darkf quit (Ping timeout: 250 seconds) |
01:02:59 | * | yglukhov quit (Ping timeout: 248 seconds) |
01:03:36 | * | darkf joined #nim |
01:03:41 | * | darkf quit (Changing host) |
01:03:42 | * | darkf joined #nim |
01:06:41 | * | darkf left #nim (#nim) |
01:11:37 | * | zepolen joined #nim |
01:16:24 | * | zepolen quit (Ping timeout: 250 seconds) |
01:16:40 | * | vendethiel joined #nim |
01:20:32 | * | OnwardEuler joined #nim |
01:22:53 | * | gokr quit (Quit: Leaving.) |
01:27:56 | * | Dre3ml0rd_ joined #nim |
01:32:08 | * | pregressive quit (Remote host closed the connection) |
01:32:15 | * | Jesin quit (Ping timeout: 244 seconds) |
01:35:50 | * | Dre3ml0rd_ quit (Remote host closed the connection) |
01:38:40 | * | Jesin joined #nim |
01:39:42 | * | vendethiel quit (Ping timeout: 276 seconds) |
01:51:38 | * | Dre3ml0rd_ joined #nim |
02:01:44 | * | pengowen joined #nim |
02:04:59 | * | cryptotoad joined #nim |
02:05:15 | cryptotoad | hey all, was wondering if Nim has a sendKeys like function? |
02:08:29 | * | Dre3ml0rd_ quit (Remote host closed the connection) |
02:08:38 | * | pengowen quit (Ping timeout: 252 seconds) |
02:09:27 | Araq | cryptotoad: what's that? |
02:10:39 | cryptotoad | like to press keys |
02:10:43 | cryptotoad | simulated typing |
02:11:00 | cryptotoad | for automation |
02:13:09 | * | zepolen joined #nim |
02:13:16 | * | Dre3ml0rd_ joined #nim |
02:15:53 | * | pregressive joined #nim |
02:16:44 | * | pengowen joined #nim |
02:17:29 | * | zepolen quit (Ping timeout: 240 seconds) |
02:19:31 | pengowen | hi |
02:20:12 | * | Dre3ml0rd_ quit (Quit: Mutter: www.mutterirc.com) |
02:21:37 | pengowen | I am trying to install the compiler on windows 7, but I get a gcc error if I try to compile a program. |
02:26:14 | * | cryptotoad quit (Ping timeout: 252 seconds) |
02:33:42 | * | pregressive quit (Remote host closed the connection) |
02:33:53 | * | vendethiel joined #nim |
02:38:02 | * | pengowen quit (Quit: Page closed) |
02:39:20 | * | pregressive joined #nim |
02:48:49 | * | brson quit (Quit: leaving) |
02:56:13 | * | vendethiel quit (Ping timeout: 255 seconds) |
03:00:12 | * | yglukhov joined #nim |
03:00:42 | * | Demos joined #nim |
03:04:35 | * | yglukhov quit (Ping timeout: 248 seconds) |
03:30:00 | * | lokien_ quit (Quit: Connection closed for inactivity) |
04:05:53 | * | pregressive quit (Remote host closed the connection) |
04:13:25 | * | endragor joined #nim |
04:13:25 | * | endragor quit (Remote host closed the connection) |
04:13:55 | * | endragor joined #nim |
04:14:42 | * | zepolen joined #nim |
04:14:47 | * | gmpreussner quit (Quit: kthxbye) |
04:17:02 | * | gmpreussner joined #nim |
04:18:59 | * | zepolen quit (Ping timeout: 240 seconds) |
04:19:59 | * | pleiosaur quit (Ping timeout: 240 seconds) |
04:19:59 | * | SirCmpwn quit (Ping timeout: 240 seconds) |
04:21:35 | * | pleiosaur joined #nim |
04:21:35 | * | SirCmpwn joined #nim |
04:22:59 | * | Kingsquee quit (Ping timeout: 248 seconds) |
04:26:12 | * | brson joined #nim |
04:26:40 | * | pregressive joined #nim |
04:43:54 | * | lxdong joined #nim |
04:50:20 | * | lxdong quit (Ping timeout: 252 seconds) |
04:52:38 | * | lompik quit (Ping timeout: 250 seconds) |
04:57:34 | * | Demos quit (Ping timeout: 240 seconds) |
04:58:11 | * | Demos joined #nim |
05:01:31 | * | yglukhov joined #nim |
05:03:34 | * | Demos quit (Ping timeout: 240 seconds) |
05:06:11 | * | yglukhov quit (Ping timeout: 248 seconds) |
05:08:22 | * | Demos joined #nim |
05:28:22 | * | endragor quit (Ping timeout: 244 seconds) |
05:51:06 | * | endragor joined #nim |
05:53:18 | * | pregressive quit (Remote host closed the connection) |
05:59:37 | * | brson quit (Quit: leaving) |
06:11:24 | * | jaco60 joined #nim |
06:16:11 | * | zepolen joined #nim |
06:18:36 | * | lxdong joined #nim |
06:20:29 | * | zepolen quit (Ping timeout: 240 seconds) |
06:22:08 | * | Demos quit (Ping timeout: 244 seconds) |
06:22:49 | * | vendethiel joined #nim |
06:30:28 | * | yglukhov joined #nim |
06:34:43 | * | yglukhov quit (Ping timeout: 248 seconds) |
06:41:38 | * | dmitry_p joined #nim |
06:45:44 | * | endragor quit (Remote host closed the connection) |
06:46:27 | * | vendethiel quit (Ping timeout: 248 seconds) |
06:48:54 | * | vendethiel joined #nim |
06:59:48 | * | endragor joined #nim |
07:03:22 | * | endragor quit (Remote host closed the connection) |
07:10:50 | * | jamesp joined #nim |
07:11:02 | jamesp | hi is there someone who could help me answer a question? |
07:11:22 | jamesp | my code is as follows: |
07:11:26 | jamesp | 11 import json as json |
07:11:35 | jamesp | 3 let 2 small_json = """{"test": 1.3, "key2": true}""" 1 jobj = json.parseJson(small_json) 0 jobj2 = parseJson(small_json) |
07:11:42 | * | vendethiel quit (Ping timeout: 244 seconds) |
07:12:05 | jamesp | why does parseJson(small_json) work when I only imported json as json |
07:12:18 | jamesp | I thought it only let using the dot way work |
07:12:48 | * | endragor joined #nim |
07:21:51 | * | Matthias247 joined #nim |
07:28:32 | lxdong | did you ask a question about performanc & GC yesterday? |
07:30:08 | lxdong | you left before someone could answer you. |
07:34:40 | lxdong | I swear to God if I could be sold...then I would be sold. |
07:36:24 | * | jamesp quit (Quit: Page closed) |
07:36:43 | * | jamesp joined #nim |
07:36:47 | jamesp | sorry i got logged out |
07:37:15 | jamesp | yeah so my question was why when i write import json as js i still get exposed to all the functions in json |
07:37:32 | jamesp | despite the docs saying i should have to call js.METHOD to call said METHOD |
07:41:50 | * | Matthias247 quit (Read error: Connection reset by peer) |
07:45:26 | lxdong | you must get up early |
07:48:45 | * | Kingsquee joined #nim |
07:50:36 | lxdong | proc parseJson*(buffer: string): JsonNode can be called like buffer.parseJson() or parseJson(buffer) but not js.parseJson(),you should read docs carefully. |
07:51:13 | * | yglukhov joined #nim |
08:08:30 | * | vendethiel joined #nim |
08:09:41 | * | jamesp quit (Quit: Page closed) |
08:10:05 | * | OnwardEuler quit (Ping timeout: 244 seconds) |
08:10:21 | * | jamesp joined #nim |
08:10:35 | jamesp | "A module alias can be introduced via the as keyword:" |
08:10:47 | jamesp | "The original module name is then not accessible. " |
08:16:13 | * | gokr joined #nim |
08:17:43 | * | zepolen joined #nim |
08:21:59 | * | zepolen quit (Ping timeout: 240 seconds) |
08:24:35 | * | allan0 quit (Ping timeout: 248 seconds) |
08:31:07 | * | miko__ joined #nim |
08:31:16 | * | vendethiel quit (Ping timeout: 244 seconds) |
08:32:32 | * | endragor quit (Remote host closed the connection) |
08:37:05 | lxdong | @gokr @jamesp who asked about GC trigger and performance is here ,you can answer him |
08:37:33 | gokr | Ehm, trying to remember the question... |
08:37:54 | * | endragor joined #nim |
08:38:15 | * | gokr1 joined #nim |
08:38:27 | * | endragor quit (Remote host closed the connection) |
08:38:30 | gokr1 | jamesp: What was the question? :) |
08:38:46 | gokr1 | Ah, if one could disable the GC, right? And control it. |
08:39:07 | * | endragor joined #nim |
08:39:44 | gokr1 | Yes, you can disable it alltogether - but that will also render a very large part of all standard libraries "useless", since they rely on it. However, as Araq often mentions, Nim would then still be a very good alternative to C. |
08:39:47 | jamesp | the question is |
08:39:57 | jamesp | no not garbage |
08:39:59 | gokr1 | But you can also control the GC in quite a lot of detail. |
08:40:05 | gokr1 | ok, shoot |
08:40:08 | * | jaco60 quit (Ping timeout: 250 seconds) |
08:40:11 | jamesp | in my code i have |
08:40:19 | jamesp | import json as js |
08:40:20 | jamesp | then |
08:40:36 | jamesp | let |
08:40:41 | jamesp | small_json = """{"test": 1.3, "key2": true}""" |
08:40:48 | jamesp | jobj = parseJson(small_json) |
08:40:59 | jamesp | why am i allowed to write this and not only allowed to write |
08:41:07 | jamesp | jobj = js.parseJson(small_json) |
08:41:49 | * | gokr quit (Ping timeout: 252 seconds) |
08:42:32 | jamesp | in the documentation for imports it says |
08:42:38 | jamesp | "A module alias can be introduced via the as keyword:" |
08:42:43 | jamesp | "The original module name is then not accessible. " |
08:43:16 | gokr1 | Right, but the imported names are accessible still. |
08:43:41 | jamesp | so in c++ speak, the root "namespace" is being polluted |
08:43:46 | jamesp | why is that? |
08:43:46 | * | Arrrr joined #nim |
08:44:22 | jamesp | like someone can just call a bunch of functions and as a reader i have no idea which package they came from |
08:44:46 | jamesp | that's why in say python i have to write json.parseJson |
08:46:21 | gokr1 | "It's also possible to use from module import nil if one wants to import the module but wants to enforce fully qualified access to every symbol in module." |
08:46:51 | jamesp | So I write from json import parseJson? |
08:48:09 | gokr1 | Eh, no, "from json import nil". |
08:48:14 | gokr1 | Btw, related: http://forum.nim-lang.org/t/1914 |
08:48:30 | jamesp | oh literally write nil |
08:48:35 | gokr1 | Forum has probably several threads worth looking at in this regard. |
08:49:09 | * | Trustable joined #nim |
08:49:15 | jamesp | ah cool |
08:49:20 | jamesp | and i get this error when i do that |
08:49:21 | gokr1 | I do know the module system in Nim is "debated" by a lot of users. Personally I can't say I have faced any real issues with it though, but... I have only written a few thousand lines of Nim so far. |
08:49:28 | jamesp | echo $jobj["test"].fnum |
08:49:39 | jamesp | "undeclared field: 'fnum'" |
08:54:17 | jamesp | how can i access the field fnum when importing as nil |
08:54:26 | jamesp | or from nil |
08:56:29 | * | allan0 joined #nim |
08:56:37 | * | toaoMgeorge joined #nim |
08:56:55 | BlaXpirit | jamesp, congrats on discovering one of the silliest parts of nim |
08:57:18 | BlaXpirit | you can write json.fnum(jobj["test"]) |
08:57:32 | jamesp | oh god |
08:57:38 | jamesp | this is disgusting... |
08:57:38 | BlaXpirit | i know right |
08:57:55 | BlaXpirit | jamesp, you have only these 2 disgusting options |
08:58:31 | BlaXpirit | (the other one is having everything global) |
08:58:39 | jamesp | i get an error with that too |
08:58:49 | jamesp | echo json.fnum($jobj["test"]) |
08:58:55 | jamesp | oh i need no $? |
08:59:21 | jamesp | undeclared identifier fnum |
08:59:24 | jamesp | is still there |
08:59:44 | gokr1 | It shouldn't be $ inside there. And you don't need it outside either, echo will do it on its own IIRC. |
08:59:57 | BlaXpirit | jamesp, I'm sorry, what I said is incorrect |
09:00:04 | BlaXpirit | fnum is an ordinary field |
09:00:13 | * | vendethiel joined #nim |
09:00:25 | jamesp | so how do you do this correctly? |
09:00:36 | BlaXpirit | maybe jobj["test"].fnum |
09:00:53 | jamesp | that's what i have |
09:01:00 | jamesp | ndeclared field: 'fnum' |
09:01:03 | jamesp | undeclared* |
09:01:12 | jamesp | from json import nil |
09:01:21 | jamesp | let |
09:01:27 | jamesp | small_json = """{"test": 1.3, "key2": true}""" |
09:01:32 | jamesp | jobj = json.parseJson(small_json) |
09:01:37 | jamesp | echo $jobj["test"].fnu |
09:02:01 | jamesp | fnum* |
09:02:58 | BlaXpirit | jamesp, correct code: echo json.`[]`(jobj, "test").fnum |
09:03:19 | BlaXpirit | (or just, you know, import json normally) |
09:04:03 | jamesp | ah that works now |
09:04:07 | jamesp | what are you doing there? |
09:04:25 | jamesp | are there plans to fix this lol? |
09:04:27 | BlaXpirit | calling the `[]` function of 2 arguments, which is defined in json module |
09:04:33 | jamesp | oh |
09:04:39 | jamesp | ok |
09:04:50 | BlaXpirit | if you write import json, this function is dumped into global namespace |
09:04:55 | jamesp | so like yeah are there plans to fix this ;). this is literally my first nim program. seems pretty obvious this is stupid |
09:04:58 | BlaXpirit | so you can write jobj["test"] |
09:07:25 | jamesp | Like what's wrong with pythonic imports? No need to re-invent the wheel here |
09:08:17 | Arrrr | What's the problem my friend? |
09:09:44 | BlaXpirit | jamesp, from x import nil does work like in python |
09:09:57 | BlaXpirit | the difference is that in python a class owns its methods |
09:10:01 | BlaXpirit | and in nim they're totally separate |
09:10:22 | BlaXpirit | jamesp, obj.stuff("arg") is merely syntax sugar for stuff(obj, "arg") |
09:10:56 | jamesp | oh so that's the problem |
09:11:07 | jamesp | are there proposals to fix *this* |
09:11:19 | BlaXpirit | jamesp, sure, proposals with no results |
09:11:31 | jamesp | just curious, why no results there :) |
09:11:41 | * | zepolen joined #nim |
09:11:51 | BlaXpirit | jamesp, there is a lot of details to argue about and difficult to implement |
09:12:17 | BlaXpirit | but main thing is the language's author thinks it's good |
09:12:20 | jamesp | yeah it's obviously very difficult to resolve. but seems like a pretty fundamental thing you'd want |
09:12:36 | jamesp | thinks the proposal is good? |
09:12:40 | * | reactormonk joined #nim |
09:12:44 | BlaXpirit | jamesp, thinks the current situation is good |
09:12:46 | jamesp | oh |
09:12:49 | jamesp | that's too bad.. |
09:13:25 | * | coffeepot joined #nim |
09:14:00 | jamesp | tbh with all these new languages they seem super awesome at first and then as you learn more you learn all these standard things that aren't quite right |
09:14:16 | BlaXpirit | sounds about right |
09:14:40 | BlaXpirit | nim is super awesome in many aspects |
09:15:57 | jamesp | BlaXpirit so you said this is one of the "silliest things" |
09:16:03 | jamesp | what else ranks up there for silly things |
09:16:07 | gokr1 | jamesp: Well, I guess it depends a bit on how you approach it. A lot of us has managed to write thousands of lines of Nim without getting "bitten" by these less wonderful corner cases. |
09:16:08 | jamesp | like give me your top 3 :) |
09:17:05 | jamesp | gokr1 in this particular case writing import json instead of import json as nil works great when you're playing around |
09:17:14 | jamesp | but if you want production level code it's not as nice |
09:17:23 | jamesp | you want namespace safety when you start to build a big system |
09:17:30 | BlaXpirit | it's no just "not nice", it's unacceptable |
09:17:33 | BlaXpirit | but oh well |
09:18:02 | * | ephja joined #nim |
09:18:08 | jamesp | my guess is not enough big systems have been attempted in nim then? |
09:18:43 | BlaXpirit | attempted maybe, but I don't see any impressive applications |
09:18:45 | jamesp | like even when you get to say 10,000 lines in one project you'll run into trouble with this import thing |
09:18:55 | BlaXpirit | i mean, the forum is pretty big, and Aporia IDE |
09:19:00 | BlaXpirit | and the compiler itself, you know |
09:19:01 | Arrrr | What's the problem again? |
09:19:31 | jamesp | The problem is 1) regular functionality goes away when you import you import BLAH as nil |
09:19:42 | jamesp | and 2) import BLAH as nil should be the default when you import BLAH |
09:19:59 | Arrrr | I didnt even know you could import stuff as nil, what does it do? |
09:20:11 | jamesp | stops the namespace from being polluted |
09:20:17 | jamesp | stops the default namespace that is |
09:20:22 | gokr1 | Not "as nil" |
09:20:28 | jamesp | and puts the functions of the module into the namespace BLAH |
09:20:34 | Arrrr | Ah, you mean like import myNameSpace as NS ? |
09:20:37 | jamesp | oh sorry |
09:20:38 | gokr1 | "From json import nil" |
09:20:44 | jamesp | from BLAH import nil |
09:20:46 | jamesp | yeah |
09:20:47 | jamesp | my bad |
09:20:48 | Arrrr | Ah, ok. |
09:20:55 | Arrrr | Like from strutils import split |
09:21:27 | jamesp | that explicitly would put split in the default namespace correct? |
09:21:34 | jamesp | that's OK if it's explicit at the top of the file |
09:21:55 | jamesp | but you also want to be able to import everything from a module without polluting the default |
09:21:56 | gokr1 | I am also guessing the intricacies here has to do with C and how libraries are dealt with etc. |
09:22:24 | Arrrr | I dont get your "everything without polluting" |
09:22:29 | jamesp | Oh yeah I'm brand new don't get me wrong this could be a really hard problem.. not proposing a specific implementation detail |
09:22:31 | * | vendethiel quit (Ping timeout: 252 seconds) |
09:22:34 | jamesp | so if i write import json |
09:22:41 | jamesp | i can then use all the functions in json directly |
09:22:53 | coffeepot | Perhaps we just need a setting to choose if you want import as nil or normal import as default |
09:23:00 | gokr1 | jamesp: You might want to search the forum a bit, I am fairly sure there are TONS of threads regarding imports and modules. |
09:23:03 | jamesp | such as parseJson |
09:23:22 | jamesp | but I want it to be the case that in order to call parseJson I must write json.parseJson |
09:23:41 | Arrrr | you want to force the use of the module you mean? |
09:23:44 | jamesp | so that i hint at any reader of my code (including my future self) what i'm doing |
09:23:47 | * | allan0 quit (Ping timeout: 248 seconds) |
09:23:56 | jamesp | yeah so in python you can do three things |
09:23:58 | jamesp | import BLAH |
09:24:01 | jamesp | from BLAH import foo |
09:24:05 | jamesp | or from BLAH import * |
09:24:24 | jamesp | (also import BLAH as BL but that's just a special case) |
09:24:35 | jamesp | it's bad python to write from BLAH import * |
09:24:40 | Arrrr | And i assume form x import * forces you to write blah.bleh ? |
09:24:47 | jamesp | no |
09:24:53 | jamesp | exactly the opposite |
09:24:55 | gokr1 | jamesp: Do note though that ... there are different views on what is best/right. |
09:24:57 | jamesp | import BLAH forces |
09:25:11 | Arrrr | Ok, now i get it. |
09:25:13 | jamesp | from BLAH import * is the regular nim import |
09:25:42 | jamesp | gokr1 I'm pretty sure you'd be hard pressed to find a large number of python developers who recommend using from BLAH import * everywhere |
09:25:53 | jamesp | I've actually never seen that used outside of a quick and dirty script |
09:25:57 | gokr1 | jamesp: I am not talking about Python. |
09:26:05 | jamesp | It doesn't matter what the language is |
09:26:11 | jamesp | the namespace principle transcends language choice |
09:26:28 | gokr1 | Well... I wouldn't state that so categorically. |
09:26:50 | jamesp | In this case I'm pretty sure you can say this with very high confidence. |
09:26:51 | gokr1 | Depending on how many languages you have used of course. |
09:26:52 | coffeepot | i think personally I'd find it annoying if say, import tables meant I had to write var x: tables.Table every time. It'd be nice if you could choose how you want the default though if you were being strict (as in large projects) |
09:26:55 | Araq | jamesp: use 'from foo import nil' to be forced to write 'foo.bar' everywhere |
09:27:24 | gokr1 | Araq: But he gets into trouble with say `[]` etc |
09:27:33 | jamesp | i don't want to have to enumerate from foo import nil, nil1, nil2, nil3 and go find everything |
09:27:39 | jamesp | oh nil |
09:27:42 | jamesp | yeah gokr1's point |
09:28:02 | coffeepot | how would you specifiy []'s module in python |
09:28:11 | Araq | so the universal "namespacing rule" doesn't apply to [] ? |
09:28:11 | jamesp | Araq: the way I import shouldn't affect my code so deeply |
09:28:13 | gokr1 | jamesp: I don't want to sound rude, but IMHO there are different models and solutions around modules/namespaces. |
09:28:30 | jamesp | OK sure there are different models that work. This one doesn't |
09:28:54 | gokr1 | jamesp: Stating "general truths" is a dangerous practice. |
09:28:57 | jamesp | Not Python, C++, java all share this |
09:29:10 | jamesp | I've never seen a language not do this actually |
09:29:21 | jamesp | anyway |
09:29:22 | gokr1 | Well, then you may not have used that many languages. |
09:29:32 | jamesp | I mean yeah I've only used like 10 |
09:29:47 | jamesp | And in terms of percent of code in existence |
09:29:53 | jamesp | I've used like 80-90% |
09:29:57 | jamesp | maybe 70 |
09:29:59 | jamesp | idk exactly |
09:30:04 | jamesp | but enough to know the principle here |
09:30:19 | vegansk | Araq, hi! I patched treads.nim to use _beginthreadex API, but this doesn't resolve crashes on mingw. Checked on mingw-w64 with gcc 4.9.1 and vanilla mingw with gcc 4.9.3 |
09:30:21 | jamesp | anyway don't make this ad hominem |
09:30:41 | gokr1 | I am not, I just get weary when people claim truths. |
09:30:42 | Araq | I've written and seen enough Nim code to know it works, Nim is not Java. And Java doesn't work as you think it does anyway. |
09:30:56 | jamesp | huh? |
09:31:14 | gokr1 | (not making it ad hominem I mean) |
09:31:14 | Araq | Otherwise Java code would be full of package.foo() but it doesn't, it's full of obj.foo(). |
09:31:23 | jamesp | sorry the huh was to araq |
09:31:33 | gokr1 | sure, I know. Just clarifying. |
09:31:39 | jamesp | and how do you initialize the obj :) |
09:31:52 | gokr1 | I am a Smalltalker for example, and modules/namespaces etc work quite differently there. |
09:32:07 | Araq | StringBuffer s = new StringBuffer(); |
09:32:16 | jamesp | And at the top of the file |
09:32:26 | jamesp | you write where you got StringBuffer :) |
09:32:33 | jamesp | so there's a direct link in the code |
09:32:36 | jamesp | made explicit for you |
09:32:42 | Araq | lol as if somebody would read that |
09:32:43 | coffeepot | jamesp but you can do that in nim |
09:32:56 | jamesp | with the json module how do I do this? |
09:32:56 | * | allan0 joined #nim |
09:33:07 | jamesp | and in java after i have this object |
09:33:11 | jamesp | i can reference the field member |
09:33:16 | jamesp | which we just said I can't do here in nim |
09:33:18 | Arrrr | In java ides after x imports write import bla.ble.*; |
09:33:24 | jamesp | I have to do the `[]` |
09:33:47 | jamesp | yeah but the point is I know the type of s. It's StringBuffer |
09:34:01 | jamesp | and so when I call s.BLAH, I know that BLAH is coming from a StringBuffer |
09:34:10 | jamesp | when I import json and then call some function there |
09:34:20 | jamesp | I don't know which of my imports that function is coming from |
09:34:40 | Arrrr | But that happens the most popular languages, c# and java |
09:34:45 | Araq | in Java you use an IDE to navigate. In Nim you can do the same. |
09:34:54 | jamesp | it's not about the IDE |
09:35:03 | Araq | surely it is. |
09:35:15 | jamesp | no because I don't need to IDE to see that s was declared as StringBuffer |
09:35:15 | Araq | nobody reads Java's import lists for exactly this reason. |
09:35:20 | jamesp | I don't need to read the imports |
09:35:28 | jamesp | I know where StringBuffer comes from |
09:35:35 | gokr1 | eh. |
09:35:39 | jamesp | StringBuffer is sufficient context for me to know where it's being imported from |
09:36:01 | jamesp | I know this is java.lang.StringBuffer |
09:36:15 | Araq | I know JsonNode is json.JsonNode. |
09:36:16 | gokr1 | How do you? What about Date? |
09:36:29 | jamesp | Yes but StringBuffer is just one class |
09:36:38 | jamesp | I don't have to learn that for every member method! |
09:36:47 | Arrrr | So, you dont like defining several types in one module? |
09:36:50 | jamesp | You have to learn that about every member method of the json module |
09:37:00 | jamesp | i'm talking about methods |
09:37:21 | jamesp | like the parseJson method |
09:37:27 | coffeepot | so, it's okay for StringBuffer, but not for other things? |
09:37:30 | Arrrr | if you import x, you dont have to care about that. I dont know what's the issue |
09:37:41 | jamesp | It's ok for stringbuffer because stringbuffer is only one name |
09:37:53 | jamesp | i don't do that for every method in the stringbuffer class |
09:38:07 | coffeepot | why not? |
09:38:14 | jamesp | Say somebody writes import json |
09:38:20 | jamesp | then later in their code they write |
09:38:33 | jamesp | jobj = parseJson(small_json) |
09:38:57 | jamesp | i have to figure out where parseJson came from (in this case it's easy because json is in the name but it's often not) |
09:38:59 | reactormonk | Do we still support XP? https://github.com/nim-lang/nimsuggest/issues/20 |
09:39:15 | jamesp | in java i'd write |
09:39:21 | Arrrr | But in python you dont explicit declare types and is not a problem there |
09:39:21 | coffeepot | so then you tell people to prefix the module.parseJson? |
09:39:22 | jamesp | StringBuffer s = new StringBuffer() |
09:39:29 | jamesp | in python it's easy |
09:39:31 | jamesp | i write import json |
09:39:37 | jamesp | then I MUST write json.parseJson |
09:39:37 | coffeepot | this sounds more like a personal code review situation |
09:39:44 | jamesp | parseJson isn't in the namespace |
09:39:59 | reactormonk | jamesp, from json import parseJson |
09:40:19 | Araq | C doesn't even have namespaces and billions of lines of production code are written in it. So much for that "Universal principle" (that isn't followed by *any* language anyway). |
09:40:25 | Arrrr | i thought the inet_top thing was resolved already |
09:40:32 | jamesp | C is 21st centure assembly |
09:40:38 | jamesp | turing machines don't have namespaces either |
09:40:48 | jamesp | like come on |
09:41:07 | jamesp | reactormonk: i don't want to have to explicitly import every function i care about |
09:41:17 | jamesp | I want to just write import json |
09:41:24 | Araq | jamesp: then don't! ;-) |
09:41:39 | jamesp | i think you're missing the point |
09:41:41 | Araq | reactormonk: we surely try to support XP |
09:41:55 | gokr1 | I am not a Python guy, but how does Python handle things like `[]`? |
09:42:01 | jamesp | how do you import all functions from a module into a namespace? |
09:42:07 | Araq | I know your point perfectly well, I have heard this argument thousands of times by now. |
09:42:22 | coffeepot | import module as new_namespace isn't it? |
09:42:23 | jamesp | like this is a very common thing people want to do |
09:42:44 | jamesp | how do i import everything into a namespace and not into the common namespace without changing my code |
09:42:45 | Arrrr | reactormonk https://github.com/nim-lang/Nim/pull/3787 |
09:43:25 | reactormonk | Arrrr, cool, thanks |
09:43:25 | jamesp | from json import nil makes you change the code |
09:43:40 | jamesp | echo json.`[]`(jobj, "test").fnum is not very readable |
09:43:57 | Araq | from json import `[]` |
09:44:11 | Araq | also you argue that it is readable. ;-) |
09:44:20 | Araq | because you like full qualifications. |
09:44:40 | Araq | and so you don't have to search where [] comes from. etc etc etc |
09:44:51 | jamesp | That's now too verbose |
09:44:56 | gokr1 | (and I don't like full qualifications) |
09:45:05 | jamesp | The point is to get the best of both worlds |
09:45:08 | jamesp | and here you can't |
09:45:20 | coffeepot | how is that too verbose, it's one import statement at the top? |
09:45:20 | jamesp | you have to choose between the benefits of the qualifications and benefits of not having them |
09:45:26 | jamesp | i want to have my cake and eat it too |
09:45:28 | Araq | the point is that you're totally arbitrary. |
09:45:30 | jamesp | as i would in python |
09:45:41 | jamesp | In practice this is not arbitrary at all |
09:45:50 | coffeepot | jamesp how do you do this in python? |
09:45:51 | jamesp | The module has several functions that are related |
09:45:54 | jamesp | in python |
09:45:58 | jamesp | I write import json |
09:45:59 | Araq | import json except JsonNode |
09:46:00 | jamesp | done |
09:46:06 | Arrrr | I recall that i suggested a {.pure.} for when importing modules. |
09:46:16 | Araq | var j: json.JsonNode # woohhoo like in Python |
09:46:30 | Araq | j["foo"] = "bar" #wooohoo like in Python. |
09:46:40 | jamesp | yeah now you have to name what you're importing |
09:46:45 | jamesp | i shouldn't have to name that in the imports |
09:46:57 | jamesp | i'm importing the full module because things in the module like to be imported together |
09:47:03 | jamesp | that's why they belong in a common module |
09:47:15 | jamesp | so it makes sense to import the full thing without being explicit about which part |
09:47:30 | Araq | nothing of this makes any sense. |
09:47:39 | flyx | so what exactly is your problem with „from json import nil“? |
09:47:44 | jamesp | Why do C++ and python do it this way then? |
09:47:46 | jamesp | and java |
09:47:49 | Araq | either you have decent tooling to navigate through large code bases |
09:47:53 | Araq | or you don't. |
09:47:54 | jamesp | from json import nil break |
09:48:00 | Arrrr | lol, we are making the same question to jamesp. |
09:48:01 | jamesp | echo $jobj["test"].fnum |
09:48:09 | Araq | and language design cannot patch over broken tooling. |
09:48:20 | jamesp | you now have to write |
09:48:21 | jamesp | echo json.`[]`(jobj, "test").fnum |
09:48:27 | jamesp | apparently |
09:48:36 | gokr1 | Araq: Did I mention the funky module system I devised in Smalltalk a few years back? |
09:49:20 | flyx | well. Ada has „use type foo“ to import all inline functions of the given type in the standard namespace. I haven't seen this anywhere else though |
09:49:38 | gokr1 | I was quite pleased with it - but... alas it never got accepted. Too much legacy friction, people are scared of change ;) |
09:50:56 | jamesp | So there isn't this huge debate about python namespaces because they figured out the problem and solved it correctly. now they focus on other problems in the language |
09:51:33 | jamesp | Anyway having things go into the default namespace breaks of a lot of safety concerns |
09:51:52 | gokr1 | It was based on an idea that people have a knee jerk reaction against, the idea that we almost always "render" source code (highlighting, folding etc), so we could actually dynamically render "full qualifications" as short as possible. |
09:51:58 | Araq | yeah sure, for some definition of "safety" that you just pulled out of your ass. |
09:52:15 | jamesp | Not at all. Say I define a function foo |
09:52:19 | jamesp | and i mispell calling it |
09:52:25 | jamesp | i accidently call food |
09:52:32 | jamesp | but food has been defined by my import |
09:52:37 | jamesp | and it suddenly calls food |
09:52:40 | Araq | so let's start a buzzword fight: Nim's way actually encourages loose coupling where things can move more freely around. |
09:52:57 | jamesp | could you explain what you mean by that? |
09:53:03 | flyx | the difference between Python and Nim is that Nim does type checking, so you usually don't accidentally call a function you don't want to, because the param types do not match |
09:53:11 | Arrrr | Btw reset shouldn't be in system, you can have accidents there. |
09:53:19 | jamesp | i agree python is very unsafe in many ways |
09:53:30 | jamesp | i'm not arguing python is safe :) |
09:53:51 | jamesp | or that python is the best language or anything like that |
09:54:01 | jamesp | i'm saying in the case of modules, python does things very well |
09:54:28 | jamesp | sorry Araq what does loose couplings mean here? |
09:54:36 | Araq | and here is the thing: Nim is not Python, and Python's solution would be a disaster for Nim. |
09:54:53 | jamesp | Could you explain why? It'd be interesting to hear |
09:55:04 | jamesp | (just the namespace part of python not other things) |
09:55:12 | Araq | and fyi I use 'from foo import *' everywhere in Python. |
09:55:41 | jamesp | Haha I can't endorse that |
09:56:18 | jamesp | So why would using namespaces in the python way be a disaster in nim? |
09:56:18 | Araq | jamesp: I refactor code, when refactoring code I move things around and don't want to patch 'module.foo' into 'moduleB.foo' all the time |
09:56:39 | jamesp | In this case you create a tool that does it for you |
09:56:57 | jamesp | So like is the refactoring the reason? |
09:57:03 | jamesp | Or is there something more fundamental |
09:57:45 | jamesp | Like actually I think the real question I want to ask is |
09:58:02 | jamesp | Why when you write "from json import nil" |
09:58:13 | jamesp | why would it be bad to allow this to still work: |
09:58:19 | jamesp | echo $jobj["test"].fnum |
09:58:47 | coffeepot | well can you do from json import nil AND import `[]` from json? |
09:59:13 | * | allan0 quit (Ping timeout: 255 seconds) |
09:59:14 | jamesp | could you explain the [] part? |
09:59:18 | jamesp | I don't think i fully understand it |
09:59:28 | gokr1 | It's the indexing operator. |
09:59:40 | gokr1 | It's just a function, like other functions. |
09:59:48 | gokr1 | But with a funky name. |
10:00:29 | Araq | Python only gets away with it because it attaches methods to classes and so importing the class gives you all the methods too. Nim doesn't attach procs to types and so what is a class in Python is usually a *module* in Nim. |
10:00:46 | Araq | and that's why we like to import *everything* from the *module*. |
10:00:59 | Araq | I don't understand why it is so hard to see that. |
10:01:41 | * | Arrrrr joined #nim |
10:01:56 | jamesp | Araq: if it only the [] part that breaks when you write from json import nil? |
10:02:04 | * | Arrrr quit (Ping timeout: 240 seconds) |
10:02:14 | jamesp | or are there other problems wirht from json import nil? |
10:02:16 | Araq | from json import `[]` |
10:02:23 | jamesp | sorry yeah |
10:02:39 | Araq | works too and lets you use [] like you want and requires qualification for the other things |
10:03:01 | jamesp | Why is it [] that I have to import to access dot fnum? |
10:03:07 | jamesp | I don't really understand this part |
10:03:13 | Araq | I don't know why 'from json import nil' should mean 'from json import `[]`' |
10:03:31 | gokr1 | jamesp: It's not for fnum, its for the ob["blabla"] part. |
10:03:36 | jamesp | no writing both |
10:03:42 | jamesp | ah ok gokr1 |
10:03:57 | jamesp | ohhh i see |
10:04:20 | jamesp | so dictionary lookup is something you have to explicitly import |
10:04:23 | gokr1 | But as BlaXpirit showed, you can actually call [] using regular function syntax too, so that you can qualify it. |
10:04:24 | jamesp | it's not there by default |
10:04:32 | jamesp | yeah i see that |
10:04:50 | jamesp | so tbh this is more of a question about [] and less about modules right? |
10:05:01 | coffeepot | yes sounds like it |
10:05:04 | gokr1 | Do note that [] is a function like any other function. They are overloaded per types etc. You can define your own. |
10:05:05 | coffeepot | or even more specifically |
10:05:18 | coffeepot | this is more a question on how operators are overloaded in nim |
10:05:22 | jamesp | so in other languages [] is special cased right? |
10:05:32 | jamesp | this is making a lot more sense |
10:05:38 | gokr1 | Well, again, it depends on how many languages you have used :) |
10:05:46 | Araq | no, the only question is why 'Python class corresponds roughly to Nim module' is so hard to accept. |
10:05:47 | jamesp | OK I'm thinking this is less of a problem than I originally thought :) |
10:06:00 | * | allan0 joined #nim |
10:06:06 | coffeepot | you can create your own operators in nim, eg proc `&%`(a: myType) etc |
10:06:13 | jamesp | I'm just using python as an example, and focusing on the module part, not the class part |
10:06:15 | coffeepot | `[]` is just one example |
10:06:26 | endragor | Araq: I think you are actually answering a different question. There is a simple misunderstanding of operator overloading from jamesp. |
10:07:03 | jamesp | endragor: there are two questions here. both a misunderstanding from me and the question araq is answering |
10:07:39 | jamesp | OK so I suppose in the languages I've experienced |
10:07:50 | jamesp | When you do the equivalent of from json import nil |
10:08:00 | jamesp | functions like [] are put into the default namespace |
10:08:17 | jamesp | and more standard functions such as parseJson are put into the json namespace |
10:08:38 | jamesp | In that sense [] is special cased elsewhere... |
10:08:43 | endragor | no, in case with python, it's __getitem__ function that is tied to the type. so when you import the type, the function is imported |
10:09:02 | endragor | in Nim procedures are not tied to types |
10:09:24 | jamesp | endragor: in python [] is part of dictionaries which are imported everywhere no need for a statement |
10:09:27 | jamesp | right? |
10:09:28 | coffeepot | that's because you're importing a type in python, where [] is part of the type. In nim, it's all procs that take particular types as params, so you have to import the [] as well |
10:10:17 | jamesp | no in python you'd use a dictionary not a json "type" |
10:10:18 | endragor | jamesp: no, [] can be overloaded in Python, too |
10:10:23 | jamesp | oh ok i see what you're saying |
10:10:34 | jamesp | so if [] is overloaded by the type in question |
10:10:40 | jamesp | you still don't have to write import []? |
10:10:44 | jamesp | that's the point |
10:10:46 | endragor | yes, because it's in the type |
10:11:00 | jamesp | sometimes we're talking about a dictionary and it's a moot point |
10:11:05 | jamesp | but when we're not ah |
10:11:22 | jamesp | OK I withdraw most of my criticism :) |
10:11:30 | coffeepot | dicts are in the default namespace in python iirc, whereas in nim you have to import tables to use dict |
10:11:33 | jamesp | With the caveat that I think import json as nil should be the default |
10:11:40 | jamesp | from json import nil |
10:11:41 | jamesp | sorry |
10:11:57 | Araq | jamesp: yeah, beginners tend to think that. ;-) |
10:12:07 | coffeepot | and in tables sure enough there is a proc `[]`[A, B](a: A, b: B) |
10:12:07 | jamesp | haha fair |
10:12:16 | * | allan0 quit (Ping timeout: 255 seconds) |
10:12:17 | jamesp | Araq why do you think beginners believe that? |
10:12:51 | jamesp | So I guess my claim is based on safety and code navigation |
10:13:00 | Araq | because you're really not special. ;-) |
10:13:09 | jamesp | I can understand the safety claim is a weak one because the static typing gives you enough safety |
10:13:37 | Araq | people come from Python where "omg, he is a nazi because he used 'from foo import *'" is universally accepted |
10:13:39 | jamesp | Araq: sorry not asking if i'm special. why do beginners tend to get this wrong? |
10:13:51 | jamesp | Yes i understand that |
10:13:54 | jamesp | but specifically |
10:13:58 | jamesp | Why is it OK to do this? |
10:13:58 | Araq | and then they notice it's the DEFAULT in Nim |
10:14:07 | Araq | that can't be right!!! |
10:14:17 | jamesp | Yeah so why do you think that it's good for reference |
10:14:27 | Araq | in other words: Everybody argues exactly like you do. |
10:14:29 | jamesp | Like your argument is an argument that should apply to python too? |
10:14:31 | jamesp | right |
10:14:42 | coffeepot | jamesp, beginners almost by definition are used to what they've experienced and not what they haven't |
10:14:53 | jamesp | No this is a different point coffeepot |
10:15:05 | jamesp | Like Araq is saying that in python from BLAH import * is good too |
10:15:23 | jamesp | (and he literally said this earlier so he's being self-consistent) |
10:15:45 | jamesp | So like I guess my question is why do you think from BLAH import * is good in python? Common knowledge is that it's bad |
10:15:50 | Araq | well I often like procedural style over OO |
10:16:13 | jamesp | Why is procedural vs OO related here? |
10:16:15 | Araq | so my Python style is more like 'free floating defs everywhere' |
10:16:25 | Araq | not attached to a class |
10:16:29 | jamesp | Like you could have procedural with namespaces though |
10:16:37 | Araq | and then Python's import foo is annoying |
10:16:45 | Araq | I use 'from foo import *' |
10:16:51 | jamesp | So let's say we're 100% in procedural land |
10:16:56 | Araq | and I can move defs around then. |
10:16:58 | endragor | jamesp: "non-safety" point is more minor for Nim, because it has static typing. It's waaay easier to make a mistake in Python by calling what you not intended to call. In Nim you will get an error in the same case. Writing "JsonNode" instead of "json.JsonNode" helps brevity and readability of the code. |
10:17:06 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
10:17:09 | jamesp | yeah i agree the non-safety point is minor |
10:17:15 | jamesp | endragor: i think that's exactly right |
10:17:25 | Araq | jamesp: and coming back to the refactoring argument. |
10:17:30 | jamesp | but my point is that json.JsonNode is more readable even when you throw out the safety argument |
10:17:40 | jamesp | So like you could make a tool that does this for you |
10:17:56 | jamesp | Like intellij does this in java land |
10:18:00 | Araq | there is a difference between 'goto definition' and *modify* this piece of code for me. |
10:18:04 | jamesp | So I can't really believe that'd the reason |
10:18:16 | jamesp | that'd be* |
10:18:26 | Araq | the modifications end up in the git history, for example. |
10:18:41 | Araq | plus it's harder to write a tool that does it reliably. |
10:18:49 | jamesp | oh ok |
10:18:54 | Araq | of course I like to have these tools. |
10:18:55 | jamesp | that's fair |
10:19:06 | jamesp | the git history thing is something the tool doesn't solve |
10:19:20 | Araq | but nevertheless code modifications are more disruptive than simply helping me to navigate. |
10:19:39 | jamesp | OK this looks like less of a problem than I thought |
10:19:44 | jamesp | OK quick unrelated question |
10:19:56 | jamesp | What kinds of performance benchmarks does nim get for super low latency stuff |
10:20:03 | jamesp | Like when you care about nanseconds |
10:20:23 | * | allan0 joined #nim |
10:20:41 | jamesp | So say I'm writing a program that allocates memory on initialization. And then while it's running during the day never again allocated memory |
10:21:01 | jamesp | And I want to get down to the hundreds of nanos per "event processed" |
10:21:12 | jamesp | Will nim be competitive with C here? |
10:21:25 | Araq | yeah, highly competitive |
10:21:37 | jamesp | And how would I in nim have it never call the GC? |
10:21:49 | jamesp | I want to totally turn off the GC and yell at me if I try to allocate too much memory |
10:21:52 | Araq | and you don't even have to watch out for allocations all that much since the GC adheres to the deadlines you give it |
10:22:05 | Araq | *you give to it |
10:22:16 | * | toaoMgeorge quit (Read error: Connection reset by peer) |
10:22:21 | jamesp | So is it always crystal clear when I'm allocating memory? |
10:22:26 | jamesp | like in C it's SUPER clear |
10:22:40 | jamesp | I want to be able to write a large amount of code that I know for sure doesn't allocate anything new to the heap |
10:22:49 | Araq | yeah right because you don't use function calls in C ;-) |
10:23:02 | jamesp | OK it's not literally 0 |
10:23:07 | jamesp | but like that gets collected for me |
10:23:12 | jamesp | Like it's really low :) |
10:23:23 | Araq | in Nim the allocations are hidden pretty much the same way they are in C, IMHO. |
10:23:36 | jamesp | ah ok |
10:23:45 | jamesp | haha for context the problem i just described is that of hft |
10:23:46 | Araq | except that you will argue that they are hard to spot |
10:24:00 | jamesp | you're saying they're not hard to spot? |
10:24:01 | Araq | because you don't know Nim as well as you C |
10:24:05 | jamesp | oh sure |
10:24:07 | jamesp | fair |
10:24:30 | jamesp | in regular imperative land are function calls the only thing that go on the heap? |
10:24:56 | reactormonk | jamesp, in imperative land you have no guarantee whatsoever what the function you call does. |
10:25:15 | jamesp | reactormonk: what exactly do you mean? |
10:25:21 | Araq | jamesp: --gc:none tells you where you used allocations |
10:25:26 | dom96 | Hello jamesp. I tried my best to read most of the IRC logs, and all I can really do now is reassure you that the Nim way works well. You have nothing to worry about when using the default 'import json' syntax. |
10:25:58 | jamesp | haha point taken |
10:26:33 | dom96 | I guess these guys have done a lot to convince you already. But let me convince you more: I've written Aporia, Nimble, NimForum, Jester and a lot of other Nim projects. Have I ever written `from json import nil`? No. |
10:26:51 | Araq | dom96: we have moved on. |
10:27:05 | jamesp | Araq: --gc:none means that you just get allerted or that the gc does nothing altogether? |
10:27:25 | dom96 | Araq: Good :) |
10:27:35 | Araq | jamesp: it disables the GC at runtime which is not that useful. |
10:27:54 | Araq | however, it also makes the compiler complain where you depend on the GC |
10:27:55 | jamesp | "not that useful" depends on your application :) |
10:28:10 | jamesp | so it still does gc for function calls though |
10:28:11 | jamesp | ? |
10:28:14 | Araq | so there is a compiletime checking aspect to it that's more useful |
10:28:42 | jamesp | cause you said function calls go on the heap |
10:28:52 | Araq | no no no. |
10:29:06 | Araq | I said in C allocations can be hidden in functions. |
10:29:20 | Araq | and they can in Nim too. |
10:29:29 | jamesp | So when you mark --gc:none |
10:29:36 | jamesp | What happens when you repeatedly call a function? |
10:30:23 | Araq | it gets a fresh stack frame repeatedly, same as in C |
10:30:41 | jamesp | So it won't run out of memory? |
10:30:49 | jamesp | on IN functions |
10:30:53 | jamesp | not by calling the function |
10:31:06 | Araq | my point was that in C it's not "super obvious" where the allocations are. |
10:31:11 | jamesp | oh ok |
10:31:25 | Araq | as C code consists mostly of function calls and functions can internally use 'malloc' |
10:31:41 | jamesp | and that malloc is automatically freed for you? |
10:31:51 | jamesp | So what happens in nim when you have function calls and --gc:none |
10:31:56 | jamesp | does that get freed for you? |
10:32:14 | Araq | yes, if the function doesn't use the GC. |
10:32:23 | jamesp | ah |
10:32:27 | jamesp | soooo in conclusion |
10:32:33 | jamesp | nim is very suited for high frequency trading |
10:32:43 | jamesp | that's my takeaway from the gc discussion |
10:32:55 | Araq | good, but it's more complex than that. |
10:33:10 | jamesp | haha of course |
10:33:15 | jamesp | what do you mean by more complex than that? |
10:33:35 | Araq | 1. the stdlib uses the GC. it's counterproductive to avoid the stdlib but not worse than C where you barely have a stdlib. |
10:33:51 | jamesp | the nim stdlib uses gc? |
10:34:00 | jamesp | ah |
10:34:05 | Araq | and the other libraries you can get for the C, you can use from Nim too ... soo no loss. |
10:34:30 | * | gmpreussner quit (Read error: Connection reset by peer) |
10:34:40 | jamesp | but using objects doesn't invoke the gc? |
10:34:43 | Araq | 2. the GC is a realtime GC, adhering to the deadlines you give to it. |
10:34:45 | * | zepolen quit (Remote host closed the connection) |
10:34:47 | jamesp | like general nim syntactic sugar |
10:35:06 | jamesp | So in the C code I write, I don't use the gc |
10:35:09 | * | zepolen joined #nim |
10:35:10 | jamesp | it would be too slow |
10:35:28 | jamesp | other than these function calls |
10:36:05 | Araq | 3. since the GC is per thread there are plans to have "GC free" threads which replace the GC with region based memory management under the hood. |
10:36:20 | * | gmpreussner joined #nim |
10:36:29 | jamesp | ah ok |
10:36:32 | jamesp | very nice |
10:36:44 | Araq | note that for 3. you can use all of Nim's stdlib. |
10:37:00 | jamesp | What are the costs of 3? |
10:37:13 | * | toaoMgeorge joined #nim |
10:37:28 | Araq | harder to ensure memory consumption stays reasonable. |
10:37:31 | jamesp | ok |
10:37:40 | jamesp | So in the C code that we write |
10:37:50 | jamesp | We do little tricks like make sure the structs are cache aligned |
10:37:55 | gokr1 | Araq: This "function calls go on the heap"... the Nim stack is the C stack, or is there something I am missing? There is no heap involved in that, right? |
10:38:15 | jamesp | can you do these in nim? |
10:39:32 | Araq | jamesp: yes and 'object' maps to struct, it's not allocated on the heap. |
10:39:42 | jamesp | ok |
10:40:17 | Araq | gokr1: right. |
10:40:21 | jamesp | do you have a guess for how long it'll take to have a 1.0 that's accurate to within a factor of 2? :) |
10:41:43 | gokr1 | jamesp: On the other hand you often use "ref object" (not just "object") and then its allocated on the heap. Up to you, what you need. |
10:41:52 | jamesp | yeah |
10:41:57 | jamesp | mhm |
10:42:11 | gokr1 | I wrote a whole series of articles about OO in Nim, on my blog. |
10:42:39 | * | lokien_ joined #nim |
10:43:48 | jamesp | gokr is this your blog http://goran.krampe.se/ |
10:44:00 | gokr1 | Yeah, check http://goran.krampe.se/category/nim |
10:44:02 | jamesp | lol i read those today :) |
10:44:06 | gokr1 | Oh :) |
10:44:35 | coffeepot | jamesp don't forget you can always look at the generated C code with nim to understand what it's doing |
10:45:49 | jamesp | Araq said nim is competitive with C in speed. What makes it competitive? Being compiled to C isn't enough. OCaml for example is not competitive and it compiles to C |
10:46:52 | Araq | jamesp: I try to make no claims about when v1.0 will be ready. but I can assure you that we already have a good "how hard is it to upgrade old code" story. |
10:47:21 | jamesp | oh you're saying once you get to 1.0 it's hard to make improvements? |
10:47:40 | jamesp | haha Araq not asking for any guarantees! just curious if it's like 1 year or 2 years or 5 years or 10 years |
10:48:38 | jamesp | Also you should get nim onto the language benchmarks game! |
10:50:15 | Araq | jamesp: we have lots of benchmarks where Nim is on par with C |
10:50:28 | jamesp | Yeah I just mean to get attention |
10:50:42 | jamesp | People pay attention to that website |
10:50:44 | * | lxdong quit (Quit: Page closed) |
10:50:56 | Araq | and no Ocaml doesn't generate C code |
10:51:19 | jamesp | isn't it interpreted by a C compiler? |
10:51:49 | Araq | Ocaml has its own native code backend |
10:52:05 | jamesp | So why do people say it goes through C? |
10:52:05 | Araq | as well as an interpreter for quick development. |
10:52:32 | jamesp | My PL prof from college said it went through C in some way |
10:53:01 | jamesp | maybe i'm mis-remembering |
10:54:03 | Araq | you're right though, generating C code is not enough. the language needs to map closely to C to get the same perf benefits. And Nim does that. |
10:54:31 | jamesp | Ah |
10:54:41 | jamesp | I should start reading the compiler in my spare time |
10:54:49 | jamesp | would probably be a good learning experience! |
10:57:02 | jamesp | This has been fun. Thank you for all of the wisdom |
10:58:03 | * | exebook quit (Ping timeout: 276 seconds) |
11:04:10 | * | exebook joined #nim |
11:04:59 | * | vendethiel joined #nim |
11:05:42 | * | jamesp quit (Quit: Page closed) |
11:10:21 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
11:10:40 | * | coffeepot joined #nim |
11:12:10 | * | arnetheduck quit (Read error: Connection reset by peer) |
11:12:38 | * | coffeepots joined #nim |
11:13:03 | * | arnetheduck joined #nim |
11:13:04 | * | coffeepot quit (Client Quit) |
11:14:17 | * | coffeepots is now known as coffeepot |
11:15:42 | * | allan0 quit (Quit: no) |
11:15:58 | * | allan0 joined #nim |
11:38:13 | * | toaoMgeorge quit (Ping timeout: 255 seconds) |
11:47:40 | * | vendethiel quit (Ping timeout: 255 seconds) |
11:47:48 | * | PMunch joined #nim |
11:49:25 | gokr1 | Super silly idiotic question. I have an int. How do I convert it to uint32? |
11:50:18 | Araq | uint32(x) |
11:50:35 | gokr1 | I thought so too, but... not sure what is happening. |
11:51:00 | gokr1 | Don't have any reasonable way to debug, not even printfs. :) |
11:54:04 | gokr1 | When c2nimming I mangled uint32_t to uint32, was that correct? |
11:54:18 | Araq | sure |
11:54:30 | gokr1 | Ok, so... (hang on) |
11:58:39 | * | vendethiel joined #nim |
12:02:16 | gokr1 | Araq: http://pastebin.com/g4mEZA8B |
12:02:36 | gokr1 | The first two don't work. It seems to be blinking "very fast". |
12:02:45 | gokr1 | The last one with hardcoded 1000 works. |
12:02:58 | gokr1 | Also threw in the proc declaration from the wrapper there. |
12:04:18 | gokr1 | Oh, the setup and loop are templates... |
12:05:17 | gokr1 | They just expand to proc loop*() {.exportc.} = |
12:08:38 | Araq | gokr1: looks like globals are not initialized properly on your system |
12:08:50 | Araq | maybe it ends up being 0 |
12:09:08 | Araq | and gets assigned the 1000 after the 'loop' for reasons that escape me |
12:09:42 | Araq | write the assignment in the 'setup' section perhaps |
12:10:59 | * | dmitry_p quit (Ping timeout: 240 seconds) |
12:12:24 | * | thotypous quit (Ping timeout: 244 seconds) |
12:13:05 | gokr1 | You seem to be right, moving the var into loop... made things start working... hmm. |
12:18:17 | vegansk | Araq, please see my latest comments on https://github.com/nim-lang/Nim/issues/3889. The problem of my library is that I can't use ``--tlsEmulation:on`` because of the foreign threads from the main c++ application. |
12:18:20 | gokr1 | ok, so ... yeah, initializing on module level doesn't seem to work. |
12:19:29 | Araq | vegansk: how is that an issue? |
12:20:33 | * | vendethiel quit (Ping timeout: 240 seconds) |
12:21:15 | vegansk | Araq, it's about createThread crashes |
12:24:21 | * | toaoMgeorge joined #nim |
12:25:37 | Araq | vegansk: no I mean why you cannot use --tlsEmulation:on |
12:27:43 | vegansk | When the foreign thread is created, it doesn't initialize structures for the TLS emulation, i.e. there is no ``GcThread`` object |
12:29:59 | vegansk | There was a PR https://github.com/nim-lang/Nim/pull/3786, with the same problem - crashes in ``setupForeignThreadGc`` because of thread vars |
12:35:55 | wuehlmaus | hmm, i have a very strange problem with tnim and i run out of ideas now |
12:36:09 | * | toaoMgeorge quit (Quit: Bye) |
12:36:14 | wuehlmaus | when i try to echo something it doesn't output anything |
12:36:33 | wuehlmaus | i deleted tnim.dat and i even reinstalled tnim no no resolution |
12:37:01 | wuehlmaus | does anyone have an idea what i could do? |
12:37:23 | wuehlmaus | nim secret DOES echo but it's a little too unstable to use |
12:38:13 | wuehlmaus | and i deleted the nimcache, too |
12:40:43 | vegansk | Araq, sorry, really must go now :-( I will think about it tomorrow |
12:41:04 | * | lxdong joined #nim |
12:46:27 | def- | wuehlmaus: I would just not use tnim, it's probably not well tested |
12:46:27 | * | vendethiel joined #nim |
12:50:30 | wuehlmaus | well what can one do if he loves using a REPL.... |
12:50:53 | wuehlmaus | normally it helps me to understand stuff better |
12:51:58 | wuehlmaus | it worked fine for weeks , too |
12:55:14 | gokr1 | Ni managed to run "1000" (kinda silly program) on my Linkit ONE :) |
13:00:00 | * | lokien_ quit (Quit: Connection closed for inactivity) |
13:00:15 | * | toaoMgeorge joined #nim |
13:06:02 | Araq | wuehlmaus: no idea. are you using Nim devel? maybe that has some recent regression |
13:07:12 | * | vendethiel quit (Ping timeout: 244 seconds) |
13:10:13 | wuehlmaus | yes, i use the git version |
13:11:12 | wuehlmaus | but as i use archlinux i was able to install the arch version and still the problem was not gone so i am REALLY confused now |
13:11:34 | wuehlmaus | arch is quite current and has 0.13 |
13:12:37 | bbl_ | "The current implementation of message passing is slow and does not work with cyclic data structures." What is the current state/status of channels? |
13:12:45 | Araq | wuehlmaus: try 0.13 instead of devel please |
13:13:10 | Araq | bbl_: 'slow' is relative and mostly refers to it not using lockfree stuff |
13:13:50 | Araq | cycles still don't work. ;-) |
13:14:12 | bbl_ | Araq: nice :P |
13:15:02 | bbl_ | Araq: will I be able to use parseql at compiletime? |
13:15:46 | Araq | will you? yes. does it work right now? with a chance of 30% perhaps |
13:16:00 | bbl_ | Araq: that's what I was thinking |
13:16:12 | Araq | but you can always use staticExec right now as a decent workaround |
13:16:20 | Araq | staticExec supports caching too. |
13:16:40 | bbl_ | I started writing yessql/hugsql like lib for nim and it would be really cool to leverage parsesql with it |
13:17:02 | Araq | my lexim project works 100% at compile-time |
13:17:12 | bbl_ | nice :P |
13:17:17 | Araq | and yet I changed it to use staticExec |
13:17:24 | bbl_ | hmmh? |
13:17:28 | Araq | compile-times went from minutes to seconds |
13:17:46 | Araq | it does DFA minimization for lexer generation |
13:19:00 | bbl_ | I'm wondering what you are calling with staticExec |
13:19:16 | Araq | I planned to give a talk about it. ... |
13:19:31 | bbl_ | I just love the fact that I don't need any outer tools writing compile time features |
13:19:37 | Araq | was a 10 line patch |
13:19:43 | bbl_ | :P |
13:19:49 | Araq | since compiletime Nim is the same as runtime Nim :-) |
13:19:59 | bbl_ | <3 |
13:20:31 | Araq | checkout out lexim, I'm sure you'll understand |
13:20:43 | bbl_ | Araq: checking indeed |
13:21:09 | Araq | nim supports marshal.nim at compile-time |
13:23:06 | * | endragor_ joined #nim |
13:26:54 | * | endragor quit (Ping timeout: 276 seconds) |
13:27:34 | * | endragor_ quit (Ping timeout: 255 seconds) |
13:47:07 | bbl_ | Araq: I'm looking forward to that talk |
13:51:31 | bbl_ | Araq: I was wondering about tuples again the other day, tuples can be unpacked var (x, y) = someProc(), why wouldn't those unpack implicitly to proc args: proc myProc(x, y: int) = ... , myProc((1, 2))? |
13:51:56 | bbl_ | this would enable chaining with multiple return values |
13:52:42 | Araq | too ambiguous |
13:52:57 | Araq | you can write an unpack macro to do that though |
13:53:49 | bbl_ | Araq: I'm just thinking that would be awesome when combined with currying :P |
13:54:17 | bbl_ | can't see any pitfalls :D |
13:55:03 | Arrrrr | +2 |
13:59:17 | * | lompik joined #nim |
14:02:11 | wuehlmaus | ouch, it seems that tcc is the problem |
14:02:43 | wuehlmaus | when i use clang as cc i have a working echo. |
14:02:56 | arnetheduck | hey, any reason why there's an caseexpr in the compiler? like ifstmt/ifexpr? |
14:03:05 | arnetheduck | *no caseexpr |
14:20:48 | * | OnwardEuler joined #nim |
14:23:24 | * | zepolen quit (Remote host closed the connection) |
14:33:54 | * | zepolen joined #nim |
14:46:58 | * | lxdong quit (Quit: Page closed) |
15:05:07 | Araq | arnetheduck: I figured it's not required. ifexpr isn't required either, but was introduced before I figured it out. |
15:06:58 | wuehlmaus | tnim without tcc is not much fun, tcc makes it very bearable but with clang you FEEL the compilation happening :) won't try with gcc |
15:07:23 | * | gokr1 quit (Quit: Leaving.) |
15:07:28 | wuehlmaus | anyway --cc=clang solved it |
15:08:05 | * | vendethiel joined #nim |
15:09:38 | arnetheduck | ah. caught me off guard.. by that logic, none of the expr/stmt division is really needed? though it was pretty convenient for nlvm at least |
15:10:27 | arnetheduck | Araq, so it's also not a bug that ifstmt is sometimes used when if is an expression? |
15:11:18 | Araq | yes. the division is really void type vs non-void type |
15:13:47 | arnetheduck | 769/1074 tests passing with nlvm btw.. getting into the hairier parts ;) |
15:26:06 | * | mat4 joined #nim |
15:26:07 | mat4 | hello |
15:26:26 | * | Wildefyrr joined #nim |
15:26:42 | * | allan0_ joined #nim |
15:26:59 | * | allan0 quit (Ping timeout: 240 seconds) |
15:26:59 | * | Wildefyr quit (Ping timeout: 240 seconds) |
15:30:34 | def- | arnetheduck: very cool. would an LLVM JIT REPL and compile time execution be possible? Basically replacing the Nim VM with LLVM JIT. |
15:31:47 | * | vendethiel quit (Ping timeout: 248 seconds) |
15:33:00 | arnetheduck | def-, shouldn't be too much trouble |
15:33:29 | def- | arnetheduck: well, that would be great: more performance at compile time and a functional REPL |
15:34:52 | arnetheduck | def-, have more pressing issues than performance, for now ;) |
15:37:49 | arnetheduck | def-, they even have a command line jit, though I haven |
15:37:53 | arnetheduck | t tried it |
15:44:51 | * | jaco60 joined #nim |
15:45:44 | mat4 | a LLVM backend for Nim ? |
15:47:07 | * | pregressive joined #nim |
15:47:45 | flyx | having one would be pretty cool |
15:48:34 | flyx | but the correct term would be frontend, not backend |
15:49:41 | mat4 | ok, name it frontend to a code generator, that's fine |
15:51:16 | mat4 | anyhow, I think there exist already a project for a C interpreter with JIT compiler |
15:51:44 | mat4 | I just can't remember right now where I found it |
15:53:04 | arnetheduck | I've had that naming issue.. from the nim compiler perspective it's a backend, but in llvm, it's clearly a frontent.. middle end maybe? |
15:53:55 | arnetheduck | mat4, https://github.com/arnetheduck/nlvm |
15:55:47 | mat4 | ok, after a quick research, it it the Cling project, an C++ interpreter. I think it can be used with Nim's C++ 'backend' = source generator somehow |
15:58:03 | mat4 | arnetheduck: For the Nim compiler, LLVM generation would be one backend. However, the generated IL (for intermediate language) is part of the frontend if I'm correct |
15:58:47 | mat4 | I mean a LLVM IL generator would be a backend for the Nim compiler |
16:07:13 | mat4 | here is the link: https://solarianprogrammer.com/2012/08/14/cling-cpp-11-interpreter/ |
16:08:09 | mat4 | the interpreter is used mainly at CERN (mature code) |
16:08:29 | * | pregressive quit (Read error: Connection reset by peer) |
16:08:42 | * | gokr joined #nim |
16:09:06 | * | pregressive joined #nim |
16:11:36 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
16:25:46 | * | yglukhov quit (Ping timeout: 255 seconds) |
16:31:33 | bbl_ | Araq: nimsuggest can't handle using channels? |
16:38:12 | * | PMunch quit (Quit: leaving) |
16:39:10 | * | toaoMgeorge quit (Read error: Connection reset by peer) |
16:40:02 | * | gokr quit (Ping timeout: 244 seconds) |
16:45:19 | * | Demos joined #nim |
16:46:03 | * | nsf quit (Quit: WeeChat 1.4) |
16:48:54 | * | Sembei joined #nim |
16:59:06 | Araq | bbl_: more likely: you need to tell nimsuggest about --threads:on |
16:59:27 | bbl_ | Araq: I feel really stupid now |
17:00:46 | bbl_ | Araq: I'm also not getting the docstrings so there must be something equally as stupid going on |
17:02:29 | * | arnetheduck quit (Ping timeout: 240 seconds) |
17:08:54 | * | vendethiel joined #nim |
17:13:19 | * | Trustable quit (Remote host closed the connection) |
17:16:45 | * | dorei joined #nim |
17:17:30 | * | yglukhov joined #nim |
17:21:59 | * | yglukhov quit (Ping timeout: 240 seconds) |
17:29:40 | * | vendethiel quit (Ping timeout: 244 seconds) |
17:43:40 | * | yglukhov joined #nim |
17:47:50 | * | zama quit (Quit: leaving) |
17:49:24 | * | zama joined #nim |
17:52:40 | * | brson joined #nim |
17:57:06 | * | vendethiel joined #nim |
18:20:01 | * | nsf joined #nim |
18:33:49 | * | gokr joined #nim |
18:33:50 | * | gokr quit (Read error: Connection reset by peer) |
18:34:02 | * | gokr joined #nim |
18:42:48 | * | shodan45 joined #nim |
18:44:18 | * | gokr left #nim (#nim) |
18:56:20 | * | yglukhov quit (Remote host closed the connection) |
18:56:41 | * | yglukhov joined #nim |
19:05:25 | * | yglukhov quit (Remote host closed the connection) |
19:24:23 | * | wh1t3r0s3 joined #nim |
19:28:38 | * | jaco60 quit (Quit: Leaving) |
19:28:41 | * | Jesin quit (Quit: Leaving) |
19:28:59 | * | jaco60 joined #nim |
19:29:38 | * | shodan45 quit (Quit: Konversation terminated!) |
19:34:52 | * | Ven joined #nim |
19:35:49 | * | Subspice joined #nim |
19:38:22 | * | Jesin joined #nim |
19:46:50 | * | Arrrrr quit (Read error: Connection reset by peer) |
19:47:43 | * | zepolen quit (Remote host closed the connection) |
19:52:41 | * | zepolen joined #nim |
20:00:30 | * | ephja quit (Quit: WeeChat 1.3) |
20:00:33 | * | Demos quit (Ping timeout: 240 seconds) |
20:00:48 | * | Demos joined #nim |
20:09:48 | * | dmitry_p joined #nim |
20:18:54 | * | boopsiesisaway is now known as boopsies |
20:26:51 | * | yglukhov joined #nim |
20:32:01 | dom96 | http://freecontent.manning.com/nim-in-action-diagram/ |
20:32:26 | dom96 | (Synchronous I/O vs. Asynchronous I/O) |
20:35:38 | * | zepolen quit (Remote host closed the connection) |
20:39:27 | ldlework | dom96: I've always thought of asynch i/o more like those "order wheels" you see in restraunts |
20:40:00 | ldlework | where the cashier yells out some order and puts the receipt on a wheel |
20:40:29 | ldlework | and then gets back the receipt and food item later |
20:41:22 | ldlework | but I do like the animation |
20:42:16 | * | nsf quit (Ping timeout: 255 seconds) |
20:43:03 | * | nsf joined #nim |
20:43:25 | * | Jesin quit (Quit: Leaving) |
20:56:59 | * | miko__ quit (Ping timeout: 240 seconds) |
21:00:59 | * | Demos quit (Ping timeout: 240 seconds) |
21:07:13 | * | Demos joined #nim |
21:07:14 | * | zepolen joined #nim |
21:10:05 | * | miko__ joined #nim |
21:14:59 | * | gokr joined #nim |
21:42:17 | * | wicast joined #nim |
21:43:52 | * | wicast quit (Client Quit) |
21:44:16 | * | Subspice quit () |
21:44:31 | * | wicast joined #nim |
21:48:55 | * | wicast quit (Client Quit) |
21:55:50 | * | wicastC joined #nim |
21:56:08 | * | samdoran joined #nim |
21:56:13 | * | wicastC quit (Client Quit) |
21:57:00 | flyx | NimYAML is now at 0.2.0 and I added a DOM API |
21:57:40 | * | wicast joined #nim |
21:58:17 | * | wicast quit (Client Quit) |
21:58:31 | * | wicast joined #nim |
21:58:50 | * | wicast quit (Client Quit) |
21:58:57 | samdoran | So, after having tried to find it myself... is there a suggested method of doing an async readline on stdin? I found an old commit that added asyncstdin to asyncfile.nim, but that seems to have been removed now |
21:59:23 | samdoran | (or I might just be messing up somewhere) |
22:00:09 | * | samdoran_ joined #nim |
22:00:22 | * | wicast joined #nim |
22:03:36 | * | samdoran quit (Ping timeout: 252 seconds) |
22:04:20 | * | samdoran_ quit (Ping timeout: 252 seconds) |
22:05:26 | * | samdoran joined #nim |
22:06:24 | * | zepolen quit (Remote host closed the connection) |
22:08:41 | * | Demon_Fox joined #nim |
22:12:02 | * | samdoran quit (Ping timeout: 252 seconds) |
22:16:31 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:31:50 | gokr | http://goran.krampe.se/2016/02/25/nim-meets-arduino/ |
22:37:09 | jeffc_ | gokr: Very Cool |
22:37:10 | * | Trustable joined #nim |
22:37:28 | jeffc_ | I've been working on something similar for ARM cortex cores: https://github.com/Jeff-Ciesielski/narm |
22:38:12 | jeffc_ | I have it up and running with FreeRTOS and enough driver underneath it to print it up and user printf/etc |
22:38:18 | gokr | In fact... I am now most probably (as I write at the end) moving to try it more seriously on mbed OS. |
22:39:00 | jeffc_ | I'm working on slowly peeling out the C library code I have and setting up an all Nim runtime |
22:39:39 | gokr | Nice! |
22:40:18 | gokr | This is more of the... "can I use Nim instead of C++" to program against the mbed OS or whatever. |
22:40:28 | gokr | Using c2nim to generate the wrappers needed. |
22:40:42 | gokr | Andreas also helped me hack alloc.nim to use malloc instead of mmap. |
22:41:03 | jeffc_ | Nice, that makes me glad to hear (alloc) |
22:41:28 | gokr | I should do a PR, but for now my hacked alloc.nim is in that repo. |
22:41:30 | jeffc_ | I've been mulling over whether or not it would be feasible to actually add a FreeRTOS/Chibi/Mbed OS target (instead of 'none') |
22:44:34 | * | thotypous joined #nim |
22:44:47 | * | boopsies is now known as boopsiesisaway |
22:47:09 | dom96 | samdoran: there is no way to read stdin asynchronously, operating systems don't support it very well. Funnily enough I explain how to get around this in my book :) |
22:47:34 | dom96 | samdoran: basically you need to create a new thread and call stdin.readLine in that thread. |
22:47:57 | dom96 | you can use spawn for that |
22:49:03 | * | Varriount_ quit (Ping timeout: 240 seconds) |
22:49:09 | dom96 | samdoran: best to take a look at this code sample from my book: https://gist.github.com/dom96/e089d0a2cde13229cc82 |
22:49:12 | dom96 | hope that helps |
22:49:14 | * | Varriount joined #nim |
22:51:00 | Varriount | gokr: What horrid frankenstein have you created?! |
22:51:16 | Varriount | flyx: I like YAML (even if it is a pain to parse) |
22:51:16 | gokr | Ehum? :) |
22:51:34 | Varriount | <gokr> I should do a PR, but for now my hacked alloc.nim is in that repo. |
22:51:59 | gokr | Ah, well, I didn't hack it - it was Andreas, I just typed what he told me. |
22:55:41 | * | PMunch joined #nim |
22:58:59 | * | vendethiel quit (Ping timeout: 240 seconds) |
23:04:12 | * | Demos quit (Ping timeout: 250 seconds) |
23:07:05 | * | zepolen joined #nim |
23:11:34 | * | zepolen quit (Ping timeout: 250 seconds) |
23:19:47 | * | Jesin joined #nim |
23:31:12 | * | Kingsquee joined #nim |
23:33:02 | mat4 | I think that is a good idea |
23:33:47 | mat4 | (the FreeRTOS target) |
23:37:15 | * | mat4 quit (Quit: Leaving) |
23:39:36 | * | awsteele joined #nim |
23:46:20 | dyce_ | has anyone tried the binaries on openwrt? |
23:46:25 | dyce_ | nim binaries* |