00:03:12 | * | yglukhov quit (Ping timeout: 276 seconds) |
00:09:25 | * | yglukhov joined #nim |
00:13:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
00:19:45 | * | yglukhov joined #nim |
00:24:01 | * | yglukhov quit (Ping timeout: 240 seconds) |
00:25:55 | * | yglukhov joined #nim |
00:37:39 | * | yglukhov quit (Ping timeout: 276 seconds) |
00:39:35 | * | yglukhov joined #nim |
00:44:48 | * | yglukhov quit (Ping timeout: 276 seconds) |
00:45:01 | * | brson quit (Ping timeout: 240 seconds) |
00:48:35 | * | chemist69 quit (Ping timeout: 272 seconds) |
00:49:30 | * | yglukhov joined #nim |
00:52:12 | * | libman quit (Remote host closed the connection) |
00:52:50 | * | chemist69 joined #nim |
00:53:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
00:59:35 | * | yglukhov joined #nim |
01:04:18 | * | yglukhov quit (Ping timeout: 276 seconds) |
01:05:59 | corecode | why does very simple code produce these void (*volatile inner)(); constructs? |
01:06:13 | corecode | and why is inner volatile? |
01:07:00 | corecode | this seems to lead to inefficient code (for a microcontroller system) |
01:07:53 | FromGitter | <Araq> it's only done in like 2 places to prevent inlining |
01:08:11 | FromGitter | <Araq> so that the top of stack is reliably detectable |
01:08:35 | FromGitter | <Araq> your microcontroller can perhaps perform 2 function calls at startup without draining all the battery |
01:10:35 | * | yglukhov joined #nim |
01:13:59 | corecode | it was surprising to see |
01:14:58 | corecode | especially because the called functions are empty |
01:15:21 | * | yglukhov quit (Ping timeout: 276 seconds) |
01:17:10 | corecode | also surprising that the c compiler doesn't merge all these empty function bodies into a single empty (just return) function |
01:20:17 | * | Demon_Fox joined #nim |
01:20:35 | * | yglukhov joined #nim |
01:28:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
01:37:21 | * | chemist69 quit (Ping timeout: 272 seconds) |
01:41:05 | * | yglukhov joined #nim |
01:45:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
01:45:34 | * | allan0 quit (Ping timeout: 250 seconds) |
01:50:30 | * | chemist69 joined #nim |
01:51:50 | * | yglukhov joined #nim |
01:59:33 | * | yglukhov quit (Ping timeout: 276 seconds) |
02:03:20 | * | kulelu88 quit (Quit: Leaving) |
02:04:40 | * | yglukhov joined #nim |
02:13:42 | * | desophos quit (Ping timeout: 264 seconds) |
02:15:48 | * | yglukhov quit (Ping timeout: 276 seconds) |
02:21:00 | * | yglukhov joined #nim |
02:30:45 | * | yglukhov quit (Ping timeout: 276 seconds) |
02:36:00 | * | yglukhov joined #nim |
02:45:42 | * | yglukhov quit (Ping timeout: 276 seconds) |
02:49:06 | * | dddddd quit (Remote host closed the connection) |
02:51:00 | * | yglukhov joined #nim |
03:01:57 | * | yglukhov quit (Ping timeout: 276 seconds) |
03:06:26 | * | ftsf joined #nim |
03:07:25 | * | yglukhov joined #nim |
03:10:40 | * | krux02 quit (Quit: Verlassend) |
03:11:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
03:16:49 | * | allan0 joined #nim |
03:18:30 | * | yglukhov joined #nim |
03:27:18 | * | yglukhov quit (Ping timeout: 276 seconds) |
03:28:40 | * | yglukhov joined #nim |
03:32:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
03:37:27 | FromGitter | <nigredo-tori> @Araq, before release you might want to fix this: https://github.com/nim-lang/Nim/issues/4834 |
03:40:51 | * | allan0 quit (Ping timeout: 272 seconds) |
03:43:30 | * | yglukhov joined #nim |
03:43:56 | * | MyMind joined #nim |
03:46:29 | * | fold4 quit (Ping timeout: 250 seconds) |
03:46:55 | * | mtj_ quit (Ping timeout: 250 seconds) |
03:47:12 | * | Sembei quit (Ping timeout: 272 seconds) |
03:48:28 | * | M-Quora quit (Ping timeout: 272 seconds) |
03:48:38 | * | sarlalian quit (Ping timeout: 250 seconds) |
03:50:03 | * | mtj_ joined #nim |
03:50:03 | * | hohlerde quit (Ping timeout: 276 seconds) |
03:50:48 | * | dyce quit (Ping timeout: 250 seconds) |
03:50:49 | * | sarlalian joined #nim |
03:52:31 | * | fold4 joined #nim |
03:53:57 | * | yglukhov quit (Ping timeout: 276 seconds) |
03:58:15 | * | yglukhov joined #nim |
04:02:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
04:08:55 | * | ARCADIVS joined #nim |
04:13:04 | * | yglukhov joined #nim |
04:15:09 | * | dyce joined #nim |
04:17:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
04:24:20 | * | mitai quit (Ping timeout: 244 seconds) |
04:27:55 | * | yglukhov joined #nim |
04:37:30 | * | yglukhov quit (Ping timeout: 276 seconds) |
04:51:58 | * | andrewo91 joined #nim |
04:53:01 | * | andrewo91 quit (Client Quit) |
04:56:43 | * | allan0 joined #nim |
04:59:25 | * | yglukhov joined #nim |
05:03:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
05:03:46 | * | wgf_ joined #nim |
05:06:51 | * | yglukhov joined #nim |
05:11:35 | * | enthus1ast quit (Quit: Leaving.) |
05:11:57 | * | yglukhov quit (Ping timeout: 276 seconds) |
05:12:30 | * | desophos joined #nim |
05:22:40 | * | M-Quora joined #nim |
05:22:45 | * | yglukhov joined #nim |
05:28:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
05:35:46 | * | yglukhov joined #nim |
05:35:55 | * | andrewo91 joined #nim |
05:40:33 | * | yglukhov quit (Ping timeout: 276 seconds) |
05:46:45 | * | yglukhov joined #nim |
05:50:48 | * | andrewo91 quit () |
05:51:01 | * | yglukhov quit (Ping timeout: 240 seconds) |
05:55:33 | * | Demon_Fox quit (Quit: Leaving) |
05:57:05 | * | yglukhov joined #nim |
06:00:54 | * | xet7 joined #nim |
06:01:01 | * | yglukhov quit (Ping timeout: 240 seconds) |
06:08:23 | * | hohlerde joined #nim |
06:08:25 | * | yglukhov joined #nim |
06:12:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
06:13:18 | * | desophos quit (Read error: Connection reset by peer) |
06:18:41 | * | yglukhov joined #nim |
06:22:39 | * | nicanaca0 quit (Ping timeout: 244 seconds) |
06:23:27 | * | yglukhov quit (Ping timeout: 276 seconds) |
06:24:25 | * | yglukhov joined #nim |
06:28:34 | * | filcuc joined #nim |
06:28:52 | * | xet7 quit (Remote host closed the connection) |
06:29:41 | * | yglukhov quit (Ping timeout: 240 seconds) |
06:33:53 | * | filcuc quit (Ping timeout: 252 seconds) |
06:35:48 | * | filcuc joined #nim |
06:40:42 | * | yglukhov joined #nim |
06:51:24 | * | yglukhov quit (Ping timeout: 276 seconds) |
06:54:10 | * | yglukhov joined #nim |
06:55:52 | * | enthus1ast joined #nim |
06:57:32 | * | Andris_zbx joined #nim |
06:58:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
07:09:20 | * | Arrrr joined #nim |
07:13:00 | * | gokr joined #nim |
07:23:13 | * | brechtm joined #nim |
07:29:58 | * | Demon_Fox joined #nim |
07:34:56 | * | filcuc quit (Ping timeout: 252 seconds) |
07:40:04 | * | enthus1ast quit (Quit: Leaving.) |
08:16:28 | * | filcuc joined #nim |
08:26:06 | * | enthus1ast joined #nim |
08:28:37 | * | yglukhov joined #nim |
08:30:08 | * | yglukhov quit (Remote host closed the connection) |
08:32:07 | * | yglukhov joined #nim |
08:48:20 | * | enthus1ast quit (Quit: Leaving.) |
08:51:02 | * | wgf_ quit (Quit: Leaving) |
08:55:04 | cheatfate | Araq_, https://github.com/nim-lang/Nim/pull/4836 fix for upcoming on your machine |
09:00:27 | * | enthus1ast joined #nim |
09:05:45 | * | enthus1ast quit (Ping timeout: 272 seconds) |
09:06:54 | Araq_ | cheatfate: yay |
09:07:20 | * | filcuc quit (Ping timeout: 252 seconds) |
09:07:29 | cheatfate | Araq_, you run tests on windows? |
09:09:53 | Araq_ | before a release, sure |
09:14:37 | * | Snircle quit (Ping timeout: 272 seconds) |
09:20:27 | * | filcuc joined #nim |
09:23:43 | * | Snircle joined #nim |
09:25:19 | * | Pisuke joined #nim |
09:28:00 | * | Demon_Fox quit (Quit: Leaving) |
09:35:35 | * | ARCADIVS quit (Quit: ARCADIVS) |
09:37:02 | * | Arrrr quit (Quit: WeeChat 1.5) |
09:41:35 | FromGitter | <dom96> Araq_: maybe you could fix some before we release :) |
09:41:46 | FromGitter | <dom96> GitLab also tests windows now, so you don't have to run them |
09:44:42 | euantor | Though it would be nice to run them on a 32 bit Windows system |
09:45:19 | cheatfate | 32bit windows must die :) |
09:45:32 | euantor | cheatfate: Very true! |
09:46:16 | cheatfate | dom96, what VM gitlab uses for Windows? |
09:46:28 | euantor | It uses my Windows server |
09:47:06 | cheatfate | euantor, is it virtual? |
09:47:10 | cheatfate | or real one? |
09:47:22 | euantor | Yes, it's virtual but has dedicated CPU resources |
09:47:33 | euantor | https://buyvm.net/kvm-dedicated-server-slices |
09:47:35 | cheatfate | euantor, but what VM it uses? |
09:47:39 | cheatfate | vmware? |
09:47:45 | euantor | It's KVM |
09:50:59 | * | Trustable joined #nim |
10:26:48 | * | arnetheduck joined #nim |
10:31:44 | ftsf | \o/ KVM |
10:39:04 | * | gokr left #nim (#nim) |
10:39:32 | * | elrood joined #nim |
10:40:36 | * | brechtm_ joined #nim |
10:43:55 | * | brechtm quit (Ping timeout: 272 seconds) |
10:44:30 | * | brechtm_ quit (Remote host closed the connection) |
10:51:32 | * | enthus1ast joined #nim |
10:54:25 | Calinou | hi dom96! I think I have time this afternoon for working on Community page finally |
10:54:35 | Calinou | (I don't have class this afternoon, this week) |
10:55:05 | FromGitter | <dom96> Calinou: Great! Let me know when you've made progress. |
10:55:29 | ftsf | hmm I noticed nim binaries under linux don't show the libraries they use under ldd, does nim do something special when linking? |
10:55:31 | * | brechtm joined #nim |
10:58:11 | FromGitter | <dom96> ftsf: most libraries are dynamically loaded |
11:00:02 | ftsf | ahh using libdl? |
11:00:22 | ftsf | is that a configurable thing, or just the way nim works? |
11:02:16 | FromGitter | <dom96> http://nim-lang.org/docs/nimc.html#dynliboverride |
11:02:35 | ftsf | dom96, ahh cheers |
11:08:20 | * | filcuc quit (Ping timeout: 252 seconds) |
11:26:13 | * | PMunch joined #nim |
11:29:13 | * | filcuc joined #nim |
11:30:57 | * | Sembei joined #nim |
11:31:18 | * | mitai joined #nim |
11:34:09 | * | MyMind quit (Ping timeout: 276 seconds) |
11:36:23 | * | filcuc quit (Ping timeout: 252 seconds) |
11:57:34 | * | enthus1ast quit (Quit: Leaving.) |
12:01:51 | * | brechtm_ joined #nim |
12:04:13 | * | filcuc joined #nim |
12:05:18 | * | brechtm quit (Ping timeout: 264 seconds) |
12:05:33 | * | Amrykid2 is now known as Amrykid |
12:05:38 | * | Amrykid quit (Changing host) |
12:05:38 | * | Amrykid joined #nim |
12:06:36 | * | enthus1ast joined #nim |
12:09:33 | * | xet7_ quit (Read error: Connection reset by peer) |
12:10:46 | FromGitter | <gogolxdong> how to resolve the proc to be called should prior to the caller |
12:14:55 | * | fredrik92 joined #nim |
12:15:43 | * | bjz_ joined #nim |
12:19:02 | * | bjz__ joined #nim |
12:19:04 | enthus1ast | hey guys and gals, when i compile an executable mingw is adding a version string like "GCC: (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 4.8.3" to every object file. After linking i find this line for every linked object in the executable (atm in my case nearly 40 times). Does one know to disable this behavior? or strip it out somehow? |
12:20:40 | * | bjz_ quit (Read error: Connection reset by peer) |
12:22:27 | Araq_ | why does it matter? |
12:22:52 | ftsf | enthus1ast, tried running strip -s/-g over it? |
12:22:59 | enthus1ast | jep |
12:23:57 | enthus1ast | Araq, one times should be enough, to credit mingw right? |
12:28:16 | * | bjz__ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
12:28:59 | ofelas | something like, strip -R .note.gnu.build-id <prog>, or whatever section that is stored in (see readelf or equiv) |
12:30:18 | * | fredrik92 quit (Read error: Connection reset by peer) |
12:31:12 | flyx | possibly relevant: https://stackoverflow.com/questions/20093856/how-to-remove-mingw-version-information-from-pe |
12:34:40 | * | confundus joined #nim |
12:37:21 | enthus1ast | ofelas, flyx ty for the hint. |
12:38:07 | * | dddddd joined #nim |
12:43:03 | * | bjz joined #nim |
12:52:00 | * | fredrik92 joined #nim |
12:57:51 | * | fredrik92 quit (Read error: Connection reset by peer) |
13:04:00 | * | fredrik92 joined #nim |
13:05:19 | * | bjz quit (Read error: Connection reset by peer) |
13:06:14 | * | bjz joined #nim |
13:09:47 | * | fredrik92 quit (Read error: Connection reset by peer) |
13:10:28 | * | krux02 joined #nim |
13:13:28 | krux02 | Araq_: would it be possible to support a default `==` and `!=` operator for case types? |
13:16:20 | Araq_ | sure |
13:17:41 | * | fredrik92 joined #nim |
13:18:00 | krux02 | cool, because I have such a case, where I implemented several case objects assuming == would be implemented by default, and now it broke and I have to implement it for a lot of types |
13:18:59 | * | couven92 joined #nim |
13:20:33 | krux02 | the error message for such a case is also not the nicest at the moment |
13:20:46 | krux02 | parallel 'fields' iterator does not work for 'case' objects |
13:20:55 | krux02 | but it doesn't tell for wich type it failed |
13:21:18 | * | couven92 quit (Client Quit) |
13:21:39 | * | couven92 joined #nim |
13:22:42 | * | fredrik92 quit (Ping timeout: 264 seconds) |
13:23:22 | * | wgf_ joined #nim |
13:23:51 | * | couven92 quit (Read error: Connection reset by peer) |
13:29:30 | Araq_ | "instantiation from here"? |
13:31:28 | * | confundus quit (Quit: leaving) |
13:32:10 | * | fredrik92 joined #nim |
13:43:43 | * | Salewski joined #nim |
13:45:24 | * | idril_ joined #nim |
13:45:33 | * | idril_ left #nim (#nim) |
13:46:15 | Salewski | if alpha < -SureCheckmate and not (x in mobSet[kingpos]): # we need the round paranthesis here! Hard to remember for me. |
13:47:43 | Araq_ | x notin mobSet |
13:48:32 | Salewski | Ah, thanks! |
13:52:11 | Salewski | Araq, recently there was a conversation in IRC logs about magic proc. system.reset() is really strange, the doc text is not helpful for me. |
13:52:19 | Salewski | resets an object obj to its initial (binary zero) value. This needs to be called before any possible object branch transition |
13:53:53 | Salewski | Of course first part is clear, second not. |
13:54:33 | * | arnetheduck quit (Ping timeout: 276 seconds) |
13:54:58 | * | arnetheduck joined #nim |
13:55:23 | Salewski | Someone used reset() recently in forum for array shift, is that ok? |
13:57:09 | * | bjz quit (Ping timeout: 276 seconds) |
13:57:27 | * | bjz_ joined #nim |
13:59:04 | ftsf | anyone on a mac able to try my game and see if it works? (nim cross compiled from linux to osx) http://static.impbox.net/vektor2089/vektor2089-2016-09-29-osx.zip (~15 MB) |
13:59:05 | FromGitter | <coffeepots> "This needs to be called before any possible object branch transition" means if you have an object variant http://nim-lang.org/docs/manual.html#types-object-variants you need to call reset to change the 'kind' |
14:02:16 | FromGitter | <dom96> ftsf: ooh, gonna try it as soon as I get home :) |
14:03:00 | ftsf | dom96, \o/ |
14:03:57 | Salewski | Interesting. Can I use system.reset() to reset other variables to default value, or is there any risk? I had the feeling that proc is very special? |
14:07:14 | Araq_ | Salewski: reset() was designed for case objects and nothing else and happens to work for the cases you describe |
14:07:32 | Araq_ | I would hesitate to use it. |
14:08:25 | * | fredrik92 quit (Read error: Connection reset by peer) |
14:10:28 | * | irrequietus joined #nim |
14:11:11 | Salewski | OK, then I will try to avoid using system.reset. It was used in http://forum.nim-lang.org/t/2552 |
14:18:19 | Salewski | Bye... |
14:18:25 | * | Salewski left #nim (#nim) |
14:19:00 | FromGitter | <coffeepots> bye Salewski :) |
14:23:33 | * | daekano joined #nim |
14:24:46 | daekano | When using the marshal library to convert JSON to an Object, is it mandatory to implement all fields from the JSON response, or can I discard fields I don’t care about? |
14:32:00 | ftsf | daekano, pretty sure you can leave stuff out |
14:32:19 | daekano | Perhaps I am misinterpreting the error message then |
14:32:21 | daekano | > Error: unhandled exception: invalid field name: centroid [ValueError] |
14:34:02 | daekano | My modest code sample: https://gist.github.com/anonymous/85caa03ef100e145d4c251c4273b731d |
14:34:15 | ftsf | sorry, i think i misunderstood the question |
14:34:38 | ftsf | if your json is missing fields that your object has, i think that's fine |
14:34:50 | ftsf | if the json has extra fields, maybe that causes an error |
14:34:58 | daekano | Yeah that would definitely be the case. |
14:35:13 | daekano | The response has way more information than I am willing to implement in my object at this moment, especially since it is quite nested. |
14:35:54 | ftsf | I see |
14:36:00 | daekano | Trying to read through source of the Marshal module to see if I can confirm |
14:36:13 | FromGitter | <dom96> don't use marshal to parse json |
14:36:20 | FromGitter | <dom96> use the json module |
14:36:30 | FromGitter | <dom96> marshal isn't for parsing json, it's for serialising/deserialising nim objects |
14:36:41 | daekano | okay |
14:36:54 | daekano | thanks @dom96, @ftsf |
14:36:56 | FromGitter | <dom96> ``parseJson(response)["key" |
14:37:06 | FromGitter | <dom96> *``parseJson(response)["key"].getStr()`` |
14:37:12 | FromGitter | <dom96> Simple example |
14:38:16 | daekano | It works, but it’s quite verbose |
14:38:24 | daekano | I imagine I could abstract this though |
14:38:49 | * | wgf_ quit (Quit: Leaving) |
14:39:27 | daekano | Consuming APIs is usually a pretty good way to familiarize one’s self with a new language :) |
14:39:42 | daekano | Far more practical than hello world. |
14:41:41 | FromGitter | <Araq> daekano: Nim can be incredibly terse but the stdlib is mostly conservative |
14:42:21 | FromGitter | <Araq> "quite verbose" often turns into "wtf is this" with some macros :P |
14:43:13 | daekano | Haha |
14:43:26 | FromGitter | <dom96> I personally love the json API |
14:43:32 | daekano | The stdlib seems to be less opinionated about how its building blocks should be used |
14:43:36 | FromGitter | <dom96> and think it's just right |
14:44:01 | FromGitter | <dom96> Languages which force you to define data types to parse JSON are annoying |
14:44:04 | daekano | I imagine getFields could help me abstract the full object parsing but have to explore further |
14:44:12 | daekano | dom96: *cough* golang *cough* |
14:44:17 | FromGitter | <dom96> indeed |
14:44:23 | * | Andris_zbx quit (Remote host closed the connection) |
14:44:34 | daekano | it’s like programming on rails |
14:44:45 | FromGitter | <dom96> daekano: what data do you need out of the JSON you are requesting? |
14:44:49 | daekano | rails as in trains, not as in RoR |
14:45:13 | daekano | dom96: This is mostly an exploratory exercise, I am just pulling out the city/province/code fields |
14:45:16 | FromGitter | <dom96> maybe I could suggest something to make it less verbose |
14:45:24 | federico3 | dom96: speaking of which, I had to switch foo["bar"].getFNum(0.1) to foo.getOrDefault("bar").getFNum(0.1) because it was broken by "0.15". The latter syntax looks a little verbose tho |
14:45:28 | FromGitter | <dom96> that should be dead easy |
14:45:52 | FromGitter | <dom96> federico3: does foo{"bar"} work? |
14:46:06 | daekano | I’m all ears dom96 |
14:47:12 | FromGitter | <dom96> daekano: Getting the city is easy: parseJson(response)["city"].getStr() |
14:47:29 | daekano | Yup, I’ve fetched all of my fields that way |
14:47:37 | FromGitter | <dom96> (You can also use {"city"} if you don't want to crash when "city" doesn't exist in the json) |
14:47:48 | federico3 | dom96: it does - it's that new(ish)? |
14:48:14 | FromGitter | <dom96> federico3: not really. In fact, getOrDefault is newer (Maybe). |
14:48:22 | FromGitter | <dom96> And the only reason it's there is for consistency... |
14:48:37 | daekano | Cool |
14:48:39 | FromGitter | <dom96> which is a bit pointless since {} exists, oh well |
14:48:48 | FromGitter | <dom96> daekano: so do you think that is too verbose? |
14:48:50 | daekano | `simpleGetOrDefault` — nice |
14:49:15 | federico3 | it would be handy to have a foo.getFNum("bar", <defaultvalue>) but would require getFNum to work on the parent |
14:49:22 | daekano | @dom96 I am comparing this method of JSON parsing to PHP’s equivalent in json_decode which converts to a native type in its entirety |
14:49:54 | FromGitter | <dom96> daekano: yes, but PHP is dynamically typed :P |
14:50:03 | daekano | My use case is simple for now but eventually I might have to parse a large body |
14:50:07 | daekano | haha yes that is true |
14:50:35 | daekano | so because the type cannot be known from JSON I have to be explicit |
14:50:35 | FromGitter | <dom96> With static typing you have to be explicit about the type you expect somewhere |
14:50:41 | FromGitter | <dom96> yep |
14:50:50 | krux02 | PHP has increment operator on strings, isn't that amazing and exciting? |
14:51:02 | daekano | are there any serialization formats that have type notation that Nim understands? |
14:51:10 | ftsf | hmm should I get a warning/error if I define a method that doesn't have a base? |
14:51:10 | FromGitter | <dom96> federico3: that exists already I think(?) |
14:51:21 | ftsf | seems like that should be an error |
14:51:35 | FromGitter | <dom96> ftsf: I think it will become an error in the future |
14:51:47 | ftsf | ahh, cool |
14:51:56 | daekano | Is the method removed during compilation at least? |
14:52:02 | ftsf | hmm i'm not sure |
14:52:04 | krux02 | daekano: for xml there is a document format specification, I don't know the name at the moment, but it should be possible to read that at compile time and use it to generate code |
14:52:40 | krux02 | code that puts the xml in statically typed structures |
14:52:56 | krux02 | but I have no practial experience with it |
14:52:58 | daekano | interesting |
14:54:20 | krux02 | XSD is the keyword |
14:54:25 | krux02 | but never used it |
14:54:31 | krux02 | so no guarantee for anything |
14:54:42 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
14:54:57 | daekano | haha |
14:56:11 | krux02 | and it's pretty verbose |
14:56:51 | krux02 | if you want cross language serialization I recommend captn proto, or protobuf |
14:57:06 | daekano | yeah was looking at protobuf as well as messagepack |
14:57:27 | krux02 | basically anything that you send of the wire should be binary, there is no need for texteditor compatibility |
14:59:00 | FromGitter | <dom96> what about when you want to debug? |
14:59:17 | FromGitter | <dom96> non-binary protocols help with that |
15:00:09 | * | yglukhov_ joined #nim |
15:00:44 | daekano | that, and not every consumer can implement a binary deserializer easily |
15:00:50 | daekano | depending on what your audience is of course |
15:03:27 | * | yglukhov quit (Ping timeout: 244 seconds) |
15:05:29 | * | xet7 joined #nim |
15:15:30 | * | arnetheduck quit (Ping timeout: 264 seconds) |
15:26:55 | * | foocraft joined #nim |
15:38:34 | * | wan1 quit (Ping timeout: 255 seconds) |
15:47:28 | * | yglukhov joined #nim |
15:47:40 | * | yglukhov_ quit (Read error: Connection reset by peer) |
15:47:42 | * | yglukhov quit (Remote host closed the connection) |
15:48:38 | * | yglukhov joined #nim |
15:52:28 | * | arnetheduck joined #nim |
15:52:35 | * | arnetheduck quit (Remote host closed the connection) |
15:57:18 | * | pregressive joined #nim |
16:00:24 | * | foocraft quit (Quit: Leaving) |
16:05:37 | * | brson joined #nim |
16:05:54 | * | PMunch quit (Quit: leaving) |
16:06:56 | * | wan1 joined #nim |
16:13:16 | krux02 | dom96: with the same argument you could argument that we should not compile our programs, because it's easier to debug interpreted languages |
16:14:18 | * | enthus1ast quit (Ping timeout: 276 seconds) |
16:15:14 | * | filcuc quit (Ping timeout: 252 seconds) |
16:18:20 | * | rtr_ joined #nim |
16:26:24 | * | nsf quit (Quit: WeeChat 1.5) |
16:27:09 | * | brson quit (Ping timeout: 244 seconds) |
16:29:06 | cheatfate | krux02, nope we must create programs with hexeditor only :) |
16:32:19 | * | yglukhov_ joined #nim |
16:32:52 | * | brechtm_ quit (Remote host closed the connection) |
16:36:30 | * | yglukhov quit (Ping timeout: 264 seconds) |
16:37:06 | * | yglukhov_ quit (Ping timeout: 264 seconds) |
16:38:22 | * | brechtm joined #nim |
16:44:19 | * | AckZ joined #nim |
17:01:00 | * | brechtm quit (Remote host closed the connection) |
17:04:55 | * | brson joined #nim |
17:08:20 | Araq_ | krux02: is it though? IME interpreters hardly even come close to GDB |
17:09:33 | * | Pisuke quit (Ping timeout: 276 seconds) |
17:12:33 | dom96 | Okay, so as far as I'm concerned here is what we need for v0.15.0 to be released: |
17:12:39 | dom96 | (and also what is already complete) |
17:12:58 | federico3 | maybe the http://nim-lang.org/download.html page should have a big version number on top |
17:13:01 | dom96 | * Windows installer (works, even though there is a small PATH issue, if cheatfate or somebody else wants to write a PR to fix it then please do) |
17:13:11 | dom96 | (but otherwise I think it's good enough) |
17:13:25 | dom96 | * Release tarball (no idea what the status of this is, federico3? Araq_?) |
17:13:38 | cheatfate | dom96, you will never give it working on clear windows installation... |
17:13:46 | cheatfate | dom96, as for me its showstopper |
17:13:54 | dom96 | cheatfate: yes, but the old installers also have this problem |
17:13:57 | dom96 | it's not a new bug |
17:14:17 | federico3 | dom96: I'm doing testing and the packaging for Debian but I'm not the one building the tarball :) |
17:14:20 | dom96 | * The news article for v0.15.0 has to be written. |
17:14:26 | cheatfate | releasing in such way is just kicking out newcomers |
17:14:28 | dom96 | federico3: who is building the tarball then? |
17:14:46 | dom96 | cheatfate: then please fix it |
17:14:55 | federico3 | dom96: I guess it's your o Araq_? I've never built the official tarball before |
17:15:03 | cheatfate | dom96, i have no any experience with nsis... |
17:15:13 | dom96 | cheatfate: neither do I |
17:15:24 | dom96 | yet I managed to fix a few things |
17:15:58 | dom96 | federico3: okay, I guess it's up to me |
17:16:09 | dom96 | Hope the wiki page is up to date |
17:16:34 | federico3 | dom96: if it can help, the CI buildbot builds tarballs but we never discussed using them as official releases |
17:16:48 | dom96 | federico3: your circleci one? |
17:16:53 | Araq_ | federico3: that's always been my plan ... |
17:17:00 | Araq_ | why else would it build the tars? |
17:17:14 | Araq_ | bleeding edge via github is good enough |
17:17:56 | federico3 | Araq_: are you saying you want to use the tarball from my CI buildbot for *this* release? |
17:18:13 | Araq_ | yeah why not? |
17:18:29 | dom96 | yeah, let's use it |
17:18:31 | federico3 | last time we spoke you said you were using the .bat file instead because you had to run the NSIS stuff |
17:18:42 | dom96 | why else would you be generating it if not for this? |
17:18:52 | dom96 | in the long run I will probably also get gitlab CI to generate it |
17:19:08 | dom96 | but let's use what you have now |
17:19:13 | dom96 | please give us a link |
17:19:16 | dom96 | I can test it on OS X |
17:19:21 | dom96 | which reminds me, ftsf's game! |
17:19:33 | * | yglukhov joined #nim |
17:19:42 | * | Jesin quit (Quit: Leaving) |
17:19:57 | federico3 | by all means I'm happy to see http://ci.nim-lang.org/ being used by so far we treated it as "unofficial" |
17:20:22 | federico3 | I'll have to fix the build because a change broke it, see https://circleci.com/gh/FedericoCeratto/nim-ci/tree/master |
17:21:24 | dom96 | ftsf: doesn't work I'm afraid |
17:21:40 | federico3 | ftsf? |
17:23:17 | dom96 | federico3: regarding his game |
17:23:42 | dom96 | Araq_: What are the top 3 changes/new things in v0.15.0? |
17:23:59 | * | yglukhov quit (Ping timeout: 244 seconds) |
17:24:13 | dom96 | federico3: okay, please fix it :) |
17:24:22 | federico3 | fixing it now |
17:25:47 | dom96 | thanks |
17:26:20 | * | Jesin joined #nim |
17:37:59 | Araq_ | dom96: no idea lol |
17:38:40 | federico3 | building... https://circleci.com/gh/FedericoCeratto/nim-ci/442 |
17:40:55 | dom96 | Araq_: bah |
17:41:01 | dom96 | Araq_: not even one thing? |
17:45:17 | corecode | i'm happy that nim can easily produce standalone code |
17:45:37 | corecode | i tried with gnat, but that was too complicated to fully pursue |
17:47:24 | * | yglukhov joined #nim |
17:55:36 | federico3 | dom96: http://ci.nim-lang.org/ tadah |
17:55:48 | federico3 | I see all the html files are gone |
17:57:55 | dom96 | what do you mean? |
17:58:15 | dom96 | bootstrapping with clang fails: ld: library not found for -lroot |
17:58:15 | dom96 | clang: error: linker command failed with exit code 1 (use -v to see invocation) |
17:59:03 | dom96 | so that's a problem |
17:59:09 | dom96 | Araq_: Any ideas what the cause is? |
18:01:35 | corecode | does the NimMain volatile inner business exist for establishing the start of the stack for gc purposes? |
18:02:59 | federico3 | dom96: the source tarball from ci.n.o does not contain html docs |
18:05:25 | * | cheatfate quit (Quit: Leaving) |
18:13:29 | * | Matthias247 joined #nim |
18:16:49 | dom96 | federico3: I don't think that's too much of a big deal |
18:16:59 | dom96 | koch is in there, so people can build the docs |
18:17:10 | dom96 | not compiling on OS X is a problem though... |
18:17:36 | federico3 | dom96: last time we spoke about it we were wondering if the html files *should* be in the source tarball. I'd say no, because they are build artifacts |
18:18:01 | Araq_ | dom96: regression, i didn't review the "add Haiku support" PR carefully I guess |
18:23:03 | dom96 | Araq_: I don't see how that could cause it |
18:24:54 | FromGitter | <Araq> nim.cfg changed, look at it |
18:26:12 | dom96 | yes, it did, but it only added haiku things |
18:26:36 | dom96 | unless ... |
18:26:44 | dom96 | I think I see the problem |
18:27:09 | dom96 | `@if not bsd or haiku:` = `@if not (bsd or haiku)` |
18:28:32 | dom96 | I just git pulled and I can still compile... |
18:29:00 | dom96 | so I'm really confused |
18:37:18 | * | yglukhov quit (Remote host closed the connection) |
18:40:41 | hohlerde | is there a way to create a ref to a tuple? |
18:47:25 | dom96 | hohlerde: why do you want to do that? |
18:48:09 | hohlerde | I don't want to do it, but this question came up in my mind while I am preparing my Nim presentation |
18:48:52 | hohlerde | so I tried: "var x: ref tuple[a: int, b: int]" |
18:49:37 | hohlerde | and the compiler didn't complain so I tried to find a way to assign a ref to x, without luck so far |
18:50:06 | Araq_ | new(x); x[] = (a: 2, b: 4) |
18:50:24 | Araq_ | there is no sugar for it because it never comes up |
18:50:27 | dom96 | https://gist.github.com/dom96/f849707709a3c6d929310eb623a41bd0 |
18:50:58 | hohlerde | ahhhh, of course ... thank you araq and dom96 |
18:51:05 | hohlerde | now I feel dumb |
18:51:06 | dom96 | Araq_: It is the Haiku PR |
18:51:25 | dom96 | But it doesn't make sense |
18:51:36 | dom96 | Niminst adds -lroot to its global linker flags |
18:51:56 | dom96 | instead of only the Haiku ones |
18:52:10 | * | gangstacat quit (Quit: Leaving) |
18:52:10 | dom96 | so I think it's a niminst bug |
18:52:17 | dom96 | or er, not niminst but koch |
18:52:26 | dom96 | whatever ./koch csources uses |
18:52:51 | Araq_ | ah yeah it's a niminst bug, hard to fix |
18:52:59 | Araq_ | we shall find a workaround |
18:53:29 | dom96 | This PR won't work anyway without a change to the build.sh template |
18:53:53 | dom96 | Also |
18:53:58 | dom96 | I think I see how you worked around it before |
18:55:19 | krux02 | is there an echo that does not print newline it compile time? |
18:55:28 | krux02 | stdout.write does not work at compile time |
18:56:01 | Araq_ | then the answer is no. |
18:57:14 | krux02 | Araq_ was that answer to me? |
18:59:37 | * | wan1 left #nim ("WeeChat 1.5") |
18:59:53 | Araq_ | krux02: yes |
19:01:11 | Araq_ | dom96: maybe just rollback the haiku PR then? |
19:01:39 | dom96 | Araq_: fixed already |
19:01:46 | dom96 | federico3: could you rebuild? |
19:03:40 | * | kulelu88 joined #nim |
19:04:17 | * | Kingsquee joined #nim |
19:04:25 | * | libman joined #nim |
19:06:48 | * | yglukhov joined #nim |
19:07:00 | federico3 | sure |
19:07:18 | federico3 | build 444 started |
19:09:07 | * | Kingsquee quit (Client Quit) |
19:10:09 | * | Ven_ joined #nim |
19:13:19 | * | Kingsquee joined #nim |
19:14:54 | * | brson quit (Ping timeout: 264 seconds) |
19:20:55 | dom96 | Looks like release ain't happening today either |
19:21:08 | dom96 | but let me know when the build finishes |
19:23:27 | federico3 | dom96: it finished |
19:23:49 | federico3 | 8 min ago - I didn't see your msg |
19:25:29 | dom96 | thx |
19:28:19 | * | cheatfate joined #nim |
19:29:25 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
19:30:49 | dom96 | cool, works |
19:31:02 | dom96 | So I think we should remove the install_nimble.nims script from there |
19:31:11 | dom96 | and rename the install_tools script to compile_tools |
19:32:14 | dom96 | shit, I forgot to update Nimble's version string |
19:37:48 | * | Kingsquee joined #nim |
19:43:19 | * | corecode quit (Ping timeout: 252 seconds) |
19:47:49 | * | heinrich5991_ joined #nim |
19:48:02 | * | brson joined #nim |
19:48:56 | * | corecode joined #nim |
19:49:30 | * | gsingh93- joined #nim |
19:50:01 | * | heinrich5991 quit (Ping timeout: 252 seconds) |
19:50:03 | * | gsingh93 quit (Ping timeout: 252 seconds) |
19:50:03 | * | kier quit (Ping timeout: 252 seconds) |
19:50:04 | * | heinrich5991_ is now known as heinrich5991 |
19:50:39 | * | gsingh93- is now known as gsingh93 |
19:50:40 | * | kier joined #nim |
19:52:57 | daekano | Oh! dom96 just realized you are the author of Jester. Thanks for taking the time to help me out earlier! |
19:53:01 | * | gangstacat joined #nim |
19:53:13 | dom96 | np :) |
20:00:37 | * | flyx quit (Ping timeout: 272 seconds) |
20:05:08 | jeffc | Powered by nim :): http://imgur.com/wYjE7NT |
20:06:16 | jeffc | Testing out fixed point PID controller. Code is going to go into a dynamic brake cooling system for rally cars |
20:07:06 | dom96 | jeffc: awesome! |
20:07:47 | dom96 | jeffc: does that red board have a name? |
20:08:03 | jeffc | It's just an infineon xmc4200 'actuator' devkit |
20:09:45 | jeffc | My hope is to eventually open source all of the embedded libraries I'm writing as a sort of alternative to arduino |
20:10:46 | * | flyx joined #nim |
20:12:56 | * | Ven_ quit (Ping timeout: 244 seconds) |
20:14:49 | * | Pisuke joined #nim |
20:20:13 | federico3 | jeffc: I guess the micro is quite more expensive than the usual atmegas |
20:21:45 | federico3 | dom96: btw, the CI is building automatically again, you can click on Started build number to check if the last build is done |
20:21:59 | dom96 | federico3: cool thanks |
20:22:15 | federico3 | it will start a new build on every commit to Nim |
20:22:34 | federico3 | (well, not every - one every few minutes) |
20:25:19 | * | Ven_ joined #nim |
20:27:33 | jeffc | federico3: atmega 328p in automotive temp range is ~$7, the xmc4200 on this board is ~$6. |
20:27:55 | federico3 | nice |
20:28:04 | jeffc | yeah, it's a really solid chip |
20:39:18 | * | nsf joined #nim |
20:43:56 | * | Ven_ quit (Ping timeout: 244 seconds) |
20:46:25 | * | Ven_ joined #nim |
20:53:22 | * | Xe quit (Ping timeout: 252 seconds) |
20:55:47 | * | Xe joined #nim |
20:56:43 | * | krux02 quit (Quit: Verlassend) |
20:58:04 | * | enthus1ast joined #nim |
20:58:06 | * | Ven_ quit (Ping timeout: 264 seconds) |
21:01:26 | * | Ven_ joined #nim |
21:05:32 | * | Xe quit (Ping timeout: 252 seconds) |
21:08:04 | corecode | jeffc: oh cool! |
21:08:12 | corecode | infineon, is that arm? |
21:08:30 | jeffc | corecode: Yeah, cortex-m4 |
21:08:54 | corecode | how do you build for it? |
21:09:02 | corecode | also, how do you debug nim code? |
21:09:32 | corecode | i played around with getting a minimal nim arm-none-eabi build last night |
21:09:58 | * | confundus joined #nim |
21:10:03 | * | Xe joined #nim |
21:10:41 | corecode | are there FSM libraries for nim? |
21:11:00 | * | confundus quit (Client Quit) |
21:11:18 | jeffc | Right now it's built with a makefile telling it where all the various nim libs I need are (so I don't need to nimble install them after every change) and setting up the verious nimflags I need |
21:11:32 | jeffc | But the actual compilation is just a call to nim c main.nim |
21:11:49 | jeffc | Debugging: I Use openocd + gdb |
21:12:00 | corecode | do i get to read nim code? |
21:12:04 | jeffc | (though it really needs some work re; unmangling) |
21:12:16 | corecode | i just started yesterday with nim |
21:12:54 | jeffc | By FSM, do you mean finite-state-machine? |
21:13:33 | * | libman quit (Remote host closed the connection) |
21:13:46 | corecode | yes i do |
21:13:54 | jeffc | I'm actually using FreeRTOS, so the state machines are lock and queue driven at this point. |
21:14:07 | corecode | so implicit |
21:14:13 | jeffc | yeah |
21:14:20 | corecode | i use smc to compile |
21:14:39 | corecode | but with nim it would be great to have a FSM DSL integrated |
21:14:51 | corecode | i have written an embedded "OS", maybe i can rewrite it in nim |
21:15:02 | corecode | (mchck.org) |
21:16:15 | jeffc | Very cool |
21:16:27 | jeffc | *perusing code* |
21:16:44 | corecode | heh |
21:17:20 | corecode | GPL tho, so i can't use my own stuff for commercial customer projects (because other people contributed to the codebase as well) |
21:17:41 | corecode | recently grew threads |
21:18:25 | jeffc | Yeah, I was looking to see if you were using context switching or coroutines :) |
21:18:41 | jeffc | (or some clever callback magic) |
21:18:46 | corecode | i bet i don't understand coroutines |
21:19:03 | corecode | i use context switching |
21:19:32 | corecode | bog standard OS time slice based preemptive multitasking |
21:20:46 | corecode | jeffc: i started out with just async programming with completion callbacks |
21:20:58 | corecode | but it becomes spaghetti quite quickly |
21:22:38 | jeffc | Indeed. I'm not a huge fan of async callback based architectures. My (now former) dayjob had a product that was written in C and based on a homegrown version of CORBA. Nasty stuff. Horrible to debug. |
21:24:20 | * | brson quit (Read error: Connection reset by peer) |
21:24:22 | corecode | anyways, my hope is that with nim + macros, implementation of FSMs can be done in a formal way, inside the language |
21:24:45 | * | Pisuke quit (Ping timeout: 244 seconds) |
21:26:20 | * | desophos joined #nim |
21:28:00 | * | brson joined #nim |
21:30:11 | * | jeffc quit () |
21:31:32 | * | Pisuke joined #nim |
21:32:33 | * | Matthias247 quit (Read error: Connection reset by peer) |
21:39:02 | * | Trustable quit (Remote host closed the connection) |
21:39:34 | cheatfate | coroutines uses context switching too |
21:40:23 | corecode | cooperatively tho i guess |
21:41:18 | * | gokr joined #nim |
21:41:51 | cheatfate | corecode i think you have implemented coroutines for your OS but you call it multitasking :) |
21:42:01 | cheatfate | same shit but different approach :) |
21:43:18 | corecode | yea no, i have a run queue, priorities, and time slices |
21:43:18 | cheatfate | switching context is the main difference i think, when to switch - that is the question :) |
21:43:25 | corecode | i don't think that's considered coroutines anymore |
21:48:27 | corecode | so it seems there is no standard FSM package for nim? |
21:48:53 | cheatfate | corecode, yeah we need one :) |
21:49:33 | corecode | do you have some design ideas or pointers? |
21:50:43 | cheatfate | corecode, it depends how much time you have :) |
21:51:09 | cheatfate | corecode, it would be nice to have async as FSM |
21:51:26 | cheatfate | corecode, but it would be nice to build FSMs for parsers too :) |
21:51:55 | cheatfate | and i think you need to take a tour on nim macros engine |
21:52:07 | corecode | i do |
21:54:06 | federico3 | corecode: the hchck looks amazing |
21:54:30 | corecode | forget the usb connector on the pcb |
21:54:32 | corecode | doesn't work well |
21:55:24 | federico3 | ouch |
21:56:01 | corecode | i'd like to have some time to develop a useful API and port it to a couple of current platforms |
21:56:18 | corecode | anyways, FSM |
21:56:24 | corecode | not to get side tracked |
21:56:39 | corecode | cheatfate: what do you mean by async as FSM? |
21:57:29 | cheatfate | corecode, currently we use iterators for our async core, but i some month ago i have read issues about using state machines for asynchronous engines |
21:58:07 | cheatfate | i think this can greatly improve speed of our async core |
21:59:30 | cheatfate | corecode, http://www.codeproject.com/Articles/535635/Async-Await-and-the-Generated-StateMachine |
22:02:42 | corecode | i think i need to know what state machine that post is talking about |
22:07:00 | corecode | cheatfate: i'm thinking of something like smc, not ragel |
22:07:11 | corecode | ragel is just impossible to reason about |
22:08:16 | cheatfate | corecode, i'm not very familiar with state machine theory, so `smc` or `ragel` don't tell me anything :) |
22:08:51 | corecode | ask teh google |
22:09:19 | corecode | both take definitions of state machines (i.e. states and transitions) and produce code |
22:11:12 | cheatfate | corecode, asking google is my favorite hobby |
22:11:18 | * | gokr quit (Ping timeout: 264 seconds) |
22:29:18 | * | Pisuke quit (Quit: WeeChat 1.5-dev) |
22:30:35 | * | enthus1ast quit (Quit: Leaving.) |
22:32:32 | * | brechtm joined #nim |
22:35:24 | * | enthus1ast joined #nim |
22:37:06 | * | brechtm quit (Ping timeout: 264 seconds) |
22:42:15 | * | irrequietus quit (Ping timeout: 244 seconds) |
22:46:47 | * | elrood quit (Quit: Leaving) |
23:01:13 | * | PMunch joined #nim |
23:43:23 | FromGitter | <gogolxdong> how to implement a template or generics to return ptr of type(x)? |
23:47:47 | cheatfate | template getptr(a: int): ptr int = |
23:48:00 | cheatfate | var b = addr a |
23:48:02 | cheatfate | b |
23:49:15 | FromGitter | <gogolxdong> could x be untyped? |
23:49:55 | cheatfate | template getptr[T](a: T): ptr T = var c = a; ptr c |
23:50:30 | cheatfate | oops var c = a; addr c |